53% Less JavaScript with jQuery | Hacker News Reader

53% Less JavaScript with jQuery

twitter.com

20 pointssawirricardo16 comments

This really isn’t worth reading. The author is trying to stir up controversy without making substantive points. For example, the ES6 the author wrote is a scapegoat file with pretty bloated design that wouldn’t pass a code review. Additionally, the author isn’t comparing bundle size, but rather LOC without dependency size which is baffling.

If you read the replies you can find people who trivially write better versions using ES6.

It still amazes me how much we argue in this field about which tools should or should not be used, there is so much tribalism.

jQuery is fine to use if it solves your problem and you like working with it. Going vanilla JS is fine too (nowadays). Use something like SolidJS if it solves your problems, or Angular if you like their approach more. Go with a server-side only solution if that floats your boat!

Everyone has a different way of thinking, a different way to mentally model a problem and therefore different tools that work better or worse for them. Stop arguing about which is better, start building with the tools that work for you.

I enjoyed slightly more fine grained comparisons, like: https://youmightnotneedjquery.com/ (this hasn't been updated in a little bit, it seems)

Either way, I think you're right, just use whatever works for you.

I'd admittedly love to see a larger scale comparison of going vanilla JS vs recreating the same functionality in jQuery/Vue/Angular/React, for a real world apps and what the takeaways are from that, say, 50'000 SLoC instead of 100, that'd probably be more useful, but also is way more unlikely. Nobody will put in that much effort just for the sake of a comparison and so a lot will be up to opinion and comparing vaguely similar projects.

Closest I've seen was https://medium.com/dailyjs/a-realworld-comparison-of-front-e... but still a fairly simplistic example, given the large amount of options that were compared. Still very cool, less about opinions and more about giving you metrics that you can weigh in yourself! Here's the repo: https://github.com/gothinkster/realworld

It can be argued that some languages or technologies are superior to others in expressive power [0]. Some languages or technologies are easier to learn, but the solutions they produce are more complex, less simple, and/or less elegant; thus, one should strive to use the most expressive or "powerful" technologies available. Granted, the shadow aspect of this line of thinking is the constant treadmill of fashionable JS frameworks and the tribalism you allude to.

That being said, Moxie was recently featured on HN frontpage [1] regarding black boxes of abstraction and a lack of understanding of what goes on underneath. Much of development these days (think npm left-pad) is unnecessary abstraction and obscurantism of how the machine actually operates. Few people understand the underlying concepts and technologies, and many are trained only to operate trendy frameworks, languages, and technologies. Once the abstractions leak, and they always will [2], they are often lost as they don't understand how to step down a layer of abstraction to something more primitive. To this extent the point can be made that it may sometimes be worthwhile to not overcomplicate your solution stack with too many layers of indirection [3]. Not only does this simplify debugging, but you can more clearly see how your system actually operates and enrich your understanding of the software.

To this extent it can be argued that one ought to pursue simpler, more "standard" (ES6, even jQuery) solution stacks in the JS space instead of the combinatorial explosion of dependencies and multilayer cake of abstractions that seems to be par for the course today.

It should be noted that level of abstraction and expressive power, while not quite orthogonal, are not quite collinear either [0].

[0] https://paulgraham.com/avg.html

[1] https://news.ycombinator.com/item?id=41208627

[2] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

[3] https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...

> It still amazes me how much we argue in this field about which tools should or should not be used

Like any craft.

Is it really a bad thing that people think about how to solve their problems better and want to share with others?

Anyone who doesn't want to listen to that will ignore it and just pursue their own work.

Post E6 I personally think that Javascript is good enough to raw dog.

Producing code that isn't locked to a single framework or library is its own reward.

especially since most jquery usage I've seen in the past couple can be replaced with a shortened reference to document.querySelectorAll

Yeah, thats a common criticism of ES6 selector I see a lot.

They are so damn verbose.

Not only verbose, querySelectorAll returns a NodeList without normal array methods like map or forEach, so I find myself doing the following pretty much every time I use it:

  [...document.querySelectorAll('.example')]

Typically I see people create a utility function $ (querySelector) and $$ (querySelectorAll with conversion to array).

But this is fairly typical of the DOM API, some parts are awkwardly designed.

For what it’s worth, NodeLists do offer a forEach method (along with a few iterator returning methods which in contrast aren’t useful for concise style).

Hold your horses now, you can absolutely do:

document.querySelectorAll('.element').forEach(i => { yourFunction(i); });

I've not used map a whole lot, but I'm positive that it would work as well.

Oh you're right, there is a forEach method.

https://developer.mozilla.org/en-US/docs/Web/API/NodeList/fo...

    entries()
    forEach()
    item()
    keys()
    values()

And maybe values().map() will work too.

Agreed, unless you need access to the plugin ecosystem perhaps. Most things are about as difficult in ES6 as they are with jQuery, so there's no huge benefit to jQuery in my experience.

Although he exposes interesting points there, the final download size is still 20x larger than ES6. You gain DevEx against some load time

The ~60k that jQuery adds is not going to matter much. It only matters if you have tons of stuff and a 8M JS bundle. Then you might want to start worrying about this stuff and shaving off stuff. But adding a single ~60k dependency? It doesn't matter, even on slow connections.

that's so subjective it's a wonder this is an actual post.

Reply on news.ycombinator.com