34 ms·

The State of Atom's Performance

234 points by ropiku 9y ago

gaius 9y 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.
- rayiner 9y ago
  Emacs' display engine, input handling, etc., are written in C.
  - gaius 9y ago
    So what? There’s no reason the Atom team couldn’t optimise their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it. Their problem is not technical, it’s ideological
    - rayiner 9y ago
      That would impair the stated goal of "hackability."
      - mr_overalls 9y ago
        Emacs and vim are perhaps the most configurable and extensible editors/IDEs in existence. Fast doesn't mean unhackable.
    - ben336 9y ago
      If you read the post, that is mostly the work that they're describing.
    - thramp 9y ago
      > 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.
  - urda 9y ago
    Your point? Write slow javascript, get slow programs. It's not a crazy concept. Edit: typo
    - arianvanp 9y ago
      Emacs is written in Elisp which is a dynamic language just like JavaScript
      - ninjakeyboard 9y ago
        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)
      - camus2 9y ago
        > 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.
  - tomjakubowski 9y ago
    And Electron’s are written in C++, so I’m unsure what your point is.
    - rayiner 9y ago
      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-rendering.html 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-smooth-emacs/10155313440066102 https://www.facebook.com/notes/daniel-colascione/buttery-smo....
- ninjakeyboard 9y ago
  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.
  - hsitz 9y ago
    > 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-like-my-vim-setup/ 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.
    - michaelsbradley 9y ago
      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
    - deleted 9y ago
      [deleted]
- valarauca1 9y ago
  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.
  - dragonwriter 9y ago
    > 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.
    - valarauca1 9y ago
      This really scares me because the emacs unexec operation has had a ton of safety related bugs.
      - c256 9y ago
        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.
- Veedrac 9y ago
  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-atom-packages-ive-found-so-far/ https://benmccormick.org/2016/01/11/the-most-interesting-ato...
  - taeric 9y ago
    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.
    - Veedrac 9y ago
      Forgive me for being skeptical. Where is this git-time-machine equivalent?
      - brlewis 9y ago
        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 https://www.emacswiki.org/emacs/Magit
        Veedrac 9y ago
        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.
        brlewis 9y ago
        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.
- mr_toad 9y ago
  These days. 20 years ago people hated on Emacs for the same reasons they hate on Atom now.
  - pjmlp 9y ago
    So we are getting a text editor with the features of a 20 years old application, using enough memory to run several Emacs instances.
    - gaius 9y ago
      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-than-800-megabytes-for-one-file https://jinolabs.com/article/12232554/atom-editor-uses-more-...
ParkerK 9y 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
- disease 9y ago
  I found it strange that they mention Vim and Sublime Text without mentioning VS Code anywhere.
  - hateduser2 9y ago
    Vim and sublime aren’t their competitor while vs code is.
  - rk06 9y ago
    most of their fans will switch to VS Code if they found it, not so for ST and Vim
- blueline 9y ago
  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.
  - stupidcar 9y ago
    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 https://github.com/Microsoft/vscode
    - blueline 9y ago
      whoops, maybe I've heard wrong then.
qaq 9y ago
One more big project in the Rust portfolio :)
qaq 9y ago
I think unless there is some drastic change VSCode is going to dominate in this space.
- txsh 9y ago
  A lot of Microsoft cheerleading/astroturfing on Hacker News these days.
  - Lev1a 9y ago
    Even I (as someone who has a profound hatred for MS and their business practices) have to admit that VSCode is vastly superior to Atom, which is why I have used the former instead of the latter for a long time.
    - gt_ 9y ago
      Weird question, I know, because I use VS Code as well, every day for about 6 months and love it, but, I’ve never used these other popular editors. What makes VS Code so much better? I chose it because it had some integration with DCC apps I use use, and I like the GUI and general simplicity. What other reasons do people have for loving it?
      - maskedSlacker 9y ago
        Relative to Atom, which I left for VS Code: Code is faster and lighter, just as extensible. Better git integration and code analysis, even for Javascript (I finally understand what devs from other languages were talking about!). My workflow is just smoother for everything except Clojure and system admin (but I use emacs for those, atom isn't any better there).
        eropple 9y ago
        VS Code was my first not-Sublime, not-vim editor, but...I really, really missed my four-up display with four editors in a square configuration. I went to Atom because of that and because of VS Code's inability to keep a pane open even with no tabs (just because nothing's in it doesn't mean I want it closed).
Waterluvian 9y ago
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.
- joshmarlow 9y 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 9y 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.
    - jkmcf 9y ago
      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.
      - vog 9y ago
        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.)
anfilt 9y 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 9y ago
  Megabytes, really? “640K ought to be enough for anybody!”
- quantummkv 9y 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.
ninjakeyboard 9y 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.
- Vekz 9y ago
  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".
  - xemdetia 9y ago
    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/ 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.
Dowwie 9y 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 9y 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 9y ago
huh, fun timing on this one. I finally got fed up with atom's performance and switched over to VSCode this morning.
consto 9y 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.
nkkollaw 9y 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).
- mikestew 9y ago
  Memory usage? Sure, but as developers we probably have GB and GB sitting there GB and GB which I had hoped to use for running an entirely other operating system, and all of its apps, in a VM, not run a goddamned text editor. And that’s what annoys me about the “so what?”s. Start up time? Even just an update that requires a restart will make me wonder “I’m in the middle of something, how badly do I want this?” Resource hungry? See above, I have those resources for other stuff, not your piggish version of Notepad. A lot of these things can be excused for an OS, a database, crypto currency worker, but NOT AN EDITOR. But even if I were more tolerant, as you point out the general use case has been abysmal in my experience. If this kind of thing is what you want, I fail to see why one wouldn’t just use VS Code.
  - nkkollaw 9y ago
    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).
joehewitt 9y 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!
- dawnerd 9y ago
  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)
- woolvalley 9y ago
  There is also time to open new files as a subset of startup. Atom is significantly slower on large files than sublime.
- BugsJustFindMe 9y ago
  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.
  - joehewitt 9y ago
    > 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.
    - BugsJustFindMe 9y ago
      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.
rulusidaze 9y ago
And it's still impossible to drag-and-drop files into two separate windows... https://github.com/atom/atom/issues/13558 https://github.com/atom/atom/issues/13558
oblio 9y ago
They should just hire Federico Mena-Quintero: https://people.gnome.org/~federico/index.html#performance-articles https://people.gnome.org/~federico/index.html#performance-ar... :) The guy is amazing.
- audidude 9y 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 https://wiki.gnome.org/Apps/Builder
dchuk 9y 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 9y ago
  My guess is that they can't challenge those assumptions since they'd break backwards compatibility for plugins.
  - bronson 9y 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?
    - dchuk 9y ago
      Correct. Don't get a better whip for your buggy, get a car sort of thing.
tony 9y ago
Here's a cool gem: https://github.com/atom/watcher https://github.com/atom/watcher There are nice possibilities for this project, it could be abstracted out to work with FreeBSD and stuff. Grunt/gulp/etc. watch features may be able to utilize it in library form. For a similar project, check out entr(1): http://entrproject.org/ http://entrproject.org/ I'm a full time VIM user, but I'm happy and glad anytime I see VSCode/Atom/etc win. I see it as a great editor for the sake of having one to recommend. Cross-platform, free, active plugin ecosystems.
- cstrahan 9y ago
  If you think those are great, check out Facebook’s watchman: https://facebook.github.io/watchman/ https://facebook.github.io/watchman/ It’s a cross platform file monitoring daemon with a json (and bser) querying API, with support for opaque cursors so you can poll for changes since the last time you checked.
squant0 9y 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 9y 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).
desertrider12 9y ago
At this point, they would have saved themselves time by implementing it in C from the beginning.
- romanovcode 9y ago
  Not that easy to make it work with all 3 OS.
  - sydd 9y ago
    Not that hard nowadays, just use something like SDL to do the heavy lifting.
    - romanovcode 9y ago
      If it would be so easy as you paint it there would be lot more native applications. Unfortunately you can count them using your fingers.
      - veli_joza 9y ago
        Just want to point out that SDL implementation would be native as in 'not running on top of VM', but not native as in 'good citizen of host OS'. It would use non-standard widgets, likely would have problems with keyboard shortcuts, clipboard handling, drag & drop integration and window resizing. Depends how much time devs spend re-implementing stuff that's already supported by OS.
        boterock 9y ago
        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)
  - desertrider12 9y 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.
valarauca1 9y 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 9y 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)
stratigos 9y 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.
bjornlouser 9y 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 https://github.com/nodejs/node/issues/14917
tbirrell 9y ago
Okay... But can it handle mounted directories yet?
tebruno99 9y ago
1.6G to .6G memory reduction is great. It’s a shame that most editors use 4-50mb
- oblio 9y 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 9y 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 9y ago
  When loading a hello.c both Emacs and Sublime almost breaks the 50 MB barrier with default settings, but does that really matter?
shaki-dora 9y 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 9y 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 9y 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
- draw_down 9y ago
jamesmcintyre 9y 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!
- GreenStodd 9y ago
  Just like with every forum, circle jerks reign supreme
  - deleted 9y ago
    [deleted]
- natecavanaugh 9y 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.
tuanh1805 9y 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') }) }
FascinatedBox 9y ago
Anyone know what tool/script they're using to measure memory usage?
vemv 9y 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!
ConcernedCoder 9y 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=KT9RGX 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.
ExactoKnight 9y 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 9y 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 9y 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/ 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.

234 points by ropiku 9y 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.

rayiner 9y ago
Emacs' display engine, input handling, etc., are written in C.
- gaius 9y ago
  So what? There’s no reason the Atom team couldn’t optimise their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it. Their problem is not technical, it’s ideological
  - rayiner 9y ago
    That would impair the stated goal of "hackability."
    - mr_overalls 9y ago
      Emacs and vim are perhaps the most configurable and extensible editors/IDEs in existence. Fast doesn't mean unhackable.
  - ben336 9y ago
    If you read the post, that is mostly the work that they're describing.
  - thramp 9y ago
    > 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.
- urda 9y ago
  Your point? Write slow javascript, get slow programs. It's not a crazy concept. Edit: typo
  - arianvanp 9y ago
    Emacs is written in Elisp which is a dynamic language just like JavaScript
    - ninjakeyboard 9y ago
      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)
    - camus2 9y ago
      > 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.
- tomjakubowski 9y ago
  And Electron’s are written in C++, so I’m unsure what your point is.
  - rayiner 9y ago
    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-rendering.html 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-smooth-emacs/10155313440066102 https://www.facebook.com/notes/daniel-colascione/buttery-smo....
ninjakeyboard 9y ago
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.
- hsitz 9y ago
  > 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-like-my-vim-setup/ 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.
  - michaelsbradley 9y ago
    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
  - deleted 9y ago
    [deleted]
valarauca1 9y ago
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.
- dragonwriter 9y ago
  > 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.
  - valarauca1 9y ago
    This really scares me because the emacs unexec operation has had a ton of safety related bugs.
    - c256 9y ago
      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.
Veedrac 9y ago
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-atom-packages-ive-found-so-far/ https://benmccormick.org/2016/01/11/the-most-interesting-ato...
- taeric 9y ago
  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.
  - Veedrac 9y ago
    Forgive me for being skeptical. Where is this git-time-machine equivalent?
    - brlewis 9y ago
      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 https://www.emacswiki.org/emacs/Magit
      - Veedrac 9y ago
        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.
        brlewis 9y ago
        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.
mr_toad 9y ago
These days. 20 years ago people hated on Emacs for the same reasons they hate on Atom now.
- pjmlp 9y ago
  So we are getting a text editor with the features of a 20 years old application, using enough memory to run several Emacs instances.
  - gaius 9y ago
    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-than-800-megabytes-for-one-file https://jinolabs.com/article/12232554/atom-editor-uses-more-...

ParkerK 9y 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

disease 9y ago
I found it strange that they mention Vim and Sublime Text without mentioning VS Code anywhere.
- hateduser2 9y ago
  Vim and sublime aren’t their competitor while vs code is.
- rk06 9y ago
  most of their fans will switch to VS Code if they found it, not so for ST and Vim
blueline 9y ago
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.
- stupidcar 9y ago
  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 https://github.com/Microsoft/vscode
  - blueline 9y ago
    whoops, maybe I've heard wrong then.

qaq 9y ago

One more big project in the Rust portfolio :)

qaq 9y ago

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

txsh 9y ago
A lot of Microsoft cheerleading/astroturfing on Hacker News these days.
- Lev1a 9y ago
  Even I (as someone who has a profound hatred for MS and their business practices) have to admit that VSCode is vastly superior to Atom, which is why I have used the former instead of the latter for a long time.
  - gt_ 9y ago
    Weird question, I know, because I use VS Code as well, every day for about 6 months and love it, but, I’ve never used these other popular editors. What makes VS Code so much better? I chose it because it had some integration with DCC apps I use use, and I like the GUI and general simplicity. What other reasons do people have for loving it?
    - maskedSlacker 9y ago
      Relative to Atom, which I left for VS Code: Code is faster and lighter, just as extensible. Better git integration and code analysis, even for Javascript (I finally understand what devs from other languages were talking about!). My workflow is just smoother for everything except Clojure and system admin (but I use emacs for those, atom isn't any better there).
      - eropple 9y ago
        VS Code was my first not-Sublime, not-vim editor, but...I really, really missed my four-up display with four editors in a square configuration. I went to Atom because of that and because of VS Code's inability to keep a pane open even with no tabs (just because nothing's in it doesn't mean I want it closed).

Waterluvian 9y ago

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.

joshmarlow 9y 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 9y 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.
  - jkmcf 9y ago
    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.
    - vog 9y ago
      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.)

anfilt 9y 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 9y ago
Megabytes, really? “640K ought to be enough for anybody!”
quantummkv 9y 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.

ninjakeyboard 9y 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.

Vekz 9y ago
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".
- xemdetia 9y ago
  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/ 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.

Dowwie 9y 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 9y 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 9y ago

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

consto 9y 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.

nkkollaw 9y 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).

mikestew 9y ago
Memory usage? Sure, but as developers we probably have GB and GB sitting there GB and GB which I had hoped to use for running an entirely other operating system, and all of its apps, in a VM, not run a goddamned text editor. And that’s what annoys me about the “so what?”s. Start up time? Even just an update that requires a restart will make me wonder “I’m in the middle of something, how badly do I want this?” Resource hungry? See above, I have those resources for other stuff, not your piggish version of Notepad. A lot of these things can be excused for an OS, a database, crypto currency worker, but NOT AN EDITOR. But even if I were more tolerant, as you point out the general use case has been abysmal in my experience. If this kind of thing is what you want, I fail to see why one wouldn’t just use VS Code.
- nkkollaw 9y ago
  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).

joehewitt 9y 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!

dawnerd 9y ago
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)
woolvalley 9y ago
There is also time to open new files as a subset of startup. Atom is significantly slower on large files than sublime.
BugsJustFindMe 9y ago
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.
- joehewitt 9y ago
  > 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.
  - BugsJustFindMe 9y ago
    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.

rulusidaze 9y ago

And it's still impossible to drag-and-drop files into two separate windows... https://github.com/atom/atom/issues/13558 https://github.com/atom/atom/issues/13558

oblio 9y ago

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

audidude 9y 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 https://wiki.gnome.org/Apps/Builder

dchuk 9y 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 9y ago
My guess is that they can't challenge those assumptions since they'd break backwards compatibility for plugins.
- bronson 9y 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?
  - dchuk 9y ago
    Correct. Don't get a better whip for your buggy, get a car sort of thing.

tony 9y ago

Here's a cool gem: https://github.com/atom/watcher https://github.com/atom/watcher There are nice possibilities for this project, it could be abstracted out to work with FreeBSD and stuff. Grunt/gulp/etc. watch features may be able to utilize it in library form. For a similar project, check out entr(1): http://entrproject.org/ http://entrproject.org/ I'm a full time VIM user, but I'm happy and glad anytime I see VSCode/Atom/etc win. I see it as a great editor for the sake of having one to recommend. Cross-platform, free, active plugin ecosystems.

cstrahan 9y ago
If you think those are great, check out Facebook’s watchman: https://facebook.github.io/watchman/ https://facebook.github.io/watchman/ It’s a cross platform file monitoring daemon with a json (and bser) querying API, with support for opaque cursors so you can poll for changes since the last time you checked.

squant0 9y 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 9y 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).

desertrider12 9y ago

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

romanovcode 9y ago
Not that easy to make it work with all 3 OS.
- sydd 9y ago
  Not that hard nowadays, just use something like SDL to do the heavy lifting.
  - romanovcode 9y ago
    If it would be so easy as you paint it there would be lot more native applications. Unfortunately you can count them using your fingers.
    - veli_joza 9y ago
      Just want to point out that SDL implementation would be native as in 'not running on top of VM', but not native as in 'good citizen of host OS'. It would use non-standard widgets, likely would have problems with keyboard shortcuts, clipboard handling, drag & drop integration and window resizing. Depends how much time devs spend re-implementing stuff that's already supported by OS.
      - boterock 9y ago
        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)
- desertrider12 9y 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.

valarauca1 9y 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 9y 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)

stratigos 9y 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.

bjornlouser 9y 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 https://github.com/nodejs/node/issues/14917

tbirrell 9y ago

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

tebruno99 9y ago

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

oblio 9y 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 9y 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 9y ago
When loading a hello.c both Emacs and Sublime almost breaks the 50 MB barrier with default settings, but does that really matter?

shaki-dora 9y 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 9y 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 9y 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
draw_down 9y ago

jamesmcintyre 9y 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!

GreenStodd 9y ago
Just like with every forum, circle jerks reign supreme
- deleted 9y ago
  [deleted]
natecavanaugh 9y 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.

tuanh1805 9y 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') }) }

FascinatedBox 9y ago

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

vemv 9y 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!

ConcernedCoder 9y 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=KT9RGX 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.

ExactoKnight 9y 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 9y 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 9y 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/ 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.