Live data from Hacker News

You might not need jQuery (2014)

youmightnotneedjquery.com

211–220 of 241 posts

Re: You might not need jQuery (2014)

#211

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…

As someone that had to handcraft client-side browser experiences in the early 2000's (think drag and drop, elements of single page applications, etc.), I basically had to write two versions of everything in order to support Netscape and IE. It was tremendously interesting because I was building things that you really didn't see out in the wild at the time. It was also tremendously frustrating dealing with DOM and feature differences.

It's hard to overstate the impact of jQuery. It more than doubled my productivity due to removal of much of the duplicated work AND the general streamlining of DOM manipulation. As someone who was also neck deep in XML and XSD, the element selection syntax also felt reasonably familiar and comfortable.

Re: You might not need jQuery (2014)

#212

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

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 overengineer…

The opinions mostly depend on what people know. The dvorak keyboard might be better?

Re: You might not need jQuery (2014)

#213
post #199
post #197

Earlier quoted context omitted.

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?

I think that's hard to ascertain because it's a drop-in replacement for react. I assume you mean hyperapp instead of hyperlink.

It gets around a half-million downloads per week according to NPM stats while hyperapp gets under 3k per week.

Re: You might not need jQuery (2014)

#214
post #204

It's funny this site doesn't mention dialog - the only feature I'm using that is hard to replace by vanilla JS... jQuery speeds up development, but in most situations it's straightforward to replace. On the other hand, I never remove React (and especially Reagent) from an existing site - too much effort, too much to break.

That's jQueryUI rather than the base jQuery.

Re: You might not need jQuery (2014)

#215

Earlier quoted context omitted.

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 Umbrella…

> jQuery is very big on not breaking behaviour even for small things

You answered your own question :)

Re: You might not need jQuery (2014)

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

"has become"? So will you be using Backbone + Marionette, or one of the other MVC frameworks? Which jQuery plugins will you be needing? Will you be using Require.js, or are you just going to have a big list of script tags? What about Bower? What about backwards compatibility and dependency management and other really boring things? If you have a very simple client that "just" uses the DOM APIs or an abstraction over…

As for "has become" there was a time when it was accepted there were things you didn't do in a browser and it was generally whatever the browser didn't support. If you wanted to do something real wild you'd use some app delivery plugin (java/flash/etc) which just happened to display in the page but that was the extent of involving the browser. Then browsers started supporting some of these abilities natively in response and complexity exploded to try to patch what the browsers shipped with at the time vs what people wanted in total resulting in many tools/libraries/frameworks to deal with the gap. Now the out of the box environment isn't very limited or fractured for the majority of use cases and so we have the option to go back to the simple era where "I can just use what's in the browser" again for most things, except now that generally covers whatever we want to make not "what a webpage should be" like it used to.

Re: You might not need jQuery (2014)

#217
post #151

Earlier quoted context omitted.

Maybe a nit, but these aren't equivalent. The jQuery version will apply it to all elements that match your selector, where the ES6 version will only apply to the first matching element. Equivalent code in ES6 would be (maybe there's a terser way but this is what I'd do at first glance): [...document.querySelectorAll('.className')].forEach(el => el.classList.add('darktheme')); Not a whole lot extra in terms of actual…

You can use forEach without the splat: document.querySelectorAll(".className").forEach(el => el.classList.add('newClass'));

Still doesn't seem like much of a win compared to the jQuery :)

    $(".classname").addClass("darktheme")

Re: You might not need jQuery (2014)

#218
post #210

Earlier quoted context omitted.

Are you being sarcastic? But, either way, it really depends. If you are writing a large application and jQuery saves thousands of lines of boilerplate, then it's totally worth it. For a tiny library (which is what this page is targeted at), then it's probably overkill and you should learn how to do it manually with pure JS. Both can be true at the same time.

It's a serious hurdle when pReact is only 10kb unzipped (13kb with hooks) while jQuery is 89kb. Accounting for 70% average minification and 40 characters per line on average, that's around 6,500 lines of normal code shipped "for free" by using pReact instead where there's both no wire cost and no extra parse time.

[deleted]

Re: You might not need jQuery (2014)

#219
post #118

Earlier quoted context omitted.

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…

The answer probably depends a lot on what you're used to from other languages.

Java users might want to make 404 an exception (FileNotFoundException), C++ users probably wouldn't throw an exception for that

Re: You might not need jQuery (2014)

#220
post #213
post #199

Earlier quoted context omitted.

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

I think that's hard to ascertain because it's a drop-in replacement for react. I assume you mean hyperapp instead of hyperlink. It gets around a half-million downloads per week according to NPM stats while hyperapp gets under 3k per week.

Yes. Or hyperscript as my parent posted. I'd love to see an example of preact with it.

But looking at the repo https://github.com/hyperhype/hyperscript I have a hard time imagining how preact can work together. They seem to overlap in functionality.

Post reply on HN