I'm a Sublime license holder, but I use Atom as much as I can, because the more open source can win, the better.
However, yesterday I was doing some complex regex's (porting a random sql dump file into a seeds.rb), and Atom kept dying, whereas Sublime was pretty much instantaneous.
I'm not doing the usual "Atom is slow" drum beating, but saying some undertones of the announcement make me worry a bit. I hear discussion of things like Electron and "social coding" as the future, and I'm hoping that means that no one considers 1.0 to equate to the core editing experience being finished. It's not, and I hope the Atom team continues to iterate before moving on to new features.
Being able to open files larger than 2MB isn't sexy, but it's necessary. Having to hard-kill my editor because the save dialog is trapped on my other full screen session that it won't let me get to deserves more than a "but it's open source" response.
tl;dr congrats team and your core users want the best editor possible over bells and whistles
However, as I understand it, the issue is not so much with raw size (although it does not help) as it is with long lines.
For instance, the following 161K file freezes completely Atom, to the point that you just have to close it: https://github.com/espadrine/aulx/blob/master/html/tokenizer...
It is too bad, as this was already fixed globally in existing web text editors such as CodeMirror. Given that it is used in Chrome and Firefox' DevTools, and that JS minification happens on the Web, it had to.
I just downloaded it and you are correct, it locks up. Its the really long line here: https://github.com/espadrine/aulx/blob/master/html/tokenizer...
If I open it in Sublime 3 I see that they don't bother to syntax highlight long lines. They just skip it.
It appears that Sublime Text 3's threshold is 16384 (2^14) characters. Longer lines are not highlighted. Works quite well to be honest.
The menu has no margins and no padding but, worse of all, everything is tiny. Note that the main text font is smaller than the i3 top bar (which is at the barely readable size).
HiDPI support is not something esoteric nowadays. Lots of hardware requires it, and Linux toolkits support it rather well (not perfect, but ok anyhow).
I fiddled with Atom's CSS enough to test drive it. It is ok for common tasks, albeit a bit sluggish (I come from vim...). I could live with that. What I can't live with is all manners of breakage my custom CSS introduced, so I can't yet do a one month run with the editor to kick the tires.
I'm pretty sure it's a limitation of the underlying webkit, as loading a file that big in the browser is typically a bad use case.
I'm using Sublime 2 on OS X and large files + regular expressions are generally a cause for pain.
Do you have any default settings changed like disabled document preview or similar?
The only thing I generally feel is a champ at regular expressions + insanely large files on OS X is TextWrangler/BBEdit. In fact, I keep TextWrangler around specifically for the large file excellence experience which I (currently) don't receive on Sublime Text 2.
I don't have issues with large files on OS X.
Major difference! Definitely sticking with 3!! Thank you :D
Extremely fast in comparison to 2.
As a vim/cli/linux user -- I'm trying to understand -- you were doing search-and-replace? As in what one (some would say a masochist) could do with sed/awk? And/or 's' in vim?
(Sed is in some ways more relevant as it works on streams, and so as long as you have the diskspace to store the edited copy, size shouldn't really matter. I suppose it might be possible to have long enough lines that sed chokes, but I've never had to deal with something like that...)
Seems off base to me too.
All in all I'd say the experience editing large files still completely sucks compared to every other editor I use.
Don't get me wrong, I still love and use Atom, but they really need to come up with a solution to this problem, because it's just ridiculous. The fact that I have to occasionally leave my text editor to edit certain text files is a huge black eye that many people won't put up with, and which I will eventually get tired of putting up with if they don't do something about it soon.
One thing I think they could do is take advantage of the fact that when you are editing a file that large, you don't expect to have a particularly good experience with the scrollbar. I don't open a file with 10 million lines and grab the scrollbar to get to the spot I'm looking for; it's just not practical. Over a certain size, they really don't need to have the entire buffer in memory at once, and maybe they don't even need a usable scrollbar so much as they need good relative navigation and search. It would be perfectly reasonable in my opinion to have a "large file mode" for the editor window that has subtly different behavior that makes it not so ridiculously heavy.
Opening up a decent sized development.log did cause it to throw random errors however.
I usually install software on my user folder on the work laptop, as I don't have enough priviledges. This time the installer worked, but why override the questions to the user, like install location, etc.? There's a standard for Windows installers, why did they ignore it? Not cool.
I agree that I didn't like the default shortcut and context menu entries, however.
Oh, come now. Even make install makes assumptions about default directories etc. The right to override is the correct level of control over target directories - people who care can make that call, and indeed will be looking for the opportunity. The rest of us would merely like to find our new piece of software in the start menu/spotlight/PATH.
Actually they have a point. But Windows and PCs are not as straightforward as that.
If you use Scoop, add the extras bucket using:
scoop bucket add extras
scoop install atom
They have their own version of Chromium called Electron. But I recommend nwjs instead, witch is also built on Chromium and nodejs. And lets you make packages that only include your source code, so that you don't have to download the "browser" for every app.
You probably want to include an "install" script that:
* Download and install nwjs if it doesn't exist
* Make the "package" open with nw.exe
* optionally: Create a shortcut to the "package" on the desktop
* optionally: Set a icon for the shortcut
It's also packing a full browser, don't forget that. And likely all sorts of assets.
I particularly don't care. I'm more interested in how it performs during use.
By the way, task manager indicates it's using less then half that of RAM, with a few tabs open.
It's super easy to hack on and contribute to.
1. Develop tool. It's small and fast and minimal! Woo!
2. It's easy to modify because it's so small! Woo!
3. Look, there's a budding ecosystem of packages! Woo! (Let's
not talk about the fact the packages exist precisely because
the original product wasn't big enough.)
4. Oh dear, some of them conflict, a lot of them suck. Well,
here's some winners, let's pull them into the core. Now the
base system is that much better! Woo!
5. Repeat 3 and 4 a few times.
6. Crap, this tool is all bloated and slow. I'm going to go
create a small, fast, minimalist solution!
See also: "minimalist web framework", "minimalist Linux distribution", "minimalist programming language".
First, whatever you don't use, it's not even loaded in memory.
Second, bloated is all about having tons of options you don't need or use. Not about adding stuff you DO need piecemeal.
Third, bloat is mostly a UI thing, not a "number of add-ons" or "too many lines of code" thing. Programs don't get slow because they are "bloated" with extra code (if it doesn't run, then it has 0 effect on their speed). They get slow because they are badly programmed (e.g. loading one big text file all at once in memory instead of having a paging system).
The availability of tens of thousands of packages hasn't made Emacs "bloated", much less Vim or ST. Or even installing those packages doesn't make those editors feel bloated.
Whereas something like Eclipse was bloated from the start -- because it was a very heavy design with tons of abstractions layers, ton of built-in options and visual clutter etc, created on a GCed language with frequent stops on larger codebases etc. That's even without any third party plugin added, just the Eclipse Java SE core packages.
... no? Hate to dismiss your entire message that way (I mean that seriously), but...
People appear to be assuming a great deal more universality than I could possibly have implied, since I don't believe it's a universal problem anyhow, and never addressed scope. It's just a cycle that definitely exists in some domains.
It's gotten to when I see something described as "minimal" I tend to just roll my eyes and move on. Especially when combined with accusations, veiled or otherwise, that something else is "bloated", which at this point I tend to just assume is a meaningless feeling word with no real technical content. Yes, that includes when used in the context of "cycle of bloat"; this is a cycle endlessly recurring, yet has very little technical content. Mature text editors are, to a first approximation, all the same. (Yeah, there's some differences, but, meh.)
For example I use vim, and when I tried Atom I threw on two Haskel add-ons and my system was unusable. Then I removed the add ons and my 7 year old desktop on OpenSUSE just lagged away. I than went to my other old desktop all in one and that lagged away just at typing (This was a month ago) and adding anything to Atom slowed down so much that typing was lagging let alone any feature.
What's an example in the wild of this "cycle of bloat" in which people complain about it?
Emacs? Yes. Absolutely. Emacs once stood, humorously, for “Eight Megabytes And Constantly Swapping”. That is a valid complaint that people have made.
First it was lean. Then it grew and became bloated. Then people complained. And then available resources grew so fast that it didn't matter.
I didn't say emacs is too bloated to use, so your entire comment is a little off base. I said people have complained about emacs getting bloated in this same way for the same reasons. And they have. Historical fact.
Atom exists because ST3 was seen to stagnate, ST3 exists because TextMate was seen to stagnate etc. They start as simple but incomplete tools that are moving fast and blah blah - its just the software circle of life.
In terms of performance, stability and extensions this doesn't even hold a candle to Eclipse Mars.
1. Small, fast and minimal.
2. Easy to create plugins.
3. Budding ecosystem and explosion of plugins.
4. Conflicts ensued and some plugins got pulled into the core project.
The cycle of bloat doesn't always take hold if your team is disciplined and dedicated to keeping it small. You simply can't expect to your 3.0 to be as small as your 1.0 because it's very unlikely you're going to know upfront how people are going to use your software.
Combining a DOM manipulation library with an AJAX library and a Promises/Deferred library is and has been a pain point for me.
Also some of those size reductions have been at the cost of features (in particular by reducing the target browser set)
Its a great project. I use it a lot but I'm not sure its a counterpoint to bloat.
You're missing my point. I'm not claiming jQuery is not bloated, what I'm claiming is jQuery hasn't bloated (grown) a lot since it was first introduced. It started out as a single one-stop-shop library to handle DOM manipulation, AJAX and event handling and the scope/size of the project hasn't really grown beyond that.
Even if it's not actually true (as you've said, it literally is not bloated wrt filesize) people still think it's true.
At what point does software become bloated? I disagree that you can approach measuiring size bloat with absolute file size as the only factor.
I rather tend to think of bloat in terms of comparing the solution to other options to achieve the same result. In that sense, if I use jQuery for something that I might as well use plain DOM for, e.g. waiting for the document to load fully before selecting an element to change its content, the level of bloat the additional 30k adds to do the same is ridiculous.
Of course, if you take into account the whole stack of software running from the bare metal up to your browser window, 30k might appear negligible, but when you have a few tabs open with sites that all load hundreds of kilobytes of badly generated CSS, JS frameworks and pictures, and the actual rendering and execution of these consume orders of magnitude more run-time memory, it all adds up.
If you have limited time use it, but you'll spend more time later trying to remove it again. Building and then marketing a library that lists jquery as a dependency is somewhat of a blight these days, isn't it?
Don't recall claiming everything is under the "cycle of bloat". The fact that I gave specific examples was a pretty big clue that it's not all equal.... and jQuery isn't in any of them, either.
Edit: Sorry, is there something wrong with my pointing out that I didn't ever claim the things being imputed to me?
I can make lists too, if that's all we're doing.
1. Get a cat.
2. Cat requires playtime or they ruin your stuff and can be annoying.
3. Repeat 1 and 2 a few times.
4. You are a crazy cat man.
Chrome advantages for me:
- install pages as apps (Mozilla prism isn't supported anymore)
Chrome disadvantages for me:
-Missing all the most useful plugins
But by 5 o' clock when I've got three windows with twenty tabs of docs / bugs / reproduction / etc. Chrome bears the weight much more gracefully.
Of course not. It's categories of software that have the cycle of bloat. I named three, by implication "text editors" are a fourth.
Based on the way people seem to be blinded by the word "bloat" naming specific examples would be seen as an attack, followed by vigorous defenses of how it's not "bloat", which, at least as far as I'm concerned, is a total waste of time because as you can see in other messages I consider the whole "bloat" concept a joke anyhow, so why stir up the conversation like that unnecessarily?
Naming the specific instances is irrelevant, because it's not about the specific instantiations. It's not the software, it's the cycle. Pretty much every text editor ever has started out as a "lean, fast" text editor. And then they grew. And then someone claimed that all the existing text editors are "bloated" and set out to make their own text editor.
Not Notepad. http://notepadconf.com
> .TXT: NoSQL before it was cool
> Advanced Notepad developer and VIM opponent.
> Hacking Notepad.exe : Using a hex editor to change the blue icon and more
> Workshop: Integrating Spell Checking Into Notepad. Attendees should bring a copy of Notepad, and a dictionary.
What I disagreed with was the way you characterized and described the growth of pluggable software. You might not have intended it, but a reasonable reader would have interpreted your post as a, "This is what happens to software with an extensible plugin system".
If I were to hazard a guess I'd say that people are finding your responses unnecessarily adversarial and pedantic. So the guy misinterpreted your comment as overly broad, you could try to understand his point and continue the conversation rather than simply "winning" by pointing out that you didn't say exactly what he implied.
FWIW I agree that the cycle exists. Especially in enterprise software, except there it's usually less about pulling in plugins and more about directly adding features to core to support more use cases/customer requests until the whole thing is a giant mess (in terms of UI, codebase, everything) and ripe for disruption by a "lightweight, fast-moving, focused" competitor.
So for what it's worth, I'm very unconvinced that "bloat" is the automatically-bad thing that whoever is saying #6 says it is. There are things that are just crappy amalgamations of whatever, sure, but there are also a lot of big things that solve hard problems, and part of the implication of the cycle is that every time a #6 pops up and starts a new project, (s)he is inevitably beginning on a journey of discovery in which (s)he will discover why the previous tool got big. Big problems require big solutions. And it turns out that "text editing" looks really simple, and gets really not simple really fast. Same for the other two things.
I've literally lost count of the minimalistic text editors with great plugin interfaces that have paraded by me at this point.
(And... uh... how can I put this delicately... writing a good web framework is actually a non-trivial exercise. The web is complicated to do it right. If you've got a 250-line web "framework", odds are what you've got is 250 lines that sorta kinda work as long as nobody tries to hack it and nobody cares about actual compliance with all of the implicit and explicit standards embedded in HTTP. It may be suitable for your blog, it may be suitable for a 3-call API, but it's probably not suitable for anywhere near as many things as you'd like. And it's probably brutally insecure somehow.)
Text editing is really simple. The problem is that plain text editors are mostly only used by coders. (Non-coders who want to write text use Word.) And coders want features like syntax coloring, autocompletion, split views, multi-file management, etc. Features that would be of no use to someone writing a quick email or jotting down a cake recipe. Basically, what coders want is a program that looks as simple and feels as lightweight as a plain text editor, but gives them many of the features of a full fledged IDE.
For your step 6, it just means disable all packages and add them back only as needed.
The amount you need to be able to do to just load a basically-plaintext webpage now is absurd.
I think the web has stabbed that one dead, though... ship a proper HTML5-compliant browser engine, and, well, you're already looking at a whackload of startup time and tons of functionality. The size of the chrome is hardly an afterthought nowadays. A really "minimal" browser can hardly browse the top-ten sites anymore.
(Wikipedia's still looking pretty good in Lynx, though... just checked.)
My all time favorite reply about bloat: "X is big because your needs are big" (in the article X = Mozilla).
Basic things like https://atom.io/packages/find-and-replace
Facebook's nuclide project replaces a bunch of core features like the tree-view and the quick file opener.
> let's pull them into the core
That doesn't actually happen. They may adopt a package or publish a more official version of a package, but all major functionality is in packages.
I can't access it, but I bet even my WIFI router, tv and PS4 have a vi somewhere laying around, ready to help with debugging in case a corresponding core developer comes around to take a look.
I'd love to promise I'll never do it again, but I'm tempted to try to draw the poison out, too. Bloat ought to be a technical concept, not a political one.
Might be time to work on some tutorials and examples to make Emacs easier to hack on and contribute to...
Have any experienced Emacs users found that Atom makes them more productive in any dimension? I want to like it but I can't see the light at the end of the tunnel.
Emacs has much more commands for simple text manipulation than any other editor (ofc, excluding Vim). No editor that I know of implements all the Emacs commands for even simple things. For example for marking and navigation in a text (mark-, backward-, forward-). Indentation and newline behavior, searching and replacing in a file (search- and replace-*; also occur-mode). And more.
I'm sure all editors will, sooner or later, get most or all of those, but using them right now would be inconvenient. I don't want to have to record macros to deal with such simple things!
And then of course is a matter of Emacs plugin ecosystem. It is enormous and includes some neat stuff, like Magit, Org, Helm, Undo-Tree, multiple cursors, Paredit, Minimap, Speedbar and so on. Some of those are "outside of scope" of the new editors, but some would be very welcome in them. I suspect that they will appear in time, but right now I wouldn't have access to them at all if I used some other, new editor. (By the way, in my experience as both Emacs and Vim user, these two are interchangeable in terms of available plugins. Emacs seems to have a little more of them, probably because Elisp sucks a little bit less than VimL)
No. Emacs is far and away superior. It doesn't have a flashy web UI, but it is better in every way that matters.
Random example from my user.el file:
(setq blink-cursor-interval 0.5)
But I just can't be bothered anymore.
Seems like Atom is having an easy time beating Emacs on this front, and I'll probably switch over for good the next time something breaks in my .emacs.d folder.
Go read the manual. I mean, I know it's not cool to read books, and manuals at that, but the Emacs Lisp and Emacs manuals (available in info format for viewing directly in Emacs, among other) are well written and there's a wealth of information there. Even relatively low-level stuff gets explained quite well. And also, try using the help system/apropos tool. It's great for finding functions and variables. Lastly, you can always issue "find-function" or "find-library" which will take you directly to the source code.
> With some trial and error, I could find out if `(setq cursor-color "White")` works.
Use iELM session for this (M-x ielm). You'll get Elisp REPL, where you can write expressions and it'll show you their values. In this case:
*** Eval error *** Symbol's value as variable is void: cursor-color
> Or see if `set-blink-cursor-interval` exists.
(symbol-function 'set-blink-cursor-interval) ;; (no, it doesn't)
> Or look up why `set-cursor-color` exists in the first place when surely it's more consistent to just modify a config variable.
Don't know why is is so, but you can possibly find some explanation in the source code. `set-cursor-color` is defined in /usr/local/share/emacs/25.0.50/lisp/frame.el.gz on my system on line 1223. You can get there with M-x find-function.
> Or find some best Emacs lisp practices online.
Does it really have to be online? There is a full book for this: "Writing GNU Emacs Extensions". It's old, but solid. [EDIT: and also https://www.gnu.org/software/emacs/manual/pdf/eintr.pdf]
> Or figure out why I could never get working my one attempt to write a custom function to scratch my own itch.
Sorry to break it to you, but if it's not working it's because you coded it wrong. All my defuns do work...
BTW, do you know that you can one-step Elisp code with a built-in debugger? Just find a defun, eval it via C-u C-M-x and you'll get breakpoint at the defun entry.
Don't think so. Atom is still a toy compared to Emacs (but awesome compared to almost everything else except for Vim).
However, it has enormous potential and, given enough momentum, could reach parity with Emacs.
For example: http://tullo.ch/articles/modern-emacs-setup/
- Cross-platform editing
- Built-in package manager
- Smart autocompletion
- File system browser
- Multiple panes
- Find and replace
Is it me, or most of these are so basic that of course any text editor would have at least this set from the start? Right, autocompletion came in several steps for Atom, but .. I have used Atom for a while and it seems to understate the real advantages over other editors, such as: it's a GitHub product!
Which brings me to the part where I couldn't stand Atom: I should be able to do any git operation strsight from Atom, no configuration files needed, with a default plugin! Instead, we are left with many community plugins, like git-diff and atomagit. I hope things will evolve in a way similar to autocomplete.
This pattern is also not uncommon. There are many high quality linux modules and distributions built on the linux kernel.
It is likely atom will take a similar architectural approach. Make it easy to build and add plugins and let the community shepherd them.
Atom is my favourite editor for coding in, and it just keeps getting better.
I introduced my team to it today (pre 1.0 release, this is a nice surprise) and they were surprised by how pleasant the experience was - just a few minor hiccups. We've tried a bunch of editors and usually stick with Sublime because it's easiest to use while pairing, but I think that will change now.
Sorry for the tough HN crowd, you can never please them.
Here's to Atom 2.0 <3
Can it be that we are both using old version of the editors (atom for you and vsCode for me)? Else it seems strange this difference of behaviors
"Initially developed for GitHub's Atom editor"
So what are we talking about?
OTOH (also in my experience), Atom is somewhat Eclipse-esque (though admittedly not nearly as bad as Eclipse) in that the performance problems it has at scale cannot really be solved by throwing more hardware at it... whether you are on a relatively low-end laptop or a high end pro workstation with a 3ghz CPU and dozens of gigabytes of memory, if you open just a few big (>2 megabyte) files in Atom you're pretty hosed.
Also! I was able to create the colorscheme of my dreams in about 15 minutes, thanks to to the dev tools integration.
The limitations feel very few, and as someone who spent a LOT of time getting my Vim environment exactly as I wanted it, switching over to Atom was a breeze as I went through my .vimrc trying to match functionality; most of it was already there.
One thing I wish they would implement (and I'm sure it will come with time) is the ability to fully navigate the file tree with the keyboard, similar to NERDTree. All you can do right now is arrow up and down, after toggling over.
I've heard its like Emacs -- and now I know what people are talking about!
If you have a lot of style settings in your vimrc, the ability to use an actual stylesheet (when combined with the native chromium dev tools) make tweaking the look and feel absolutely trivial.
The downsides are that it's comparatively slow. The vim keybinding emulation isn't great but I can now use it without getting frustrated using ^[ to get back to normal mode.
I still use Vim for most things but I do Clojure/Clojurescript in Emacs evil-mode, and Typescript in Atom.
Atom's installer is a huge download, and the editor is much slower ... It also consumes much more memory and written in coffeescript. Takes a long time to start up ... just a few things on the top of my head.
It's a great initiative though so that's already a good point.
Which, for Emacs, is not an issue at all. Leave the server running and all clients will open instantly whenever I ask.
E.g. I can't type '@', '\', and 'µ'. Yes, I can't write metadata annotations or escape some characters.
In the meantime however I recommend using this package https://atom.io/packages/keyboard-localization which has worked really well for me (german keyboard).
Perhaps such keyboards don't concern that many people?
Also, this was supposed to be fixed in 1.0. I don't know why they decided to release 1.0 prematurely.
Now I can `quote´ in annoying ways or more ‘proper’ ways. This is life changing.
It's also nifty to be able to type ¼ and ½
LiveScript is a pain with it :\
Personally I even prefer the German layout for programming, though I've met a lot of programmers who prefer the American layout because it requires less chords.
My new laptop has a weird keyboard that seems to be based on the US keyset with the right symbol key replaced with the ISO key you're referring to. In other words: angle brackets are right next to the space bar (left ctrl, symbol key, left alt, space bar, angle brackets, AltGr, Fn, right ctrl). Also the arrow keys are lodged in between that and the numpad. It's odd, but I have gotten used to it.
The only problem is finding an external keyboard with the same layout. I found that switching keyboard layouts is extremely bad for my productivity but I don't want to carry around an external keyboard everywhere I take my laptop.
The main reason to use this keyboard for me is the trackpoint - my hands never leave the home row (I have arrow keys and a num pad on layer 4, see http://neo-layout.org/ (mouse over the "Ebene 4" button).
This really does make it hard for me to user other machines, you're right about that (although every linux distro ships neo, and for windows there is a no-installation-required autohotkey-based executable). But I'm not using other machines enough to make any compromises there. 99% of the time I'm using my machines, and that's what I've optimised for.
Typing accented characters is far easier in Spanish with a Spanish layout, that we all grow up with. The software shouldn't just ignore half the planet on the basis of "use English".
I agree it's a pity.
EDIT: the blog post mentions support for Babel! http://blog.atom.io/2015/02/04/built-in-6to5.html
It's not that they've decided they're opposed to ES6, it's just that there's been no leadership in moving towards it. Which at this stage has left the language almost dead in the water.
It's just one extra barrier of entry for non-coffeescript developers. I personally thought about writing a simple plugin, went to the documentation and realized it was all in coffeescript with no JS option, and gave up. I simply don't have the mental capacity to learn another language that probably won't be around in 10 years.
CoffeeScript is a nice language, but I think it's reputation suffers from it's association with Ruby. Far too many CoffeeScript tutorials are aimed at Rails devs who don't want to learn new syntax.
Fair enough on the == operator, but it's another that I have honestly never needed or wanted.
Babel is part of a general movement towards unification. Babel out of the box has support for JSX and type annotations (which are already just defined in terms of extensions to JS). Google's AtScript has been redefined as an extension to TypeScript (which in turn seems to be moving towards redefining itself as an extension to JS). I think this is a far more productive development than everybody trying to create their own compiled-to-JS language from scratch.
(..and yes, its technically possible to do with plain js, but I challenge any of the 'but just use js' folk to link to a popular plugin, with a UI, that does)
I tell you what, you try it and tell me how it goes for you?
It's really not that simple.
Seriously, CofeeScript is tiny.
On the other hand, confusing both concepts is bad because it makes it harder to reason about scope, and it has been the cause of much confusion regarding closures in Python and Ruby.
(I jumped ship to babel though)
> The UI library is in coffee script; if you want use a UI for your plugin, youre pretty much stuck using it.
> (..and yes, its technically possible to do with plain js, but I challenge any of the 'but just use js' folk to link to a popular plugin, with a UI, that does)
The ease of finding and installing themes and plugins is unparalleled.
Considering trying it for a week or two as my daily driver (with vim mode, of course.)
However, one thing that stands out to me, the file size of Atom.app is 203MB!! How in the world can a text editor be that large? Compare that with MacVim, which is about 27MB.
edit: And the full WebStorm app is 293.5 MB
I wonder this too - it's a freakin text editor. A very cool text editor, but hundreds of megabytes?
More to the point it is suspicious that such a basic functionality as a text editor has so much weight without reusing things with other programs. If every program measures itself by the same standards of size, we will all run out of disk...