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

111–120 of 404 posts

Re: jQuery v4.0 Beta

#111

Post by erhaetherth »

genocidicbunny wrote: post #65
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…

I don't think it's that surprising given the demographics of HN posters that I've observed. Many will immediately reach for the big JS framework du jour when they need anything more than a little DOM selection stuff, because that's what they've always done.

There's 2 types of web pages. Websites and web apps. If you're building a web app, you're going to want a framework that isn't going to fall apart the second things start getting complicated. If you're making a little marketing website, sure, sprinkle some jQuery on there and call it a day. Probably better for performance and SEO unless you want to spend 10x as long micro-optimizing your SSR. Point is, there's different use-cases.

Re: jQuery v4.0 Beta

#112

Post by tipiirai »

cxr wrote: post #95
tipiirai wrote: post #80

Earlier quoted context omitted.

It's the jQuery API design. I often find myself creating functions like this one: export function $(query, root=document) { ... } jQuery acted as a role model for standard web committees. The argument for querySelector / querySelectorAll calls is literally mimicked from John Resig's groundbreaking API design.

[flagged]

Absolutely yes.

jQuery selector engine was developed before the official Selector API, which ended up being almost exactly the same. Except for a few exceptions which John wasn't too sure about when they asked for feedback:

https://johnresig.com/blog/thoughts-on-queryselectorall/

Re: jQuery v4.0 Beta

#113

Post by kmoser »

ActualHacker wrote: post #22

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

With SaaS, the front end might be the least important piece of the application.

Re: jQuery v4.0 Beta

#114

Post by erhaetherth »

dylan604 wrote: post #82
duskwuff wrote: post #59

Earlier quoted context omitted.

> I find $.ajax() much more simple than promise, await, async of native JS. $.ajax() returns a promise. If you're calling .done() / .error() on it to handle the results -- well, that's exactly how you work with promises.

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.

Re: jQuery v4.0 Beta

#115

Post by dylan604 »

umvi wrote: post #88
dylan604 wrote: post #52

Earlier quoted context omitted.

I mean, duh? Of course doing something that I've done for a long time is going to be more simple to me than me fumbling/stumbling through something I haven't done much. What new insight are you providing me here?

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.

see, this is where i'm not cool with this newness.

i've spent years getting away from procedural, and switching to functions, classes/methods. now, we want to get away from that and go back to procedural?

that's all fine and dandy, but you're trying to have a new trick conversation with an old dog that just doesn't care. you're bringing some sort of logic to a conversation where it's not needed. it works for me. i don't get paid to make UI apps or write heavy code nonsense with server side JS. i use a proper back end language. JS can stay in the browser and manipulate the DOM thank you very much. i get paid to make heavy processing code that sometimes is helpful to have UI dashboards.

i can whip up a JQuery front end faster for my needs than most can even figure out what NPM librar[y|ies] they need to use

Re: jQuery v4.0 Beta

#116

Post by genocidicbunny »

erhaetherth wrote: post #111
genocidicbunny wrote: post #65

Earlier quoted context omitted.

I don't think it's that surprising given the demographics of HN posters that I've observed. Many will immediately reach for the big JS framework du jour when they need anything more than a little DOM selection stuff, because that's what they've always done.

There's 2 types of web pages. Websites and web apps. If you're building a web app, you're going to want a framework that isn't going to fall apart the second things start getting complicated. If you're making a little marketing website, sure, sprinkle some jQuery on there and call it a day. Probably better for performance and SEO unless you want to spend 10x as long micro-optimizing your SSR. Point is, there's differ…

Okay, what part of what I said are you trying to refute or educate me on?

There's a large proportion of posters on HN who spend their days building web apps. They are very likely to stick to using what they know, even when building web sites.

If you spend your days working as a welder, and suddenly need to build a box for some reason, you're probably not going to be breaking out the fine wood joinery tools. You're probably going to take some sheet steel and weld up a box and move on to whatever else you have to do.

It's not a problem, it's not a fault, it just how things are.

Re: jQuery v4.0 Beta

#117

Post by [deleted] »

treflop wrote: post #90
Capricorn2481 wrote: post #64

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.

[deleted]

Re: jQuery v4.0 Beta

#118

Post by colordrops »

erhaetherth wrote: post #104
ecshafer wrote: post #23

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…

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?

Yes, there isn't much reason to use jQuery these days other than keeping with the idioms of a legacy system.

Re: jQuery v4.0 Beta

#119

Post by pier25 »

erhaetherth wrote: post #104
ecshafer wrote: post #23

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…

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?

One line of jQuery can replace many lines of vanilla js.
Post reply on HN