Any advances to removing deprecated APIs or functions are great. jQuery will probably be around dominantly on the web for years to come.

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.

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.

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.

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.

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

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

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.

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.

I upgraded PHP 7.2 to 8.3 for a business client yesterday.

It was a CentOS VM.

It took maybe 5 commands, no server restart involved either.

I could barely bill an hour and that is because I kept tail -f their logs to see if everything went smooth. And it did.

How is that painful?

And your example, codeigniter, is one of the worst examples in PHP.

Not only it is a framework that has minor usage: https://trends.google.com/trends/explore?q=codeigniter,larav...

It is infamous for being hard to upgrade. No responsible PHP developer would start a complex project in it today.

A typical PHP project in the last years use either Laravel or Symfony.

Not to mention PHP has mature tooling to perform automated code upgrade between versions: https://github.com/rectorphp/rector

The project I mentioned was 4 years old and so far no code change was required between PHP 7.2 and PHP 8.3.

And again, my parent was clearly talking about server upgrade: "was alway easier just to build a new server".

And the change I had to do was not even multiple lines, it was a single line in a Dockerfile. I found the Pull Request and it was from 7.4 to 8.3:

https://i.imgur.com/MmemYSp.png

Saying Code Igniter is not used in a lot of places because of Google trends is wrong for a lot of reasons, but the biggest of which being your graph shows laravel and codeigniter neck and neck a decade ago. Who cares whether new projects are started in code igniter? PHP is mostly legacy apps, and there are other frameworks with similar nightmare stories.

Again, JS is bad too, but we have to completely rewrite sites due to some PHP framework upgrades because PHP let's people do really dumb ORM templating.

I have no idea what you're referring to with your distinction between tech debt and server upgrades. I'm talking about server upgrades, clearly. I'm just saying if you upgrade PHP on an old project chances are things will break. This happens with Laravel and Slim too.

PHP has nothing to do with ORM problems. Any language allows dumb stuff related to ORM. Those are the libraries rather than the language.

PHP, like any language, has good and bad libraries.

If a project uses a bad solution for ORM, the language is not to blame.

I can do dumb ORM stuff in C#, Java, Rust, C++ and Python.

If a project picked a bad framework 10 years ago and now complains about the language instead of the framework I don't know what to tell you.

The same goes for Node, which doesn't break servers just because you upgrade it. I have updated from 12 to 20 with no problems because of the dependencies.

You might have had a smooth experience, and happy for you. But PHP didn't have, maybe it does now, such a good version manager as NVM.

But yeah we also had once where all the way back where we didn't do it with NVM and that was a pain in the ass.

And how to install every version you want NVM, that's on the user if it didn't work. That's not something different then can happen with PHP or other tools as mysql in the LAMP setup.

It's fairly normal to run some version of `npm run serve` with a filesystem watcher that will hot-reload changes as they occur so that you can see changes every time you hit :w (or CMD+S or whatever saves a file on your filesystem)

I just use Docker for both local development and remote deployments, with bind mounts of source code when I'm working the code, sometimes with appropriate remote debugging set up. I don't even care that much about what packages or versions are available on my workstation OS, as long as Docker (or another OCI runtime like Podman) works. Same for external dependencies, like Redis, RabbitMQ, MariaDB/MySQL/PostgreSQL and so on, they can just be throwaway containers, or maybe something more persistent in a cloud deployment.

I can even start with an Alpine/Debian/Ubuntu/whatever base image and install the packages myself in whatever order I want, to use as a base image for all of my apps. And on the server, I can run whatever cluster I want, since Docker Swarm or Nomad will be way easier to use for most use cases than a full distro of Kubernetes (although K3s is fine). That takes care of scheduling, health checks, restarts, resource limits and reservations, storage, networking and a lot of other concerns.

I usually have some sort of a web server as a reverse proxy in front of everything anyways (Apache/Nginx/Caddy/Traefik/...), so it's no big deal to add a bit of configuration. Even on PHP side, setting up PHP-FPM is a few commands and any configuration for either is sufficient with either environment variables, or changing a few files. Maybe a Bash script for an entrypoint that does the setup for every container launch, based on the needed configuration.

As an aside, with Apache you often don't really need to use .htaccess since disabling it and using configuration files under sites-enabled is better for lower IO, much like Nginx, since you don't need to scan every directory to look for the file: https://httpd.apache.org/docs/current/howto/htaccess.html#wh...

Node is fine. I don't even need to use nvm locally, I can just have different base images for containers with different node versions and then easily check how easy it would be to carry all of my software over to something else (by swapping out the base image), without messing around with installing stuff manually. As for installing packages "globally"? Who cares, it's all inside of the container image anyways, so suddenly that distinction doesn't matter in the slightest.

I don't need any external services or PaaS providers, it's just a container that I can run on pretty much any VPS host and horizontally and vertically scale as far as I need. Regardless of whether inside of the container there's JS, PHP, Java, .NET, Ruby, Python or anything else. This is especially nice when I can use Woodpecker CI or Drone CI, or GitLab CI or pretty much anything else and not worry about polluting workspace folders, the builds use containers.

And with modern frameworks and libraries, it's pretty hard to go wrong: Express and Next are okay, Laravel is okay, Spring Boot is okay, ASP.NET is okay, Ruby on Rails is okay, Django is okay, there's a lot of established options out there. Do they have pain points? Sure, but they hardly matter. Docker solved software development for me.

Honestly, just use whatever works for you. jQuery has its place, so does Node and PHP. I think I even have some Perl running somewhere.

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.

Nowadays the basics are just abstracted away and talking with developers today who might even have never seen the basic version of an on old-school Webserver or a simple HTTP request executed manually via telnet runs sometimes into really weird error and root causes analysis.

So sometimes I wish the younger developers would know a bit more from the old world while the older developers now a bit more of the new world of web technologies (apache and a cgi driven bash script are not always the best solution even if you can squeeze ultimately everything into making even that work depending on your time and sadistic level :-)).

Most of the modern solutions out there have been developed to solve very specific problems for a certain group of people (see the difference between React and Angular in that regard) and not always the solution everyone seems to use is the best for your problem, team and business.

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.

  JQUERY:
  $(el).toggle();

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

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

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

You can golf it down a bit:

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

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

  $(el).toggle();

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

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.

jQuery selector engine was developed before the official Selector API, which ended up being almost exactly the same. Except for a few exceptions which John wasn't too sure about when they asked for feedback:

https://johnresig.com/blog/thoughts-on-queryselectorall/

To reiterate:

> The argument for querySelector / querySelectorAll calls is literally mimicked from John Resig's grounbreaking API design

No, it wasn't. "The argument for querySelector / querySelectorAll calls" is literally ... CSS's selector language, which predates jQuery by about a decade. And the idea to make a library function to match against selectors was conceived of and implemented by Simon Willison years before jQuery was released, spawning lots of copycats. jQuery was literally named jQuery because writing a library to do this was the hotness at the time and one such library Resig had used was called cssQuery.

(jQuery does do a lot more than just match CSS selectors, but what that involves is not something jQuery has in common with querySelector—it's nowhere near "almost exactly the same". The result of a jQuery call has a weird, jQuery-specific shape. (It's not an element node). If Simon's getElementsBySelector did what jQuery did, Resig wouldn't have written jQuery.)

This is a matter of public record, and to state or suggest otherwise is worse than just being wrong. It misleads and confuses people.

https://twitter.com/simonw/status/1536129600232665088>

https://www.slideshare.net/jeresig/history-of-jquery>

One would argue whether we'd have querySelector if jQuery wasn't as popular. We may have an inspiration chain here... but thanks for pointing out to prior art.

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.

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

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

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

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.

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

(I was going to joke that TRS-80 BASIC had it circa 1979, but it turns out that it would be a two-step operation: Python’s str.ljust(40) would become LEFT$(STRING$(40, " "),40) .)

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.

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.

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.

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.

Please excuse any typos, written on the phone

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

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

Since JavaScript never actually requires line breaks, yes.

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

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

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.

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.

Do you have an example of that?

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

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.

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.

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.

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

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.

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

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.

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

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.

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.

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

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.

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.

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.

jQuery + the DOM are well known frameworks. ;P

We have stuff like querySelector and toggle in vanilla JS that makes it possible to change state simply, async stuff is much easier to understand than callbacks, and there are ways to split your code into components without using shadow or virtual DOM (see: raw web components, shadowdomless Lit, Svelte, etc). I've never found myself longing for something like jQuery.

The thing is for a certain time, jQuery was almost seen as inseparable from JS itself. Like the Python standard library is to Python. You can still find StackOverflow questions today asking to do something in JS and the answer is jQuery, and not just "here's how to do it in jQuery", just "here's what you asked for". That means it certainly got used in a lot of places where it wasn't really necessary.

The backlash against it, though, is just your typical pendulum swing that seems so much an unfortunate part of human nature. It's like when CSS was in and table-based layouts were out. I saw developers trying to use CSS to render tables. Nuance is hard and people can't help going to extremes. jQuery is probably still a really useful tool. I've seen some jQuery expressions that are far more elegant and beautiful then a plain JS equivalent. Whether this matters for any particular project is completely up to you. I don't like the way it encourages tons of ad hoc JS snippets all over the place, but that's a fault of developers, not jQuery.

A rewrite in a modern JS framework is just not going to happen unless it becomes absolutely necessary. Much of this code is extremely client-specific stuff written over a decade ago. The argument that using a modern framework helps recruiting doesn't work - the company only pays $75-90k for frontend engineers and has very low turnover, most current engineers have been there 5+ years. And most importantly, their current stack works just fine; they have a bunch of long-time clients who are happy.

A good chunk of software engineering happens in "boring" businesses like this in cities with a much lower cost-of-living than the big tech industry hubs like the Bay Area / Seattle / etc.

Not broke? Don't fix!

If I ever decide to retire from latest and greatest hype cycle big tech startup world, I’ll go build Wordpress sites for honest coin and wrap up every day by 3pm.

Maybe on meeting 27 they will put the damn thing on and save themselves the headache of getting out of RBLs.

If theres one thing WP developers cant write its contact forms! :)

P.S. Wordpress is fine in general.

[Just for example, my base component class listens for a particular custom resize event dispatched from the screen that contains it, which only dispatches to components on screens that don't scroll and need to reformat their contents. The screen class listens for window.resize but only dispatches if it's in trouble with the layout. Putting individual DOM resize listeners to window on each and every component would be insane.]

    document.querySelector('#something').dispatchEvent(
      new CustomEvent('myCustomEvent', {...options})
    );

    document.querySelector('#something-else').addEventListener('myCustomEvent', () => {...});

    new Event('myCustomEvent')

For triggering 'click' events and such, you can create and dispatch native events, as described here [1].

More verbose than jquery, like most native DOM APIs, but works well.

If you're not dealing with a DOM element and just need to dispatch/listen from a class, try out EventTarget [2]?

Your class can inherit from EventTarget, and it gets dispatchEvent and addEventListener, just like a DOM element and you can use any of the above things with it:

    class Test extends EventTarget {
    ...
    }

    let foo = new Test();
    foo.dispatchEvent(...);

[2] https://developer.mozilla.org/en-US/docs/Web/API/EventTarget

Dojo put the fear (respectful) and fear (scared) of big, enterprise frontend development in me.

http://script.aculo.us/

Do we need to get into underscore etc?

Why still? WordPress, like jQuery, is awesome. It's an incredibly powerful and easy open source CMS. I hope it takes more of the Web.

And if you're gonna defend the decentralization of the Web (and I do), it's hard to find a better argument than “just buy a domain and install WordPress”.

We’ve built sites for a very large social media company where everything had to be audited before production including third party plugins. WP VIP has a list of plugins they’ve vetted and/or applied their own patches to secure.

Rock solid? I don't really trust the codebase at all, and generally you need at least some plugins.

While I do a lot of effort to stay off jQuery these days, every time I have a library that ends up using jQuery its always intuitive to use.

if something is used, it has value. it's not deprecated.

It would be around for long is nice, but you can't make a career using it these days.

jquery, perl just some of those insanely useful tools which get the work done, but they don't pay you well these days.

Honestly at the end of the day they both get the job done, but for me personally working in JSX is just so easy to pickup and use, and while it's not perfect, I do prefer it over having to learn yet another library specific templating kinda-sorta language.

That's not what vue templates are. It's three or four different templating DSLs in one.

v-for alone will show that it's not HTML with Javascript: https://news.ycombinator.com/item?id=28059397

And there's more: https://news.ycombinator.com/item?id=19199423

The pattern is very obvious?

If array: (value, index)=>void

If object: (value, key, index)=>void

If it's an array, it's the call signature for the args of the forEach method, i.e. (value, index)=>void, but can be assigned a function that's just (value)=>void if index is unneeded. If it's an object, it's an extension of the same logic with (value, key, index).

It's not 4 dsls in one, anymore than jsx is a 1000 markups in one.

It's not

> It's not 4 dsls in one, anymore than jsx

I "like" that when discussing these things everyone completely ignores everything, and focuses on one specific thing.

So, again. The claim was that Vue templates is "HTML + Javascript"

1. As v-for clearly shows it's not even close to Javascript, as there are no Javascript constructs that correspond to this

2. As everything else, not just v-for shows, it's neither HTML (so many custom attributes with extensions and shorcuts etc.) nor Javascript.

https://github.com/BorisMoore/jquery-tmpl

[1] https://github.com/alex-kinokon/jsx-dom

For work that needs a little enhancement on top of server-side HTML, but not a full-blown JS UI framework, jQuery is a small price to pay for a stable, reliable, and cross-browser compatible dependency.

Yes, the vanilla selectors are more verbose, but any half decent code editor will make them just as fast to type. I don't mean to be penantic, but I don't really understand why so many people still use jQuery at all.

https://youmightnotneedjquery.com/

And what are we saving by eschewing it and going vanilla? One little 30kb-gzipped javascript file - smaller than most jpegs. I agree for super simple tasks it might be best to skip it.

The DOM API is a sloppy and hastily-designed pile of crap from the OOP era that we're unfortunately stuck with for legacy reasons. jQuery shows what it could have been.

Ends up eliminating 50-60% of the code, and the time for writing and reading it.

As for jquery I haven’t needed it much since stimulusjs but loved it whenever I used it.

You can modify the code to set the display property as inline-block, but now you need a different show function for every possible display value you want to restore. Or you need to build a layer of state to remember what the original value was and hey you've rewritten the jquery version.

And this is all ignoring that the jquery versions just look so much simpler to remember and are cleaner to read.

```css .hide { display: none important!; } ```

```js function hide(el) { el.classList.add('hide'); } ```

I'm convinced this site is actually satire and it designed to promote jQuery. In nearly every example, the native version is far more verbose.

These days I find vanilla far easier to read and it is a lot more clear to me what is actually happening in the code.

Depending on jQuery limits your ability to work with code that does not use it. Ie a lot of the more professional libraries.

For me dropping jQuery feels like a step up. Why don't you just try it, see what happens. It's just a day of being a little bit annoyed and then you should be fine.

Because it has a beautifully designed API. I don't directly use jQuery usually anymore. But I use the API in a basic DOM wrapper I've written. https://gist.github.com/pseudosavant/b86eedd9960ade958d49447...

The great things about these plugins is that you can strip them down to what you need and patch them yourself (remember lib or vendor directory). NPM and build tools make this a chore.

It could be argued that avoiding unnecessary work is my main job function. It's a lot more efficient to just get something that already does what I need, without requiring patches. In my experience leaving the jQuery ecosystem made this a lot easier.

You'll likely be adding 6-700KB of React and its ilk anyway (I see it in every project now).

With jQuery it feels like a lot of functionality is hidden away, which can lead to unexpected situations that are harder to debug.

In my experience writing vanilla code takes less time, not more, because I have a better grip on what is happening.