[tipiirai]

Second to that: jQuery is awesome.

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

[p-e-w]

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

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

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

[Finbarr]

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

  JQUERY:
  $(el).toggle();

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

Gotta love that "modern" triple attribute repetition.

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

[piaste]

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

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

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

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

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

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

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

[extra88]

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

[mschuster91]

> Gotta love that "modern" triple attribute repetition.

You can golf it down a bit:

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

[OJFord]

Surely

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

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

[anakaine]

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

[Finbarr]

Of course. Because that's infinitely better than:

  $(el).toggle();

[1123581321]

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

[frereubu]

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

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

[fwip]

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

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

[tipiirai]

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

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

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

[admaiora]

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

[krapp]

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

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

[Macha]

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

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

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

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

[collyw]

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

[gunapologist99]

That was part of the problem that jQuery was solving.

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

[marcosdumay]

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

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

[jampekka]

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

[LamaOfRuin]

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

Just like leftpad.

[ipaddr]

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

[krapp]

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

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

[selcuka]

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

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

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

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

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

[chipotle_coyote]

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

[Macha]

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.

[midasuni]

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

[sireat]

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

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

This is how abstractions and progressive enhancement should be done.

[midasuni]

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

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

[anakaine]

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

[ryanisnan]

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

[mobilemidget]

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

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

[GrumpyNl]

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

[nextaccountic]

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

[kkarpkkarp]

> you can have that with server-side rendering plus

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

[geek_at]

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

[flemhans]

watch -n 1 git pull

[vmfunction]

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

[wouldbecouldbe]

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

[pzmarzly]

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

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

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

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

[wouldbecouldbe]

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

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

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

[hu3]

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

[viraptor]

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.

[KronisLV]

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.

[Aeolun]

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

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

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

[Scotrix]

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.

[jddj]

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

[Capricorn2481]

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

[rfl890]

Express

[tipiirai]

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

[teaearlgraycold]

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

[postepowanieadm]

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

[PrimeMcFly]

> JavaScript is a must, not optional.

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

But it's seldom required.

[manuelmoreale]

Just want to say I appreciate you for doing that.

[PrimeMcFly]

Thanks :)

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

[manuelmoreale]

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