HN Explorer

Ask HN: Why was Atom (text editor) written in JavaScript?

4 points by whizzkid ↗ HN
As a programmer, before starting a project, the first thing I consider is which tool is the best fit for the job.

If it requires a lot of concurrency, or if the time is limited, or if needs to be used on different kinds of environments. Depending on those, I pick my toolset.

Atom, on the other side is actually confuses me these days, since it is a text editor to deal with thousands of lines constantly, and requires to provide both fluent experience to user and to be fast.

I am using Sublime Text and really happy to pay for the licence. Because in return I am getting a wonderful experience.

I really wanted to love Atom because it was open source, but the experience so far was unfortunately not good at all for me.

What was the reason for Atom developers to go with web based technologies while we know that performance is not yet great with them?

Is it that Javascript has really promising roadmap for upcoming years or was it something else?

6 comments

[ 3.1 ms ] story [ 17.3 ms ] thread
api
I can't speak for the Atom devs, but JS-based apps that use a browser rendering engine to do UI (node-webkit and similar) are currently the least ugly way to do cross-platform desktop UI development.

Qt is a close second, but it's slower and more bloated and in many ways just as ugly.

Turing_Machine
It's probably a lot easier to find JS developers than Qt developers, too. Ugly or not, there are a lot of people who know JS.

Then there's skill transferability. GitHub no doubt already had a bunch of JS developers already in-house. Those devs can (at least in theory) move back and forth between Atom and other GitHub projects. That's not likely the case for Qt. They would have had to hire or train dedicated Qt developers, and what else could they have done with them?

Maybe they could have put them to work on a GUI-based git front-end, but that's about the only other thing I can think of.

api
Yep. The awesome power of installed user base.
auganov
Being web-tech based was/is basically the core feature and motivation of building Atom I believe. So I don't think they could have picked anything else (unless compile-to-js langs count).
luckman212
I wonder what the future for Atom will look like with respect to performance. I use both (Atom + Sublime) infrequently; load times for Sublime are "instant" on my Mac Mini vs. ~6 seconds for Atom with only minimal packages installed (minimap, color-picker).

I remember reading that perf wasn't going to be looked at until after 1.0. The pace of Atom's development is impressive but I find myself cringing slightly before launching Atom in anticipation of the slow load time. I guess I'm spoiled but I like my editors to load in <1s.

dexterjs
What other technology is being worked on my so many large companies? It may not be as performant now as other languages but I don't doubt that it will get there. The barrier to entry to build packages is also lower seeing as a lot of developers already know web technologies.