Ask HN: Is jQuery still a thing?
With so many "new" js frameworks (like React, Vue.js, Mithril,..) and js-like languages (Elm, Dart, TypeScript,..) is classic jQuery still taken as something good and recommended to use for the front-end? Or should it by replaced by something else? Maintainability and minimum of errors are more relevant for me than raw speed or "hype".
89 comments
Absolutely. Most projects that would be considered "websites" rather than "web applications" are likely candidates for jQuery. It's still extraordinarily useful.
This.
Pick the right technology to solve the problem you're trying to solve.
Some inexperienced devs just try and cram every single technology they've ever heard of into a simple project when it's not needed. You're not at Facebook's scale just yet where many of these abstractions are anything other than an extra complication and a waste of time and future liability.
Your average simple website for a law firm, bike repair shop, or a pizza delivery place doesn't need 93 different libraries/frameworks/technologies/build systems/etc to show/hide a couple products or submit a form or two. You can go pretty far with just jQuery in many cases.
It gets a little more complicated as you go from simple site to more complex site to app to more complex app, but I see too many developers trying to be trendy and over engineering simple problems and wasting a lot of time and money.
Pick the right technology to solve the problem you're trying to solve.
Some inexperienced devs just try and cram every single technology they've ever heard of into a simple project when it's not needed. You're not at Facebook's scale just yet where many of these abstractions are anything other than an extra complication and a waste of time and future liability.
Your average simple website for a law firm, bike repair shop, or a pizza delivery place doesn't need 93 different libraries/frameworks/technologies/build systems/etc to show/hide a couple products or submit a form or two. You can go pretty far with just jQuery in many cases.
It gets a little more complicated as you go from simple site to more complex site to app to more complex app, but I see too many developers trying to be trendy and over engineering simple problems and wasting a lot of time and money.
I was going to say the same thing. If you are building an app something like Angular is great. But for a website that needs to be simple, fast and easy to maintain then jQuery still works well.
I disagree. jQuery was the tool that acts as a "polyfill" for cross-browser compatibility. Nowadays jQuery is dying, not because of React, Angular or TypeScript, Elm. It's dying because of browser-support of `querySelectorAll`, unified event handlers, unified AJAX request API and others.
jQuery had it's time. Now you just use "vanilla" JS and it is enough. No external dependencies for your landing-page / non-web-app site.
jQuery had it's time. Now you just use "vanilla" JS and it is enough. No external dependencies for your landing-page / non-web-app site.
Here's what I tell my devs:
Yes, "you might not need jQuery". But, the first time you have to log real hours fixing a cross-browser bug that the jQuery team already took care of, I'm fucking firing you. Choose wisely.
Yes, "you might not need jQuery". But, the first time you have to log real hours fixing a cross-browser bug that the jQuery team already took care of, I'm fucking firing you. Choose wisely.
Do you know a better library for support of a wide array of browsers going back many years, with a huge log of support issues and test cases behind it?
And that won't go away after a year.
And drop-dead simple, so that a programmer from any background can pretty much just look at the code, and figure it out?
Not necessarily better, but there are a few similar libraries from that time, like prototypejs.
But it's not about whether there is something better, it's whether it's still needed or not.
But it's not about whether there is something better, it's whether it's still needed or not.
jQuery doesn't officially support IE 8 and earlier, or any other browser older than "current - 1". React supports at least the same as jQuery.
http://jquery.com/browser-support/
> If you need to support older browsers like Internet Explorer 6-8, Opera 12.1x or Safari 5.1+, use jQuery 1.12.
> If you need to support older browsers like Internet Explorer 6-8, Opera 12.1x or Safari 5.1+, use jQuery 1.12.
Looks like ~70% of the top million sites are using jQuery
https://nerdydata.com/search?query=jquery
https://nerdydata.com/search?query=jquery
Given that most applications are actually not public facing and do not require 'slick' UIs like we're getting with the new frameworks, I think it will continue to be the choice for utilitarian shops that want to produce easy to maintain stuff quickly. I will certainly admit that it crumbles under its own weight in large apps, but I will continue to evaluate it as my first option when building. Disclaimer: I make my living on the back-end.
It depends on what you're doing, and what you're comfortable working with. If you have page content that is largely rendered server-side, with bits of interactivity and some basic AJAX on the frontend, jQuery's your friend. If you want to build a single-page application that rests mostly or entirely on the frontend, thats what the newer frameworks and methodologies are designed to do, and you're better off going with one of them.
Also, for maintainability - if you're freelancing and plan on handing this off to someone unknown later, I would err on the side of being conservative, and if it turns out that an SPA is what you want to do, then go with a really widely-used framework like React or Angular.
OP here: I'm a back-end dev working on an internal company site. I have used jQuery for the past years for things like simple AJAX and manipulationg dropdowns. Recently I had to build an AJAX heavy part of the page, and got a bit lost in callbacks and DOM manipulations (1500+ lines already). There is no real reason to re-code everything, now it's working, but after seeing all the new shiny frameworks, I started to question my ability to maintain the code of this specific page ("Wouldn't this framework be better and easier to read/debug/extend?"). Still, don't know if one javascript-heavy page is enough to bring a new framework in the project and start over again.
> I had to build an AJAX heavy part of the page, and got a bit lost in callbacks and DOM manipulations
jQuery might not be the fancy new hotness on the block, but it still works and is still used.
I get the feeling more and more that developers are embarrassed about using it, similar to how some devs are embarrassed about using PHP, yet it's still a workhorse.
I get the feeling more and more that developers are embarrassed about using it, similar to how some devs are embarrassed about using PHP, yet it's still a workhorse.
It's really silly that is how the culture behaves. The right tool for the job is a common moniker in other industries, yet in ours its the source of heated debate and hipsterdom.
PHP is some tool that was never really good, but had some compelling features that no other tools provided. Except that now there are better tools for any task it solved, excluding the task of "maintaining a PHP codebase".
If you are starting a new project on it, you should indeed feel silly.
If you are starting a new project on it, you should indeed feel silly.
I disagree, -- sure if you're building native php apps w/out a framework.. but Laravel is probably the easiest MVC framework out there to pickup and build something that works super fast without having to know how to deploy a VPS, etc... For small to midsize php is STILL a workhorse -- but I wouldn't recommend wordpress or vanilla php themselves.
Laravel collections alone make it almost a functional language when using it w/ laravel.
Laravel collections alone make it almost a functional language when using it w/ laravel.
Have you looked at the PHP landscape over the past few years? You may still not love the syntax, but PHP as a language, an ecosystem, and a developer community is extremely strong. It's a fantastic choice for a web app in 2016.
Honestly, no, I haven't look at it in the last 7 years. (It's being that great! Thanks for lighting-up my day.)
Also honestly, I don't think I should look now. The PHP applications I see around are still the ones getting serious vulnerabilities found every week, the same ones that other communities found ways to pack the solutions into tools and conventions that are easier to use than not to. I also don't see anybody claiming PHP has any new template system to replace the dated original one.
I've seen some progress on the language, but not nearly enough to make it compelling. I have plenty of stuff already on my ToTry list, PHP would have to say something better than "I'm not a complete mess anymore" to enter it.
Also honestly, I don't think I should look now. The PHP applications I see around are still the ones getting serious vulnerabilities found every week, the same ones that other communities found ways to pack the solutions into tools and conventions that are easier to use than not to. I also don't see anybody claiming PHP has any new template system to replace the dated original one.
I've seen some progress on the language, but not nearly enough to make it compelling. I have plenty of stuff already on my ToTry list, PHP would have to say something better than "I'm not a complete mess anymore" to enter it.
You can of course choose to still avoid it - but your advice to other devs to do the same makes little sense. It's a completely different beast than it was 7 years ago.
Do you know of any compelling reason, instead of problem fixes?
Because the language is a bit archaic (has maintainability problems for large codebases, has the "too little power" problem for small codebases); as far as I have looked, the ecosystem still does not include a good templating system (although it does include most of the tools available on other web ecosystems); and the community is still heavy on applications with the same kinds of security bugs they always had, and many, many "X-only" developers.
And, anyway, fixing those outstanding problems can only make it an ordinary language. And there's no reason to look at any language that the best claim is "it's not worse than any other random language".
Because the language is a bit archaic (has maintainability problems for large codebases, has the "too little power" problem for small codebases); as far as I have looked, the ecosystem still does not include a good templating system (although it does include most of the tools available on other web ecosystems); and the community is still heavy on applications with the same kinds of security bugs they always had, and many, many "X-only" developers.
And, anyway, fixing those outstanding problems can only make it an ordinary language. And there's no reason to look at any language that the best claim is "it's not worse than any other random language".
I disagree. Let's try adding 0.2 and 0.3 with the JScript library of your choosing and see if it's any easier than PHP.
Javascript being bad does not make PHP any better.
There are more than 2 languages available for backend programming. Some even get both templating and IO right.
There are more than 2 languages available for backend programming. Some even get both templating and IO right.
Floating point math has been around for a very long time, I don't get why that's what you would pick as a problem; a lot of languages have the same behavior. I'm not a fan of JS either, so you don't have to give me a reason to dislike it.
I wasn't necessarily giving you a reason to dislike it. I was giving you a reason why I personally believe it to be over-hyped and convoluted (and why I disagree that PHP is embarrassing by comparison).
I picked floating point math as a problem because JScript would give you an incorrect answer.
I picked floating point math as a problem because JScript would give you an incorrect answer.
PHP should be significantly more embarrassing than jQuery. The jQuery interface is well designed and reliable.
The fact that it still works is important. As long as I've got clients asking for IE 8 support, jQuery's going to be in my toolbox. And probably even after.
The fact that it still works is important. As long as I've got clients asking for IE 8 support, jQuery's going to be in my toolbox. And probably even after.
Ouch. PHP dev here. We write design-pattern-influenced code with classes, abstract classes, DI, interfaces, etc. It's not all bad.
You know, it's been well over a decade of seeing the anti-PHP stuff and I still have yet to see a "PHP is evil" argument that doesn't fall apart after a little scrutiny. I proudly use it and am happy to look at it's usage vs. alternative languages in any of the real-world projects I've developed.
React (plus a couple shims) works great with IE8 up until v15.
Yes, jQuery is good and most people still use it. It does its job perfectly fine. The thing is, HN is a very small like-minded community of people who are always looking for something better than the status quo, which is why you're always seeing news about things like React and Vue, etc.
Very simple and as always it depends on what you want. You want to do the cool new thing? Then use one of the younger frameworks but expect things to be slow, buggy, and ungooglable. If you want to make money wiht little effort then use the older frameworks that survived (e.g. jquery).
How does one make money? Help please
1.
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.m...
2. Profit
2. Profit
For web apps I would use anything BUT jQuery.
For adding simple functionality to a web page, I would probably ever ONLY use jQuery. (Assuming plain js was going to be a hassle.)
FWIW I haven't used much jQuery for about the last 3 years, and all I do is web apps all day every day. The day I discovered Knockout (as the gateway drug) was the day life got exponentially better.
For adding simple functionality to a web page, I would probably ever ONLY use jQuery. (Assuming plain js was going to be a hassle.)
FWIW I haven't used much jQuery for about the last 3 years, and all I do is web apps all day every day. The day I discovered Knockout (as the gateway drug) was the day life got exponentially better.
The only use case for jQuery is if you want virtually all your logic and rendering to be server side and only want to use javascript for toggles, form checking, or other jQuery sprinkles. I wouldn't choose this but if someone did and picked jQuery I wouldn't question the jQuery part much.
If you're writing more than a couple hundred lines of javascript, the jQuery model of putting your application state in the DOM is inferior to pretty much any other application model. There's a reason everybody went to Backbone and then to the component libraries. Separating your model and rendering concerns and delegating the latter to your framework roughly halves the amount of code you need to write.
If you're writing more than a couple hundred lines of javascript, the jQuery model of putting your application state in the DOM is inferior to pretty much any other application model. There's a reason everybody went to Backbone and then to the component libraries. Separating your model and rendering concerns and delegating the latter to your framework roughly halves the amount of code you need to write.
Not to mention storing app state directly in the DOM can have performance implications, as JS needs to cross the bridge and possibly force relayouts to access the state info.
Popular doesn't mean good. Check out modern pop music or American president (joke).
jQuery is ok for super simple sites, but modern interfaces becomes more and more interactive and complex. Attempts to organise some logic via imperative jQuery way usually turns into hell. So, first of all it isn't scalable.
Btw, I wrote an article how Vue.js can replace jQuery for "websites", not only for "web applications": https://medium.com/@borisadimov/vue-js-the-second-breath-of-...
jQuery is ok for super simple sites, but modern interfaces becomes more and more interactive and complex. Attempts to organise some logic via imperative jQuery way usually turns into hell. So, first of all it isn't scalable.
Btw, I wrote an article how Vue.js can replace jQuery for "websites", not only for "web applications": https://medium.com/@borisadimov/vue-js-the-second-breath-of-...
Of course it is!
The way I build web apps is to use intercooler.js (which is built on top of jQuery) for my AJAX and then jQuery, or jQuery-based plugins, for UI needs.
Works great. Yes, the jQuery API has some aspects that haven't aged all that well, but it's a pretty well thought out and through library that provides great tools that should have been baked into all browser environments since the start, and that has a rich ecosystem around it to boot.
The jQuery haters are usually folks who tried to write an SPA with it, which they say, correctly, is a terrible idea. But then, building an SPA is usually a terrible idea as well.
The way I build web apps is to use intercooler.js (which is built on top of jQuery) for my AJAX and then jQuery, or jQuery-based plugins, for UI needs.
Works great. Yes, the jQuery API has some aspects that haven't aged all that well, but it's a pretty well thought out and through library that provides great tools that should have been baked into all browser environments since the start, and that has a rich ecosystem around it to boot.
The jQuery haters are usually folks who tried to write an SPA with it, which they say, correctly, is a terrible idea. But then, building an SPA is usually a terrible idea as well.
> But then, building an SPA is usually a terrible idea as well.
Would you care to elaborate on this? I'm interested in why.
Would you care to elaborate on this? I'm interested in why.
I was obviously being flippant, but a long story short is that going to a JSON-based, RPC-style SPA app gives up a lot of the advantages of the original RESTful web network architecture, not the least of which being simplicity.
Long-suffering HN readers can skip all of this (sorry guys) but I expand on this in the following blog posts:
http://intercoolerjs.org/2016/01/18/rescuing-rest.html
http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...
http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
Long-suffering HN readers can skip all of this (sorry guys) but I expand on this in the following blog posts:
http://intercoolerjs.org/2016/01/18/rescuing-rest.html
http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...
http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
All of these seem to imply discoverability and queries are the biggest pain point in web apps. For me, in creating specific purpose business apps, the biggest headaches are presenting the data in ways that minimize the user's unnecessary actions and, even more of a pain, wiring things up so an event in one location triggers the proper client display changes in another location.
For my use cases, discoverability and ad hoc queries just don't apply.
For my use cases, discoverability and ad hoc queries just don't apply.
Mmm, this is probably a long conversation, but I don't disagree with what you are saying. I think discoverability (in API terms) is different than the flexibility that HATEOAS, with a proper hypertext gives you.
The query issue just depends on how complex your data consumption needs are. The closer they get to levels requiring SQL-levels of expressivity, the more you will need to either churn your API or expose expressivity (and security risk) on the browser side.
In the old days, the way we dealt with changing the UI in another location was by simply replacing the whole page. This actually works pretty well, except for those FOUCs, and we are heading back that way, but now people are starting to do DOM diffs to avoid the blinky-blink. intercooler has a few options for solving it as well (either expanding your replacement target or using dependencies.) I imagine eventually I'll end up adding DOM-merging as an option as well.
Anyway, it's a long conversation.
The query issue just depends on how complex your data consumption needs are. The closer they get to levels requiring SQL-levels of expressivity, the more you will need to either churn your API or expose expressivity (and security risk) on the browser side.
In the old days, the way we dealt with changing the UI in another location was by simply replacing the whole page. This actually works pretty well, except for those FOUCs, and we are heading back that way, but now people are starting to do DOM diffs to avoid the blinky-blink. intercooler has a few options for solving it as well (either expanding your replacement target or using dependencies.) I imagine eventually I'll end up adding DOM-merging as an option as well.
Anyway, it's a long conversation.
> I imagine eventually I'll end up adding DOM-merging as an option as well.
This will be nice. I was playing with some of the examples on the site and noticed a number of them tended to "jump" a bit when the response was returned.
This will be nice. I was playing with some of the examples on the site and noticed a number of them tended to "jump" a bit when the response was returned.
I think it's still super userful.
I'm an Ember developer myself, and I love it, but there's no way in hell I'd use it for a small website. For that matter, I wouldn't use React or Angular 1.x either (I haven't had to do any project in Angular 2.x yet, so I don't really have an informed opinion yet).
So, that out of the way, next up is jQuery, which I think is still a perfect fit for smaller projects. The fact that you can just use it, without having to worry about any real initial prep-work, or having to compile anything, is almost kind of magical in this day and age.
I'm an Ember developer myself, and I love it, but there's no way in hell I'd use it for a small website. For that matter, I wouldn't use React or Angular 1.x either (I haven't had to do any project in Angular 2.x yet, so I don't really have an informed opinion yet).
So, that out of the way, next up is jQuery, which I think is still a perfect fit for smaller projects. The fact that you can just use it, without having to worry about any real initial prep-work, or having to compile anything, is almost kind of magical in this day and age.
[deleted]
React is my only choice for single-page apps, but it's unnecessary for ordinary JS UI widgets on a mostly server-rendered site.
For UI elements that have a lot of internal state, React can remove a ton of complexity. However, the delay between initial page render and the React component rendering itself can sometimes be distracting when those elements are key parts of the UI. This is a solved problem if you're using Node on the server, obviously, but if you're rendering pages with other server-side technology it is a drawback to React. jQuery does not have these issues as it just attaches itself to the server-rendered markup.
For UI elements that have a lot of internal state, React can remove a ton of complexity. However, the delay between initial page render and the React component rendering itself can sometimes be distracting when those elements are key parts of the UI. This is a solved problem if you're using Node on the server, obviously, but if you're rendering pages with other server-side technology it is a drawback to React. jQuery does not have these issues as it just attaches itself to the server-rendered markup.
[deleted]
https://www.npmjs.com/package/jquery
2.3 million downloads in the last month and 4883 dependencies... what do you think?
2.3 million downloads in the last month and 4883 dependencies... what do you think?
This is useful: http://youmightnotneedjquery.com/
It all depends on your needs.
The frameworks you mentioned are not exactly in the same "niche" as jQuery, which encapsulates a friendly way to manipulate DOM, make ajax requests, etc.
However, if maintainability is your focus, write in plain js as much as possible. Frameworks come and go. Code written in ES5 will still work in 5 years from now, while jQuery code may get at least partially deprecated.
The frameworks you mentioned are not exactly in the same "niche" as jQuery, which encapsulates a friendly way to manipulate DOM, make ajax requests, etc.
However, if maintainability is your focus, write in plain js as much as possible. Frameworks come and go. Code written in ES5 will still work in 5 years from now, while jQuery code may get at least partially deprecated.
I have been using query in one of my projects. For me support of IE 8 and older is not an issue but support of mobile users is. So I have replaced jquery with vanilla JavaScript. I found the page performance to be noticeably better. It was also easy to keep the necessary JavaScript functions in mind, compared to jquery, not to mention the reduction in js file size.
As an embedded systems guy, Hackernoon [0] tells me that nobody uses jQuery anymore:
> -It’s 2016 man, no one uses jQuery anymore, it ends up in a bunch of spaghetti code. Everyone knows that.
[0] https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
> -It’s 2016 man, no one uses jQuery anymore, it ends up in a bunch of spaghetti code. Everyone knows that.
[0] https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
Yes.
1. There are some edge cases where it is still useful and it would be way more painful to reimplement it in vanilla js (though maybe still possible). But in these edge cases why bother when:
2. In any largish project invariably _something_ will require jquery. Think Bootstrap or some widget library the boss/users absolutely want or something some "UI" person built themselves.
1. There are some edge cases where it is still useful and it would be way more painful to reimplement it in vanilla js (though maybe still possible). But in these edge cases why bother when:
2. In any largish project invariably _something_ will require jquery. Think Bootstrap or some widget library the boss/users absolutely want or something some "UI" person built themselves.
Keep it simple. Being clever usually leads to making things buggy. Unclever and boring makes things reliable and sustainable.
"websites" still mostly use jquery,
"webapps" typically use a concoction of 100+ js frameworks/plugins, including one of angular/react/ember/backbone (or in some really hotness of the month type places - more than one of those).
it's of useful to know jquery, just to keep things simple when you can.
"webapps" typically use a concoction of 100+ js frameworks/plugins, including one of angular/react/ember/backbone (or in some really hotness of the month type places - more than one of those).
it's of useful to know jquery, just to keep things simple when you can.
Even angular used to/still comes with a jQuery-lite object you can use if you aren't already including jQuery. The new frameworks don't replace everything jQuery does.
What's worse even IE7 is still a thing!
Every other framework relies on JQuery so--yes, absolutely--it's still a thing.
And if you don't work for a company that is in the JavaScript-framework-of-the-month mode, you should know JQuery is still king.
And if you don't work for a company that is in the JavaScript-framework-of-the-month mode, you should know JQuery is still king.
> Every other framework relies on JQuery
This just isn't true. OP mentioned React, Vue.js, and Mithril. None of these use jQuery as a dependency. Neither does Angular, Backbone, or Ember.js.
This just isn't true. OP mentioned React, Vue.js, and Mithril. None of these use jQuery as a dependency. Neither does Angular, Backbone, or Ember.js.
Angular 1.x uses a version of JQ Lite, and will utilize jQuery if it's already loaded on the page.
That being said, I don't think knowing jQuery is very valuable for JS developers anymore. Browser standards have come a long way and frameworks are handling your DOM writes for you, so that major use case for jQuery is gone in any website that requires substantial scripting.
That being said, I don't think knowing jQuery is very valuable for JS developers anymore. Browser standards have come a long way and frameworks are handling your DOM writes for you, so that major use case for jQuery is gone in any website that requires substantial scripting.
Really? what if you have to support legacy apps that are 100% jquery on the frontend / php on the back? It's VERY much still a thing..
Well, technically jQuery is listed as dependency in the bower.json file for Ember.
But I think that's really only so the Ember jQuery wrapper will work properly. So you're still right.
But I think that's really only so the Ember jQuery wrapper will work properly. So you're still right.
No popular current generation framework relies on jQuery. The most recent one I can come up with is Angular 1's reliance on their jQlite micro-library but would use the full jQuery if it was on the page.
OpenUI5 [0] relies on jQuery
[0] http://openui5.org/
[0] http://openui5.org/
I'd never heard of this library and I spend a couple hours a day reading developer news so I wouldn't call this popular.
I'd also argue that this as a current generation framework. I only did a brief skim but the patterns remind me of a Knockout or Enyo codebase with data binding between components doing explicit dom manipulation. The contributors tab shows a 2014 start but I'd have guessed a 2010-2011 start from looking at the code.
I'd also argue that this as a current generation framework. I only did a brief skim but the patterns remind me of a Knockout or Enyo codebase with data binding between components doing explicit dom manipulation. The contributors tab shows a 2014 start but I'd have guessed a 2010-2011 start from looking at the code.
You'd be surprised. UI5 is made by SAP as their go-to UI technology. SAP's profit last year was over 6B euro and it's used in almost every large enterprise out there. It's just hard to see as a tech company because it's not consumer facing.
I'm an SAP and UI5 developer.
I'm an SAP and UI5 developer.
I hope you don't take my comment as too much of an insult to your work. I consider the hallmarks of the current generation of frameworks to be component composition, framework based change synchronization (KVO, diffing, dirty checking), and the avoidance of DOM interaction (jsx, templates). Not being on the newest trend doesn't automatically make something bad and it's clear that you and your team put significant effort into your framework so I'll have to do a much more thorough investigation before I have a real opinion on it.
Check every new SAP web application. It is not the best out there, but it is used A LOT.
I haven't touched jQuery in over 2 years. It's not necessary anymore as the browsers I support are following standards. Even though the syntax is a little bit nicer than vanilla js I don't see any real advantage in using jQuery anymore. jQuery did a lot for the web (it pushed browsers to keeping standards and it brought native implementations like querySelector), but I think the time has come to move on.
I know for a fact that React doesn't. And it's now possible to do quite a bit of element selection (and style flipping), AJAX, and JSON manipulation with pure javascript.
That being said, I agree with your last statement. For better or worse, jQuery still seems to be king.
That being said, I agree with your last statement. For better or worse, jQuery still seems to be king.
No it isn't.
A better way to state that:
"Is jQuery omnipresent now? Yes.
Will jQuery earn you as much money as on the peak of first gen webapps craze? No, totally no"
I myself was earning CAD $90k just in plain salary at the time when jQuery craze was on its peak and when "a dedicated front-end developer" meant a jQuery developer
Honestly saying, I had no realisation how shitty my code was back then, and now I feel ridiculous when I realise how much a bad dev can earn as long as he does something considered "trendy"
A better way to state that:
"Is jQuery omnipresent now? Yes.
Will jQuery earn you as much money as on the peak of first gen webapps craze? No, totally no"
I myself was earning CAD $90k just in plain salary at the time when jQuery craze was on its peak and when "a dedicated front-end developer" meant a jQuery developer
Honestly saying, I had no realisation how shitty my code was back then, and now I feel ridiculous when I realise how much a bad dev can earn as long as he does something considered "trendy"
They do? React, Angular, etc?
Angular 1 and Polymer 1 have a limited version of jquery integrated into the stack. Don't know about React, Angular 2, or Polymer 2 though.
yes, Angular requires jquery for selectors. React I'm pretty sure doesn't.
Mithril and Vue are not new.
Of course jQuery is still a thing.
Can I ask how old you are, linkula? This seems like a question a 13 year old would ask.
Of course jQuery is still a thing.
Can I ask how old you are, linkula? This seems like a question a 13 year old would ask.