
The State of Atom's Performance - ropiku
http://blog.atom.io/2018/01/10/the-state-of-atoms-performance.html
======
Waterluvian
I am _not_ badmouthing JavaScript or bandwagoning on the "Electron is the
devil. Long live native apps!" But I've been wondering more and more,
especially through my own experienced biases at work: how much of the, "we
chose x because y and z" is retroactive justification for the simple truth: "I
wanted to use the technologies that make me _enjoy_ my job."

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.

~~~
smacktoward
I would phrase the problem slightly differently: not "I want to use the
technologies that make me enjoy my job," but "I want to use the technologies
that _I already know._ "

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.

~~~
stupidcar
The thing is, are those alternative toolkits _better_?

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.

~~~
mattgreenrocks
That Google felt the need to invest millions of dollars into making a document
delivery platform into something resembling an app platform is not really
relevant here. Sure, it is robust. But the whole point of the thread is
engineers are notoriously bad at asking what the customer _needs_ from a
product vs what the engineer finds fun to write. You want to have fun as an
engineer? Work on a side project.

The larger the dependency, the more it should have to do to justify itself.
"It's fun to write in" is not a sufficient justification for a 70mb
dependency. "I need a cross platform app" is better.

As an engineer, you're responsible for the transitive dependency graph that
gets delivered to customer machines. If you want to take on gigantic
dependencies because they are the current lovechild of ascendant Medium
bloggers, be my guest. I prefer to go off of more than fun and social proof
when making engineering decisions, however.

------
nkkollaw
I do go back to Atom often because of a few details that I like better over VS
Code, but it's a lost cause, and reading this proves it.

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).

~~~
mikestew
_Memory usage? Sure, but as developers we probably have GB and GB sitting
there_

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.

~~~
nkkollaw
You know, I'm not saying those things aren't important.

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).

~~~
mikestew
Sorry, wasn’t really arguing with you personally. And I agree, I am _way_ more
tolerant than I should be because “shiny”. Last I used VS proper (and it has
been a while), it was a pig, but kinda worth it for the developer experience.
But as you point out, all that piggishness _and_ the experience is less than
great? Umm, someone needs to do a rewrite.

------
dchuk
Reading updates like these from Atom reminds me a lot of some struggles I've
seen with my teams in terms of how to breakdown problems you need to solve. I
try to emphasize the idea of challenging the base assumption that current
problems are stemming from to determine whether we've created our own issues
or are truly facing problems we need to solve for our business.

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.

~~~
oblio
My guess is that they can't challenge those assumptions since they'd break
backwards compatibility for plugins.

~~~
bronson
When Atom makes serious changes to APIs, they find all published packages
using those APIs and notify the authors that things are changing. Often the
notification arrives as a pull request implementing the needed changes, along
with an apology and an explanation of why the changes are necessary. It's
impressive.

I'm guessing the OP is hinting about moving off Electron?

~~~
dchuk
Correct. Don't get a better whip for your buggy, get a car sort of thing.

------
consto
Performance is the reason I switched from Atom to Sublime Text in the first
place. I was annoyed that it took seconds to start, and even then it felt
sluggish. At some point I might give it another go but for now Sublime Text
suites my needs perfectly, even if it has a smaller package ecosystem than
Atom.

------
bjornlouser
The Node performance issue they reference was funny. "you run perf... no you
should run perf... no you..."

[https://github.com/nodejs/node/issues/14917](https://github.com/nodejs/node/issues/14917)

------
shaki-dora
It must be tough to see how quickly the community turns on you when something
better (in some ways) comes around.

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.

~~~
gmueckl
Microsoft has a ton of experience with misbehaving third party developers.
Distrust of code written by others is by now a second nature to them. I am
sure that they would have gotten this right even without Atom falling into the
"open internals" trap first.

~~~
GreenStodd
Which, to be fair is understandable on Microsoft's part. Blindly trusting
others to create in your ecosystem while novel, is a _very_ scary place to be
if you are the one who has to answer to the shortcomings of the platform

------
qaq
I think unless there is some drastic change VSCode is going to dominate in
this space.

------
ninjakeyboard
I've been learning emacs over the last 6 month or so. How is the "hackability"
of atom compared to emacs? I threw away spacemacs, started over, built all my
config, am starting to build plugins etc. While the learning curve was steep,
the flexibility of emacs is quite amazing and I've only just scratched the
surface of the extensibility. It makes me very intrigued to hear about how
other people are using editors like Atom.

~~~
cle
I tried out Atom and found its "hackability" sorely lacking compared to Emacs.
Which made me sad, because it's the only new-gen editor to really claim to be
"hackable".

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.

~~~
earenndil
> 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).

~~~
cle
Because building attractive UIs and doing graphical things is much easier on a
web stack. Emacs can run in a terminal emulator, but as an editor in a
development environment, that's not a use case I've ever had. I'd much rather
be able to seamlessly plot some data with vega.js or slap together a quick UI
for a tool, or be able to trivially inline images, animations, videos, PDFs,
etc. without having to fiddle with native libs.

~~~
runevault
This makes me wonder what an editor would look like where you can hack at the
text buffer/background data/etc in something lower level, but had that
information also accessible with a web based layer for doing UI stuff. Might
be best of both worlds, might just be insanely messy.

~~~
cle
That is basically the ideal editor I have in my head. It would be messy, but
in the way that Emacs is also messy, which is what makes it so great :). It
significantly shortens the distance from my brain to running code.

------
tony
Here's a cool gem:
[https://github.com/atom/watcher](https://github.com/atom/watcher)

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/](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.

~~~
cstrahan
If you think those are great, check out Facebook’s watchman:
[https://facebook.github.io/watchman/](https://facebook.github.io/watchman/)

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.

------
joehewitt
Don't get all the gripes about slow startup time. How often do you launch your
editor? We're programmers - the editor stays open all the time!

~~~
loup-vaillant
Every time I type `git commit`. Every time I visualise files with ranger
(terminal based file browser). Every time I typed an email, back when I was
using Mutt —which I might again.

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.

~~~
joehewitt
Have you considered that Atom is not an editor meant for "quick jobs"? It's a
workhorse for programmers who are coding all day every day.

~~~
seawlf
I don't think that's a good justification for slow startup time and general
sluggishness. Despite having 30+ plugins and 800 color schemes installed vim
starts up in just a few milliseconds on my work rig. I code all day every day.

------
tebruno99
1.6G to .6G memory reduction is great. It’s a shame that most editors use
4-50mb

~~~
oblio
> Note also that these numbers are for users running Nuclide, which adds
> substantial functionality to Atom and increases its memory usage. Typical
> Atom users should see lower memory consumption.

~~~
flukus
It was a really odd graph to show actually, there's no context and it makes me
suspicious. How are we supposed to know if all the memory improvements have
come from atom or nuclide?

------
desertrider12
At this point, they would have saved themselves time by implementing it in C
from the beginning.

~~~
romanovcode
Not that easy to make it work with all 3 OS.

~~~
sydd
Not that hard nowadays, just use something like SDL to do the heavy lifting.

~~~
romanovcode
If it would be so easy as you paint it there would be lot more native
applications. Unfortunately you can count them using your fingers.

~~~
veli_joza
Just want to point out that SDL implementation would be native as in 'not
running on top of VM', but not native as in 'good citizen of host OS'. It
would use non-standard widgets, likely would have problems with keyboard
shortcuts, clipboard handling, drag & drop integration and window resizing.
Depends how much time devs spend re-implementing stuff that's already
supported by OS.

~~~
boterock
I don't think that would be too much trouble, you can find fully custom widget
toolkits with excellent performance and seamless OS integration (check blender
or UE4 for example)

------
qaq
One more big project in the Rust portfolio :)

------
tuanh1805
We are working with electron, and make a simple solution for starting app, if
already, Just create new entry point, in this entry, dont do anything except
check the makeSingleInstance function If an instance already alive => just
quit :D It's make our app seem very fast const app = require('electron').app;
const shouldQuit = app.makeSingleInstance((argv, workingDirectory) => { });
if(shouldQuit){ app.quit() }else{ app.on('ready', ()=>{ require('./startUp')
}) }

------
ConcernedCoder
I love JavaScript and the IDEA of Atom ( I recently tried it again last week
), but a 1/2 second-per-keystroke lag ( on a kinda beefy PC IMHO see:
[https://pcpartpicker.com/user/jeffallen6767/saved/#view=KT9R...](https://pcpartpicker.com/user/jeffallen6767/saved/#view=KT9RGX)
) is a deal breaker for me. If I can't type 60 words a minute in your IDE, I'm
just not able to use it sorry.

------
vemv
Performance certainly matters. I applaud the tireless effort from the Atom
core team.

Personally I'm taking a pause off Atom (after 3 years professional usage)
until it definitely improves.

Best wishes!

------
squant0
It's funny reading this article that details how many core issues still exist,
yet all the while both Atom and VSCode have spent significant engineering time
and resources building superfluous features like shared real-time code editing
and (Atom's) github integration. They are marketed as "text editors" and the
feature work should be prioritized as such.

~~~
oblio
What makes you think those features are superfluous? That's how they plan to
make money with these applications (well, I guess part of the plan).

------
Dowwie
I gave VS Code a try recently for Python development. VSC almost won me over.
However, in the end I found important features / packages that are available
in Atom weren't available in VSC, so I moved back. For instance, autocomplete
("intellisense") failed to recognize functions that were written in files open
in the editor!

~~~
nothrabannosir
As far as I know intellisense, it’s based on their model of your AST and
import paths in the current file, not which other files are open. Open files
are more of a “word complete” feature. i.e. text, non-semantical. like C-N in
vim.

(Not to say you’re wrong to expect it—just for context.)

------
notatoad
huh, fun timing on this one. I finally got fed up with atom's performance and
switched over to VSCode this morning.

------
ParkerK
>Atom takes longer to start up than text editors like Vim and Sublime Text
because of the dynamic architecture of the app. The majority of our code is
written in JavaScript as opposed to C or C++, which is important for Atom’s
extensibility, but makes it more challenging to ensure that the app starts
quickly.

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

~~~
disease
I found it strange that they mention Vim and Sublime Text without mentioning
VS Code anywhere.

~~~
rk06
most of their fans will switch to VS Code if they found it, not so for ST and
Vim

------
ExactoKnight
Honestly, coming from a Ruby dev environment of all things, I have been
_really_ impressed Visual Studio lately. Never thought I'd see the day.

~~~
romanovcode
It's Visual Studio Code tho, Visual Studio is still alive and kicking as a
huge behemoth IDE that works under Windows only.

~~~
ExactoKnight
I dev on a Mac, I'm anti-Microsoft through and through, and I thought the
same. But seriously, their Mac version of Visual Studio (which I use) is now
mature and I think in parts thanks to Microsoft taking steps to support bash,
the ruby support so far has been great if you add the appropriate add ons.
[https://www.visualstudio.com/vs/visual-studio-
mac/](https://www.visualstudio.com/vs/visual-studio-mac/)

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.

------
oblio
They should just hire Federico Mena-Quintero:
[https://people.gnome.org/~federico/index.html#performance-
ar...](https://people.gnome.org/~federico/index.html#performance-articles) :)

The guy is amazing.

~~~
audidude
Interestingly enough, the tool he uses there (Sysprof) I rewrote last year to
modernize it and we use it to both keep GNOME Builder¹ fast, and profile
applications within Builder.

¹ [https://wiki.gnome.org/Apps/Builder](https://wiki.gnome.org/Apps/Builder)

------
valarauca1
Wait.

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.

~~~
acdha
jQuery also provided a ton of usability improvements which many developers
learned how to use. In many cases those are now obsolete[1] but there's a lot
of habits and, more importantly, library code which uses jQuery. Migrating
away from that would require replacing all of that code as well before you can
see any savings in network transfer or memory usage.

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));
        };
    

(that's viable on the web now; with a single modern target you could even drop
the Array.from bit)

------
anfilt
Meh, tried it a while ago. VSCode is better, but still a bloated piece of
software. Glorified text editors that use megabytes of memory when running...

~~~
bastijn
Megabytes, really? “640K ought to be enough for anybody!”

------
stratigos
I want to believe!

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.

~~~
bronson
> First I lost lots of productivity configuring Atom to be in a similar state
> to how I use Sublime Text 3.

> 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.

------
FascinatedBox
Anyone know what tool/script they're using to measure memory usage?

------
rulusidaze
And it's still impossible to drag-and-drop files into two separate windows...

[https://github.com/atom/atom/issues/13558](https://github.com/atom/atom/issues/13558)

------
jamesmcintyre
Why has Hacker News become such a hotbed for cynicism, ridicule and snark by
which almost none comes constructive ideas?

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!

~~~
Khaine
> Why has Hacker News become such a hotbed for cynicism, ridicule and snark by
> which almost none comes constructive ideas?

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.

~~~
oblio
I, and many others, don't care about "native". I've used Java applications and
I will keep using them when they're useful.

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.

~~~
Khaine
Look, I was being a bit snarky. I think all apps that are not native, or don't
follow system convention, create an impedance in that they don't always follow
system conventions, or something about them doesn't work exactly as it would
in a native app. This can cause confusion in users. The level of impedance
depends on the user skill, experience and expectations. I know traditionally,
Mac users have cared a lot about consistency and following the HIG, whereas
Linux users are more likely to pick the application they prefer and not care
whether it is GTK or QT.

If you are someone who jumps between Windows, Linux and macOS using the same
app then consistency in how the app works is a big gain for you, and then the
impedance comes from the system you are using.

I didn't mean to imply that Java apps are bad, far from it. Many java apps are
good, they just stick out like the proverbial, and performance historically
was not as good as native apps. There was a time when the go to torrent
application was java based and Netbeans and Eclipse were the IDEs of choice.
But they made trade-offs, and two of the key ones are performance and
consistent UX with the operating system. For many applications / users, this
is a fine trade off to make. But Atom made a similar trade off and then the
developers have spent all this time and effort trying to improve performance,
and that is what I was trying to be snarky at, that its obvious why
performance will always lag.

------
gaius
_Atom takes longer to start up than text editors like Vim and Sublime Text
because of the dynamic architecture of the app_

And yet Emacs is fast, hmmm.

~~~
rayiner
Emacs' display engine, input handling, etc., are written in C.

~~~
gaius
So what? There’s no reason the Atom team couldn’t optimise their critical
paths while retaining extensibility and cross-platform-ness, and the proof is
that Emacs has already done it.

Their problem is not technical, it’s ideological

~~~
rayiner
That would impair the stated goal of "hackability."

~~~
mr_overalls
Emacs and vim are perhaps the most configurable and extensible editors/IDEs in
existence. Fast doesn't mean unhackable.

------
tbirrell
Okay... But can it handle mounted directories yet?

