Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

jQuery 4

blog.jquery.com

Post reply on HN
Print view View original

131–140 of 313 posts

Re: jQuery 4

#131

Post by eloisius »

gbalduzzi wrote: post #56
flomo wrote: post #51

Whenever HTMX comes up here, I always think "isn't that just some gobbledy-gook which replaces about 3 lines of imperative jquery?" Anyway, jQuery always did the job, use it forever if it solves your problems.

The problem with jQuery is that, being imperative, it quickly becomes complex when you need to handle more than one thing because you need to cover imperatively all cases.

Part of me feels the same way, and ~2015 me was full on SPA believer, but nowadays I sigh a little sigh of relief when I land on a site with the aesthetic markers of PHP and jQuery and not whatever Facebook Marketplace is made out of. Not saying I’d personally want to code in either of them, but I appreciate that they work (or fail) predictably, and usually don’t grind my browser tab to a halt. Maybe it’s because sites that used jQuery and survived, survived because they didn’t exceed a very low threshold of complexity.

Re: jQuery 4

#132

Post by adzm »

hsbauauvhabzb wrote: post #73
flomo wrote: post #51

Whenever HTMX comes up here, I always think "isn't that just some gobbledy-gook which replaces about 3 lines of imperative jquery?" Anyway, jQuery always did the job, use it forever if it solves your problems.

These days I’ve moved to native JS, but hot damn the $() selector interface was elegant and minimal vs document.getElement[s]by[attribute)]. While presumably jquery is slower than native selectors, maybe that could be pre-computed away.

The $ (and $$) selector functions live on in chrome/chromium devtools!

Re: jQuery 4

#133

Post by temporallobe »

admiralrohan wrote: post #126

What is the usecase for this in the age of React, NextJS? And for static sites we have Astro etc. And even if you need something simple why use jQuery? Vanila JS has better API now. Am I missing anything?

I do a lot of custom JS widget development, games, and utilities that are outside the context of a gigantic framework like React. Not everything is a a full-page SPA. Vanilla JS is indeed better than it was, but I found myself writing small JQ-like libraries and utilities to do tedious or even basic DOM manipulation, so I switched back to JQ and saved myself a lot of time and headaches. Compressed, minified JQ is also pretty small and is negligible in space consumption.

JQ is also used in frameworks like Bootstrap (although I think they’re trying to drop third-party dependencies like this since they tend to cause conflicts).

I have also used JQ in an Angular app where complex on-the-fly DOM manipulation just isn’t practical with standard tooling.

Re: jQuery 4

#134

Post by hotgeart »

admiralrohan wrote: post #126

What is the usecase for this in the age of React, NextJS? And for static sites we have Astro etc. And even if you need something simple why use jQuery? Vanila JS has better API now. Am I missing anything?

Hobbyists don’t want to learn every new framework. Someone can have a small business website for their activity and have been happy using jQuery since 2010.

Re: jQuery 4

#135

Post by Sammi »

lioeters wrote: post #76
blakewatson wrote: post #20

Related: This is a nice write-up of how to write reactive jQuery. It's presented as an alternative to jQuery spaghetti code, in the context of being in a legacy codebase where you might not have access to newer frameworks. https://css-tricks.com/reactive-jquery-for-spaghetti-fied-le...

This brought me flashbacks of jQuery spaghetti monsters from years ago, some were Backbone related. In retrospect, over-engineered React code can be worse than decently organized jQuery code, but some jQuery mess was worse than any React code. So I guess I'm saying, React did raise the bar and standard of quality - but it can get to be too much, sometimes a judicious use of old familiar tool gets the job done.

I hear you saying that React raised the floor but also lowered the ceiling.

Re: jQuery 4

#136

Post by Sammi »

jraph wrote: post #130
hyperhello wrote: post #122

Earlier quoted context omitted.

body.qsa('.class').forEach(e=>): Yes, add qs() and Array.from(qsa()) aliases to the Node prototype, and .body to the window, and you’ve saved yourself thousands of keystrokes. Then you can get creative with Proxy if you want to, but I never saw the need.

Please don't mess with native prototypes though.

Agree if you've a library developer. If you're an app or website developer then it's your project. Everyone else should steer clear of adding to native prototypes, just so they are clean for the end user.

Re: jQuery 4

#137

Post by mb2100 »

blakewatson wrote: post #20

Related: This is a nice write-up of how to write reactive jQuery. It's presented as an alternative to jQuery spaghetti code, in the context of being in a legacy codebase where you might not have access to newer frameworks. https://css-tricks.com/reactive-jquery-for-spaghetti-fied-le...

That's a very nice pattern indeed. If you add signals, the update function even gets called automatically. That's basically what we do in [Reactive Mastro](https://mastrojs.github.io/reactive/) ;-)

Re: jQuery 4

#138

Post by jraph »

Sammi wrote: post #136
jraph wrote: post #130

Earlier quoted context omitted.

Please don't mess with native prototypes though.

Agree if you've a library developer. If you're an app or website developer then it's your project. Everyone else should steer clear of adding to native prototypes, just so they are clean for the end user.

If you are an app or website developer, at least you won't break other's systems.

But you might still break stuff in your own projects. Imagine you extend a native prototype with a method, and later the native prototype starts having a method with the same name.

Newer libraries start using that new standard method.

You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code.

It only works if you ever works on projects that have zero dependencies, or dependencies you never update.

Or you could spare yourself the troubles and define a method that takes the node in parameter.

It's also a question of forming good habits: you could be working on your projects now, forming a habit of extending prototypes, but will you remember not to do this the day you write a library?

By the way, how can you be sure you won't move some of your app code to a library because you like your utility functions and would like to reuse them in another project of yours? And why not open source that shared code, so you can just install it with NPM? Bam, that stuff is a library now.

Re: jQuery 4

#139

Post by sethaurus »

niek_pas wrote: post #69
ulrischa wrote: post #44

I still love the simplicity a ajax call can be done in Jquery

What does jQuery provide that the Fetch API doesn’t?

Upload progress. The Fetch API offers no way observe and display progress when uploading a file (or making any large request). jQuery makes this possible via the `xhr` callback.

Re: jQuery 4

#140

Post by nchmy »

madduci wrote: post #33

This is huge. jQuery is still my way to go for any website requiring some custom interaction that isn't available in vanilla js.

What isn't available in vanilla js?
Post reply on HN