jQuery v4.0 Beta(blog.jquery.com)
blog.jquery.com
jQuery v4.0 Beta
https://blog.jquery.com/2024/02/06/jquery-4-0-0-beta/
397 comments
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.
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.
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.
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.
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.
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.
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:
From: https://youmightnotneedjquery.com/#toggle
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
> 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.
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.
A more modern solution would be to use classList.toggle() or toggleAttribute(hidden).
> Gotta love that "modern" triple attribute repetition.
You can golf it down a bit:
You can golf it down a bit:
el.style.display=el.style.display == 'none' ? '' : 'none';Surely
el.style.display = el.style.display ? 'none' : ''
Even though I can appreciate the elegance of your solution, I'd prefer the former for clarity.
Of course. Because that's infinitely better than:
$(el).toggle();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.)
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.
Edit: https://caniuse.com/?search=classlist.toggle and click Usage Relative.
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).
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).
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.
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.
cxr(1)
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.
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.
For some reason, JQuery is the exception to the general rule of seeing a mature, battle-tested library as a sign of quality.
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".
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".
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.
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.
Another part was the abysmal API that Javascript (and mostly still today) offers to work with the DOM.
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.
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.
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.
>For almost every task it describes, the jQuery code is shorter, cleaner, and more intuitive than the vanilla "modern" JS one.
Just like leftpad.
Just like leftpad.
Instead of needing to import leftpad you have the missing standard js lib
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.
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.
> 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
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
Ruby and PHP both have string padding functions. So does Swift. (edit: and as Macha points out, C and any language with printf functionality, like Perl.) It’s not that uncommon.
(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 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) .)
C has it in their standard library, basically forever. See the list of specifiers to printf. C! If it fits into the C standard library, it's not bloating the Javascript standard library.
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.
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.
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.
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.
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.
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.
Weird analogy. I’ve camped my whole life, never once brought a power tool.
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
Though both do what I typically need them to do, customising datatables.net takes me a bit more time though
Big plus is, it also gives yo the option to export the tables to pdf and other file formats.
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.
> you can have that with server-side rendering plus
yes, we use PHP for this which is much simpler to grasp than JS-SSR
yes, we use PHP for this which is much simpler to grasp than JS-SSR
In node there is EJS which is basically PHP templating with JS.
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.
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.
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.
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.
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.
> Upgrading PHP version is even more painful, I've tried to do version updates, and was alway easier just to build a new server.
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?
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?
This is just intellectually dishonest. It completely depends on whether your libraries have breaking changes and how your app is structured. Many legacy projects use old versions of ORMs and frameworks that don't support PHP 8. So now you're also upgrading code igniter and you're looking at hundreds of files that call it's ORM
No. If we're talking about tech debt (that's not what parent was talking about by the way) then JS is a magnitude worse. Running old projects from JS ecosystem can require multiple miracles, not only code refactoring.
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
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
Nobody said js wasn't worse, just that your experience is not the experience of most PHP upgrades.
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.
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.
it was when I had to move php5 to php7 5-6 years back, and if I remember correctly a few OS libs didn't support php7 so that was really hard. Was faster to build a new VPS, since no big DB or storage was easier.
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.
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.
You normally want to see things locally as you develop them. Vercel is cool and all, but doing a git push and waiting for the build every time you want a refresh? Nah, that's not viable. And almost everything mentioned above for deployments applies to your own dev machine as well.
Okay then your comment is weird, windows & mac dont have distribution with node versions lower then LTS. It can be an issue on ubuntu/linux having an outdated registry. But nextjs clearly states minimum node version in their docs: https://nextjs.org/docs/getting-started/installation
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.
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.
The context here is the "starting with" situation. It's much easier to do that with PHP since you normally don't have to care about versions there - barely anything requires version higher than in LTS. On the other side it doesn't matter what is clearly documented, or which registry is up to date - a person looking at this for the first time is either going to have an easier life or not. Nextjs effectively has extra steps you need to know about and follow.
that's simply not true. nodejs v12 is years old, its like using php5 and lots of platforms don't support 5 anymore.
Why do you have to wait?
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)
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)
The context is about the initial setup and the parent comment recommended vercel git flow. Yes, you can run it locally, but that's back to the "getting started" issues: https://news.ycombinator.com/item?id=39286669
Okay. I think it's fair to say that if you don't install the tool you're developing in, it does make it much harder to work in locally.
That's equally true of PHP.
Moreover, it's equally true that distros aren't always shipping the latest PHP versions, and that there are similar flamewars surrounding phpenv/pvm as there are nvm/asdf. There are options, and people have opinions. The more ensconced one gets in an ecosystem, the more easy it is to know which tools offer which benefits relative to your needs. None of those decisions are easily made when new to an ecosystem -- Elixir is newish and has enough coalescence around most of the mainstream things, but as someone new to it, if I needed to choose between Cowboy and Bandit, I would have quite a bit of learning required upfront.
That's equally true of PHP.
Moreover, it's equally true that distros aren't always shipping the latest PHP versions, and that there are similar flamewars surrounding phpenv/pvm as there are nvm/asdf. There are options, and people have opinions. The more ensconced one gets in an ecosystem, the more easy it is to know which tools offer which benefits relative to your needs. None of those decisions are easily made when new to an ecosystem -- Elixir is newish and has enough coalescence around most of the mainstream things, but as someone new to it, if I needed to choose between Cowboy and Bandit, I would have quite a bit of learning required upfront.
You really think nextjs is difficult just because one person you knew had a very outdated nodejs version; it's really not.
From where I stand, both of you have some good arguments, but in my eyes the technologies are similar enough for the differences not to matter too much.
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.
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.
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.
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.
The funny thing, even with React and Next, it’s ultimately just files served via a Webserver and I believe it’s the least flawed version you can get without building your own implementation of a TCP server which support HTTP (good luck with that btw ;-)).
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.
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.
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.
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.
Express
[deleted]
You sure can, but it then comes to the separation of concerns. CSS-in-JS (coupling of concerns) is the preferred option.
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.
Even better - you may use service workers as your 'server-side'.
> 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.
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.
Just want to say I appreciate you for doing that.
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.
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.
I hear you. My site is 1 http request and no js so I’m definitely with you on this.
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.
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.
"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.
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.
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
Please excuse any typos, written on the phone
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.
No one is arguing that complex web applications don’t benefit from React and friends. It’s completely overkill for most of the web.
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.
any website that has any sort of meaningful functionality and communication with a server is mostly likely using some sort of framework.
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.
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.
A lot of marketing agency development is this sort of brochureware, and to your point they usually aren't using react.
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.
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?
> 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.
Since JavaScript never actually requires line breaks, yes.
Otherwise, absolutely not. Modern web APIs remain highly statements-based, with little affordance for pipelining / cascading.
One line of jQuery can replace many lines of vanilla js.
Nearly everything in jQuery is more concise, consistent and composable compared to modern JS APIs. As this site clearly shows: https://youmightnotneedjquery.com/
[deleted]
Yes, there isn't much reason to use jQuery these days other than keeping with the idioms of a legacy system.
[deleted]
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
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.
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.
From the guidelines:
"Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes."
"Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes."
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.
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.
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.
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).
lol react. Never seen a good react project. They all end up a mess.
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
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.
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.
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.
Its can be convenient to have some kind of reusable conponents. Like listviews wtih certain functionality. Same for routing. Caching etc.
Native web components / custom elements work great for this.
So you end up with an component framework.
you don't "need" a framework for backend development, too, but most people find it highly convenient
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.
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.
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)
jQuery remains the best JSONP library. It can get data even when other libraries are blocked.
If I understand this announcement correctly, they removed support for JSONP
Just removed "Automatic" JSONP "promotion". JSONP is still available.
Fully agree, jQuery + Bootstrap + standard Web + SSR, and we're gold.
I read that the JS fetch API makes jQuery obsolete, is that not true?
>But jQuery doing dynamic binding to dynamically generated forms
Do you have an example of that?
Do you have an example of that?
Yup, jQuery is indeed awesome!
cxr(1)
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
[deleted]
React was developed by Facebook. I don't think they did it for small components on otherwise static sites.
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
https://legacy.reactjs.org/blog/2013/06/05/why-react.html
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.
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.
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.
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.
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.
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.
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.
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.
Give it a shot, it's stupid-easy, and that's not downplaying anything either.
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.
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.
Thankfully it's pretty easy to align a team with a little time and learning what everyone wants.
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.
> 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.
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.
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.
Guess what? Spooky action at a distance continues with reducers, custom hooks, custom injected contexts, etc, etc.
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.
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.
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.
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.
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.
jQuery is also pure JS whereas Svelte is Typescript so it may be more difficult to debug/hack if your primarily JS coder.
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.
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.
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.
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.
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.
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.
> 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
jQuery + the DOM are well known frameworks. ;P
I don't care what anyone says, jQuery still rocks and is so damn important and influential. You remove jQuery from every piece of software a good chunk of the all the websites stop working all around the Internet.
Yup, hard truths: vanilla JS is far less readable and clunkier than just using jQuery to do the same thing. Also, not everyone needs or wants to move to a shadow DOM framework with a zillion components and high complexity. If you're building a SPA or PWA, yes, absolutely, but for the vast majority of us who use a traditional backend/CMS-driven site with server-side rendering where client-side interactivity is needed, jQuery still does the job really nicely.
Now I might not know what I'm missing out on since I haven't worked in any projects w/ jQuery as I haven't been developing websites for a long time (and the type of sites I make probably also influences the stack), but there's probably something that does what you want as elegantly without jQuery.
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.
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.
If you're creating a fully interactive webapp (google maps, docs, or apple music), go with one of the frontend frameworks because they will give you a much simpler way of managing states and binding it to the view layer. But the majority of websites are not apps or shouldn't be. You'd only have a couple of interactive elements if you strip the UX to its core. And that can be done easily with server rendered templates and a bit of jquery/vanilla js.
I'm not saying jQuery isn't great, but being entrenched and being great are two different things. It's not really saying anything to say things would break if you remove it.
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.
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.
It's not just WordPress. A company I used to work for has tens of thousands of lines of jQuery code powering their enterprise SAAS product.
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.
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.
The other problem with a "rewrite in a modern JS framework" is that when it's finally done it'll only be a few more years until it needs another "rewrite in a modern JS framework". And that's worse, because at least with JQuery it just stays the same whereas with anything in the NPM ecosystem using anything older than, say, 6 months is kind of a nightmare in terms of dependencies and tooling.
Not broke? Don't fix!
Not broke? Don't fix!
Wordpress devs are the plumbers of the tech industry. It’s not glamorous work but there’s a ton of money in it because so many people need them.
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.
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.
The fact that Wordpress runs so much of the web sometimes wakes me in a cold sweat. If you're a dev worth their salt and knows proven engineering and design patterns, then Wordpress code is absolutely terrifying to look through.
See comments like yours do that for me. I will see you in the 30 meetings needed for the new form on the contact page.
Comments like yours do that for me. Every day we suspend several WP sites for failing to put basic captcha on their contacts page that results in the form being abused for email bombing.
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.
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.
heh, try 11-12pm. o.O
I was going to post on HN not long ago and didn't, about how I still can't find a great event chain handling / bubbling model that lets me use both DOM members and abstract class instances to trigger interchangeable events. I've built my own event dispatchers here and there, but jQuery just does everything right. Although event handling is almost the only thing I still use jQuery for, it's so useful that I still include it in almost every client-side project. The reason I was going to post was to ask if anyone knew of a slim library that could both $(window).trigger('click') and $(myClassInstance).trigger('myCustomEvent',{data}) with the same API for listening to either one asynchronously. With the rise of fetch() and css selectors I could probably do without the rest of jQuery at this point. But why reinvent the wheel? And before anyone tells me that having class instances dispatch events is a code smell... it's absolutely necessary if you want to build responsive frameworks from scratch.
[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.]
[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.]
If your class instances are attached to the DOM somehow, you may be looking for CustomEvents?
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:
[2] https://developer.mozilla.org/en-US/docs/Web/API/EventTarget
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
Thanks. Frequently though, my class instances are not attached to the DOM ...more often they're purely data classes that receive occasional updates and listen for events from one another. And it's unweildy or impossible to have them all inherit EventTarget as a base class. In any case it's overkill: I just need a fairly simple event loop to track instances, listeners and callbacks (on or off the DOM) and work as a switchboard for events, with the caveat that it's also nice to be able to pipe native events through the same switchboard when applicable.
I remember switching from mootools to jQuery back in 2006ish. Thought it was fantastic.
Awesome it’s still around. We still use it from
Time to time.
Don't forget Prototype (http://prototypejs.org/)
and scriptaculous!
http://script.aculo.us/
http://script.aculo.us/
YUI https://clarle.github.io/yui3/
Do we need to get into underscore etc?
Do we need to get into underscore etc?
Heh, yeah, I was a heavy Prototype user back when it wasn’t clear which one of jQuery, Prototype, Scriptaculous, dojo, or mootools would ‘win’.
And Dojo! https://dojotoolkit.org/
Oh man, back in the day I got my first exposure to big, enterprise web apps in the form of an undergrad internship on a control panel for a major database that ran on Dojo. Every time I could scurry back to Python to work on a backend feature, I breathed a sigh of relief. It put me off frontend for a long time until I arrived at a shop that taught better, and not being taught was definitely a big part of my fear of Dojo/frontend dev, but Dojo is also BIG and you can build some really unwieldy systems with it. You can do that with any framework, sure, but in the heyday of Dojo, it was a lot of opaque logic that wasn't as well doc'd out or understandable just by reading as today.
Dojo put the fear (respectful) and fear (scared) of big, enterprise frontend development in me.
Dojo put the fear (respectful) and fear (scared) of big, enterprise frontend development in me.
>…WordPress is still more than 1/3 of the web…
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”.
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”.
It's a buggy insecure mess. No one should be advocating for wordpress.
The only buggy or insecure code is really from third party plugins and themes. Wordpress core has been rock solid. Ya you still need to setup caching and there’s some modifications to run it at scale but that’s all a solved problem thanks to the likes of Automattic and their VIP platform.
how much of that ⅓ of the internet is running third party plugins and themes on their WP installation?
If they hired bespoke custom development from contractors at the price range these WP sites are developed for, do you think that would be better code?
How much of the rest of the web are using third party dependencies in their code?
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.
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.
> The only buggy or insecure code is really from third party plugins and themes. Wordpress core has been rock solid.
Rock solid? I don't really trust the codebase at all, and generally you need at least some plugins.
Rock solid? I don't really trust the codebase at all, and generally you need at least some plugins.
I’d like to know the name of this alternative that’s as feature-rich and yet bullet-proof while still being open source
it's called processwire and once I found it I never looked back
Django and Wagtail is one option. Do a little research and you'll find others.
Neither are written in PHP so they don't work on most cheap hostings.
You can get a kimsufi server for $6/month, and there is plenty of cheap hosting offering django, pretty sure you can even find python hosting for free up until a point.
It depends on who you listen to. Non coders seem to love Wordpress. I worked in a place with a Django booking site and a Wordpress marketing site. The other two devs knew PHP, while I know python, they advised me not to learn it and to stay away.
nature abhors a vacuum
jQuery will always hold a special place in my heart. It made absolutely terrible APIs usable and help abstract away a lot of the different browser issues.
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.
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.
And many many company internal tools, that won't be rewritten and just get replaced with something better(ReactJS?) over time.
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.
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.
> Any advances to removing deprecated APIs or functions are great.
if something is used, it has value. it's not deprecated.
if something is used, it has value. it's not deprecated.
The fact that it, well, works doesn’t help with the React world domination either.
Honestly, though, given more sophisticated browser-native selectors were implemented way after jQuery was, I wonder why didn't they just make at least somewhat jQuery-compatible API. It's just way simpler.
A lot of us are using it actively. It's so lightweight now that it s free, and it s somewhat better than vanilla js.
jQuery is just way cooler than the comparatively build in (and sometimes obtuse) web standard replacements for it.
They just need to add JSX support. Half the reason people use react is because of JSX.
Maybe unpopular opinion but JSX is inferior to something like the Vue templating system. I much prefer to have HTML with some JS sprinkled in than JS that looks like HTML but isn’t.
And to wage this holy war a little, I personally much prefer JSX over a templating system that looks like html attributes but acts different, while trying to act like javascript but can't.
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.
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.
Most of us devs had "separation of concerns is critical" drilled into us for many, many years. For that reason alone, JSX just gives me the baddest of smells when I look at it.
How does jsx not have separation of concerns? I get what you are referring to but that's not SoC as I know it
This way of looking at separation of concerns helps: https://x.com/simonswiss/status/1664736786671869952
> I much prefer to have HTML with some JS sprinkled
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
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
> That's not what vue templates are. It's three or four different templating DSLs in one.
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.
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.
> The pattern is very obvious?
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.
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.
And vue templates are in turn inferior to lit-html
Fully agreed. I built a mostly vanilla JS app using a bare bones JSX lib[1] a few months ago and was surprised at how little I missed the rest of React.
[1] https://github.com/alex-kinokon/jsx-dom
[1] https://github.com/alex-kinokon/jsx-dom
A variant of this was tried over a decade ago, but never made it live - jQuery Templates. Not quite the same…
https://github.com/BorisMoore/jquery-tmpl
https://github.com/BorisMoore/jquery-tmpl
If "they" is WordPress, have you tried modern PHP? 8.x has come a long way to looking and feeling like a modern programming language. So many new things reminding me of Typescript, Javascript, Python, etc.
Should be easy. It is just a case of presenting the right interface to the generated code. For example Mithril supports it (with some quirks admittedly). But in simple terms it is an adaptor.
I think you can already do that by wiring together something like NakedJSX. You just need a fancy jQuery plugin to make it more ergonomic.
Now we have React, React DOM and jQuery in WordPress.
1/3 of the web does not mean much. Are you referring to web usage or just the number of web pages?
web pages and it does matter a lot. Among others, Woocommerce runs 23.43% of e-commerce.
I'm consistently surprised by the commenters on HN who seem to think jQuery is just a DOM selection library, when in fact it is a widely supported, incredibly stable tool set for (yes) DOM selection, but also attribute manipulation, Ajax requests, event handling, animation, and general utility functions. What's more, where there _is_ native functionality that replaces jQuery, the API is never as fluent.
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.
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.
A few years ago I dropped jQuery for plain vanilla js and I've never looked back. Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins", that usually only do what they want to do and not much else.
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/
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/
Look at your own link - the "modern" way of doing it is always about 2-3x as verbose as jQuery. Editors let you type that mess faster, but you'll still have to read through it, maintain it, scroll it into view in your editor, see less of it onscreen at a time, etc. I'll take a clean, succinct API over a noisy verbose cumbersome one any day.
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.
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.
You just described why I use slim-lang in all of my projects. produces clean, correct HTML with zero noise.
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.
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.
I'd only drop jQuery/lodash if you were adding Typescript. And I do prefer dropping them for Typescript, but the previous are still cool.
That is not correct at all. The DOM API is entirely functional based upon traversal of a lexically scoped model. It may not be as declarative as you like but lying about what it is because it makes you feel uncomfortable is rather ignorant.
> The DOM API is entirely functional based upon traversal of a lexically scoped mode
wat
DOM APIs have been, and still are, 90s-era OOP style with zero attempt at being functional, declarative, or composable.
Even the newly developed API are usually stuck in the same mindset (see everything developed for web components)
wat
DOM APIs have been, and still are, 90s-era OOP style with zero attempt at being functional, declarative, or composable.
Even the newly developed API are usually stuck in the same mindset (see everything developed for web components)
The DOM is a big in memory object but the DOM APIs are entirely functional. Functional is not the same as declarative.
> DOM APIs are entirely functional.
(Almost) none of the DOM APIs are functional. They are literally `object.methodCall()`
(Almost) none of the DOM APIs are functional. They are literally `object.methodCall()`
Yes, functional programming can have methods. Methods are functions. OOP is all about polyinstantiation and inheritance. Functional programming is all about functions and input/output, which is entirely what happens in this case. The only OOP here is the method assignment you don’t see: Element.prototype.getElementById = function () {};
You're making no sense. Functional programming is more than just "about functions".
DOM APIs are the embodiment of 90s-era OOP. There's literally nothing functional about them. All [1] "functions" are methods defined on very specific objects. You can't even get a proper reference to them without binding them to specific object instances
What exactly is functional about this?
Most (all?) other "global" functions are defined on the instance of the window object: getComputedStyle, getSelection etc.
DOM APIs are the embodiment of 90s-era OOP. There's literally nothing functional about them. All [1] "functions" are methods defined on very specific objects. You can't even get a proper reference to them without binding them to specific object instances
What exactly is functional about this?
const newDiv = document.createElement("div");
const newContent = document.createTextNode("Hello, world");
newDiv.appendChild(newContent);
const currentDiv = document.getElementById("div1");
document.body.insertBefore(newDiv, currentDiv);
const function_reference = document.getElementById;
function_reference("#id");
Most (all?) other "global" functions are defined on the instance of the window object: getComputedStyle, getSelection etc.
> What exactly is functional about this?
A series of function calls that each do something and each returns a value.
> Okay, here's an easier question. What will happen here, and why?
A function call that does something and returns a value, because in this language complex types are passed by reference.
A series of function calls that each do something and each returns a value.
> Okay, here's an easier question. What will happen here, and why?
A function call that does something and returns a value, because in this language complex types are passed by reference.
> A series of function calls that each do something and each returns a value.
Doesn't make it functional
> A function call that does something and returns a value,
Ah, so you don't know.
Here's what will actually happen:
If it was functional this would never be the case. But since this is 90s-era OOP, you have to do this:
Doesn't make it functional
> A function call that does something and returns a value,
Ah, so you don't know.
Here's what will actually happen:
TypeError: Can only call Document.getElementById on instances of Document
If it was functional this would never be the case. But since this is 90s-era OOP, you have to do this:
const function_reference = document.getElementById.bind(document);
function_reference("#id");> A series of function calls that each do something and each returns a value.
This is not what functional programming is. Functional programming is a completely different paradigm for writing code, and it _is_ declarative by definition. The Wikipedia definition is pretty decent:
[1]: https://en.wikipedia.org/wiki/Functional_programming#Compari...
This is not what functional programming is. Functional programming is a completely different paradigm for writing code, and it _is_ declarative by definition. The Wikipedia definition is pretty decent:
Functional programming is a programming paradigm where programs are constructed by applying and composing functions. It is a declarative programming paradigm in which function definitions are trees of expressions that map values to other values, rather than a sequence of imperative statements which update the running state of the program.
[1]: https://en.wikipedia.org/wiki/Functional_programming#Compari...
Hate to pile on, but this is absolutely not the definition of functional programming.
Functional programming uses stateless, immutable transformations to contorl data flow. The second you instantiate an object with some internal properties that change in memory, you are no longer programming functionally
Functional programming uses stateless, immutable transformations to contorl data flow. The second you instantiate an object with some internal properties that change in memory, you are no longer programming functionally
Some of those examples aren't really equivalent. If you use that vanilla js way to show/hide, it won't restore the display property to the value it was before using hiding. It will just shift it between display: "none" and display: "". If you need something to be a display: "inline-block", the vanilla js example will lose that and break your styling.
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.
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.
Except you can do this:
```css .hide { display: none important!; } ```
```js function hide(el) { el.classList.add('hide'); } ```
```css .hide { display: none important!; } ```
```js function hide(el) { el.classList.add('hide'); } ```
LMFAO every example of "modern" looks like a course in how not to design an API, etc. The jQuery examples are so clean and expressive. Imagine landing on a page like that and thinking, "hey, that 'modern' option looks good." You'll end up with 28KB (jQuery gzipped size) of just extra syntax before you're done with your app, not to mention the additional 160 hours of work.
You'll likely be adding 6-700KB of React and its ilk anyway (I see it in every project now).
You'll likely be adding 6-700KB of React and its ilk anyway (I see it in every project now).
The code I write these days is cleaner and more readable than anything I did back in the jQuery days. The only thing I add (for bigger projects) is Typescript.
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.
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.
> Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins"
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.
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.
Stripping them down is work, especially with the type of code that can often be found in random jQuery plugins.
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.
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.
"I don't really understand why so many people still use jQuery at all."
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...
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...
> https://youmightnotneedjquery.com/
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.
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.
It's just a random site I remembered from a long time ago, there are better ones out there. One of them convinced me that jQuery is just a crutch. I tried a small project without it and it really did not take long to adjust.
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.
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.
FWIW, I'm not a front-end developer. I've had to do some over the years, but it's certainly not my area of expertise (I work in AppSec), so my opinion is worth very little.
jQuery might be a crutch, sure, but I'm not sure crutches are a bad thing. There's no reason to make something harder than it has to be. I just like how some things take far fewer key stroke and are less verbose, but still readable.
Readability is subjective. There are people that think Perl is fine and I think it ranks as one of the least readable languages to ever reach popular status. Meanwhile, I think Python is the most readable language to have ever been created, and somehow some people struggle with it, and tbh it kind of blows my mind.
jQuery might be a crutch, sure, but I'm not sure crutches are a bad thing. There's no reason to make something harder than it has to be. I just like how some things take far fewer key stroke and are less verbose, but still readable.
Readability is subjective. There are people that think Perl is fine and I think it ranks as one of the least readable languages to ever reach popular status. Meanwhile, I think Python is the most readable language to have ever been created, and somehow some people struggle with it, and tbh it kind of blows my mind.
your link actually convinced me that jQuery is a much better alternative to vanilla js.
I don't think it's that surprising given the demographics of HN posters that I've observed. Many will immediately reach for the big JS framework du jour when they need anything more than a little DOM selection stuff, because that's what they've always done.
There's 2 types of web pages. Websites and web apps. If you're building a web app, you're going to want a framework that isn't going to fall apart the second things start getting complicated. If you're making a little marketing website, sure, sprinkle some jQuery on there and call it a day. Probably better for performance and SEO unless you want to spend 10x as long micro-optimizing your SSR. Point is, there's different use-cases.
It’s all the same. The difference is not in the product but in the developer’s perception of the product. The code and the user don’t notice the difference, just the developer in the middle. There are those who can dynamically put text on screen and those who need just a little help to dynamically put text on screen.
> the user don’t notice the difference
Users do notice the difference is large JS framework driven applications.
Users do notice the difference is large JS framework driven applications.
Yeah, they notice how slow and janky they are, and how often they're staring at empty gray boxes while things load.
Okay, what part of what I said are you trying to refute or educate me on?
There's a large proportion of posters on HN who spend their days building web apps. They are very likely to stick to using what they know, even when building web sites.
If you spend your days working as a welder, and suddenly need to build a box for some reason, you're probably not going to be breaking out the fine wood joinery tools. You're probably going to take some sheet steel and weld up a box and move on to whatever else you have to do.
It's not a problem, it's not a fault, it just how things are.
There's a large proportion of posters on HN who spend their days building web apps. They are very likely to stick to using what they know, even when building web sites.
If you spend your days working as a welder, and suddenly need to build a box for some reason, you're probably not going to be breaking out the fine wood joinery tools. You're probably going to take some sheet steel and weld up a box and move on to whatever else you have to do.
It's not a problem, it's not a fault, it just how things are.
> Okay, what part of what I said are you trying to refute or educate me on?
Not the GP, but that's why, when applicable, I try to prefix my replies with a variant of "I agree, and btw..."
Not the GP, but that's why, when applicable, I try to prefix my replies with a variant of "I agree, and btw..."
yes and far easier to drop jq into a project.
no need for build tools and all headache. (i know you do that with react but its not comparable features).
no need for build tools and all headache. (i know you do that with react but its not comparable features).
You don’t run your JS through babel or minification?
why would I?
for a small project those efficiencies wont make a difference on my $20 godaddy hosting account.
i dont want some tool or process getting in my way. if i have a problem then i will look for a solution.
for a small project those efficiencies wont make a difference on my $20 godaddy hosting account.
i dont want some tool or process getting in my way. if i have a problem then i will look for a solution.
This, so much.
I do like SPA also, but some of the nicest projects I've worked with could be run locally by launching `python3 -m http.server 8008' on the right folder.
I'm happier when I can do something without a processing step, or the need for a package.json. Need a third-party script? Vendor it, and never have to worry about supply-chain attacks.
I do like SPA also, but some of the nicest projects I've worked with could be run locally by launching `python3 -m http.server 8008' on the right folder.
I'm happier when I can do something without a processing step, or the need for a package.json. Need a third-party script? Vendor it, and never have to worry about supply-chain attacks.
For browser compatibility?
In a world where many of us are actively trying to remove the last vestiges of jQuery, who is actively developing using jQuery? Genuinely curious. I’ve found that most of what I went to jQuery before is baked in now. querySelectorAll being the most powerful.
Because I'm old and new tricks are less interesting, I find $.ajax() much more simple than promise, await, async of native JS.
I have used straight native JS on a couple of smaller personal projects just to get some familiarity with it. However, it's just muscle memory type of getting stuff done with $.ajax() for me.
Also, maybe 20 people use any of the code I write for manipulating DOM. I'm not a UI person. I'm a back end person that has to write front end stuff because nobody else does it.
I have used straight native JS on a couple of smaller personal projects just to get some familiarity with it. However, it's just muscle memory type of getting stuff done with $.ajax() for me.
Also, maybe 20 people use any of the code I write for manipulating DOM. I'm not a UI person. I'm a back end person that has to write front end stuff because nobody else does it.
It’s only simpler because you know how to use it. For most use cases fetch and async/await is just easier.
I mean, duh? Of course doing something that I've done for a long time is going to be more simple to me than me fumbling/stumbling through something I haven't done much. What new insight are you providing me here?
Async await fetch lets you flatten your nested callback functions into simple procedural programming. It makes everything much easier to reason about, no more closures and such.
JQUERY:
await $.post({
url: '/my/url',
data: data
}).then(() => {});
await fetch('/my/url', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify(data)
}).then(() => {});
You dropped about 250000 characters from the first example.
Of course if you load a bunch of code beforehand your code will be marginally better.
The fact is that you probably don’t need to send JSON anymore because fetch accepts the whole form as an object:
Of course if you load a bunch of code beforehand your code will be marginally better.
The fact is that you probably don’t need to send JSON anymore because fetch accepts the whole form as an object:
await fetch('/my/url', {
method: 'POST',
body: new FormData(form)
})> Of course if you load a bunch of code beforehand your code will be marginally better.
That's exactly the point though. We use jQuery because it has an incredible easy and consistent interface that makes writing for the web so much more enjoyable. Selectors, events, chaining,... are all just nicer to work with than the vanilla counterparts. Same goes for all libraries and frameworks. :)
BTW: Your example is sending a "multipart/form-data". Not all API's will understand this, and will need JSON anyway.
That's exactly the point though. We use jQuery because it has an incredible easy and consistent interface that makes writing for the web so much more enjoyable. Selectors, events, chaining,... are all just nicer to work with than the vanilla counterparts. Same goes for all libraries and frameworks. :)
BTW: Your example is sending a "multipart/form-data". Not all API's will understand this, and will need JSON anyway.
> Not all API's will understand this
Who’s talking about APIs? Most jQuery users I know just use jQuery to submit forms and load some JSON, both of which are covered by fetch without altering the headers manually.
What I’m saying is that it’s not fair to judge a tool for something you don’t have to do with it, namely sending JSON for everything. Fetch also supports native binary uploads, whereas most people base64 data when using $.ajax
> makes writing for the web so much more enjoyable
Writing? I agree. Actually making it work? No way. $('forn').hide() doesn’t work, but the browser will never tell you why (hint: wrong selector).
jQuery errors are often silent, and that’s good enough reason to abandon it.
Who’s talking about APIs? Most jQuery users I know just use jQuery to submit forms and load some JSON, both of which are covered by fetch without altering the headers manually.
What I’m saying is that it’s not fair to judge a tool for something you don’t have to do with it, namely sending JSON for everything. Fetch also supports native binary uploads, whereas most people base64 data when using $.ajax
> makes writing for the web so much more enjoyable
Writing? I agree. Actually making it work? No way. $('forn').hide() doesn’t work, but the browser will never tell you why (hint: wrong selector).
jQuery errors are often silent, and that’s good enough reason to abandon it.
You don't need that then in the fetch example. I don't know about ajax.
[deleted]
see, this is where i'm not cool with this newness.
i've spent years getting away from procedural, and switching to functions, classes/methods. now, we want to get away from that and go back to procedural?
that's all fine and dandy, but you're trying to have a new trick conversation with an old dog that just doesn't care. you're bringing some sort of logic to a conversation where it's not needed. it works for me. i don't get paid to make UI apps or write heavy code nonsense with server side JS. i use a proper back end language. JS can stay in the browser and manipulate the DOM thank you very much. i get paid to make heavy processing code that sometimes is helpful to have UI dashboards.
i can whip up a JQuery front end faster for my needs than most can even figure out what NPM librar[y|ies] they need to use
i've spent years getting away from procedural, and switching to functions, classes/methods. now, we want to get away from that and go back to procedural?
that's all fine and dandy, but you're trying to have a new trick conversation with an old dog that just doesn't care. you're bringing some sort of logic to a conversation where it's not needed. it works for me. i don't get paid to make UI apps or write heavy code nonsense with server side JS. i use a proper back end language. JS can stay in the browser and manipulate the DOM thank you very much. i get paid to make heavy processing code that sometimes is helpful to have UI dashboards.
i can whip up a JQuery front end faster for my needs than most can even figure out what NPM librar[y|ies] they need to use
surely you still use procedural code within your functions and classes.
the point of await/async is you break down the callback nesting into a single set of procedural code. it doesn't mean all your code is procedural. just that what used to have to be a series of indented anonymous functions or spread all over the place named functions can now be an easy to read concise few lines of code all at the same indentation in a single spot. its an obvious net-win for readability and code maintainability. you are doing yourself no favors by not understanding/embracing it.
the point of await/async is you break down the callback nesting into a single set of procedural code. it doesn't mean all your code is procedural. just that what used to have to be a series of indented anonymous functions or spread all over the place named functions can now be an easy to read concise few lines of code all at the same indentation in a single spot. its an obvious net-win for readability and code maintainability. you are doing yourself no favors by not understanding/embracing it.
[deleted]
> now, we want to get away from that and go back to procedural?
AFAIK, we are all still programming browser UI with Javascript. It is an imperative language, about as stateful as you can get.
Now, if you managed to do your frontends with Haskell or Prolog, I'd be interested on learning how.
AFAIK, we are all still programming browser UI with Javascript. It is an imperative language, about as stateful as you can get.
Now, if you managed to do your frontends with Haskell or Prolog, I'd be interested on learning how.
LISP in the browser! You end up having to ship a large runtime with your app but it all transpiles to vanilla JS.
https://clojurescript.org/
https://clojurescript.org/
> I find $.ajax() much more simple than promise, await, async of native JS.
$.ajax() returns a promise. If you're calling .done() / .error() on it to handle the results -- well, that's exactly how you work with promises.
$.ajax() returns a promise. If you're calling .done() / .error() on it to handle the results -- well, that's exactly how you work with promises.
you think it's the same, but it's not even close to me
fetch().then((e)=>function()) is even close to being the same, then we're just not even talking the same language
.ajax({
success:function(result),
error:function(xhr),
}
fetch().then((e)=>function()) is even close to being the same, then we're just not even talking the same language
function ajax({url,success,error}) {
fetch(url).then(success, error)
}
Boom, same syntax if that's what you prefer.
J/K, the error status handling is not the same and the auto-deserialization isn't present. Not hard to add but it's harder to argue not to use a lib instead of copy-pasting 114 lines of niceties into each project.
Boom, same syntax if that's what you prefer.
J/K, the error status handling is not the same and the auto-deserialization isn't present. Not hard to add but it's harder to argue not to use a lib instead of copy-pasting 114 lines of niceties into each project.
> the auto-deserialization isn't present
You mean like response.json()?
You mean like response.json()?
You would just do:
const response = await fetch(...)
Bam, now you have the response without needing callbacks.
const response = await fetch(...)
Bam, now you have the response without needing callbacks.
The async/await design is absolute garbage and no one will ever convince me otherwise. `fetch` is a particularly egregious example: it has all kinds of insane random quirks that you need to memorize. For example, how do I handle an error there? What's the obvious way to handle it? Is response null or something? Well, not exactly, you need to check for:
response.ok; // false
response.status; // 404
I don't see how the design of the fetch API relates to async/await being badly designed, can you explain?
For example, `response` can't ever be null (even though it would be totally expected to if the request borks) due to the fact that under the hood, you're dealing with a promise (probably the most boneheaded implementation of asynchronous programming). async/await tries to put lipstick (syntactic sugar) on a pig (promises), and the fetch API, among many others, suffers for it.
I still don't know what specifically you'd want different. What would a better language construct be for an asynchronous operation that enabled a better Fetch API in your eyes?
Fetch returning null on a network error just seems the worst possible design, as you don't get any information about why it failed. Raising an error or rejecting the promise seems an appropriate choice for fetch. It failed to reach any server, so it cannot produce a Response object -- but it can raise an error with failure details.
Fetch returning null on a network error just seems the worst possible design, as you don't get any information about why it failed. Raising an error or rejecting the promise seems an appropriate choice for fetch. It failed to reach any server, so it cannot produce a Response object -- but it can raise an error with failure details.
There are many popular wrappers like axios that fix some of these things.
The fact that these kinds of wrappers exist instead of the most popular wrappers eventually ending up standardized in JS directly is mind-boggling.
We'll just stick with all-in-one jQuery, thanks
I'm genuinely curious. How does this difference affects you?
WebSockets are easier and faster.
Based on last year’s Stack survey, JQuery is the third popular.
https://survey.stackoverflow.co/2023/#section-most-popular-t...
https://survey.stackoverflow.co/2023/#section-most-popular-t...
It's funny, I just spent a bunch of time removing the last vestiges of react for a company, replacing it with HTMX, which imo is the spiritual successor to jQuery in some ways
> who is actively developing using jQuery?
Yea same, I am actively trying to get rid of jQuery, but my guess would be people get used to working with a tool and there just isn't enough desire or a business case to get rid of it as it would require a rewrite.
I would say that I doubt new projects are starting with jQuery but I know there are devs out there that know the jQuery way better than the vanilla javascript way to get things done.
Yea same, I am actively trying to get rid of jQuery, but my guess would be people get used to working with a tool and there just isn't enough desire or a business case to get rid of it as it would require a rewrite.
I would say that I doubt new projects are starting with jQuery but I know there are devs out there that know the jQuery way better than the vanilla javascript way to get things done.
But if you don’t want to get rid of it for business reasons, which I get, a major upgrade that changes a bunch of APIs and drops features would still require a lot of work.
And if you’re forced to leave 3.x over security or something (may happen in the future) then why not just move off then?
And if you’re forced to leave 3.x over security or something (may happen in the future) then why not just move off then?
I'd imagine upgrading from JQuery 3.x to 4.0 will be much less hassle than starting from essentially a blank page even if you were using some of the deprecated methods (even though you've previously been warned).
Yea, see the last half of my comment. There is a lot of legacy knowledge around how jQuery handles things and there are devs out there who just aren't interested in learning how to do it without jQuery.
For their customers and users, it makes no difference.
For their customers and users, it makes no difference.
Solo or small team devs who hate modern tooling. Good example is levelsio guy: https://twitter.com/levelsio/status/1750175827197567165
I'm also in that camp and still use jQuery.
My current SaaS is an extension that doesn't have much UI code https://www.snipcss.com, and my next SaaS will be a chatgpt powered web automation extension that has a good amount of UI. Both use jQuery.
Edit: I didn't say why I don't just use vanilla with querySelectorAll - majn reasons are I like how I can attach events (attaching to parent while targeting dynamically added subelements), chaining functions, and it's just less code than vanilla
I'm also in that camp and still use jQuery.
My current SaaS is an extension that doesn't have much UI code https://www.snipcss.com, and my next SaaS will be a chatgpt powered web automation extension that has a good amount of UI. Both use jQuery.
Edit: I didn't say why I don't just use vanilla with querySelectorAll - majn reasons are I like how I can attach events (attaching to parent while targeting dynamically added subelements), chaining functions, and it's just less code than vanilla
Django uses jQuery for its admin interface. (That is, jQuery is used by the Django maintainers to write the built-in admin interface.)
But I also know that a lot of the "low-cost" agencies are still using it. Probably because de the devs are used to using and don't want to bother to (re)learn things.
At least in my country, a lot of website are still using it (and very old, outdated versions at that).
But I also know that a lot of the "low-cost" agencies are still using it. Probably because de the devs are used to using and don't want to bother to (re)learn things.
At least in my country, a lot of website are still using it (and very old, outdated versions at that).
[deleted]
The DOM API now solves a lot of the issues jQuery solved 15 years ago, but often in very different ways. I don't think it's better; a lot of the APIs are awkwardly designed IMO. The big upshot is that it's built-in, but that's it, and with a very small jQuery library you get a nicer API. Sometimes the extra dependency is best avoided, but often it doesn't matter.
So, whenever reasonable, I prefer to just add jQuery. Maybe there's something better, but the differences/improvements of what I've seen doesn't seem that great and jQuery works, so that's the point? I guess the younger kids never used it, but it's easy enough to pick up if you know standard JS.
So, whenever reasonable, I prefer to just add jQuery. Maybe there's something better, but the differences/improvements of what I've seen doesn't seem that great and jQuery works, so that's the point? I guess the younger kids never used it, but it's easy enough to pick up if you know standard JS.
There are plenty of legacy web projects still using jQuery that nobody has been able to replace.
Off the top of my head I'm thinking of complex boring stuff like WCAG-compliant carousels or whatever. The kind of libraries people tend to reach for because marketing wanted them, but are otherwise ignored.
Off the top of my head I'm thinking of complex boring stuff like WCAG-compliant carousels or whatever. The kind of libraries people tend to reach for because marketing wanted them, but are otherwise ignored.
jQuery is still excellent if you are creating websites (not web apps) with minimal JavaScript.
I am using it when I need AJAX + Datatables for quick, but not dirty pages showing data in different ways that takes minutes to set up. Actually my projects are native JS for most and jQuery for that specific combination above. These are not public or commercial apps, just internal use for my department. I am not even a developer by role, but I build stuff when needed and time allows it.
I'm guessing most active development which people are actually consuming. Already mentioned is Wordpress, which is most of the web. There's probably tons of front-ends using old Bootstrap which also came with Jquery.
Greenfield projects might not be using Jquery, but is anyone actually using those? ;)
Greenfield projects might not be using Jquery, but is anyone actually using those? ;)
I wouldn't exclude the possibility of new developers that found some stackoverflow answer, or another, which suggests jQuery as the solution.
Awesome. My problem is I've been waiting for 4.0 soooo long I ended up making my own jQuery with some key differences:
That said, it's fantastic to see 4.0 here, and I'll certainly be upgrading my many sites that use it!
* Animations, tweens, timelines use pure CSS, instead of jQuery's custom system.
* Use one element or lists transparently.
* Inline <script> Locality of Behavior. No more inventing unique "one time" names.
* Vanilla first. Zero dependencies. 1 file. Under 340 lines.
That said, it's fantastic to see 4.0 here, and I'll certainly be upgrading my many sites that use it!
I've always thought there should be a modern, lightweight jQuery alternative like this. Well done! I love the syntax and have been implementing something similar (although with inline events and more than just the standard array methods). [0]
Do you have an article/screencast on how the locality of behavior is implemented in both surreal and its companion project css-scope-inline? I'd love to understand it so I can maintain it longterm and add it to my own projects.
I'd love to talk with you about your philosophy of the web. I think we could sync up about some things!
[0] https://hyperspace.so/All.js.png
Do you have an article/screencast on how the locality of behavior is implemented in both surreal and its companion project css-scope-inline? I'd love to understand it so I can maintain it longterm and add it to my own projects.
I'd love to talk with you about your philosophy of the web. I think we could sync up about some things!
[0] https://hyperspace.so/All.js.png
> I've always thought there should be a modern, lightweight jQuery alternative like this.
Have you heard of Zepto? https://zeptojs.com
Have you heard of Zepto? https://zeptojs.com
Yes, thank you! Zepto is great and it's nice it's jQuery compatible. I've used it before and liked it.
However, I guess I was thinking something a bit more modern -- adding more advanced functionality than what jQuery has. Like more array methods for elements (e.g. `pluck` elements based on property values), reactive data stores/templating, a mutation observer helper.
However, I guess I was thinking something a bit more modern -- adding more advanced functionality than what jQuery has. Like more array methods for elements (e.g. `pluck` elements based on property values), reactive data stores/templating, a mutation observer helper.
What do you mean by `pluck`? Is it like `array.map(i => i[key])`?
This throws me back to my junior days (2008~) where i had a heated discussion with my technical lead, to add jQuery to a project.
His argument was that the size of minified library(40kb) would add too much overhead to the loading time of the page.
He then, promptly spent a full week trying to code an ajax call and testing its support on different browsers and ultimately failed to make it work on Internet explorer 5.
jQuery solves many headaches back then, and yes he finally added the library to the project.
His argument was that the size of minified library(40kb) would add too much overhead to the loading time of the page.
He then, promptly spent a full week trying to code an ajax call and testing its support on different browsers and ultimately failed to make it work on Internet explorer 5.
jQuery solves many headaches back then, and yes he finally added the library to the project.
With browsers having much better support with DOM selection, why would anyone be using jQuery in 2024? Not trying to throw shade, I actually think it's cool that it's still being worked on. But I'm confused as to what the use case is.
There's a bunch of pretty convenient selectors that are not supported by document.querySelector(), such as :selected, :checked and a bunch of others (I forgot which exactly, but I've run in to it a few times).
In general the DOM API offends pretty much every single of my sensibilities on how to design good APIs. I also have some gripes with the jQuery API, but it's a lot better. jQuery just reads and writes so much more fluently.
In general the DOM API offends pretty much every single of my sensibilities on how to design good APIs. I also have some gripes with the jQuery API, but it's a lot better. jQuery just reads and writes so much more fluently.
:checked is standard CSS, and old.
:contains(text) is useful.
`:visible` and `:hidden` are really cool
In my opinion selecting something based on it's layout is oftentimes a dangerous pattern, you are basically tying the UI layout with the logic. People can overuse these cool selectors. I've personally worked on a website where the frontend part was a spaghetti mess with the half of the source code occupied by selector names. Some files have over 5000 lines of code. It would be far less pain to maintain and implement features if the website used some framework like angular.
Legacy projects? I maintain an old .NET web app that's ~15 years old and runs on jQuery. While the dream of refactoring or rewriting the entire thing using something more modern (like Web Components) is nice we're never gonna do it.
If I had to guess, a convenient API and a massive ecosystem.
I love it for admin pages.
If only 20 internals are ever going to see it, jquery is as light as can be, can be loaded right from a CDN, needs no kind of transpilation and handles basically all you need.
If only 20 internals are ever going to see it, jquery is as light as can be, can be loaded right from a CDN, needs no kind of transpilation and handles basically all you need.
> admin pages
> CDN
There’s a sysadmin just got called in for a security incident. Best to include it as a vendor library.
> CDN
There’s a sysadmin just got called in for a security incident. Best to include it as a vendor library.
FWIW we built our entire low code platform drag and drop editor with jquery. This includes editor, all controls (read Ui components) and needlessly to say that even the code that it ends up generating is pure play jquery. But the execs at big corps often question our sales engineering for why not react/angular/ etc.
So I am super glad to read that jquery continues to be so relevant even now. And am glad my cofounder and CTO always continued to back this rather than looked at moving the stack.
So I am super glad to read that jquery continues to be so relevant even now. And am glad my cofounder and CTO always continued to back this rather than looked at moving the stack.
I remember when jQuery was first released. To convince my coworkers to use it, I held an internal presentation called "Don't Fear the $," where I walked through the advantages it provided.
I remember jQuery from it's heyday when we used it as a replacement for Mootools. Since many people are going from React to HTMX, maybe we've made a full circle and we'll see web using just plain jQuery as well?
I came up in a similar era, I don’t think back fondly on those messes. Doing a modern app with accessibility, mobile support, real time updates, visualizations, and maybe a few PWA features with just jQuery sounds incredibly unpleasant.
I’m waiting for the HTMX hype train to meet reality too. Programming your app in pseudo attributes with a DSL is going to wear thin quickly.
I’m waiting for the HTMX hype train to meet reality too. Programming your app in pseudo attributes with a DSL is going to wear thin quickly.
I think that many websites even nowadays don't need all that jazz and many would improve if less JavaScript was on them. How many times have you loaded a website only to watch a couple of JavaScript "spinners" for everything to load only to click somewhere and everything started again? MS Azure management is one of such sites.
SPA with real time updates, complex layouts to be mobile-friendly, real-time updates of many components, endless scrolling and PWA features would be a total PITA. Yes, I don't disagree.
The vast majority of web apps I have seen so far don't need to be like that.
SPA with real time updates, complex layouts to be mobile-friendly, real-time updates of many components, endless scrolling and PWA features would be a total PITA. Yes, I don't disagree.
The vast majority of web apps I have seen so far don't need to be like that.
HTMX makes me think of Mootools: small, very specialized js library.
HTMX is like $().load()
"many" might be a stretch
Oh I loved jQuery.
Anybody remembers DataTables https://datatables.net or X-editable https://vitalets.github.io/x-editable/ ?
Anybody remembers DataTables https://datatables.net or X-editable https://vitalets.github.io/x-editable/ ?
I loved jQuery. Still great, but browser APIs have improved.
Now I mainly use AJQuery: https://github.com/coolaj86/ajquery.js/blob/main/ajquery.js
Now I mainly use AJQuery: https://github.com/coolaj86/ajquery.js/blob/main/ajquery.js
Just in case folks aren't familiar, this site breaks down jQuery features into web standard code:
https://youmightnotneedjquery.com/
I learned jQuery before i learned javascript proper over a decade ago. I didn’t even really understand what i was doing was considered programming. although i’ve not touched jquery in many years, i now have a great livelihood doing something i love. Long may they live.
Bring yayQuery back. The people demand it.
I remember building web apps in the days before jQuery, it was a mess. The DOM APIs were full of quirks, and all the libraries that predated jQuery had their own issues.
These days, we have better options for building complex web apps, including much-improved native APIs. I don't think I've started a new project using jQuery in 10 years. But for maintainin a lightweight website that just needs a little bit of interaction or pizzazz, I still think jQuery is perfectly fine.
These days, we have better options for building complex web apps, including much-improved native APIs. I don't think I've started a new project using jQuery in 10 years. But for maintainin a lightweight website that just needs a little bit of interaction or pizzazz, I still think jQuery is perfectly fine.
Especially the events! Those were browser-specific nightmares
Today it's not nearly as bad as it was before. I personally have very few reasons to use jQuery. Maybe it's somewhat shorter code and supports some cool pseudoselectors (IMHO, they are often bad patterns) but for me it's often easier to understand and debug a code using vanilla JS. For example, sometimes I have struggled to find the exact event listener callback by using dev tools because when you use nested click events because the code passes throw a lot of jQuery code before reaching the actual event listener.
A lot of what jQuery was created to do is now baked into the browser. CSS selectors, proper ajax, animation, etc.
I built a small convenience library around fetch to make it super easy to use ajax like in jQuery. Also built a small utility library around ES6 methods that recreate jQuery methods. It doesn't take much to get back the convenience of jQuery but still use all the new tools.
I love jQuery and used it for years. But there are better tools now.
I built a small convenience library around fetch to make it super easy to use ajax like in jQuery. Also built a small utility library around ES6 methods that recreate jQuery methods. It doesn't take much to get back the convenience of jQuery but still use all the new tools.
I love jQuery and used it for years. But there are better tools now.
Jquery made it to version 4 beta and there's a version 5 in the future. it looks like there's a big enough market for JQuery.
For the functions that are being removed, is there a list of the native replacements. eg $.isNumeric() == parseFloat() ?
A guide would be nice but you can always look at the jQuery implementations. isNumeric:
https://github.com/jquery/jquery/blob/bf48c21d225c31f0f9b544...
https://github.com/jquery/jquery/blob/bf48c21d225c31f0f9b544...
Thanks. That seems useful to keep in jQuery even though its only one line of code. So everyone doesn't have to copy and paste that non-obvious function.
I like Vue's reactive nature the best (specifically `v-if`, `v-for`), but jQuery was the one that got me over the hump before I actually knew Javascript.
And I encourage most projects that use a lot of jQuery to consider using jQuery's CDN version as there is like a 50%+ chance the person already has it cached on their system.
And I encourage most projects that use a lot of jQuery to consider using jQuery's CDN version as there is like a 50%+ chance the person already has it cached on their system.
This hasn't been the case for about four years. Since you can use cache status to track people, resources are now cached per hostname requesting as well.
https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
This feels like it is still pretty good when you are on a common host like github pages.
Doesn’t work anymore :(
https://news.ycombinator.com/item?id=24894135
https://news.ycombinator.com/item?id=24894135
Wow! I'm embarrassed I didn't know this since 2020. Too bad we can't allow certain super popular libraries of whose project maintainers we trust to still be cached across domains.
[deleted]
Time to send letters to the core js standards team to ask JR for permission (plus giving him a briefcase and a deus ex machina ;)) to bring the full jQuery treatment into core JS. In order to replace the cumbersome JS things with jQuery. Why always complicate things...
Worst part of jQuery is actually upgrading it to a new version, because the api design that made jQuery powerful is also what makes it quite difficult figure out if you broke anything.
Why worry when you can easily load both versions with jQuery.noConflict() !!!
Or you can just load one on top of the other. It will be ok
Or you can just load one on top of the other. It will be ok
Loading jQuery twice is a band aid solution.
However the jQuery 4 announcement page linked to this jQuery migration plugin that I was unaware of. Perhaps it can help in some old projects.
https://github.com/jquery/jquery-migrate
However the jQuery 4 announcement page linked to this jQuery migration plugin that I was unaware of. Perhaps it can help in some old projects.
https://github.com/jquery/jquery-migrate
I was really really joking
Nothing to add. Just happy to see jQuery is still around.
It's easy to forgot how widely used (depended on, rather?) it still is.
Always depressed when I saw some new JS library promote
"No jQuery" is one of its main features
"No jQuery" is one of its main features
I still use it as my low level html operations lib in my framework. Its still super handy. And size wise small.
I'll still take jQuery over raw JavaScript. Much easier, more efficient, more intuitive.
If most of the web didn't have a huge jQuery dependancy, we would have mostly moved on years ago.
I thought so too before reading these comments. I'm surprised how much people think jQuery still provides everything you need for a modern webapp. I have to step back and realize that my world has been working on millions+ LOC apps with hundreds of simultaneously committing devs, vs a lot of jQuery devs committing to personal-sized projects or blog-like web pages. Totally different solutions for different problems. I'd still pick vanilla es6+ vs jQuery for smaller stuff, but I get why some might not.
Most elegant API for Javascript, can it become part of Javascript API directly one day?
I feel like most of Jquery has been re implemented as browser api's anyway.
I still think that MooTools was better.
Another day another JavaScript framework! I'm so tired of all this churn in frontend. /s
In job postings for FE developers, I usually put in this line:
“A healthy disdain for jQuery”
This changes nothing.
“A healthy disdain for jQuery”
This changes nothing.
The filter works both ways.
When I see too much emotion in engineering job posts I take it as a sign that the team is more likely to be cult driven and less likely to reasonably discuss tools in terms of trade-offs.
When I see too much emotion in engineering job posts I take it as a sign that the team is more likely to be cult driven and less likely to reasonably discuss tools in terms of trade-offs.
Fair. In reality it usually leads to some good questions on the nature of frameworks.
jQuery has mostly been replaced by new browser apis. It was a great library that brought the web forward. It will still be around the web for decades to come. If you're updating to jQuery 4. Why not try switching to native js.
https://youmightnotneedjquery.com/
https://youmightnotneedjquery.com/
I was evaluating a SaaS solution just yesterday, and in one of their examples on Github they used jQuery as the primary frontend for the project, with extensive usage.
I passed on the company
I passed on the company
Why? What's wrong, if it works well?
There are things that work better.
Seems a weak reason for rejecting a solution and this is subjective.
I prefer native JS but something can be well designed in jQuery.
I prefer native JS but something can be well designed in jQuery.
Too bad for you. I'm glad for them they don't have to deal with you as a customer.
With SaaS, the front end might be the least important piece of the application.
Any advances to removing deprecated APIs or functions are great. jQuery will probably be around dominantly on the web for years to come.