[ecshafer]

Also, jQuery is awesome.

People have been in love with the overly complex and fancy javascript frameworks for the last 15 years or so. But jQuery doing dynamic binding to dynamically generated forms for some error states and maybe an ajax calls is literally all the javascript you need in 99% of web pages and the rest is overkill.

The industry is going to move away from the complexities to React and towards more of this simplicity with htmx, phoenix live view, ruby on rails turbo, and yes just jQuery.

[tipiirai]

Second to that: jQuery is awesome.

Or more specifically: the idea that websites can be built with vanilla HTML, CSS, and _optional_ JS. jQuery embraces progressive enhancement and separation of concerns pattern, which is quite the opposite of how websites are built these days. Web development starts with 10+ React import statements for components, CSS, images, and whatnot. JavaScript is a must, not optional.

[p-e-w]

One website that almost always gets mentioned when people talk about jQuery today is "You might not need jQuery" (https://youmightnotneedjquery.com/).

That site is the best ad for jQuery I've ever seen. For almost every task it describes, the jQuery code is shorter, cleaner, and more intuitive than the vanilla "modern" JS one.

And that's after almost 20 years, and I don't know how many billions of dollars invested into advancing JavaScript.

[Finbarr]

This is incredible and such a great ad for jQuery. It's almost as if the creator(s) built that site ironically. So many examples are way clearer and easier in jQuery, like this one:

  JQUERY:
  $(el).toggle();

  IE8+:
  function toggle(el) {
    if (el.style.display == 'none') {
      el.style.display = '';
    } else {
      el.style.display = 'none';
    }
  }

Gotta love that "modern" triple attribute repetition.

From: https://youmightnotneedjquery.com/#toggle

[piaste]

> It's almost as if the creator(s) built that site ironically.

No, the site's advice is simply more narrow and fine-grained than a blunt 'never use jquery'. From the front page:

> jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.

> If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement.

This seems eminently reasonable to me. For a website, adding a jquery dependency costs little and you get much nicer, more maintainable code.

But for a library, every transitive dependency introduces the possibility of future version conflicts for applications that depend on it. And at the same time, library code shouldn't need to change and grow nearly as much as application code.

So library authors should strongly consider forsaking mere convenience for the sake of reducing dependency baggage. This isn't even JS-specific advice, it applies to most ecosystems.

[extra88]

A more modern solution would be to use classList.toggle() or toggleAttribute(hidden).

[mschuster91]

> Gotta love that "modern" triple attribute repetition.

You can golf it down a bit:

    el.style.display=el.style.display == 'none' ? '' : 'none';

[OJFord]

Surely

    el.style.display = el.style.display ? 'none' : ''

(after toggling we've already obliterated any possible third value for it anyway, doesn't seem significant)

[anakaine]

Even though I can appreciate the elegance of your solution, I'd prefer the former for clarity.

[Finbarr]

Of course. Because that's infinitely better than:

  $(el).toggle();

[1123581321]

Toggle was a bit of a pitfall because the developer had to keep track of all the possible states prior to that line. It's easy to drop in as a function when needed in simple scripting (expanding faq sections, etc.)

[frereubu]

IE8 is a bit of a straw man. We've dropped IE entirely when testing unless there's significant (1%+) usage for particular clients, but even the NHS in the UK has dropped IE11.

Edit: https://caniuse.com/?search=classlist.toggle and click Usage Relative.

[fwip]

Plus, the jQuery example also accepts any selector for `el`, including ones that select multiple elements.

The `toggle(el)` function only accepts a single element that you've already selected (e.g: via `document.getElementById("foo")`). You'd need to at least add a call to `querySelectorAll(...).foreach(toggle)`, if you wanted to preserve that piece functionality (which you admittedly don't always want).

[tipiirai]

It's the jQuery API design. I often find myself creating functions like this one:

export function $(query, root=document) { ... }

jQuery acted as a role model for standard web committees. The argument for querySelector / querySelectorAll calls is literally mimicked from John Resig's groundbreaking API design.

[admaiora]

Yesterday I was checking HN from 10years±2weeks ago and guess what the top posts were... "Why you need jQuery" and "You might not need jQuery". I'm too young to know about those days but I guess not much has changed in relation to people's attitude towards jQuery.

[krapp]

What's changed is the billion dollar tech industry invested in convincing people that JQuery is a dead and obsolete technology.

For some reason, JQuery is the exception to the general rule of seeing a mature, battle-tested library as a sign of quality.

[Macha]

The problem jQuery was solving was to provide a usable abstraction over an inconsistent platform for core functionality like event handling and DOM manipulation.

The point of the last decade and a half of standards work was to eliminate that problem, and it has at least moved it from "core web functionality" to more complicated areas like bluetooth, 3d rendering and audio, which jQuery's goals do not include handling.

Is it urgent to remove jQuery from projects? Not really. And it's good the jQuery team maintain the project for that reason. Certainly some projects have gotten performance gains out of removing it, but part of the work they've done in 3.x and now 4.x is arguably jQuery removing stuff internally and replacing them with the now reliable browser APIs.

But on the other hand, is there a great argument for including jQuery in new projects? This is also a "not really".

[collyw]

It was initially sold as a way to fix browser incompatibilities, but I still use it because there are really nice plugins like select2. I really don't see the point in SPA apps for the most part. Fair enough if you have a heavily interactive frontend, but I can build an app in Django with a bit of JQuery and end up with around half the code compared to adding in React.

[gunapologist99]

That was part of the problem that jQuery was solving.

Another part was the abysmal API that Javascript (and mostly still today) offers to work with the DOM.

[marcosdumay]

That site message is "don't import all of jquery just to use the $ global and one or two specific functions".

It's a very fine message and the site contents spread it quite well. But if you actually want to use jquery instead of just some function you got from a reference, by all means, use it, it's a very nice library.

[jampekka]

Much of the billions are used to make JavaScript worse. E.g. ESM is a byzantine mess compared to CJS, and the ceremony and bondage of TypeScript is dramatically increasing busywork.

[LamaOfRuin]

>For almost every task it describes, the jQuery code is shorter, cleaner, and more intuitive than the vanilla "modern" JS one.

Just like leftpad.

[ipaddr]

Instead of needing to import leftpad you have the missing standard js lib

[krapp]

It isn't missing. Javascript was created to serve a specific purpose, which didn't include left-padding text in a terminal. Most language I'm aware of wouldn't have that in their standard lib.

If you want Javascript to act as a drop-in replacement for C++ or Java or some other general programming language (which Javascript was never intended to be) don't act as if needing to write libraries to cover that missing functionality is a problem with the language. You're using the wrong tool for the wrong job.

[selcuka]

> Most language I'm aware of wouldn't have that in their standard lib.

Python has str.ljust [1] (and str.rjust [2]):

> Return the string left justified in a string of length width. Padding is done using the specified fillchar (default is an ASCII space). The original string is returned if width is less than or equal to len(s).

[1] https://docs.python.org/3/library/stdtypes.html#str.ljust

[2] https://docs.python.org/3/library/stdtypes.html#str.rjust

[midasuni]

Yesterday I wrote a custom page which dumped out a table for some investigation. I threw jquery and a tablesorter plug-in. Without JS you get the table, but with you can easily sort and filter. Took about 2 minutes to add the optional filter. The backend is bash of course.

[sireat]

For tables my favorite jQuery plug-in is: https://datatables.net/

Have a page with some tables? A few lines of jQuery and you have search sorting etc. It can be customized but defaults are fine.

This is how abstractions and progressive enhancement should be done.

[midasuni]

I’m not even sure what I used, it’s the same 5 lines I’ve used for years. Boom bang and on to the next problem.

For every unicorn saas webapp $300k a year developers are writing there’s a thousand small pages. If you’re building a house you aren’t going to use a Swiss Army knife, but if you’re camping out for a couple of days you aren’t going to take a van full of power tools.

[anakaine]

A couple.of well selected power tools are certainly helpful, however. A battery blower to start the fire, a small electric chainsaw for any wood cutting depending on the area and what you take in, and a portable fan if you're in a hot climate. Sometimes a couple of selected power tools are very helpful.

[ryanisnan]

Weird analogy. I’ve camped my whole life, never once brought a power tool.

[mobilemidget]

I personally prefer https://sortablejs.github.io/Sortable/ over datatables.net

Though both do what I typically need them to do, customising datatables.net takes me a bit more time though

[GrumpyNl]

Big plus is, it also gives yo the option to export the tables to pdf and other file formats.

[nextaccountic]

About optional JS: you can have that with server-side rendering plus a modern framework (like next.js or leptos). That's certainly not as simple as vanilla html and js, but totally doable.

[kkarpkkarp]

> you can have that with server-side rendering plus

yes, we use PHP for this which is much simpler to grasp than JS-SSR

[geek_at]

plus you don't need to restart any services or rebuild servers. Just git pull and you have the new code on the live server without even a second of downtime

[flemhans]

watch -n 1 git pull

[vmfunction]

In node there is EJS which is basically PHP templating with JS.

[wouldbecouldbe]

Nah, not simpler, nextjs is simpler then php to start working with. Also running & deploying nowadays is easier. PHP used to be easiest, but fell behind.

[pzmarzly]

This very much depends on what you are building and how experienced you are.

If you just want a few pages, no need for background workers or database migrations, PHP is still the king. You download one of many single-executable LAMP servers, and start writing your index.php. Deploy? Just copy files to server. Zero downtime deploy? Copy files to server and use symlink to atomically switch versions. Dependencies? Composer (package manager) is a single-file script, you can place it wherever. Pain only begins when you want to break away from file-based routing, or need custom .htaccess and nginx.conf, or want to isolate components, or need Redis and cron for background jobs.

On NextJS side, I knew a few people who wanted to start their career with it and the experience wasn't smooth. You install nodejs... but your distribution only ships Node 12, so everything is failing with cryptic errors. You search how to upgrade Node, and get caught in nvm vs n vs asdf flamewars. Once you found a working solution (which probably required you to edit env variables), you run the npm command... and it wants root access? To install packages system-wide? So you google around, find a way to make it use the user home directory. Then you are up and running, you aren't sure what this "React" thing is, but you get stuff done. Time to deploy - and you are told to either learn Docker (and Kubernetes if you want zero downtime), or to use one of few hosting companies with a price markup. Well, at least there is a free tier (for now), so most people choose the latter. Was this a simple start?

Now, when it comes to big apps, I'd very much rather use Nextjs than PHP, it is production-tested, gives you a lot "for free", JS LSP is built-in to VSCode, I already know React and most of JS ecosystem. But if somebody tells me that they just finished learning HTML and vanilla JS, and they want to do something simple server-side, I'm torn on what to recommend nowadays.

[wouldbecouldbe]

You haven't worked with Vercel. Just connect your git account and you have a fully git-flow based server, with preview urls for every PR. Especially for small projects ideal.

Running it on a VPS is a skill on it's own, for both, if users had known to use NVM (which is explained in most top articles in Google) it would have not been a problem and if they don't know they should accept the learning pains of running productions apps (PHP, node or whatever), or otherwise use a managed service such as Vercel.

Upgrading PHP version is even more painful, I've tried to do version updates, and was alway easier just to build a new server. And also requires specific knowledge of apache, or nginx. Let alone deal with server outages, backups, restart, memory issues.

[Aeolun]

PHP is great for getting started, but I think it gives you a fundamentally flawed idea of how the web works. You tend to think in files, and not worry about what Apache or Nginx are actually doing.

Then when you switch to node, or basically any other language, you wonder where your file based logic is, and everything feels annoying and painful.

Do you really need to host your own server to run a single file? Yes, you do with PHP too, but it’s hidden in Apache and php-fpm.

[jddj]

Opinion: If more product teams had one person high up who felt embarrassed by even one of the things in your third paragraph we'd have significantly better tech.

[Capricorn2481]

I guess as someone that likes php and is meh on Next JS and uses both for most of their job, this seems like an unfair comparison. You have node woes listed here, but nothing about different PHP versions or the headache of migrating from 7.4 to 8 (which every app is overdue for). And while composer can be good, managing php extensions is a nightmare in my eyes. Xdebug in particular is bizarre to me. I'm so used to being able to debug something in an IDE by default that I'm surprised when I switch to a certain PHP version for a project and forget the debugger won't work here until I set up the extension again.

[rfl890]

Express

[tipiirai]

You sure can, but it then comes to the separation of concerns. CSS-in-JS (coupling of concerns) is the preferred option.

[teaearlgraycold]

Having CSS in a separate file feels like defining the predicates for your if statements in a separate file. With tailwind we're getting pretty close to a great solution here.

[postepowanieadm]

Even better - you may use service workers as your 'server-side'.

[PrimeMcFly]

> JavaScript is a must, not optional.

I build plenty of CSS only sites without any JS just fine. I avoid using it as much as I can and generally only need it for forms or galleries, occasionally some ajax stuff.

But it's seldom required.

[manuelmoreale]

Just want to say I appreciate you for doing that.

[PrimeMcFly]

Thanks :)

It just seems like good practice. I want my sites to be as fast, minimal, compatible and as usable as possible, while still looking and feeling modern.

[manuelmoreale]

I hear you. My site is 1 http request and no js so I’m definitely with you on this.

[krick]

I won't dare to predict where industry "is going to move", since I'm not really a frontend developer, so what do I know anyway (and especially since it seems to switch directions every couple of years, and mostly being pulled in all directions simultaneously). But personally I still prefer to use stand-alone JS-scripts and libs included directly into the page, if I can. Mostly because I hate having to deal with complicated (and, importantly, rather slow) build process just for the sake of a couple of web-pages, when the real stuff is some totally invisible backend processing or maybe some sort of HTTP API to be used by other services.

Also, honestly, I really just don't know what's the "correct" way to do things in 2024 on frontend, and I don't know where to even look for a guide, if I don't really want to spend next 6 months entirely in the pursuit of attaining "real" frontend-dev proficiency, but ultimately just to make working stuff, even if it doesn't quite follow the v2024 web-etiquette.

[palmfacehn]

"Etiquette" implies there is some civilizing force. A system that allows us to coexist in peaceful, accessible sanity.

Someone said of a profitable app/site I created with vanilla JS, "But this is looks like it is just a Bootstrap site"

At this point, functionality be damned, customers expect a loading spinner. The norm is something that doesn't load on the first request. Sites don't paint the screen until 10 seconds later, because they are avoiding repaints. Maybe 10-20mb of JS is included in the typical app in this niche. Many totally fail on Firefox. Ambiguous user facing errors on a black screen, "An application client side error occurred" are par for the course.

[khasan222]

I’ve been writing JavaScript for 15 years professionally, and I must say this comment seems to be made by someone not as familiar with the context here. Moving away from React and frameworks like it would require a radical rethinking of what we expect to do with web apps. Building something like google maps, google docs, figma, are definitely doable with some of these tools, but it is almost impossible to maintain. This comment truly ignore the context of why frameworks like react took off. Jquery is great if you need a slideshow on a page, and maybe just some tracking, and even then, I’ve recently opted to just use vanilla js, with things like webpack build targeting whatever versions I would need. JavaScript programming is complex because making great ux can be a non trivial task.

Please excuse any typos, written on the phone

[heartbreak]

How many React apps actually have an interface approaching the complexity of Figma or even Facebook?

No one is arguing that complex web applications don’t benefit from React and friends. It’s completely overkill for most of the web.

[anthonypasq]

why does everyone have this impression that people are using react to render a website that is 5 divs and some images, like where is this perception coming from? do you have any examples at all?

any website that has any sort of meaningful functionality and communication with a server is mostly likely using some sort of framework.

[docmars]

Agreed. There is a _lot_ of naivety around how these frameworks are perceived, from people who have never used them, or who come from different programming backgrounds (i.e. not frontend). It's amusing.

[hombre_fatal]

Yeah, there's this whole meme on HN where React competes with hand-writing the HTML of your three-page brochure website, a website virtually nobody is building.

[lizardking]

A lot of marketing agency development is this sort of brochureware, and to your point they usually aren't using react.

[silent_cal]

These crazy libraries might make sense to you because you've been a JS dev for 15 years. JS is supposed to be a basic building block of the web. React places a learning curve in front of the everyday developer that is effectively impossible. It's fine if it's helpful in edge cases, but it shouldn't be the norm. Basic technology should be accessible.

[erhaetherth]

If you don't want to use a big framework, then you needn't use any library at all. Nearly everything in jQuery is 1 line of modern JS, no?

[masklinn]

> Nearly everything in jQuery is 1 line of modern JS, no?

Since JavaScript never actually requires line breaks, yes.

Otherwise, absolutely not. Modern web APIs remain highly statements-based, with little affordance for pipelining / cascading.

[pier25]

One line of jQuery can replace many lines of vanilla js.

[troupo]

Nearly everything in jQuery is more concise, consistent and composable compared to modern JS APIs. As this site clearly shows: https://youmightnotneedjquery.com/

[colordrops]

Yes, there isn't much reason to use jQuery these days other than keeping with the idioms of a legacy system.

[rdedev]

I'm not a web developer but sometimes I have to make a page with some JS functionality. jQuery saves me a lot of time in such cases

[lucsky]

No, the "industry" is not going to move away from React (or Vue or Solid or Svelte), but idiots on HackerNews (and Reddit and Twitter and Mastodon, etc) might finally stop conflating web SITES and web APPS. One can dream.

[cphoover]

Agreed...Another gripe... the amount of people on HN complaining that a web-app doesn't 'work without JS, when the number of user's who disable JS inside their browser is well under 1%. HN users don't even consider they are not in anyway typical web users.

[spillguard]

From the guidelines:

"Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes."

[lucsky]

You're right, this was 100% sent out of frustration and I probably shouldn't have. I still think that the level of nonsense in this comment section is of galactic proportion though.

[webworker]

I keep saying this. At some point, some very smart people are going to figure out how expensive React is to build and maintain, and it’s going to change the conversation.

[patrickaljord]

jQuery is amazing, still remember the joy of using it 20 years ago. That being said, React, Vue and similar are just better IMO to build and maintain complex apps. Don't get me wrong, jQuery was the best thing at its time and I will always be grateful to its contributors, but today there are better alternatives. I think htmx is nice but not seeing it taking over other frameworks.

[linkjuice4all]

Definitely agree that the modern frameworks are better for complex stuff. Ideally there’s not really a middle ground - you’re either doing complex interactive “app-like” stuff with a framework or adding modest dynamic features to otherwise static content (e.g. static export of WordPress with some jQuery for your forms).

[throwaway2990]

lol react. Never seen a good react project. They all end up a mess.

[holoduke]

You still need some kind of application framework. Jquery is just a low level utility. But higher level you need to maintain architecture. Specially in spa's

[hnfong]

You don't "need" an application framework.

People have been building websites (even SPAs) before the 2010s and they didn't "need" these frameworks.

Given what we know today, I'll grant you that in some cases people would want to use a framework, but it's hardly a necessity unless the context provides more specific requirements.

[bdhcuidbebe]

You dont ”need” anything. But most people prefer some organization, familiarity and reusability, and not having to reinvent the wheel in every project they start.

[holoduke]

Its can be convenient to have some kind of reusable conponents. Like listviews wtih certain functionality. Same for routing. Caching etc.

[claytongulick]

Native web components / custom elements work great for this.

[holoduke]

So you end up with an component framework.

[agos]

you don't "need" a framework for backend development, too, but most people find it highly convenient

[docmars]

Organizing a large jQuery project is absolute hell though. I'll take modern frameworks like Vue any day. The ease of shipping a full-fledged app that feels easy to create and maintain began with Vue (and Svelte).

React tries to achieve the same result, but if you don't use it perfectly right, you're in for hours and hours of headaches and non-solutions.

[dagss]

Unpoly too (very similar to htmx but the small difference makes it a lot more convenient I feel, I wonder why Unpoly isn't getting as much traction as htmx)

[falsandtru]

jQuery remains the best JSONP library. It can get data even when other libraries are blocked.

[rolisz]

If I understand this announcement correctly, they removed support for JSONP

[falsandtru]

Just removed "Automatic" JSONP "promotion". JSONP is still available.

[pjmlp]

Fully agree, jQuery + Bootstrap + standard Web + SSR, and we're gold.

[silent_cal]

I read that the JS fetch API makes jQuery obsolete, is that not true?

[esaym]

>But jQuery doing dynamic binding to dynamically generated forms

Do you have an example of that?

[DonHopkins]

Hold my beer!

https://alive22-dev.turnaroundhealth.com/static/javascript/q...

[ourmandave]

More that one line, doesn't count! =D

[DonHopkins]

It's one line when minimized! ;)

[yashg]

Yup, jQuery is indeed awesome!

[bufferoverflow]

jQuery is not awesome.

It was awesome 15 years ago. Now it's completely outdated. It's very hard to reason about DOM that can be manually changed by any random piece of code. That's why declarative solutions like React/Vue/Svelte are so much better.

[rjbwork]

>It's very hard to reason about DOM

I don't mean to be overly snarky here, but as someone who's just totally out of their depth in modern web UI - is that why people like these frameworks? Because they're very easy to reason about? I've generally found them to be mountains and mountains of boilerplate and spaghetti, but I really do not have a wide base of experience to pull from on this topic.

[Capricorn2481]

I started with Jquery, I learned React. I prefer React.

React complexity is often conflated with things like Next JS or other SPA solutions. React was originally meant to be a library for building small components that you drop into an otherwise static websites. But people usually don't talk about React unless they're talking about whole sites being in React. For that reason, I think its complexity is exaggerated.

More importantly, what the commenter is referring to is the fact that you are encouraged to write Jquery code that can break if you decide to move a div or change a class name. The workflow of CSS selectors is fine for small apps, but can lead to hard to track bugs down the road. It can be avoided if you make a lot of unique IDs. But otherwise you're screwed. There's no scoping. You technically have to read every piece of Jquery code before changing any other code, html, or css, because you could break half the site depending on what people were depending on. There's no IDE support telling you what is selecting what. Events are not colocated on the things they attach to, they could be anywhere.

I can update a React component and be sure that the only places it affects are the places its rendered. And I can get type checking on every input going into a component. That's just way better to me.

I still use JQuery at work, but I usually dread it. And people say JQuery is "smaller" but I would still prefer something like Svelte to Jquery if that's a concern.

I can take or leave Vue, I don't really notice a huge difference between it and other component frameworks.

[treflop]

I’m a big fan of React and jQuery but it sounds like you’re not using jQuery right.

All my jQuery components were self contained and you just initialized them with $(‘[data-date-picker]’).datePicker(). It is pretty obvious to anyone looking at the code that if you remove “data-date-picker”, it stopped being a date picker.

[erhaetherth]

Then you have dumb stuff like if you check a box and want some additional form fields, you have to inject a div or input into the DOM manually, and then make sure you initialize your datepicker, but maybe there will be a flash of unpickerified input if you don't do it right.

[spiderice]

I haven’t used jquery in 10 years or so, but I’m pretty sure this isn’t what you would do. You would just hide or unhide the inputs with jquery.

[Capricorn2481]

That is true, but this is built-in to React and it's optional for JQuery. I am working on legacy projects a lot and nobody ever writes JQuery like this outside of famous libraries.

[rolisz]

React was developed by Facebook. I don't think they did it for small components on otherwise static sites.

[Capricorn2481]

Facebook was a fairly static site back then, but small is a relative term here. I don't mean to say it was only meant to do that. Just that the origins of React are a far cry from the complexity of SPA frameworks like Next JS. And it can still be used as quite a simple drop in component system. Nothing is stopping you from doing that. Which is why people often say React is not a framework but a library, because it's true.

https://legacy.reactjs.org/blog/2013/06/05/why-react.html

[Zardoz84]

what I usually did, was using data-xxx attributes (and document these attributes and how works) to inject special functionality to html elements. I did this with jQuery, and now I do with vainilla JavaScript.

[christophilus]

That's one of the reasons I like them, yes. I've done a lot of manual DOM manipulation, and a lot of jQuery. When you're building anything complex, it starts to become quite difficult to figure out why a particular piece of the DOM is behaving the way it is. It could be an overly aggressive selector that accidentally targeted it, or any number of things.

Prior to React (and similar libraries), DOM manipulation was generally done in a mutating, effectful way. With React (and similar), if a thing is behaving strangely, I just need to go to the component that rendered said thing, and I can almost always find the problem.

[kccqzy]

Yes React is easy to reason about. In fact old versions of React were even easier to reason about than modern versions using hooks (`useState`). I used to use React and just React: no random npm packages, no Babel or any transpilation, no JSX, and it was pure joy compared to jQuery in a complex multi-step form. The jQuery code was in fact spaghetti.

[jmondi]

For your blog, jquery is totally fine and reasonable. Jquery for a web application? That is going to be way more of a headache. It all depends on what you’re trying to accomplish.

[marcosdumay]

I guess the "easy to reason about" thing people keep saying is meant to tell you that the modern frameworks allow modularization.

Personally, I do find their style of modularization abhorrent. As you said, it's full of boilerplate, it's also full of dependencies, and the worst sin in a software architecture: they don't enable you to specify a simple interface between modules. But they do solve the lack of structure you get when all the code talks to each other freely through the DOM.

[docmars]

Creating a brand new Vue app using Vite as your build system (official) takes less than 2 minutes and you can immediately start using Vue by following its documentation and creating a well-organized web application with its friendly patterns and solutions to the most common pro-UX problems you could encounter in a web app.

Give it a shot, it's stupid-easy, and that's not downplaying anything either.

[rjbwork]

This is pretty funny because the front end team at my company decided last year to migrate from Vue to React because Vue is too complicated and it's hard to find people who know it vs React. Impossible for me to get a read on this stuff. Such a clusterfuck of an ecosystem.

[docmars]

Yea there's certainly a lot of mixed opinions and learning curves involved to be sure. On the one hand, I love how many options there are to build web applications, but on the other, it really does feel fragmented and hiring front-end engineers is a huge gamble with all the different preferences involved because there is no true concept of "standards" everyone follows.

Thankfully it's pretty easy to align a team with a little time and learning what everyone wants.

[scotty79]

You can make spaghetti with everything. But without framework spaghetti is even worse. People who make a mess out react do it because they try to use it as if it is jquery.

[genocidicbunny]

> It's very hard to reason about DOM that can be manually changed by any random piece of code.

I think the parents point is that many websites don't need to change all that much DOM manually, automatically, or in any fashion. And I would agree with them, that for when the only 'dynamic' part of your site is one or two simple forms, and maybe a little carousel of images, jQuery may be perfectly awesome.

[williamcotton]

That is not why React became popular. We have to go back to the end of the server-side ORM era. ERB templates creating an LI element in a certain manner and jQuery creating the same element. So have fun keeping those DOM elements in sync! This and the ever expanding DOM APIs led to single page applications where all of the markup was generated by the client. Cue, oh fuck this is slow and oh fuck, page loads and SEO suffers, so then we see the emergence of virtual DOMs along with server-side Javascript, and we are now generating the same DOM elements with the same code on the front and back. Then everyone realized we are making these complex applications with an untyped language with lots of warts… Flow and Typescript emerge.

Guess what? Spooky action at a distance continues with reducers, custom hooks, custom injected contexts, etc, etc.

[labster]

Different use cases. A lot of the web only has only one or two interactive elements in a scope. The DOM being changed by any random piece of code is not a problem when all of the JavaScript fits on two screens. In fact, it’s a benefit here.

[drschwabe]

It's good for quick things and prototyping cause you can always swap out those calls with native later. It's API is generally easier to remember/less typing that most native equivalents. You can also use its API serverside via Cheerio to do parsing & manipulation of html without a dom.

edit: also its way more lightweight than React/Vue/Svelte i don't necessarily disagree you shouldn't reach for jQuery if you have a dynamic page (something like uhtml+preact signals would be good if you have fair bit of rendering logic going on) but I would say you should totally try seeing how far you can get with jQuery instead of Svelte/React/Vue on simple pages.

[zztop44]

Is it really way more lightweight than Svelte? Svelte has more tooling (of course) but it ships no runtime and only sends the user the JS they actually need to interact with your page.

[drschwabe]

Well, if you're talking SvelteKit then it requires a build step so yes, jQuery is way more lightweight.

jQuery is also pure JS whereas Svelte is Typescript so it may be more difficult to debug/hack if your primarily JS coder.

[hsbauauvhabzb]

I learnt jQuery and I would say ‘I could code in jquery, but not pure JavaScript’ - that’s since changed but I do still find foreach jQuery iteration by classname fairly elegant, in addition to $.get and $.post.

I’m not saying that it’s good or bad, but maintenance may mean developers who don’t know or care for modern web don’t have to learn something new.

[Klonoar]

No, if you actually make modules with jQuery where it’s creating it’s own DOM tree, it’s no different from what React & Co are doing.

Reasoning about the DOM structure has almost never been an issue in my almost 20 years of professionally doing this junk. The complexity has always been elsewhere.

[alternatex]

And you're arguing the complexity that has to be somewhere should go in your custom built jQuery modules instead of components built with a well-known framework?

I spent years maintaining front-end code built by devs who believe their way of doing things was better than what's popular in the industry and I disagree about jQuery entirely.

jQuery is a low level tool and always ends up biting people as the project grows.

[Klonoar]

> And you're arguing the complexity that has to be somewhere should go in your custom built jQuery modules instead of components built with a well-known framework?

jQuery + the DOM are well known frameworks. ;P