4 ms·
The parent did not say that plugins caused bloat, instead that resolving common problems with plugins (stability, quality, conflicts etc.) by pulling them into
by duncanawoods 11y ago
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 11y agoStill: 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?
- duncanawoods 11y agoI 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.
- alexandre_m 11y agoExcept that neither ST3 or TextMate were open source.
- girvo 11y agoTextMate 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 :)
- Tehnix 11y agoTextMate 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.
- knodi123 11y ago> 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 11y agoThat 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?
- knodi123 11y ago> 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.
- wahnfrieden 11y agoYes, 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 11y agoIf it is slow, use vim --startuptime to check for slow plugins on startup.
- grumblestumble 11y agohas 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 11y agoFirefox: the initial design principle desired a browser that was simple, fast, pluggable, compared to the old Mozilla browser which had features out the ass