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.
I should've done the same. After 8 months of having it it still has a lot of very weird issues. I hoped Dell would somehow fix it with a firmware update but nope... everything is still the same.
Which version? I've got XPS 13 9350 and it's been a constant pain. Boot time is very slow [0], bluetooth connectivity is weak, I've got constant graphic glitches when on battery. Latest update of the video driver introduced annoying coil noise, I had to downgrade. Actually I have two XPS 13s at home and both of them have some issues.
I'm also using Dell Thunderbold Dock TB15 and it drops video output and USB connections after 3h (because of heat) [1].
Of course I've got everything updated.
I had an excellent experience with XPS 12 years ago but this 9350 is constantly driving me crazy. I would certainly not recommend it.
Not the parent but I'm using it to stage sections of the file and then revert everything that is not staged. For example all logging statements.
Or use staging as a mini commit. It's sometimes easier to look at the diff and stage what you consider to be working code without introducing commits. That of course could also be done with committing and then squashing but that's more work :)
Very cool. It's amazing to me that the developer got it under 1KB.
This is the first I've heard of that project, but based on a quick skim, I can point out a few differences between it and Runiq - although the two are certainly similar in that they execute over a very simple plain-array-based AST. (Clearly miniMAL and Runiq were created with different ultimate aims in mind, so any fair comparison ends there. :) )
- Runiq is fully designed around async. (At first glance I'm unsure how you would express, say, an HTTP request or file I/O in miniMAL - i.e., anything which in JS would require a callback.) In Runiq it would look something like this:
; assuming 'print' and 'read-file' are defined in the DSL... ;
(print (read-file "foo.txt"))
- Runiq execution happens in parallel (taking a cue from functional languages) and the tree can be reduced stepwise; Runiq has a built-in mechanism for pause and resume. It looks like miniMAL executes wholesale, but I may be mistaken.
- Runiq has no (built-in) JavaScript interop, although it would be trivial to add that feature via Runiq's DSL-building API. I specifically avoided adding any type of sytnax to talk to JS directly because I wanted Runiq to be a safe sandbox by default, with the option to add "dangerous" functions easily if need be.
But, that's super cool and I wish I'd come across that earlier!
Oh, I just found a issue for that: https://github.com/Microsoft/vscode/issues/1031