There are a few options I've been looking at that could yield improvements in this area.
1) Install the play store, if your chromebook supports it. Then something akin to Gnuroot Debian, and set up the environment that way. Install the package, and then forward the X11 window to something like "XServer XSDL". Tricky to explain to people, and I couldn't get it working when I tried for a few different reasons.
2) Add a side-by-side node.js server inside VS Code. This would effectively serve up the HTML/CSS/Javascript inside the window and the user could just use the web browser. By launching on boot this would have the neatest integration with Chrome OS, as you could pin to shelf and then it's just a http://localhost:XXXX URL. Even if the web content could be forwarded in this way I think re-implementing the Electron calls for the web could be a lot of work, and it probably belongs as an alternative Electron implementation I would think. The upside is that you wouldn't need dev mode as this could also run under e.g. GNURoot.
These are a couple of ideas I've had. Would be eager to get someone from Microsoft's take on it though. :-)
It shows my own homebrewed Desktop environment running in a browser window with a Monaco based editor open. So it's doable, but it would need quite a bit of work to beef it up to VS code abilities.
Things are a bit broken right now(like file requesters don't return the file selected)
I work on it sporadically. Now that native promises are a thing I want to go through and tidy up some of the callback structure. The App API should ideally be all promise based.
It's an intimidating task though. Next big update I'll probably get it to a point where I ask assistance.
As someone who's never owned one, I think there is something called 'crouton' which makes a chromebook into sort of like a low-end ubuntu laptop. Given that I've run VS code on Ubuntu with 2gb ram, it seems like it should be doable.
Judging from comments in this thread 'crouton' still has a several second splash screen on boot telling you to press space that when pressed wipes your entire drive.
Hacks like this which devs seem to be happy to endure are not a solution for helping these kids to code.
People keep saying this without realizing what is going on truely, there is two option:
1. Install crouton and use shell to Chroot to your distro (which makes most sense, became what is the reason to buy Chromebook in first place, since maybe you can buy laptop with better Linux support about same price, in this option you have your dev tools in your distro and simultaneously you enjoying your command line dev tools)
But remember you are inside chrome OS so you dont have any way to access graphic stack and run Linux GUI app, I think with recent port of Android stack to chrome OS , makes Chromebook more valuable except if you want to run something like Java Swing oe eclipse( eclipse working on web UI , named Che)
2.Use croutin to install complete stack to run Linux GUI apps too.( Honestly I don't understand rational behind this, since you don't have for example Win key in Chromebook and many other issues.)
The point of a Chromebook is ChromeOS. If you're using Ubuntu you might as well be using a low-end PC. Nothing wrong with that, but it's not a Chromebook any more. Chromebooks are not about the hardware.
There are a few options I've been looking at that could yield improvements in this area.
1) Install the play store, if your chromebook supports it. Then something akin to Gnuroot Debian, and set up the environment that way. Install the package, and then forward the X11 window to something like "XServer XSDL". Tricky to explain to people, and I couldn't get it working when I tried for a few different reasons.
2) Add a side-by-side node.js server inside VS Code. This would effectively serve up the HTML/CSS/Javascript inside the window and the user could just use the web browser. By launching on boot this would have the neatest integration with Chrome OS, as you could pin to shelf and then it's just a http://localhost:XXXX URL. Even if the web content could be forwarded in this way I think re-implementing the Electron calls for the web could be a lot of work, and it probably belongs as an alternative Electron implementation I would think. The upside is that you wouldn't need dev mode as this could also run under e.g. GNURoot.
These are a couple of ideas I've had. Would be eager to get someone from Microsoft's take on it though. :-)