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

341–350 of 404 posts

Re: jQuery v4.0 Beta

#341

Post by bmelton »

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.

Why do you have to wait?

It's fairly normal to run some version of `npm run serve` with a filesystem watcher that will hot-reload changes as they occur so that you can see changes every time you hit :w (or CMD+S or whatever saves a file on your filesystem)

Re: jQuery v4.0 Beta

#342

Post by gunapologist99 »

Macha wrote: post #294
krapp wrote: post #256

Earlier quoted context omitted.

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.

The problem jQuery was solving was to provide a usable abstraction over an inconsistent platform for core functionality like event handling and DOM manipulation. The point of the last decade and a half of standards work was to eliminate that problem, and it has at least moved it from "core web functionality" to more complicated areas like bluetooth, 3d rendering and audio, which jQuery's goals do not include handling…

That was part of the problem that jQuery was solving.

Another part was the abysmal API that Javascript (and mostly still today) offers to work with the DOM.

Re: jQuery v4.0 Beta

#343

Post by Zardoz84 »

Capricorn2481 wrote: post #64
rjbwork wrote: post #47

Earlier quoted context omitted.

>It's very hard to reason about DOM I don't mean to be overly snarky here, but as someone who's just totally out of their depth in modern web UI - is that why people like these frameworks? Because they're very easy to reason about? I've generally found them to be mountains and mountains of boilerplate and spaghetti, but I really do not have a wide base of experience to pull from on this topic.

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…

what I usually did, was using data-xxx attributes (and document these attributes and how works) to inject special functionality to html elements. I did this with jQuery, and now I do with vainilla JavaScript.

Re: jQuery v4.0 Beta

#344

Post by _rend »

austin-cheney wrote: post #265
troupo wrote: post #261

Earlier quoted context omitted.

You're making no sense. Functional programming is more than just "about functions". DOM APIs are the embodiment of 90s-era OOP. There's literally nothing functional about them. All [1] "functions" are methods defined on very specific objects. You can't even get a proper reference to them without binding them to specific object instances What exactly is functional about this? const newDiv = document.createElement("div…

> What exactly is functional about this? A series of function calls that each do something and each returns a value. > Okay, here's an easier question. What will happen here, and why? A function call that does something and returns a value, because in this language complex types are passed by reference.

> A series of function calls that each do something and each returns a value.

This is not what functional programming is. Functional programming is a completely different paradigm for writing code, and it _is_ declarative by definition. The Wikipedia definition is pretty decent:

    Functional programming is a programming paradigm where programs are constructed by applying and composing functions. It is a declarative programming paradigm in which function definitions are trees of expressions that map values to other values, rather than a sequence of imperative statements which update the running state of the program.
The "Comparison to imperative programming" section[1] offers a decent example of the paradigm, but DOM manipulation in JavaScript is pretty much as imperative as it gets. Having functions is necessary, but not sufficient, for functional programming.

[1]: https://en.wikipedia.org/wiki/Functional_programming#Compari...

Re: jQuery v4.0 Beta

#345

Post by mobilemidget »

sireat wrote: post #207
midasuni wrote: post #190

Earlier quoted context omitted.

Yesterday I wrote a custom page which dumped out a table for some investigation. I threw jquery and a tablesorter plug-in. Without JS you get the table, but with you can easily sort and filter. Took about 2 minutes to add the optional filter. The backend is bash of course.

For tables my favorite jQuery plug-in is: https://datatables.net/ Have a page with some tables? A few lines of jQuery and you have search sorting etc. It can be customized but defaults are fine. This is how abstractions and progressive enhancement should be done.

I personally prefer https://sortablejs.github.io/Sortable/ over datatables.net

Though both do what I typically need them to do, customising datatables.net takes me a bit more time though

Re: jQuery v4.0 Beta

#346

Post by mostlysimilar »

bradly wrote: post #293
austin-cheney wrote: post #185

Earlier quoted context omitted.

It’s all the same. The difference is not in the product but in the developer’s perception of the product. The code and the user don’t notice the difference, just the developer in the middle. There are those who can dynamically put text on screen and those who need just a little help to dynamically put text on screen.

> the user don’t notice the difference Users do notice the difference is large JS framework driven applications.

Yeah, they notice how slow and janky they are, and how often they're staring at empty gray boxes while things load.

Re: jQuery v4.0 Beta

#347

Post by docmars »

ecshafer wrote: post #23
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.

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…

Organizing a large jQuery project is absolute hell though. I'll take modern frameworks like Vue any day. The ease of shipping a full-fledged app that feels easy to create and maintain began with Vue (and Svelte).

React tries to achieve the same result, but if you don't use it perfectly right, you're in for hours and hours of headaches and non-solutions.

Re: jQuery v4.0 Beta

#348

Post by docmars »

anthonypasq wrote: post #320
heartbreak wrote: post #277

Earlier quoted context omitted.

How many React apps actually have an interface approaching the complexity of Figma or even Facebook? No one is arguing that complex web applications don’t benefit from React and friends. It’s completely overkill for most of the web.

why does everyone have this impression that people are using react to render a website that is 5 divs and some images, like where is this perception coming from? do you have any examples at all? any website that has any sort of meaningful functionality and communication with a server is mostly likely using some sort of framework.

Agreed. There is a _lot_ of naivety around how these frameworks are perceived, from people who have never used them, or who come from different programming backgrounds (i.e. not frontend). It's amusing.

Re: jQuery v4.0 Beta

#349

Post by docmars »

rjbwork wrote: post #47
bufferoverflow wrote: post #32

Earlier quoted context omitted.

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.

>It's very hard to reason about DOM I don't mean to be overly snarky here, but as someone who's just totally out of their depth in modern web UI - is that why people like these frameworks? Because they're very easy to reason about? I've generally found them to be mountains and mountains of boilerplate and spaghetti, but I really do not have a wide base of experience to pull from on this topic.

Creating a brand new Vue app using Vite as your build system (official) takes less than 2 minutes and you can immediately start using Vue by following its documentation and creating a well-organized web application with its friendly patterns and solutions to the most common pro-UX problems you could encounter in a web app.

Give it a shot, it's stupid-easy, and that's not downplaying anything either.

Re: jQuery v4.0 Beta

#350

Post by lakpan »

peebeebee wrote: post #334
lakpan wrote: post #260

Earlier quoted context omitted.

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

> Of course if you load a bunch of code beforehand your code will be marginally better. That's exactly the point though. We use jQuery because it has an incredible easy and consistent interface that makes writing for the web so much more enjoyable. Selectors, events, chaining,... are all just nicer to work with than the vanilla counterparts. Same goes for all libraries and frameworks. :) BTW: Your example is sending…

> Not all API's will understand this

Who’s talking about APIs? Most jQuery users I know just use jQuery to submit forms and load some JSON, both of which are covered by fetch without altering the headers manually.

What I’m saying is that it’s not fair to judge a tool for something you don’t have to do with it, namely sending JSON for everything. Fetch also supports native binary uploads, whereas most people base64 data when using $.ajax

> makes writing for the web so much more enjoyable

Writing? I agree. Actually making it work? No way. $('forn').hide() doesn’t work, but the browser will never tell you why (hint: wrong selector).

jQuery errors are often silent, and that’s good enough reason to abandon it.

Post reply on HN