Also nice to see ARM getting some attention. Still too many places offer Linux builds in 32 and 64 bit where It's like the Blues brothers line "we have both kinds of music here, County _and_ Western"
(There are some of us, we do exist, world) :-)
If you don't want to install Crouton, it's possible to do some moderately clunky development using Chrome Developer Tool's little-known IDE feature; you can point it at a local directory and edit files there. That allows HTML/JS development directly on an unmodified Chromebook, including the integrated debugger. It's not brilliant, though. If you want to go that route your best bet is a cloud development platform (which requires a network connection, of course).
I wonder if its possible to port vscode to run inside Chrome as a downloadable webapp?
I develop on a Chromebook some times. I use a DigitalOcean VPS, using tmux + vim to code and ChromeOS to debug.
Why shouldn't I buy a chromebook and put linux on it?
I got an Asus delivered with Linux for 300 €.
Do you have links to models you'd recommend?
Sure it doesn't have 1080p, but most apps aren't able to use it anyway.
https://libreboot.org/faq.html#intel
I replaced ChromeOS with a fully free Debian system.
This in itself proves one of my previous points, Intel has no serious competition, even the big industrial players can't bend Intel.
[0] https://chrome.google.com/webstore/detail/caret/fljalecfjcio...
I've been waiting forever for a good local Git client for chromebooks but it seems like there's just no one working on it. The few that are on the chrome app store haven't been updated since 2013-14 and are full of bugs and don't actually even work. If one existed, I would be able to clone a repo locally and at least edit code in a stable way even when internet is flakey.
I'm currently working on a Mail application and my benchmark test case is an email account with 20,000 emails to be displayed. Noting we currently have no lazy loading and all these are loaded from an on-disk database and put inside their own Shadow DOM it truly did surprise me when it took just over 400ms for an entire page load on my development laptop (~3 years old with an i5, nothing special).
Even if you need to do complex algorithms, just write that particular part in C and use it in the rest of your JS code like normal.
My main issue is battery life. I just need to open one electron app (Discord, Slack, Spotify even though that's CEF, but close enough) to have powertop drop from 10 hours expected battery life to 3-4.
That's really surprising to me, I've had completely the opposite experience. Just resizing a window shows how slow it is to repaint and scrolling is often pretty poor too, and this is on a moderately powerful desktop machine. I really hate to think how it'd cope on an embedded device with an ARM processor. There's a marked difference to me between Atom and e.g. Sublime Text.
> I'm currently working on a Mail application and my benchmark test case is an email account with 20,000 emails to be displayed.
Is this benchmark open source? I'd be really interested to try it compared to something similar build in Qt or Gtk+.
> Even if you need to do complex algorithms, just write that particular part in C and use it in the rest of your JS code like normal.
This might speed up complex background processing, but the fact remains that the UI is built on the DOM with interactions handled by JS. It's just not ideal for a desktop application.
With all that said, I totally understand why a lot of applications are built with these sort of technologies. It's much easier to build a cross-platform application than anything else. The price you pay is that the UX is poor.
- signed, former Atom user.
In my experience, VSC's cold boot startup time is just as bad as Atom, and it's not immune to interface jank - for example, when unfolding the "tree view" on one of my projects, I can actually see the folders being painted top to bottom.
But I don't use VSC day-in-day-out (since it's missing multiple project root folder support), so perhaps I'm missing something.
Afraid it's not, currently the only working copy is closed-source whilst I work on rewriting it all into an open source repository. Having said that, I'm in no doubt that Qt or Gtk+ would be significantly faster than rendering what is essentially a local website.
> I really hate to think how it'd cope on an embedded device with an ARM processor. There's a marked difference to me between Atom and e.g. Sublime Text.
Reminds me of a joke told by a friend of mine:
Friend: "The thing I like about Atom is that it encourages you to write small files."
Me: "How does it do that?"
Friend: "Well, it crashes if you write more than a couple hundred lines."
Personally, I too do use Sublime Text. Not entirely sure how Atom is so slow, but it takes ten times longer to startup and five times longer to search through my files. Definitely caused me to switch away from it.
> but the fact remains that the UI is built on the DOM with interactions handled by JS
Excellent point, but I think if you're doing complex interactions that require a large amount of computing time then you shouldn't be using a program like Electron. For something like a mail application, not much changes. We actually never remove mail items, simply hide them from view, so we have one large render time at start-up and then almost none after that (displaying and hiding an element from view is incredible efficient). For something like atom, you have a significant amount more happening and you want just about everything to be instantaneous. Plus the fact that it's expected to be able to deal with large files consistantly without any hiccups.
Of course, atom is a specific case that lagged behind vscode for a while. I have no idea whether that's still true.