Live data from Hacker News

jQuery v4.0 Beta

blog.jquery.com

101–110 of 404 posts

Re: jQuery v4.0 Beta

#101
post #67

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.

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…

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

Just like leftpad.

Re: jQuery v4.0 Beta

#102
post #41

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…

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

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

Re: jQuery v4.0 Beta

#104

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…

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?

Re: jQuery v4.0 Beta

#105

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…

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.

Re: jQuery v4.0 Beta

#107
post #41

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…

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

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.

Re: jQuery v4.0 Beta

#109
post #90

Earlier quoted context omitted.

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

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.

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.

Re: jQuery v4.0 Beta

#110
post #98
post #77

In job postings for FE developers, I usually put in this line: “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.

Fair. In reality it usually leads to some good questions on the nature of frameworks.
Post reply on HN