1. 63
    1. 49

      I can’t believe Atom the syndication format outlived Atom the code editor.

      1. 16

        I mean, there are a lot more implementations of Atom the syndication format than of Atom the code editor. And, of course, data tends to outlive code in general.

        1. 6

          That’s true. The Atom spec is also relatively easy to implement. A cross-platform code editor, not so much.

    2. 48

      Never used Atom, but Tree-sitter originated there, and that’s in many editors now, so it will live on in a way. :)

      I find it very useful.

      1. 32

        Not to mention Electron!

        (For better or worse…)

        1. 18

          I only learned last year that it is called “Electron” b/c of its relation to “Atom” facepalm

    3. 36

      I owe Atom the decision of starting using Vim. I used it around 2015 and it crashed when opening big JSON files. Tired of it, looked for and editor which didn’t freeze my computer when dealing with big files and ended up learning Vim and I have not stopped since then (I guess I don’t know how to exit :^) )

      1. 3

        nvi is the next step

    4. 22

      Welp, we all saw this coming. Microsoft already has two editors (VS and VS Code), keeping a third around was unsustainable.

      (Though I am curious what are the reasons for continuing to use Atom instead of VS Code. By all accounts, as well as in my own experience, it’s far slower and clunkier than its counterparts.)

      EDIT: the founder of Atom, nathansobo, commented on the related HN and r/programming discussions that they are working on a new editor focused on speed and real-time collaboration, Zed.

      1. 18

        (Though I am curious what are the reasons for continuing to use Atom instead of VS Code. By all accounts, as well as in my own experience, it’s far slower and clunkier than its counterparts.)

        It’s slower, but depending on what features you heavily rely on, I’d honestly call VSCode the clunkier of the 2. For something I’m in and out of dozens of times a day, the Project-wide Find (and Find-and-Replace) experience in VSCode is terrible compared to Atom’s, and hasn’t seen significant improvement in years. There’s a couple of different “make VSCode’s search work like Atom/Sublime” plugins out there, but they’re mostly broken in my experience.

        Tons of other things are similar – the settings UI is a lot more pleasant in Atom than the weird way it works in VSCode. Atom just generally traded off a focus on speed in favor of a much more polished experience, generally.

        All that said, I saw the writing on the wall and went back to Sublime last year. It’s not as polished as Atom, but less of a jankfest than VSCode, and its search interface was what Atom’s was based on anyways. Bonus points for not setting my battery on fire by running an entire webbrowser just to draw text on a screen.

        1. 9

          Interesting to read this point of view. But a bit baffling, I should say. I used atom a little bit back in the day, but found it too hip and it was very sluggish, compared to gedit, grant, scribes, sublime, etc.

          When visual studio code came, it felt snappier, launched quicker, and personally I found it to be more pleasant to use. The UI was more focus on being functional than visually slick. Git integration was done just the way I like it. As well as other rminor but I portant details such as mru file switching. Built in terminal. Split screen.

          This is very much an opinion. But I find VSCode to be just a well designed and executed product. With pragmatism taking the central role. Kind of Microsoft showing that it is still capable of releasing useful software.

          1. 8

            How Microsoft manages the feature requests and bugs on the public vscode issue tracker never fails to impress me. There is a ton of professionalism shown towards a free and open source product. Product owners clearly communicate status and engage feedback.

          2. 5

            When visual studio code came, it felt snappier, launched quicker, and personally I found it to be more pleasant to use. The UI was more focus on being functional than visually slick.

            Very much different tastes. I booted it up after posting this, and still find it incredibly grating to use. They’ve screwed up the page “weight” or scrolling speed (on the Mac, at least), so that a sweep of my fingers on the trackpad when I’m scrolling a file is much, much faster than it is in any other app on the system (whereas scrolling in Sublime feels like scrolling in Safari feels like scrolling in the Terminal feels like, etc). It gives the whole thing a floaty, jittery feeling and screws up my years of scrolling muscle memory (cynically, I half wonder if they use a faster-than-system-scroll-speed to perpetuate the whole “VSCode is fast” marketing, because the rest of it, from the app startup to doing a search, is noticeably laggy)

            Like the preference pane’s spastic sidebar flying open and closed by itself as you scroll down the unbelievably long single preference page (which the floatyness of the scrolling in general exacerbates) it just behaves like nothing else on the system, and that makes the whole experience grating and weird compared to everything else. It’s like nails on a chalkboard, just a constant low-level stream of annoyances, to me.

            But if it’s your cup of tea, all power to you. Editor monocultures are the last thing we need.

            1. 6

              The thing I dislike the most about VSCode vs other editors is that it uses the Microsoft method of text selection. So if you hover over a character and click + drag the cursor, it won’t highlight the character that you are hovering over. Whereas in a macOS text field/editor it does.

              So in VSCode when I am forced to use it, I tend to miss-select a bunch of text all the time making it an extremely frustrating experience.

              The same issue exists in other interfaces that try to emulate some sort of text selection, the AWS console for example has a way to use AWS SSM to connect to a remote system and get a terminal in your browser. It has the same selection behavior.

              When applications don’t match the behavior of the OS they are running on it becomes an incredibly jarring experience.

              1. 1

                So if you hover over a character and click + drag the cursor, it won’t highlight the character that you are hovering over. Whereas in a macOS text field/editor it does.

                I agree that inconsistency is frustrating, but I cannot reproduce the inconsistency you describe in macOS 10.14 Mojave. Whether I’m using VS Code, TextEdit, or Finder, when I hover over a character, then click and drag, the selection starts from whichever side of the character the mouse cursor was closest to. I never see, for example, the selection start at the right side of an ‘O’ if I position my cursor on the left side of the ‘O’ before dragging.

            2. 2

              But if it’s your cup of tea, all power to you. Editor monocultures are the last thing we need.

              I agree 100%. I’m a long time vim user, but have switched to using both vscode and emacs. I interchange between the two, and am interested in newer projects too such as helix. All monocultures are bad and have awful side effects. That said, I think editors are personal enough that vscode will never fully dominate.

              I keep coming back to vscode for multiple reasons including: multiple selection, remote ssh sessions, and relatively simple configuration of everything including plugins. I’ve never noticed significant performance issues in vscode, while I have spent countless hours learning vim and emacs even to do basic configuration. That has taken away from development time. I don’t regret that time, but it is a trade off decision everyone has to make.

              If I may ask, what do you use?

              1. 1

                If I may ask, what do you use?

                I went back to Sublime when it seemed the writing was on the wall for Atom, and I’m currently pretty happy with it – much of the same basic features, and at least my battery life is a lot better. I’ve flirted with Emacs for years, and I’m pretty proficient with elisp, but I always hit a point where the constant mental friction of switching between “one-set-of-platform-wide-conventions-and-keystrokes” and “special-set-of-conventions-and-keystrokes-just-for-emacs” wears me out.

            3. 2

              That’s exactly my experience. There’s a very clear lag even while typing. I’m also encountering so many rendering bugs. For example, code warnings show up inline in a very long floating horizontal bar and it’s extremely difficult to scroll through it to read the entire message. The embedded terminals are full of display bugs and characters suddenly start flying all over the place while I type for no obvious reason.

              What I found really impressive is the the ability to quickly launch a dev Docker container and do all of the work inside it. That’s the only reason I’m using it. It’s sad though that the core editing experience is so subpar compared to sublime, IntelliJ, Xcode and even TextEdit.

              Atom was just as bad though in my experience.

            4. 1

              Now that you mention it, you’re right, editors in VS Code do seem to scroll faster than other scrollable areas. I looked into this and found an existing bug report and a workaround.

              Bug report: After 1.66 update scroll speed is faster, submitted 2022-03-31


              Add this to your settings.json:

                // Adjust scroll sensitivity to match macOS-native scroll surfaces, by my estimation
                // These settings might become unnecessary after this scrolling speed bug is fixed: https://github.com/microsoft/vscode/issues/146403
                "editor.mouseWheelScrollSensitivity": 0.5,
                "workbench.list.mouseWheelScrollSensitivity": 0.5,
          3. 1

            I used atom a little bit back in the day, but found it too hip and it was very sluggish, compared to gedit, grant, scribes, sublime, etc.

            I think back in the day, it was very slugish. But because of those early fails, I still don’t want to touch VS Code, even though I know it’s everywhere. At $DAY_JOB we use IntelliJ so I use that after hours as well (yeah, yeah, I know, talk about slugishness - but the important parts are fast for me), and for quick and dirty stuff, I rather pick Sublime. But yeah, I don’t know where it’ll go in the future, I know I’ll keep my vim scripts up to date in any case.

      2. 4

        Muscle memory? I mean, if it still works for you, why incur switching costs?

      3. 2

        A reason to keep using Atom instead of VS Code could be the use of telemetry in the latter. Although I’m not sure if Atom lacks this ‘feature’.

        1. 2

          I’m not a VS Code fan, but just FYI Atom does have/had telemetry. If that’s something that bothers you also note there are builds of VS Code that do not (see vscodium).

    5. 18

      As Github’s post notes, Atom is the thing that gave us Electron. That’s going to be with us a long time.

      1. 37

        But other than that, Mrs. Lincoln, how was the play

        1. 15

          Know what’s cooler than pissing and moaning about Electron? Taking a web codebase and getting three desktop apps for cheap. I run a 2013 MBP and good Electron apps are fine. What the hell are people complaining about? Is this some sort of purity test?

          1. 11

            For me, personally, many Electron apps are quite sluggish and far less resource efficient than native apps (Discord, Skype, etc)

            1. 1

              There’s definitely good and bad electron apps. Slack, VS Code and Spotify are very snappy and do enough stuff to justify the extra memory usage, while Discord and Signal are absolute turds.

              At the end of the day the memory usage thing is a bit of a canard. I have a 2018 laptop with 16GB of RAM, regularly run Goland, PyCharm (multiple instances), Spotify, Slack, Firefox, Chrome, VS Code, Obsidian… and still have a few GB of RAM to spare.

              1. 2

                So in other words, running a bunch of Electron apps takes gigabytes upon gigabytes of memory and you’d be screwed if you had only 8GB.

          2. 9

            Doing something for cheap that degrades the user experience is cool for managers, but not for users. If good Electron apps run fine on a 2013 laptop, think of what bad Electron apps do on a 2008 laptop.

            1. 1

              I grew up in a developing country, and even I find it hard to shed a tear for those poor people using a laptop that is almost a decade and a half old.

              1. 3

                The slope of the Moore’s Law performance curve has leveled off significantly in the last ~10 years or so; the difference between a 2008 computer and a 2022 computer is a lot smaller than a 1994 computer and a 2008 computer. If it works well enough (or perhaps, if the only reason it wouldn’t work well enough is shitty, resource-gluttonous software), why spend money and create more e-waste replacing it?

          3. 3

            Maybe desktop applications are not desirable. Maybe Web applications are an anti-pattern. It’s not a purity test, but a realization that we made an architectural wrong turn.

            1. 3

              If you’re against desktop and web applications then are you for a new platform? How does it differ from the web beyond just being better somehow?

              1. 1

                Maybe the concept of “application” – the deliverable, the product, the artifact which is sold to consumers – is incorrect.

                At a minimum, we could imagine replacing the Web with something even more amenable to destroying copyright and empowering users of Free Software. A content-addressed system is one possible direction.

          4. 2

            Electron apps tend to crash my Wayland desktop if they’re not updated. They rarely are, like Discord’s Electron hasn’t been updated for ages.

            Sure there are always ways to skirt around the issue, but we have a lot of resources yet most of them are spent on apps that run worse. Often those apps use Electron.

            We shouldn’t have worse resource usage and waste of energy just because some managers think it’s cheap on the short run.

            1. 1

              Nobody’s forcing you to use those apps. Just take your money somewhere else and notify those managers that they are losing your business because they use electron.

              1. 6

                Pretty much everyone is forcing me to use Slack, though. To the point where it was actually a significant factor in finally deciding I had to buy a new computer a couple years ago, with as much RAM as I could fit in it so that Slack didn’t make the fan practically lift it off the desk. Yeah there’s a web client but it doesn’t have all the integrations and blah blah. And I’d say 90% of the companies & projects I’ve worked with & on in the last 3-4 years have required me to use it, no matter how much I don’t like it.

              2. 6

                I am forced to use Discord if I want the community around my games to thrive.

                I’m locked in to these systems, that’s the whole point of making them like this.

                Same with Slack, but for work.

                Edit: Not to forget all my friends who use discord, and good luck trying tp convince them to use any alternatives.

          5. 2


        2. 0

          Sparks - So Tell Me Mrs. Lincoln Aside From That How Was The Play? (Official Audio) https://youtu.be/OuHGmtdJrDM?list=OLAK5uy_ntUoHXUt38rtp3L91dpdq-n7l776TF0nE

      2. 1

        Nodewebkit existed and was a big deal before that. Electron is not the breakthrough piece of softtware many are assuming it is.

        1. 2

          As did Microsoft’s HTA in 1998, but in the end, it was Electron that got mass adoption.

    6. 7

      Atom deserves credit for, as far as I know, kicking off a new generation of editors – Sublime, VS Code and others. But in my little experience with it, it never really was better than its successors.

      (Actually upon investigation, Sublime started significantly earlier than Atom. I only ever heard about it because of people talking about Atom though…)

      1. 63

        Sublime predates Atom, and they’re all to some extent part of a family tree of user interface ideas that originated with TextMate (Sublime caught on as, essentially, cross-platform TextMate when TextMate was popular & Mac-only).

        1. 2

          Thanks, I don’t know much about TextMate so it’s nice to learn about the underlying lineage. <3

    7. 6

      I’m grateful they announced this rather than just letting it die in ignominy. It has been getting more and more decrepit for some time and holding back the Electron ecosystem for some time. The ambiguity about whether or not anything was going to get fixed or updating was worse than just knowing there won’t be a future for it.

      I was never a user myself (neovimer), but it has been my go-to recommendation for non-programmers needing to hack on my projects for a while now. It served that purpose well for many years, but the lack of maintenance has been showing through and I’ve found myself writing hacks to help people I support work around it’s problems.

      1. 2

        I can understand using it if you’re familiar with it, but I’m curious what drove you to keep recommending it to newcomers instead of switching to the very similar but better maintained vscode?

        1. 7

          Because the UI is much less intimidating out of the gate and as far as keeping non-programmers comfortable without understanding what they are looking at it was easy to configure for use in advanced projects while keeping the UI to a minimum. VSCode is conceptually very similar but presents a lot more complexity within easy reach out of the box.

          Secondarily, I’m familiar with walking people through setup of the editor and relevant plugins they would need for the projects I manage—projects coordinated between a handful of programmers and a whole host of content authors (think: writers, translators, copy-editors, etc. working with Markdown in Git repos). Of course I’ll be looking for and getting a workflow going for them in some other editor now which is quite a project for me, but as I said it is at least nice to know that’s the way this is headed.

    8. 2

      I think one of the stand-out features of Atom was Teletype. Apparently some of the devs that worked on Atom and Teletype are making another effort at a better collaborative editing experience, see zed.dev (on lobste.rs).

      1. 1

        Vscode has that these days with “liveshare”, we have encountered a few bugs (particularly with terminals, and undo), but it generally works well enough.

        1. 1

          Any way to use “liveshare” to pair-program across editors, e.g. from VSCode to NeoVIM per this question? I’ve been looking for a way for me to stay in NeoVIM and let other folks follow along and chime in via a GUI editor for a while. So far the quest has been elusive.

          1. 1

            Strictly speaking I think the answer is yes, because it supports both VSCode and actual Visual Studio (I haven’t tried it with Visual Studio, but the internet tells me it works even cross editor).

            But I believe the entire extension is proprietary and I don’t think there is a way for anyone but microsoft to add support for another editor. I suspect it would be a non-trivial undertaking as well, because presumably they need to use some standardized CRDT for representing the buffer behind the scenes. The cursor position and text selection presumably also both need to use that CRDT (both because it shows them to the other users, and because other uses editing things need to not screw them up).

            One of the people (or maybe both? Not sure about the other) who I’ve been using this with uses vim keybindings in VSCode, and that works as well as vim keybindings in VSCode ever work. I’m sure that’s not the solution you are looking for, but it might be an acceptable workaround?

    9. 1

      When does JetBrains fleet arrive?

    10. 1

      watches another editor’s star rise, fall, and quietly extinguish from the comfort of his Emacs *scratch* buffer

      On a serious note, this is why I’m looking more and more to invest my time and effort in “forever tech”. I can name quite a few editors that have followed this trajectory, and are now (officially or effectively) dead, and all the while my continued gradual learning and improvement on Emacs continues to pay dividends.

    11. 0

      In many ways, this doesn’t come as a surprise.