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

71–80 of 241 posts

Re: You might not need jQuery (2014)

#71

Post by franciscop »

I made Umbrella JS back in the day, a 3kb alternative to jQuery born from the question: You might not need jQuery, then what do you need?

https://umbrellajs.com/

It's heavily inspired by "You might not need jquery" as the intro shows! Lots of the methods are just like in these examples, only with looping/multiple nodes. Example:

$(el).addClass(className); vs el.classList.add(className);

Do not work the same. jQuery (and Umbrella JS) deal with multiple elements and with multiple class names in multiple formats (as a string, as arguments, etc). That's why I find myself still using Umbrella JS from time to time in smaller non-React projects! Just makes everything a lot easier, for 3kb.

Re: You might not need jQuery (2014)

#72

Post by franciscop »

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.

Have you considered some alternatives? I made a 3kb one back in the day (https://umbrellajs.com/) and there are others like Zepto that don't need to deal with the baggage of IE and old browser APIs and still give you the niceties of jQuery.

Re: You might not need jQuery (2014)

#73

Post by varrock »

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

I just want to mention that you are replying to someone who never said anything about SPA. They made an interesting point about trade offs.

Re: You might not need jQuery (2014)

#74

Post by skynet-9000 »

franciscop wrote: post #72
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.

Have you considered some alternatives? I made a 3kb one back in the day ( https://umbrellajs.com/ ) and there are others like Zepto that don't need to deal with the baggage of IE and old browser APIs and still give you the niceties of jQuery.

Very nice, and great site design too.

(BTW, the baggage of supporting old versions of IE was removed when jQuery 2 was launched in 2013. There's now also a "slim" jQuery that removes a few features for a smaller file size.)

Re: You might not need jQuery (2014)

#75

Post by viseztrance »

jart wrote: post #8
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.

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.

Lines of code is a bad metric for complexity.

Jquery is a thin wrapper over javascript, whereas React has a comparable size but is a significantly higher level abstraction.

Re: You might not need jQuery (2014)

#76

Post by galaxyLogic »

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

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 package with your app.

Re: You might not need jQuery (2014)

#77

Post by quattrofan »

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.

As has been seen many times recently third party libraries are a major attack vector for the bad guys.

Re: You might not need jQuery (2014)

#78

Post by franciscop »

skynet-9000 wrote: post #74
franciscop wrote: post #72

Earlier quoted context omitted.

Have you considered some alternatives? I made a 3kb one back in the day ( https://umbrellajs.com/ ) and there are others like Zepto that don't need to deal with the baggage of IE and old browser APIs and still give you the niceties of jQuery.

Very nice, and great site design too. (BTW, the baggage of supporting old versions of IE was removed when jQuery 2 was launched in 2013. There's now also a "slim" jQuery that removes a few features for a smaller file size.)

Thanks! But jQuery has not really moved over, compare "addClass" in jQuery vs UmbrellaJS:

- Umbrella 6 lines (max col 55): https://github.com/franciscop/umbrella/blob/master/src/plugi...

- jQuery 35 lines (max col 83): https://github.com/jquery/jquery/blob/master/src/attributes/...

Yes I reuse methods there to make my life easier like `.eacharg()`, but jQuery as well with `getClass()`. The difference is that UmbrellaJS is using the native `classList.add`, while jQuery is doing string concatenation and cleaning it up heavily. jQuery does not even use `className`, it uses the even older `.setAttribute()`.

Why they cannot just move over? I did try to move them over, the thing is that the edge cases of jQuery were solidified into features as people found them and wrote tests. And jQuery is very big on not breaking behaviour even for small things, so the only way to maintain the current exact behaviour is to have the current exact code, hence you cannot just migrate it over.

Re: You might not need jQuery (2014)

#79

Post by catmanjan »

galaxyLogic wrote: post #76
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 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.

Re: You might not need jQuery (2014)

#80

Post by cheph »

galaxyLogic wrote: post #76
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 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.

Post reply on HN