The State of Atom's Performance | Hacker News Reader

The State of Atom's Performance

blog.atom.io

234 pointsropiku283 comments

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.

Firstly, I agree with you! I like the philosophy that "Production should be as boring as possible."

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.

I heard once that if you're doing something boring to pick an exciting technology. If you're doing something exciting, pick a boring technology.

Not sure what you would consider exciting or boring, but I thought it was decent advice.

That advice is good when you only report to yourself. If you report to a company and your decisions affect $$$$, directly or indirectly, then it's probably the worst advice.

Do you care to elaborate? That doesn't make any sense to me, as the advice given above is exactly what you should do in a company, if I understood it correctly.

(Higher risk on a simple project, because that's the only opportunity to learn new stuff, as in the worst case you can start over. Lower risk for a complex project, because there's already enough risk in the project itself.)

Processing transactions at a bank is "boring". It's simple, apart from scale, and the spec is usually insanely well documented.

But if you reach for that new language that hasn't been battle-tested yet, you're probably screwing the bank over.

I'm in banking at a startup level and I'd have to disagree with this.

There is tremendous fear in the industry right now over being seen as outdated or dinosaur, especially with all the blockchain hype.

You can make simple technology choices like moving from a stateful SQL database over to a blockchain ledger like Sequence, and in doing so, you will attract a way higher calibre level of talent. You will also have way more people interested in working for you, and the skillsets and knowledge learned within the company for doing it will future proof you far better than going the boring old route.

I'm one of the contractors that rolled out instant transactions at CBA.

The feature is absolutely hype, and a selling point, or was til the RBA required everyone else to follow suit.

But it doesn't change the fact that fundamental things that cannot be allowed to fail should not be built on twigs.

CBA worked with Wells-Fargo to build a blockchain ledger, running atop skuchain, which itself Go and JS. That's a lot of hype and new in one place.

But it wasn't in a simple systems-critical place, it was done for one contract, with one customer first, with regulatory approval for the experiment, to see if blockchain technology was feasible. It was also not proof that this can scale, that needs more experimentation.

Lots of simple things are fundamental, and you do not mess with those.

Simple/complex isn't enough to say whether you should experiment, because experiments should be as far from impacting your bottomline as possible.

R&D should stay in R&D, until it is proven stable. You can't afford to build a house of cards.

The main gist is whatever you add to the company stack, the company is now responsible to maintain, possibly forever. My current situation is basically this times 10 since the people who did exciting tech left.

If the team and managers agree, by all means use the exciting tech, but it isn't a decision to make in isolation.

The canonical link on choosing boring technology is http://mcfunley.com/choose-boring-technology.

A relevant example is microservices which are all the rage right now. But, you have to be this tall to use them[0]. You cannot effectively just say you are going to do microservices, especially if you don't know how to do microservices.

Alternatively, consider the potential problems for your company if you had introduced React on your own in a core business element, and your company had a patent beef with Facebook, and FB hadn't switched to the MIT license.

[0]: https://martinfowler.com/bliki/MicroservicePrerequisites.htm...

> If you're doing something exciting, pick a boring technology.

Not being exceedingly serious here but... you pretty much summed up why Python is so successful in AI/ML and science ;)

How does that follow?

The boring technology in AI/ML is C++.

Which is why TensorFlow etc. have a boring & hard C++ core, and a lovely & easy Python layer that transmits the computational graph to the core.

Electron is similar: a boring & hard Chromium C++ core, and a lovely & easy JS layer.

What pains me is that there is no reason to include libraries we don't use.

Each Electron embeds a large amount of memory-consuming libraries that do things that are way out of scope for most apps: screen recording, sound editing, GPU graphics libraries…

Python is a boring technology. It's a 10+ years old language, like ~20 years behind cutting edge programming language research and implementation. Also, as for the programming style it encourages, it strongly nudges you against any "cool" way of programming: even the most basic kinds of functional programming is something you end up avoiding in P and "dumbing down" your code to more procedural idioms, and OOP over-over-over-architecting is something you just don't do because of the performance penalty and the lack of serious refactoring tools for large codebases. The side effect is that all code is more readable and understandble to anyone, including self-taught devs. JS itself is a boring language at its core too, except that it evolves faster than anything else. And the ecosystem is anything but boring (and also anything but sane...).

Cooler and more advanced (in terms of language features) languages are Julia (it has real macros, advanced type inference etc.) and even R (yeah, it's a mess, but as a language it's more advanced and "cooler" than Python). On the "web backend" scene Ruby is a way more "not boring" language, but the ML and science communities avoided it almost completely (I have a few theories as to why...).

And then there's the "truly cool" and "0% boring" languages like: Scala, Rust, Elixir, Clojure, Haskell, Elm, Crystal, Pony etc.

But don't get me wrong, I like Python for being what it is: an incredibly boring scripting language, that encourages a "stone age level" style of dumbed-down programming. With slightly awkward but stable libs (on which people agree almost unanimously of which to use). Because with Python I can focus on the product instead.

Python was shown to the world in 1991, and hit 1.0 in 1994, making it roughly 27 years old, incidentally. You did say 10+, but most people don't realize just how lengthy a pedegree Python has.

C++98 mostly coded in C style, is boring & hard.

C++17 written using best practices in safety learned in the last decades, is exciting and simple.

Huh?! ever seen a c++ project not using any pre-C++17 code?! If it's there, sooner or later you're going to have to debug through it :)

Anyway, C++ is nothing but boring... even the bugs you encounter are nothing bu extremely surprising and "creative" :P

I wrote C++17, just to hint how one should aim to write proper code as of 2018. At very least, one should be making use of C++11 and whatever the compiler already supports from C++14.

Of course, it will take time to move from "C compiled with C++ compiler" to something better, specially in the embedded domain where Assembly and C still rule.

The tools are there, and an incremental update into safer code is always better than throwing everything away, and rewrite everything, including the already fixed bugs.

The only thing that C++ cannot fight against is the C mentality. That is only possible in languages that lack copy-paste compatibility with C.

Most engineers have this bias. Feigned justification for biased decisions in the past rather than challenging original assumptions in the first place.

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.

I don't disagree with your analysis, but I disagree that it's a simple rephrase. They are two separate issues:

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.

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.

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.

> The thing is, are those alternative toolkits better?

IME, yes. Most of those toolkits also have thousands of hours invested to work well across platforms, not consistently but natively, or at least a close facsimile of native.

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

So nothing that hasn't been true of desktop apps for decades then? If you want power then nothing beats being able to overide the paint method of a widget, you have complete and total control.

If you're interested in seeing how easy desktop apps are I built the canonical todo list in Gtk (https://gitlab.com/flukus/gtk-todo/blob/master/main.c), the goal is a demo that's a bit more complex than hello world. This is in a language not known for it's terseness, uses one of the nastiest parts of the framework (GtkTreeView) yet it still comes in at less than 100 lines of fairly straight forward and simple code.

Yeah, this is is actually one of the reasons I used Electron for a screen-recording project...because most browsers didn’t implement the experimental screen recording APIs yet but Chrome already had it.

https://github.com/styfle/magnemite

> 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

And it only costs you 400MB of RAM and 20% CPU utilization!

And note that outside of C, C++, .NET, and java, making a desktop means using a library built in another language with documentation in another language. (C has GTK and C++ has QT.)

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

I experienced this too. Strong Python developer wants to build a GUI in a few days to help others perform a task. Uses PyQt, runs into segfaults (in Python?!) and has to drop down a level, understanding the implementation and nuances of QT.

Forget Lazarus. There is no (finished) Cocoa for Mac. Development is not on Github. Syntax has no common style. Documentation is uneven. The whole ecosystem feels (well, is) dated.

Of course, Lazarus/FPC is still quite nice. But to really shine and be a valid alternative, it would need a large infusion of money and manpower.

Thus, don't hope too eagerly...

> There is no (finished) Cocoa for Mac.

This is true but in practice the Carbon backend will work fine and if that isn't good enough you can use the Qt backend which uses Cocoa (but then you'd have to bundle Qt with your app which increases its distribution size a bit). To preempt a "then why not just use Qt" reaction, this isn't the same as using Qt since you can use the Win32 and Gtk backends in the other platforms.

Cocoa is of course under heavy development, but keep in mind that there are only a handful of Lazarus developers that even have access to a Mac and they actually had to write a special dialect for the compiler (Objective Pascal) to be able to handle Cocoa objects directly without the need of an intermediate (like Qt that needs libqt4pas that exposes the Qt API as a C interface that is then linked dynamically with FPC through a C-to-Pascal binding).

> Development is not on Github.

This is not a negative, please do not enforce the GitHub monoculture, GitHub is not the be all end all of open source development.

> Syntax has no common style.

What do you mean? The IDE even provides formatting tools.

> Documentation is uneven.

Documentation is lacking in terms of detail but generally you can find stuff easily and things have improved tremendously over the last five years or so (it used to be that you had to have some old Delphi help file to find anything or dig into the source code).

> The whole ecosystem feels (well, is) dated.

Sorry but this doesn't mean anything, please be more specific because this feels like you just want to mudsling.

> But to really shine and be a valid alternative, it would need a large infusion of money and manpower.

Careful what you wish for, because more often than not having a company become a dominant player, it ends up steering a project against the wishes of the community. Lazarus, like Free Pascal, are fully community made projects and most of the people who work on it do it on their free time. On one hand you get a few rough areas like those you mentioned (immature Cocoa support, spotty documentation, etc) but on the other hand you do not have anyone throwing their weight around. For me Lazarus being community driven is a major feature.

The biggest problem Lazarus has is simply the lack of developers, but this will only be solved with developers fixing the issues they face. Fortunately i've seen a lot of new blood lately in the mailing lists so i expect things to improve.

No mudslinging intended, I'm thankful for the community and Lazarus is a nice tool indeed.

>> Development is not on Github. >This is not a negative, please do not enforce the GitHub monoculture, GitHub is not the be all end all of open source development.

(Most important is, what the fpc/lazarus developers want). -- Many people likely don't want to bother/install the 'ugly and stupid' SVN nowadays and Lazarus/FPC looses all those potential contributors at once. I don't like monocultures either but GitHub (maybe Gitlab) is the pragmatic choice and imho helps to have/find contributors.

>> Syntax has no common style. >What do you mean? The IDE even provides formatting tools.

Comparing Lazarus, FPC, MSEgui and some component sets, I had the impression that there are many (small) differences, e.g. 'integer', 'Integer', 'INTEGER', where begin..ends are placed and many more 'non-conventions'...

Tool is good, but (imho) the issue is that there is no BDFL which would gently nudge towards a commonly agreed style guide. Likely not helpful is also that Pascal is not case-sensitive and that there are multiple modes (OBJFPC, DELPHI, FPC..)?

>> Documentation is uneven. >Documentation is lacking in terms of detail but generally you can find stuff easily and things have improved tremendously over the last five years or so (it used to be that you had to have some old Delphi help file to find anything or dig into the source code).

I don't want to complain. Core FPC docu is high-quality, written in Tex. But I found it difficult to get an overview: which are the relevant pdf's/links, where is the source for it, how would I contribute or report an error? For a quick shallow fix, it seems too complicated: Tex, xml; inline help, huge separate svn docu project; FPDoc generator. Contrast this to many environments where you can quickly fix a typo or phrase in the browser and the project gets a PR.

>> The whole ecosystem feels (well, is) dated. >Sorry but this doesn't mean anything, please be more specific because this feels like you just want to mudsling.

Difficult to be specific. If you e.g. look at go (golang.org/), rust (www.rust-lang.org), julia (julialang.org) and/or haskell (haskell.org) and some of their tool-choices, it feels for me very different than FPC/Lazarus. This is not mudling, it's just a realistic look at the situation. Dated also doesn't mean that it wouldn't work any more.

It is imho a problem if e.g. there is newpascal.com site with a more modern feel instead of the old trusted projects moving to a more modern approach. Don't know details but this choice raises the complexity for a user as it is not clear, what to choose.

>> But to really shine and be a valid alternative, it would need a large infusion of money and manpower. >Careful what you wish for, because more often than not having a company become a dominant player, it ends up steering a project against the wishes of the community. Lazarus, like Free Pascal, are fully community made projects and most of the people who work on it do it on their free time. On one hand you get a few rough areas like those you mentioned (immature Cocoa support, spotty documentation, etc) but on the other hand you do not have anyone throwing their weight around. For me Lazarus being community driven is a major feature.

Do you have examples for such companies / situations? As the code is mostly GPL-2 (components LGPL2 with link-exception or MPL), it seems to be difficult for a company to take over. And personally I wish that there were steerings towards a more uniform and easier-to-enter 'FPC/Lazarus-world'.

>The biggest problem Lazarus has is simply the lack of developers, but this will only be solved with developers fixing the issues they face. Fortunately i've seen a lot of new blood lately in the mailing lists so i expect things to improve.

Yes I hope things improve with new blood. For the 'Pascal universe' as a whole, lack of developers means 'not attractive enough'. As I really like the language I would blame the choice/proliferation of 'dated stuff' to be a contributing factor.

Last but not least, Lazarus worked well last November when I tried it out again. I was positively surprised. Nevertheless one has to have realistic hopes...

> And note that outside of C, C++, .NET, and java, making a desktop means using a library built in another language with documentation in another language. (C has GTK and C++ has QT.)

Not necessarily. D has dlangui and dwt, tcl (and also python?) has tk. Vala is also available for gtk. I think VB also lets you write GUIs although not sure I never used it. Objective-c has cocoa (gnustep outside of macosx).

> This "I don't have to learn anything new" factor is literally the only thing Electron has going for it.

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.

The other thing to keep in mind is that a similarly script-extensible Qt application carries the weight of Qt shared libraries, plus scripted wrapper shims. This can easily run 25-40 MB in Python-Qt systems, at which point 70 MB for Electron looks much less crazy.

(also a C++/Qt dev, jealously eyeing love preview, hot-reloading, and other niceties).

> Starting from a web framework not only gives you portability

... except when you actually need to actually, you know, port it, to a platform it wasn't already ported to out of the box.

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

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.

Free software is obliged to use technologies that make contributors enjoy their job, especially for a project like Atom where you can't expect an individual or small group to do all of it.

Is it really bandwagonning to be annoyed that so many bits of software, which many people run simultaneously, use a tool where a Hello World is over 100MB in memory?

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

Electrino was a great idea, but the project was more of a POC and I haven’t seen any new development.

So until someone can build a production ready, cross platform, JS desktop experience....Electron will live on.

On android I think both Chrome and Firefox supports installing a website as an icon on the home screen.

It might already hide the address bar when opened in this mode. I personally expect that it's just a matter of time before this becomes an install mode for desktop apps as well.

When I check where my battery life is disappearing will these apps appear under Firefox/chrome or the app name?

It sounds like a promising avenue for bitcoin mining.

http://fluidapp.com/

You fail to realize the purpose of Electron.

It’s not to wrap a website, it’s to add features that the web doesn’t offer.

For example, how could Atom exist and be able to show your files in the explorer pane as a web app? It can’t.

Electron adds the missing pieces/permissions that desktop apps have had since the beginning.

Here are some more reasons to pick a technology:

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.

Thanks to Docker and Kubernetes, everyone that cares about DevOps needs to brush up their Go skills, regardless how we might think about it.

However this is a part of being professional, using the required tools for the job.

I wish engineers and computer scientists would pay attention to that gut reaction more often.

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.

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

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

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

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.

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

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.

> I fail to see why one wouldn’t just use VS Code

Github is cool, Microsoft isn't. /s

VSCode is really bizzare, in a good way. All the configuration is done through JSON files. It's a good editor as well as an IDE. There's no "projects" or "solutions" or wizards. I almost never run into issues with it.

It doesn't feel like a microsoft product at all. Nothing like Visual Studio.

Maybe I should give VSCode a try then. I've been using Atom for a year now and some things just never felt good.

I was in your position a year back. Now I'm in love with VSCode. Do give it a try.

VSCode won me over grudginly. It's faster, lighter, and just as extensible. I was conditioned at an early age to throw holy water at anything Microsoft, and still, I like VSCode better than Atom.

VS Code is basically everything Atom tries to be and/or should have been. To me it’s the spiritual successor of the original TextMate: works great out of the box, but can also be customized to fit your needs.

I don't know about this. Configuration via JSON is common (Sublime Text, the most popular), I'd say that it's Atom that is bizzare on this aspect.

As for "projects", I'd argue that if you open a folder, that's your project/workspace/whatever.

Just thought I'd add this in case someone who doesn't know VS Code[ well] gets confused.

Atom can also configured via JSON files. They create their config file as CoffeeScript Object Notation (CSON) by default, but nothing is stopping you from changing it to ~/.atom/config.json

Configuration via JSON is common (Sublime Text, the most popular)

I haven't tried Sublime Text. I was comparing VSCode with Visual Studio, and IDEs I consider to be in the same space like Netbeans and Eclipse.

VS Code is not an IDE, it's an editor (like Sublime Text).

Netbeans and Eclipse are both IDEs.

I disagree. It has smart auto-completion, refactoring, it informs me of errors in my code before I run or compile it, integrated version control, auto-compilation, and many other features.

I use vscode as a Golang IDE. It's pretty comprehensive with the extension that integrates the Go toolchain.

I tried Gogland EAP for a while, and liked it a bit better, but now it's a paid product, I'm happy with vscode (which has 95% of the features I use and 0% of the price).

Man you are so pissed and condescending. Do they make you use Atom at your work or are you really that angry that other people use an editor you don't like?

> What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness.

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.

Maybe they should rewrite it in React. I've been argued into the ground under the guise that it's faster than the browser's rendering of DOM.

That doesn't make sense...the browser always does the rendering of the dom. Not react.

React speed when keeping your states and data in sync is that React makes all changes to the virtual dom then it makes it to the browser dom.

It not different then the concept of batching graphic changes in a 2d game. You blit batches of sprites that need to be changed around the same frame instead of making 500 draw calls you make 1.

Instead of the developer worrying about trying to gather all their dom changes dependent on user interaction and data syncing you interact directly with Reacts vDom and then react takes care of making the dom changes.

Virtual dom frameworks are a huge thing now cause UX/UI are more complex and we were fighting those issue before. Angular, Ember now, Vue, react ect cause we get speed back when making many state changes to our UI.

This has nothing to do with Atom.

If a bottleneck is dom manipulation, then something that smartly batches them and reduces the number of times it's called would help. How would that not apply to Atom?

The article says this:

> In May, we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible. We made use of the latest DOM technologies and rendering techniques, and built a tiny React-like library called etch that allows us to structure our rendering code cleanly while still allowing for imperative DOM manipulation for maximal performance in certain code paths. 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.

Emphasis is mine.

Because they already implemented something similar as per the blog post.

React has an implementation of a virtual Dom. They don't have to use react to do that and as discussed in the blog that is the major slow down on their UI.

*wasn't one of the major slow downs

They've been there and done that

http://blog.atom.io/2014/07/02/moving-atom-to-react.html

http://blog.atom.io/2014/07/22/default-to-react-editor.html

Turns out that for the important things in an editor, React has a hard time optimizing as much. I'm a huge proponent of React, but the right tool for the right job is an important principle for the pragmatic.

https://github.com/atom/atom/pull/5624

I think since then, they've circled around to a much more restrictive and faster virtual dom. React could be made quite a bit faster (as proven by Inferno) without changing the API and moving to a more monomorphic, but verbose API could probably offer a big performance boost.

I've wondered in the past if the best solution wouldn't actually be to render the editor part as a canvas element and remove the normal DOM from the picture completely. VS Code did something similar with their console a few versions ago.

https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...

EDIT: Looks like they've given some thought to canvas already (for the next go around). With webassembly, they could even offload to a nice C++ or rust library running and repainting a canvas element in another thread.

http://blog.atom.io/2017/06/22/a-new-approach-to-text-render...

This is the exact reason I've commented (and been shouted down for) saying that React is a fad. It's trying to replace fundamental core system with a layer, and do it better. It will never work, it can't.

Eventually everyone will figure out that building "apps" with DOM manipulation will never be as performant as lower level coding (ie, not a script layer), and they will move on. And the DOM will return to light apps and general purpose websites with basic interactivity.

How can it go any other way? Btw, the only reason I am posting this is bit out of frustration that stating something so obvious makes some people really angry. I suspect its because they have invested so much in React, and don't want to consider it a temporary hack until webassembly or shadow dom or some other tech makes it completely obsolete.

I tried out Atom, it's miserably slow. And I recently downloaded VScode, just to give it a whirl, and it's impressively faster. But I use Komodo, and that is based on Scintilla and Firefox, and it works just fine.

React’s declarative Api is much easier to read and update than working with dom calls directly. And React itself doesn’t even have to target the dom, as with react native which generates native system UI

I actually like that Sublime Text keeps its settings in JSON files. That way I can pop em in git alongside the rest of my workstation configuration.

We as developers might have plenty of RAM to waste, but our users usually don't. If it runs well on our machine but not in the users', what good is it?

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?

> We as developers might have plenty of RAM to waste, but our users usually don't.

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

Unfortunately the attitude is pervasive and electron is also used for applications more in line with what your mom would be using. I think many would be shocked that a good chunk of their audience has less than 8GB: http://store.steampowered.com/hwsurvey

It's also a mistake to assume developers have plenty of RAM to waste. A couple of years ago I was using a potato for coding on the way to work that only had 2GB, which made atom a no go.

Also, what happened to the idea of dog-fooding? It's not dog-fooding if your on a machine much faster and with more memory than your users. I think the problem with windows 10 is that all the devs were dog-fooding on top of the line surface pros.

> Memory usage? Sure, but as developers we probably have GB and GB sitting there...

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

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

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.

> Who cares about start-up time? I only open the thing once/day.

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.

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.

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

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?

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

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.

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

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.

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.

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

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

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.

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

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.

I would also like further discussion on this. I am full-time emacs. I hear from other colleagues that they will split time between editors. "vim for writing and VSCode for refactoring".

If anything the thing that is a killer feature that I always try to get out of emacs but ends up being half baked is the code completion/code aware tools (like the example given of refactoring). With emacs and yasnippet I can emit a ton of code but if I ever have to do a big surgery and have some level of assurance it's right as I go along is nice and I end up falling back into Eclipse/Visual Studio for those sorts of things. I have rarely gotten Emacs to have good code completion with most large software projects, and I end up using tools like opengrok to do the initial search because it just indexes better before diving in with emacs.

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.

This isn’t really relevant to Atom, but... Emacs is working on this, on several fronts. In many ways, this isn’t (yet) an improvement, because what we have now are a bunch of partial implementations that mostly get different parts ‘right’. On the other hand, progress.

TBH, one of the big stumbling blocks is that a lot of the most adept Emacs hackers simply don’t do much of the sort of ‘IDE-grade’ stuff, so in a real sense, they don’t understand what they (and Emacs) are missing. (Fair cop: I’m largely in this boat myself.)

For example, Emacs has had dynamic adaptive customizable electric hippie completion for longer than there has been a publicly released Java language, BUT many (is it still most? My experience is old) Emacs hackers just never did the sort of refactoring that made people tolerate Eclipse — and that was over a decade ago.

One more thing: if you are interested in lisp, can stand to see C code, and are interested in LSP, look at Emacs-devel.

Ya I do periodically spend time in intellij when I work with scala, just because of the discovery and refactoring capabilities. Particularly very large/involved refactoring is helped by the tools. I did a core redesign to support an entirely new use case in a product I'm working on now. I tried to do it by hand and burnt a day, threw away everything, opened intellij, and applied a couple refactoring. In 40 minutes I had the tests passing for what was a very broad and wide refactor.

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.

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

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:

http://leoeditor.com/

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

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

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.

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.

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.

Here's a cool gem: 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/

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.

If you think those are great, check out Facebook’s 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.

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!

I don't either. It's pretty fast as it is. Even if it took 10 seconds I don't think I'd mind too much as I close atom maybe once every few days, mostly by mistake (stupid cmd+q)

There is also time to open new files as a subset of startup. Atom is significantly slower on large files than sublime.

I would like to be the first to welcome you to the world where your personal preferences and experiences aren't universal. I don't use my computer exclusively for editing text, and therefore my text editor is not open all the time.

> I don't use my computer exclusively for editing text, and therefore my text editor is not open all the time.

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.

Design for whatever you want to design for. Plenty of us are programmers who program all day every day and still don't agree with you. What you choose to prioritize is different from what you understand, though. So at least now you should "get" the gripes.

Well if the Atom developers are reading this I want to encourage them not to waste energy optimizing startup time due to Hacker News complainers who are using the product for a use case better suited to Notepad.

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.

> Every time I type `git commit`

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

Opening a new window in the already-running app is also slow; they cover a strategy for increasing that performance in the linked blog post.

No doubt but e.g. VSCode’s sub-second performance shows that’s not a huge stretch while sticking with Electron and it has a subset of the challenges for startup performance

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.

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.

VS Code's update cycle is like once per month which requires a restart. It starts up so fast that it doesn't even matter. Can't say the same for Atom.

If you're on the insider channel, the update cycle is daily. Microsoft's Code group is really knocking it out of the park with attention and responsiveness.

I imagine you use arrow keys too.

I use vim, which launches almost immediately. I launch a new instance for every file I open, each in a new screen. It seems to work fine. Yet I wouldn't be able to do that under atom... (ignoring the issue of it doesn't work with tty).

I launch instances of neovim all the time. So often that I have a keybinding for it (super + v). It launches and is ready to use in under 500ms.

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

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

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?

When loading a hello.c both Emacs and Sublime almost breaks the 50 MB barrier with default settings, but does that really matter?

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

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

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

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.

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.

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)

If you don’t care about native look and feel, you just need std lib, POSIX/win32 library (threads/sockets), SDL and IMGUI. Do a handmade hero-style platform layer for the system stuff and you’re portablr.

I was wondering that, they are going to extraordinary lengths to deal with issues that wouldn't have existed in a native application.

One more big project in the Rust portfolio :)

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

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

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!

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.

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

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!

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

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

>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

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

Vim and sublime aren’t their competitor while vs code is.

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

I know that vscode has a lot of non-electron native code baked in as well, which I'm assuming atom has far less of.

Does it? I've not heard this myself, and the GitHub page says there's no native code in the main repo: https://github.com/Microsoft/vscode

whoops, maybe I've heard wrong then.

Apparently they use a lot of windows apis and dlls -- except that it works on linux and there's no c/++ to generate a dll, and I forget where I read that. (Somewhere on HN.)

I just started writing a GAE Python app, and I needed a good, free editor for my Mac. I chose vscode, and it's been superb. Hitting shift+cmd+p for any command, the python tooling, and the default keyboard bindings are great.

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.

Also isn't the majority of Sublime Text written in Python which in my experience is slower than JavaScript.

No, common misconception. It just has Python bindings for extensions.

The majority of Sublime Text is written in C++, it's extensible using Python.

It is not "much faster" at all, both are horribly slow. (I can see how one would be convinced VSCode is fast if they're comparing it to Visual Studio which has absolutely abysmal performance). Though I could be convinced with newer benchmarks. All I could find was this experiment from a year ago that shows Atom and VS Code opening within a fraction of a second of each other, but Sublime and TextEdit beating both of them by an order of magnitude:

https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...

>if they're comparing it to Visual Studio which has absolutely abysmal performance)

how? it's slow to start, sure, but once it's started it's not noticeably slow.

I don't know why you would characterize it that way when they very clearly describe what they've done to improve this and their plans to improve it further. I wish every company would "refuse to admit" the same way!

Because their direct statement, at the end of the day, just unilaterally shifts blame to Electron for something that is partly their fault. So while they do have improvements in 2017, and it's great to see their steps for the future, they still have a fundamental issue in not admitting that they are slower than their direct competitors, who also are burdened by the same issues Atom is saying are the reason for their performance.

Emacs starts reasonably quick and it is written in a very extensible language.

I don't know if this is still true, but for many years emacs used a horrible hack called "unexec" to obtain this startup performance.

https://lwn.net/Articles/673724/

That sounds similar to the "snapshot" feature Atom is using.

It was only true for glibc as well, and its no longer true as unexec got ripped out of glibc recently as only emacs was using it.

The problem I believe is not with the startup time. If you load bunch of scripts in your emacs, it also gets sluggish at start. The way Emacs people solved this problem was to use a server client architecture and run Emacs as a daemon.

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

I believe that was actually due to a quirk in the way CSS animations worked in Chrome. It was fixed by changing to setInterval which is what was used before. GIF animations were proposed, but AFAIK never actually used.

Here's the GH issue: https://github.com/Microsoft/vscode/issues/22900

From the atom FAQ in answer to the question "Atom feels slow or is consuming too much CPU or memory"

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

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.

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

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/

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.

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

The guy is amazing.

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

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.

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)

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

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

You never have used any of those java based IDE, have you?. A clean install of Eclipse takes about 400 mb before even creating a project. Android Studio is a nightmare of epic proportions. VSCode provides the same level of autocomplete and features at a fraction of memory without lagging at every keystroke.

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.

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

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

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

https://github.com/atom/atom/issues/13558

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!

Just like with every forum, circle jerks reign supreme

Personally, Atom is not my editor of choice (team Sublime!), but I really hope Atom succeeds. I do love it's hackability, and I would much rather have my plugins in JS, but alas, it's just not fast enough for me, yet.

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.

If sublime natively supported JS plugins I think all Electron-based editors would be in trouble.

This may sound like heresy but I seriously encourage checking out today's version of Visual Studio.

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.

Yeah, but the Visual Studio installer still sucks, there's no portable version that I know of, and extending it is a major undertaking. Plus, it's Windows only (the version for Mac is mostly a different app).

It is a great app, I agree, but it also comes with its own legacy.

I'm using the Mac version. Started with it today. It felt like getting all the benefits of RubyMine without the learning curve of needing to learn its non-Sublime macros, thanks to Visual Studio's option to automatically map key commands to mimic Vim, Sublime or Atom.

Not sure how difficult extending it is, but on day one in their app store I found all the important ruby bindings I needed to replicate what I value most in my Sublime set up: i.e. ruby linting and rubocop.

The switch was so painless I hardly noticed I wasn't using Sublime -- except in the moments of joy when I found the other powerful things it can do.

This stands in big contrast to RubyMine -- an IDE I absolutely also adore for its power -- but one that I found challenging to pick up due to its custom macros.

You mean Visual Studio Code? I feel we're talking about different things here...

Eh, yeah, I guess that's what I meant. Didn't know there was a distinction? This: https://www.visualstudio.com/vs/visual-studio-mac/

If you're talking about VS Code, I tried it a few months ago, and while it was faster than Atom, it also aggressively took over file associations, which is pretty irritating, TBH.

I'll have to look into the plugin API, though. I'd have to convert a lot of custom plugins, but that could be a fun weekend distraction.

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

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.

s/in-group/in-meme

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

This is a wonderful subject, memes and group think, I would say everyone feels like they are part of an minority/snowflake community in some of their views. Memes just makes it easier to get that feeling.

So it is not possible to have these discussions without the out-group interpreting your remarks as snarkiness. Handling that is hard, FUD is one way to handle it, compassion another. Social interactions are hard.

I think the moderators do an excellent job on HN. The signal to noise ratio is pretty high here and while there is snark, there's far less than in most other forums.

One stark difference between HN, Product Hunt, and other maker forums is that HN is a very critical audience. It's even been specifically called out as such by Pieter Levels in his new book, Make.

Snark is against the guidelines, and I can tell you that the moderators find it dreadfully boring, whomever the source. We could use your help if you come across highly-ranked snark to please downvote, flag, or email hn@ycombinator.com. We don't see everything on the site, but we do read all of those emails.

https://news.ycombinator.com/newsguidelines.html

Positivity is marketing, you can get that anywhere. I come to places like HN to see what's honestly bad about various technologies and tools.

And don't tell me no editors are really worse than any other editors. That's crap.

How you say things also matter. If you are an asshole about shit people will be less likely to share their work with you.

>> written in the accessible Javascript language so that anyone can contribute

Anyone that knows JavaScript.

Which is a very substantial population.

Lowest common denominator.

We put it on every kids desktop in the 1990's. We put it on every kids phone in the 2000's. We are shocked when they reinvent the wheel with in the 2010's.

Now in 2020 they are trying to tell me all the kinks are worked out with frameworks and to get your javascript to work in a browsers you first need to compile/transpile it.

Skip the whole multi-platform idea and focus on electron with all the custom bells/whistle not available on all the platforms. Btw how does meltdown/spectre affect the outlook on security with all these application in their own little v8 kingdoms?

I'm not cynical, I'm concerned.

Indeed. The mess we're in is one of crap upon crap.

I wanted to use a CSS framework the other day, and I all but had to rip the project apart manually just to get the files without them stuffing a heavy build tool like Gulp down my throat.

All of this... just to get some !@#$ing CSS.

And before that every computer had C and Basic. There seems to be a common aspect here, the default programming languages suck :)

My first one came with ZX Basic and Z80.

The next one came with debug and GW Basic.

Followed by another one with debug, GW Basic and QBasic.

I always had to buy my Assemblers, Pascal and C++ compilers.

Which computers came with C, besides UNIX workstations?

My general dislike for Atom wasn't anything to do with the editor itself, I've just always been sore they used CoffeeScript which is a language I personally _loathe_. I was excited to have a sublime replacement I could hack on, but that killed it for me. It was that it was so inaccessible and for such a asinine reason (a language purely for syntactical sugar). JavaScript is the lingua franca of the internet for fucks sake... I'll stop ranting about that.

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.

> CoffeeScript which is a language I personally _loathe_. [...] it was so inaccessible

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?

Why would I learn something which doesn't offer me any value? CoffeeScript is literally syntactical sugar, which I believe, adds levels of indirection to the code and makes it more difficult long-term to support, read, and develop. Not only that, but JavaScript's evolution has made nearly every reason to use it moot.

Also FWIW-- I've done vastly more native and server-side programming over the last... oh, seven years than "web." So... I don't think this is something with "web developers."

yeah, I could see myself saying the same but not about coffeescript. That thing just needs to go away, seriously.

Having to constantly keep a mental model of two languages when you write code outweighs any benefits from syntax sugar and supposed readability.

It was nice ten years ago when JavaScript was absolutely horrendous but not now.

> It was nice ten years ago when JavaScript was absolutely horrendous but not now.

ECMAScript 5 was released in December 2009, Coffeescript first appeared the same month with release 0.1.0.

What was absolutely horrendous about ECMAScript 5?

edit: Javascript 1.8 shipped with Firefox 3 in June 2008.

i don't even.. for people making these claims there's just no way to convey how horrific js development was until quite recently (it still is far worse than most popular languages out there tbh) other than inventing a time machine and sending you there, but then it's a kind of punishment i wouldn't want upon my worst enemy.

browser fragmentation rings any bells? were you actually doing js dev back then?

What is the connection between browser fragmentation and coffescript syntax? Coffescript was born to have a lighter JavaScript-like syntax, not to remove browsers fragmentation.

the connection is between fragmentation and claim that ecmascript and js 1.8 were released and everything magically became great in december 2009 as was implied by the grandparent.

> magically became great in 2009 as was implied by the grandparent.

I implied nothing, I asked you a question. Might have been a bit open ended but you made a claim that did not reflect with my reality. So I did a reality check.

If there was a "magic" moment I will give chrome released late 2008 and firebug 1.4 released early 2009 the attribution for a turning point in webdev.

> I implied nothing

X was horrible ten years ago -> but X' was actually released 10 years ago, what was horrible about X'?

sorry, there is no way for me to interpret that other than implying that my statement was false.

there were multiple magic moments, but js didn't stop being horrible on daily basis for another couple years. having chrome debugger or firebug didn't save you from having to support internet explorer, did it?

> save you from having to support internet explorer, did it?

I showed IT how we can keep firefox updated on all our machines using AD.

External sites said best viewed with firefox and mentioned ie6/ie8 a steph-child.

My solution not acceptable for everybody, but my employers were happy and I could continue being productive without worrying to much about ie.

lucky you

> were you actually doing js dev back then?

Actually started webdev in 2004 php3 and basic js. Back then the joke was "nobody know how to code js, everybody just copied this one piece of code and mutated it from there".

It sadness me to think such behavior is more entrenched in todays development environment with sites like stack-overflow.

Don't get me wrong I'm grateful that sites like SO exist. I'm also grateful that when I had to learn the ropes or solve "hard problems", I could not turn to my browser. Like I do today; every fsck'ing time; because it is easier and I'm lazy.

> that didn’t stop me from writing hundreds of lines of Emacs Lisp

Oh, you wrote an A.I.-enabled missile launch control system in your first weekend too? ;)

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

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.

Not sure I entirely agree with the second bit. I adored Reddit until everyone abandoned digg for it. Just about every post had some expert commentary

I tend to see the cynicism/ridicule only at first. As comments accumulate it balances out. Overall it is not cynical. I would say it has improved over the years actually!

Perhaps there's lots of cynics hunched over their keyboard hitting refresh on HN so they can jump in. Who knows?

Ask a group of carpenters about what brand of hammer they use and see if you get cool, calm, rational responses.

Beats me. I use Atom everyday and spend zero time wishing I had a better editor.

Comment from actual Atom user, doesn't think it sucks, amazing!

Honestly, the strongest text editors are those that integrate with an IDE that also syncs with your runtime.

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.

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

Dude you are so off base. Atom for daily driving is not slow at all and on OSX feels perfectly native and well integrated with the OS. So your entire point is dependent on assumptions that the UX sucks and the performance is worse than many native apps, both of which in this case are completely wrong.

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.

The last time I tried atom a year ago (for the second time) it was so slow I had to write this to warn my future self: https://github.com/QasimK/my-setup/blob/master/atom.md (Nov 19 2016). This was on a modern powerful desktop.

I'd imagine after a year of updates it would be the perfect time to give it another spin. Not saying it's any better but to negate something entirely because of a bad experience over a year ago is a little over the top IMO.

The usual counterpoint: VSCode.

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.

True. jEdit is one of the best editors i have used. Not my default editor but i use it from time to time and install it everywhere.

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.

If they're so bad, why are so they popular?

https://insights.stackoverflow.com/survey/2017#technology-mo...

Being popular isn't a synonym for quality.

It proves that there was a need not met by other options. Do you resent Atom developers for giving away free tool that you consider subpar? Or are you angry at its userbase for choosing Atom over your preferred option?

I don't use Atom but I'm glad it exists. It improves on state-of-art in some areas and that benefits everyone.

Yes, because of Atom many developers probably won't be giving money to e.g. Sublime Text or any other commercial alternative.

This is why good tools are only available to enterprise customers, the only ones willing to pay for their tools, just like in other professions.

There is nothing in Atom that I can consider state of the art.

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

They did, and the result wasn't that bad: http://www.jedit.org/

I meant in terms of performance and nativeness. I was thinking of like Netbeans and Eclipse, which were both great IDEs yet sucked with performance (i.e. start up time, memory consumption) and fitting in with system idioms.

Well said!

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.

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

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

That would impair the stated goal of "hackability."

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

If you read the post, that is mostly the work that they're describing.

> There’s no reason the Atom team couldn’t optimize their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it.

I believe that's what the Atom team is doing. They've detailed several critical paths that can and will be rewritten in C++/Rust in the linked post.

Your point?

Write slow javascript, get slow programs. It's not a crazy concept.

Edit: typo

Emacs is written in Elisp which is a dynamic language just like JavaScript

emacs core is written in C. All of your extensions are mostly in elisp. A few run servers and talk to them though. (Eg ensime)

> Emacs is written in Elisp which is a dynamic language just like JavaScript

All dynamic languages are not born equal when it comes to performance. 2 implementations of the same language aren't even equal. While V8 is a fast JS engine, the DOM isn't. Emacs doesn't rely on the DOM unlike Atom or VSCode.

And Electron’s are written in C++, so I’m unsure what your point is.

Yes and no. E.g. Atom does its line layout and rendering in Javascript, which manipulates the DOM, and Electron then renders things using C++ code: http://blog.atom.io/2017/06/22/a-new-approach-to-text-render....

Emacs' display loop is tens of thousands of lines of C that directly calls the native text-rendering API: https://www.facebook.com/notes/daniel-colascione/buttery-smo....

emacs can be very slow to start if you install everything and the kitchen sink. I had spacemacs installed with everything for working with elixir and it took maybe 5 or 6 seconds to start. I started over from a blank init.el and I have it much quicker but it doesn't really matter because you just run a daemon and connect to it.

> it doesn't really matter because you just run a daemon and connect to it.

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.

On macOS, I have the following defined in ~/.bashrc:

   alias emacs="/Applications/Emacs.app/Contents/MacOS/Emacs -nw"
   alias e="et"
   alias eb="/Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q --eval \"(load-theme 'misterioso)\""
   alias et="emacsclient -t -a ''"

Explanation of the `-a ''` option per `emacsclient --help`:

   -a EDITOR, --alternate-editor=EDITOR
       Editor to fallback to if the server is not running
       If EDITOR is the empty string, start Emacs in daemon
       mode and try connecting again

Emacs is very slow to start. Especially once you have a few extensions and addons.

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.

> Emacs does an “unexec” operation to save its entire memory map to disk so its startup looks faster.

The changes Atom is looking at regarding user-side snapshots seems conceptually similar.

This really scares me because the emacs unexec operation has had a ton of safety related bugs.

Also, it’s a portability PITA, and it can be a serious impediment to bringing new developers on-board. Emacs is looking (in the long-term, serious project sense) to replace or remove dumping and unexec if it can.

Emacs doesn't offer a fraction of the graphical flexibility that Atom does. How would you do any of the below?

https://benmccormick.org/2016/01/11/the-most-interesting-ato...

The only one of those I'm not sure on is the expose one. The rest seem like they already exist in emacs.

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.

Forgive me for being skeptical. Where is this git-time-machine equivalent?

What's the point of the graphics in git-time-machine? The bubble plot seems less useful to me than a readable log. If it were useful there would probably be an equivalent findable from https://www.emacswiki.org/emacs/Magit

The question isn't "do I like these extensions?" It's "does Emacs let you build these extensions?" The Atom developers thought that providing this flexibility was important, which is at least in part why they used the technology they did.

The first question was "How would you do any of the below?" which is easier to answer when it's apparent what problem an extension is solving.

The second question was "Where is this git-time-machine equivalent?" which is easier to answer when one knows what a user is expected to accomplish by using it, specifically the graphical part.

I think the Atom developers are doing the right thing now by focusing on performance more than useless graphics. Right now I recommend vscode to other people even though I'll probably always use emacs myself.

https://github.com/pidu/git-timemachine

Magit

Apologies for the slow response.

I don't know on the actual charts, as I just don't use that sort of thing. Seeing anything git related and I think magit. Pretty much period. That is, I didn't see the chart.

You can do graphics in emacs, though. I typically just use it to show email and inline images for org-mode.

I did actually know Emacs can do images, as per the well-known opening screen[1], but it's very Web 1.0.

[1] https://i.stack.imgur.com/IOd6q.png

Ha, I forgot about the opening screen!

Calling it "web 1.0" seems amusingly critical. That said, taking it back to the question at hand, there doesn't seem to be a technical reason you can't do the images in the time machine thing. Most of my emails in gnus show graphically in a correct way. (Some of the more heavily formatted ones mess up, but usually not terribly so.)

For a better idea of what it can look like, enable LaTeX previewing inline in a buffer. Again, I'm usually in an org-mode buffer. And I confess I probably can't fight off a "web 1.0" argument. I have not gone for more modern UIs for some time. :( I grant it is a preference, but helm and similar UIs are much preferrable to me over what I typically see in the newer apps.

It wasn't a value judgement; it's 1.0 more web than my own editor ;).

These days. 20 years ago people hated on Emacs for the same reasons they hate on Atom now.

So we are getting a text editor with the features of a 20 years old application, using enough memory to run several Emacs instances.

The old joke was Emacs meant Eight Megs And Constantly Swapping.

Except now you get less functionality in 800M at least https://jinolabs.com/article/12232554/atom-editor-uses-more-...

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

Reply on news.ycombinator.com