Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might not need jQuery (2014)

youmightnotneedjquery.com

Post reply on HN
Print view View original

131–140 of 241 posts

Re: You might not need jQuery (2014)

#131

Post by aheckler »

KptMarchewa wrote: post #108
Mooty wrote: post #104

No one mentions the fact that jQuery is still used in Wordpress (33% of all websites) everywhere and (as far as I know) in the last theme version they provided this year. Which makes it somehow the biggest library around in terms of usage. I'm still confused why people needs node/react or vue to achieve simple thing that back in the days where pretty easy to do with basic php/jquery. Simplicity in coding was better a…

The raw count of websites, aka copies of code sitting on some server means nothing, and is bad metric. What matters, is either website view count, or some metric of developer time spend on developing those websites.

I think the percentage that the GP is referencing is from W3Techs [0]. It's currently 39.7% in fact, and that's only looking at the top 10 million websites [1], so it's not just a simple installation count across all sites ever created.

[0] https://w3techs.com/

[1] https://w3techs.com/technologies

Re: You might not need jQuery (2014)

#132

Post by austincheney »

human wrote: post #57

I’d be careful about premature optimization. If you can write your code 2x faster by using jQuery, by all means do it. Eventually, if needed, you could rewrite your JS to be free of jQuery, but it would not be a priority for me. Dev speed if more important than load speed for me.

That’s not premature optimization:

https://en.m.wikipedia.org/wiki/Program_optimization#When_to...

If your code can execute 10x faster without jQuery then the optimization is not premature. If a developer takes twice as long to write any code the problem isn’t optimizations at all.

Re: You might not need jQuery (2014)

#133

Post by pkorzeniewski »

jamiesonbecker wrote: post #2

It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.

I've never stopped using jQuery, it makes everything so much easier to work with. I've built large web apps using only jQuery and never had any problems, I just really like direct DOM manipulation instead of some abstractions and jQuery makes it as simple as possible.

Re: You might not need jQuery (2014)

#135

Post by finiteseries »

joshxyz wrote: post #96
halis wrote: post #23

Having used react and redux for several years now, I'm a bit burnt out on how bloated and silly the entire front end has become. If I could decide for myself, I probably would use raw DOM or jQuery at this point.

I did the following, still comfy with react. - Got rid of redux because it's shit - Got rid of Material UI because it's bulky and its API changes are painful, replaced it with tailwind - Got rid of React Router because it's bulky and its API changes are also painful, replaced it with a simple hook

I haven’t used react since 2017, but the fact that react-router is still undergoing painful API changes somehow doesn’t surprise me.

Re: You might not need jQuery (2014)

#136

Post by tomtomtom777 »

arp242 wrote: post #56
jart wrote: post #8

Earlier quoted context omitted.

This comment is a great example of what I call "lines of code mindset" which is form of tip of the iceberg mentality, where programmers optimize for simplicity only the code they see. Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Hidden complexity you don't control is the most expensive kind I think.

It's 77k for the latest version, and after compression it's ~32k. It's really not all that large. You can also reduce this to about ~27k if you exclude some less-commonly used things like animations, shortcuts, etc. JS people be like: "86K jQuery dependency is wasteful!" Also JS people: "why do you care that an SPA loads 2M of JavaScript? Are you stuck on a 56k modem or something?"

There is an additional cost to such a dependency that isn't expressed in bytes.

Javascript/CSS/HTML forms the common basis of web development. You may assume every reader of your code is familiar with it.

If you use a specific library, you are restricting (easy) readability to those that know the specific library.

This has merit if the library provides sufficiently useful abstractions or shortcuts, but it's only a drawback if the library provides merely an alternative way to write something already possible in the base layer.

Re: You might not need jQuery (2014)

#137

Post by nicoburns »

porker wrote: post #121
jarek-foksa wrote: post #109

Earlier quoted context omitted.

With modern JavaScript you can easily cast a NodeList to an Array, e.g. `let spansArray = [...element.querySelectorAll("span")]`. I find both `element.nextElementSibling` and `element.next()` to be examples of poor API design. The former one is more verbose than needed while the latter one is so short you can't even tell whether it's a method or a property.

> With modern JavaScript you can easily cast a NodeList to an Array, e.g. Ah, thanks. I got bitten by this recently and didn't know what to do with this "thing that's not an array but seems like it should be, and doesn't always behave like one"

FYI the reason it's not an array is because if you store a reference to it, it will stay up to date as and when the DOM changes.

Re: You might not need jQuery (2014)

#138

Post by nicoburns »

userbinator wrote: post #39
jamiesonbecker wrote: post #17

Earlier quoted context omitted.

> Hidden complexity you don't control is the most expensive kind I think. That's called encapsulation. :) Seriously, encapsulating complexity is the foundation of most programming paradigms.

In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better. Encapsulation/abstraction should really be a tool of last resort. From experience, it doesn't actually help reduce complexity if overused, but just makes it hidden and more likely to surprise you when you're debugging.

> In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better.

jQuery's not a very good example of this though. It's one of the most widely used, and hence most tested and least buggy pieces of software out there. Nowadays the web APIs are pretty solid, but back in the IE6/7/8 days the jQuery API was a lot less buggy than using the built in APIs directly.

Re: You might not need jQuery (2014)

#139

Post by ryanbrunner »

tomtomtom777 wrote: post #136
arp242 wrote: post #56

Earlier quoted context omitted.

It's 77k for the latest version, and after compression it's ~32k. It's really not all that large. You can also reduce this to about ~27k if you exclude some less-commonly used things like animations, shortcuts, etc. JS people be like: "86K jQuery dependency is wasteful!" Also JS people: "why do you care that an SPA loads 2M of JavaScript? Are you stuck on a 56k modem or something?"

There is an additional cost to such a dependency that isn't expressed in bytes. Javascript/CSS/HTML forms the common basis of web development. You may assume every reader of your code is familiar with it. If you use a specific library, you are restricting (easy) readability to those that know the specific library. This has merit if the library provides sufficiently useful abstractions or shortcuts, but it's only a dr…

That's fair, but I also think that JQuery is often judged much more harshly than other libraries that have a significantly higher learning curve.

I know plenty of developers who would view inclusion of JQuery as some cardinal sin due to reasons like the ones you state, but don't apply the same logic to React, Redux, or other more modern, significantly more complex libraries.

Re: You might not need jQuery (2014)

#140

Post by ryanbrunner »

graftak wrote: post #83
eyelidlessness wrote: post #9

Earlier quoted context omitted.

I doubt the “choose not to use jQuery” path means “never write a function to wrap up that boilerplate”. The point is that you might be able to write the equivalent function instead of pulling down a whole library. That said, optimization techniques have gotten good enough that you might be able to just let a build tool do that for you. If you really still want to use jQuery.

jQuery is immune to modern optimisation techniques such as three shaking (only including the modules actually used) because it’s fluent interface makes it a gorilla that holds quite a few bananas, even if you only need one of the bananas.

I would imagine the percentage of front end projects that have a build chain sophisticated enough that tree shaking is important and where 30 KB has a significant impact on their bundle size is vanishingly small.
Post reply on HN