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

251–260 of 404 posts

Re: jQuery v4.0 Beta

#251

Post by austin-cheney »

troupo wrote: post #224
austin-cheney wrote: post #196

Earlier quoted context omitted.

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

> DOM APIs are entirely functional. (Almost) none of the DOM APIs are functional. They are literally `object.methodCall()`

Yes, functional programming can have methods. Methods are functions. OOP is all about polyinstantiation and inheritance. Functional programming is all about functions and input/output, which is entirely what happens in this case. The only OOP here is the method assignment you don’t see: Element.prototype.getElementById = function () {};

Re: jQuery v4.0 Beta

#252

Post by preommr »

troupo wrote: post #191
IgorPartola wrote: post #30

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.

> 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

> That's not what vue templates are. It's three or four different templating DSLs in one.

The pattern is very obvious?

If array: (value, index)=>void

If object: (value, key, index)=>void

If it's an array, it's the call signature for the args of the forEach method, i.e. (value, index)=>void, but can be assigned a function that's just (value)=>void if index is unneeded. If it's an object, it's an extension of the same logic with (value, key, index).

It's not 4 dsls in one, anymore than jsx is a 1000 markups in one.

Re: jQuery v4.0 Beta

#253

Post by sanitycheck »

profmonocle wrote: post #164
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.

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…

The other problem with a "rewrite in a modern JS framework" is that when it's finally done it'll only be a few more years until it needs another "rewrite in a modern JS framework". And that's worse, because at least with JQuery it just stays the same whereas with anything in the NPM ecosystem using anything older than, say, 6 months is kind of a nightmare in terms of dependencies and tooling.

Not broke? Don't fix!

Re: jQuery v4.0 Beta

#254

Post by krapp »

ipaddr wrote: post #134
LamaOfRuin wrote: post #101

Earlier quoted context omitted.

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

Instead of needing to import leftpad you have the missing standard js lib

It isn't missing. Javascript was created to serve a specific purpose, which didn't include left-padding text in a terminal. Most language I'm aware of wouldn't have that in their standard lib.

If you want Javascript to act as a drop-in replacement for C++ or Java or some other general programming language (which Javascript was never intended to be) don't act as if needing to write libraries to cover that missing functionality is a problem with the language. You're using the wrong tool for the wrong job.

Re: jQuery v4.0 Beta

#255

Post by holoduke »

hnfong wrote: post #206
holoduke wrote: post #202

Earlier quoted context omitted.

You still need some kind of application framework. Jquery is just a low level utility. But higher level you need to maintain architecture. Specially in spa's

You don't "need" an application framework. People have been building websites (even SPAs) before the 2010s and they didn't "need" these frameworks. Given what we know today, I'll grant you that in some cases people would want to use a framework, but it's hardly a necessity unless the context provides more specific requirements.

Its can be convenient to have some kind of reusable conponents. Like listviews wtih certain functionality. Same for routing. Caching etc.

Re: jQuery v4.0 Beta

#256

Post by krapp »

admaiora wrote: post #238
p-e-w wrote: post #67

Earlier quoted context omitted.

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…

Yesterday I was checking HN from 10years±2weeks ago and guess what the top posts were... "Why you need jQuery" and "You might not need jQuery". I'm too young to know about those days but I guess not much has changed in relation to people's attitude towards jQuery.

What's changed is the billion dollar tech industry invested in convincing people that JQuery is a dead and obsolete technology.

For some reason, JQuery is the exception to the general rule of seeing a mature, battle-tested library as a sign of quality.

Re: jQuery v4.0 Beta

#257

Post by viraptor »

wouldbecouldbe wrote: post #249
pzmarzly wrote: post #241

Earlier quoted context omitted.

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

You normally want to see things locally as you develop them. Vercel is cool and all, but doing a git push and waiting for the build every time you want a refresh? Nah, that's not viable. And almost everything mentioned above for deployments applies to your own dev machine as well.

Re: jQuery v4.0 Beta

#258

Post by mysteryos »

This throws me back to my junior days (2008~) where i had a heated discussion with my technical lead, to add jQuery to a project.

His argument was that the size of minified library(40kb) would add too much overhead to the loading time of the page.

He then, promptly spent a full week trying to code an ajax call and testing its support on different browsers and ultimately failed to make it work on Internet explorer 5.

jQuery solves many headaches back then, and yes he finally added the library to the project.

Re: jQuery v4.0 Beta

#259

Post by wouldbecouldbe »

viraptor wrote: post #257
wouldbecouldbe wrote: post #249

Earlier quoted context omitted.

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

You normally want to see things locally as you develop them. Vercel is cool and all, but doing a git push and waiting for the build every time you want a refresh? Nah, that's not viable. And almost everything mentioned above for deployments applies to your own dev machine as well.

Okay then your comment is weird, windows & mac dont have distribution with node versions lower then LTS. It can be an issue on ubuntu/linux having an outdated registry. But nextjs clearly states minimum node version in their docs: https://nextjs.org/docs/getting-started/installation

And how to install every version you want NVM, that's on the user if it didn't work. That's not something different then can happen with PHP or other tools as mysql in the LAMP setup.

Re: jQuery v4.0 Beta

#260

Post by lakpan »

peebeebee wrote: post #223
umvi wrote: post #88

Earlier quoted context omitted.

Async await fetch lets you flatten your nested callback functions into simple procedural programming. It makes everything much easier to reason about, no more closures and such.

JQUERY: await $.post({ url: '/my/url', data: data }).then(() => {}); VANILLA: await fetch('/my/url', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(data) }).then(() => {}); I know which one I still prefer.

You dropped about 250000 characters from the first example.

Of course if you load a bunch of code beforehand your code will be marginally better.

The fact is that you probably don’t need to send JSON anymore because fetch accepts the whole form as an object:

  await fetch('/my/url', {
   method: 'POST',
   body: new FormData(form)
  })
Post reply on HN