> Atom is so slow it's a sideshow. It also has the problem of jEdit and Komodo, not a native app so they greatly reduce battery life on laptops.
Granted I would expected it to be slower using an interpreted language and all but other than opening large files the only thing noticeably slower to me is start-up. That's it. The plug-in ecosystem got me to permanently switch to Atom and it's very fast. I also haven't noticed any battery issues yet as I still will frequently use my MacBook for sometimes most of a day before needing to charge.
I'm not sure if you were speaking from experience with Atom or just approximating but it's surprisingly good. I know I was extremely skeptical to the point of calling it a dumb idea to write an editor in the way they did but after they dumped react I don't notice any slowdowns.
I agree with you. The slower start compared to ST is not a problem for me and a lot of the other things atom provides for me are good enough positives for me to have switched to it and not looked back.
Can I ask what you mean with large files? I haven't tried Atom in a while but I recall it having issues with something as small as 2MB.
Granted, I typically use Sublime in a way that others probably do not...more for manipulating / viewing data than actual coding. Outside of HTML, JS & CSS, I tend to use IDEs for development (VS for C#, XCode for ObjC and Jetbrains for most everything else). Maybe Atom isn't meant for that type of use and it much more suited for use as something akin to an IDE.
All that being said, I have found nothing that compares to Sublime for simple data viewing / manipulation (regex)...it seems to have no issues with 100+ MB files where as I don't even know if Atom could open something that large.
> Can I ask what you mean with large files? I haven't tried Atom in a while but I recall it having issues with something as small as 2MB.
Since I only use Atom to write code I would consider anything over, say, 200kb a large file. Unless it's a log file I never open anything larger than that in Atom. A few MB usually isn't too bad but once I hit around 5MB it gets to be just too slow.
My usual goto for simple data viewing / manipulation (regex) is geany. I find it's search and replace to be a little friendly for me. Though I do miss some dialog keybinds that I can't seem to find anymore on Mac OSX (the ones for document only vs selection only vs entire session for substitutions).
>the only thing noticeably slower to me is start-up
That's a big pain point, if you switch between windows (e.g. browsers - including some tabs/incognito for testing etc.). After having used eclipse when I moved to ST 3/4 years ago. I realized what I was missing. Faster start time and switching is a must. I normally have 3/4 projects (i.e ST sessions open). And just using key board (ctrl-tab) switch between them, and its almost instantaneous.
I typically use it for coding Go, bit of C++ and web UI (javascript etc).
The fast feel is so good, that now, I think even if I need to start a Java project, I will try ST with some appropriate plugins.
I'm not sure I follow. Start-up time and switching time are two completely different things. In web browsers sure switching between tabs can slow down because they deallocate between them after some time but Atom doesn't do that. Switching is always instant in Atom because it's all kept in memory.
I typically have 4-5 Atom windows open all with multiple files open and each has always opened instantly when switching.
I do understand the difference between start-up time and switching time. I included the latter to tell about my experience with editors like eclipse (and other editors developed in Java).
Have not used Atom. Great for you, if you like it.
My point being, when I started to use ST (which has been coded in C++). It dawned on me, that most editors not coded in C/C++ (or coded in Java, which are the ones I used) are slow, mainly because of lots of extra memory usage. Using ST also brought back the memories of fast and responsive Vi(m) earlier. I recalled, even MS Visual C++ (which I believe is done in either C or C++), which I used before eclipse/etc was quite fast. Hence my submission. So now, I don't think I am going to like using a coding editor, which is done in any garbage collected language (basically any non C/C++ language). As a side note, when I tried to use the DartEditor for coding in Dart, after having tasted ST, I was thinking why did Dart team not make a simple ST plugin instead? I believe an editor could make a difference in adoption of a new language. In love with ST.
> Javascript isn't interpreted, it is dynamically typed, but there is a compilation process before any JS code even executes.
Being interpreted and dynamically typed are not mutually exclusive. Regardless I'm not going to get into a pedantic argument about what is or isn't an interpreted language because it's ridiculous. If you feel strongly about JavaScript not being an interpreted language, as per your personal definition of interpreted languages, then feel free to update the wikipedia article (https://en.wikipedia.org/wiki/Interpreted_language).
> The plugin system is great. But updating, searching, parsing, is very slow.
I haven't noticed. By the time I get to the point of needing a search function over a project (because in file is instant) it's not the fastest operation in any editor.
> Have you tried displaying the keybindings? It takes forever.
Yeah though I've never noticed any slow down in doing so (seems to open in less than a second every time I try it on my MacBook Air). Regardless keybindings is something I'd open once every 3 months-ish; so it could take 20 minutes to open for all I care as long as the editor itself is fast and improves my productivity, which at the moment it does (I previously used Sublime).
I move to whatever editor makes me more productive. I have no loyalty here. I tried Visual Studio Code which was pretty nice but I'm too used to tabs and had to move back to Atom.
Try putting a few base64 encoded images in a file and move your cursor. It doesn't work. Keep atom open for a week without turning your computer off. It crashes randomly. There are countless problems with slowness and lag that I have encountered when I leave the app in the background / foreground for a very long period (days to weeks). After trying to use atom for at least 6 months, I'm back to sublime.
You're opening files with base64 encoded images in them? That sounds like hell either way :D
Yeah I've opened maybe one or two files like that before. I honestly can't remember if there was an issue or not but like I said I would be shocked if I ever needed to open a file that's bigger than, say, 200kb in Atom. If I need to open a big file that's, say, logs or contains base64 encoded stuff in it then I use Sublime. Atom just isn't a good fit for opening large files.
Granted I would expected it to be slower using an interpreted language and all but other than opening large files the only thing noticeably slower to me is start-up. That's it. The plug-in ecosystem got me to permanently switch to Atom and it's very fast. I also haven't noticed any battery issues yet as I still will frequently use my MacBook for sometimes most of a day before needing to charge.
I'm not sure if you were speaking from experience with Atom or just approximating but it's surprisingly good. I know I was extremely skeptical to the point of calling it a dumb idea to write an editor in the way they did but after they dumped react I don't notice any slowdowns.