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

171–180 of 241 posts

Re: You might not need jQuery (2014)

#171

Post by ratww »

leetrout wrote: post #26
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.

There really isn’t a good middle ground yet. Look at svelte if you haven’t.

I like Svelte too, but I find Preact with HTM[1] is more of a middle ground. Or Preact + Domz [2] if you're not into the HTM syntax.

It doesn't have a compilation phase but it allows us to use Preact, and it's only 5k.

[1] https://www.npmjs.com/package/htm

[2] https://www.npmjs.com/package/domz

Re: You might not need jQuery (2014)

#172

Post by Wintamute »

inbx0 wrote: post #118
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…

Your fetch examples don't reject the promise if the server responds with error status code, like 404, which is probably not what you'd want. You'd need to handle that separately with something like const resp = await fetch('/my-url') if (!resp.ok) throw new Error(await resp.text()) const data = await resp.json() From MDN ( https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API ): > The Promise returned from fetch…

I know this pattern and have used it myself. The problem is though, that generally you should only throw an error when you reach an exception - it's like saying "I don't know what to do next", and you defer that decision up the stack.

Is a request that technically succeeds (the response has come back), but has a status code where the server has indicated something didn't work always an _exception_ in your client code? I'd argue it isn't, and should just be handled in the normal control flow of your client code via conditionals.

Re: You might not need jQuery (2014)

#173

Post by kebman »

DangerousPie wrote: post #161

I bought into this a few years ago and ended up regretting it. My code has become much harder to maintain and read due to all the extra boilerplate code, and it probably has hidden bugs and compatibility issues that I'm not even aware of. And for some things I still ended up requiring jQuery, because they just weren't feasible to do in vanilla JS. I have actually gone back to making heavier use of jQuery again these…

I guess the irony is that jQuery is indeed written in JavaScript, so whatever you set out to do is still "feasible to do in vanilla JS." With that said the main difference is of course that there's far more people involved in maintaining jQuery than there is on most people's individual codebases. Personally I try to make do without it, if nothing else than because it forces me to learn JavaScript better.

Re: You might not need jQuery (2014)

#174

Post by fabiospampinato »

I'd suggest to anybody wanting a thin wrapper over the DOM to just go with Cash [1] instead, which I maintain.

Cash is largely a drop-in replacement for jQuery Slim at a significantly smaller size (~6kb vs ~24kb min+gzip).

The methods listed in youmightnotneedjquery.com are a little simplistic/buggy at times and not tested, if you just need a single method from jQuery it would probably be a better idea to simply copy/paste it from Cash.

[1]: https://github.com/fabiospampinato/cash

Re: You might not need jQuery (2014)

#175

Post by donapieppo »

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.

> 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

To me this seems a comment that only stands for one-developer projects.

Re: You might not need jQuery (2014)

#176

Post by iaml »

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.

Why do you think you can only write multi-megabyte apps with react? And why do you think those two are the only options? You can write decently sized react code that's 300-500 kb bundled and if you're not ok with that you can start dynamically loading dependecies. Companies just choose to not spend any time optimizing it.

Re: You might not need jQuery (2014)

#177

Post by vagrantJin »

bichiliad wrote: post #10
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 a lot of the initial appeal around jQuery was that it made querying and manipulating the DOM simple. Much of its features have been replaced by broadly-available APIs like Document.querySelector and Element.classList. Loading the entirety of jQuery just to access some of the remaining features just means you're loading JavaScript that you aren't going to use. I miss relying on jQuery because it's familiar and…

Jquery isn't going anywhere. It might take a few weeks to get a JNR dev up to speed with native dom apis. It'll take a few hours for them to grasp jquery and begin writing working spaghetti in no time at all.

> Loading the entirety of jQuery just to access some of the remaining features just means you're loading JavaScript that you aren't going to use

Isn't this the penalty for every single library we use. At most we can use about 20% and the rest is just out taking space.

Re: You might not need jQuery (2014)

#178

Post by mejutoco »

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

Agree. Even before getting into things like: $(".classname").closest(".container").addClass("active”);

I do not get the hate over jquery, specially since frameworks like angular used (use?) to include a light version of it (sizzle or similar?) and methods like $httpParamSerializerJQLike, which does not scream of elegance.

I still remember when prototype.js was the default in rails, and jquery was so less overengineered and it just worked. It felt like magic.

Re: You might not need jQuery (2014)

#179

Post by mejutoco »

asiando wrote: post #93
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")

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

This is probably a feature. The non-jquery version will need a check for the elements existance to not blow up, which could the same be added to the jquery version for error reporting.

Plus, in this case, you will find out by seeing the dark theme is not active :p

Re: You might not need jQuery (2014)

#180

Post by jarek-foksa »

nicoburns wrote: post #137
porker wrote: post #121

Earlier quoted context omitted.

> With modern JavaScript you can easily cast a NodeList to an Array, e.g. Ah, thanks. I got bitten by this recently and didn't know what to do with this "thing that's not an array but seems like it should be, and doesn't always behave like one"

FYI the reason it's not an array is because if you store a reference to it, it will stay up to date as and when the DOM changes.

The NodeList returned by querySelectorAll() is not live. There is really no reason for it to return a NodeList other than backward compatibility.
Post reply on HN