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?
33 comments
The best advertisement for jQuery, ironically, is this site: http://youmightnotneedjquery.com/ Look at how simple things are in the left column, and how much more code is needed in the right column.
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.
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.
That site is from 2012. It defaults to IE9, and the latest version of IE listed is IE10, which was EOLed in 2016. replaceWith() and prepend() are included in Edge 17 (released Apr 2018).
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:
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; }
Feel free to disregard this advice, I don't do anything in javascript.
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.
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.
Sure, but one can learn a great deal about Jquery in a short time. It's more accessible than the frameworks mentioned in OP.
Affirmative. It's not just that there are advanced application frameworks like React and Angular -- it's also that browsers are more standards compliant, and standard APIs have evolved in recent years to cover much of the gap that jQuery once usefully filled.
I made a diagram of the way I think about it here: https://plectica.com/m/ADUNN80H4
When you map it out like this, the answer seems obvious that the place to invest your time is in learning the standards.
When you map it out like this, the answer seems obvious that the place to invest your time is in learning the standards.
Jquery selectors are still more powerful, even if vanilla is faster.
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.
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.
Not a perfect analogy, but PHP was on its way out for a while and probably would have gone all the way out -- if it had not been for one very high-profile company that essentially made it usable at scale. And the reason it did so was because even though PHP had little cachet, it was easy to hire PHP devs.
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.
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.
> And the reason it did so was because even though PHP had little cachet, it was easy to hire PHP devs.
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
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
Obviously not now. But the choice to start with PHP and not quickly migrate away did have something to do with the fact that it was easy to find people familiar with it, and easy for people not familiar with it to pick it up.
I would argue that Facebook's work had little impact on the "scalability" of PHP. I don't see people adopting HipHop (HHVM) in huge numbers. The problem with PHP was it's standards body wasn't doing a good job of keeping the language consistent and it lacked a package manager where Ruby, Python and Node all had solid standards bodies and it was driven by having package management.
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.
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.
Actually HHVM had a huge impact. Having competition is always a good thing. It forced the devs to go into overdrive and improve the product.
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.
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.
>it's not a concurrent system. It's blocking and that's a problem for modern Web languages.
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.
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.
Even if most people don't use HHVM, I claim it increases use because it allays fears about what happens if your project / company does need scale.
Wordpress is a big reason a lot of people will still use PHP. Also Wikimedia to some extent.
So to complete the thought, at which age should we expect developers to know nothing about new technologies? Also, are you involved in the hiring process at your company?
Becoming good at jquery is a waste of time, yes, unless you have inherited a legacy project built in it.
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.
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.
If learning a bit of Jquery (which is not hard) helps you get something from concept to client's screen faster, then it has its place.
> 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.
> 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.
It is quick and easy to access and work with the DOM using jQuery. Both React and Angular are heavyweight libraries that require a lot of bondage and discipline to work as intended. React is from and linked to Facebook and Angular is from and linked to Google. Both of these social media ad companies are broadly considered to be corrupt and potentially best broken up by force of law. There is not particular corporate agenda or threat of breakup hanging over jQuery.
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.
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.
> It is quick and easy to access and work with the DOM using jQuery
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.
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.
Both angular and react are MIT licensed libraries that could be forked at any time by any one. Furthermore these useful frameworks have nothing to do with the business model of Google and Facebook.
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.
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.
[deleted]
Yes its on its way out. I don't think learning it is a waste of time if you touch legacy stuff. jQuery still does some things better than DOM, but if all you need is XHR and css selectors, you don't need it anymore.
Popular component frameworks such as bootstrap still uses jQuery.
Popular component frameworks such as bootstrap still uses jQuery.
[deleted]
Honestly, yeah. Whereas in the past I would reach for jQuery for low-effort "spicing up" of a webpage with javascript, now I reach for Vue. It's very easy to just include Vue in the header, plop down a bit of markup, a bit of JS, and you're on your way, plus it offers a bridge from there into a more full-featured Vue application. It's almost as lightweight as jQuery, and it's not work you have to "undo" later if you wanted to work towards a SPA or more-advanced functionality.
There will always be a use for jQuery. Just not every use. If you're looking to make simple, imperative changes to the DOM in a web page, and not worry about what browser it's happening on, it's still the go-to choice.
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.
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.
I think jQuery is still a relevant tool for building dynamic websites—animations, carousels, pop-ins, etc.
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.
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 jQuery is still a relevant tool for building dynamic websites—animations, carousels, pop-ins, etc.
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 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.
You could take some time to understand jQuery it is not that big or complicated. It might be on its way out, but it will be around long enough to be worth the effort in my opinion.
If catering to older browsers, developers that aren't familiar with JS build/release tools or the latest fad/buzz then jQuery is still viable. jQuery used to be the easiest way of getting things done but now it is more of a tool. I loved jQuery but I have seen it abused so bad that it has become a design smell if the page/service gets too big. If you are doing simple things then jQuery will be ok but if it is a really complex page/site then using something like Vue or React may be appropriate just for ease of diagnosing problems/reasoning.
GitHub has a good post on removing jQuery: https://github.blog/2018-09-06-removing-jquery-from-github-f...
I still include it because I'm lazy, and it largely plays well with TypeScript.
I still include it because I'm lazy, and it largely plays well with TypeScript.
Becoming good at jQuery is reasonably quick and easy. If you have a use case for it, Yes! Why not? (ex: legacy stuff)
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.
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 think it’s worth learning FROM jQuery.
https://youtube.com/watch?v=i_qE1iAmjFg
https://youtube.com/watch?v=ARnp9Y8xgR4
https://youtube.com/watch?v=i_qE1iAmjFg
https://youtube.com/watch?v=ARnp9Y8xgR4
I use Vue[1], luxon[2], markdown-it[3], Vue Form Generator[4], and a localhost "backend" written in Go. (No browser-local storage, thank goodness.)
I started this project one year ago; Jquery never crossed my mind for it.
[1] https://vuejs.org/v2/api/
[2] https://github.com/moment/luxon
[3] https://github.com/markdown-it/markdown-it
[4] https://github.com/vue-generators/vue-form-generator
I started this project one year ago; Jquery never crossed my mind for it.
[1] https://vuejs.org/v2/api/
[2] https://github.com/moment/luxon
[3] https://github.com/markdown-it/markdown-it
[4] https://github.com/vue-generators/vue-form-generator
I recently made a decision on the following front-end stack:
- 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.
- 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.
Well my litmus test regarding outdated way of doing stuff is the answer of the question "If I start a new project today, would I use 'x'?". Answer "no" means the technology is fading even for simple use cases.
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
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
Only you can decide what tools are best for your projects. Jquery is javascript. It's a clever tool that often results in better, clearer, readable syntax.
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.
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.
I still use jQuery and won't be ditching it anytime soon.
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.
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.
Most my work is generally in Mojolicious (with or without an Nginx instance proxying and providing SSL support, but I've found with Nginx easier), jQuery and Bootstrap. A while back I bit he bullet and learned a bit of Vue... and I have to say, it's pretty nice, even if I just use it as a way to build the page.
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).
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).
Amen. It sounds like you have a good toolset to me.
> Due to the proliferation of many advanced JS libraries such as React and Angular, do you think jQuery is on its way out?
Absolutely.
> Is becoming good at jQuery a waste of time?
Unless you are going to be maintaining legacy code, yes.
Absolutely.
> Is becoming good at jQuery a waste of time?
Unless you are going to be maintaining legacy code, yes.
I'd argue Lodash/Underscore.js is a direct comparable to jQuery rather than React/Angular.
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 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.
Well hopefully Javascript will be on it's way out thanks to WebAssembly. Any tool that fills a critical gap in a worldwide ecosystem should be admired, but at the end of the day every tool should eventually be replaced as we evolve the craft.
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.
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.
Actually I still feel jQuery is still an amazing lib (and philosophy) precisely because it is not an all or nothing tool. I recently (as a non webdev) found myself overwhelmed with react/vue. I simply chose to go jQuery with decent modularization of components and got the job done. Now yes my "modularization" will asymptomatically look more and more like React as I consider the more and more usecases that React supports, but the learning curve is pretty for me.
I think for creating a messy Proof of concept, or creating a simple tool with minimum UI and complexity, I will always be grabbing JQuery. It's just so simple and I've got all of it memorized for so long...
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?
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?
React itself can easily be used as a drop-in much like jQuery, but then you will be using plain Javascript syntax, which is a bit less readable than JSX.
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).
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).
Angular and React is not what competes with jQuery. Its VueJS. Why? Because unlike React and Angular, you can use Vue in small dosages, ala jQuery. You dont need to write the entire HTML part as JS or JSX. Just insert Vue in parts you want to make "dynamic".
My current setup is to use Vue for interactivity and frontend axios for ajax. Works pretty well. No compiling/transpiling needed.
My current setup is to use Vue for interactivity and frontend axios for ajax. Works pretty well. No compiling/transpiling needed.
Yes, we deprecated it many years ago, only used for select2 and datetime picker. People should learn the browser nowdays, not jquery
There is also the option of using a much smaller, lighter weight library to handle ajax (where the standard based approach still has some limitations) and using standards for everything else.
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.
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.
You forgot to mention Vue. ;)
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.
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.
> 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.
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.
Sometimes you want some simple "glue" for very simple dynamic web pages / effects (e.g. Jekyll homepages). In my experience JQuery is the best for that followed by Vue.js by adding a one liner and then you can start using it.
I would say everything jquery does is now supplanted by a better alternative. So unless you need libraries that depend on it I would not include it in any new project.
If you work on legacy stuff, you'll need to be able to at least modify jQuery. Newer stuff and greenfield projects won't use it.
Jquery still strikes me as being much faster to get up and running than react. Is the issue it’s speed compared to vanilla js?
jquery is something you can throw in quickly onto a page and have a few useful helper functions.
Not everyone is building web applications, sometimes we just want a simple tool to do a single job.
Not everyone is building web applications, sometimes we just want a simple tool to do a single job.
I recently used jQuery to parse an XML file. Easier than vanilla JS