[HN Gopher] jQuery 4
___________________________________________________________________
jQuery 4
Author : OuterVale
Score : 677 points
Date : 2026-01-18 04:23 UTC (18 hours ago)
(HTM) web link (blog.jquery.com)
(TXT) w3m dump (blog.jquery.com)
| rationably wrote:
| Unbelievably, still supports IE 11 which is scheduled to be
| deprecated in jQuery 5.0
| tartoran wrote:
| Backwards compatibility. Apparently there are still some people
| stuck on IE11. It's nice that jQuery still supports those users
| and the products that they are still running.
| phinnaeus wrote:
| Are those people/products upgrading jQuery though?
| jbullock35 wrote:
| Who is still stuck on IE 11---and why?
| ejmatta wrote:
| Some corporate machines still run XP. Why upgrade what
| works?
| ExpertAdvisor01 wrote:
| SECURITY
| Joel_Mckay wrote:
| Yet it would still run Windows Adware edition. =3
| LtdJorge wrote:
| Use Enterprise
| Joel_Mckay wrote:
| Enterprise Adware? Sounds hilarious to people that
| already paid $190 USD/seat to get spammed.
|
| In general, Windows has always belonged on a VM snapshot
| backing image. =3
| ddtaylor wrote:
| I think anything still using ActiveX like stuff or "native"
| things. Sure, it should all be dead and gone, but some
| might not be and there is no path forward with any of that
| AFAIK.
| flomo wrote:
| There are some really retrograde government and bigcorps,
| running ten year old infrastructure. And if that is your
| customer-base? You do it. Plus I worked on a consumer
| launch site for something you might remember, and we got
| the late requirement for IE7 support, because that's what
| the executives in Japan had. No customers cared, but yeah
| it worked in IE7.
| jbullock35 wrote:
| Oh, certainly, corporations run ten-year-old software.
| But for the record, IE 11 turns 13 this year [1]. Which
| makes it somewhat more surprising to me.
|
| [1] https://en.wikipedia.org/wiki/Internet_Explorer_11
| layer8 wrote:
| Microsoft will support IE 11 until 2032.
| kstrauser wrote:
| My reading is that they'll support Edge's IE 11
| compatibility mode until then, but that IE 11 is already
| EOLed except for a couple of extremely niche enterprise
| versions.
| layer8 wrote:
| The IE 11 desktop application remains supported on a
| number of Windows LTSC versions:
| https://techcommunity.microsoft.com/blog/windows-itpro-
| blog/... At least one of them, Windows 10 IoT LTSC, will
| receive support until 2032.
| simondotau wrote:
| Surely by this point someone has written a 0-day for MSIE
| 11 which gets root and silently installs an Internet
| Explorer skinned Chromium. If not, someone should get onto
| that. --Signed, everyone
| wqweto wrote:
| Last available Chromium on XP has 0-days too, so not a
| big win.
| epolanski wrote:
| One of my clients in the past had, as of 2020, noticeable
| traffic from IE8, 9 and IE11. When I say noticeable I mean
| 10%+ out of million users.
|
| It followed the 8-17 monday-friday pattern.
|
| Essentially it was people at their work machines (posts,
| banks, etc) running corporate computers where modern
| browsers were not installed.
|
| We had a computer for manually testing every release on IE8
| and 9.
|
| If somebody is looking for our products from those
| computers, we aren't gonna lose them.
|
| But as far as I know, that client dropped support for IE8
| and IE9 in 2024 with IE11 planned to be dropped this year.
| kstrauser wrote:
| This is the part that I find the strangest:
|
| > We also dropped support for other very old browsers,
| including Edge Legacy, iOS versions earlier than the last 3,
| Firefox versions earlier than the last 2 (aside from Firefox
| ESR), and Android Browser.
|
| Safari from iOS 16, released in 2022, is more modern in every
| conceivable way than MSIE 11. I'd also bet there are more
| people stuck with iOS 16- than those who can _only_ use IE
| 11, except maybe at companies with horrid IT departments, in
| which case I kind of see this as enabling them to continue to
| suck.
|
| I'd vote to rip the bandaid off. MSIE is dead tech, deader
| than some of the other browsers they're deprecating. Let it
| fade into ignomony as soon as possible.
| sebazzz wrote:
| "Support" here probably means "we're testing jQuery for
| compatibility on those web browsers" - likely Safari from
| iOS 16 still runs this version of jQuery just fine.
| However, running automated test suites or support bugfixing
| for those clients is a lot harder than spinning up some
| Microsoft-provided VM with IE11 on it.
| kstrauser wrote:
| Fair point.
| toyg wrote:
| Also, mobile phones get upgraded/upcycled much faster
| than desktop.
| troupo wrote:
| > Safari from iOS 16, released in 2022, is more modern in
| every conceivable way than MSIE 11.
|
| There are likely millions if not tens of millions of
| computers still running MSIE11. There are likely to be no
| devices running iOS 16
| kstrauser wrote:
| According to Cloudflare, there are almost no users still
| on MSIE of any version.[0]
|
| Statcounter says there are about 4.6% of iOS users still
| on iOS 16.[1]
|
| My gut instinct is that there are multiple times more
| people using iOS 16 today than MSIE of any version.
|
| [0] https://radar.cloudflare.com/reports/browser-market-
| share-20...
|
| [1] https://gs.statcounter.com/os-version-market-
| share/ios/mobil...
| troupo wrote:
| IIRC public counters tend to miss corporate networks.
| kstrauser wrote:
| A jQuery update would miss those quarantined browsers,
| too.
| pmontra wrote:
| I visited a distillery in 2020. Their machines were
| managed by HP laptops running Windows XP. Those machines
| and those laptops and that Windows XP are probably still
| there with their old IE browser.
| wqweto wrote:
| XP support IE8 max
| mortenjorck wrote:
| They will probably be there for as long as the capacitors
| last, but the critical thing is that they are almost
| certainly running some Win32 industrial process software
| with no need for web browsers or for that matter even
| Internet connectivity. In fact I hope they're not on wifi
| given the state of legacy WinXP security!
| SchemaLoad wrote:
| Those machines are probably not connected to the
| internet.
| Strom wrote:
| > There are likely to be no devices running iOS 16
|
| My iPhone X is stuck on iOS 16 with no way to upgrade.
|
| However, the phone is still working well. Despite being
| in daily use for 8 years it still has 81% battery
| capacity, has never been dropped, has a great OLED
| screen, can record 4K@60 video. It is far more responsive
| than a brand new 2025 $200 Android phone from e.g.
| Xiaomi. It still gets security patches from Apple. The
| only real shortcoming compared to a modern iPhone is the
| low light camera performance. That and some app
| developers don't support iOS 16 anymore, so e.g. I can't
| use the ChatGPT app and have to use it via the browser,
| but the Gemini app works fine.
| croes wrote:
| It's rarely a horrid IT department but some special or
| legacy software without modern replacement
| voxic11 wrote:
| But is this horrid legacy software really going to be
| pulling in a new major version of jQuery?
| layer8 wrote:
| There are a lot of intranet web applications that require
| IE, and IE is still in support by Microsoft. Even on
| Windows 11 Edge still has IE Mode for that reason. IPhones
| stuck on older iOS version by definition aren't supported
| by Apple anymore.
| kstrauser wrote:
| Use those browsers for the internal undead apps, but a
| modern browser for the Internet.
|
| Those phones are still supported. The most recent iOS 16
| update was in September 2025.
| ulrischa wrote:
| Not everybody in the world can use modern hard- and software.
| There are tons of school computer labs running old software
| halapro wrote:
| Yes, run jQuery 3.
|
| Crazy to think that software running inside IE11 should use
| the latest version of a library.
| indolering wrote:
| It looks like it was done to not delay the 4.0 release. Since
| they follow semvar, that means it won't get the axe until 5.0
| [1]. Pretty wild considering that 3.0 was released 10 years
| ago.
|
| But maybe they will scope this one better: they were talking
| about getting 4.0 released in 2020 back in 2019!
|
| [1]: https://github.com/jquery/jquery/pull/5077 [2]:
| https://github.com/jquery/jquery/issues/4299
| layer8 wrote:
| Microsoft will support IE 11 until 2032 in Windows 10 LTSC and
| IE Mode in Edge on Windows 11.
| b3ing wrote:
| Nice to see it still around and updated. The sad part is I guess
| this means React will be around in 2060.
| b65e8bee43c2ed0 wrote:
| there are already de facto two Reacts. by 2060, there will be
| five.
| 2muchcoffeeman wrote:
| Two Reacts!?
| exac wrote:
| As someone who doesn't use React, there is React Native
| (for iOS & Android), and React (and that can be server-
| rendered or client-rendered).
| psnehanshu wrote:
| There's also React Native Web
| underdeserver wrote:
| I'm sorry what
| rauli_ wrote:
| In case you want to use React to make Web sites as well.
| neals wrote:
| They should make a version of that runs as an app on a
| phone
| jasongill wrote:
| They have one, it's called React Native Web Native
| afiori wrote:
| I find it is a good idea, it allows developers to cleanly
| define how to structure elements without random divs
| sneaking in.
|
| It requires a strong design system and it probably makes
| it harder to use some web APIs but those can be
| reasonable tradeoffs
| tcoff91 wrote:
| Twitter is built in React Native Web
| atulvi wrote:
| There was also react vr
| tcoff91 wrote:
| class components & function components.
| afiori wrote:
| That is the least interesting divide in the react
| community
| o_m wrote:
| The main divide now is client side React versus Server
| Components usually with a node.js backend
| mikeaskew4 wrote:
| by 2060 React Native should be up to v0.93
| altern8 wrote:
| 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
| lopatin wrote:
| 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.
| gmac wrote:
| 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.
| docmars wrote:
| 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 without
| workarounds, and they're named in a way that make sense.
| [1]
|
| And don't get me started on React's sad excuse for global
| state management with Contexts. A performance nightmare
| full of entire tree rerenders on every state change, even
| if components aren't subscribing to that state. Want
| subscriptions? Gotta hand-roll everything or use a 3rd
| party state library which don't support initialization
| _before_ your components render if your global state
| depends on other state /data in React-land.
|
| 1. https://vuejs.org/api/composition-api-lifecycle.html
| leptons wrote:
| I use Preact, in the old-school way, without any "use-
| whatever" that React introduced. I like it that way. It's
| simple, it's very easy, and I get things done quickly
| without over-thinking it.
| Capricorn2481 wrote:
| I'm all for people avoiding React if they want, but I do
| want to respond to some of this, as someone who has made
| a few React apps for work.
|
| > 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.
|
| Hooks didn't fundamentally change anything. They are ways
| to escape the render loop, which class components already
| had.
|
| > Nobody in their right mind is remembering to use
| `useDeferredValue` or `useEffectEvent` for their very
| niche uses.
|
| Maybe because you don't necessarily need to. But for what
| it's worth, I'm on old versions of React when these
| weren't things, and I've built entire SPAs out without
| them at work. But reading their docs, they seem fine?
|
| > And don't get me started on React's sad excuse for
| global state management with Contexts. A performance
| nightmare full of entire tree rerenders on every state
| change
|
| I think it's good to give context on what a rerender is.
| It's not the same as repainting the DOM, or even in the
| same order of magnitude of CPU cycles. Your entire site
| could rerender from a text input, but you're unlikely to
| notice it even with 10x CPU slowdown in Devtools, unless
| _you_ put something expensive in the render cycle for no
| reason. Indeed, I 've seen people do a fetch request
| every time a text input changes. Meanwhile, if I do the
| same slowdown on Apple Music which is made in Svelte, it
| practically crashes.
|
| But pretty much any other state management library will
| work the way you've described you want.
| cyberax wrote:
| 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.
| bossyTeacher wrote:
| 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.
| mehagar wrote:
| How is it overly verbose?
|
| I find it very intuitive, with the exception of useEffect.
| major_major_ wrote:
| Svelte looks good at first until you realize that to get
| the best support and features you're basically required to
| use the meta framework SvelteKit which sucks.
| ezfe wrote:
| Well yes but that's not related to React: Svelte = React.
| epolanski wrote:
| Recommending Elm in 2025 is nonsense and I say it as an Elm
| lover.
| Capricorn2481 wrote:
| 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.
| epolanski wrote:
| Complex APIs that require intimacy with internals with their
| gotchas.
|
| Complex rendering model and hard to tame lifecycle since they
| ditched the class component. Very hard to get performant
| websites (but you're free to link me what you've produced
| with React and prove me wrong).
|
| Also, biggest issue: severely misused for websites that are
| mostly static content and are nowhere near "app-like" nor
| have any particular reactivity need. 95%+ of react
| "applications" would've benefited from being written with a
| templating language instead.
|
| E.g. Github was miles better under all aspects when it used
| ruby but of course somebody had to sell to upper management
| their promotion case.
| tentacleuno wrote:
| In 2021, they published a post[0] about how they used web
| components, alongside a library called Calalyst. It seemed
| like quite a nice system. I've still seen include-fragment
| elements in the HTML, so I assume they still use it.
|
| [0]: https://github.blog/engineering/architecture-
| optimization/ho...
| maxloh wrote:
| Even after migrating to ES modules, jQuery is still somewhat
| bloated. It is 27 kB (minified + gzipped) [0]. In comparison,
| Preact is only 4.7 kB [1].
|
| [0]: https://bundlephobia.com/package/jquery@4.0.0
|
| [1]: https://bundlephobia.com/package/preact@10.28.2
| onion2k wrote:
| jQuery does a lot more though, and includes support older
| browsers.
| halapro wrote:
| > includes support older browsers
|
| Which is entirely the issue. Supporting a browser for the 10
| users who will update jQuery in 2025 is insane.
| mejutoco wrote:
| Breaking backwards compatibility to turn 27kb into less
| because of "bloat" makes less sense to me.
| shevy-java wrote:
| It is definitely more than 10 users.
| halapro wrote:
| 12
| ZeroAurora wrote:
| Officially they state they only support 2 latest versions of
| chrome. But considering their support of IE11, that's
| actually a lot.
| topspin wrote:
| > Preact is only 4.7 kB
|
| Is there some outlier place where people using virtual DOM
| frameworks don't also include 100-200kb of "ecosystem" in
| addition to the framework?
|
| I suppose anything is possible, but I've never actually seen
| it. I have seen jQuery only sites. You get a lot for ~27kB.
| downsplat wrote:
| I do that when I need to make a simple SPA. Plain Vue plus a
| few tiny add-ons of my own.
| ttoinou wrote:
| Look at Deno + Fresh which is based on preact. You can do a
| lot with preact only
| leptons wrote:
| I use Preact for a very lean build for a front-end that lives
| in a small embedded MCU flash ROM. Gziped the whole front-end
| is about 25KB, including SVG images baked-in to the preact
| gzip file. I'm very careful about the libraries I include and
| their impact on the overall payload size.
|
| I had started with a simple front-end that was using jQuery
| to quickly prototype the device controls, but quickly
| exceeded my goal of keeping the front-end at under 40KB total
| gzipped. The problem is needing more than just jQuery, we
| also needed jQueryUI to help with the front-end, or build out
| similar complex components ourselves. And as soon as the
| jQuery code became non-trivial, it was clear that Preact made
| much more sense to use. Our payload is quite a bit smaller
| yhan the jQuery prototype was.
| MarkdownConvert wrote:
| Long-time user here. It served me well for years, though I
| haven't really touched it since the 3.0 days. Glad to see it's
| still being maintained.
| tonijn wrote:
| No love for $...?
| netbioserror wrote:
| I was surprised that for most of my smaller use cases, Zepto.js
| was a drop-in replacement that worked well. I do need to try the
| jQuery slim builds, I've never explored that.
| NetOpWibby wrote:
| Zepto! That's a name I haven't heard in years. I don't remember
| how it happened but I'm still a member of the ZeptoJS org on
| Github.
| indolering wrote:
| I really like that project! Why don't y'all hand it over to
| someone willing to do maintenance or at least archive it?
| karim79 wrote:
| 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!
| sieep wrote:
| all these kids chasing the new frameworks...jQuery and .NET
| framework have always kept me fed!
| metaltyphoon wrote:
| I mean... jQuery and .NET (6+) can still feed you very well
| :D
| ei8ths wrote:
| so true, 15 years of jQuery for me, it's my go to.
| radicalethics wrote:
| Someone should just hook up a virtual dom to jQuery, it's got a
| whole plugin ecosystem that AI could really re-use. Jquery +
| Jquery UI + Jquery Plugins + AI is probably a super power we're
| all overlooking.
| cj wrote:
| The first time I read this I assumed you were joking about
| hooking up a virtual dom. But I think you're being serious.
|
| Why hook up a virtual dom when you have a real one? Unless
| you're saying AI can't interact reliably with a real browser
| yet.
| jusonchan81 wrote:
| The first time I truly enjoyed web development was when I got the
| hang of jQuery. Made everything so much simple and usable!
| Joel_Mckay wrote:
| jQuery made a messy ecosystem slightly less fragmented.
| Combined with CKEditor it effectively tamed a lot of web-
| developer chaos until nodejs dropped. =3
| blakewatson wrote:
| 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...
| Klaster_1 wrote:
| I used this approach before and it indeed works better than the
| 2010-style jQuery mess. A good fit for userscripts too, where
| the problem you attempt to solve is fairly limited and having
| dependencies, especially with a build steps, is a pain. Note
| that you don't need jQuery for this at all, unless you are
| somehow stuck with ancient browser support as a requirement -
| querySelector, addEventListener, innerHtml - the basic building
| blocks of the approach - have been available and stable for a
| long time.
| doix wrote:
| Unfortunately, nowadays writing userscripts is much harder
| than it used to be. Most websites are using some sort of
| reactive FE framework so you need to make extensive use of
| mutationObservers (or whatever the equivalent is in jQuery I
| guess).
| Klaster_1 wrote:
| Very true. I guess that depends on what websites you find
| issues with? I just checked mine and all of those are
| quality of life improvements for fully server rendered
| sites like HN or phpBB forums.
| doix wrote:
| Yeah, I mostly use it for QoL improvements but for work
| related things. So Jira, Bitbucket, GitHub, Linear etc.
| basically whatever my employer uses. Back in the early
| 2010s most of that software was fully server rendered.
| Nowadays it's pretty rare for that to be the case.
|
| I just try and get LLMs to do it for me because I'm lazy,
| and they like to use setInterval instead of
| mutationObservers and if it works, I just live with the
| inefficiency.
| mschuster91 wrote:
| The Atlassian stack is particularly bad to extend IMHO
| given that there are sooooo many API endpoints that their
| UI calls and most of them are dog slow.
| egeozcan wrote:
| It's easier to write with LLMs. One-off projects (the way I
| treat userscripts) is where they really shine.
|
| Oh the horrible things I do with Instagram...
| tensegrist wrote:
| go on
| hebelehubele wrote:
| I often go for `setInterval` over `MutationObserver`
| because it works and I don't need instant reactivity and I
| don't have to think too much about it.
| ComputerGuru wrote:
| I'm not a frontend dev but I came up with this and use it a
| lot in my userscripts. It's not the most efficient (it can
| certainly be refactored to create a MutationObserver
| singleton and then have each call hook into that) but it
| works well enough for my needs and lets me basically use an
| old-school to dealing with reactive sites (so long as you
| are fine with using async): function
| awaitElement(selector) { return
| awaitPredicate(selector, _ => true); }
| function awaitPredicate(selector, predicate) {
| return new Promise((resolve, _reject) => {
| for (const el of document.querySelectorAll(selector)) {
| if (predicate(el)) { resolve(el);
| return; } }
| // Create a MutationObserver to listen for changes
| const observer = new MutationObserver((_mutations, obs) =>
| { // You could search just inside
| _mutations instead of the entire DOM.
| // Efficiency will depend primarily on how precise your
| selector is. for (const el of
| document.querySelectorAll(selector)) {
| if (predicate(el)) {
| resolve(el); obs.disconnect();
| // Don't forget to disconnect the observer!
| break; } }
| }); // Start observing the document
| observer.observe(document.documentElement, {
| childList: true, subtree: true,
| attributes: false, characterData:
| false, }); }); }
| lioeters wrote:
| 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.
| Sammi wrote:
| I hear you saying that React raised the floor but also
| lowered the ceiling.
| epolanski wrote:
| 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 and nobody could touch it
| without them.
|
| I remember writing pages and pages of notes to understand how
| this all tied up in those extremely complex chains and
| claiming progress after few hours when I achieved to simplify
| the flow by removing a handful of these actions. Hooray.
|
| Then it suddenly dawned on me that...I could just rewrite it
| from scratch.
|
| Nuked the entirety of that nonsense and replaced it with a
| single useState in a matter of few hours also implemented the
| newly requested features.
|
| The client could not believe my progress and the fact I also
| removed many of their previous issues.
|
| Then I had a second realization: React was useless too and it
| got dropped for native HTML forms and a handful of JS
| callbacks.
| normie3000 wrote:
| > 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.
| Capricorn2481 wrote:
| I really can't understand how someone would make 30 redux
| actions for a simple use case, as someone has implemented
| the exact same thing. But yes, not a fan of Redux myself
| gloryjulio wrote:
| Many years ago, I used Redux to build real time streaming
| data processing layer. Basically I need to receive,
| merge, and process multiple data streams into a single
| realtime data pool. After that,consuming the realtime
| data becomes dead easy.
|
| Even now I am not sure I could find a better tool to deal
| with real time data and synchronization. But for simple
| crud Redux is mostly overkill
| hirako2000 wrote:
| https://rxjs.dev/guide/observer
| loglog wrote:
| Have some pity for those Senior Expert Architect Full-
| Stack Developers (fresh out of boot camp) in urgent need
| of job security.
| epolanski wrote:
| 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.
| namtab00 wrote:
| 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).
| epolanski wrote:
| 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.
| gejose wrote:
| 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.
| TuringNYC wrote:
| >> 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.
| mb2100 wrote:
| 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/) ;-)
| 1123581321 wrote:
| The last major jquery app I wrote ended up using a similar
| reactive pattern. I had to shoehorn a custom search engine
| frontend into a Joomla CMS where I wasn't allowed to change
| much. Good times!
| davidzweig wrote:
| MobX autoruns happily call jQuery functions.
| augusto-moura wrote:
| 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
| gocsjess wrote:
| jQuery is v4 now, but a lot of sites esp. wordpress still have
| 1.11 or 1.12 and only uses them to either doing modals(popover),
| show/hide(display), or ajax(fetch).
| nchmy wrote:
| WordPress ships with 3.x and is already looking to update to 4
| gocsjess wrote:
| I was talking about a lot of sites in wordpress, not
| Wordpress themselves
| tpoacher wrote:
| still needs more jQuery
| NetOpWibby wrote:
| I remember being scared of jQuery and then being scared of
| vanilla JS. My, how time flies.
|
| Incredible it's still being maintained.
| giancarlostoro wrote:
| Same experience I had! Impostor syndrome is a pain.
| indolering wrote:
| I love that they support ES6 modules, Trusted Types, and CSP! The
| clearing out of old APIs that have platform replacements is nice
| to see too!
| madduci wrote:
| This is huge. jQuery is still my way to go for any website
| requiring some custom interaction that isn't available in vanilla
| js.
| nchmy wrote:
| What isn't available in vanilla js?
| chao- wrote:
| I cannot express how much I admire the amount of effort jQuery
| puts into their upgrade tools.
| maxpert wrote:
| jQuery is the last time I felt a library doing magic! Nothing has
| matched the feelings since then.
| Minor49er wrote:
| Not even modern vanilla JavaScript?
| marticode wrote:
| It's fairly close now but so much more verbose: ie
| document.getElementById('theID') vs $('#theID')
| majewsky wrote:
| Nearly every time I write something in JavaScript, the
| first line is const $ = (selector) =>
| document.querySelector(selector). I do not have jQuery
| nostalgia as much as many others here, but that particular
| shorthand is very useful.
|
| For extra flavor, const $$ = (selector) =>
| document.querySelectorAll(selector) on top.
| SahAssar wrote:
| const $$ = (selector) =>
| Array.from(document.querySelectorAll(selector))
|
| is even nicer since then you can do things like
| $$('.myclass').map(e => stuff)
| yread wrote:
| Hmm maybe i can finally move on from 2.x
| ulrischa wrote:
| I still love the simplicity a ajax call can be done in Jquery
| niek_pas wrote:
| What does jQuery provide that the Fetch API doesn't?
| sethaurus wrote:
| 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.
| gethly wrote:
| jQuery was peak JavaScript.
|
| Good times, I'm glad it is still around.
| shevy-java wrote:
| It is still used by many websites.
| marticode wrote:
| Indeed. Though a lot of its feature found their way into
| plain vanilla Javascript and browsers, the syntax is still so
| much easier with jQuery.
| shevy-java wrote:
| I am still using jQuery.
| flomo wrote:
| 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.
| gbalduzzi wrote:
| 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.
| flomo wrote:
| Yeah, that's the other HN koan about "You probably don't need
| React if..." But if you are using jquery/vanilla to shove
| state into your HTML, you probably actually do need something
| like react.
| epolanski wrote:
| It's not really about state but dom updates.
| eloisius wrote:
| 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.
| skizm wrote:
| Facebook is PHP ironically.
| ryan_n wrote:
| I think in 2026 Facebook is a conglomeration of a bunch
| of things... Definitely not just PHP anymore.
| connorgurney wrote:
| It was once upon a time, hence them moving to HHVM to
| interpret it, but it's been all but replaced with a PHP
| spinoff named Hacklang now.
| hsbauauvhabzb wrote:
| 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.
| egeozcan wrote:
| jQuery but gets compiled out like svelte... Not a bad idea at
| all.
| efskap wrote:
| I hate to sound like a webdev stereotype but surely the
| parsing step of querySelector, which is cached, is not slow
| enough to warrant maintaining such a build step.
| egeozcan wrote:
| Some things you build not because they are necessary, but
| because you can.
| jraph wrote:
| In case you missed them: check out querySelector and
| querySelectorAll. They are closer to what the jQuery selector
| system does, and I think they were inspired by it.
|
| If the verbosity bothers you, you can always define an
| utility function with a short name (although I'm not
| personally a fan of this kind of things).
|
| https://developer.mozilla.org/docs/Web/API/Document/querySel.
| ..
|
| https://developer.mozilla.org/docs/Web/API/Document/querySel.
| ..
|
| https://developer.mozilla.org/docs/Web/API/Element/querySele.
| ..
|
| https://developer.mozilla.org/docs/Web/API/Element/querySele.
| ..
| hyperhello wrote:
| 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.
| jraph wrote:
| Please don't mess with native prototypes though.
| Sammi wrote:
| 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.
| jraph wrote:
| 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.
| hyperhello wrote:
| Rules beget rules.
| janderland wrote:
| > 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.
|
| He was suggesting adding a prototype method, not
| replacing one. Unless the library your using is also
| adding prototypes, I can't think of an issue with this.
| Sure, if a new version of JS ends up using these names
| then things could break, but I'd bet this won't cause him
| a problem in actuality.
| adzm wrote:
| The $ (and $$) selector functions live on in chrome/chromium
| devtools!
| Sammi wrote:
| Very simple jquery implementation with all the easy apis:
| (function (global) { function $(selector, context =
| document) { let elements = []; if
| (typeof selector === "string") { elements =
| Array.from(context.querySelectorAll(selector)); }
| else if (selector instanceof Element || selector === window
| || selector === document) { elements =
| [selector]; } else if (selector instanceof NodeList
| || Array.isArray(selector)) { elements =
| Array.from(selector); } else if (typeof selector
| === "function") { // DOM ready if
| (document.readyState !== "loading") {
| selector(); } else {
| document.addEventListener("DOMContentLoaded", selector);
| } return; } return new
| Dollar(elements); } class Dollar {
| constructor(elements) { this.elements = elements;
| } // Iterate each(callback) {
| this.elements.forEach((el, i) => callback.call(el, el, i));
| return this; } // Events
| on(event, handler, options) { return this.each(el
| => el.addEventListener(event, handler, options)); }
| off(event, handler, options) { return
| this.each(el => el.removeEventListener(event, handler,
| options)); } // Classes
| addClass(className) { return this.each(el =>
| el.classList.add(...className.split(" "))); }
| removeClass(className) { return this.each(el =>
| el.classList.remove(...className.split(" "))); }
| toggleClass(className) { return this.each(el =>
| el.classList.toggle(className)); }
| hasClass(className) { return
| this.elements[0]?.classList.contains(className) ?? false;
| } // Attributes attr(name, value) {
| if (value === undefined) { return
| this.elements[0]?.getAttribute(name); }
| return this.each(el => el.setAttribute(name, value));
| } removeAttr(name) { return
| this.each(el => el.removeAttribute(name)); }
| // Content html(value) { if (value ===
| undefined) { return
| this.elements[0]?.innerHTML; } return
| this.each(el => (el.innerHTML = value)); }
| text(value) { if (value === undefined) {
| return this.elements[0]?.textContent; }
| return this.each(el => (el.textContent = value)); }
| // DOM manipulation append(content) {
| return this.each(el => { if (content instanceof
| Element) {
| el.appendChild(content.cloneNode(true)); } else
| { el.insertAdjacentHTML("beforeend",
| content); } }); }
| remove() { return this.each(el => el.remove());
| } // Utilities get(index = 0) {
| return this.elements[index]; }
| first() { return new
| Dollar(this.elements.slice(0, 1)); }
| last() { return new
| Dollar(this.elements.slice(-1)); } }
| global.$ = $; })(window);
| itsHel wrote:
| const $ = document.querySelector.bind(document);
|
| const $$ = document.querySelectorAll.bind(document);
| Zardoz84 wrote:
| const $ = document.querySelectorAll
| recursive wrote:
| Probably have to bind the this value.
| sgt wrote:
| I pretty much use HTMX and vanilla JS to solve most problems,
| when I use Django at least. Keeps things simple and gives that
| SPA feel to the app too.
| recursivedoubts wrote:
| yes: htmx grew out of intercooler.js, which was based on jquery
| and inspired by the jQuery.load() method:
|
| https://api.jquery.com/load/
|
| which I found while doing some performance work at one point.
| intercooler.js started as a custom function that hooked .load()
| in based on custom attributes (a trick I learned from angular
| 1.x)
|
| deeply respect and love jquery
| rolymath wrote:
| Are you Carson?
| recursivedoubts wrote:
| yep
| lrvick wrote:
| Everything I ever used jquery for 15 years ago, I found myself
| able to do with the CSS and the JS standard library maybe 10
| years ago. I honestly am confused when I see jquery used today
| for anything.
|
| Is there still anything jquery does you cannot easily do with a
| couple lines of stdlib?
| jampekka wrote:
| Jquery does many things in one line that requires a couple
| lines of stdlib. Writing less code is what libraries are for.
| glemion43 wrote:
| Until you have to upgrade it and it bites you
| jampekka wrote:
| jQuery's big point was to give a consistent API over
| inconsistent browser implementations, so it typically saves
| you from bites more often than it bites you.
| simondotau wrote:
| The terse and chainable jQuery syntax is more readable, easier
| to remember, and thus more pleasant to maintain. Rewriting for
| stdlib is easy, but bloats out the code by forcing you to
| pepper in redundant boilerplate on nearly every line.
| hypnot wrote:
| It's amazing how much jQuery is still used today. Even on modern
| websites you can often find it included (browser devtools ->
| jQuery in the console, and see). And not just on hobbyist sites,
| but on serious company websites and their web tools as well.
| KellyCriterion wrote:
| Curious:
|
| Whats the current behemoth instead of JQ?
|
| I perceive it as still being the de-facto standard?
| croes wrote:
| Many things JQ introduced are browser native now.
| bonzini wrote:
| Or can be replaced by other technologies, like CSS
| animations that replace jQuery animation code with just
| addClass/removeClass.
| johanyc wrote:
| is there any reason to use jquery if you've never used it before
| modarts wrote:
| Don't let all of the old heads glazing jquery in this thread
| confuse you - they're just nostalgic. There's no reason to even
| think of using jquery in 2026
| rtbruhan00 wrote:
| It's refreshing to see jQuery 4
| AdrianB1 wrote:
| I used jQuery for the past ~ 10 years on smaller apps and I had
| no problems with it. Then I slowly replaced it with modern JS
| wherever possible and I found that today I am using jQuery only
| because Datatables.js depends on it.
|
| It was a nice ride, many thanks to the people that worked and
| still work on it. Not sure we'll ever see a jQuery 5, but that's
| life.
| ttoinou wrote:
| I love jQuery and it's elegant methods chaining over object /
| array of DOM elements you keep in the chain.
|
| 15+ years ago I wrote a tutorial for french people about using
| jQuery, it got a lot of views. I hope it helped spread jQuery.
| pocketarc wrote:
| > includes some breaking changes
|
| Most of the changes are completely reasonable - a lot are
| internal cleanup that would require no code changes on the user
| side, dropping older browsers, etc.
|
| But the fact that there are breaking API changes is the most
| surprising thing to me. Projects that still use jQuery are going
| to be mostly legacy projects (I myself have several lying
| around). Breaking changes means more of an upgrade hassle on
| something that's already not worth much of an upgrade hassle to
| begin with. Removing things like `jQuery.isArray` serve only to
| make the upgrade path harder - the internal jQuery function code
| could literally just be `Array.isArray`, but at least then you
| wouldn't be breaking jQuery users' existing code.
|
| At some point in the life of projects like these, I feel like
| they should accept their place in history and stop themselves
| breaking compatibility with any of the countless thousands
| (millions!) of their users' projects. Just be a good clean
| library that one can keep using without having to think about it
| forever and ever.
| wartijn_ wrote:
| I don't understand your use case. If you've got legacy projects
| that you don't want to touch, why upgrade a dependency to a new
| major version? You can keep using jquery without having to
| think about it. Just keep using version 3.7 and don't even
| think about version 4.
| Zardoz84 wrote:
| To fix vulnerabilities?
|
| I recently had to upgrade from jQuery 2 to the latest
| version, because an client demanded it (security issues), and
| just ran into compatibility issues with third party
| libs/plugins.
| g947o wrote:
| I thought this would include more drastic changes, but it seems
| that this is more house cleaning stuff, like, "nobody should
| really be using this in 2026". They are providing a library for
| someone who _really_ likes jQuery and wants to use it over
| something like React. (Which is completely fine and reasonable.)
|
| Looks like the core behavior doesn't change, something that
| people complain about, e.g.
| https://github.blog/engineering/engineering-principles/remov...
|
| > This syntax is simple to write, but to our standards, doesn't
| communicate intent really well. Did the author expect one or more
| js-widget elements on this page? Also, if we update our page
| markup and accidentally leave out the js-widget classname, will
| an exception in the browser inform us that something went wrong?
| By default, jQuery silently skips the whole expresion when
| nothing matched the initial selector; but to us, such behavior
| was a bug rather than a feature.
|
| I completely agree with this, because I have been bitten so many
| times by this from subtle bugs. However I can see some other
| people not caring about any of it.
|
| I already know that I am definitely not going to use jQuery in my
| personal projects, and there is no chance that my workspace does.
| (I much prefer letting a framework handle rendering for me based
| on data binding.) So none of that concerns me. But good luck to
| jQuery and anyone who sticks with it.
| admiralrohan wrote:
| 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?
| temporallobe wrote:
| 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.
| hotgeart wrote:
| 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.
| senfiaj wrote:
| jQuery was very useful when many features were missing or not
| consistent/standardized between browsers. Nowadays, JS / DOM API
| is very rich, mature and standardized. So, jQuery is not as
| necessary as it was before.
|
| https://youmightnotneedjquery.com/
|
| Yes, sometimes the vanilla JS analogs are not the most elegant,
| but the vast majority are not terribly complicated either.
|
| IMHO, another advantage of vanilla JS (aside from saving ~30KB)
| is potentially easier debugging. For example, I could find /
| debug the event listeners using the dev tools more easily when
| they were implemented via vanilla JS, since for complicated event
| listeners I had to step through a lot of jQuery code.
| padjo wrote:
| That bit about focus event order gave me flashbacks and raised my
| heart rate by a couple of bpm. Had some bad times with that ~15
| years ago!
| bikamonki wrote:
| For us that started doing web apps as soon as the web was
| invented, JQ was a miracle.
|
| Thanks guys!
| Pikamander2 wrote:
| That changelog is wild; it closes out dozens of issues that have
| been open on Github for 5+ years. I assume that's related to this
| being the first new major version in years.
|
| Has anyone done any benchmarks yet to see how jQuery 4 compares
| to jQuery 3.7?
| nashashmi wrote:
| I wish it also included support for XPath Query.
| ksec wrote:
| 20 Years! I remember when jQuery first release I thought in 5 to
| 10 years time we wont need jQuery because everything jQuery has
| will be built into the browser or becomes part of HTML Spec.
|
| But then Google, Chrome, iPhone, PWA or JS for everything took
| over and took a completely different path to what I imagine
| webpage would be.
| alphax314 wrote:
| Amazing oss library, glad its still being maintained!
| hk1337 wrote:
| Meh. I was a Mootools connoisseur back in the day and saddened
| how jQuery became more popular.
|
| I'm glad JavaScript has evolved to the point we don't need
| jQuery anymore.
| thm wrote:
| Okay, your turn, script.aculo.us & Mootools.
| thrownaway561 wrote:
| there are 2 frameworks I haven't had of in some time.
| goykasi wrote:
| 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!
| nprateem wrote:
| What's jquery? I only use dynamic drive for my DHTML
| alnico wrote:
| Congrats to everyone involved in the jQuery 4.0 release.
|
| For what it's worth, if you're looking for a more structured
| approach on top of jQuery, JsViews (https://jsviews.com) provides
| a reactive templating and data-binding system that's been around
| and stable for many years.
|
| It hasn't seen the same level of adoption as newer frameworks,
| but it may still be of interest to people who prefer the jQuery
| ecosystem.
| vanderZwan wrote:
| That looks interesting, I'm not likely to write any jQuery any
| time soon, but I'll check out the source code to see if I can
| learn anything from it.
|
| Regarding adoption levels, the JsViews website made me think I
| had accidentally toggled the "Desktop Site" option in my
| Iceweasel browser, I wonder if that scared people off. Or
| perhaps it's because, as others mentioned, most jQuery
| development these days is in legacy codebases where the devs
| are not allowed to add _any_ new libraries, reducing the
| adoption rates of any new jQuery libraries even more than you
| 'd expect based on the raw nrs of jQuery users.
|
| (the website does _work_ though, and it loads fast. Which is
| something I 've always appreciated about jQuery based sites
| still alive today. The only thing I'm missing is any indication
| of how big it is when minified + gzipped. EDIT: jsrender.js is
| 33.74 kB, jsrender.min.js a mere 12.82 kB)
| alnico wrote:
| I've been collaborating with Boris, the author of JsViews,
| and we do have plans to modernize the website--which speaks
| directly to your point about first impressions and adoption.
| You're absolutely right that presentation matters; if
| something looks dated, people may disengage before digging
| any deeper.
|
| I also raised the jQuery dependency concern with Boris for
| exactly the reason you mentioned: many teams automatically
| rule out anything that requires jQuery, especially outside of
| legacy codebases. That's a real barrier today.
|
| For what it's worth, a jQuery-free version may happen. Boris
| is actively exploring it, but he's making no promises--it's a
| non-trivial problem and would effectively require a full
| rewrite rather than a simple refactor.
| kordlessagain wrote:
| Wow. Great job.
| kordlessagain wrote:
| Now what we need is realtime log forwarding from js to the llm.
| recursivedoubts wrote:
| hail to the king
| fourseventy wrote:
| Now that's a name i've not heard in a long time...
| sodafountan wrote:
| Wow, this is interesting to see. I thought jQuery was dead.
|
| My next question would be, is this something that OpenAI and
| Anthropic would train their data on? If I ask Claude Code to
| write an app and utilize jQuery, would it resolve to the previous
| version until it's retrained in a newer model?
| giancarlostoro wrote:
| Much like I am sure anyone else who started doing web dev in the
| 2000s and 2010s before SPA frameworks were as prevalent I learned
| web development scripting with jQuery and I am happy to see its
| still around. Theres so many things I built on top of jQuery in
| those early years that likely still work. Kudos to the team.
| zghst wrote:
| I feel so old. jQuery was hate/ok early in my career, as I
| started on the tail end of HTML5/in the middle of ES6 with all
| the new stuff.
| thr0waway001 wrote:
| Good ol' jQuery.
|
| Thank you for everything you've done for us.
| thrownaway561 wrote:
| 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.
| t1234s wrote:
| 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?
| augusto-moura wrote:
| 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/
| 101008 wrote:
| Yes, my default to go now is Django + Tailwind with HTMX and
| celery for background tasks. That alone took me far away.
___________________________________________________________________
(page generated 2026-01-18 23:00 UTC)