For those of you who are curious what drives jQuery in 2024 and beyond, you need to remember that WordPress is still more than 1/3 of the web, and the majority of installations and so many plugins critically rely on jQuery. Yes, seriously. Any advances to removing deprecated APIs or functions are great. jQuery will probably be around dominantly on the web for years to come.
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 th…
jQuery v4.0 Beta
311–320 of 404 posts
Re: jQuery v4.0 Beta
#312Earlier quoted context omitted.
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?
Re: jQuery v4.0 Beta
#313This 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.…
Re: jQuery v4.0 Beta
#314Earlier quoted context omitted.
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…
[flagged]
---
Sigh. There are people who cannot program and fortunately for those people there is jQuery. Writing any kind of UI in vanilla JS is trivial and even more so with TypeScript. If that takes you a 160 hours to complete you are not the guy to be doing that work. I could pay my pest control guy to figure it out. Maybe it might take him 160 hours.
JQuery used to make sense back in the days of IE, especially before IE9, and your team was green. Even then most cross browser issues were in CSS, not JS. Those days are long gone.
Re: jQuery v4.0 Beta
#315Earlier quoted context omitted.
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 th…
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.
"Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes."
Re: jQuery v4.0 Beta
#316Earlier quoted context omitted.
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.
Re: jQuery v4.0 Beta
#317Earlier quoted context omitted.
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? Compo…
Re: jQuery v4.0 Beta
#318Earlier quoted context omitted.
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? Compo…
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 prod…
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.
Re: jQuery v4.0 Beta
#319Earlier quoted context omitted.
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 prod…
> 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?
Re: jQuery v4.0 Beta
#320Earlier quoted context omitted.
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. T…
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.
any website that has any sort of meaningful functionality and communication with a server is mostly likely using some sort of framework.