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

221–230 of 313 posts

Re: jQuery 4

#221

Post by Capricorn2481 »

epolanski wrote: post #185
bossyTeacher wrote: post #118

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.

Recommending Elm in 2025 is nonsense and I say it as an Elm lover.

As a non Elm lover, Why is that? I think you could freeze every JS frontend framework in time right now and use them for the next decade. JS is very backwards compatible.

It's the ones that do some kind of server connection that introduce vulnerabilities and need active development.

Re: jQuery 4

#222

Post by augusto-moura »

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

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

Re: jQuery 4

#223

Post by thrownaway561 »

Congrats on shipping!!!! It's been a long time since I've written any jQuery but I remember how wonderful it was to work with in the age of browser inconstancies. Thank you EJohn and the team for continuing the project.

Re: jQuery 4

#225

Post by t1234s »

If you are using server side rendering is jQuery or native JS all you need or is is still worth looking into more complicated JS frontends?

Re: jQuery 4

#226

Post by augusto-moura »

t1234s wrote: post #225

If you are using server side rendering is jQuery or native JS all you need or is is still worth looking into more complicated JS frontends?

htmlx[1] is the library for ssr nowadays, and TBH, pretty good option. It removes JS completely from the equation most of the time

[1]: https://htmx.org/

Re: jQuery 4

#227

Post by epolanski »

namtab00 wrote: post #216
epolanski wrote: post #211

Earlier quoted context omitted.

The original developers weren't bootcampers but engineering graduates. And in the same way faang is filled with leetcode blackbelt charlatans writing slop, so is Romania apparently.

Great generalization of an entire country's sector workforce. I'm sure you'd 100% approve of such a statement of your country when based on one anecdotal recount (even if it true).

It's not about Romania or any other country.

I was making a point that whether you graduate or not has little correlation with your capacity of handling higher abstractions and complexity, because neither bootcampers nor engineering graduates have the experience of building complex systems, let alone under time, tech leadership and management pressure.

It is likely that the original authors may have found themselves in a situation where they were tasked to build a trivial form with technologies they were not accustomed to at the request of some superior and they ended writing a soup.

Re: jQuery 4

#228

Post by gejose »

normie3000 wrote: post #187
epolanski wrote: post #180

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.

This sounds like an engineering quality problem rather than a tooling problem.

Well structured redux (or mobx or zustand for that matter) can be highly maintainable & performant, in comparison to a codebase with poorly thought out useState calls littered everywhere and deep levels of prop drilling.

Redux Toolkit has been a nice batteries-included way to use redux for a while now https://redux-toolkit.js.org/

But the popularity of Redux especially in the earlier days of react means there are quite a lot of redux codebases around, and by now many of them are legacy.

Re: jQuery 4

#229

Post by 101008 »

augusto-moura wrote: post #226
t1234s wrote: post #225

If you are using server side rendering is jQuery or native JS all you need or is is still worth looking into more complicated JS frontends?

htmlx[1] is the library for ssr nowadays, and TBH, pretty good option. It removes JS completely from the equation most of the time [1]: https://htmx.org/

Yes, my default to go now is Django + Tailwind with HTMX and celery for background tasks. That alone took me far away.

Re: jQuery 4

#230

Post by cyberax »

docmars wrote: post #147
gmac wrote: post #107

Earlier quoted context omitted.

The problem with React IMHO is it’s so dominant and so annoyingly over-engineered for many problems. I use Mithril and find it much less fuss.

When they started adding new hooks just to work around their own broken component/rendering lifecycle, I knew React was doomed to become a bloated mess. Nobody in their right mind is remembering to use `useDeferredValue` or `useEffectEvent` for their very niche uses. These are a direct result of React's poor component lifecycle design. Compare to Vue's granular lifecycle hooks which give you all the control you need…

How exactly is Vue better? It just introduces more artificial states, as far as I see.

My major problem with React is the way it interacts with async processes, but that's because async processes are inherently tricky to model. Suspense helps, but I don't like it. I very much feel that the intermediate states should be explicit.

Post reply on HN