Ask HN: Is jQuery on its way out? Due to the proliferation of many advanced JS libraries such as React and Angular, do you think jQuery is on its way out? Is becoming good at jQuery a waste of time? |
Ask HN: Is jQuery on its way out? Due to the proliferation of many advanced JS libraries such as React and Angular, do you think jQuery is on its way out? Is becoming good at jQuery a waste of time? |
jQuery was an amazing step forward but it's almost always better to use standards based options and those are now available for much of jQuery's functionality.
I would say it's done. ES6 javascript replaces a lot of its functionality as well.
I switched from jQuery to Vue/ES6 (last March) and would never contemplate switching back. The difference is like night and day.
The next stage I'm thinking about is moving over to TypeScript for more productivity and safer development.
Check this out if you haven't already:
https://github.com/Microsoft/TypeScript/wiki/Type-Checking-J...
Even if without any annotations, type inferencing can catch some bugs for you.
Not everyone is building web applications, sometimes we just want a simple tool to do a single job.
jQuery has many convenience features such as chaining, for example: item.addClass('selected').siblings().removeClass('selected'); and you don't have to check for nulls after each selection.
Many functions such as closest() and remove() have no equivalents in IE11, and other things such as replaceWith() and before() are not available even in Edge.
For simple sites it is easy enough to remove jQuery, but for more complex javascript applications, especially apps that have a lot of interactivity, removing jQuery will result in more code, or you will end up writing a lot of utility functions thereby creating your own little clone of jQuery.
A modern version of youmightnotneedquery with, say, features currently supported by 90%+ browsershare would be even more concise. The AJAX JSON request in the first example, for example, is just:
fetch('/my/url').then(response => response.json())
fetch('/my/url').then(response => ...).catch(error => ...)
@keyframes fadeIn {
from { opacity: 0 }
to { opacity: 1 }
}
#el { animation: fadeIn 1s linear; }
Whether or not it's worth becoming good at jQuery is essentially determined by your goals in life, and whether becoming good at jQuery in particular, is in alignment with those goals and also of high importance.
Any time you spend honing one skill is time not spent honing another. You want to be sure to spend your time on the most important things. Figuring out what is important itself becomes a skill to learn.
Pinging HN on whether it's worth learning jQuery is one way to assess importance. But keep in mind, if the people who answer have different goals than you, their answer may not be relevant and may actually be bad advice for your case. This answer included.
Figure out your goals. Find people who have accomplished them. Talk to them directly about what they did and how they did it. Adapt what makes sense to your life.
Finally, be careful of learning something just for the sake of learning. It feels great, but it can actually be procrastination in productivity's clothing. Make sure you are clear on why you are spending the time learning X right now, and be clear on why you are not spending time on learning Y right now.
When you map it out like this, the answer seems obvious that the place to invest your time is in learning the standards.
There's more options, more possibilities. The selectors are a core part of Jquery's strength. As soon as your project requires a bit more complexity in selector needs, that's when Jquery steps up and helps out. That's what I've found anyway.
Similarly, there are now a lot of things you can achieve with vanilla JS (or even vanilla CSS) that you used to only be able to achieve with jQuery, and frameworks like React and Angular are viewed more favorably. But lots of devs of a certain age know jQuery, even if they don't currently use it, and there is something to be said for familiarity. Honestly, if I needed to whip something up in a day, I would probably use jQuery rather than a heavier framework.
Jquery's strength was in its polyfills for older browsers for selecting elements and the like. Since it's introduction, browsers have pretty much replaced all of jquery's functionality intrinsically.
> browsers have pretty much...
No, there's a bunch of selectors and methods that are much easier to work with, read and write using Jquery, IMHO.
This idea of software tools being on the way out is a slippery one. Perl and PHP are both broadly considered to be somewhere between slipping and no longer relevant, yet a close look shows there are still many commercial sites and actively developed frameworks built using those tools. Popularity and recent trends alone are not necessarily a robust guide to utility or futures.
I think the actual medium-term risk to jQuery is not the heavyweight alternatives that you identified. It's that browsers are much better and providing standard and consistent API support for many necessary DOM interactions.
When I need a lightweight solution, I find myself using MDN documentation more often than jQuery documentation. For me, jQuery was much more about providing a single API that was usable across a wide array of browsers. That's less necessary today than it was a decade ago.
All that being said, I don't think jQuery will die out anytime soon. It still has a niche that it can usefully fill for a long time, and still has a ton of existing dependencies that rely on it.
jQuery is not suitable for large application development. It can be useful here and there but not as a foundational layer for an application architecture.
Popular component frameworks such as bootstrap still uses jQuery.
Yes, you can use the native API for some of what jQuery does. but, don't let anyone here fool you - the full API of jQuery has not been completely replaced by the "vanilla" API. And, jQuery's API is still much better designed.
Now, if you're building something Very Large, you don't want to lean on jQuery alone. If you're using a framework whose footprint includes what jQuery does (anything with a virtual DOM and automatic updates, for example), then there's no point in also using jQuery.
There's room for all of the tools. Use the right one for the right job. Do enough front end development, and you'll know which one to pull out when you need it.
However, for building SPAs, jQuery has been eclipsed by Angular and React. And thank god for that, jQuery was always an ill-suited tool for the job. Even bad Angular applications are better than good jQuery applications, in my experience.
I think that vanilla and CSS3 is a better option. Ten years ago there weren't the options. Now all browsers are up to speed and standards compliant there is not the need. It takes less time to learn how to do something properly the vanilla than it does to hack older jQuery code into shape for one's own use case.
If I do something the vanilla way I feel as if I have learned something. When copying and pasting some jQuery module I don't get that feeling.
I still include it because I'm lazy, and it largely plays well with TypeScript.
Is it a valuable skill? Well, probably not! But not because of React or Angular, only because being good at jQuery is easy. Which makes it a less valuable skill and that is why I said if you have a use case for it.
Not to mention, a big part of jQuery success was the short learning curve. While simplicity is its strong point, it is also what makes it less valuable as a skill.
Unlike back-end technologies, front-end technologies have a shorter lifespan. Because of all the design evolutions, redesigning, and front-end optimizations and refactoring which is more accessible and less resource hungry for many businesses. So keep that in mind that probably you are not going to use jQuery in any customer-facing new project.
I started this project one year ago; Jquery never crossed my mind for it.
[2] https://github.com/moment/luxon
- Bootstrap 3.x
- jQuery
- KnockoutJS
because of the following reasons:
- The devices that will be accessing the web app may have older browsers, both desktop and mobile.
- My users will be in geography where network connection is sometimes slow.
- These libraries have been in the wild for very long time and time tested with lot of support available on public forums.
- Very easy to get started.
- As I am not primarily a front-end web developer, I am not in a position to handle various quirks of different browsers; if libraries such as bootstrap, jquery and knockoutjs handle that for me for older devices and browsers then it is useful.
If I had an option to go for a more modern stack, then I would have gone with svelte.technology, unpolyjs and bootstrap.
Example, 'x' and 'No'-answer :
- jQuery / prototypejs / etc...
- Backbone
- CoffeeScript
- Perl, SVN, Java Applets :D
On the other hand you still have 'Yes'-es for some old tech-stack, since it is still acceptable to do a task with old technology. Example, 'x' and 'Yes'-answer :
- Form + POST requests / No javascript
- Pure CSS ( no SCSS, etc... )
- Handlebars, instead of React / Vue / you name it
Creative devs or "mid level" front-enders like myself enjoy its clean syntax and reliable operation. I am VERY thankful for Jquery in how it helped me understand and execute more difficult concepts, and complex interfaces, and gave me opportunity to make better things beyond my vanilla abilities.
End users don't know or care if an app uses it or React/Angular/Vue.
I've built SPAs with it and don't see why that's a problem for others who've mentioned it, but that's because I don't know what specific problems they ran into. I've not run into any.
But, I also use CouchDB as a backend, almost all my app code is JS running in the browser, and I don't use Node.js at all. I still do my server side work in Perl. So I'm not building apps like most are right now.
React/Angular/Vue, etc, might work better for some apps, and/or apps with a zillion users hitting the server a zillion times, but my apps don't have either of those issues to deal with. They barely touch my web server or the CouchDB. All the heavy lifting is done in the user's web browser.
The only real downside to that design approach, if we choose to call it that, is that we don't track every click a user makes, but as a user I really like knowing that.
The best thing about going with jQuery is I didn't really have to learn how to use it. I do that on a need to know basis and generally go to Stackoverflow where I almost always find the best way along with a few other ways to do something.
I'll offer that using a "much smaller, lighter weight library" offers a kind of a false sense of gain. You can use Service Workers to cache jQuery on the client side, or a CDN to deliver it, so it's not really costing you much (or any) bandwidth to deliver it to users, and modern web browsers are not choking on the size of it. I test my apps on a old Raspberry Pi running their latest OS and Chrome and they're plenty fast (very fast).
Here's the thing. I spent about two months looking for the "Best" way to build apps. Most of that time was going over frameworks at TodoMVC.com. When I was finished I didn't have any better idea of what was best than when I'd started, but I did have a clue about what I'd have invest to get up to speed with them, and in most cases it was lot.
So, I decided to instead explore what was the easiest way, and not just for me really, though I don't expect anyone should agree, but just generally speaking I tried to consider that.
I use the Apache web server and CouchDB, PouchDB.js, jQuery, and Bootstrap. It's a pretty amazing feature set those tools provide, and how easy they are to use together.
Almost no one I know does it this way.
Absolutely.
> Is becoming good at jQuery a waste of time?
Unless you are going to be maintaining legacy code, yes.
jQuery is likely diminishing but its death has been somewhat overstated. There's at least two areas that hurt jQuery:
- IE11 is disappearing for consumers (less so in corporations/governments)
- ECMAScript 6 now offers enough conveniences so jQuery isn't as "mandatory" as perhaps it once did.
We still use jQuery with AngularJS, but we also need to support business users so our IE11 share is significantly higher than most consumer sites.
jQuery filled a niche when browsers were less standardized and the DOM was harder to work with. It also came about at a time when people were just starting to play with the idea of web apps, and people could get away with less structured approaches to web design.
Which makes me curious, actually, how basic can you get with Vue and React? I only know the large "boilerplate" versions with Redux and bells and whistles. Anybody prototyping on React/Vue/Angular?
If you're planning to use JSX, you'll need a JSX transpiler and before you know it you're down the Webpack/Babel rabbithole and you get a node_modules folder containing a zillion packages written by a thousand people, of which - statistically speaking - at least a handful will be clinically insane.
But yeah, in principle you can do it (and I have done it).
My current setup is to use Vue for interactivity and frontend axios for ajax. Works pretty well. No compiling/transpiling needed.
Really not true. There is no part of the hiring process at FB that focuses on trying to find PHP (or now — Hack) developers. The main impetus was that there was an existing, large, PHP code base.
Disclaimer: former FB engineer
With Composer that changed and it appears now they are doing a much better job of standards and changes to the language.
With that said, it's not a concurrent system. It's blocking and that's a problem for modern Web languages.
I do think PHP growth is on the way down... but slowly.
What came out of it was PHP 7 and the gap closed significantly. There were even rumblings about a PHP JIT complier. So I would say the impact was a good one.
As for PHP growth, what's there to replace it? Golang, Exlir, Node, Crystal, Ruby, Python? They all have their own pros and cons.
With laravel being a great framework and much easier for developers to use rather than symfony. I would say the future of PHP has never looked better.
PHP has had async for a while (https://reactphp.org/) and more recently an extension (https://www.swoole.co.uk/) had brought PHP async to equal or better performance to NodeJS (https://gist.github.com/nkt/e49289321c744155484c)
I recently started working with NodeJS more intensively (heavy lifting for dozens of microservices for complex app/data). While there are many nice features NodeJS has, most people don't understand what PHP can do. In my opinion PHP is superior for many backend application and the "snob factor" is one of the reasons it's not more known beyond wordpress.
The main thing it provides is a sane toolset for what I was already slowly moving towards, which was templates in script tags (grabbed through jQuery), and my own home rolled templating in JS (it's just a few lines for something minimal). I get some JS from the server (or serve it on the page), and use a JS class to build the representation for display, but this allowed me to easily build the initial page and also get updated without a complete page reload and reliably update the page.
Vue is basically the same thing, but taken a few generations farther. You have a data structure, you define how to build the HTML from the data structure, and Vue tracks the data so if you change one five levels deep in the data structure, the page just updates accordingly (and it only updates the things that change, so half entered forms/text boxes don't lose all their state.
It's nice to just have to serve JSON, or a minimal HTML page with some JSON data in a script tag. No mixing Perl templating, and HTML, and JS anymore. At least for a select few new things I've deployed. It's not like I can just replace everything. I also forego the whole NPM and deployment stuff, and just include Vue with a script tag, and write my components either on the page, or in a JS file (or set of files) I can load, depending on whether the components have any use outside the page I'm writing them for. Dead simple.
If you haven't tried it Vue (and you very wel may well know everything I just mentioned about it already), I suggest you do one of the quick online tutorials to get an idea. It's actually a pretty cool idea (and since it's hard to get away from using JS anyway, you at least get to cleanly separate the front-end from the back-end).