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

61–70 of 241 posts

Re: You might not need jQuery (2014)

#61

Post by heleninboodler »

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.

> In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative.

"Every single example?" Are we reading the same page? I was fairly surprised to find that 75% of the alternatives are literally one-liners. There are a handful that swell up to 10-15 lines of code, but I would say it's a very small portion, far from "every single example."

Re: You might not need jQuery (2014)

#62

Post by jamiesonbecker »

arp242 wrote: post #58
jamiesonbecker wrote: post #45

Earlier quoted context omitted.

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

There are quite a few more examples of this: $('.class').remove() $('.class').after(...) vs: var e = document.querySelector('.class') e.parentNode.removeChild(e) document.querySelector('.class').insertAdjacentElement('afterend', ...)

This kind of code grows explosively in a moderately-sized project, and the sheer volume and verbosity makes it hard to debug. Not to mention requiring more tylenol ;)

Re: You might not need jQuery (2014)

#63

Post by [deleted] »

franklyt wrote: post #24
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 haven't gone this far, but I still like lodash. It feels like it fleshes out a too-light core JS lib.

[deleted]

Re: You might not need jQuery (2014)

#64

Post by jamiesonbecker »

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…

Fair point. Thanks for bringing it up!

Re: You might not need jQuery (2014)

#65

Post by _slyo »

jQuery is fantastic. I am not a web programmer by trade, but I can always get busy with jQuery and just a couple of Google searches.

Last weekend I was trying to find new car dealerships in my region that carried a particular model of car that I'm interested in. They had a dealer search page that could return all dealerships within 250 miles, and they had an inventory search page that had hardcoded the 3 nearest dealership IDs into the URL. But they had no GUI to search all the cars for all the dealers in my region.

I poked around at the elements on the dealership search page, cobbled together a jQuery one-liner to dump all the dealership IDs in my region, and pasted those into the URL to finally see every individual car in my region of the model I wanted. The page took quite a while to load, so probably have have some DoS vulnerabilities to deal with, but at least I was happy.

Vanilla javascript would have been so much more cumbersome!

Re: You might not need jQuery (2014)

#68

Post by abiogenesis »

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.

What we need is a Jquery-to-VanillaJS transpiler.

Re: You might not need jQuery (2014)

#69

Post by acemarke »

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 rewritten official tutorials in the Redux docs, which have been specifically designed to show our recommended practices:

- "Redux Essentials" tutorial [0]: teaches "how to use Redux, the right way", by building a real-world app using Redux Toolkit - "Redux Fundamentals" tutorial [1]: teaches "how Redux works, from the bottom up", by showing how to write Redux code by hand and why standard usage patterns exist, and how Redux Toolkit simplifies those patterns

The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today.

You should also check out the Redux "Style Guide" docs page [2], which explains our recommended patterns and best practices, and why they exist. Following those will result in better and more maintainable Redux apps.

[0] https://redux.js.org/tutorials/essentials/part-1-overview-co...

[1] https://redux.js.org/tutorials/fundamentals/part-1-overview

[2] https://redux.js.org/style-guide/style-guide

Re: You might not need jQuery (2014)

#70

Post by toper-centage »

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

That's a very good point. We have been hating JQuery for so long, that we didn't notice that it's size when down while app size inflation grew exponentially. 15 years ago loading 50kb of bloat was reason to worry, today no one bats an eye.
Post reply on HN