Live data from Hacker News

Atom 1.0

blog.atom.io

371–380 of 459 posts

Re: Atom 1.0

#371
Seriously, creators of Atom, what feature did you not find in any of the current text editors that you had to built one. Let's have a editor in every language!!!

Re: Atom 1.0

#372

Earlier quoted context omitted.

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?

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

Re: Atom 1.0

#373
post #242

Earlier quoted context omitted.

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.

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

Re: Atom 1.0

#374
post #137
post #124

Earlier quoted context omitted.

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 o…

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

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.

Re: Atom 1.0

#375
post #348

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 underton…

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 can open a 15MB log file, but my CPU usage skyrockets.

Re: Atom 1.0

#376
post #60

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…

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.

Re: Atom 1.0

#377

Earlier quoted context omitted.

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 j…

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

Re: Atom 1.0

#378

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 underton…

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.

Re: Atom 1.0

#379
post #290

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

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.

Re: Atom 1.0

#380
Downloaded it and added Facebook's Nuclide plugin suite but many things seem to not work. the mercurial plugin doesn't appear to function at all and frequently the config section where you list installed plugins just seems to hang, without loading anything. I'll stick with Webstorm (favorite) and Brackets (favorite "Atom like" editor) and vim (favorite command line). Atom seems too buggy to me.
Post reply on HN