Okay, so recently I wrote about the Atom editor and how the community took efforts to revive the editor after the sunset announcement from Microsoft.
By now, things have changed a little bit. There was some disagreement on how the project should be handled from the atom-community maintainers: few people that were on the leadership decided that we should make “graceful changes” – things that do not disrupt too much the editor, small PRs that can be reviewed, and lots of stability. And I actually agree – that’s the way a project should be handled!
Except there’s a big catch: for me, this only works when the project is alive. The Atom editor is dead, for better or for worse. It’s announced already, so there’s no way “graceful changes” will be able to keep the editor alive or even relevant than, for example, VSCode – even for people that want a lightweight alternative or have want a different approach on handling code.
There were other disagreements on the roadmap – for some people, they wanted Atom to have the same functionality that it have today. And, speaking for me, I don’t agree – I think there are functionalities on the the Atom editor that are simply too much: for example, native support for CoffeeScript and TypeScript. I firmly believe that all Atom/Pulsar plug-ins should be transpiled – and that’s not only because the editor should only run JavaScript, it because it’s more reliable that way (the native support can fail between different tooling, language versions, etc. As an example, Atom supports plug-ins written in CoffeeScript 1.12 – and the current version is 2.7.0). Also, if a plug-in is bundled in a single JavaScript file, it’s actually more efficient both in terms of memory and performance for the editor.
Atom is hackable, which means a single plugin in Atom can (and will!) use too much memory if there are too many files for example. As for me, I actually want to remove these “native supports” for these languages, but somehow keep the editor working – like, for example, adding the ability to transpile (and bundle) plug-ins “on the fly”, when you install that plug-in. Sure, more work needs to be done – like checking if it will still work if we bundle everything, changes on APM (even to the point of deciding if APM should be bundled inside the editor or keep it separate as it is today), etc.
If that’s doable, then no changes in the current plugins that Atom offers should be needed! But these are not “graceful changes” – are actually very aggressive ones. And these changes in functionality (and also the fact that the atom-community wanted to include more core packages, like the atom-ide family, and I would prefer to keep it as it is, maybe even includes fewer packages) made a clear how our approaches on how to handle the sunset differ.
And that’s when pulsar-edit was born. It’s a new GitHub organization that will track changes for the atom-community and try to merge back them into our own fork. Our fork will be focusing on making the changes that are needed for the editor to keep being relevant.
There were also other problems honestly – social ones. For some of us, it felt that a few of the maintainers and admins of atom-community were not really open to hear different approaches. We had problems to discuss the path forward, as it felt that the path was already written and it was up to us that to make it happen (like, for example, rebranding. There were some concerns about keeping the same name and a similar logo that were just dismissed).
And that is a big no in my list – this is not how I want a true hackable code editor to work. I want to discuss things with other maintainers, check what makes sense; if one of us want an aggressive change, back it up with benchmarks or tests, and real-world production case scenarios, and not just by “gut feeling” of a specific group of people. To be honest, “gut feeling” is actually not that easy to get rid of – sometimes, all things being equal, we have to rely on it. But I got into multiple discussions over discord and over PRs when I tried to change a point of view, just to get shunned by “No, that’s not how you do it”.
This was a mistake I made in the past – I trusted that “Microsoft’s Atom” would be the same as “the GitHub’ Atom” – that the original authors would still work on it, or a different group of people, or even few people that would talk with the community to keep the editor alive, that Microsoft would honor the project and/or the creators by keeping both VSCode and Atom; to be honest, I even was prepared for Atom to become more unstable, imagining it would become a “sandbox” or a “playground” for new functionalities in VSCode. Not even this happened – they simply let it wilt until almost everybody left, decided to archive the project – and now are letting the servers rot with lots of Internal Server Error‘s failures and SPAM attacks, even before the Sunset, to further prove the point that the editor is not needed, bury the project when it’s not even dead yet, and to make more people run away.
I will not make this same mistake again – I will not rely on “Specific Person’s Atom” – I want a true community driven, hackable text editor that’s visual and modern. Most of these things also exist in other editors, like Emacs and NeoVim – and I am/was actually a Vim user, but it does feels complicated to use, it feels dated, and hard to modernize. Emacs is more hackable, and people love it, but I actually feel that for people that “get” Emacs, it’s wonderful, and for people that “don’t get it” (like me) it always feel the community is saying “you’re doing it wrong”. It’s not really straightforward to just fire up the editor and start typing things, and if you want more, you just install a plug-in and do it.
Atom was actually the best of all worlds for me. And now Pulsar will be, if we’re able to keep it working on it.