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

221–230 of 241 posts

Re: You might not need jQuery (2014)

#221

Post by acemarke »

littlecranky67 wrote: post #107
csande17 wrote: post #99

Earlier quoted context omitted.

> Hi, I'm a Redux maintainer. We've heard your complaints that Redux adds a lot of unnecessary complexity and abstraction. Please note that we've now solved this problem in typical Redux fashion: by piling on additional layers of abstraction. > Also, I am going to continue posting this same comment on every discussion about Redux over and over for the rest of my life.

This is so sad but true. Redux-Toolkit now abstracts away the abstractions introduced by Redux & Co. in the first place. Think about that.

Not sure I agree with this statement.

The Redux core by itself doesn't really introduce abstractions. A reducer is just a function. An action is just an object. They're not abstractions, just a particular usage pattern.

Re: You might not need jQuery (2014)

#222

Post by hajile »

hu3 wrote: post #220
hajile wrote: post #213

Earlier quoted context omitted.

I think that's hard to ascertain because it's a drop-in replacement for react. I assume you mean hyperapp instead of hyperlink. It gets around a half-million downloads per week according to NPM stats while hyperapp gets under 3k per week.

Yes. Or hyperscript as my parent posted. I'd love to see an example of preact with it. But looking at the repo https://github.com/hyperhype/hyperscript I have a hard time imagining how preact can work together. They seem to overlap in functionality.

You can either use their native `h` (basically createElement in React)

https://preactjs.com/guide/v10/tutorial/

or you can use the full hyperscript markup library

https://github.com/queckezz/preact-hyperscript

Re: You might not need jQuery (2014)

#223

Post by HiJon89 »

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 think this misses the point, which is called out directly at the top of the site:

"jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.

If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency."

If you're shipping a big application and need to use a large number of these utilities, by all means use jQuery. But if you're shipping a small library and only need one or two of these functions, you might want to forgo the dependency. Using jQuery in your library forces it as a dependency onto everyone who uses your library, potentially making them deal with version conflicts if your version of jQuery doesn't align with their version of jQuery (or the version that another dependency wants).

Re: You might not need jQuery (2014)

#224

Post by satyrnein »

arp242 wrote: post #147
satyrnein wrote: post #142

Earlier quoted context omitted.

I think they are referring to loading it from a global CDN.

Yes, those aren't cached globally any more. https://arstechnica.com/gadgets/2020/12/firefox-v85-will-imp... https://developers.google.com/web/updates/2020/10/http-cache...

Thanks, I didn't know that!

Re: You might not need jQuery (2014)

#225

Post by Viliam1234 »

ryanbrunner wrote: post #139
tomtomtom777 wrote: post #136

Earlier quoted context omitted.

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.

Not a front-end developer, but could this simply be a generational issue? Every framework invented before my career is a clumsy dinosaur, every framework invented during my career is the silver bullet that will solve all problems...

Re: You might not need jQuery (2014)

#226

Post by jrumbut »

martin_a wrote: post #202
spicybright wrote: post #183

Earlier quoted context omitted.

I'm so sorry. Do you want to talk about it? :P

I'm not sure. It was kind of traumatic, but on the other hand it's a very old site, so it was obvious that there might be some dead bodies in the basement. Found one, ignored the others.

The IE 7 compatibility code broke the site in modern browsers, or did you really get a visitor on a Windows 98 machine?

Re: You might not need jQuery (2014)

#227

Post by galaxyLogic »

3131s wrote: post #103
DarkWiiPlayer wrote: post #100

Earlier quoted context omitted.

You'd end up writing a subset of jQuery that only has the parts you need and skips those where you almost wouldn't gain anything.

Well, except that jQuery and a number of third parties have already extracted or ported various subsets of jQuery and have packaged it already for easy integration.

That's a good solution if you need such a subset. But maybe you need just a single function.

And maybe such a single function is currently already provided by the browser APIs.

Or maybe there are packages of individual functions of JQuery? But that would serve little purpose IF the functionality is provided by current browsers.

In any case I think the article serves a good purpose in explaining what are the most useful parts of JQuery and how you could implement them yourself with the more modern browsers if and when you need them.

My preference is to avoid dependencies if I can and prefer depending on my own code which uses standard APIs if possible.

Re: You might not need jQuery (2014)

#228

Post by galaxyLogic »

catmanjan wrote: post #146
DarkWiiPlayer wrote: post #100

Earlier quoted context omitted.

You'd end up writing a subset of jQuery that only has the parts you need and skips those where you almost wouldn't gain anything.

Over time you end up adding just about everything back in as the app grows... But worse!

Probably not for any given single app. Some apps need more JQuery-like functionality some less

Re: You might not need jQuery (2014)

#229

Post by galaxyLogic »

cheph wrote: post #80
galaxyLogic wrote: post #76

Earlier quoted context omitted.

> In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative But isn't the point here that you can wrap the 10-15 lines into your own function which you can then call with just a single line of code? So you "might not need JQuery" because you can program it yourself following the examples given, and can choose which parts of it you need and want to packag…

> So you "might not need JQuery" because you can program it yourself following the examples given, and can choose which parts of it you need and want to package with your app. You could do that for any software, not sure what you gain from doing it though.

Your app becomes smaller and easier to maintain and understand because it has fewer dependencies.

Of course if you need much of the functionality of JQuery then it is a perfect fit for you.

Note there is a cost to JQuery associated with learning and understanding what exactly each function of its API does. If you have paid that cost already by using JQuery and thus learning it, and you need it, then it makes sense to keep on using it.

Re: You might not need jQuery (2014)

#230

Post by WorldMaker »

ryanbrunner wrote: post #139
tomtomtom777 wrote: post #136

Earlier quoted context omitted.

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.

I think a lot of that is the "problems they are solving" and "problems they left behind for the developer". JQuery was built to solve "browser compatibility issues" and left behind things like "component structures of code/code organization", "data-flow organization", and more as out of scope.

Browsers have since mostly fixed "browser compatibility issues" at the standards level, so that problem technically no longer needs solving.

As applications have grown larger those other things that were out of scope for JQuery have become bigger and bigger problems that developers face. (Of the big two I mentioned React solves one, Redux solves the other.)

Some people see JQuery as a "cardinal sin" for the first issue: browsers have already "solved" this, this is a deadweight because it fixes a problem I no longer have. They would have fewer problems with React/Redux/whatever because they solve new problems.

Some people see JQuery as a "cardinal sin" as much for the latter issue: because JQuery was so unopinionated on code structure, data flow, component structure, it led to a lot of real world code that was "JQuery spaghetti" littered with anti-practices like relying heavily on global or might as well be global variables for state information, with no structure to which code might impact which variables and when. Componentizing a JQuery system was often a lot of hard work that JQuery itself didn't help with (and given it's own common usage as a window.$ global with sometimes surprising bits of hidden state inside it, in some cases directly hurt those efforts). Given libraries like React or Redux were designed to solve some of the problems that JQuery once created, it also seems clear why some developers might be very vocally antagonistic to JQuery but have no problem bloating a project with tools that solved those problems and/or have more structure and opinions on building "good" componentized/compartmentalized structures.

Post reply on HN