[joefitzgerald]

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.

[jerf]

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

[coldtea]

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.

[jerf]

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

[baldfat]

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.

[duncanawoods]

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.

[coldtea]

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?

[knodi123]

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

[mcbuilder]

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?

[wahnfrieden]

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.

[labianchin]

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

[duncanawoods]

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.

[Tehnix]

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.

[alexandre_m]

Except that neither ST3 or TextMate were open source.

[grumblestumble]

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?

[tomc1985]

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

[bitmapbrother]

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.

[pron]

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

[steego]

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.

[mikeryan]

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.

[steego]

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

[steveklabnik]

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.

[boomlinde]

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

[jerf]

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.

[thiht]

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"

[Kequc]

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?

[joshburgess]

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.

[steego]

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.

[jerf]

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

[radlad]

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.

[kedean]

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.

[reitanqild]

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.

[jerf]

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

[judah]

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

Not Notepad. http://notepadconf.com

[steego]

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

[resu_nimda]

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.

[crusso]

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.

[jerf]

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

[doodpants]

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

[oblio]

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.

[jbenner-radham]

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.

[matwood]

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.

[zacharypinter]

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

https://en.wikipedia.org/wiki/Firefox#History

[TheLoneWolfling]

Try: the web itself.

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

[knodi123]

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.

[jerf]

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

[oblio]

http://www.jwz.org/doc/easter-eggs.html

My all time favorite reply about bloat: "X is big because your needs are big" (in the article X = Mozilla).

[crucialfelix]

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.

[erikb]

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.

[nchudleigh]

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

[hollerith]

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.

[macjohnmcc]

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.

[rndn]

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.

[hawsome]

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

[jerf]

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.

[robogimp]

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

[omouse]

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

[jflatow]

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.

[klibertp]

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)

[davexunit]

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

[danneu]

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.

[klibertp]

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

[webkike]

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

[kansface]

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

[webkike]

For now. And in JS! Yay!

[outworlder]

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

[davidshepherd7]

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.

[outworlder]

Indeed.

For example: http://tullo.ch/articles/modern-emacs-setup/

[kajecounterhack]

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

[afarrell]

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

[palmer]

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

[kajecounterhack]

And for writing: https://github.com/google/vim-maktaba

[jastanton]

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.

[pvdebbe]

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

[r0muald]

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.

[sklogic]

How exactly it is easier to extend than emacs?

[ffk]

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.

[carussell]

Visual Studio Code is not a set of Atom plugins.

[lettergram]

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