Live data from Hacker News

jQuery v4.0 Beta

blog.jquery.com

241–250 of 404 posts

Re: jQuery v4.0 Beta

#241

Earlier quoted context omitted.

> you can have that with server-side rendering plus yes, we use PHP for this which is much simpler to grasp than JS-SSR

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.

Re: jQuery v4.0 Beta

#242

Earlier quoted context omitted.

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?

Re: jQuery v4.0 Beta

#243

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?

"many" might be a stretch

Re: jQuery v4.0 Beta

#244
post #162
post #77

In job postings for FE developers, I usually put in this line: “A healthy disdain for jQuery” This changes nothing.

A job pays you 10k a week for writing jQuery code, will you refuse it?

we all know that job does not exist

Re: jQuery v4.0 Beta

#245

Earlier quoted context omitted.

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

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

Re: jQuery v4.0 Beta

#246
post #2

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.

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.

Re: jQuery v4.0 Beta

#247
post #95

Earlier quoted context omitted.

[flagged]

Absolutely yes. jQuery selector engine was developed before the official Selector API, which ended up being almost exactly the same. Except for a few exceptions which John wasn't too sure about when they asked for feedback: https://johnresig.com/blog/thoughts-on-queryselectorall/

I don't know what you think that link shows (I don't know what John thought it showed, either—it's a classic "talking to one's own head, instead of who you're trying to communicate with" situation, and David Baron's confusion on the mailing list at the time is understandable).

To reiterate:

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

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

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

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

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

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

Re: jQuery v4.0 Beta

#248

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

Re: jQuery v4.0 Beta

#249

Earlier 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…

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.

Post reply on HN