Atom 1.0
371–380 of 459 posts
Re: Atom 1.0
#372Earlier 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?
Re: Atom 1.0
#373Earlier 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.
Re: Atom 1.0
#374Earlier 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?
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
#375Congrats 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.)
Re: Atom 1.0
#376The 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…
Re: Atom 1.0
#377Earlier 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.
Re: Atom 1.0
#378Congrats 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'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
#379Congratulations 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…