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

91–100 of 241 posts

Re: You might not need jQuery (2014)

#91

Post by motogpjimbo »

austincheney wrote: post #84
donutdan4114 wrote: post #81

jQuery 3+ minified is 31Kb.... Wtf is the problem with that? Can we just admit that vanilla JS is not ideal and having some abstraction (and tiny bit of page load) is worth it? I am not building web apps that are primary used in Sudan with 1G connection. 31Kb is practically nothing. THIS image is larger than that! http://content.cdn.viber.com/stickers/144/10400/00010400.png

JQuery is orders of magnitude slower than vanilla JS. It’s not about download time but execution time. I am not deliberately trying to punish my users.

Do you use React? In my experience, people arguing against jQuery are usually simultaneously arguing for React as a replacement for it, and are therefore arguing for replacing a ~30kb library with multi-megabyte bundles of catastrophically broken SPA code.

Re: You might not need jQuery (2014)

#92

Post by petecooper »

lmm wrote: post #48
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.

> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Yes, absolutely. That's a total no-brainer. > Hidden complexity you don't control is the most expensive kind I think. There's oodles of hidden complexity you don't control in any modern CPU, but most developers (rightly!) don't care. Complexity you have to fix bugs in is the expensive type, but IME you're far more likely to hit bugs in your cu…

>> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? >Yes, absolutely. That's a total no-brainer.

I'm curious - would you be able to elaborate, please? Thank you.

Re: You might not need jQuery (2014)

#93

Post by asiando »

jamiesonbecker wrote: post #45
peanut_worm wrote: post #40

Earlier quoted context omitted.

This is all very old javascript to be fair, the modern equivalents are as terse as jquery these days.

Somewhat true, but this was also old jQuery :) Even the old jQuery seems easier to read than the modern ES6 equivalent (IMO). jQuery: $(".classname").addClass("darktheme") ES6: document.querySelector(".classname").classList.add("darktheme")

Yes but the former will silently fail on you. Good luck finding that!

Re: You might not need jQuery (2014)

#94

Post by austincheney »

motogpjimbo wrote: post #91
austincheney wrote: post #84

Earlier quoted context omitted.

JQuery is orders of magnitude slower than vanilla JS. It’s not about download time but execution time. I am not deliberately trying to punish my users.

Do you use React? In my experience, people arguing against jQuery are usually simultaneously arguing for React as a replacement for it, and are therefore arguing for replacing a ~30kb library with multi-megabyte bundles of catastrophically broken SPA code.

I do not, but Angular is worse. Last I looked it’s a 300mb download after installing the npm dependencies.

Re: You might not need jQuery (2014)

#95

Post by asiando »

jamiesonbecker wrote: post #13
brundolf wrote: post #11

Earlier quoted context omitted.

Worth noting is that at least in the animation case, the non-jQuery (CSS) version should perform better than the jQuery version

Are you sure? AFAIR, jQuery has used native (hardware-accelerated) CSS transforms since 2014.

Assuming you meant "CSS Transitions": No, jQuery uses requestAnimationFrame.

* "CSS transforms" are unrelated to animations.

Re: You might not need jQuery (2014)

#96

Post by joshxyz »

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

Re: You might not need jQuery (2014)

#97

Post by robertlagrant »

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?"

Good point: different JS people have different opinions on tradeoffs.

Re: You might not need jQuery (2014)

#98

Post by deergomoo »

jjcm wrote: post #86
cocktailpeanuts wrote: post #3

What we need in 2021 is not this site, it's a youmightnotneedreact.com

I would say that this corollary would only be possible once webcomponents have form support in all browsers. In my opinion this is the last major hurdle before there is a native alternative for reusable components in the browser. Firefox is working on it[1] but there's no current roadmap for the work for Safari (though the initial form element proposal was well received by their team). [1] https://bugzilla.mozilla.or…

The Shadow DOM spec always seemed like a good idea poorly implemented to me.

As well as the form issue, what made webcomponents untenable for me was that you can't use slots without opting the whole component into CSS encapsulation.

Great if you want to distribute components without fear of the consumer's CSS messing with your styles, absolutely useless if you want to extract common patterns in your own app because now you have to duplicate the relevant CSS in every component.

Re: You might not need jQuery (2014)

#99

Post by csande17 »

acemarke wrote: post #69
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.

Hi, I'm a Redux maintainer. Please note that "modern Redux" code is very different than what most older tutorials show. We've introduced newer APIs like Redux Toolkit, which is a set of utilities that provide a light abstraction to simplify the most common Redux tasks, and the React-Redux hooks API, which is generally easier to use than the traditional `connect` API. I strongly recommend reading through the newly rew…

> 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.

Re: You might not need jQuery (2014)

#100

Post by DarkWiiPlayer »

catmanjan wrote: post #79
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…

I've done this before - you just end up rewriting jQuery hehe.

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.
Post reply on HN