Atom 1.25
blog.atom.io
blog.atom.io
switch( ) {
case:
break;
case:
break;
}
Good job Atom.
If you're interested in more details, there's also this talk from the developer behind tree-sitter (https://www.youtube.com/watch?v=a1rC79DHpmY), where he showcases how they could use tree-sitter to quickly parse entire multi-megabyte minified JS files to provide complete syntax highlighting for them that updates as you edit, and how the accuracy and usefulness of the actual syntax highlighting can improve over regex based implementations due to having access to the fully specified grammar of the language.
I think tree-sitter is also a game changer for extension development once it stabilizes and the APIs are opened up. Extensions like swackets will no longer have arbitrary performance constraints that break user experience (https://atom.io/packages/swackets), and it opens the door to a whole new set of intelligent extensions that understand the languages you write at a much deeper level that were previously unfeasible due to parsing performance, or required some external heavy-weight language server.
I really had hope when they introduced V8 Snapshots on 1.17, then I had exact same crash couple of days later. And memory management wasn't better. I was even thinking about to replace my mac, because I was running out of RAM just by having Atom + Firefox + iTerm with rails server and console running.
It's really annoying to have your editor, where you spend most of your day, your shortcuts, extensions, settings, theme, all got destroyed in a moment in the middle of the working day. And you have still have to keep working with fresh installation settings. Damn. Worse, although I'm aware of sync-settings, I keep forgetting syncing my settings as they are evolved with time and it still feels insecure to be in need of syncing stuff because you don't know when it will crash for the next time.
Looking at the issues, assuring that I did a good decision by moving away from it.
This one is still open: https://github.com/atom/atom/issues/12255
https://github.com/atom/atom/issues/14909 https://github.com/atom/atom/issues/14922 https://github.com/atom/atom/issues/15443
All joking aside, it would be a fascinating analysis; all the rationales for browser performance benchmarks apply here as well.
(And also, kudos to the Atom team for the new tree-sitter parser - very cool stuff!)
I timed (by hand using an app on my phone) the total time I spent "waiting" for Atom to launch over a full work week. It came to about 80 seconds.
80 seconds in chunks of like 10 seconds or so mostly at the start of my day. I have a shitload of plugins and my Atom instance loads significantly slower than my coworkers, but even so 80 seconds a week is nothing compared to the time savings that atom brings me.
Yes, it could be faster, but it won't materially improve my experience.
But it feels absolutely awful to have to wait 5 minutes to start doing something useful. Especially when its not necessary, and when you've got alternatives that start up instantaneously (ie basic vim install).
The problem is in that transition from 10ms wait to 10s wait; the difference is immense.
And of course, theres the idea that an order of magnitude difference isn't just an order of magnitude difference; it can enable entirely different paradigms and workflows. In the fashion that the shifts in web-capabilities correspond at least to a degree to the shift in network capabilities. Streaming doesn't make sense on a 10kb/s connection, but on 10mb/s the whole world changes
To be fair, the same happens when discussing OSes, languages, and frameworks.
Is it really that much better than Atom? I quite like Atom, but I started to use VS Code for Flutter development.
It’s the first editor I’ve used since the original TextMate that worked well straight out of the box, is easily configurable for 95% of customization needs, and has high-quality extensions that don’t feel like they’re all conflicting with one-another.
I don’t know if Atom has gotten any better in the past year, but it never quite felt right to me. Lack of polish and care, I guess. VS Code had me a convert from day one.
I’ve been recently using it with FB’s Nuclide, but that’s such a massive suite of plugins, it might as well be a considered a derivative of it. I can’t recommend Nuclide. It’s bloated, and breaks a bunch of behavior from vanilla Atom, but it is the only thing that seems to get remote editing right. I just wish someone would get that piece out of put it as it’s own plugin.
- http://blog.atom.io/2017/09/12/announcing-atom-ide.html
- http://blog.atom.io/2017/11/15/code-together-in-real-time-wi...
Still beta, though.
Remote editing is logging into a remote machine, and being able to manipulate the files there just as if they were stored locally. Nuclide gets this right https://nuclide.io/docs/features/remote/
Various sync plugins aren't reasonable because they want code in both places, which is a complete waste because you'll never run the local code. Alternatively, many of these require various per project config files which is just too much overhead.
The rmate-like plugins look interesting until you find out that there's no integration with the tree view, or any of the project like searching.
Some "solutions" that people point to are simply file transfer UIs, which is just misunderstanding the problem.
This thread really explains the problems with all of these approaches. https://discuss.atom.io/t/working-with-a-remote-server-throu... Sadly, only Nuclide does it right, but god is there a lot of shit with it.
I guess I'll have to go with sshfs, but that's also a bit awkward.
What's wrong with sshfs? That does it at the OS level and it then works for everything?
Also, you have to remember to mount and unmount the drive outside of the editor, (especially if you close your laptop for a while), whereas if the editor manages the connection, then it's transparent to your normal workflow.
Quite frankly, I don't think FB cares enough to break remote editing out of their extant project which they really really like. There's no benefit to them.
I like Atom's interface, but it's such a resource hog. So I will continue to stick with Sublime.
I don't see how this translates into general slowness for normal use cases
Even if it's locked in my OS's credential store, do I really want to trust a text editor with my passwords? Why not suggest the more secure option? How sure can I be that none of the atom plugins I use will try to steal it?
I work with about five languages just fine.
However, I am sick to death of its excessive memory consumption. This morning it was using 1.5 GB of memory.
It's a text editor for God's sake!
It may just be because I'm more familiar with it, or because I'm too lazy to set up VSCode and get the plugins for Rails dev.
I'm afraid my workstation only has room for one Electron-based monster(Slack).
Hopefully the Rust re-write improves things.
To clarify, I don't think there are any plans to rewrite all of Atom in Rust; the UI will likely always use Electron. They are just rewriting some of the more intensive backend libraries in Rust for performance.
(Someone correct me if I'm wrong.)