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

151–160 of 241 posts

Re: You might not need jQuery (2014)

#151

Post by ratww »

ryanbrunner wrote: post #143
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")

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'));

Re: You might not need jQuery (2014)

#152

Post by ritchiea »

cocktailpeanuts wrote: post #3

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

Doesn't everyone know you don't need React? That it's a choice?

That said, I was once a single page app skeptic but I now think React and Vue are great alternatives to HTML/templates that compile to HTML if you have a reasonably complex front end. Pre-React and Vue, in the Angular.js/Ember.js/Backbone era, SPAs were not in a stage of maturity that made it simple or optimal to use them as a primary front end. Today I'd say for a complex FE go ahead with React or Vue, if you have a very simple FE, definitely consider HTML/template-to-HTML as a serious option.

Re: You might not need jQuery (2014)

#153

Post by Dudeman112 »

onion2k wrote: post #33
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 would prefer web developers accepted they need to write a few hundred lines of 'ugly' vanilla JS to drive their website than they include a 30KB library that they only really use 0.2KB of. On the web, user experience should really be a higher priority than developer experience.

If your website has two non thumbnail images in it, the 30KB library is gonna become a rounding error in the load time

Re: You might not need jQuery (2014)

#154

Post by mhd »

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.

But think of the react video course makers and router re-implementors!

Re: You might not need jQuery (2014)

#155

Post by user3939382 »

codeisawesome wrote: post #47
jrumbut wrote: post #42

Earlier quoted context omitted.

document.querySelector was not available in IE 6 and 7. Dealing with those versions was where jQuery really earned its spot in the JS universe. It was a lot to remember where all the quirks were and the incantations to work around them.

IE 6. Now that's a name I haven't heard in a long time...

The longer the better. What a neverending nightmare it was.

Re: You might not need jQuery (2014)

#156

Post by inopinatus »

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 activation hook.

It feels really good to have a complete application UI that works with JS disabled, and I can still progressively enhance it with JS for necessary perversions of HTML like ARIA etc.

Re: You might not need jQuery (2014)

#157

Post by spiralx »

porker wrote: post #121
jarek-foksa wrote: post #109

Earlier quoted context omitted.

With modern JavaScript you can easily cast a NodeList to an Array, e.g. `let spansArray = [...element.querySelectorAll("span")]`. I find both `element.nextElementSibling` and `element.next()` to be examples of poor API design. The former one is more verbose than needed while the latter one is so short you can't even tell whether it's a method or a property.

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

Before that ES2015 allowed you to do Array.from(nodeList, mapFunc?) which I still use due to the optional mapping function e.g. Array.from(document.querySelectorAll('a'), a => a.href)

Re: You might not need jQuery (2014)

#158

Post by ratww »

jjcm wrote: post #86
cocktailpeanuts wrote: post #3

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

I would say that this corollary would only be possible once webcomponents have form support in all browsers. In my opinion this is the last major hurdle before there is a native alternative for reusable components in the browser. Firefox is working on it[1] but there's no current roadmap for the work for Safari (though the initial form element proposal was well received by their team). [1] https://bugzilla.mozilla.or…

I don't think it will replace React, honestly.

WebComponents can do just a fraction of what React/Vue do, and it's just the least interesting parts. The encapsulation is great, of course, but it was already possible to have "reusable components" back in the jQuery days and before.

All the WebComponents usage I've seen professionally lately were wrapping React/Vue or using some other lightweight framework that does something similar.

Not saying WCs are bad tech: just saying I think there are some great ideas in Vue/React that still don't have a native API. Would LOVE to see a new version of WebComponents adopting some of those ideas (only the good ones though haha)!

Re: You might not need jQuery (2014)

#159

Post by ozim »

austincheney wrote: post #132
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.

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.

"optimization - an act, process, or methodology of making something (such as a design, system, or decision) as fully perfect, functional, or effective as possible"

If you optimize process of delivering feature to the end user then using JQuery is optimization and not premature. It does not have to be optimization of runtime/load time.

Re: You might not need jQuery (2014)

#160

Post by glckr »

austincheney wrote: post #132
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.

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.

Post reply on HN