Improving startup time in Atom with V8 snapshots
blog.atom.ioNew world, same old problems. Fascinating to see how this parallels the way Emacs tackled this problem long ago.
It's because when you truly add a new capability to your toolset, like 100ms installs, or universal cross platform loading, this has ripple effects through every problem you solved before. Some things simply don't work in the new codebase, other things have regressed. Then you go back and one-by-one you fix everything to work in this new reality. This happens every time our aggregate software architecture gets a big new ability.
Of course if you're touching the same code over and over again, that's probably a sign you're not solving the problem well. Solving problems with a finality such that they don't have to be reopened again and again is the aim of good software engineering. That is true.
But in order to get there, you need to periodically add a major new capability—and thus a major new assumption—to your architecture. If you're not making these kinds of sweeping changes every now and then it's almost certain that you're not actually doing deep refactors that resolve longstanding challenges in lower energy ways.
Resistance to these kinds of sweeping changes amongst professional developers and their ambassadors at major platform companies is the reason why Windows, iOS, Oracle, and the like have stable interfaces and smaller audiences. On the web you don't need permission to write a whole new JavaScript framework, so people can take those first big steps, even though they are quite painful for the developer.
Let's not forget Lisp I.
Lisp I Programmer's Manual, 1960, Page 67
http://history.siam.org/sup/Fox_1960_LISP.pdf> ... that immediately after all the triplets have been > evaluated the state of the memory as it stands is read out > onto tape 8 as the new "base" image for the memory. ...And sendmail long ago (pre-sendmail 8) -- it used to dump out a binary image of itself after parsing sendmail.cf to speed up startup.
It also looks very similar to a Smalltalk image...
And here's a relevant explanation from drfuchs.
https://news.ycombinator.com/item?id=13076098
I quote it in full, here:
OK, if you promise to stay off my lawn, I'll explain the history behind undump. Back in the 70's, the big CS departments typically had DEC 36-bit mainframes (PDP-10, PDP-20) running the Tops10/Tops20/Tenex/Waits/Sail family of operating systems. These are what Knuth used to do all of TeX, McCarthy LISP, and Stallman and Steele EMACS. Not Unix; and Linus hadn't touched a computer yet.
Executable program files were not much more than memory images; to run a program, the OS pretty much just mapped the executable image into your address space and jumped to the start. But when the program stopped, your entire state was still there, sitting in your address space. If the program had stopped due to a crash of some sort, or if it had been in an infinite loop and you had hit control-C to interrupt it, the program was still sitting there, even though you were staring at the command prompt. And the OS had a basic debugging capability built-in, so you could simply start snooping around at the memory state of the halted program. You could continue a suspended program, or you could even restart it without the OS having to reload it from disk. It was kind of a work-space model.
Translating into Linux-ish, it's as if you always used control-Z instead of control-C, and the exit() system call also behaved like control-Z; and gdb was a builtin function of the shell that you could invoke no matter how your program happened to have been paused, and it worked on the current paused process rather than a core file (which didn't exist).
The OS also had a built-in command to allow you to SAVE the current memory image back into a new executable file. There wasn't much to this command, either, since executables weren't much more than a memory image to begin with. So, the equivalent of dump/undump was really just built into the OS, and wasn't considered any big deal or super-special feature. Of course, all language runtimes knew all about this, so they were always written to understand as a matter of course that they had to be able to deal with it properly. It pretty much came naturally if you were used to that environment, and wasn't a burden.
Thus, when TeX (and I presume the various Lisp and Emacs and etc. that were birthed on these machines) were designed, it was completely expected that they'd work this way. Cycles were expensive, as was IO; so in TeX's case, for example, it took many seconds to read in the basic macro package and standard set of font metric files and to preprocess the hyphenation patterns into their data structure. By doing a SAVE of the resulting preloaded executable once during installation, everyone then saved these many seconds each time they ran TeX. But when TeX was ported over to Unix (and then Linux), it came as a bit of a surprise that the model was different, and that there was no convenient, predefined way to get this functionality, and that the runtimes weren't typically set up to make it easy to do. The undump stuff was created to deal with it, but it was never pretty, since it was bolted on. And many of use from those days wonder why there's still no good solution in the *nix world when there are still plenty of programs that take too damn long to start up.
Hey! I don't get the karma points?!
12 hours later: Well, this has now garnered me more karma than my original posting; thanks, winestock!
Sure you do (at least one from me)! You'd get more though if you somehow reintroduced this lovely way of doing things back into the mainstream. I guess we sort of have it again with VM snapshots, but that's not nearly as elegant. I love the idea of having a persistent memory state that can be examined or reentered. That's how it should be!
I don't recall overcoming long startup times in vi and vim. Did I miss something?
Emacs and Atom share the architectural aspect of implementing most of their functionality in a higher-level language inside of an execution environment. This has costs and benefits.
vi had a much simpler structure and much more limited feature set. vim is obviously a much more capable/flexible editor and has scripting support, but is still predominantly written in C.
Not necessarily. You might just be extra patient, or not use many plugins, or only use well behaved ones that down slow down startup that much. I remember years ago when I used Vim I had pretty slow start up time for a while but narrowed the problem down to one plugin I decided I could live without (can't remember which one it was, though).
Is Coffee-Script still a thing? Looking at Atom source code it's still 80% in Coffee-Script. Why hasn't someone rewrote (eg transpiled and than refactored) it in JS with hand-tuned optimisation? https://github.com/atom/atom/tree/master/src
Was listening to a podcast with one of the first Atom authors (Nathan Sobo) and he mentioned that all new code is in ES6 these days. The codebase is pretty big. They're doing a convert-on-touch approach he said.
https://itunes.apple.com/ca/podcast/the-changelog/id34162326...
I'm way more worried about memory issues while running. Atom take up 1 gig+ with very little open. It pushes all my other tools out of RAM and into swap. Switching to the browser to see documentation takes a few seconds if I'm lucky.
Compiling a few more seconds to page in. Ssh a few more. Everything on my laptop slows to a crawl as they fight for RAM with Atom taking up the way more than it should.
I know the answer, "buy more RAM it's cheap", from the Atom people, but then my browser people tell me the same thing. So do my interface people, and my kernel people, and by the time I say "okay" to all of them, I'm out of RAM again.
Application need to learn they aren't the only thing running. For some reason, my machine seems to be getting slower and slower no matter how much I upgrade.
> I'm way more worried about memory issues while running.
Same here. Start-up time is important when the average user is hitting a web app or application but for developers? We open something once and then keep it open pretty much all day.
Unless I'm an edge case I'd suspect start-up time is mostly meaningless to developers with long running developer tools.
At the same time we always have tons of tools open at once so we need as much memory as possible because once things hit the swap the performance degrades terribly.
If Atom ran like vim, I'd take 60 seconds+ of startup time. If it ran like ed, maybe even an hour.
I probably spend more time hitting backspace when typing 'atom' than they saved in startup time.
What is cheaper, more memory or a SublimeText license?
Depends on the region you're in. Around here an 8gb ram module costs the same as a sublime text license.
I'll take the license.
I was just looking at a DDR3L 8GB module for $43, but I could perhaps see the value in Sublime at $70 a license if it significantly improves on Atom, but as it is I've yet to even fully utilize all that Atom offers, or have pain points.
> For some reason, my machine seems to be getting slower and slower no matter how much I upgrade.
I've been feeling this way for years, and I've mostly ascribed it to my faulty perception. I figured that if things simply aren't getting faster (i.e., they're not changing at all), I'm probably just imagining them getting slower.
But then I start wondering why aren't things getting faster...
amdahl's law
Atom is far from the only option. There are plenty of better text editors that will fly on that machine.
I don't get this. I've built text editors in JavaScript. I've built Electron apps. Granted, I've never built a text editor in Electron. But it's gotta be some trivial combination of my past experiences. I don't understand why Atom is such a pig.
Sounds like you're running on 4GB of RAM, which in today's dev world is nothing, I've been on 16GB for over 3 years and have yet to worry about RAM being a limiting factor.
I'd say buy some more RAM, it IS cheap and you never have too much.
Laptops with 16 gb are still very rare.
I've had 16GB in my laptop for about 3 years now. Laptop CPUs have supported 16GB for quite a while. Granted I'm an Apple guy, so maybe 16GB isn't as accessible in Windows world? :(
same here, I've switched away from Atom for that reason.
You could try lowering the "swappiness".
Is there any way not to conclude they have just been out designed/architected/optimized by Microsoft?
What a compliment to the VSC team that after all this work, Atom still doesn't seem to match startup time, or more importantly perceived performance while editing.
It's a more interesting comparison since they're both bound by similar constraints, and building cross platform apps.
In the bad old days I once worked for a MS competitor where there were often complaints of unfair competition. Most often around how knowledge of closed sourced OS internals allowed optimization insights unavailable to others.
Not all MS devs are great for sure, but I'm inferring two things here. The VSC team is pretty damn good, and that IP and institutional knowledge from decades of investment in dev tools probably helps a bit.
I'd offer the alternative theory that the VSCode team learnt everything they could from Atom's past mistakes.
Speed is only one of the issues–I'm actually quite happy with Atom in that regard. VSCode has a much more restricted API, and a more robust extension system. With Atom, I always felt like extensions started interfering with each other, and with the 'vanilla' experience. OTOH, I was exploring a few ideas, such as inline rendering of comments in markdown, and that's really only possible in Atom.
Sounds similar to the complaints about Firefox, though the only notable issues I've run into with Atom have been related to shared file editing (and resulting sync issues). If someone could just leverage etherpad lite with Atom, it'd make me so happy!
Firefox mostly has the problem that the open web suddenly became incredibly important for Google: it's their platform, in the fight against Facebook and Apple's iOS.
No organisation on the planet could compete with a team that Google considers a core asset for actual survival.
Mozilla has made quite a few mistakes, but the times may change, and I sure hope they'll be around when Google's incentives are no longer aligned with the open web's.
Google can be out-competed, look at their attempts at social networks & messaging/calling.
Google has lit dumpsters full of cash on fire in an effort to get anywhere near Facebook, Twitter, Whatsapp, Viber or even Signal Private Messenger, and yet their extremely fractured strategy that they have dumped R&D into still has less users than any of those in their respective categories.
Mozilla can be competitive, akin to Darktable vs Adobe if Mozilla chooses to be. No more mucking about bailing their friends out (ie: Pocket acquisition), or trying to fight Google on hardware prices (Firefox OS's entire strategy). Mozilla can create a playing field tilted in their favor, and force others to compete on their turf rather than duking it out on Google or Chinese OEMs turf.
I'd offer the alternative-to-your-alternative-theory that the VSCode team had members that had lots of real world experience working on text editors and desktop apps, whereas Atom, based on the company's public statements on the matter, started as a hobby project by the CEO and slowly added a few very smart non-specialists over the years..
In other words, unlike the Atom team, VSCode didn't have to re-make mistakes Microsoft learned from 15 years ago...
Why is it always Atom and VS Code and no one talks about Adobe Brackets, is it comparable for JS development? too bad Adobe doesn't care about Linux.
Plus their speed of development has been incredible. I don't imagine it's a very large team.
And their change logs are great, thankfully.
I'll provide a contrasting opinion to the comments saying startup time isn't important to them.
I tend to work chaotically. I dive into a project and tackle whatever the problem of the day is. The result is a sprawling mess of reference code pulled up in different editor windows, documentation and google results spewing out over 4 browser windows and 30 tabs, and just as many terminals managing VCS, compilation, tests, etc.
It's not that I'm a messy coder or anything; it's just that when I'm focused on a problem then my concern is about that problem, not about the growing heap of reference material. The problem is particularly pronounced when working on web applications, where I have to handle multiple code bases at once.
Once I'm done, I'll become horrified by the state of my desktop and proceed to close everything.
The next coding session starts fresh.
So startup time is actually important to me. I have to say I'm annoyed by VSCode's startup time. It starts up to a state where I can hit the menu and start opening things very quickly, but isn't completely finished for another couple seconds. Atom's in a very similar boat.
I'm glad to see progress being made here.
Great article. Avid ST3 user here, but glad to hear about the improvements.
For anyone curious, I made a quick gif comparing startup times on my machine for Sublime Text 3 (Build 3129), Atom (1.16.0), Atom Beta (1.17.0-beta2, the one mentioned here), VSCode (1.11.2), and VSCode Insiders (1.12)
https://media.giphy.com/media/3ohzdTHkfj5ISAAPq8/source.gif
I should mention - my ST3 is heavily customized (28 plugins), while Atom and VSCode are absolute stock.
They all look to be within the same ballpark; none of those startup times would be a problem for me, at least. But when I tried Atom it was noticeably less responsive, which I have very little tolerance for. I haven't tried VS Code. (I also use Sublime)
My experience is that VSCode is much more responsive than Atom.
Just a lot "snappier". Startup is not much of a problem, I don't open ordinary files in VSCode or Atom by default (I use gedit for that)
Showing a window is in the same ballpark, but being ready for input is something else. On Sublime this is basically the same instant. On VSC and Atom it takes a bit longer to actually render a cursor.
Nice comparison! Would be even better to see them all side-by-side.
> Overall, on a stock installation, we made loading Atom almost 50% faster and snapshots were a crucial tool that enabled some otherwise impossible optimizations.
Note that this hasn't shipped on stable yet, but is available on 1.17 beta.
The article mostly lists the various problems and associated optimizations. Concise & nice read.
Google long ago released Snappy Start, a tool for snapshotting processes, saving the full state to disk, so new instances can be launched faster. This is a more general Checkpoint-Restore capability than V8's impl and a bit different, but definitely somewhere in the same field of computer technology.
Seems also related to CRIU, which does something similar, but for the purposes of live migrating a process from one host to another. https://criu.org/Main_Page
Yeah I probably should have lead with CRIU. It's been a longstanding ongoing project of excellence. A lot of people who work or worked (unsure of breakdown) on OpenVZ have been cranking on this for many year.
Work from the CRIU crew started getting upstreamed almost exactly four years ago, breaking some initial resistance to the tech needed for CRIU- https://mobile.twitter.com/__criu__/status/58727373960931328... https://criu.org/History
It's interesting the breakdown in sell- CRIU is a swiss army knife of a tool, whereas Snappy Start and V8 Snapshots seem targetted and marketted largely towards fast "initialization" concerns.
Emacs does a similar thing for startup time with dumping:
The Emacs dumper dispute https://lwn.net/Articles/707615/
Funny how everything old is new again. Dumping an image, something seen with Emacs, and with SmallTalk and LISP languages since before Emacs was derided as "eight megs and constantly swapping" :)
Unfortunately Atom is not on par with VSCode considering responsiveness.
There are a few more issues, Emanuel Quimper summarized in: https://equimper.github.io/2017/02/25/why-i-moved-away-from-... explaining why he moved from Atom to VSCode in detail.
A month ago there was an interesting submission in favor of Sublime Text 3. Mainly because of its incredible responsiveness: https://news.ycombinator.com/item?id=13928752 by Tristan Hume, comparing Vim, Spacemacs, Atom and Sublime Text. I highly recommend it.
My workflow now looks like this: VSCode+Plugins replaces my zsh+tmux+vim toolchain when running on AC. On battery zsh+tmux+vim provide VSCode+Plugins functionality with less beautiful gfx but unmatchable battery lifetime.
The zsh+tmux+vim toolchain is heavily customized, though: https://github.com/rscircus/dotfiles
I love it when new problems can be solved in old ways. In physics we say there aren't 10,000 problems there are just 10,000 manifestations of 5. And it really seems like that's true here. Maybe we should stop laying off people for being old lol.
The industry is doing fine without the old workers with outdated skillsets. Correctness does not matter as much as velocity to release.
No, industry is pushing food around the plate, and has been for some time. It must have been amusing (to some) to see WebSockets arise, when TCP sockets do the same thing. Why is a new standard needed? Because firewalls block everything but port 80 and 443, and every other program that uses non-HTTP sockets has all-but-died off (with the exception of some games).
90% of the "innovation" in application programming is just an exercise in combinatorial virtualization.
(That said, it's not all bad. The browser has had a remarkable and wonderful effect on GUI application architecture that probably wouldn't have happened elsewhere.)
Interesting! Image-based development is actually really useful for many applications. It would be interesting to see V8 support this more generally. It's something I quite like about CL and Smalltalk systems.
From the article it sounds like they're basing these tests off probably their dev machines. Seems like they should be trying this out on slower machines.
It sounds to me like they are testing it on slower machines (specifically slower hard drives), as they specifically call out one of the "smaller" optimizations as having a significant impact on machines with slower hard drives.
It sounded to me like they were extrapolating though, "This resulted in a ~100ms improvement on a fast machine with an SSD but, since most of this work was I/O bound, we expect it to be even more noticeable on slower hardware." This in fact was where I drew the inspiration for my comment from.
From the article, they have the electron-link[1] module that anyone can use in a electron app to get the same functionality working. Not sure how it plays with webpcack.
Minifying the code can also speed up the startup time ... Another trick is to auto-start the app and bring it to the background (invisible). Then when the user "starts" it, just make it visible.
Your solution is a good one, but I get kind of sad when I remember the context : launching a text editor :/
I wish atom would just add preloading. I be happy to always have a hidden, sleeping window ready to pop to front on request. There must be some reason this is harder than I imagine...
You can basically do that now: just don't quit. If you start Atom and it discovers that it's already running, it tells the running process to handle the request. It even honors environment variables and flags like --dev.
For example, starting Atom cold on my medium-sized project (by running `atom .` in the base dir) takes 6 seconds. If I close all windows but leave Atom running, do something else for a while, and then run that command again, it takes 3 seconds.
(That's still a disturbingly long time... but it's quick enough once launched. I like Atom enough that I can live with it for now.)
Edit: just tried the beta. It's a little quicker: 4.5ish seconds and 2 seconds. Still OK for long-term coding but too slow to be $EDITOR for things like `git commit`.
You are right, it is things like 'git commit' where I'd like it to be faster -- and that's where an invisible window feels like the right option. Start opening another one whenever I start using the last hidden one.
This is really simple procedure that should take like a millisecond why does it take seconds?
I always hated this argument. It feels to me like someone is complaining why a train can't go from 0-60 in 10 seconds while many cars can. The answer is always "because that's not what it's designed to do".
Regardless of how you feel about it, the team behind Atom made a design decision to sacrifice performance to gain a large amount of other benefits ("easier" higher level language, easy cross platform support, extremely easy to write plugins for it from it's target "demographic", etc...).
Because of those architecture choices, things like spawning a new window aren't as easy and straightforward as they might be in another architecture.
So just because you want a method of transportation that goes from 0-60 in 10 seconds, doesn't mean that all methods of transportation need to go from 0-60 in 10 seconds. And just because a method of transportation can't go from 0-60 in 10 seconds doesn't mean the designers were lazy or cut corners, it just means that they prioritised other things, and are solving different problems.
Oh man, I wish I could use snapshots in the browser. In some extreme cases, I'm dealing with multi-minute startup times.
I think v8 does cache machine code in some cases. There are a couple of flags in chrome://flags you'll want to look at:
V8 Caching Mode, V8 caching strategy for CacheStorage
https://v8project.blogspot.ca/2015/07/code-caching.html
Edit: Not the same as snapshots mentioned in the article
What kind of application are you building?
Electronics design software. :)
Most of the time is spent doing fine collisions with shapes coming out of an R-tree to build up a connection graph.
For the vast majority of designs, it's fast. For very dense, imported designs, it can get slow. (No two tools keep data in the same form, so translating leads to inefficiencies.)
I recently evaluated all online EDAs that I could find. Some of them where quite slow because they used SVG for rendering. I would love to see your tool, too. Unfortunately, I couldn't find it in your profile. Do you have a link?
We use canvas, which saves us from the SVG DOM, but it also means managing the scene ourselves. If I ever get some time, I'd like to experiment with a WebGL renderer...
Do you have any blog posts or similar about how you're managing the scene graph? I've been thinking a lot about building a scene graph lately, and coordinate -> component mapping seems expensive in time and/or memory depending on how you do it.
That sounds less like startup inefficiency and more like the application doing actual work on startup. Have you tried caching it?
Isn't that what these V8 snapshots are?
> V8 snapshots allow Electron applications to execute some arbitrary JavaScript code and output a binary file containing a serialized heap with all the data that is left in memory after running a GC at the end of the provided script.
I started this issue a long time ago, and it's been frozen since: https://github.com/electron/electron/issues/3041
Maybe now we can have actual source code protection?
Why do you consider it valuable to give people an application and make it harder to debug when it crashes or misbehaves?
Because the end user shouldn't have any debug access, only the developer. Errors should be handled in application. In worst case (total exit of process from an error) Most people don't have error handling anyway. (And I don't want the only tool required to evade the license check to be notepad + asar)
if you want to protect your source code, don't use Javascript.
>don't distribute your programs
That's what it really comes down to. From what I can see, it's mostly an emotional response. I'd be surprised if code/binary obfuscation is a net win in general.
I've had to disabuse developers of this idea. One distributed binaries that weren't quite valid but ran on the CLR, though not Mono. A 10 line script was enough to remove the invalid sequences. What did the developer gain in this case? An extra build step, undoubtedly more than one bug, and in the end, no "protection".
I agree with the idea that anything can be reverse engineered. However electron by default has plain text javascript code. I'd like to prevent people from editing plain text (!!!) to evade my licensing check!
For what it's worth I agree with the Electron dev's decision to close the ticket. They don't seem to have the same use case as you and are under no obligation to support it.
There's also the unstated issue of ongoing support for the feature. If they put in code obfuscation they'll be obligated to make sure that it provides adequate protections to avoid a deluge of "someone hacked my obfuscated code" type tickets. What constitutes "adequate protections" will have to be updated over time as more advanced techniques are discovered for reversing out the code.
Combined with the performance drops that were clearly outlined by the Electron devs it would seem like a code obfuscation feature could be a really big waste of time.
Perhaps try hosting a page with a crack or serial for your product and see if there's significant usage in the first place? My guess is people are more worried about this than it warrants. A user of professional tools opting to edit the source code of a tool every time it updates seems like they might not be a paying customer in the first place.
I guess "source code protection" is for distributing plugins for Atom without distributing the source so the code isn't accessible. So I would call this "source code concealing". In any event, this could be done with WASM.
I actually needed this with it's framework electron. Unfortunately I haven't yet found a method of compiling coffeescript (or javascript) with WASM.
I'm just asking for concealing against my licensing code from being in a text file.
I like javascript. It makes development faster. I'd like to prevent people from editing plain text (!!!) to evade my licensing check!
Is compiling to WebAssembly an option to you?
Better than relying on memory snapshots.
I haven't heard of a method of compiling Coffeescript or Javascript with WebAssembly? Have I missed something?
Really I just want my licensing code to not be in a text file so people can't just load up notepad to evade it.
just tried the beta its still pretty slow :(
About 10 seconds of startup opening a directory, from terminal to loaded workspace. I'm on a MacBook Pro (Retina, 13-inch, Early 2015). I have 76 community plugins installed.
76? Daaam. I thought I was overdoing it at 53. (If anyone wants to check:
Have you checked Timecop? (cmd-shift-p, "timecop") Might be a few you can do without.ls ~/.atom/packages | wc -l # minus 1 for the READMEI have too many. But it works well for me. I've worked on too many languages with the same editor, so I've got... Front and back-end JS tools (linting, tern autocompletion, builds); clojure with a repl and parinfer, paredit; some rust and elm plugins that can probably go since I just experimented with those mainly. Linter for terraform. I also use atom for general note taking, so I've got a couple plugins for that.
And here I was thinking I needed to start slimming down at 23.
`apm list --installed --bare` is also a good one-liner.
Or you can not have a text editor in a browser. :)
Cool article regardless
Must every thread about VSCode and Atom start the same way? It's a trade off: performance for a cross platform JavaScript app development. If that is a tradeoff you don't have to make, don't do it. Atom and VSCode have made that tradeoff. I don't know what rehashing this can possibly accomplish.
>Must every thread about VSCode and Atom start the same way
If many people believe this is the case, why not? All articles get some common types of responses based on the topic, this is just one topic/response combo that you happen to disagree with.
>It's a trade off: performance for a cross platform JavaScript app development.
It's an unnecessary tradeoff.
If a single developer can create ST from scratch for Windows, OS X and Linux, then surely GitHub or Microsoft (for VSCode) can create a cross platform native set of UI components in C or C++, wrap them, and have the rest of the development (plugins etc) happen in JS (to keep the familiar language, easy access to npm modules, etc).
> If a single developer can create ST from scratch for Windows, OS X and Linux,
One of the reasons why some people are switching from ST to Atom/VSCode is the former's tortured development schedule, which has seen months or years go by without an update. Contrast VSC, which reliably delivers a heap of improvements every month. JavaScript is probably responsible for a big portion of this. Again, it's a tradeoff.
> then surely GitHub or Microsoft (for VSCode) can create a cross platform native set of UI components in C or C++,
Maybe they can. Or maybe they can't, and if they tried then they'd have the same slow pace as ST. You don't know.
VS Code's release record is impressive. And didn't it grow out of the Monaco browser-based editor? Microsoft probably wouldn't have funded the hypothetical C++ version.
That said, one of the Atom developers says using web technologies made development harder in many ways.[1] Very few solo developers can match a team with Microsoft's resources, and a monthly release schedule is more about discipline than anything else.
>Contrast VSC, which reliably delivers a heap of improvements every month. JavaScript is probably responsible for a big portion of this.
I am pretty sure the project being open source and in the hand of a team in a big company instead of an independent developer has more to do with it.
> If many people believe this is the case, why not? All articles get some common types of responses based on the topic, this is just one topic/response combo that you happen to disagree with.
Because such comments tend to be repeats, making them not interesting. They also tend to derail interesting discussion. When there's an article on an interesting detail about X, but the top comment litigates why X should even exist, the interesting part of the article never gets discussed. And when that happens on all threads that involve any aspect of X, it's boring.
If this was truly that simple, don't you think someone would have already done it? Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?
>If this was truly that simple, don't you think someone would have already done it?
Someone already has done it. An one-man-shop built Sublime Text by himself.
Surely it's not having JS as an extension language as opposed to Python (the only difference between ST and what I propose) that's making it difficult.
>Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?
There's a "cross platform, development-focused text editor with native UI component" that's working great.
Whether there's an open source editor like that is orthogonal, since what I'm discussing is whether is technically feasible to create such a browser -- and the existence of ST proves that it is (and that's by a single developer: with resources such as that GitHub or even better MS, have, it would be much easier).
The choice of license is just a decision after that.
I think the developer behind Sublime Text is widely recognised as an outlier.
>> "Sublime Text 2 is mostly coded in C++ and uses a custom UI toolkit." ... [0]
How many other devs/teams are going to reasonably take that on.
(And how do you think the debugging story of his custom framework compares to Chrome Devtools).
> How many other devs/teams are going to reasonably take that on?
This strikes me as a sort of devolving-human standpoint that might lead to someone in 2050 asking how anybody could possibly walk 10 miles unassisted.
In the past, small teams of talented developers have written an entire game + game engine + associated tools from scratch, countless times.
Doing in-depth custom UI development for the desktop as part of creating a text editor does not bin as 'Mountain-moving; Don't even try' difficulty.
I don't think anyone is arguing that it's technically impossible to create anything. I was just pointing out that the tradeoffs that Atom accepted aren't simply trivial to solve. Jon has put an amazing amount of work into Sublime Text to get it where it is today; it's not some simple thing to build a great, native text editor. However, it's not like Sublime Text isn't without its own tradeoffs.
How long did it take to build Sublime Text vs. Electron + Atom? Are the original developers in Atom experienced in C++? How easy is it for 3rd party developers to contribute extensions to each? How do the extension catalogs compare, in size?
Qt Creator? Although at this point its UI is a mixture of wrapped native widgets and non-native QML widgets.
I wouldn't really call Qt Creator a text editor though.
IntelliJ does a good job of it without resorting to Electron.
No, it just resorts to the freaking JVM, which is not any more lightweight or native than Electron apps.
I don't think that's true. The JVM is far closer to native code than Javascript, both technically and in terms of actual performance. Here's some synthetic number crunching benchmarks: https://benchmarksgame.alioth.debian.org/u64q/javascript.htm...
Even on the I/O heavy workloads that Node/V8 should be able to handle best, Java is ahead: https://www.techempower.com/benchmarks/
And yes, there are many Java apps that like to eat memory but I don't believe it's as bad or worse than V8/Electron and I don't believe Java is as inherently memory hungry as V8/Electron.
The JVM is a virtual machine, just like V8, and neither is particularly "native." Java is an easier-to-optimize language than JavaScript, mainly because static types give better information to the compiler and prevent certain kinds of hard-to-optimize behavior from being written in the first place.
That being said, as someone who's used both Atom and IntelliJ a fair amount (although my daily driver is Vim), you can definitely see the downsides of using the JVM vs V8 in terms of startup cost. People complain about Atom being slow to start, but IntelliJ is so, so much worse — elsewhere in this thread dstaley mentioned it being almost 4x worse on a test file, and in large projects I've seen IntelliJ take literally minutes to begin being usable. The JVM is optimized for long-running server processes that can afford time to boot and warm up; the V8 team spends inordinate amounts of time ensuring that JS can begin executing quickly, even sometimes at the cost of peak performance. And RAM usage in IntelliJ isn't pretty either.
I don't think using the JVM instead of Electron buys much (if anything) in terms of editor performance compared to writing in native languages, like Rust or C++, and using native GUI toolkits instead of Swing/JavaFX or the DOM.
I don't think IntelliJ vs. Atom is a good comparison for Electron vs. JVM. IntelliJ is doing a lot of things Atom doesn't do, like loading/building an index of all of your code and dependencies in order to auto-complete and show docs on demand.
IntelliJ doesn't use native UI components though. Furthermore, Atom can open a single file in 3s, whereas opening the same file in IntelliJ takes 11s (these numbers are from cold starts). This is with clean installs of both IDEs on a 2016 MacBook Pro.
Using web technology was less about making development easier on us, because in many ways it made it harder. Web technology is about enabling extension authors to use a powerful and familiar technology to achieve their goals.
Could you give some examples of extensions that benefit from Atom being built on Electron instead of just embedding a JavaScript or Python interpreter?
Most of them!
The minimap extension is made easy because they can just throw some HTML in a side pane, the image preview plugin just leverages the image displaying abilities of the browser, custom styling is as easy as throwing some CSS in a file, the extensions which let you preview the web page you are working on right in the browser use the full extent of the browser, the plugin that lets you easily preview markdown just uses a simple markdown->html converter then just displays the HTML/css. Themes are just a set of CSS which targets certain classes. Plugins can move, change, hide, show, do anything.
It also let's plugin authors do things the original developers never imagined possible. 3D object preview using webgl in a custom pane, replacing the whole implementation of tabs with something else, completely redesigning how the sidebar works and looks because it's all just HTML.
And while none of that can ONLY be done in a browser, the fact that a browser is the UI means that it's much easier, much quicker, and much more maintainable.
An embedded scripting language is only part of the story. Think about all of the APIs the browser exposes. For starters there's the DOM... there's no UI toolkit more that's more universally understood. Then there's CSS. Look how many Atom themes there are out there because people can tweak styling with a system they already understand. Then there's the long list of other standardized APIs. WebRTC, fetch, WebGL. Chromium is a very full-featured cross-platform environment that offers us more than embedding a scripting language would. I'm not denying it doesn't come with some negative trade-offs, but I do think those will diminish as Chrome improves and we improve our usage of Chrome... we're also dropping critical components to C++, which Electron makes it easy to do, so over time Atom will evolve into an increasingly "native" application with a cross-platform standards-based interface layer. The overhead of that layer will always be there though.
They could, but they chose not to. Maybe they know something about their organization that you don't. Either way, nothing is stopping anyone from writing a cross platform editor that you describe! If it's really so easy you should team up with all the people who show up to complain about electron in these threads. Until you or someone else makes an editor as good as Atom or VSCode I'll keep going to them as my first choice of text editor.
Aren't all tradeoffs unnecessary? I mean, it's part of the definition, right?
No they aren't, since when we talk about tradeoffs we are already assuming a specific desired outcome. The tradeoffs are necessary in order for us to achieve it.
But in order to achieve an outcome such as: "an editor that's cross platform and is programmable in JS", using Electron and/or the DOM is not a necessary tradeoff at all.
I feel silly asking but what is ST?
Edit: Sublime Text?
Yes.
It's a bit the same issue then something like rails. Easy in the short run, but when you starting doing advance optimization - likw those - you wonder why not rewrite in a more performance oriented language.
Because the whole point of the editor is the web stack.
The fact that it's built on web technologies, and web developers can make plugins easily and quickly and can hack on the core code is the entire reason for it's existence, and why it's so popular.
If you rewrite it in another stack, you basically just created an entirely new editor which isn't compatible in just about every way with atom.
Great comparison. In both cases choosing the language that helps you launch quickly is almost always the right decision. You can always scale later. Better to find out if your app is even going to be a success, first.
I don't really see what the benefit of JavaScript app development is. You don't need to use electron and JavaScript for portability, as far as I'm aware. For example, I know of Qt, and I'm sure there are other toolkits in other similarly mature platforms.
This seems destined to go the way of emacs. This is always what happens when an idealistic perspective wins out over a practical one in a development team.
I hope you're right that this goes the way of emacs. I've been productive in emacs for 30 years, but I'm growing impatient for emacs to get a real programming language with lexical scoping like they were talking about doing with Scheme 20 years ago. Despite its lack of macros, JavaScript is arguably a better Lisp than Emacs Lisp. I've toyed with Atom a couple of times recently and am seriously thinking of switching.
Emacs Lisp in GNU Emacs has now lexical scoping...
Oh cool how did I miss this? https://www.emacswiki.org/emacs/DynamicBindingVsLexicalBindi...
See, I just don't understand why you would want to use emacs over an editor that does all the work for you. Thats why I avoid it, it seems like a big cost that I don't have to pay if I just use a different editor.
How do you think an IDE "does all the work" for you? Somebody working on the editor wrote some code in C++ or Java or whatever that makes it do that, and that code is baked into the IDE.
In emacs, the only missing part is that perhaps nobody has already written the elisp that makes it do whatever task you are asking for.
emacs is a smallish program written mostly in C that defers to a scripting language for nearly everything, and it ships a bunch of code in that scripting language that does all the work of being an editor. You can look at that code using the editor itself, and you can change that code using the editor itself. It's insanely flexible and extensible; see e.g. advice [0], and most modules provide meaningful hooks for you to add your own code.
All the IDE/editor behavior is just code. If it's compiled and baked into your IDE, fixed, unchanging, then if there is any behavior you don't like, you better hope the dev included a knob that lets you tweak it, or you have a lot higher barrier to making your editor work the way you want it to.
[0] https://www.gnu.org/software/emacs/manual/html_node/elisp/Ad...
Thats exactly my point, theyve written all the various features you might have to write yourself, and theyve integrated them for you.
guess it's a tradeoff. if what you want is common enough, it's quite possible it'll already have been written. if not, you may have to write elisp yourself.
but, if what you're working on is not common, maybe there isn't a (good) IDE either.
Whether an editor needs to be programmable or not depends on what "all the work" is. If you're doing the same exact work as everybody else then certainly a programmable editor is overkill. If your work is different, then programming is how you tell the editor what it means to do all the work for you.
People seem to ridiculously inflate this cost. If you are going to be using a tool for 40 hours a week 50 weeks a year for the next decade then you will be using it for 20,000 hours over the next decade.
Spending a few hours to configure it to your liking. In fact if you start atom and wait 6 seconds for it to start just once a day then twice wait 3 seconds for a new window you will in the same time frame have waited 8 hours for atom to start.
Heres the thing, its a cost you pay for every single project you start and every change you make to your build system. Emacs makes it possible but hard to maneuver, by my reckoning.
There are some really giant projects where that becomes reasonable, but for me thats just not the case. And if I were going to invest time like that, I'd rather invest it into an environment which has a higher ceiling for what it can do (emacs doesnt provide fast/rich/easy autocomplete, for example)
> This seems destined to go the way of emacs.
Hilarious. Emacs is one of the most successful programs of all time in my book. If I ever made an editor I'd pray every night that it'd be at least half as successful as Emacs.
It's a benefit if your engineers already know JavaScript, obviously.
Also, emacs is one of the most successful text editors so I'm not sure I get your comparison.
I don't consider emacs successful. Succesful among fanatics, maybe, but I don't consider is valuable to a serious programmer.
Also, surely it's not that hard to switch languages? In my experience all languages are essentially the same.
>In my experience all languages are essentially the same.
That's the problem: you don't seem to have enough experience.
I dont seem to have much experience? Based on what? For having a different view than you? Isnt that a little naive?
So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week.
How much experience do you think I have? I've used plenty of languages, and I'm well aware that there are nuances.
>So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week.
That's because you either used the languages superficially, or use only very similar languages, probably of the Algol family (e.g. Ruby, Python, PHP, JS, etc).
You won't get very far with Haskell "over the course of a week". Or APL. Or Idris. Or Erlang. Or Lisp -- or any other language that's not a mere Algol derivative with some different bells and whistles. And even those have their idioms, of course, that one needs much more than a week to get competent with, but, it gets worse when we expand languages to not be "mainstream Algol derivatives". One would only be using languages like Smalltalk, OcamL, Scheme, Scala, Self, etc, superficially without getting into their idioms and nuance, which wont happen in a week (and can take years to really master).
Well of course you can't include languages like Haskell in the group of interchangeable languages. Incidentally I have used Haskell (and it did take more than a week). But it doesn't matter because we're talking about moving JavaScript developers to Java, or C++, or as you say, Algol-likes.
>Well of course you can't include languages like Haskell in the group of interchangeable languages.
Well, if you can only include "interchangeable languages" then it's not an observation but a tautology.
No kidding? What I was trying to say (I thought I was pretty clear) is that we're really only considering institutional languages here. As it turns out to my knowledge theyre basically all the same.
> I dont seem to have much experience? Based on what?
Based on the fact that you think all programming languages are essentially the same. That's just a ridiculous claim and it immediately exposes you as someone who's only used a couple of Algol derivatives.
2 things
1. I don't think literally all programming languages are the same
2. I have used Haskell, and am very aware of every language listed in the other replies to this comment, so you're completely wrong.
I kind of thought this community was better than this, to be honest.
This community is in fact pretty good you posted something wholly and totally ridiculous and the worst thing anyone has said is that you need to get out there and get more experience.
Try saying silly things on reddit and watch the hate flow in.
Well sure we beat reddit I guess, and maybe I just don't post here enough, but I feel like the community is deteriorating. I used to hold this place to higher standards. Also I still don't think what I said was ridiculous, and its something I basically believe.
Well, it might not be ridiculous IF qualified.
E.g. "most of algol-derived languages are quite similar, aside from small differences in syntax and feature set".
Or:
"Most modern mainstream languages, etc have pretty much similar feature sets and syntax (while still differing in being dynamic vs statically typed etc)"
That's not the same as what you said.
i suppose youre right
Not useful to serious programmers? Do you feel the same way about Vim? Just because you haven't gotten used to using something, doesn't mean it's necessarily total shit. There is a reason why people have been using emacs for decades.
I do actually, and I should reword that to "not useful for serious programming." VIM to me is best used for lightweight, quick and short editing tasks. THats how I use it. For any involved work, you're going to want a debugger, you're going to want automated build tools, you're going to want effortless compile/run cycles and so on..
You don't really want to implement all of that in VIM because your work won't be portable.
I have all those. They're just not integrated into my editor. I use vim; it is my editor, but not my development environment. Unix is my development environment.
I;ve tried that approach, and its cumbersome to remember all the different commands, flags, combinations etc. I might need for each different project and for each different task. IDEs simplify this process dramatically. Its akin to GUI v DOS in terms of usability benefits.
That's fine. But myself and a lot of other people get a lot of "serious programming" done using the approach.
I don't really understand what the benefit of it is.
For me, using vim+vimium for Chrome means that majority of the time my hands are on the keyboard. I barely ever use the mouse.
Have you seen a really seasoned vim user work? Purely from an efficiency point of view, vim/modal text editing is simply better than traditional text editors.
Sounds to me like you aren't familiar with Vim and the ecosystem. Plug-ins are your friends. Use a package manager like Vundle to easily install plug-ins. Not sure why you say vim isn't portable. I have my vimrc file on my github. Not only is vim available on all major platforms, it comes pre-installed on a bunch of systems. All I need is my vimrc file, Vundle and an Internet connection to customize any vim install to exactly how I want it.
Do you really conflate suitable to your own tastes with being useful or not? Further in what profession is any tool "all the same" See the blub paradox.
I thought everybody moved over to Visual Studio Code by now.