Live data from Hacker News

jQuery v4.0 Beta

blog.jquery.com

191–200 of 404 posts

Re: jQuery v4.0 Beta

#191
post #27

Earlier quoted context omitted.

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.

> 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

Re: jQuery v4.0 Beta

#192

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

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.

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.

Re: jQuery v4.0 Beta

#193

Earlier quoted context omitted.

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.

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.

This way of looking at separation of concerns helps: https://x.com/simonswiss/status/1664736786671869952

Re: jQuery v4.0 Beta

#194

Earlier quoted context omitted.

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

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)

Re: jQuery v4.0 Beta

#195
post #154

Earlier quoted context omitted.

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 Um, okay, I get it.…

There are many popular wrappers like axios that fix some of these things.

We'll just stick with all-in-one jQuery, thanks

Re: jQuery v4.0 Beta

#196
post #194

Earlier quoted context omitted.

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)

The DOM is a big in memory object but the DOM APIs are entirely functional. Functional is not the same as declarative.

Re: jQuery v4.0 Beta

#197

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

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.

Re: jQuery v4.0 Beta

#198

Earlier quoted context omitted.

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.

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.

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

Re: jQuery v4.0 Beta

#199

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

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

Re: jQuery v4.0 Beta

#200

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…

Yup, jQuery is indeed awesome!
Post reply on HN