Hacker News Reader

Comment by steego | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com