I often have to fight with myself to pick the right tool for the job, not the tool that makes my job the most fun to do.
At least the Electrino idea is more reasonable. Using a framework already loaded into memory by the OS and sharing it would go a long way toward reducing the bloat...though not toward the horrible battery problems it introduces. Seriously, people are still brushing aside issues with something where a blinking cursor caused CPUs to crank up to the max...
So until someone can build a production ready, cross platform, JS desktop experience....Electron will live on.
That being said, using tech that makes you enjoy your job will help you be more productive and potentially attract enthusiastic developers.
I feel there's probably a balance (as in all things) between boring production/exciting development - but I don't feel I hear that discussed often enough.
Not sure what you would consider exciting or boring, but I thought it was decent advice.
Electron is popular because it lets you write desktop apps in JavaScript, and there are a lot of developers out there who know JavaScript. By going with Electron, those developers can build desktop apps without having to learn anything new. They can extend their existing skills into a new arena, without having to learn any new ones. Developers are always asked to turn products around as fast as they possibly can (and, um, also people are lazy), so this is a very powerful appeal.
This "I don't have to learn anything new" factor is literally the only thing Electron has going for it. Using any other alternative will result in applications that perform better, fit into their host environments more naturally, and generally work better than an Electron app will. But there are a lot of JavaScript developers out there, and any other alternative would require all those folks to learn a whole bunch of new stuff to get started -- new languages (C/C++, C#, Java, Python, etc.), new toolkits (UWP/Win32/Cocoa/whatever, Qt, WxWidgets, etc.), new programming paradigms, etc. etc. etc. Whereas with Electron they can pick it up and be productive in a couple of hours, which is a hugely appealing prospect.
Tools that let people leverage what they already know will always do better than those that require a whole bunch of learning up-front to use. Electron is just the latest example.
Done right, they're faster, for sure. But when you use Electron you're leveraging thousands of man-years of Google developer effort to build a web browser that works consistently and well across different platforms. Although the web platform gets a bad rep for cross-browser compatibility problems and general weirdness, a huge amount of that goes away when you target a single runtime. Suddenly you can use every half-baked Chromium API and prefixed CSS feature without worrying about how it's going to break in IE 11.
In that situation, you suddenly realise just how much power the web platform give you. You can style any element, any way you want. You have you have a complete, out-of-the-box object model for your whole UI, plus developer tools to help you debug it. You have advanced typography control. You can drop a canvas element in and get an immediate-mode 2D or 3D graphics API. You can layout stuff in flexbox or grid, or just as a plain old document (which most toolkits would delegate to an embedded web browser anyway).
There are better languages that JS, that's true. But whether there are truly better cross-platform app toolkits than the web is, in my opinion, rather more unclear.
I started building an app in Rust against GTK with a Rust shim, but I only got so far before I had to start reading through GTK docs which meant understanding the C-derived documentation, on top of the Rust shim.
If the goal is to learn GTK, Rust, and C, then it's not a big deal. If the goal is to build something that you need, you end up scratching it and going back to something you know already.
(In my case? Java which has the underrated JavaFX 2.0. And I'm sure I'll look elsewhere some other time - I'd really like to learn Rust better, but I think I'll do something other than a desktop app, or at least wait for better documentation or more time.)
That said, Lazarus looks really cool as well and may be the thing I always hoped for...
Not completely, don't underestimate how hard it is to write a cross platform UI that runs on Windows, OSX and Linux.
Starting from a web framework not only gives you portability but also a common UI language(that may diverge a bit from native app conventions but that's a tradeoff you need to weigh).
I say this as a die-hard C++/native dev. I've done wxWidgets, QT and a bunch of others and it's never a trivial thing to do.
1. Pros/cons of using tools we already know 2. Pros/cons of using tools we enjoy using
I am awful at Docker because I started using it yesterday. But upon using it, I'm suddenly so attracted to it and am thinking about what fun personal projects I can apply it to. It's a beautiful technology.
I am very strong in JavaScript but love avoiding it like the plague unless it is the appropriate technology.
Edit: okay I'm skeptical of a part of your analysis. Please show me a detailed example of building a desktop app that runs on Mac/Windows/Linux, looks reasonable, and takes the same or less time from a competent developer. I am genuinely starving for an alternative to Electron that doesn't come with a significantly heavier dev/support cost.
Yes.
In "Code Complete", Steve McConnell argues that although a programmer can learn a language syntax in a couple weeks, mastering the language, tools and libraries that make up a platform can take a couple of years.
In other words, asking developers to build and maintain non-trivial products in a language that they don't already know is an even bigger burden than you might think, to the point that it's probably an unreasonable request.
Familiarity, knowledge transfer is a big drive for technology adoption. The bad bit is when the decision maker leaves the team and the rest are unfamiliar with the tech. I think this applies to Electron pretty well as web developers can now contribute.
The "it would look good on my CV". I'm thinking about Kubernetes where it doesn't make sense to use most of the time but everybody wants to be doing it because it's hot.
However this is a part of being professional, using the required tools for the job.
Programming really at some level is as much about translating human ideas into physical computations as anything. In this regard, it is a fundamentally psychological process, as much about the programmer as the computer. There's a sort of psychological-cognitive -> math -> physics process, and I often feel as if the emphasis is on the second two steps, and not so much on the first two.
There's good reasons for this, but it's resulted in a sort of blind spot that often comes out as people just preferring languages like python or javascript or whatever, and not wanting to acknowledge that those fuzzy, poorly understood preference processes are driving development as much as the choice of algorithm or hardware constraints.
I think it's poor ergonomics, really, and effects things as much as memory management models, etc.
We're at a stage, though, where languages like Nim, etc. offer some promise of ergonomics and performance, and I hope people will pay attention to it carefully, so we don't end up in the same situation as the one Atom exemplifies. I like Atom, and don't have any particular attachment to Nim, but do think there's something we shouldn't be ignoring anymore. Often when a language is difficult to intuit, the reaction is to shame the programmer, to characterize them as not smart enough to understand the language. Sometimes there's some truth to that, but sometimes I think it reflects deficits in the language, whose sole purpose, really, is to translate human thoughts into computational events.
One language that openly acknowledges it is designed first and foremost with psychological factors and ergonomics in mind is Ruby:
"For me the purpose of life is partly to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, So Ruby is designed to make programmers happy."
https://github.com/alexch/ruby_notes/blob/master/ruby-intro....
Who cares about start-up time? I only open the thing once/day. Same thing for large files: it's a edge case. Memory usage? Sure, but as developers we probably have GB and GB sitting there, if the thing worked it wouldn't be a big deal for the most important tool in your arsenal.
What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness.
What they'd need is a huge architectural overview, and the fact that they're showing off how much they're optimizing proves that they'll never be as performant (or even close) as they'd need to.
Also weird that they blame extensibility. Emacs does it, Firefox does it, Chrome does it, and most importantly VS Code does it. I'm sure it's not easy, but it's done by other projects.
Too bad, because the UI is very nice, package management is very good, as well as not having to edit JSON files for settings (which sure I can do, but I see no added value and I'm lazy).
GB and GB which I had hoped to use for running an entirely other operating system, and all of its apps, in a VM, not run a goddamned text editor.
And that’s what annoys me about the “so what?”s. Start up time? Even just an update that requires a restart will make me wonder “I’m in the middle of something, how badly do I want this?” Resource hungry? See above, I have those resources for other stuff, not your piggish version of Notepad. A lot of these things can be excused for an OS, a database, crypto currency worker, but NOT AN EDITOR.
But even if I were more tolerant, as you point out the general use case has been abysmal in my experience. If this kind of thing is what you want, I fail to see why one wouldn’t just use VS Code.
I'm just saying that the general use case sucks enough that I'd think you'd want to worry about that _first_, then perhaps think about startup time (maybe).
Github is cool, Microsoft isn't. /s
They specifically address those issues in the post:
> Text Rendering Rewrite - Atom renders text... we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible... The result is that when typing, typical DOM updates now take less than 5 milliseconds: well within the range required for smooth animation and low energy usage.
> Removing remaining synchronous IO: - Atom still uses synchronous IO (which blocks the UI thread) in some places... Much of the synchronous IO has been eliminated, but there are several Git-related code paths that we still have not updated, and which kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths and convert them all to use asynchronous IO.
Adding to the other comments about having better use for my memory than piles and piles of JavaScript bloat, how do you think GC performance is affected by the amount of memory it has to manage?
All the micro lags in rendering and input handling are affecting your performance consciously and subconsciously.
You know, the exact thing you complain about:
> What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness.
caching the contents of the disk, so that you get performance and improved battery life.
if you're using a modern OS, your RAM is never just "sitting there".
I care.
I live in three editors: Xcode for iOS/Mac/Swift on server development, VS Code for Rust, Go and Python, and Sublime for a thing that starts up fast, opens new windows fast and can deal with huge amounts of text. I wouldn't mind reducing that number to two, but it doesn't seem likely to happen anytime soon.
Even if it runs well on the users' machines, how many resource-heavy applications can they run concurrently? Will they have to close one to open another?
Mh? This is a tool for developers. I don't get your point. My mom isn't going to use Atom for her shopping list :-)
People tend to ignore the base cause/assumption and hone in only on the problems that stem from those base causes/assumptions. Sometimes that's unavoidable, but often it's at the very least a good thought experiment to back up even further along the decision chain and challenge the original ideas instead. "Think outside the problems" or something I guess. It's really just making sure that you're being as methodical/objective as possible.
Atom seems to have been built with a set of initial goals/assumptions that triggered a massive chain reaction of problems to solve. Rather than challenging those original goals/assumptions, a lot of engineering talent and time is being invested in essentially cleaning up these problems that were self-imposed.
I'm guessing the OP is hinting about moving off Electron?
Atom clearly offered something that struck a chord when it initially appeared. I remember having an idea, and implementing it as a plugin, all within a lazy Sunday afternoon. This allowed the ecosystem to flourish, and new ideas being extremely easy to at least prototype.
It also allowed unprecedented[0] access to almost everything.
The latter turned out to be somewhat of a curse, unfortunately. Because the wide-ranging access allowed extension authors, and their users, to shoot themselves in the foot: It often lead to performance degradation, instability, murky UIs etc. Such troubles would usually be attributed to Atom itself. This was the groundwork for the narrative to almost instantly flip when VSCode appeared.
VSCode itself took the lessons from Atom, which must make it even more painful to now see it glorified vis-a-vis Atom: Extensions have to work through tightly defined protocols, and are never run on the main threat. This works well to avoid performance issues and to keep the UI from disintegrating. But it is also a severe limitation on the freedom to experiment, which is why that extension I once tried my hand on could not possibly be build in VSCode (it renders block comments written in Markdown as HTML right in the source code, including images, diagrams, links etc.)
[0]: Yeah, I'm sure there's some other editor that did it before. But somehow Atom got it right with Javascript as the language, and maybe the UI and documentation steering people to actually try it.
I agree, and i want to like atom. I love the motivation and i love how they have moved the "friendlier than VIM but not quite an IDE" market forward, because that's exactly the sort of editor I want.
but ultimately i'm trying to do a job, and that job is a lot easier when i'm not waiting for a text editor to catch up to my keystrokes. Even if it is some plugin's fault and not actually Atom's fault that the editor is slow, I don't have time to troubleshoot that when other editors don't let plugins screw up the editor.
Specifically, what I'm looking for in an editor is the ability to introspect most/all of the editor's internals from the editor itself (including documentation, debugging, live modification of the editor, etc.). In Emacs, all of that is just a few keystrokes away. Atom is somewhat introspectable in that I can pop open a Chrome dev console and poke around at the DOM and the JS files, but it isn't at all as straightforward as in Emacs (e.g. given some keystroke or some function in Emacs, it's extremely trivial to jump to the source code and start modifying/debugging it). Given that these activities aren't clearly documented in Atom documentation, I can only assume that they aren't priorities for Atom and that, in fact, Atom isn't designed to be "hackable" in the sense that Emacs is "hackable".
Which is really disappointing, because a truly "hackable" editor a la Emacs, built on a web stack like Electron, would make me giddy with excitement.
Why? I would much rather a truely "hackable" editor a la emacs, built on a native stack. Like emacs. (And I say this as a vim user).
Although it is ugly, and the documentation is poor, and web site looks like it's from the 90's, and the project lead is a bit eccentric, you may want to consider the Leo editor:
It's written in Python, and pretty much gives you access to most/all its internals. Unfortunately, the state of the documentation is pretty poor which is why I never had the time to spend mastering it. But I've followed it enough, and it really is a very powerful editor. I think only Emacs surpasses it in self-scriptability. A lot of non-programmers have used it to do pretty interesting things (helps that Python is "easier" for them than Lisp).
Because emacs in most implementations is not project aware the same way an IDE is (like the ways eclipse preprocesses the project and holds a coherent data model in memory while you edit) it just doesn't have the tools available to even build off of. It was only post-LLVM that tools for that kind of formatting and editing are expected to be coming from the compiler's AST itself (things such as https://langserver.org/ is pretty exciting). I think Go has some of the best source code at command line tools, but they are leveraging that there is a 'one true way' of go tools to work that is easy enough to deal with so a simple command can do just enough work to do what needs to be done as opposed to a C/C++ application that is a #define soup with custom build infrastructure that emacs has no way of getting a coherent model out of to decide whether it can refactor things or not.
I keep trying to make emacs work for it, but it turns into a lot of custom tooling that I really don't have time to build for the kinds of applications I end up having to work with. Emacs is still superior for actually reading and writing large bodies of code, just it is awful on operating on the code at a syntax-aware level and doing the same quality of IDE-grade checks to make it a mechanical thing as opposed to a brain-driven thing.
There are nice possibilities for this project, it could be abstracted out to work with FreeBSD and stuff. Grunt/gulp/etc. watch features may be able to utilize it in library form.
For a similar project, check out entr(1): http://entrproject.org/
I'm a full time VIM user, but I'm happy and glad anytime I see VSCode/Atom/etc win. I see it as a great editor for the sake of having one to recommend. Cross-platform, free, active plugin ecosystems.
It’s a cross platform file monitoring daemon with a json (and bser) querying API, with support for opaque cursors so you can poll for changes since the last time you checked.
For such quick jobs, launching the editor should be instantaneous. And I don't want to use another editor for them, I like the key bindings of my main editor.
This is true with something like Vi but with a separate GUI app, wouldn't the most common case be setting EDITOR={atom,code,etc.} and it simply opening a new window in the already-running app?
(Or, for that matter, don't most people using something IDE-like use the built-in UI to make a commit?)
Ok, well if I was developing a programmer's text editor I'd consider you a marginal user and design for the use case of the editor staying open 24/7. Startup time seems pretty low on the priority list.
Personally I'm taking a pause off Atom (after 3 years professional usage) until it definitely improves.
Best wishes!
(Not to say you’re wrong to expect it—just for context.)
Yet Microsoft's VSCode, which is also Electron based, is much faster than Atom. Electron obviously slows it down, but Atom's refusal to admit their performance issues for so long are also to blame
"Atom isn’t designed to be a tiny native-code editor. If the ultimate in speed is what you’re after, Atom probably isn’t what you’re looking for at least for now … and possibly not ever depending on what you’re expecting."
I tried Atom as an alternative to Eclipse, about 3 months back, as I consider Eclipse to be pretty bloated and slow, but Atom made Eclipse look like a speed demon. I tried running with --safe, removing plugins, but nothing seemed to help, it was still painfully slow. Perhaps it's my machine or some other local issue, but I run Eclipse with lots of plugins and it runs great, in comparison.
After reading the above in the FAQ and many many posts about how Atom was running slow and the responses those issues received, it seemed to me like they actually do admit there are performance problems but have the attitude of "That's just how it works, if you don't like it use something else"
I think the real problem Electron apps face is that rendering everything on the DOM is really expensive. I still remember the VS Code bug that caused a huge battery consumption because the gif they used to display the blinking cursor was in a high resolution.
Emacs was critisized, heck even banned from uni labs back in the day, because it used too much RAM. Now the time has come for us to mock Electron based editors :).
I wouldn't recommend switching away from Visual Studio to vscode, for .NET work, but for a new language/project, it's a great choice.
So now I started editing an asciidoc file in vscode on windows, since it's a productive text editor, but the back, forward, previous, next, kill, killall key bindings are all Windows-like and not Emacs/Unix like. Fortunately, it's was easy to add the six bindings in their fancy settings cascade text editor.
https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...
how? it's slow to start, sure, but once it's started it's not noticeably slow.
Seriously as a ruby hipster I know all the love our community has in hating enterprise IDE's, then I grew up and realized they give you out of the box amazing functionality (like dynamic runtime variable value inspection and automatic app-wide class name refactoring) that makes manual refactors look like amateur hour.
These features are so powerful that I implore any Ruby dev using Atom or Sublime to at least give RubyMine a look if they don't want to give VisualStudio a look. You will be a stronger and faster programmer having them in your toolkit. Especially, and I repeat ESPECIALLY, for refactors of class names.
The guy is amazing.
If your JavaScript is only going to execute in 1 version of the V8 engine forever why use JQuery?
Serious question. I’m not a huge JS Develoler but when I dabbled I was told JQuery was there to soften the differences between browsers.
1. For example, how many projects could basically use this for a significant fraction of their jQuery calls:
let $$ = (selector, scope = document) => {
return Array.from(scope.querySelectorAll(selector));
};
I want to like Atom so badly. I really buy into the features it offers over my beloved Sublime Text (3). I want the connectivity to the greater community, the ease of styling, and the ease of extension. I want everything Atom claims to offer!
In my last year of switching from Sublime Text 2/3, I have pretty much just gained one thing: cooler language syntax styles. I havent actually taken advantage of all of the ideas behind atom - I guess, when it comes to the grind, Im not interested in them enough to actually take advantage. When it comes to how I use my code editor, I seemed to have focused only on my career's needs, and not the joy of customizing, extending, and contributing back (to the code editor's community, that is).
What is important to me is productivity. In my year of using Atom, I lost a lot of productivity. First I lost lots of productivity configuring Atom to be in a similar state to how I use Sublime Text 3. That wasnt hard, Atom is just different, so there was some learning that distracted me when I wanted to focus on work. Thats cool, I can accept that for any "next big new thing." Then I lost a lot of productivity due to things related to package-management systems, configuration issues, and I had to wipe and reinstall a few times as it was easier to get back to work than to figure out what tidbit of an advanced feature I was misunderstanding. Then I lost a lot more productivity after package updates broke other packages (mostly language syntax stuff, but enough to be a big distraction when coding). It felt like getting into ES6 JS for the first time after only using jQuery - except in Atom's case, it was a tool getting in the way of me working.
I also really loathe all of the git-integration features, though they sounded great at first. I am constantly having to git reset and git checkout <filename> etc because I diddnt realize I had the @#$%ing sidebar in focus instead of the text area for the zillionth time. I diddnt realize when I was trying to select and delete text with a keystroke, that I deleted files from the sidebar view yet again. So on and so forth - its given me a major fear of using the software as misclicks and such lead to pain that I have to undo via my terminal. Dont get me started on how bad its auto indent or copy paste intelligence is... and again, zero of these issues with ST3.
Atom might be "free," in theory, but it cost me many hundreds (possibly low 4-figure number) of dollars worth of billable hours in my 2017 fiscal year.
Ive probably lost a cumulative total of 4-5 billable hours to Sublime Text in my whole life, and that was usually to Sublime's wonky updating patterns.
Id really like to like Atom, but Im "thiiiiiiiiiiiiiis close" to deleting it off my work machines and going back to Sublime Text 3. It has taught me that productivity it way more important to me than modern web-enabled features.
Here is to hoping 2018 is a better year for the Atom IDE, as my relationship with it has about 1-more incident worth of tolerance left.
> Ive probably lost a cumulative total of 4-5 billable hours to Sublime Text in my whole life
It sounds like you haven't spent any time customizing Sublime? If so, then why did you need to spend so much time customizing Atom? They have a very similar out-of-the-box user experience (except for speed of course).
I'm interested to hear what needed changing.
I along with many of my fellow engineers use Atom everyday and love it. Sure it has some shortcomings but if anything this retrospective from the Atom team shows that they're trying to address those shortcomings at a rapid clip.
I love that it's an entirely open source system and that it is written in the accessible Javascript language so that anyone can contribute. I love that I feel like I can change any aspect of the editor fully, without limitations imposed by some vendor.
Atom, like any editor, is not for everybody. I don't care much for Sublime but it certainly has its strengths- I don't pounce on HN posts about Sublime spouting negativity because it's not my preferred editor.
Please, fellow engineers, before you post something negative think about a project you've worked on that you were most passionate about and cared most about and then remember that projects like Atom do require passionate developers and those developers likely deserve a bit more than snark or non-constructive negativity.
Thank you Atom contributors! I think the idea and ongoing evolution of Atom is a special project and I hope to one day make some contribution of my own, in some form, to the core or plugins!
And don't tell me no editors are really worse than any other editors. That's crap.
Why would you build a text editor on top of a web browser engine? Who would think that is a good idea?. Of course it is not going to be performant, it is being used for something it was not designed for. On top of that, cross-platform apps built using the one stack are horrible. They never feel exactly like native apps.
If this was 20 years ago, atom would be built with java using swing. It would be just as slow and just as un-native. Java apps on the desktop are ridiculed for a reason. The only difference is that now they are using 'trendy' things.
I think blind Freddy could tell you that, yes you can build a text editor on top of a web browser, but performance, and usability will suck. That is why everyone is so cynical, because it is so obvious.
And regarding Java application speed, IntelliJ is pretty much comparable with the "native" Visual Studio.
About the looks, I'm using right now Vim (GTK), Skype (I don't even know what toolkit it's using, but I'm pretty sure it's not native), Eclipse (SWT - sort of native), Pidgin (GTK), Firefox (XUL? I'm not 100% sure after 57), Chrome (Skia?), etc.
Users don't really care as long as the applications are useful and developed properly. I've used many crap and butt-ugly "native" apps...
I don't even use Atom, but this vitriol annoys me.
Please consider going back to the parent post and contrasting that with your way out of bounds response that ends with "everyone is so cynical, because it is so obvious" in light of the fact that all the outcomes you assume are just not right.
https://insights.stackoverflow.com/survey/2017#technology-mo...
They did, and the result wasn't that bad: http://www.jedit.org/
My experience is that Engineers are just snarky and cynical. Especially about text editors. Frankly, HN is a lot more constructive than Slashdot or Reddit was back in the day.
However I held onto Textmate until 2010 and Sublime wore me down, so I'm a laggard as well.
So no negativity from me, because I just want a great editor that I can control and hack on. But I'll be real, I don't see it happening for a little bit. If sublime were to support JS plugins, I fear Atom might be in trouble at that point, TBH.
I dev on Ruby and I am a hardcore Sublime user, which is about as far away from Microsoft-friendly as you can get, and I have been really impressed by it.
Their app store is advanced, and crucially they allow Visual Studio to be setup with key bindings that match Sublime's, meaning switching over is really easy with almost little to no need to learn new macros. IDE's like Visual Studio can allow you to do code and class refactorings that make Sublime look like a joke.
BUT NOW.. for anyone else like me-- it looks like, from my quick glance, there's not much CoffeeScript left in the repo. So maybe it's time to give it a chance again.
You know JavaScript, yet CoffeeScript is inaccessible? WTF. I had never written a line of Lisp in my life before using Emacs, but that didn't stop me from writing hundreds of lines of Emacs Lisp during the first weekend that I used Emacs.
What's up with the unwillingness (or inability?) that many web developers seem to have for using more than one or two programming languages?
The kind of debugging and refactorings you can do in that kind of set up are mindblowing, and it took me years of doing it the old vim/sublime/atom way before realizing this.
Perhaps there's lots of cynics hunched over their keyboard hitting refresh on HN so they can jump in. Who knows?
The moderators have almost certainly played a part. Selectively permitting snark from the in-group is easy in the short run, but eventually incurs a cost to the community.
Apple products are bad now despite having a pretty similar rate of technical glitches they always did
It’s just the changes impact the HN crowd more now so complaining em masse is allowed
It’s meme-tribalism
No one wants to be the one to have to give up on their meme
Anyone that knows JavaScript.
And yet Emacs is fast, hmmm.
https://benmccormick.org/2016/01/11/the-most-interesting-ato...
It is probably mentioned in every editor thread, but org-mode is enough magic with an editor to mystify most developers. Syntax highlighting for multiple languages in a single file is already stretching most boundaries.
Emacs does an “unexec” operation to save its entire memory map to disk so its startup looks faster.
But many people still run Emacs in a daemon. This preserves your sessions between “running the editor” and prevents ever having to restart.
The changes Atom is looking at regarding user-side snapshots seems conceptually similar.
I'm writing this because I think many people are unaware of this feature of Emacs and might gloss over it in your post.
As far as I'm concerned startup time is next to irrelevant in Emacs, since you can start an Emacs server once when you boot up and then just run clients that open and connect instantaneously. That is, you can then run 'emacsclient' from the command line in any terminal you want, and it will open a working Emacs instance in a few milliseconds.
Here's blog post that describes this feature:
https://brainlessdeveloper.com/2017/12/27/making-emacs-work-...
The blog post above actually overstates how difficult it is to start working with Emacs in this way. It's dead easy.
Their problem is not technical, it’s ideological
Write slow javascript, get slow programs. It's not a crazy concept.
Edit: typo