jQuery 3.6.0(blog.jquery.com)
blog.jquery.com
jQuery 3.6.0
http://blog.jquery.com/2021/03/02/jquery-3-6-0-released/
291 comments
>Do people still use jQuery?
Oh yes. Everyday. Still love it.
>…Javascript document api via document.querySelector, and document.querySelectorAll
The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc).
>…smaller footprint libraries like lodash
jQuery is ≈30k gziped and most likely already cached from CDN.
>…has fallen out of favor of more comprehensible state management inside of JS (like React Hooks, Redux...etc.)
Managing state is hard. There shouldn't be much of it in any single view. IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft. Vue is a bit better, but still, I'd much rather use jQuery if given the choice.
If you're building something like Spotify/Slack, I can maybe see the need for virtual DOMs, etc. If you're sprinkling interactivity to your webpage, which is arguably what most of the web should be, jQuery is probably as good as it will ever get.
Oh yes. Everyday. Still love it.
>…Javascript document api via document.querySelector, and document.querySelectorAll
The jQuery API is still (and probably aways will be) far superior to the native DOM (terser, composable, more expressive, etc).
>…smaller footprint libraries like lodash
jQuery is ≈30k gziped and most likely already cached from CDN.
>…has fallen out of favor of more comprehensible state management inside of JS (like React Hooks, Redux...etc.)
Managing state is hard. There shouldn't be much of it in any single view. IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft. Vue is a bit better, but still, I'd much rather use jQuery if given the choice.
If you're building something like Spotify/Slack, I can maybe see the need for virtual DOMs, etc. If you're sprinkling interactivity to your webpage, which is arguably what most of the web should be, jQuery is probably as good as it will ever get.
> jQuery is ≈30k gziped and most likely already cached from CDN.
This part isn't so true in reality anymore, due to revised browser caching systems[1]. Doesn't mean you shouldn't use jQuery, just that part of the benefits of a centralized CDN are no longer a factor and it's a lot more sensible to self-host.
1: https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
This part isn't so true in reality anymore, due to revised browser caching systems[1]. Doesn't mean you shouldn't use jQuery, just that part of the benefits of a centralized CDN are no longer a factor and it's a lot more sensible to self-host.
1: https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
Right you are. But jQuery is around the same size as Vue, and that's the lean alternative to React. So the “jQuery is bloat” argument still doesn't make much sense.
A single retina hero banner is larger than most JavaScript libraries/frameworks.
A single retina hero banner is larger than most JavaScript libraries/frameworks.
> and that's the lean alternative to React.
Ahem https://preactjs.com/
Ahem https://preactjs.com/
oh look, another one. lol
> another one
Preact [0] came before Vue [1].
[0] https://github.com/preactjs/preact/commits/master?after=605b... [1] https://github.com/vuejs/vue/commits/dev?after=5255841aaff44...
Preact [0] came before Vue [1].
[0] https://github.com/preactjs/preact/commits/master?after=605b... [1] https://github.com/vuejs/vue/commits/dev?after=5255841aaff44...
vue.js came before preact, it was first released february 2014 https://blog.evanyou.me/2014/02/11/first-week-of-launching-a...
A lean alternative to React would be preact.
Vue is the lean alternative to Angular.
And you can swap Zepto for jQuery which is like 10k and has pretty much all the functionality apart from some ancient browser support.
One thing that doesn't help jquery's case is that it and its plugin ecosystem isn't modular, making it impossible to trim the code size below the minified size via dead code elimination or even es6 partial imports. It would be nice to see more fluent DOM apis like jquery, but having 1st class support for es6 modules so you can import only the functionality you need in your final bundle
ZeptoJS has a modular build tool, allowing you to select only the desired modules
https://zeptojs.com/
https://zeptojs.com/
So does jQuery by the way; you can use some flags to grunt to enable/disable parts you don't want. The README has some docs on this.
Cash supports partial builds:
https://github.com/fabiospampinato/cash/blob/master/docs/par...
https://github.com/fabiospampinato/cash/blob/master/docs/par...
The reality was you where almost never getting a cached version anyway. There are so many versions of jQuery in use over so many CDNs that the chance of a user already having the exact version and cdn that you use is almost nothing.
We looked into this several years ago and found that most of our users had likely encountered and cached the several most popular versions on CDNs. There was a power law distribution in effect.
In the last five years, the release schedule has slowed, so there was a convergence onto fewer versions in the wild, but at the same time, users were visiting fewer sites that used CDN versions (and fewer sites in general.)
In the last five years, the release schedule has slowed, so there was a convergence onto fewer versions in the wild, but at the same time, users were visiting fewer sites that used CDN versions (and fewer sites in general.)
Thanks for the article. I was just telling someone that jQuery was most likely already in the browser cache so don’t worry about it. Guess I need to go back and say I was wrong...
There's still a huge benefit to using CDNs, despite caching being dead - they are almost certainly faster then whatever is hosting your site. If your site is relatively light and has a lot of traffic (especially international), pulling libs from a CDN could significantly increase the amount of requests you can process on the same server hardware and regardless of that, decrease the load latency for your users.
considering the size of frameworks like react, it's basically a "nothing" download. I've seen people spend more bandwidth on rounded corners.
React with react-dom is like ~35kb gzipped
Well, you are still getting less server load and faster response times across the globe, right?
> …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...
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!
We used to use google.com for hosting jquery for us. Then when google.com started being blocked by the great firewall our site broke (it was pretty popular in China). It took a while to find out what went wrong, especially with the language barrier.
Back then we decided it's just better to self host. Less things can go wrong.
Back then we decided it's just better to self host. Less things can go wrong.
> IMO, React doesn't bring much to the table in this regard while adding a lot of complexity and heft.
Strongly disagree with this. In any complex web application with a lot of components, specially ones where a lot of fixed components can live for a while, React is definitely a massive improvement over vanilla JS or something like Backbone which allows wild west.
Imagine state coming from sockets, rest APIs etc with updates being either pull or push. A user might do an action which changes the state in some other component, keeping track of the components gets hard if the state is distributed. Also, centrally managed state with things like Redux allows for good caching of API data which can make a SPA considerably fast.
While I love plain HTML pages which need little or no JS, a lot of applications are better as SPAs.
Strongly disagree with this. In any complex web application with a lot of components, specially ones where a lot of fixed components can live for a while, React is definitely a massive improvement over vanilla JS or something like Backbone which allows wild west.
Imagine state coming from sockets, rest APIs etc with updates being either pull or push. A user might do an action which changes the state in some other component, keeping track of the components gets hard if the state is distributed. Also, centrally managed state with things like Redux allows for good caching of API data which can make a SPA considerably fast.
While I love plain HTML pages which need little or no JS, a lot of applications are better as SPAs.
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 to shoehorn types into it, only to later transpile it back? Not to mention JSX.
It all seems so crazy to me, but this ship has long sailed.
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 to shoehorn types into it, only to later transpile it back? Not to mention JSX.
It all seems so crazy to me, but this ship has long sailed.
> 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 solution (nothing is) I would strongly suggest you checking into Svelte as it looks more like traditional web development vs. highly complex Webpack + TS + React + eslint + Babel etc etc-based development.
The ship hasn't sailed. Your instincts to be weary of such a complex, constantly re-invented toolchain to get traditional development tasks accomplished are a natural response to the craziness that these tools bring to the table.
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 solution (nothing is) I would strongly suggest you checking into Svelte as it looks more like traditional web development vs. highly complex Webpack + TS + React + eslint + Babel etc etc-based development.
The ship hasn't sailed. Your instincts to be weary of such a complex, constantly re-invented toolchain to get traditional development tasks accomplished are a natural response to the craziness that these tools bring to the table.
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.
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.
I've been running Svelte with esbuild and it's incredible, and doesn't bring along all of the above overhead. I get to target modern browser stacks which is a huge plus that keeps a large amount of complexity out of my toolchain.
Mileage will vary =)
Mileage will vary =)
Svelte has been on my list to try, thanks for the reminder. I've also liked htmx (from intercooler) for keeping complexity managed. Any comparisons?
I saw the Svelte presentation a few years ago when it was released and my jaw hit the floor hard. That was some cool radical thinking. I haven't used it beyond playing with a few examples, so I can't really tell for sure if it holds up. Everything looks great on the demos.
Unfortunately it hasn't caught on, though it maybe be too early to call.
Unfortunately it hasn't caught on, though it maybe be too early to call.
Too early to call.
Wait until Typescript is properly supported.
Wait until Typescript is properly supported.
That happened like half a year ago[0]
[0] https://svelte.dev/blog/svelte-and-typescript
[0] https://svelte.dev/blog/svelte-and-typescript
Definitely too early to call, but it is making waves already:
https://2020.stateofjs.com/en-US/technologies/front-end-fram...
https://2020.stateofjs.com/en-US/technologies/front-end-fram...
what runs with a 'constantly running event loop' exactly?
I can't think of a single framework that does this, (its neigh impossible, actually, it'll just lock up your browser)
Svelte is cool, but this statement needs some serious proof
I can't think of a single framework that does this, (its neigh impossible, actually, it'll just lock up your browser)
Svelte is cool, but this statement needs some serious proof
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?
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.
If 400 people are accessing 10,000 static pages, don't use any js at all.
I couldn‘t disagree more. It‘s a user portal managing thousands of different interactions and workflows, based on the users existing information. Most of them can be edited live with a content-management-system by an editor. These workflows are very hard to reason about with just jquery or nor js at all.
It can, sure, but having coding conventions is essential, which those frameworks/linters help to enforce.
But we've been doing projects with millions of pages way before React :)
Checkout Wikipedia, which, by the way, uses jQuery, of course. And PHP.
>Also, what‘s bad about typescript?
It tries to turn the very dynamic JavaScript into something it will never be and no amount of contortion can hide it. Unless it stops being a superset of JavaScript in the future, but I don't see that coming.
But we've been doing projects with millions of pages way before React :)
Checkout Wikipedia, which, by the way, uses jQuery, of course. And PHP.
>Also, what‘s bad about typescript?
It tries to turn the very dynamic JavaScript into something it will never be and no amount of contortion can hide it. Unless it stops being a superset of JavaScript in the future, but I don't see that coming.
Wikipedia is a largely uniform, read-only, static experience. These days people want app-like experience on the front-end. Can‘t manage them with jquery.
The bit about typescript is true at runtime. However, Typescript is also good documentation for developers.
The bit about typescript is true at runtime. However, Typescript is also good documentation for developers.
Do you need SPA for everything there? Because if server side rendering/logic is “allowed” with only a few interactive bits here and there written in jquery, than it can be absolutely done as that was/is the case a “few” years back.
I work on an app that is half react and half rails templates. Every time something has to change on one of the rails templates it becomes a process of explaining to the project manager that we can't easily make this change which would have been trivial elsewhere because this specific page is using server side rendering.
Its become such a large obstetrical that we have scheduled in a task this year to remove all server side rendering from the app.
Its become such a large obstetrical that we have scheduled in a task this year to remove all server side rendering from the app.
I work on an app that is half react and half rails templates. Every time something has to change on one of the rails templates it becomes a process of explaining to the project manager that we can't easily make this change which would have been trivial elsewhere because this specific page is using server side rendering.
Its become such a large problem that we have scheduled in a task this year to remove all server side rendering from the app.
Server side rendering almost always means implementing the same feature twice, once on the server so it loads correct, and then a second time on the frontend so it changes as the user modifies it.
Its become such a large problem that we have scheduled in a task this year to remove all server side rendering from the app.
Server side rendering almost always means implementing the same feature twice, once on the server so it loads correct, and then a second time on the frontend so it changes as the user modifies it.
https://htmx.org
For when I’ve wanted to sprinkle interactivity, this is what I’ve turned to lately. It’s quite brilliant, and more declarative than most solutions.
But React is still necessary in my day to day job, as our web application is incredibly complicated in terms of feature set and customisation. They both have a place.
For when I’ve wanted to sprinkle interactivity, this is what I’ve turned to lately. It’s quite brilliant, and more declarative than most solutions.
But React is still necessary in my day to day job, as our web application is incredibly complicated in terms of feature set and customisation. They both have a place.
I'm on the same boat, super productive with php/twig/jquery.
But recently my boss gave my a side project without any specific requirements, 10 charts and 2-3 tables with their associated crud.
I made everything with react + php, and oh my god that site is super fast. It's eye opening!
Make Postbacks Great Again.
That's more like redux and company...
Yeah, but redux etc gained traction with React, and together they make SPAs good.
SPAs were perfectly good before with ExtJS and similar, and more easily extensible too.
ExtJS = "What if JSX, but in JSON" ;)
For me, ExtJS redefined what's possible on the web a full decade before React/Angular & co, and it's sad that Sencha is now part of a heartless corporate graveyard.
For me, ExtJS redefined what's possible on the web a full decade before React/Angular & co, and it's sad that Sencha is now part of a heartless corporate graveyard.
SPAs were never good, the entire notion of them or shoehorning full apps into a browser is a farce. But, as parent says, that ship has long sailed
Native apps definitely have advantage in some areas.
But web apps give the ability to ship an app to more platforms and not be restricted by app store border control. Spotify had an Ubuntu client which never worked well, but as their web app improved I got almost the same experience as I would have on OS X or Windows web app. This gives equal chance to other platforms and to app developers as well as they don't have to play by rules like 30% cut.
As long as we can ensure web browsers can be kept open on major platforms(the only exception right now is iOS), it gives more freedom and choice to non platform developers. I would be really happy if PWA support in web browsers keeps improving going forward and need for dedicated apps gets eliminated for most things.
But web apps give the ability to ship an app to more platforms and not be restricted by app store border control. Spotify had an Ubuntu client which never worked well, but as their web app improved I got almost the same experience as I would have on OS X or Windows web app. This gives equal chance to other platforms and to app developers as well as they don't have to play by rules like 30% cut.
As long as we can ensure web browsers can be kept open on major platforms(the only exception right now is iOS), it gives more freedom and choice to non platform developers. I would be really happy if PWA support in web browsers keeps improving going forward and need for dedicated apps gets eliminated for most things.
"The jQuery API is still (and probably aways will be) far superior to the native DOM"
The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations. It only operates on individual DOM nodes. Any looping should be done using your JS loop of choice (forEach, for loop, which, etc).
The script started out really small. I've slowly added more and more as I need more functionality for some projects.
https://gist.github.com/pseudosavant/b86eedd9960ade958d49447...
The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations. It only operates on individual DOM nodes. Any looping should be done using your JS loop of choice (forEach, for loop, which, etc).
The script started out really small. I've slowly added more and more as I need more functionality for some projects.
https://gist.github.com/pseudosavant/b86eedd9960ade958d49447...
> The jQuery API really is so well done. I stopped using jQuery, but implemented a simple script (jSugar.js) that exposes many basic jQuery things but is really just a wrapper for native DOM operations.
so... like jQuery?
so... like jQuery?
No, because jQuery normalizes all sorts of DOM stuff. Part of the reason it is 30kb. What I've done is basically syntatic sugar and is only 74loc.
>most likely already cached from CDN.
I don't believe any major browser allows sites to share 3rd party caches anymore.
Previous HN discussion: https://news.ycombinator.com/item?id=24894135
I don't believe any major browser allows sites to share 3rd party caches anymore.
Previous HN discussion: https://news.ycombinator.com/item?id=24894135
True, there is still a perf win however since CDNs are located geographically closer to a global consumer than keeping the libs on your own box.
Self-hosting is no longer the performance drain it used to be now that HTTP/2 is a thing, as soon as the browser parses the page, the JS file is only 1 RTT away. Using a CDN for a single asset like jQuery requires a DNS lookup, TCP connection and TLS negotiation - that's 3 RTTs plus unknown latency from the user's resolver before the HTTP request is even sent. The performance difference in the single request scenario is likely negligible and the benefits of not relying on a 3rd party can outweigh the latency savings.
But don't modern frontend-oriented sites/apps deploy to CDNs anyway?
I agree with this 100%. Even though "vanilla JS" is more powerful now, JQuery is still much easier to work with.
I used to write a lot of JQuery, and I've switched to Vue three years ago. Occasionally I have to go back and write more JQuery, and it makes my head hurt.
edit: why the dowvotes? are we not allowed to share our experiences now?
edit: why the dowvotes? are we not allowed to share our experiences now?
I know we're not supposed to discuss voting but people downvoting someone simply because that person said something disagreeable, yet still within the rules of Hacker News, is becoming a serious problem in my opinion. I'd like it just fine we get rid of downvotes altogether.
Trying to write any kind of complex interactivity with JQuery event handlers is a serious pain in the butt, and it's so hard to go back and read.
I did the same as you; moved on to Vue and haven't looked back. My frontend code is so much cleaner and easier to debug. I've built a large library of components, so often times adding a new page only takes a couple hours re-using those instead of writing a bunch of new JQuery from scratch.
JQuery is great when I need to make (non-contentful) changes to the DOM. But I refuse to use it for managing the state of my app or putting content in UI components.
I did the same as you; moved on to Vue and haven't looked back. My frontend code is so much cleaner and easier to debug. I've built a large library of components, so often times adding a new page only takes a couple hours re-using those instead of writing a bunch of new JQuery from scratch.
JQuery is great when I need to make (non-contentful) changes to the DOM. But I refuse to use it for managing the state of my app or putting content in UI components.
Smaller footprint in my mind doesn't refer to download size which is minimal in either case but the footprint or impact on a project. IMO It is way harder to move off of jquery once it has been fully utilized throughout the project than to swap a single function to/from lodash once a core API has a better way of handling it. Using JQuery demands you buy into the whole ecosystem whereas Lodash is modular.
Also as others have mentioned caches are individually isolated for each domain now to prevent tracking/data leaks.
Also as others have mentioned caches are individually isolated for each domain now to prevent tracking/data leaks.
Firefox and Safari use partitioned caches, and Chrome is following with the feature behind an experiment flag for now. The argument that it's probably cached from a CDN is just about dead.
[deleted]
[deleted]
> If you're building something like Spotify/Slack, I can maybe see the need for virtual DOMs
Heck, even Slack was built with jQuery the first time. Only after a while they migrated to react.
Heck, even Slack was built with jQuery the first time. Only after a while they migrated to react.
[deleted]
Still use it. Still love it.
Just last month I decided to toss a quite arbitrary `=>` in my javascript (I still write `function (args) { code }`), and shipped it. Immediately got a _TON_ of user complaints.
Turns out, we sent a link in a newsletter, and most folks were reading those in Outlook, and that evidently just opens links internally, and that is still IE11. We don't ordinarily support IE11, but given that this is a specific info page shown there, for this we make an exception, and... => doesn't even work there.
Thus, another year goes by, and another year where I am 100% convinced it is totally not worth my time or effort to investigate newer options.
I'm honestly confused about why jQuery is considered 'bad'.
It's a dependency - yeah, 30k or so. This complaint (that it adds load time) boggles my mind; in this day and age of 10MB+ load pages, and the choice is to complain about a 30k library? Some javascript-library variant of the Total Perspective Vortex may be warranted to try to make sense of this.
A more interactive (as in, between server and browser), more stateful integrated model? Oh, yeah, totally, I can see that, but that 'formula' surely isn't the go-to strategy for every web page out there, right? Most of the pages I write work perfectly well via a 'server generates data, server throws it through a template and sends it to browser, client downloads jquery and some javascript for that page which adds interactive elements', and wouldn't be any 'nicer' if it was a much more javascript-native fully state-shared amalgamation. When I do need that live-updating stateful interaction model, sure, don't need jQuery. But that 30k is the least of my worries if that happens.
Just last month I decided to toss a quite arbitrary `=>` in my javascript (I still write `function (args) { code }`), and shipped it. Immediately got a _TON_ of user complaints.
Turns out, we sent a link in a newsletter, and most folks were reading those in Outlook, and that evidently just opens links internally, and that is still IE11. We don't ordinarily support IE11, but given that this is a specific info page shown there, for this we make an exception, and... => doesn't even work there.
Thus, another year goes by, and another year where I am 100% convinced it is totally not worth my time or effort to investigate newer options.
I'm honestly confused about why jQuery is considered 'bad'.
It's a dependency - yeah, 30k or so. This complaint (that it adds load time) boggles my mind; in this day and age of 10MB+ load pages, and the choice is to complain about a 30k library? Some javascript-library variant of the Total Perspective Vortex may be warranted to try to make sense of this.
A more interactive (as in, between server and browser), more stateful integrated model? Oh, yeah, totally, I can see that, but that 'formula' surely isn't the go-to strategy for every web page out there, right? Most of the pages I write work perfectly well via a 'server generates data, server throws it through a template and sends it to browser, client downloads jquery and some javascript for that page which adds interactive elements', and wouldn't be any 'nicer' if it was a much more javascript-native fully state-shared amalgamation. When I do need that live-updating stateful interaction model, sure, don't need jQuery. But that 30k is the least of my worries if that happens.
"Fun" fact: Outlook today still uses Word to render HTML, which is about as capable as IE3 released in 1996.
It's not that simple. It used to have a more capable renderer, they rolled it back to the Word one (no animated GIFs!) and have since upgraded again. So Outlook 2007-2016 is really crappy, versions before and after that, a bit less so.
The lovely world of enterprise software.
The lovely world of enterprise software.
Your use of the word "still" is a little misleading. IE _was_ the default email rendering engine until 2007 when Microsoft made the inexplicable decision to move to Word 2007 instead.
Outlook is part of Office;
Word is part of Office.
IE, and now Edge, is a different business unit.
Not inexplicable at all. NIH doesn't only apply at corporate boundaries.
IE, and now Edge, is a different business unit.
Not inexplicable at all. NIH doesn't only apply at corporate boundaries.
My theory is still that it was about using Word as a component to write replies. However, if they delayed the HTML->Word conversion to that point, everyone would complain to MS "Reply is broken!"
By using Word as a viewer the email is broken right on delivery and users now complain "The email you sent me is broken!"
At least it's still better than Notes
By using Word as a viewer the email is broken right on delivery and users now complain "The email you sent me is broken!"
At least it's still better than Notes
jQuery is "bad" when complexity increases.
jQuery's strength is the CSS selector based approach, where CSS, HTML and JS all "speak the same language", but it also its greatest weakness, your JS code gets too tightly coupled with the structure of the HTML, which makes it harder to refactor.
Good code management can solve this, like using a class or class like construct (e.g. jQuery plugin) to create independent components. But jQuery misses a lot of features to be a truly component based solution. jQuery UI widget is somewhat closer but still missing features like other component based solution has, e.g. no built in template library.
One of the most common things in JS is to attach listeners to HTML elements, however the most common way when doing so in jQuery is that you have a bunch of selectors and then some listener code, but that type of statements is not self explanatory, you have no function name to describe what it is doing or any other context. You see all these registrations of event listeners scattered across the project. What do they do? Are they in use? Hard to tell because searching your source code for a CSS selector is very difficult. That is why jQuery based projects usually have tons of leftover code from the last refactor, no one dares to touch it.
Many component based libraries out there lets you register a method name on the HTML element directly. Much better. If you can't find the method/function name referenced in your code, you can delete it.
It is true that you can add event listeners inline on your HTML element, but that is not how jQeury is usually written, because it is selector based.
jQuery's strength is the CSS selector based approach, where CSS, HTML and JS all "speak the same language", but it also its greatest weakness, your JS code gets too tightly coupled with the structure of the HTML, which makes it harder to refactor.
Good code management can solve this, like using a class or class like construct (e.g. jQuery plugin) to create independent components. But jQuery misses a lot of features to be a truly component based solution. jQuery UI widget is somewhat closer but still missing features like other component based solution has, e.g. no built in template library.
One of the most common things in JS is to attach listeners to HTML elements, however the most common way when doing so in jQuery is that you have a bunch of selectors and then some listener code, but that type of statements is not self explanatory, you have no function name to describe what it is doing or any other context. You see all these registrations of event listeners scattered across the project. What do they do? Are they in use? Hard to tell because searching your source code for a CSS selector is very difficult. That is why jQuery based projects usually have tons of leftover code from the last refactor, no one dares to touch it.
Many component based libraries out there lets you register a method name on the HTML element directly. Much better. If you can't find the method/function name referenced in your code, you can delete it.
It is true that you can add event listeners inline on your HTML element, but that is not how jQeury is usually written, because it is selector based.
I think a lot! For example, the new https://www.whitehouse.gov uses jQuery.
When you just want to add a small bit of interaction to a mostly-static site, jQuery can help.
There's a current trend to complicate things with a JAM stack that really don't need to be complicated.
I've seen people propose something like
When you just want to add a small bit of interaction to a mostly-static site, jQuery can help.
There's a current trend to complicate things with a JAM stack that really don't need to be complicated.
I've seen people propose something like
[NodeJS/Ruby/PHP backend]
-> GraphQL API
-> React Frontend
-> static html
[NodeJS/Ruby/PHP backend]
-> static htmlI do think in some cases SPA make sense, but in many other cases just using a bit of jQuery/vanilla js to add a bit of interaction is enough. Server side rendering is way easier to do and is often faster to load for the client.
SPA make sense whenever you want to write a proper application running in the browser. When you just want a website, stop the SPA madness.
> When you just want to add a small bit of interaction to a mostly-static site, jQuery can help.
For very small amounts, perhaps, but honestly, even then I think it has limitations. As an anecdote, about six months ago, I needed to add a couple of dynamic forms to a static site. The forms were a simple contact us, and a mailing list sign up form, and only needed to handle the states of Open->Submitting->Thanks|Failed->Open, while preventing double submissions, etc.
I wrote the first one in jQuery (site was already using it due to the theming), and making sure handled all the various edge cases, and fixing one bug didn't cause another was far harder and time consuming than it should be.
Out of frustration, I wrote the other form in VueJS, and hacked the whole form in about an hour or two. My take away was that anything involving state in jQuery can get overly complicated very quickly.
For very small amounts, perhaps, but honestly, even then I think it has limitations. As an anecdote, about six months ago, I needed to add a couple of dynamic forms to a static site. The forms were a simple contact us, and a mailing list sign up form, and only needed to handle the states of Open->Submitting->Thanks|Failed->Open, while preventing double submissions, etc.
I wrote the first one in jQuery (site was already using it due to the theming), and making sure handled all the various edge cases, and fixing one bug didn't cause another was far harder and time consuming than it should be.
Out of frustration, I wrote the other form in VueJS, and hacked the whole form in about an hour or two. My take away was that anything involving state in jQuery can get overly complicated very quickly.
> When you just want to add a small bit of interaction to a mostly-static site
Then I'd reach for Alpine. Very lightweight, and I can use the fetch API instead of $.ajax.
Then I'd reach for Alpine. Very lightweight, and I can use the fetch API instead of $.ajax.
Jquery has been around for 14 years. That framework..16 months.
You want to be as confident as possible you can bump to a new version on your old site in 4 years if you have to? Use Jquery.
You want to be as confident as possible you can bump to a new version on your old site in 4 years if you have to? Use Jquery.
Plus it's easier to hire for. Chances are more developers have experience with JQuery than <new hot js library>.
Or just fork Alpine and fix it. It’s javascript, not rocket science.
or Lit-Element.
whitehouse.gov uses jquery because its wordpress
There's no need to complicate static sites with jQuery. All it does can be achieved with vanilla.
Vanilla has always been able to do what jQuery can, otherwise jQuery wouldn't exist. It all depends on what your threshold for abstraction and verbosity is. That is going to depend on what you are doing and who you are.
Exactly.
I mean, all you really need is a Turing Machine, but they're not very pleasant to program.
Same thing with vanilla JS and jQuery.
I mean, all you really need is a Turing Machine, but they're not very pleasant to program.
Same thing with vanilla JS and jQuery.
> All it does can be achieved with vanilla.
Well, yes. Every JS library can be written in vanilla JS. The point of jQuery, React, etc. is to make it easier for the programmer to reason about what is going on while avoiding bugs.
Well, yes. Every JS library can be written in vanilla JS. The point of jQuery, React, etc. is to make it easier for the programmer to reason about what is going on while avoiding bugs.
I tend to agree, and unless you have to support like IE prior to IE9 it will probably easily support all of your target browsers.
Promises aren't available in IE11, and as the last "true" IE, I imagine it'll be around a bit longer than it should be.
I recently had to rewrite a bunch of vanilla promise-based code to use jQuery promises once I realized IE11 didn't work.
I recently had to rewrite a bunch of vanilla promise-based code to use jQuery promises once I realized IE11 didn't work.
As a competitive code golfer, I can confidently say that vanilla JS has never offered the raw performance of jQuery.
I like jQuery because:
- The API is still more concise than what is built into the browser (Compare the number of lines used here: http://youmightnotneedjquery.com/)
- It is still useful for older browsers that might not support something.
- The API is burned into my brain, it speaks jQuery.
- If I have any issues, Google will usually surface how to use the API faster than the (standards compliant API * can I use it?)
I do use React for UI, but sometimes you have to interact with the DOM; in those cases for larger programs I find jQuery easier to read and write.
- The API is still more concise than what is built into the browser (Compare the number of lines used here: http://youmightnotneedjquery.com/)
- It is still useful for older browsers that might not support something.
- The API is burned into my brain, it speaks jQuery.
- If I have any issues, Google will usually surface how to use the API faster than the (standards compliant API * can I use it?)
I do use React for UI, but sometimes you have to interact with the DOM; in those cases for larger programs I find jQuery easier to read and write.
> This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll.
Have you actually compared the two methods in a real website? It's like saying why use Ruby when you can use Java. The Javascript document API is super verbose. No thanks.
Have you actually compared the two methods in a real website? It's like saying why use Ruby when you can use Java. The Javascript document API is super verbose. No thanks.
Conversely, looking at how you do it through jQuery after seeing how it is in Javascript gives me the same reaction.
The fact that jQuery is usually assigned to the dollar sign definitely doesn't help, especially for beginners. The amount of questions I've answered that stemmed from a fundamental misunderstanding of how Javascript works, all because they learned jQuery instead of Javascript, is pretty significant.
The fact that jQuery is usually assigned to the dollar sign definitely doesn't help, especially for beginners. The amount of questions I've answered that stemmed from a fundamental misunderstanding of how Javascript works, all because they learned jQuery instead of Javascript, is pretty significant.
I remember when I was in uni that the $() must've had a special meaning or something. I was pretty convinced that the $ was some tough mathematical operator or computer science concept that I didn't yet understand.
When I learned that it was simply a function invocation that returned a jQuery object so you could chain it, I was absolutely shocked about the simplicity of that statement.
Beginning developers sure like to project their cognitive insecurities onto programming. Or at least, I did :)
When I learned that it was simply a function invocation that returned a jQuery object so you could chain it, I was absolutely shocked about the simplicity of that statement.
Beginning developers sure like to project their cognitive insecurities onto programming. Or at least, I did :)
There's so much magic in programming that as a beginner, it's hard to know which magic you should dig deeper into, vs which is such a treacherous rabbit hole you're better off cargo culting.
It think this is true of many technical things. Statistics, sailing, car mechanics, photography... What I love about HN is it often gives clues as to which are the interesting rabbit holes.
That argument stands true for most frameworks on most platforms. I prefer the dollar sign; it's pervasive and concise.
I disagree. There's nothing about React, Vue or any other framework that I'm aware of that does anything similar to jQuery's dollar sign. The only magically-looking abstraction I can think of is JSX, and that's not only not mandatory but very obviously something that's off the curve. Unlike the dollar sign, which just looks like a special construct of the language.
Svelte uses the dollar sign.
https://svelte.dev/tutorial/reactive-declarations
You don't have to use all of it though, right? You can choose to only only use the applicable parts:
eg:
``` $('.container-element') .addClass('active');
// vs
document.querySelectorAll('.my-class-selector') .classList.add('active') ```
I use the native APIs all the time, they are not that complicated or overly verbose. Easily memorized with practice IMHO. Also they are all extremely well documented on MDN.
``` $('.container-element') .addClass('active');
// vs
document.querySelectorAll('.my-class-selector') .classList.add('active') ```
I use the native APIs all the time, they are not that complicated or overly verbose. Easily memorized with practice IMHO. Also they are all extremely well documented on MDN.
Technically that breaks, you want:
document.querySelectorAll('.my-class-selector').forEach(el => el.classList.add('active'))
Yeah, oh so many years ago I realized that I use just a small subset of jQuery, and just rewrote those bits, to avoid having to inject whole of jQuery into all pages that I browse (I had some global https?://* userscripts, so I was basically injecting jQuery into every single page and frame).
https://megous.com/dl/tmp/basic.js
1.3kB compressed. Much better. :) And I avoided having to rewrite my extensions with platform APIs. That was before FF killed all the joy in writing userscripts for me, because I was no longer able to install and update them just by copying them to mozilla folder and had to invoke a lot of clicking ceremony to just get my 20 scripts or so from git into firefox past the webextension limitations on storage/access to mozilla folder.
https://megous.com/dl/tmp/basic.js
1.3kB compressed. Much better. :) And I avoided having to rewrite my extensions with platform APIs. That was before FF killed all the joy in writing userscripts for me, because I was no longer able to install and update them just by copying them to mozilla folder and had to invoke a lot of clicking ceremony to just get my 20 scripts or so from git into firefox past the webextension limitations on storage/access to mozilla folder.
You should totally open-source that, put it on NPM, and write an article or so about it.
Everyone will have different set of methods they use. Point of this is that if you need some method you can just add it in in 4-5 lines or remove one you don't need. So it's not the best fit for NPM. It's good fit for good old copy/paste into a project, if you're optimizing for size/memory use. :)
BTW, NodeList.prototype.forEach is not available on every browsers that supports querySelector/querySelectorAll, such as IE11: https://caniuse.com/mdn-api_nodelist_foreach
So you need to be careful about writing code like that if you want to avoid jQuery.
So you need to be careful about writing code like that if you want to avoid jQuery.
Your example does not work. querySelectorAll returns array and you can't write `array.classList.add("...")`, because array does not have that property. You need to iterate over that array. And that's exactly why jQuery is so much more convenient over native API: you can just treat collections of elements like an element and jQuery will iterate for you if necessary.
Another jQuery advantage is pseudo-selectors which don't exist in CSS.
There are plenty of convenient one-liners in jQuery which will expand to plenty of lines in native API. That said, with modern API and JS features it's not that bad either.
Another jQuery advantage is pseudo-selectors which don't exist in CSS.
There are plenty of convenient one-liners in jQuery which will expand to plenty of lines in native API. That said, with modern API and JS features it's not that bad either.
Just a nitpick, but querySelectorAll returns a NodeList.
This can bite at times, for example IE supports Array.forEach, but not NodeList.forEach
This can bite at times, for example IE supports Array.forEach, but not NodeList.forEach
Yeah this gets me every time. You can .forEach a NodeList, but can't .map. I usually end up wrapping it in an array and calling map on it like [...theNodeList].map(...)
I think the fact that your very simple example (which is already longer and more complicated in your version) doesn't work shows the advantage of jQuery
Isn’t your example a type error. JQuery’s operations auto-broadcast over the lists of elements it returns whereas the native methods don’t
[deleted]
How so? Who stops you from doing something like `const $ = document.querySelector`?
There's a ton of other functions you need like element.addEventListener, insertAdjacentElement, XMLHttpRequest (when you need progress) etc. etc.
At that point you might as well save yourself and the person after you a major headache and just use jQuery whose API everybody knows.
The big magic of jQuery is that you can act on an array of elements as if it were a single element. Your alias does not give you that at all.
Good point
I'm still a little bit sad we got fetch as part of javascript when the request module had such a great interface. I still prefer the look of it.
https://www.npmjs.com/package/request
https://www.npmjs.com/package/request
> The Javascript document API is super verbose.
Can't say I've ever heard that as an issue before..
Also I think the main point was there are so many better frameworks that manage the DOM better than jQuery as the need has evolved. I'll always have fond memories of jQuery but I don't see it as my go-to anymore, by a long shot.
Can't say I've ever heard that as an issue before..
Also I think the main point was there are so many better frameworks that manage the DOM better than jQuery as the need has evolved. I'll always have fond memories of jQuery but I don't see it as my go-to anymore, by a long shot.
I never understood why people say “We’ve solved your jQuery problem” by introducing getElementsByClassName() or even querySelector(). When I come back to my older app, $(“.my-class”) is still much nicer. jQuery gets out of the way, the class gets syntax-highlighted, and .focus() can’t create an NPE.
I know it doesn't replace jQuery, but this is fairly straightforward:
$ = document.querySelector.bind(document)
$$ = document.querySelectorAll.bind(document)It's annoying that it returns a NodeList which doesn't have some common array-y methods and the like. While these aliases are certainly convenient, the jQuery semantics are much nicer and more intuitive IMO.
You can, of course, make it more robust, like:
function $$(sel, parent) {
var nodes = (parent || document).querySelectorAll(sel);
return Array.prototype.slice.call(nodes, 0);
}
Yeah, but 19 helper functions later and you've got half of jQuery. I'd rather use a properly tested library.
Using this since ages. Also use window.DOM = document
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.
> jQuery gets out of the way, the class gets syntax-highlighted, and .focus() can’t create an NPE.
So if your selector is wrong, you won’t actually know, because your code will pretend to run along just fine.
I personally consider that a con, not a pro, and one of my (many) reasons not to use jQuery.
So if your selector is wrong, you won’t actually know, because your code will pretend to run along just fine.
I personally consider that a con, not a pro, and one of my (many) reasons not to use jQuery.
I help teach an introductory programming class to high school students. We still use jQuery to teach basic programming concepts, because it helps students add basic interactivity to a web page without a) the overhead of learning a full framework like React, or b) exposing them to the insanity of web APIs. Check out the curriculum if you're interested: https://github.com/itscodenation/curriculum-20-21
If you just want to add simple interactivity to a web page, jQuery provides a really nice API to do just that. Sure it's not the ideal thing to build a whole SPA on, but it has its place.
If you just want to add simple interactivity to a web page, jQuery provides a really nice API to do just that. Sure it's not the ideal thing to build a whole SPA on, but it has its place.
I've written a number of small apps for testing at my company with basically jquery+html+rust backend "web server" and it works quite well if you're not trying to get too fancy.
I think it’s like Lisp, or rather the reaction to Lisp.
In a world without jQuery every site / devshop uses their own little set of conventions and polyfills (analogous to macros) to add useful abstractions.
In isolation, these are neat. En masse though it means that each site has their own meta language (conventions) which have to be memorized before you can contribute to the code base. Languages like Ruby and Lisp suffer from this too: there are so many minute variants across code based that it becomes hard to truly view them as the same language. jQuery, in the context of JavaScript, is a standardisation track for all those little language additions.
Personally, I just use the native APIs. I don’t work with enough people across enough sites to benefit from standardisation. You will probably find a big overlap between proponents of jQuery and professionals — especially contractors — who work with many other people on many different codebases.
In a world without jQuery every site / devshop uses their own little set of conventions and polyfills (analogous to macros) to add useful abstractions.
In isolation, these are neat. En masse though it means that each site has their own meta language (conventions) which have to be memorized before you can contribute to the code base. Languages like Ruby and Lisp suffer from this too: there are so many minute variants across code based that it becomes hard to truly view them as the same language. jQuery, in the context of JavaScript, is a standardisation track for all those little language additions.
Personally, I just use the native APIs. I don’t work with enough people across enough sites to benefit from standardisation. You will probably find a big overlap between proponents of jQuery and professionals — especially contractors — who work with many other people on many different codebases.
Or just people who have a poor memory, or who are not very self consistent. I love things like jquery (and Django and other opinionated frameworks) because it saves me the hassle of having bike shed trivial details for myself and then remember them later. And naming things is one of the two hard problems etc...
You wouldn’t believe in the amount of solid applications using jQuery out there. It’s still widely adopted, specially when you are maintaining legacy applications.
While I personally don’t use it in my day job anymore (Mostly React nowadays), I still know a good number of people that use jQuery in my local community.
Worth noting: Legacy doesn’t mean bad. Just software that sustained the tough test of time.
I'm trying to wean off of jQuery to reduce dependencies, but it makes me appreciate jQuery all the more. The native JS API is quite a bit more verbose and cumbersome to use, and my absolute biggest gripe with it is that it doesn't even build on modern JS features. It's not compatible with for...of, map, filter, find, etc, which seems really strange for a relatively recent vanilla JS API.
Ironically, http://youmightnotneedjquery.com/ makes a pretty good case in favour of jQuery.
Ironically, http://youmightnotneedjquery.com/ makes a pretty good case in favour of jQuery.
What I don't understand is why the modern js api didn't just adopt query's conventions... they're so much nicer and more expressive most of the time.
They cannot. If they do and remove the old getelementbyname, etc, then it will be breaking change.
If they just add $ notation, then there will be redundancy / inconsistency with existing api. Furthermore it will break / confuse apps which use jquery.
Then it's far easier to just include minified jquery into your apps when you want to use it, and you have more control about it's version, etc.
If they just add $ notation, then there will be redundancy / inconsistency with existing api. Furthermore it will break / confuse apps which use jquery.
Then it's far easier to just include minified jquery into your apps when you want to use it, and you have more control about it's version, etc.
I'm not saying to use $, but the elegance/composability of jQuery could have been implemented as they updated the API. And deprecating getelementbyname etc could have been done over a long period.
You can easily extend NodeList.prototype with Array.prototype functions you like, and then just use them:
['map', 'find'].forEach(f => NodeList.prototype[f] = Array.prototype[f]);
document.querySelectorAll('bla').map(el => whatever)
Nice,
['map', 'find', 'filter', 'reduce'].forEach(f => NodeList.prototype[f] = Array.prototype[f])
// this is for for..of, cannot be above 'map', 'filter' etc.
NodeList.prototype[Symbol.iterator] = Array.prototype[Symbol.iterator]
document.querySelectorAll('span').map(el => console.log(el))
document.querySelectorAll('span').filter(el => el.className === 'fc-black-500').reduce((acc, el) => (acc += el.className, acc), '')
for(let p of document.querySelectorAll('p')) { console.log(p) }
You can also create a getter on NodeList.prototype named '_' that returns Array.from(this) and then just use any of the array methods on it. Like
document.querySelectorAll('div')._.some(...)
It is literally the first thing I add to every personal project I build, and it's included with a lot of things I work with professionally. Jquery just makes life easier.
This. I can just prototype something so gosh darn quickly in jQuery and I'm so used to it by this point that between that and advancements in CSS it's incredibly awesome.
Why replace what's not broken?
Why replace what's not broken?
Yes. For quick small things.
When I need a to write a small web service, I usually just grab a python micro-framework and do the work. Not much complexity and not a lot of setup required. When I need to do something more elaborate that needs structure because it will get extended over time, I will take my time to setup something like Django... but it would be too much unnecessary work do to that for small web services.
The same applies to front-end.
When I need a few quick HTML pages that need some quick DOM manipulation, I usually just grab jQuery and do what we have been doing for years. Whenever I know that something will get extended over time and needs structure, that is when I take the time to setup React/Redux and all the build scripts necessary to make it work.
Just personal preference, but I am sure I am not alone...
When I need a to write a small web service, I usually just grab a python micro-framework and do the work. Not much complexity and not a lot of setup required. When I need to do something more elaborate that needs structure because it will get extended over time, I will take my time to setup something like Django... but it would be too much unnecessary work do to that for small web services.
The same applies to front-end.
When I need a few quick HTML pages that need some quick DOM manipulation, I usually just grab jQuery and do what we have been doing for years. Whenever I know that something will get extended over time and needs structure, that is when I take the time to setup React/Redux and all the build scripts necessary to make it work.
Just personal preference, but I am sure I am not alone...
Yep. I still use it for side one-off projects here and there. For me, there's just something so convenient about being able to make a html page that you can drop in a quick CDN link for jquery and not have to worry about compiling, webpack, create-react-app etc. I'll still use React when something is a larger project with a ton of moving parts, but otherwise I stick with jquery.
As for why I'm not using the native DOM api's...I could, but haven't gotten around to learning that syntax since I'm very used to jquery (being specific, if I want to do things that are more complicated than selecting an element + changing its properties, the native API is more complicated). jquery is just a nice default.
As for why I'm not using the native DOM api's...I could, but haven't gotten around to learning that syntax since I'm very used to jquery (being specific, if I want to do things that are more complicated than selecting an element + changing its properties, the native API is more complicated). jquery is just a nice default.
I hear you. Personally I think learning the native APIs isn't so bad once you take the plunge. They are easily memorized with practice. Imagine not needing to go for that CDN link (or depending on some 3p for your website to work correctly)
It's not that more complicated. There are after()/before()/closest()/remove(), and a lot of other similar easy to use methods these days.
It's not el.parentNode.insertBefore(new, el) and el.parentNode.removeChild(el) days anymore.
It's not el.parentNode.insertBefore(new, el) and el.parentNode.removeChild(el) days anymore.
Well, Wordpress and Drupal still uses jQuery, they auto load it by default and there is no reason not use at this point, unless you specifically building React or some other custom thing on top of either of them.
"What is the current use-case for jQuery? I'm curious from hearing it's current users answer this."
I still see it used for file upload/download, as the fetch api doesn't provide a reasonable way to show progress if the channel is using gzip or deflate. The ajax functionality is also still popular for a compact way to deal with different types of errors (app errors vs connectivity errors).
I still see it used for file upload/download, as the fetch api doesn't provide a reasonable way to show progress if the channel is using gzip or deflate. The ajax functionality is also still popular for a compact way to deal with different types of errors (app errors vs connectivity errors).
For me personally, it's partly familiarity and also still compatibility. I know that if I use jQuery, then (for the parts it covers) I don't have to search caniuse.com.
But then, I'm not a front-end web developer, so I optimize for different type of projects.
But then, I'm not a front-end web developer, so I optimize for different type of projects.
There were other things like the "Ajax" (remember that word?) API, but that one's also been matched by a native API (fetch())
> keeping state within the DOM has fallen out of favor of more comprehensible state management inside of JS
Not everything needs a whole reactive templating library. There's absolutely still a usecase for mostly-static sites to do imperative DOM manipulation.
The usecase for jQuery itself these days is dodgier, since as you point out most of its big features are native now. It should still help with browser compatibility (not necessary for modern-ish browsers, but many sites don't want to limit themselves to modern-ish browsers), its APIs are arguably still a little nicer in some places, and it does have a significant ecosystem of plugins so there's probably some value in having that stuff integrate together. But personally I would have a hard time justifying a whole library just for slightly nicer APIs unless I was doing something significantly complicated, and at that point I would just use React.
> keeping state within the DOM has fallen out of favor of more comprehensible state management inside of JS
Not everything needs a whole reactive templating library. There's absolutely still a usecase for mostly-static sites to do imperative DOM manipulation.
The usecase for jQuery itself these days is dodgier, since as you point out most of its big features are native now. It should still help with browser compatibility (not necessary for modern-ish browsers, but many sites don't want to limit themselves to modern-ish browsers), its APIs are arguably still a little nicer in some places, and it does have a significant ecosystem of plugins so there's probably some value in having that stuff integrate together. But personally I would have a hard time justifying a whole library just for slightly nicer APIs unless I was doing something significantly complicated, and at that point I would just use React.
jQuery is like WordPress. There may be other more streamlined, purpose-built solutions out there, and they all have their uses, but sometimes ease of setup is the thing you're optimizing for, sexiness be damned.
When you have a vast, mature ecosystem and a decade and a half of community knowledge to draw upon, even the most obscure use cases tend to have a precedent somewhere. Being able to jump right to a StackOverflow answer to exactly what you're trying to do is, in my opinion, a highly underrated feature of legacy web technology.
When you have a vast, mature ecosystem and a decade and a half of community knowledge to draw upon, even the most obscure use cases tend to have a precedent somewhere. Being able to jump right to a StackOverflow answer to exactly what you're trying to do is, in my opinion, a highly underrated feature of legacy web technology.
I’ve seen the code of Wordpress and would not touch the spaghetti cluster-f that it is.
I won’t even speak of the ecosystem built on the above principles.
All I can say is that a 1-click install does translate to popularity :)
I won’t even speak of the ecosystem built on the above principles.
All I can say is that a 1-click install does translate to popularity :)
> Do people still use jQuery?
A ton.
jQuery is still holding up the client side code of a lot of projects I've worked on and doing a pretty decent job at it.
Sure they could be rewritten to not use it but there really hasn't been a business reason to do it.
Though I personally wouldn't use it on a new project moving forward that's for sure.
A ton.
jQuery is still holding up the client side code of a lot of projects I've worked on and doing a pretty decent job at it.
Sure they could be rewritten to not use it but there really hasn't been a business reason to do it.
Though I personally wouldn't use it on a new project moving forward that's for sure.
> Do people still use jQuery?
All the time.
> This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll.
The official replacements for the stuff jQuery does tend to be verbose and non-orthogonal, as compared to the much more unified and consistent API of jQuery.
All the time.
> This has been rolled into the Javascript document api via document.querySelector, and document.querySelectorAll.
The official replacements for the stuff jQuery does tend to be verbose and non-orthogonal, as compared to the much more unified and consistent API of jQuery.
It is still bundled in WordPress and WP is still most popular CMS (30% sites on the web runs on it)
It is not necessary to use jQuery when you build site but tons of tutorials on the web is using it so people does.
Plus wp-admin still loads jQuery for itself so it is in use even unnoticed.
It is not necessary to use jQuery when you build site but tons of tutorials on the web is using it so people does.
Plus wp-admin still loads jQuery for itself so it is in use even unnoticed.
I write a lot of B2B apps that have tabular data views. For all of its quirks, DataTables (https://datatables.net) does a great job and with the right plugins offers all the features my customers expect (re-ordering/resizing columns, column based search, fixed headers, fixed columns, item selection, etc.) DataTables requires jQuery.
Lots of other vanilla JS table plugins out there but I can't find one with all of those features that work when they are all on.
Lots of other vanilla JS table plugins out there but I can't find one with all of those features that work when they are all on.
I dropped it a long time ago for similar reasons to only using selectors. It was not worth adding the extra request and execution time for what was really now a vanilla feature.
> Do people still use jQuery?
Oh yes. Very much so.
Oh yes. Very much so.
Every day I do.
Granted I don't so much as use it as I fix it / change it.
Anything new is just vanilla as far as the legacy systems go. But those legacy systems pay the bills...
Granted I don't so much as use it as I fix it / change it.
Anything new is just vanilla as far as the legacy systems go. But those legacy systems pay the bills...
>"Also for me, along with I'm sure many others, keeping state within the DOM has fallen out of favor of more comprehensible state management inside of JS (like React Hooks, Redux"
In my opinion using React / Redux combo for state management is a poor choice. So to each their own. The arguments like: everyone else including my cat does that do not make really it any better in my eyes.
In my opinion using React / Redux combo for state management is a poor choice. So to each their own. The arguments like: everyone else including my cat does that do not make really it any better in my eyes.
> there are rowser compatibility issues that jQuery solved
Current browser support[1] isn't really _that_ great. I know it used to be, but I'm not sure that's a legit selling point these days. Not that it's bad, but I hear that argument come up a lot.
[1]: https://jquery.com/browser-support/
Current browser support[1] isn't really _that_ great. I know it used to be, but I'm not sure that's a legit selling point these days. Not that it's bad, but I hear that argument come up a lot.
[1]: https://jquery.com/browser-support/
I still use it all the time because document.querySelector is nowhere nearly as good as $, and it's extremely verbose to create a nested tree of nodes in vanilla JS.
I've really forgetten how to do things without jQuery. If anyone knows a framework that is less verbose than jQuery please tell me!
I've really forgetten how to do things without jQuery. If anyone knows a framework that is less verbose than jQuery please tell me!
Every single WordPress blog ships it by default.
I would not start a greenfield project based on it today, sure, but it is used by a truly staggering amount of sites today, so having it get updates in the form of security fixes and some additional functionality benefits a large part of the web.
I would not start a greenfield project based on it today, sure, but it is used by a truly staggering amount of sites today, so having it get updates in the form of security fixes and some additional functionality benefits a large part of the web.
I use it extensively to maintaining our apps ui which has coded with old fashioned Backbone, Underscore and Jquery. our UI is working and we do not see need to re-engineer/refactor it to go to newer frameworks just for the sake of it.
> What is the current use-case for jQuery?
WordPress ships with it, so using jQuery often doesn't require any extra footprint. I still prefer vanilla calls for admin-only code, but jQuery has better compatibility for user-facing pages.
WordPress ships with it, so using jQuery often doesn't require any extra footprint. I still prefer vanilla calls for admin-only code, but jQuery has better compatibility for user-facing pages.
I use it primarily because it provides an easy interface for ancestor, descendant utilities. But I'm also not doing this in a FT setting, just for side projects.
Still use jquery. Just look at any of the "you don't need jquery" sites to see how verbose even modern JS is for many simple dom manipulation tasks.
There are still a ton of legacy sites that use it. New development? Don't know, but the last 2 companies I worked for had massive systems written in JQuery.
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.
Browser compatibility issues can be resolved with Babel and as such fulfills the need of jQuery and allows me to just write javascript.
I use it for my landing page in countingcarbons.co
Yes, absolutely.
The use case: a small CraftCMS-driven site using a bunch of long-lived jquery plugins and almost no custom JS.
Also, no need for transpiring or bundling.
It is wonderful.
The use case: a small CraftCMS-driven site using a bunch of long-lived jquery plugins and almost no custom JS.
Also, no need for transpiring or bundling.
It is wonderful.
jQuery is bundled in WordPress and many of the plugins so I guess there are a few sites still using it :)
IMHO, if jQuery adds support for the virtual DOM, it will be more attractive
[deleted]
Ajax, foreach, Datatables, small but perfect reasons to use it.
Legacy systems, probably.
I read, Ember.js would depend on it.
I read, Ember.js would depend on it.
Makes life lot easy....
Wordpress.
Daily.
I'm a happy jQuery/Bootstrap user @ https://forwardemail.net.
The site scores ~100% on Lighthouse and PageSpeed Insights and is ranked #1.
Open-startup @ https://forwardemail.net/open-startup!
Completely open-source too @ https://github.com/forwardemail
The site scores ~100% on Lighthouse and PageSpeed Insights and is ranked #1.
Open-startup @ https://forwardemail.net/open-startup!
Completely open-source too @ https://github.com/forwardemail
Yes but if you’re not using the latest JS framework how do you get girls.
This. I was a happy Rails dev but html over the wire wasn’t cutting it at the club anymore. So I had to switch to React and now I’m married.
Just kidding. My wife loves Rails.
Just kidding. My wife loves Rails.
Jokes on you, html over the wire is HOT NEW SH*T.
https://hotwire.dev/
https://hotwire.dev/
server-side blazor does similar.
never checked out web dev with dotnet, but maybe I will check out blazor I keep hearing cool things
You get a girl by going places where girls congregate at a similar or higher percentage to guys. Took me a while to figure that out... Anyway, I understand sarcasm, too.
Upvote. Made me literal lol.
Super cool. I really like that you can also reply using this service to each individual inbox. Like a universal inbox but not married to any specific client/app. Maybe suggest making that a little more easier to learn on your marketing homepage.
For your current users, are you seeing them use this more like the demo gym owner video or for other use cases? Thanks
For your current users, are you seeing them use this more like the demo gym owner video or for other use cases? Thanks
So many cases. Some are using this on hundreds of sub-domains. I hope to launch SMTP and regex support soon. Then... it has final form, power level over 9000.
From your FAQ
> No. Prices will never increase. Unlike other companies, we will never shutdown our service either.
How can you guarantee this?
> No. Prices will never increase. Unlike other companies, we will never shutdown our service either.
How can you guarantee this?
There are only two ways I think this can work.
Their price completely covers every user signed up at any scale. If they lose all but 1 customer, that customer can keep the lights with just their subscription.
The other is that company has such a large warchest it'd be impossible to run out of money.
Their price completely covers every user signed up at any scale. If they lose all but 1 customer, that customer can keep the lights with just their subscription.
The other is that company has such a large warchest it'd be impossible to run out of money.
I would not start this business if I could not keep it going. Period. Even beyond my lifetime. I keep things simple - when I started I had so many struggles, and wish something like this existed. I have contingency plans in place if something happens. My philosophy is outlined in the documentation for Lad.
Do you use automatic translation? At least the German version feels a bit odd.
Yeah, Google Translate via the npm package "mandarin" I made @ https://www.npmjs.com/package/mandarin. I planned to hire curators to go through the JSON files and clean it up - though I'm incredibly surprised that open source contributors have come forward (sometimes for their first time doing a PR) to submit fixes to locales. I give them free service for several years for their help.
Wow 15k??? That's impressive. I use another email forwarder but haven't been happy with it, maybe I'll switch.
Nice open start up page! Congrats on success, will be signing up for the free plan with my domain!
Offtopic but thanks for launching this.
A happy customer.
A happy customer.
Very glad to have you Tycho.
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 this on a jQuery release, but May the 4th be with you! A short time ago in a galaxy exactly like this one, we released jQuery 3.5.0.
Release notes are also very well thought out and their philosophy is to "move slowly and not break things". I admire that. They go to great extent to provide help about how to deal with breaking changes. Ends with a section thanking the contributors.
Super nice people.
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 this on a jQuery release, but May the 4th be with you! A short time ago in a galaxy exactly like this one, we released jQuery 3.5.0.
Release notes are also very well thought out and their philosophy is to "move slowly and not break things". I admire that. They go to great extent to provide help about how to deal with breaking changes. Ends with a section thanking the contributors.
Super nice people.
> 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.
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.
Speaking of nice developers, Reaper DAW developers are giving away temp license and in return only asks the user to wear mask. Warmed my heart to see it.
JQuery and reading Resig's book and viewing the source code are responsible for lifting me from horrible dev to below average dev:-)
I learned to extend the library and understood to create some minimal libraries for myself.
It can be very useful to this day and is almost a ballerina when comparing the bloat of other frameworks or library stacks.
You never know maybe the come up with something better than react.
I learned to extend the library and understood to create some minimal libraries for myself.
It can be very useful to this day and is almost a ballerina when comparing the bloat of other frameworks or library stacks.
You never know maybe the come up with something better than react.
> reading Resig's book
I hope you mean the JS ninja one because I just bought it week. Do you remember a particularly impactful section?
I hope you mean the JS ninja one because I just bought it week. Do you remember a particularly impactful section?
I consider secrets of the javascript ninja to be one of if not the best books on javascript. The section on functions and closures are a must read.
The one I have meant was "jQuery in action", at the time that left a bigger impact as far learning is concerned. The jQuery team had promises and other things long before they became part of the standard API, he explains how they made it work.
However, secrets of a js ninja is very good as well, touches newer things like generators and es6, es7 features.
However, secrets of a js ninja is very good as well, touches newer things like generators and es6, es7 features.
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 free without using its full-blown SPA framework. However you do need master a lot more concepts comparing to jQuery.
React/Angular are both overkill for 90% use cases, unless you're doing a serious SPA that is.
For me it's between jQuery and Vuejs these days, I learn both, one reason I worry about jQuery is that it's losing some steam and the development is not very active. Still I'm excited about this new release.
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 free without using its full-blown SPA framework. However you do need master a lot more concepts comparing to jQuery.
React/Angular are both overkill for 90% use cases, unless you're doing a serious SPA that is.
For me it's between jQuery and Vuejs these days, I learn both, one reason I worry about jQuery is that it's losing some steam and the development is not very active. Still I'm excited about this new release.
I remember the first time I used VueJS after being a long time JQuery developer. It was incredible how much power VueJS and similar frameworks put in your hand using such simple concepts. Not having to add event listeners to everything and manually re triggering things is revolutionary.
I was building dynamic UIs with ease that would have been massive and bug prone jobs in jquery.
I was building dynamic UIs with ease that would have been massive and bug prone jobs in jquery.
do you use the full spa framework, or just use vuejs like jquery(use script to include it in each page)? whenever you have to do vuejs full SPA framework it comes with quite some concepts which takes (a lot) time to digest and stay up to date.
For that project I just imported it on to a single page to build one particularly complex (for me) feature. It was a little news letter builder which generated a JSON string for the config and saves it to the db. The backend could then use that config to send emails.
I was getting nowhere with jQuery. My final solution in vue was tiny compared to just setting up all the event listeners on the first try.
I was getting nowhere with jQuery. My final solution in vue was tiny compared to just setting up all the event listeners on the first try.
> 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.
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.
Looks pretty active to me https://github.com/jquery/jquery/milestone/7?closed=1
Thanks! I will lean towards jquery more than vuejs as long as jquery is actively developed.
For those wondering, JQuery is still used on the majority of web sites in the world apparently [1]
I'm not sure how the data is run, but it's quite massive share however you cut it.
JQuery is still in it's foundational phase, it's still a 'core' thing, it's not remotely legacy yet.
[1] https://almanac.httparchive.org/en/2019/javascript
I'm not sure how the data is run, but it's quite massive share however you cut it.
JQuery is still in it's foundational phase, it's still a 'core' thing, it's not remotely legacy yet.
[1] https://almanac.httparchive.org/en/2019/javascript
jQuery taught me how to write JavaScript frameworks. John Resig, the founder of jQuery, wrote a book called "Secrets of the JavaScript Ninja" was back then really a mindbender.
Function.prototype.toString() is really the craziest thing I know to date regarding JS. Heavily used in earlier versions of jQuery according to the book.
Function.prototype.toString() is really the craziest thing I know to date regarding JS. Heavily used in earlier versions of jQuery according to the book.
Please elaborate about toString() ?
The toString() method returns a string representing the source code of the function.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
That's pretty neat. Thanks for the link.
If called on a Function it returns the source of the function, which allows for all sorts of meta programming.
If memory serves, a real world example was Angular doing a toString then injecting dependencies before calling eval on the new code.
To be honest, I don’t know that there’s ever a good reason to use it in production as it almost always involves performance and security problems.
To be honest, I don’t know that there’s ever a good reason to use it in production as it almost always involves performance and security problems.
> involves performance [...] problems
Except when it solves them! https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...
Except when it solves them! https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...
I once used it for a proof of concept for computer worm type message on a sort of message board. Used to re-generate the source code to be added to new messages.
Yep. We used to use this for some hacks back before AST libraries were a thing, mainly because Function.prototype.toString() preserves comments.
function foo() { /* a comment! / }
console.log(foo.toString()); //-> "function foo() { / a comment! */ }"
function foo() { /* a comment! / }
console.log(foo.toString()); //-> "function foo() { / a comment! */ }"
> We still have our eyes on a jQuery 4.0 release, but until then we will continue to support the 3.x branch and address important issues.
There seems to be milestones for 4.0 setup on Github: https://github.com/jquery/jquery/milestone/7
This caught my eye too. What could they be cooking?
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.
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).
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.
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.
I think jQuery is amazing, but one thing that I've found over the years is that the real killer for it was CSS animations becoming simpler to use and more widespread in terms of support.
The final thing I used to reach for jQuery for was animation support, but that need is by and large gone now. AJAX/JSONP is good there, but to be honest it's not something that needs a wrapper these days.
Glad to see the library is still updated, though - for sites that might not have a budget to upgrade, knowing it's still got support must be nice.
The final thing I used to reach for jQuery for was animation support, but that need is by and large gone now. AJAX/JSONP is good there, but to be honest it's not something that needs a wrapper these days.
Glad to see the library is still updated, though - for sites that might not have a budget to upgrade, knowing it's still got support must be nice.
CSS animations are a pain-inducing non-starter for thousands of recurring use cases.
Example: Using Javascript to SHOW a modal, but then relying applying addClass('animate') using CSS animations to transition that modal (eg: bottom of screen to center, while fading in) are nearly impossible without tons of hackery. The animations do not render.
Hence jQuery animation calls.
Example: Using Javascript to SHOW a modal, but then relying applying addClass('animate') using CSS animations to transition that modal (eg: bottom of screen to center, while fading in) are nearly impossible without tons of hackery. The animations do not render.
Hence jQuery animation calls.
CSS animations are a necessity if you want any kind of performance on mobile browsers and older phones.
They are. But I still wouldn’t turn to jquery to solve this particular problem.
What you’ve described is actually pretty simple to do with CSS Animations. Just not with CSS Transitions, which is what people usually use.
I still believe that jQuery is the best tool for the job if you're creating a small web application and don't want to learn an entire new framework.
YES this 1000X - I love React and choose to use it regularly and willingly. I am forced to use Angular quite a bit for my day job. While both of these libraries have their place not everything needs to be a single page app. Using server side rendered pages and sprinkling a little JS to add some DOM scripting and dynamic UX should not require adding React or Angular. It many cases using jQuery is good enough.
I no longer use jQuery nowadays due to React/Stimulus but one nice thing about jQuery is ability search for an element in a DOM note and append html. You can do it with raw JavaScript but jQuery API is light years ahead.
For a good reason. XSS is no joke. I even block innerHTML and friends in my apps via empty trusted-types and require-trusted-types-for 'script' CSP.
A lot of people throw shade on jQuery, but it’s extremely powerful and versatile. I’ve built entire apps with just jQuery, Foundation, and POJO classes (and other smaller libraries as needed sprinkled in). This stack is certainly not appropriate for all apps, but for small projects it’s far easier to manage than the overkill that is React or Angular. Sure, you don’t get generators and built-in spec testing or other Enterprise-friendly goodies, but for simple apps that use a REST API, jQuery sure as hell provides a nice set of tools. And while modern browsers support the query selector methods that sort mimic jQuery, this starts to get awfully tedious if you want to do complex DOM manipulation and you’ll find yourself writing functions that start to look a lot like jQuery. Why reinvent the wheel in order to save a few kb of space and pride yourself on having a “100% jQuery-free app!” when modern apps already load much larger libraries or minify and package the entire app’s code?
I think a lot of the comments in this thread that are critical of SPAs are thinking about them wrong.
SPAs aren't (shouldn't be) a replacement for websites.
They are a fantastic option for replacing native apps (PWAs).
Moving from walled garden native apps to the open web is good for everyone except the app stores.
SPAs aren't (shouldn't be) a replacement for websites.
They are a fantastic option for replacing native apps (PWAs).
Moving from walled garden native apps to the open web is good for everyone except the app stores.
Probably because many websites today are written as SPAs. Many of these modern frameworks are also pushed as to be used for websites.
Is jQuery worth learning in 2021?
I started studying web development 2 years ago and I never feel the need to reach for jQuery. From the very beginning I wanted to get a solid knowledge of front end technologies without libraries or frameworks. After working for some time in this field I do feel the need for stuff like Bootstrap, Tailwind, Vue/React, but not jQuery. What's is selling point considering that DOM manipulation and HTTP requests has improved over the years in vanilla JS?
I've read through most of the comments and I see a lot of:
I'm used to jQuery syntax
$ is shorter than document.querySelector
jQuery provides better support for older browsers
First two aren't really meaningful to me, and for the last one, I'd say if you care about browser support you are probably compiling your code anyway.
I'm not familiar with using jQuery but I work with people that use it and I've realized it promotes some bad practices like:
Repeated DOM node selection due to the ease of use of $(selector)
Manipulation of CSS that should be done in CSS
jQuery is not JavaScript. Some people use it as a crutch and it shows
So my main question, if someone is comfortable with vanilla JS, does it make any sense learning jQuery?
I started studying web development 2 years ago and I never feel the need to reach for jQuery. From the very beginning I wanted to get a solid knowledge of front end technologies without libraries or frameworks. After working for some time in this field I do feel the need for stuff like Bootstrap, Tailwind, Vue/React, but not jQuery. What's is selling point considering that DOM manipulation and HTTP requests has improved over the years in vanilla JS?
I've read through most of the comments and I see a lot of:
I'm used to jQuery syntax
$ is shorter than document.querySelector
jQuery provides better support for older browsers
First two aren't really meaningful to me, and for the last one, I'd say if you care about browser support you are probably compiling your code anyway.
I'm not familiar with using jQuery but I work with people that use it and I've realized it promotes some bad practices like:
Repeated DOM node selection due to the ease of use of $(selector)
Manipulation of CSS that should be done in CSS
jQuery is not JavaScript. Some people use it as a crutch and it shows
So my main question, if someone is comfortable with vanilla JS, does it make any sense learning jQuery?
If you’ve been doing web dev for 2 years you can pick up jQuery in an evening. Go do it. You might never need it but learning is fun and understanding what jQuery is instead of hearing about it’s flaws on HN is a good idea.
I sometimes look at react, and these modern frameworks and wish they had a same nice API as jQuery. I still profoundly remember how much simple it was compared to Prototype.js, and how simple it was to do a zebra stripes on table. I am still looking for that next piece of revolutionary simple library that will bring the joy of jQuery with modern concepts and simplicity.
Jquery is awesome. I still use it in all my web projects.
[deleted]
I super love jQuery. The proliferation of SPA is super unfortunate, maybe one day the pendulum will swing back to server side HTML with lighter JS for progressive enhancements.
React is trying that with server rendered components
Crazy to think what legacy jQuery and others left. Now I am using React and the usual lib stack.
But I remember using jQuery, pug (or jade), browserify, bower... that was what 5 to 6 years ago?
But I remember using jQuery, pug (or jade), browserify, bower... that was what 5 to 6 years ago?
jQuery solved (and solves) a lot of browser inconsistencies (fewer now than before) and I guess a lot of older codebases still rely on it, so I am glad to see it is still moving forward. However, jQuery has a built in problem in modern web development, as the DOM-functions that now makes it obsolete, as in it does not solve the more complex problem of state management and scoping of components. For some sprinkling on top of server side rendered web pages I guess it still has some value if you need to cater for older web browsers, but for those who build applications that handles state and components for the current setup of browsers it is not needed in your toolbox any more when bootstrapping new projects. However, it helped us getting to a point where we could rely on solid libraries and focus on building better user experiences. I am glad it still gets updated but will probably not write "jQuery-code" anymore in my professional life.
It’s definitely on the way to becoming legacy tech, but jQuery was a great library back in the day, like, history book great.
It played a big part in the Web 2.0 days, could be argued that if it wasn’t for jQuery we wouldn’t have the modern web at all, or if so, it would be a lot worse.
It played a big part in the Web 2.0 days, could be argued that if it wasn’t for jQuery we wouldn’t have the modern web at all, or if so, it would be a lot worse.
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.
Bootstrap 5 dropped jquery but apparently it’s still possible to include it for tooltips and modals.
[deleted]
I know jquery is still in use a lot all over the web, but are people still starting new projects with it?
Yes. It's fine for progressive enhancement of server-side-rendered webpages.
I think it is still widely adopted in CMSs like Drupal and Wordpress and they have a big market share. Jquery will not die soon even if it is not the first choice for starting a new project. It's been years since the last time I used it.
[deleted]
Absolutely. Starting most new projects with something like React/Vue is complete overkill and jquery makes adding small incremental JS functionality to your app a breeze.
I can't speak for React, but I found adding VueJS was perfect for adding JS functionality incrementally to a section of a site. See my other comment on this thread on using it to create a dynamic contact form to an otherwise static site.
I've had to learn it at a new job after starting my career making UIs with React. It's not so bad.
jQuery is also an amazing educational tool for teaching people to program in steps, learning the native DOM methods and then being introduced to jQuery has been really fun to see light bulbs going off for new students.
It’s still not dead??
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 solved with smaller footprint libraries like lodash.
Also for me, along with I'm sure many others, keeping state within the DOM has fallen out of favor of more comprehensible state management inside of JS (like React Hooks, Redux...etc.)
What is the current use-case for jQuery? I'm curious from hearing it's current users answer this.