Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

jQuery v4.0 Beta

blog.jquery.com

Post reply on HN
Print view View original

151–160 of 404 posts

Re: jQuery v4.0 Beta

#151

Post by PrimeMcFly »

tambourine_man wrote: post #146
technojunkie wrote: post #18

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.

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

Re: jQuery v4.0 Beta

#153

Post by jkingsman »

andrew_ wrote: post #63
kentf wrote: post #43

Earlier quoted context omitted.

Don't forget Prototype ( http://prototypejs.org/ )

And Dojo! https://dojotoolkit.org/

Oh man, back in the day I got my first exposure to big, enterprise web apps in the form of an undergrad internship on a control panel for a major database that ran on Dojo. Every time I could scurry back to Python to work on a backend feature, I breathed a sigh of relief. It put me off frontend for a long time until I arrived at a shop that taught better, and not being taught was definitely a big part of my fear of Dojo/frontend dev, but Dojo is also BIG and you can build some really unwieldy systems with it. You can do that with any framework, sure, but in the heyday of Dojo, it was a lot of opaque logic that wasn't as well doc'd out or understandable just by reading as today.

Dojo put the fear (respectful) and fear (scared) of big, enterprise frontend development in me.

Re: jQuery v4.0 Beta

#154

Post by dvt »

umvi wrote: post #92
dylan604 wrote: post #82

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

You would just do: const response = await fetch(...) Bam, now you have the response without needing callbacks.

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. So to get the text content of the response, I just need to do response.text, right? No, you dummy, that's a function! You need to call response.text(), duh. It's so funny how an entire generation of front-end engineers just accepted this slop as acceptable API design. You can't fix the past, but thank God for (oh the irony) Microsoft and TypeScript.

Re: jQuery v4.0 Beta

#155

Post by jazzcrab »

wkirby wrote: 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…

> commenters on HN who seem to think jQuery is just a DOM selection library

proceeds to name selection and native functions

Re: jQuery v4.0 Beta

#156

Post by lostemptations5 »

technojunkie wrote: post #18

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.

jQuery is just way cooler than the comparatively build in (and sometimes obtuse) web standard replacements for it.

Re: jQuery v4.0 Beta

#157

Post by todotask »

technojunkie wrote: post #18

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.

Now we have React, React DOM and jQuery in WordPress.

Re: jQuery v4.0 Beta

#158

Post by spiderice »

erhaetherth wrote: post #109
treflop wrote: post #90

Earlier quoted context omitted.

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.

I haven’t used jquery in 10 years or so, but I’m pretty sure this isn’t what you would do. You would just hide or unhide the inputs with jquery.

Re: jQuery v4.0 Beta

#159

Post by radium3d »

emseetech wrote: post #72
technojunkie wrote: post #18

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.

Wordpress devs are the plumbers of the tech industry. It’s not glamorous work but there’s a ton of money in it because so many people need them. If I ever decide to retire from latest and greatest hype cycle big tech startup world, I’ll go build Wordpress sites for honest coin and wrap up every day by 3pm.

heh, try 11-12pm. o.O

Re: jQuery v4.0 Beta

#160

Post by noduerme »

technojunkie wrote: post #18

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.

I was going to post on HN not long ago and didn't, about how I still can't find a great event chain handling / bubbling model that lets me use both DOM members and abstract class instances to trigger interchangeable events. I've built my own event dispatchers here and there, but jQuery just does everything right. Although event handling is almost the only thing I still use jQuery for, it's so useful that I still include it in almost every client-side project. The reason I was going to post was to ask if anyone knew of a slim library that could both $(window).trigger('click') and $(myClassInstance).trigger('myCustomEvent',{data}) with the same API for listening to either one asynchronously. With the rise of fetch() and css selectors I could probably do without the rest of jQuery at this point. But why reinvent the wheel? And before anyone tells me that having class instances dispatch events is a code smell... it's absolutely necessary if you want to build responsive frameworks from scratch.

[Just for example, my base component class listens for a particular custom resize event dispatched from the screen that contains it, which only dispatches to components on screens that don't scroll and need to reformat their contents. The screen class listens for window.resize but only dispatches if it's in trouble with the layout. Putting individual DOM resize listeners to window on each and every component would be insane.]

Post reply on HN