Live data from Hacker News

jQuery 4

blog.jquery.com

241–250 of 313 posts

Re: jQuery 4

#241

Earlier quoted context omitted.

It's overly verbose, unintuitive and in 2025, having a virtual dom is no longer compulsory to write interactive web apps. If you want to write modern web apps, you can use Svelte. If you want to write web apps truly functionally, you can use Elm. React is the jQuery of our times. It was really helpful in the Angular era but we are living at the dawn of a new era now.

How is it overly verbose? I find it very intuitive, with the exception of useEffect.

React's hello world:

```js

import React from 'https://esm.sh/react@19';

import ReactDOM from 'https://esm.sh/react-dom@19/client';

const root = ReactDOM.createRoot(document.getElementById('root'));

root.render(Hello, world!);

```

---

HTML's hello world:

```html

Hello, world!

```

---

JS's hello world:

Nothing, it was already done in HTML

Re: jQuery 4

#242
post #94
post #84

Earlier quoted context omitted.

What's wrong with React? It made it so much better to build apps vs. spaghetti jQuery. I still have nightmares about jeeping track of jQuery callbacks

The problem with React is that it solved frontend. So the options are to 1. Code React all day and be happy with it. 2. Come up with reasons why it's bad. There are many talented and intellectually curious people in the field which lean towards 2.

It didn't solve frontend, it sold developers one lie (i.e. ui = f(state) ) and managers another (developers are interchangeable gears).

Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them.

Re: jQuery 4

#243

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

In ol'times people used BackboneJS[1] for that purpose. And surprisingly enough, it is still being actively supported[2]. If someone is still using jQuery for legacy reasons, BackboneJS might be a good intermediate step before going for a modern framework. Backbone is pretty light and pretty easy to grasp [1]: https://backbonejs.org/ [2]: https://github.com/jashkenas/backbone/tags

There was a period where BackboneJS models were used as the datastore for React, before Redux took over. I haven't used it like this myself, but could definitely see it as a way to do an incremental rewrite.

Re: jQuery 4

#244

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 is still the way - jQuery or not - for UI where you can't/don't want to use a component library. I use the same approach for my browser extensions, both for page scripts and options pages. Writing features so you update state then re-render also means you get things like automatically applying option changes live in page scripts, rather than having to reload the page, for free. Just receive the updated options and re-run everything.

Browser extension options pages are mostly a form mapped to what you have stored in the Storage API, so implementing them by handling the change event on a wrapping all the options (no manual event listener boilerplate) then calling a render() function which applies classes to relevant elements ( classes are so good for conditionally showing/hiding things without manually touching the DOM), updates all form fields via named form.elements and re-generates any unique UI elements makes it so un-painful to change things without worrying you're missing a manual DOM update somewhere.

My options pages are Zen Garden-ing 5 different browser-specific UI themes from the same markup to match their host browsers, which is a brittle nightmare to maintain in an app which needs to change over time rather than static demo HTML, but once you've tamed the CSS, the state handling and re-rendering is so painless I'm sticking with it for a while yet, even though it would be long-term easier if I used Preact+htm for no-build option components which know what the active theme is and can generate specific UI for it.

My favourite dirty old-school knowledge is still the named global created for an element with an id, why bother selecting an element when it's right there (once you know you need to avoid global name collisions)?. I use those suckers all the time for quick fun stuff and one-off tool pages.

    
      Readers added context they thought people might want to know
    
    
      
    
    Copy
    
      communityNoteCopyButton.addEventListener('click', () => {
        navigator.clipboard.writeText([
          communityNoteHeading.innerText,
          communityNote.value,
        ].join('\n\n'))
        communityNoteCopyButton.innerText = 'Copied'
        setTimeout(() => communityNoteCopyButton.innerText = 'Copy', 1000)
      })
    

Re: jQuery 4

#245

Earlier quoted context omitted.

You reminded me of a time where one of my clients asked me to add a feature on a file uploader written in react/redux. This was early 2021. I kid you not, there were 30+ redux actions chaining in the most incomprehensible ways, the form literally had a textual input, a button to open the file explorer and a submit button. It took few weeks one of their Romanian team to build it and apparently that team was reassigned…

> I kid you not, there were 30+ redux actions chaining in the most incomprehensible ways I 100% believe this, as it describes all the redux codebases I've seen. The library seems to be an antipattern of indirection.

> The library seems to be an antipattern of indirection.

Auto-generated actions from slices are a codified way to do what was once considered an antipattern: Tying an action directly to a single reducer, instead of actions being an action the user could do on a page (which multiple reducers could respond to).

Re: jQuery 4

#246

Earlier quoted context omitted.

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.

>> This brought me flashbacks of jQuery spaghetti monsters from years ago, some were Backbone related. To be fair, jQuery was a response to the the IE and JS variant mess of the early 2000s. jQuery made development possible without debugging across three browser varients.

Standardized selectors was the big use case for me

Re: jQuery 4

#247
For the record, JQuery is NOT to blame for the so called spaghetti code. Most people seem to blame JQuery for their own short coming. Most people also do not seem to understand the genius that was contained in JQuery. See "http://eyeandtea.com/crxcmp" for an example of what could already be done with JQuery in the IE8 era. A lot of the things later invented in the browser were to mask these shortcomings instead of admitting to them. The shadow DOM is one example. JQuery already had a feature that rendered the shadow DOM unnecessary, but it would require discipline that most developers did not have nor understand.

Having said that, after JQuery 1.x, and in particular, the changing, the deprecating, and the dropping of things here and there, JQuery no longer made sense. Somewhat similar to the SDL situation in the C/C++ word. An important role of JQuery, similar to SDL, was a strong code contract before anything else, and if the developer now has to account for JQuery's version differences like having to account for browser differences, what is the point.

Re: jQuery 4

#248
post #15

Still one of my favourite libs on the whole planet. I will always love jQuery. It is responsible for my career in (real) companies. Live on jQuery! Go forth and multiply!

I love tech hype cycles haha, I remember when you got laughed at for using jquery and now it seems everyone’s burned out and happy to go back to a simpler time

Re: jQuery 4

#249

Ive never been a frontend guy, although I was a heavy user of jquery when I needed it. But I cant help but stick to my roots.... LONG LIVE PROTOYPE!

Prototype was great when it first landed but I found jQuery to be so much more elegant and fluid. For example, the overloaded $(...) which I'm pretty certain we have to thank for querySelectorAll.

Re: jQuery 4

#250
post #140
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?

I think it's probably a matter of things being easier: show()/hide() or simple animations versus futzing with style properties and CSS animations.
Post reply on HN