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

191–200 of 241 posts

Re: You might not need jQuery (2014)

#191

Post by wilsonrocks »

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…

I've tried redux toolkit in production and it is a lot better... But I still wouldn't choose redux on balance.

Re: You might not need jQuery (2014)

#192

Post by marlowe221 »

inopinatus wrote: post #156
cocktailpeanuts wrote: post #3

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

I've got a toolkit of pure CSS widgets I privately call "You might not need Javascript". Dropdowns, modal/lightbox, concertina, slideovers, toggles, popover, transitions, no problem. Hacks with :checked are well known, but you can do a ton of stuff with :focus-within, :invalid, :target, :hover, / /[open], grids/flexbox/visibility, and the adjacent-sibling selector. is almost there, although it still needs a JS activa…

As new web developer, I would LOVE to learn how to do this kind of thing purely in CSS!

Re: You might not need jQuery (2014)

#193

Post by brundolf »

brundolf wrote: post #32
jamiesonbecker wrote: post #13

Earlier quoted context omitted.

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

At least in the example on this page, it performs .fadeOut() by changing the opacity via JavaScript instead of using the CSS transition property. You can verify by inspecting the DOM https://api.jquery.com/fadeOut/ Edit: I just realized you said "transforms". Transforms are a separate question from transitions . CSS transforms are concerned with giving an element a different size, rotation, and/or position. Transitio…

Edit: I partly misspoke. I assumed CSS transitions would be nontrivially more performant since it's a more declarative API and the math would be done natively by the browser, but according to MDN the performance difference is negligible in most (though not all) cases if you're using requestAnimationFrame in the JavaScript version: https://developer.mozilla.org/en-US/docs/Web/Performance/CSS...

The main case where CSS transitions are meaningfully faster appears to actually be transforms themselves, because for those the actual transition, too, can be moved to the GPU, whereas a JavaScript-driven transition still has to be run on the main CPU thread.

Re: You might not need jQuery (2014)

#195

Post by austincheney »

glckr wrote: post #160
austincheney wrote: post #132

Earlier quoted context omitted.

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.

> If your code can execute 10x faster without jQuery then the optimization is not premature. One could argue that it is premature if the code doesn't _need_ to run 10x faster.

One could also argue that driving to work is premature if you have two perfectly good legs. All ridiculousness aside a person can invent any absurd excuse to hide from the common practices of their profession.

Re: You might not need jQuery (2014)

#196

Post by simon04 »

mdtrooper wrote: post #113
domenicd wrote: post #44

Earlier quoted context omitted.

I agree this page hasn't aged well, but that's because it's stuck on IE10 as the support level it's targeting. If you don't need to target IE at all (only Edge), then everything becomes simpler. That's not always safe, but that's why you might not need jQuery... For reference: // JSON const data = await (await fetch('/my-url')).json(); // Post await fetch('/my-url', { method: 'POST', body: data }); // Request try { c…

Really thanks, but Android Chromium has support "fetch" too late (2020). Well, I can wait.

You can use a polyfill such as https://github.com/developit/unfetch (500 bytes).

Re: You might not need jQuery (2014)

#197

Post by hajile »

mad182 wrote: post #185
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?"

The size argument against jquery has always dumbfounded me. Bundle sizes in megabytes, "node-modules" folders with thousands of files and hundreds of megabytes are fine for modern web apps, but if you dare to mention jquery, you can bet someone will cry about overhead and waste.

Sites looking to use jQuery most likely aren't doing much more than a few event handlers and an interactive component here or there.

In those cases, I'd argue pReact is superior. It's almost 10x smaller (29kb vs 3.5kb gzipped). It's faster and more structured leading to less maintenance cost and more code reuse. If you use hyperscript, there's also no JSX compilation required.

Re: You might not need jQuery (2014)

#198

Post by schwartzworld »

nate wrote: post #164

I miss jQuery. It's funny that an argument against jQuery is "oh, but you have to load that big thing to access your site", but then we'll create Single Page Apps that then proceed to spend loading json for 10 seconds before we start interacting with them. :)

The techniques listed in that website aren't really used for single-page apps.

They're listing APIs that you used to need jQuery for that are now natively supported by the browser. This is for people still doing the jQuery style of development.

Re: You might not need jQuery (2014)

#199

Post by hu3 »

hajile wrote: post #197
mad182 wrote: post #185

Earlier quoted context omitted.

The size argument against jquery has always dumbfounded me. Bundle sizes in megabytes, "node-modules" folders with thousands of files and hundreds of megabytes are fine for modern web apps, but if you dare to mention jquery, you can bet someone will cry about overhead and waste.

Sites looking to use jQuery most likely aren't doing much more than a few event handlers and an interactive component here or there. In those cases, I'd argue pReact is superior. It's almost 10x smaller (29kb vs 3.5kb gzipped). It's faster and more structured leading to less maintenance cost and more code reuse. If you use hyperscript, there's also no JSX compilation required.

I'd like to learn about usage of preact with hyperlink or similar. Do you know of a repo I can take a look?

Re: You might not need jQuery (2014)

#200

Post by princevegeta89 »

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.

Agree with this. Fancy libraries like React/Vue etc are great, but they require more human resources in terms of development and add more complexity to your development cycles. I am working on a side project and initially got tempted to use Vue for the front-end but once I stepped back and re-thought about it, jQuery was a no-brainer in terms of how much I can achieve in the time I have.
Post reply on HN