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

231–240 of 241 posts

Re: You might not need jQuery (2014)

#231

Post by WorldMaker »

ryanbrunner wrote: post #140
graftak wrote: post #83

Earlier quoted context omitted.

jQuery is immune to modern optimisation techniques such as three shaking (only including the modules actually used) because it’s fluent interface makes it a gorilla that holds quite a few bananas, even if you only need one of the bananas.

I would imagine the percentage of front end projects that have a build chain sophisticated enough that tree shaking is important and where 30 KB has a significant impact on their bundle size is vanishingly small.

Tree-shaking isn't a sophisticated feature with ES2015 modules and it's more surprising today when build chains don't support it. (The sophisticated features come into play doing any sort of tree-shaking on older module types such as CommonJS or UMD.)

It's not even a build-chain only feature at this point. Some of the reasons the ES2015 module format was built the way that it was were exactly so that browsers can do their own tree-shaking of runtime code. Even if you don't save on the performance impact of the extra 30 KB from being downloaded, in modern enough browsers you would potentially still see a performance impact on browser memory usage and JIT compilation time.

Even if your bundle size has bloated to a MB already, a 30 KB savings is still roughly a 3.3% savings. It's still noticeable. Whether that is "significant" is an argument of personal taste and how many "9s of performance" you try to deliver. Even single digit percentage savings can be huge "significant" wins for many projects.

Re: You might not need jQuery (2014)

#233

Post by franciscop »

jamiesonbecker wrote: post #215
franciscop wrote: post #78

Earlier quoted context omitted.

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

Yes the "Why they cannot just move over?" was a rhetorical question since I was just explaining that. The larger point being that jQuery being still stuck in doing things manually is detrimental, hence devs could/should consider small modern alternatives even if they want an API similar to jQuery.

Re: You might not need jQuery (2014)

#234

Post by preommr »

ratww wrote: post #158
jjcm wrote: post #86

Earlier quoted context omitted.

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

We need a better term for front-end-js-frameworks than to keep typing react/vue, or variations of it like react/vue/angular, react/vue/svelte, react/vue/angular/svelte,

Re: You might not need jQuery (2014)

#235

Post by lmm »

capableweb wrote: post #127
lmm wrote: post #48

Earlier quoted context omitted.

> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Yes, absolutely. That's a total no-brainer. > Hidden complexity you don't control is the most expensive kind I think. There's oodles of hidden complexity you don't control in any modern CPU, but most developers (rightly!) don't care. Complexity you have to fix bugs in is the expensive type, but IME you're far more likely to hit bugs in your cu…

> > Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? > Yes, absolutely. That's a total no-brainer. That's what we've been thought but it's not a no brainer at all. Context matters, but you disregard it and only focus on the lines of code, just as the author of the comment you respond to is saying people do. You're building a marketing page that's not gonna be updated after completed and only g…

> You're trying to build a fast and slim UI that's gonna be deployed on routers and possibly loaded on low-power devices? You better care about every single line that gets loaded on the device.

Unless you've gone out of your way to buy a (more expensive) part with less memory, your router will have enough memory to make 86.1Kb an utter irrelevancy; so will most of what were traditionally considered "low-power devices". Yes there are extreme cases where it matters, but we're talking about a vanishingly rare proportion of use cases.

> I'm not saying dependencies are always wrong. I'm also not saying it's always right. I'm saying why you need the dependency and the quality of the code it includes is important to consider, and knee-jerk reactions of "of course I'd use it" is hurting the profession more than the library reuse saves us currently.

I think this is backwards, and the knee-jerk reaction of "of course it's important and you need to carefully think about it" is what's holding back the industry. The overwhelming majority of the time, the right thing is to use the dependency; the best development practice is to default to using dependencies and reassess if and when it you hit an actual problem.

Re: You might not need jQuery (2014)

#236

Post by lmm »

petecooper wrote: post #92
lmm wrote: post #48

Earlier quoted context omitted.

> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Yes, absolutely. That's a total no-brainer. > Hidden complexity you don't control is the most expensive kind I think. There's oodles of hidden complexity you don't control in any modern CPU, but most developers (rightly!) don't care. Complexity you have to fix bugs in is the expensive type, but IME you're far more likely to hit bugs in your cu…

>> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? >Yes, absolutely. That's a total no-brainer. I'm curious - would you be able to elaborate, please? Thank you.

Just look at the cost-benefit. Typically internal code has a defect rate of around 1/1000 lines, so 10-15 lines is about 0.01 bugs. 86.1Kb of an established, widely used library is a cost that I can't meaningfully distinguish from zero.

Re: You might not need jQuery (2014)

#237

Post by martin_a »

jrumbut wrote: post #226
martin_a wrote: post #202

Earlier quoted context omitted.

I'm not sure. It was kind of traumatic, but on the other hand it's a very old site, so it was obvious that there might be some dead bodies in the basement. Found one, ignored the others.

The IE 7 compatibility code broke the site in modern browsers, or did you really get a visitor on a Windows 98 machine?

It was a bug in an old version of superfish.js which relied on a deprecated jQuery function to detect the browser. $.browser broke in the new(er/est) version of jQuery which is integrated in that site.

Re: You might not need jQuery (2014)

#238

Post by inopinatus »

marlowe221 wrote: post #192
inopinatus wrote: post #156

Earlier quoted context omitted.

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

As new web developer, I would LOVE to learn how to do this kind of thing purely in CSS!

My process:

* trial

* error

* reading the HTML, DOM, and CSS standards documents very thoroughly end-to-end

* stackoverflow

* repeat

Re: You might not need jQuery (2014)

#239

Post by ratww »

preommr wrote: post #234
ratww wrote: post #158

Earlier quoted context omitted.

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

We need a better term for front-end-js-frameworks than to keep typing react/vue, or variations of it like react/vue/angular, react/vue/svelte, react/vue/angular/svelte,

The term is Reactive but I wanted to be more specific.

Re: You might not need jQuery (2014)

#240

Post by abiogenesis »

paxys wrote: post #120
abiogenesis wrote: post #68

Earlier quoted context omitted.

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

Uh, what do you think jQuery is written in?

jQuery is written in JS, but if your code is using jQuery functions you are not writing "vanilla JS" anymore. Otherwise we wouldn't need the term "vanilla JS".

What I meant was inlining the jQuery calls to their equivalent JS snippets, removing the need for including a 80K library if you are not overly dependent on jQuery. It was also a tongue-in-cheek comment.

Post reply on HN