Hacker News new | comments | ask | show | jobs | submit login
Atom 1.0 (atom.io)
1096 points by mrbogle on June 25, 2015 | hide | past | web | favorite | 442 comments

Congrats to the team for reaching this important milestone.

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

I agree wholeheartedly with the sentiment.

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...

The reason is that the core syntax highlighter (https://atom.io/packages/language-javascript) is heavily unoptimized, and tries precomputing data for the whole line without considering that only the first 0.5k characters will probably be seen.

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.

> For instance, the following 161K file freezes completely Atom, to the point that you just have to close it:

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.

Issue filed:


I think you meant line 634, not 63. Also, pro-tip, always link to a specific file version when you're referencing a line because master will change:


thanks, it got accidentally chopped

> 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.

I concur. Congratulations to the team. The project seems to be going in the right direction. It's not up to 1.0 standards for me, though. I'm on Linux, on a last year's X1 Carbon. HiDPI display, at slightly over 200dpi. I'm greeted with this:


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.

lol, 2MB? I use emacs and hardly played with Atom. To me this sounds like you are complaining about a 20MB mp3 interfering with your audio player.

Yeah, it's a bit nuts. Sublime handles those files without batting an eye, and opens files that are hundreds of MB (and even multi-gig files) easily (it handles files that in the past I'd never open in a windowed text editor)

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 don't remember Winamp not able to play 20MB mp3, such a rip of entire album, since I started using it in 98.

I think that's the point of the comparison -- 20MB is really only the start of the heavier usecases people might want out of a music player, but an underdeveloped player might only be able to do, say, 2MB.

Sorry for side-jacking this comment - but which version of Sublime, may I ask, and what OS?

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.

Upgrading to Sublime 3 can't hurt...

I don't have issues with large files on OS X.

Is the beta stable enough to use regularly?

Yes, I would say it is quite stable. In fact, in the ST blog it says: "Sublime Text 3, while still technically in beta, is the recommended version of Sublime Text to use." [0]

[0]: http://www.sublimetext.com/blog/articles/sublime-text-3-buil...

Thanks :) I'll give it a whirl!


Major difference! Definitely sticking with 3!! Thank you :D

Extremely fast in comparison to 2.

Atom crashed and froze on me numerous times during this day of 1.0 release. ST3 'beta' has never crashed or frozen on me since it's been out.

I use the dev version (currently on the latest build 3092) for all of my editing, never had an issue. And if it should ever break, it's easy to download the next-older build and use that. Very satisfied.

Any update on this long-past inquiry of the future status of Sublime Text?


Since that post development has picked back up:


I had found that Sublime did pretty terribly with large files (not source), so I was back in in Emacs.

> I was doing some complex regex's (porting a random sql dump file into a seeds.rb)

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...)

I know it's off-topic, but is regex the best way to convert SQL into seeds.rb? I'm thinking of doing the same thing, but I figured I'd use Ruby or a gem. https://github.com/rroblak/seed_dump

This was a data dump from a previous development effort, and the Rails app was no longer connected to that database. Moreover, it was MySQL, not Postgresql, the new target. I probably could have stood up MySQL and used that gem to achieve the same result, but honestly, while the regex is at times a bit complex, it's straight-forward, since an insert's parenthetical list of values is very close to what you pass to Model.create. Thanks for the gem recommendation though, and hopefully it'll be a better solution the next time I encounter a similar situation.

"...now you have two problems"

Seems off base to me too.

I just tried it on a 14MB file to confirm, and Atom can open files larger than 2MB. (I also scrolled through the whole file just to make sure Atom wasn't cheating somehow, and it seemed to be working fine.)

I just tried it on a 35MB log file and it gave me an alert that said it was gonna be sluggish, then took about 20s to actually open the file I requested (I could navigate to other tabs in the meantime but there was no indication that anything was happening), and then once the file appeared, it took another 20s to become responsive. Searching for a string which appeared in the second line of the file took over 30s, probably because it was searching the entire file to highlight all matches, and all the while, it was completely unresponsive. Then when I tried to close the file, the entire editor hung and eventually gave me a "this tab is not responding" dialog. I clicked "wait" and it took another 10s and the window finally closed.

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.

Now try to do the same thing in Sublime 3. You can even try with ~2GB and it will be quick and responsive.

Just opened a ~800MB log file on Sublime Text 3 (running in OSX), wow, it's really fast and responsive.

Thanks - that must be new, as the last beta I can remember (within the last week or so) didn't crash, but tossed up a dialog saying it had a hard-limit. Now it just gives the the warning that it'll be unresponsive.

Opening up a decent sized development.log did cause it to throw random errors however.

I can open a 15MB log file, but my CPU usage skyrockets.

You're not trying to scale for millions of users. It's okay to let your CPU cook a bit.

Wow... just downloaded the windows installer version and it autoinstalled itself wherever it chose fit, without questioning, it installed shortcuts on the start menu, placed itself on an already bloated contextual menu on several file extensions as an Open option, instead on "Open with...", etc.

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 don't know if this has changed, but when I tried Atom and didn't like it, I discovered that there was no uninstaller. Hooray for deleting context menu entries by hand in the registry.

I was able to uninstall it from the Programs list and context menu entries are gone.

One of the first things I've noticed after trying out the new release, very annoying.

Thanks for the heads up, I was about to try Atom but I'll wait until this is fixed.

To be fair Chrome doesn't ask you either, at least on the storage location. It looks like Atom puts itself in APPDATA, which is the easiest place to install because you have known permissions and update strategies. I actually like this method.

I agree that I didn't like the default shortcut and context menu entries, however.

i also hate that part of chrome - i don't have a fast disk on my default C drive, and i want to move my apps to a separate disk. But chrome doesn't let you do that easily...why do product teams think they can make the best choice for the user, without giving a way out? For a normal user, they can just use a default, and it should be fine. But let me choose if i want to, god damn it!

Can't you create a symlink to another drive, and keep chrome on the same logical location?

This frustrates me to no end. I prefer to install my software in a certain location. Having it selected for me is not okay. Nor is giving me the option to override it.

> Nor is giving me the option to override it.

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.

It's optimizing the onboarding and install process to its bare minimum. I'm sure they go "Well you don't get a choice for OSX or mobile apps either, so why should you for windows"?

Actually they have a point. But Windows and PCs are not as straightforward as that.

You get a choice for OS X. You can put most apps wherever you want; just drag the .app "file" anywhere.

The context menu is the most annoying thing. I can delete the shortcuts no problem, however to delete the context menu it requires some registry fiddling.

Personally I think there is something to be said for skipping irrelevant questions. I don't care where a program installs to, I just want it to work. I want the developers to deal with that kind of detail so I don't have to worry about it.

See, for many, that is not an irrelevant question. Could be very important if you have multiple partitions/network drives specific for different purposes.

The question isn't irrelevant.

I have just pushed version 1.0 of Atom to the scoop-extras repository

If you use Scoop, add the extras bucket using:

    scoop bucket add extras
Then install atom

    scoop install atom
It will install it into your user folder. No privileges required.

I clicked the download button and noticed 70+ MB file. I thought to myself, why in the world a text editor needs to be so huge. And then I see your comment. I clicked on the Pause button on my download.

It comes with Chromium, that is basically a browser.

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.

Really? How is the app opened then without bundling Chromium? I built an app 4 months back and that was the only option.

You simply zip the files and rename to dot nw. Then the first time the user runs the file, the user needs to select "open with nw.exe".

ref: https://github.com/nwjs/nw.js/wiki/How-to-package-and-distri...

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
Or instruct the user on how to do it. Many files work that way, that you have to select a program to open it with, so the user probably already knows how to do it.

It isn't really, but I guess it's so that in the future, if more apps are built with nwjs, it's possible to just download the 'runtime' and then each program sees if its installed, then downloads it if needed.

That's what we have package managers that handle dependencies for. Hopefully, that decade-old feature will be the future on windows too.

Did you intend to run it in a potato? Even a raspberry pi would have no difficulty with that file size.

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.

The killer feature of Atom to me is the ease with which it can be extended (via packages) and the openness to community contribution on core features. That's not a knock against any other editor (some of which share similar characteristics in this regard) – it's just what draws me to Atom.

It's super easy to hack on and contribute to.

It's the Cycle of Bloat.

    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!
Repeat indefinitely.

See also: "minimalist web framework", "minimalist Linux distribution", "minimalist programming language".

Do people believe that having access to packages and add-ons makes an editor (or whatever else) "bloated and slow"?

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.

"Do people believe that having access to packages and add-ons makes an editor (or whatever else) "bloated and slow"?"

... 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.)

Well I hate to also semi-dismiss your message, BUT when certain add-ons are essential to using a tool like Atom it makes it slow and bloated.

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.

The parent did not say that plugins caused bloat, instead that resolving common problems with plugins (stability, quality, conflicts etc.) by pulling them into core is what causes bloat (slowness, complexity etc.) and that trying to resolve the tension between flaky plug-in based systems and bloated monolithic systems is cyclical.

Still: is anyone complaining of Emacs or Vim or ST3 being slow/complex because they have installed plugins to the core?

What's an example in the wild of this "cycle of bloat" in which people complain about it?

> Still: is anyone complaining of Emacs or Vim or ST3 being slow/complex because they have installed plugins to the core?

Emacs? Yes. Absolutely. Emacs once stood, humorously, for “Eight Megabytes And Constantly Swapping”. That is a valid complaint that people have made.

That comment would make sense in the 1990s when we had 32 MB of ram, but you probably haven't used it since then. I type `e` and I'm instantly in an emacs client frame running on top a server and using a modern package manager that loads plugins and different modes in on the fly. I restart and kill the entire server after editing my init.el file and it takes takes a few seconds. Emacs itself takes up so little of a memory footprint I don't even care about it. And do you seriously think that a text editor that is older than most people on HN would be wasteful about allocating resources?

> Emacs itself takes up so little of a memory footprint I don't even care about it

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.

Yes, it's quite easy to get vim to a point where it's mysteriously slow at mysterious times due to random plugins installed. The lack of async makes this all the easier since everything blocks UI to begin with.

If it is slow, use vim --startuptime to check for slow plugins on startup.

I can't speak for the parent but I would say the most commonly seen effect of complexity is stagnation. Change becomes harder, promised features take forever, the developers lose motivation and significant new releases grind to a halt.

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.

TextMate 2 actually tried to solve the stagnation problem by open-sourcing. It has worked quite well and updates became much more frequent. Still though, it doesn't feel as easy to extend as Atom or VIM.

Except that neither ST3 or TextMate were open source.

TextMate 2 is, thankfully. Although the point still stands; one editor I'd love to see take off but doubt is Vico, a modern "Vim-esque" editor written in Nu :)

has anyone who has ever used Emacs not complained of it being bloated? Isn't that the de facto argument in the age-old Emacs vs. Vi flamewars?

Firefox: the initial design principle desired a browser that was simple, fast, pluggable, compared to the old Mozilla browser which had features out the ass

I must say, the same people that criticized Eclipse for its "bloat" that are now making excuses for the bloat in Atom is very amusing.

In terms of performance, stability and extensions this doesn't even hold a candle to Eclipse Mars.

Don't know about Eclipse, but NetBeans runs much faster than Atom on my Mac, with far fewer pauses. Unfortunately, Atom is built in a language with a much worse GC than NetBeans (or IntelliJ, or Eclipse).

I disagree with your characterization. Take jQuery for example.

    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.
Eventually, the growth of jQuery tapered off as the project stabilized. Not only did the size taper off, it got smaller as well. After nearly 10 years, we're talking about a payload of 30K minified and gzipped. https://mathiasbynens.be/demo/jquery-size

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.

Jquery is a lot of things but minimal isn't really accurate.

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.

> 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.

While this is true, and I love JQuery, there's a significant number of JavaScript programmers who do say that JQuery is bloated and slow and old and you shouldn't use it. http://youmightnotneedjquery.com/ and all 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.

> as you've said, it literally is not bloated wrt filesize

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.

Kind of a good example of what I mean about how I don't care much about "bloat" anymore... it is my perception that the vast majority of people who fling the term around are not doing so after any sort of careful examination of the system in question and coming to a considered conclusion... it's mostly just an accusation more than anything else. It's not generally a very nice thing to say about a framework, even if you can somehow objectively prove it, it immediately puts the entire conversation on a very hostile footing.

Your link explicitely says "you MIGHT not need jQuery", there's nothing wrong about that, quite often you actually don't need it at all. It doesn't say "never use jQuery"

I find jquery is a good rapid prototyping tool.

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?

Certain things in jQuery are definitely dated & slow. It has a pretty meh implementation of promises, and the .animate library has pretty bad performance. That's why things like Velocity.js exist.

My point wasn't if jQuery is a bloated library or not, but whether its plugin system caused it to bloat beyond its original purpose.

"The cycle of bloat doesn't always take hold"

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?

The problem is you haven't given a single example of any software that fits the model, and people are continuing to provide counter-examples.

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.

Firefox is a pretty solid example. Started slim as hell, gradually pulled plugins in until it was more bloated than IE and everyone moved to Chrome. They realized the problem and have started pulling back (although you could argue the opposite with the new integrations), but it still stands as an example.

Have been using Firefox since beta, hardware hasn't always been exactly latest and greatest and I really don't get this whole Firefox is bloated meme.

Try Chrome for a month and you'll get it. I'm switching back to Firefox, but believe me, the argument holds weight.

Use Chrome and/or Chromium all time and find the speed is almost the same.

Chrome advantages for me: - install pages as apps (Mozilla prism isn't supported anymore)

Chrome disadvantages for me: -Missing all the most useful plugins

I find the speed difference between Chrome and Firefox to be minimal at the beginning of the day.

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.

If Firefox wasn't bloated, then nearly all of the new value-added features since version 3 or so should have been added as included (and disable-able) plugins: spell check, Hello, the new tab implementation, etc etc

"The problem is you haven't given a single example of any software that fits the model,"

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.

> Pretty much every text editor ever has started out as a "lean, fast" text editor. And then they grew.

Not Notepad. http://notepadconf.com

it's hilarious, my favorites:

> .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.

I don't recall accusing you of claiming everything is under the cycle of bloat.

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".

Edit: Sorry, is there something wrong with my pointing out that I didn't ever claim the things being imputed to me?

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.

There are projects like Linux Kernel, Mercurial, and Rails that have managed to be very extensible and have had good leadership in knowing what to put into core and what to cut from core as time goes on.

Well, I know for sure I've witnessed people say #6 about the Linux Kernel and Rails multiple times.

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.)

> And it turns out that "text editing" looks really simple, and gets really not simple really fast.

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.

Text editing is not simple. Not since Unicode is a thing. And it's not because of Unicode, it's because of us humans and our crazy languages.

Totally agree with you there. I've been reading over the Unicode spec and some of it makes my head spin. I would have never imagined the required level of complexity beforehand.

And the language Atom is written in supports Unicode very badly indeed, to keep things relevant to the topic at hand.

Atom is cool in that it shows how much time a package adds to startup. It's also so modular that you can remove most of what you don't need or want.

For your step 6, it just means disable all packages and add them back only as needed.

See also: "minimalist web browser" and the history of Firefox :)


Try: the web itself.

The amount you need to be able to do to just load a basically-plaintext webpage now is absurd.

that's a really good point. I used to browse http over telnet because my boss couldn't tell I wasn't hard at work. Needless to say, I can no longer do that.

Yup, that one was certainly big for a while! KHTML and its whole menagerie of browsers competing to be more "minimal" than the last.

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).

True story. To mitigate this all of Atom's core are implemented as packages that you can disable or completely replace with other versions.

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.

Yeah the moment people realise this they tend to start to learn the basics of an old, bloated but still maintained and loved tool like emacs or vim in the case of editors. Nobody wants to relearn the same things over and over again every three years. And you can't really get away from the disadvantages software has (either too small or too bloated). But these old tools will stay.

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.

This is true for some projects, but with atom you can strip away core packages as needed. Just go to settings and disable!

Your cycle of bloat might describe many other projects, but not Atom because from the start, Atom depended on 10s of millions of lines of code -- a different copy of those 10s of millions of lines than the copy in your web browser.

I have suffered the same with Visual Studio addin's. My main extension Visual Assist X works great. Once you start adding others the performance gets really poor really quick.

I do this all the time, the number of my installed Emacs packages and Firefox add-ons looks like a sawtooth wave when plotted over time.

You're probably one of those people that pull in jQuery to use just the selector.

I must say, I greatly underestimated the degree to which the word "bloat" triggers all the bad side-taking rationality-bypassing political thinking and socializing mechanisms in programmer's brains.

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.

This. This needs to be a musical number along the lines of the Lion King's "circle of life"

Welcome to what I've felt with Emacs since I first used it.

Might be time to work on some tutorials and examples to make Emacs easier to hack on and contribute to...

Yes. I keep trying to like Atom because I want to have native WebView buffers while I'm editing. Every time I try it, I end up wondering how anyone can be comfortable using it. I'm not sure how much of that is due to instability that will be fixed over time, and how much is because I'm coming from Emacs.

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.

I've got the same problem with both Atom and LightTable. They have potential; they are just 30-years too young for me.

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)

>Have any experienced Emacs users found that Atom makes them more productive in any dimension?

No. Emacs is far and away superior. It doesn't have a flashy web UI, but it is better in every way that matters.

My custom Emacs init file that's grown over the years reminds me of my main problem with Emacs: to do anything, it just feels like a bunch of magical incantations using global variables and function calls I wouldn't know how to discover on my own.

Random example from my user.el file:

    (set-cursor-color "White")
    (setq blink-cursor-interval 0.5)
With some trial and error, I could find out if `(setq cursor-color "White")` works. Or see if `set-blink-cursor-interval` exists. Or look up why `set-cursor-color` exists in the first place when surely it's more consistent to just modify a config variable. Or find some best Emacslisp practices online. Or figure out why I could never get working my one attempt to write a custom function to scratch my own itch.

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.

> I wouldn't know how to discover on my own.

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:

  ELISP> cursor-color
  *** Eval error ***  Symbol's value as variable is void: cursor-color
so, no.

> Or see if `set-blink-cursor-interval` exists.

In ielm:

  (symbol-function 'set-blink-cursor-interval) ;; (no, it doesn't)
Via help system: C-h a; then input the name.

> 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.

I think you'll find that Atom is going to be the exact same, but with Javascript.

No, Atom's API is probably an order of magnitude smaller than Emacs.

For now. And in JS! Yay!

> 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.

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.

The ease of installing packages in Emacs has improved hugely in the last few years, so I think it's getting better for beginners already.

I've felt largely the same about vim. I think atom is the GUI'ed equivalent of excellent extensible minimalist command line tools.

You have felt it is easy to install, debug, and write vim plugins? As a vim user, I am super curious how?

Installing and managing plugins at least is pretty easy with pathogen and vundle.

While I see that as a strength it might be a double edged sword. I installed a few packages I thought were necessary and soon Atom was crashing constantly and was riddled with bugs. I think it's possible that too many people have the ability to control core pieces of what makes Atom so good and as a result the experience degrades.

The inverse also applies. Take Chrome/Chromium where the extensions are generally powerless against core components, making the whole browser useless for decent customization.

Still, there are six "highlight features" right on the home page:

- 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.

How exactly it is easier to extend than emacs?

The trick is to not pull them into core. Let others curate a set of high quality plugins. This is exactly what is happening. Examples include Microsoft's Visual Studio Code and Facebooks Nuclide.

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.

Visual Studio Code is not a set of Atom plugins.

This is kinda the reason that you have quite a few die hard emacs fans.

Congratulations GitHub and Atom team!

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

Hear, hear! Well done, GitHub! This will be an invaluable resource for the software development community for years to come. Congrats on 1.0.

Great job from the Atom team for such an outstanding editor. Our whole company switched over from IntelliJ and never looked back. Everyone is totally thrilled.

I've gotta say, honestly, I'm preferring Visual Studio Code over Atom simply due to the fact that it seems MUCH more stable and lightweight. Atom is very visually appealing, and I'm a fan of the project, in general, but it constantly freezes up and crashes on me. I think I'll be sticking with VS Code & Sublime.

FWIW I use Atom for hours every day to edit Ruby & JS code and it has never frozen up on me once. Earlier versions used to spin the CPU pretty hard at times but I haven't seen that for a while now either.

In part, this is because VS Code is currently not extensible at all – there is no package ecosystem, and therefore no vector for users to possibly introduce instability / performance issues.

Visual Studio code needs to let me make CoreCLR executables on OSX and Linux, yesterday.

I have the same problem but VS code. I was using it for my node projects because it was very easy to use the debugger tool but it practically crashed (freezing the whole editor) 1/2 of the times so I reverted back to atom (that for me never crashed)...

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

In the case of Atom, I don't think so, as I just updated to the recent version TODAY and had it freeze literally 3-4 times and fully crash once. I hear many people complain about similar issues with Atom. VSCode is in a much earlier development state (nowhere near Version 1.0 yet), but I've used it on Windows 8, Linux Mint, and Elementary OS without any issues whatsoever. shrug

Funny, as VS Code is based on Atom.

VS Code is not based on Atom - it's built on Electron, the app framework Atom is also built on, and uses some of the same Node packages Atom developed.

Electron was extracted from Atom and was originally named Atom Shell. I don't see your point.

Electron was also not extracted from Atom - it was always extracted as atom-shell. It was just rebranded as Electron. Atom ≠ atom-shell.

Maybe we aren't speaking the same language. Here's what it says on electron.atom.io:

"Initially developed for GitHub's Atom editor"

So what are we talking about?

"for" does not equal "as part of".

No it's not.

I find it to be a bit depressing that software bloat has advanced to the point that we have text editors plagued with performance issues.

Thirty years ago people complained that GNU Emacs needed 8 megabytes of RAM.

This is true, but if you gave emacs the 8 megabytes it wanted it ran great even at scale (lots of buffers into lots of giant open files) in my experience.

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.

"Eight Megabytes And Constantly Swapping"--Seems quaint now, doesn't it?

A little, but at least it could open an 8mb file, not to mention a 2mb file...

Thirty years ago 1MB of RAM was $800+ ...I would have complained too.

Of course, that was the reasoning behind it. RAM was expensive and allocating all the RAM on an Unix box to one process was 'unpopular'. Especially when there were more than one time-shared user on the machine.

There are still editors out there that work. Just don't use those that suck, and they will go away. Or at least I wish they would.

I made the switch yesterday not knowing 1.0 would be released today, and I am seriously psyched. Their Vim bindings are now good enough, and there are tons of tweaks you can do to make them better (which will inspire more people to contribute). I found a few bugs here and there related to installing / removing packages (just checked and 1.0 fixes them), but nothing major, and was able to migrate my mammoth .vimrc configuration file over over the course of an afternoon, with everything I need having already been developed by the community. Super fast, too.

Also! I was able to create the colorscheme of my dreams in about 15 minutes, thanks to to the dev tools integration.

What are the main advantages that atom gives you over native vim?

From the perspective of a web app developer it's just so modern. The language of the interface takes all of the (admittedly subjective) best-practice lessons that the web has taught us over the years and embeds them directly in, and then lets you hack them apart however you wish -- simply. Code editing works without a thousand inconsistencies, and then you have things like embedding your terminal directly with ease (its trivial to create a tmux like environment), etc.

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!

I haven't looked at Atom yet, but can it parse the vimrc file to load the right settings?

Atom's vim mode is a joke. No ex mode, you need another plugin for that ... which is kind of clunky.

Nope. Most of the code editor settings are there in the main config to be tweaked, and new packages can be installed right inside the preferences / command line.

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.

You have to manually point and click. It's a regression. But OMG clicking is SO EASY /sarcasm

Background processes don't block the main thread, the extension points are better thought out and the development experience in working on extensions is a LOT better, js/coffee are better languages than vimL, and display is not limited to a fixed grid of text cells.

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.

You should check out Neovim. The native scripting language is Lua, and it's a fork of the vim codebase so still fast and commands all work identically. It's still early, but I am monitoring (and supporting) the project closely.

Also, one of Neovim's banner features is asynchronous job control, which greyrest complained about.

I can't wait until we don't have to run it in a terminal though.


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.

I just timed it and it was less than 5 seconds. I would suggest giving 1.0 a spin before you judge.

Thats still a long time for a text editor though. Sublime, Vim, gedit, etc are all instantaneous.

On this MacBook Pro (MacBookPro12,1) i7(3,1GHz) 16GB of RAM, 512GB SSD ... it takes less that 5 seconds which is way to long for me. If that's ok for you no worries, but you can't say it isn't slow.

My Emacs with all customizations takes longer than Atom does to startup.

Which, for Emacs, is not an issue at all. Leave the server running and all clients will open instantly whenever I ask.

It offers a point and click interface for people that can't be fucked to learn how to set up a .vimrc

Eh. Why is 1.0 out already? Keyboard layouts which use AltGr are still broken.

E.g. I can't type '@', '\', and 'µ'. Yes, I can't write metadata annotations or escape some characters.

I agree, that should really be fixed in the core.

In the meantime however I recommend using this package https://atom.io/packages/keyboard-localization which has worked really well for me (german keyboard).

I'm running Atom 0.116.0 on Xubuntu and AltGr works perfectly fine. My keyboard layout is Norwegian.

Norwegian with Sámi has a lot of collisions. With the regular Norwegian layout, the only collision should be µ (M + AltGr).

0.116.0? That's an ancient version (or a typo). You should probably upgrade to 1.0.

>Eh. Why is 1.0 out already? Keyboard layouts which use AltGr are still broken.

Perhaps such keyboards don't concern that many people?

AltGr is used by many layouts such as German, Turkish, French, Polish, and US International.


Also, this was supposed to be fixed in 1.0. I don't know why they decided to release 1.0 prematurely.

Today I learned I can type an acute accent ´ without memorizing the "alt code" by using right alt.

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 ½

Yes, I'm from Germany and had the same problem.

LiveScript is a pain with it :\

That's going to render whole countries worth of developers reconsider using Atom. AltGr is widely used at Nordic countries at least and I wouldn't be surprised if elsewhere too.

Let them speak English! This'll bring the world closer together.

Switching to an American keyboard layout just so programs work isn't very practical. Especially when you have to switch back to your localized layout for correspondence with your non-English speaking peers and colleagues in between.

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.

I prefer the Neo layout (which is completely different, think: Dvorak), which has excellent placement of all programming-relevant keys as well as German and English bi- and trigrams. Very comfortable to type, but too many programs capture events that break functions of the keyboard layout. It uses left and right shift, caps lock and ' (# on QWERTZ), the key between shift and Z (that's not there on a US keyboard) as well as AltGr as modifiers (plus combinations of the above). Sublime is particularly bad (captures compose and tab) :\

I used a custom layout with easy access to tons of special characters but gave up on it when I frequently had to switch between different operating systems.

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.

It's... suboptimal.

I have a ThinkPad Compact USB keyboard at work and a ThinkPad at home (although the external version has a terrible controller/firmware, TrackPoint scrolling is hard in Linux. I've mapped it to right click + TrackPoint because otherwise I'd get spurious paste events when trying to scroll).

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.

We speak English, but our laptops come with localized keyboards.

Can't you just pick a different layout in the OS -- and that will remap the physical buttons?

Of course you can -- but at the same time you ditch tens of years worth of muscle memory and habits. Also the physical buttons don't correspond to the characters anymore, which can be irritating when trying to remember where that one damned seldom-used sigil was again. Also it's a pain in the ass to have to switch constantly between layouts, if you want to write some non-code text in your native language that uses characters that are not present in the US layout. (Btw. for what it's worth, I use customized Dvorak layout that contains all the characters I use when coding, typing English and Finnish. But I'd imagine most of us won't go that far to actually customize their layouts.)

I think having to remap your systems keyboard to something other than your native language in order to use an editor is a bit unreasonable.

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".

Atom is the ONLY editor which cannot handle my keyboard layout properly so I can't write brackets :D ([]) I reported it on the first day when the alpha came out, still no fix for this. Let me put it this way: I CAN'T WRITE BRACKETS IN A TEXT EDITOR. LOL

I can't use half the keybindings in my spanish keyboard lol.

I'm on a spanish keyboard and it works for me {çñ¬#%|ª}, etc. so there might be something that you can do!

Link the GH issue please.

Have you tried this https://github.com/andischerer/atom-keyboard-localization ? Looks like they almost fixed it.

I really want to like Atom but it's such a pity that they went for CoffeeScript instead of plain ES5/ES6.

I was a big supporter of their choice of CoffeeScript... until @jashkenas et al decided not to adapt to ES6. Now the language is dead and users are better off migrating to Babel and just dealing with the curly braces and commas.

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

When did @jashkenas decide not to adapt to ES6? I searched and found this, which indicates they're open to it. Someone just needs to implement it.


> "I think that such a pull request has a moderately slim chance of being accepted — it's probably still better to wait until real JS modules are finished and fully described. But it's worth a shot."

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.

That's really only a problem if you're contributing to the core, right? You can write your own packages in JS, and if you're just a user of the editor I don't see how that matters.

Sure, you can write your own packages in vanilla JS. Unfortunately though all of the documentation (and most packages themselves) are all written in coffeescript. Basically, the only way you can write a plugin in Javascript is if you already know Coffeescript (at least enough to read it).

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.

I wouldn't even classify CoffeeScript as another language. It's really just javascript with some syntactical sugar. It took me about 20 mins to get comfortable with it.

It's another barrier to entry. Documentation is probably the worst place to encounter a new language, since the reader is already confused and frustrated.

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.

It's a lot of syntactic sugar and things removed. Even the ?: operator which I use a lot. Typing "a = if b then c else d" is a huge wasted opportunity to just keep the ?: op. Plus there's no way to get the == operator even if you know you want it and understand the nuances.

I honestly find I use the ? operator in coffeescript far, far more often than I want to use a ternary conditional.

Fair enough on the == operator, but it's another that I have honestly never needed or wanted.

If c is truthy: a = b && c || d

Sure, but it's not the same, on one side I'd like to read the core and hack it on my own terms, on the other I'd feel more comfortable writing packages if I could just read the core and see how things work under the hood. I'd like it to be a "hackable editor" as it touts itself, but as it stands right now it's a "hackable editor if you are comfortable with CoffeeScript".

It will take you less than a day to learn to read CoffeeScript if you are familiar with JS.

Coffeescript is a very polarizing language. Most people appear to either love it or hate it vigorously.


CoffeeScript was released in a time when ES6 wasn't yet a thing as far as most developers were concerned. It was also a time when JS saw a huge influx of new developers coming from other languages. CoffeeScript itself draws heavily from Ruby (and some Python), which explains why it was rapidly adopted by the Ruby community and became part of Rails (just like Sass replaced CSS).

When I first revisited JavaScript after a long time writing Python code, I was quite fond of CoffeeScript because it let you pretend you're not actually writing JavaScript and because it enabled a lot of idioms that didn't exist in vanilla JavaScript.

CoffeeScript is decidedly not an extension of JavaScript. It doesn't build on existing JavaScript idioms and just add syntactic sugar (partially because many idioms of modern JS simply didn't exist at the time and there was less consensus about them) -- it substitutes idioms from Ruby and Python and implements their syntax, all the way down to changing how variables are declared and how the equality operator behaves.

CoffeeScript is written for programmers who understand JavaScript but don't want to write JavaScript when creating JavaScript code.

Thanks to Babel.js ES6 (now ES2015) is now a thing. Most of the new things CoffeeScript brought to the table for JavaScript programmers are now satisfied by the language itself or syntactic extensions supported by Babel. There is a well-understood and well-defined class syntax, there are arrow functions and tons of syntactic shorthands like method literals and object/array destructuring. What's more, because these are now officially part of the language, Babel itself just serves as a stopgap while we wait for the JS environments to catch up.

Outside its original use case of allowing Ruby programmers to avoid writing JavaScript, CoffeeScript is obsolete and (at least in terms of hype and momentum) dead. It has outserved its usefulness and has given way to more specialised languages (e.g. ClojureScript) and Babel.

It's unsurprising that Atom core is written in CoffeeScript if you consider that GitHub is and always was predominantly not a JavaScript company but a Ruby company. It is heavily invested in the Ruby world and CoffeeScript is part of the Ruby world more than it is part of the JavaScript world.

I'm not sure whether CoffeeScript's role in the Ruby world will change anytime soon, but outside that microcosm, it has become irrelevant and is quickly fading into obscurity. It served a useful purpose at the time and it has certainly influenced the development of ES6 but other than allowing Ruby programmers to avoid writing JavaScript it's just no longer worth bothering with.

Also note that at the time everybody was trying to replace JavaScript with new languages (which were either supersets of JavaScript (like TypeScript), shared a common subset with JavaScript (like CoffeeScript) or did something else entirely (like ClojureScript)).

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.

In a nutshell: I don't hate CoffeeScript, but I consider it a major smell when evaluating libraries and projects. If it's written in CoffeeScript it might as well not be written in JavaScript at all.

Yeah CoffeeScript is pretty easy to learn and doing things like configuring snippets seems like a good use for it.

In general tho, I am pretty hesitant to go all in with CoffeeScript, mainly because you still have to watch and massage the javascript output, negating any time saved for me at least.

You can write in Plain JS if you want (it supports Babel, apparently); CoffeeScript is not a hard limitation, just a preference.

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)

You can call CoffeeScript functions from JavaScript and vice versa. There's no reason that you can't use the UI library from code written in JS. The fact that its written in CoffeeScript is an implementation detail

Inheritance. DOM element functions. Gee, I must have never tried this and have no idea what I'm talking about right?

I tell you what, you try it and tell me how it goes for you?

It's really not that simple.

But all the docs are in Coffeescript, and it's quite hostile to a new dev.

Grab a cup of coffee, start reading the CoffeeScript documentation. Your coffee won't even by cold by the time you finish with it. Start coding.

Seriously, CofeeScript is tiny.

We've been working on Atom for a long time. I think that CS was a great choice when it was made some years ago, and I can say that the core team quite likes ES6 (which directly addresses a lot of the same JS warts that CS was designed to avoid). That said even if we decided to move to ES6 today, it's a big ship and it takes a long time to turn :)

Do you really care that much which dialect of JavaScript your text editor is written in?

It's a bit like worrying about the brand of gruel you're eating.

CoffeeScript is actually pretty cool, from a few minutes spent with it it was just syntaxic sugar for js. Why don't you like it?

Did you miss that you can't create local variables?

WHAT? You mean, you can't declare them without initialization. Oh well, you can't; it's also impossible in Python or Lua. Why is it a bad thing?

Let's not confuse matters here: in both those languages an initialization-assignment will introduce a new binding within function scopes. In CoffeeScript it will always be the parent scope's binding, which means that you must take extra care not to introduce variables used in scopes above, or below, at any given time.

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.

Lua has perfectly sane lexical scope for its local variables. Don't mix it with Python and Coffeescript.

Ah, true, I checked again and you're right. Too late to edit.

you can if you cheat: http://coffeescript.org/#try:%0Aa%20%3D%201%0Ax%20%3D%20-%3E...

(I jumped ship to babel though)

Nothing stops you using javascript in your own packages

And by "nothing" you mean the entire UI library

I quote:

> 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)

That's something I like about it.

I had initially dismissed the whole thing as folly as JavaScript is really stupid, but I had someone install Atom the other day and came to learn that it is really quite an impressively great editor these days.

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.)

I am loathe to install something like Atom with a 4MB limit on file size and 80 MB install size when Sublime Text does the same or better in a 8 MB install package with no limits.

Do you really do your work on a computer where an 80MB install is a problem? No argument on the file size limit.

Yes, I program on a netbook. I find the resource limitations useful in writing programs that are very efficient. I do mostly scientific programming, so if it runs on my netbook, it flies on my cluster.

Just downloaded and opened Atom for the first time, and I have to admit the look and feel is amazing! Fantastic job to all those involved!

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.

That's why you shouldn't let javascript developers produce desktop apps... The whole Chromium is bundled with Atom.

No, a subset of Chromium is bundled with Atom: https://github.com/atom/libchromiumcontent

It's because the shell (http://electron.atom.io/) is based on Chromium, which can be quite large if you include everything. But in the future, the size should get smaller. NWJS, which is also based on Chromium, is already making efforts to significantly shrink the binary size.

It's possibly more fair to compare it with an IDE, not simply a text editor. WebStorm as a download is 131 MB. Not as big, but in a similar class.

edit: And the full WebStorm app is 293.5 MB

If you want a better comparison, Sublime Text's installed size is 1/10th of the size of Atom at 23 MB.

What problem does the extra 176MB present to you when you likely have 256+GB of disk storage?

This kind of reasoning is exactly why we have even more bloated, crap software these days

Who said it was a problem?

I wonder this too - it's a freakin text editor. A very cool text editor, but hundreds of megabytes?

I only hace 64 in my tablet. Half of which the OS already ate.

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...

Do not write software ever


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact