Live data from Hacker News

jQuery 3.6.0

blog.jquery.com

211–220 of 292 posts

Re: jQuery 3.6.0

#211

jQuery has the kindest, most warm hearted, whimsical release notes. During the pandemic last year: > We hope you’re staying healthy and safe while so many of us are stuck at home. With a virus ravaging the planet, we realize that jQuery may not be a high priority for you or the sites you manage. When you do have a moment, we recommend that you review this new version and upgrade. Some fun: > I’ve never gotten to say…

> their philosophy is to "move slowly and not break things"

The world needs more of this. I'm tired of seeing tooltips that don't disappear and thus get in the way and long GC pauses on Firefox, because nobody bothered to test their bloated React app in Firefox.

Re: jQuery 3.6.0

#212

Frontend has been a pain in the ass for me for quite a while as someone trying to learn frontend development. jQuery's concise syntax beats everyone, I hope Javascript can adapt it someday, truly a KISS design gem. However I do need write code to do data-binding myself, which is important for interactivity. Vuejs can be used to replace jQuery however it does not have the simple syntax, you do get data-binding for fre…

> one reason I worry about jQuery is that it's losing some steam and the development is not very active

It’s super mature which I like. Compare to Vue 3 which is now GA yet lots of related components like Vuetify are quarters behind in supporting v3. Lots of exciting features for sure but also lots of churn.

Re: jQuery 3.6.0

#213
post #140

Earlier quoted context omitted.

My guess is a slimmed-down API with most or all support for older browsers removed, perhaps something similar to Zepto. There is still something to be said for the usability of jQuery's API for direct DOM manipulation, as opposed to the more verbose API offered by the DOM itself.

I love modern reactive frameworks, but for DOM manipulation the jQuery-style API is great. Some problems are much easier to solve working directly with the DOM (eg: drag and drop). The problem is that you either have control over the DOM, or let someone else do it (React, Vue, etc).

> The problem is that you either have control over the DOM, or let someone else do it (React, Vue, etc).

Someone needs to implement a (higher or lower) level of DOM access than what's offered by the current API -- something that would allow React's virtual DOM to be the actual DOM, whether that means allowing direct API access to the underlying tree data structure, or simply implementing the internal React VDOM API on top of the current DOM API.

Re: jQuery 3.6.0

#214

Earlier quoted context omitted.

One could also save document.querySelector to $ as a constant.

That would be very confusing for unsuspecting reader. Please use something different, I would suggest `qs` for `querySelector` and `qsa` for `querySelectorAll`.

This method is not so much for multi-dev codebases but for single devs working on their personal or low-tech sites and are having a hard time letting the $('some-selector') syntax go.

Re: jQuery 3.6.0

#215

Earlier quoted context omitted.

I'm exactly arguing against this Webpack, Typescript, React, etc approach to web development. I'm more productive in PHP + jQuery, a lot due to familiarity, of course, but I'm also a huge believer in a simple stack. If you've 20+ mutually dependent inputs, maybe you need a better UI, not a complex state management framework. If your browser is ultimately executing an untyped crazy dynamic language, is it worth trying…

> It all seems so crazy to me, but this ship has long sailed. Nope. And it's why Svelte is something that I've been hard adopting because it looks the closest to old-school JS/CSS/HTML while still bringing some of the same capabilities over that I love from React and VueJS. It also runs without a VDOM or a constantly running event loop - both things are incredibly attractive to me. Although it's not a perfect solutio…

I really, really hate the JS toolchains like "Webpack + TS + React + eslint + Babel etc etc" that you mentioned.

I rather like Svelte.

But honesty requires that we recognize that Svelte also uses Webpack/Rollup + TS + Svelte etc etc.

I like the idea of Snowpack. But if A.svelte and B.svelte both use C.svelte, Snowpack has to do a lot of redundant work to provide A.js and B.js with Svelte.js and C.js all converted again and again from ts then baked into both A.js and B.js. That's a lot of server work and a lot of client work and a lot of network work.

So you still want a webpack or rollup or what have you to bundle and tree-shake and codesplit for production. I don't know why this irritates me more than running any of my other code through a compiler. But it always has.

Re: jQuery 3.6.0

#216
Are CSS Frameworks like Bootstrap still using jquery? Otherwise I don't see the use case of it now that we have so many JS frameworks plus Javascript as a language has changed so much.

Re: jQuery 3.6.0

#217

Earlier quoted context omitted.

> …and faster response times across the globe, right? Unfortunately not. There is no benefit to leaving your critical files on anyone else’s infrastructure: https://csswizardry.com/2019/05/self-host-your-static-assets...

As someone who is well experienced in web dev, that was a great article! Not so easy to find online, keep up the good work and I’ve become a fan

Thank you!

Re: jQuery 3.6.0

#218

Earlier quoted context omitted.

I'm exactly arguing against this Webpack, Typescript, React, etc approach to web development. I'm more productive in PHP + jQuery, a lot due to familiarity, of course, but I'm also a huge believer in a simple stack. If you've 20+ mutually dependent inputs, maybe you need a better UI, not a complex state management framework. If your browser is ultimately executing an untyped crazy dynamic language, is it worth trying…

At Work, we‘re building web applications that need to be accessed by hundreds of editors with thousands of pages. Most of them share an essential bundle of components. Are you telling me a project that complicated can be built using just jquery? Also, what‘s bad about typescript?

The number of clients accessing the page has no bearing on the best framework to use. The number of pages on the website is also not that relevant.

If 400 people are accessing 10,000 static pages, don't use any js at all.

Re: jQuery 3.6.0

#219
post #6

Do people still use jQuery? I thought the biggest advantage of this library back in the day was css selector access of DOM nodes (back when we only had getElementById, getElementsByClassName, and getElementsByTagName). This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll. Also there are browser compatibility issues that jQuery solved but a lot of these are so…

Still use it because the code base is still full of it and don’t want to have multiple patterns. Plus the plugins are really useful and the syntax is nice.

Re: jQuery 3.6.0

#220

Frontend has been a pain in the ass for me for quite a while as someone trying to learn frontend development. jQuery's concise syntax beats everyone, I hope Javascript can adapt it someday, truly a KISS design gem. However I do need write code to do data-binding myself, which is important for interactivity. Vuejs can be used to replace jQuery however it does not have the simple syntax, you do get data-binding for fre…

> one reason I worry about jQuery is that it's losing some steam and the development is not very active It’s super mature which I like. Compare to Vue 3 which is now GA yet lots of related components like Vuetify are quarters behind in supporting v3. Lots of exciting features for sure but also lots of churn.

on jQuery 4.0 roadmap page: https://github.com/jquery/jquery/milestone/7 , it seems having no progress in two full years.
Post reply on HN