Live data from Hacker News

jQuery v4.0 Beta

blog.jquery.com

161–170 of 404 posts

Re: jQuery v4.0 Beta

#161

Earlier quoted context omitted.

you think it's the same, but it's not even close to me .ajax({ success:function(result), error:function(xhr), } vs fetch().then((e)=>function()) is even close to being the same, then we're just not even talking the same language

function ajax({url,success,error}) { fetch(url).then(success, error) } Boom, same syntax if that's what you prefer. J/K, the error status handling is not the same and the auto-deserialization isn't present. Not hard to add but it's harder to argue not to use a lib instead of copy-pasting 114 lines of niceties into each project.

> the auto-deserialization isn't present

You mean like response.json()?

Re: jQuery v4.0 Beta

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

Re: jQuery v4.0 Beta

#163

Earlier quoted context omitted.

>…WordPress is still more than 1/3 of the web… Why still? WordPress, like jQuery, is awesome. It's an incredibly powerful and easy open source CMS. I hope it takes more of the Web. And if you're gonna defend the decentralization of the Web (and I do), it's hard to find a better argument than “just buy a domain and install WordPress”.

It's a buggy insecure mess. No one should be advocating for wordpress.

I’d like to know the name of this alternative that’s as feature-rich and yet bullet-proof while still being open source

Re: jQuery v4.0 Beta

#164

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.

It's not just WordPress. A company I used to work for has tens of thousands of lines of jQuery code powering their enterprise SAAS product.

A rewrite in a modern JS framework is just not going to happen unless it becomes absolutely necessary. Much of this code is extremely client-specific stuff written over a decade ago. The argument that using a modern framework helps recruiting doesn't work - the company only pays $75-90k for frontend engineers and has very low turnover, most current engineers have been there 5+ years. And most importantly, their current stack works just fine; they have a bunch of long-time clients who are happy.

A good chunk of software engineering happens in "boring" businesses like this in cities with a much lower cost-of-living than the big tech industry hubs like the Bay Area / Seattle / etc.

Re: jQuery v4.0 Beta

#165

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 remains the best JSONP library. It can get data even when other libraries are blocked.

Re: jQuery v4.0 Beta

#166

If most of the web didn't have a huge jQuery dependancy, we would have mostly moved on years ago.

I thought so too before reading these comments. I'm surprised how much people think jQuery still provides everything you need for a modern webapp. I have to step back and realize that my world has been working on millions+ LOC apps with hundreds of simultaneously committing devs, vs a lot of jQuery devs committing to personal-sized projects or blog-like web pages. Totally different solutions for different problems. I'd still pick vanilla es6+ vs jQuery for smaller stuff, but I get why some might not.

Re: jQuery v4.0 Beta

#167
post #105

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…

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

"Etiquette" implies there is some civilizing force. A system that allows us to coexist in peaceful, accessible sanity.

Someone said of a profitable app/site I created with vanilla JS, "But this is looks like it is just a Bootstrap site"

At this point, functionality be damned, customers expect a loading spinner. The norm is something that doesn't load on the first request. Sites don't paint the screen until 10 seconds later, because they are avoiding repaints. Maybe 10-20mb of JS is included in the typical app in this niche. Many totally fail on Firefox. Ambiguous user facing errors on a black screen, "An application client side error occurred" are par for the course.

Re: jQuery v4.0 Beta

#168

I was evaluating a SaaS solution just yesterday, and in one of their examples on Github they used jQuery as the primary frontend for the project, with extensive usage. I passed on the company

Too bad for you. I'm glad for them they don't have to deal with you as a customer.

Re: jQuery v4.0 Beta

#169

Earlier quoted context omitted.

It's good for quick things and prototyping cause you can always swap out those calls with native later. It's API is generally easier to remember/less typing that most native equivalents. You can also use its API serverside via Cheerio to do parsing & manipulation of html without a dom. edit: also its way more lightweight than React/Vue/Svelte i don't necessarily disagree you shouldn't reach for jQuery if you have a d…

Is it really way more lightweight than Svelte? Svelte has more tooling (of course) but it ships no runtime and only sends the user the JS they actually need to interact with your page.

Well, if you're talking SvelteKit then it requires a build step so yes, jQuery is way more lightweight.

jQuery is also pure JS whereas Svelte is Typescript so it may be more difficult to debug/hack if your primarily JS coder.

Re: jQuery v4.0 Beta

#170
post #138

Worst part of jQuery is actually upgrading it to a new version, because the api design that made jQuery powerful is also what makes it quite difficult figure out if you broke anything.

Why worry when you can easily load both versions with jQuery.noConflict() !!!

Or you can just load one on top of the other. It will be ok

Post reply on HN