The State of Atom's Performance

The State of Atom's Performance(blog.atom.io)

234 points by ropiku 8 years ago | 283 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.

redwall_hp 8 years ago | |

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

styfle 8 years ago | | |

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.

joshmarlow 8 years ago | |

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.

beckler 8 years ago | | |

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.

smacktoward 8 years ago | |

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

Electron is popular because it lets you write desktop apps in JavaScript, and there are a lot of developers out there who know JavaScript. By going with Electron, those developers can build desktop apps without having to learn anything new. They can extend their existing skills into a new arena, without having to learn any new ones. Developers are always asked to turn products around as fast as they possibly can (and, um, also people are lazy), so this is a very powerful appeal.

This "I don't have to learn anything new" factor is literally the only thing Electron has going for it. Using any other alternative will result in applications that perform better, fit into their host environments more naturally, and generally work better than an Electron app will. But there are a lot of JavaScript developers out there, and any other alternative would require all those folks to learn a whole bunch of new stuff to get started -- new languages (C/C++, C#, Java, Python, etc.), new toolkits (UWP/Win32/Cocoa/whatever, Qt, WxWidgets, etc.), new programming paradigms, etc. etc. etc. Whereas with Electron they can pick it up and be productive in a couple of hours, which is a hugely appealing prospect.

Tools that let people leverage what they already know will always do better than those that require a whole bunch of learning up-front to use. Electron is just the latest example.

stupidcar 8 years ago | | |

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.

ebiester 8 years ago | | |

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

vvanders 8 years ago | | |

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

Waterluvian 8 years ago | | |

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.

sjellis 8 years ago | | |

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

dchuk 8 years ago | |

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

zimbatm 8 years ago | |

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.

pjmlp 8 years ago | | |

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.

rolypolypup 8 years ago | |

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.

jimbokun 8 years ago | | |

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

brlewis 8 years ago | |

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.

nkkollaw 8 years ago |

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

dchuk 8 years ago |

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

People tend to ignore the base cause/assumption and hone in only on the problems that stem from those base causes/assumptions. Sometimes that's unavoidable, but often it's at the very least a good thought experiment to back up even further along the decision chain and challenge the original ideas instead. "Think outside the problems" or something I guess. It's really just making sure that you're being as methodical/objective as possible.

Atom seems to have been built with a set of initial goals/assumptions that triggered a massive chain reaction of problems to solve. Rather than challenging those original goals/assumptions, a lot of engineering talent and time is being invested in essentially cleaning up these problems that were self-imposed.

oblio 8 years ago | |

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

bronson 8 years ago | | |

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?

consto 8 years ago |

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

bjornlouser 8 years ago |

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

shaki-dora 8 years ago |

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

Atom clearly offered something that struck a chord when it initially appeared. I remember having an idea, and implementing it as a plugin, all within a lazy Sunday afternoon. This allowed the ecosystem to flourish, and new ideas being extremely easy to at least prototype.

It also allowed unprecedented[0] access to almost everything.

The latter turned out to be somewhat of a curse, unfortunately. Because the wide-ranging access allowed extension authors, and their users, to shoot themselves in the foot: It often lead to performance degradation, instability, murky UIs etc. Such troubles would usually be attributed to Atom itself. This was the groundwork for the narrative to almost instantly flip when VSCode appeared.

VSCode itself took the lessons from Atom, which must make it even more painful to now see it glorified vis-a-vis Atom: Extensions have to work through tightly defined protocols, and are never run on the main threat. This works well to avoid performance issues and to keep the UI from disintegrating. But it is also a severe limitation on the freedom to experiment, which is why that extension I once tried my hand on could not possibly be build in VSCode (it renders block comments written in Markdown as HTML right in the source code, including images, diagrams, links etc.)

[0]: Yeah, I'm sure there's some other editor that did it before. But somehow Atom got it right with Javascript as the language, and maybe the UI and documentation steering people to actually try it.

gmueckl 8 years ago | |

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

GreenStodd 8 years ago | | |

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

notatoad 8 years ago | |

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

qaq 8 years ago |

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

ninjakeyboard 8 years ago |

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.

tony 8 years ago |

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.

cstrahan 8 years ago | |

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.

joehewitt 8 years ago |

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!

tebruno99 8 years ago |

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

oblio 8 years ago | |

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

flukus 8 years ago | | |

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?

emj 8 years ago | |

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

desertrider12 8 years ago |

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

tonyedgecombe 8 years ago | |

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

romanovcode 8 years ago | |

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

desertrider12 8 years ago | | |

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.

sydd 8 years ago | | |

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

qaq 8 years ago |

One more big project in the Rust portfolio :)

tuanh1805 8 years ago |

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

ConcernedCoder 8 years ago |

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.

vemv 8 years ago |

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

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

Best wishes!

squant0 8 years ago |

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

oblio 8 years ago | |

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

Dowwie 8 years ago |

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

nothrabannosir 8 years ago | |

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

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

notatoad 8 years ago |

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

ParkerK 8 years ago |

>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

ExactoKnight 8 years ago |

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

romanovcode 8 years ago | |

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

ExactoKnight 8 years ago | | |

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.

oblio 8 years ago |

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

The guy is amazing.

audidude 8 years ago | |

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

valarauca1 8 years ago |

Wait.

If your JavaScript is only going to execute in 1 version of the V8 engine forever why use JQuery?

Serious question. I’m not a huge JS Develoler but when I dabbled I was told JQuery was there to soften the differences between browsers.

acdha 8 years ago | |

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

1. For example, how many projects could basically use this for a significant fraction of their jQuery calls:

    let $$ = (selector, scope = document) => {
        return Array.from(scope.querySelectorAll(selector));
    };

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

anfilt 8 years ago |

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

bastijn 8 years ago | |

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

quantummkv 8 years ago | |

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.

stratigos 8 years ago |

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.

FascinatedBox 8 years ago |

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

rulusidaze 8 years ago |

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

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

jamesmcintyre 8 years ago |

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!

ploxiln 8 years ago | |

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.

yalph 8 years ago | | |

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

Khaine 8 years ago | |

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

Why would you build a text editor on top of a web browser engine? Who would think that is a good idea?. Of course it is not going to be performant, it is being used for something it was not designed for. On top of that, cross-platform apps built using the one stack are horrible. They never feel exactly like native apps.

If this was 20 years ago, atom would be built with java using swing. It would be just as slow and just as un-native. Java apps on the desktop are ridiculed for a reason. The only difference is that now they are using 'trendy' things.

I think blind Freddy could tell you that, yes you can build a text editor on top of a web browser, but performance, and usability will suck. That is why everyone is so cynical, because it is so obvious.

oblio 8 years ago | | |

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.

Vinnl 8 years ago | | |

The usual counterpoint: VSCode.

eagsalazar2 8 years ago | | |

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.

stupidcar 8 years ago | | |

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

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

cbm-vic-20 8 years ago | | |

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

rayiner 8 years ago | |

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

cududa 8 years ago | | |

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

natecavanaugh 8 years ago | |

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.

ExactoKnight 8 years ago | | |

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.

brennebeck 8 years ago | | |

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

aphextron 8 years ago | |

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

rubyn00bie 8 years ago | |

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.

subsection1h 8 years ago | | |

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

_d8fd 8 years ago | |

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

ExactoKnight 8 years ago | | |

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.

eagsalazar2 8 years ago | | |

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

emmelaich 8 years ago | |

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?

whatyoucantsay 8 years ago | |

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

andrewbinstock 8 years ago | | |

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.

sctb 8 years ago | | |

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

jejrjntkpou 8 years ago | | |

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

Avshalom 8 years ago | |

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

Anyone that knows JavaScript.

brennebeck 8 years ago | | |

Which is a very substantial population.

GreenStodd 8 years ago | |

Just like with every forum, circle jerks reign supreme

SkyLinx 8 years ago | |

Well said!

gaius 8 years ago |

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.

tbirrell 8 years ago |

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

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