My last two projects have completely forgone jQuery for vanilla JS and a minimal Lodash. Widespread support for querySelector, querySelectorAll, getElementById eliminate all of those handy selector functions. The rest you can read below.
The big advantage of jQuery is that everyone and their dog knows it. You can throw a rock in a crowd, hide the guy you hit and he will be able to code on your projects.
This comes with the big disadvantage of jQuery, everyone and their dog knows it and dogs are not great coders.
Did you mean "hire" or where you intentionally trying to make it sound like you're abducting programmers off the street and hiding them in your basement?
I try to look at it in a more positive light. Browsers are finally catching up to everything the great jQuery library solved. Now we have a standard built in, that we can all use. This should result in lighter weight experiences, especially as we all move towards mobile.
All the people that hate on jQuery in 2016 either forgot or were not there when it came out and provided a unified solution for the mess that were browsers at the time. Its biggest selling point is not as compelling any more.
You're looking at it from an overly pessimistic perspective. jQuery didn't solve any new problems, there were tons of libraries that solved the exact same problems in different ways at the time that it came out, like MooTools, Dojo, and Scriptaculous/Prototype. jQuery was not innovative, it didn't save the world from anything. It's biggest selling point was that the code was easy for designers to pick up, eliminating a lot of the need for the designer/developer dichotomy.
tldr; jQuery's success was not innovation or unification, it was an easy to pick up syntax. From there it was all inertia.
You know, I hear this sentiment very often on HN and I have to wonder who these websites are being developed for.
The last two products I've worked at has had an audience that includes individuals who either cannot or will not upgrade their web browser. They are stuck on whatever their IT department froze their browser version to year(s) ago. This could be internet explorer 9 or some ancient version of Firefox or Chrome.
The individuals in this circumstance always amount to what some might consider to be a negligible amount of people (Probably less than 2%), however, I've always been unable to construct a good argument for why we should be unwilling to support 2% of our customer base when using a good cross-browser compatible library like jQuery from the start can save the argument from even taking place.
I suspect this is more the nature of working on B2B apps than B2C, although I do wonder how many people are actually looking at the browser analytics of their audience when they are so willing to forsake jQuery for "vanilla javascript".
I agree this used to be the case, but even in my very large, stubborn organization, we have finally upgraded to the most recent IE11 release. Because, so much on the web now, just doesn't work without it anymore. A lot of our issues come from the banking industry, where their apps will just straight not work. We've even had a few say you MUST use Chrome. For a BANK to request that is saying something about the landscape of supporting old browsers. The large push by Microsoft to get people's asses in gear is a good thing. The other half of the planet is using Chrome.
When my analytics still tell me I have customers accessing my site from internet explorer 9 and 10, I'm not sure what else I'm supposed to do. I can tell them to upgrade all I want, that doesn't mean it's going to happen.
Well, that appears to be what the rest of major organizations are doing. Their techs will literally just tell us too bad. Upgrade or use a different browser, and I agree. Progress.
When you're in a growing startup trying to get as many customers as you can, slamming the door on them with an avoidable technical issue isn't progress.
I would argue a growing startup shouldn't worry about supporting 2% of the user base. You're needlessly allocating resources, and adding additional overhead for a tiny fraction of probably non paying customers. I really believe the era of having to worry about IE8/9 is over.
Yeah... if you look at global stats and extrapolate to your own company you're doing yourself (and your company a disservice). It completely depends on what you're selling and who your customers are.
Sure, okay, I'll tell my CEO that 2% of our customers just don't matter, becuase - yanno, the progress of the internet needs to happen.
Or I could just use jQuery from the start and not think about this problem again.
This youmightnotneedjquery.com website is nice but I'd be more interested to know what features are available in jQuery but currently missing from vanilla JS.
At the moment, I get the feeling that if I start with vanilla JS, at some point I'll need features that only jQuery provide, so I'll either have to reimplement them in my project, or backpedal and add jQuery.
Well technically nothing is missing from vanillas JS, as jQuery is written in JS. I'd be REALLY interested to hear what you're doing that you couldn't do fairly easily without jQuery. Majority of users are doing basically selectors, setting attributes, ajax, etc. All easily done without it.
Unfortunately Promises need to be fixed before fetch will be sane and here's how the promises spec currently looks:
- unhandled errors silently swallowed [1] (this is the case for the most popular polyfill [1] too - the one recommended by fetch polyfills, BEWARE [3])
- no 'finally' method, despite pretty much everything in a UI needing some common 'cleanup' after e.g. a fetch()
- not cancellable
Right now you're better off with `$.ajax` (maybe make a custom build of jQuery) or a promise-like library like reqwest [2], rather than fighting with fetch.
That depends on whether the Promise specification gets cancellations. I like fetch's clean API, but being able to cancel my ajax requests is essential.
jQuery has its uses, many uses. But for the ones stated above, it's just not needed. People are including a large library on their site, to use a couple functions. Use the correct tool for the job.
My original post was ditching jquery for native JavaScript. Nothing to do with additional libraries. Except for Lodash which is very specific to some complex things I'm doing that jquery wouldn't help with anyhow.
Those query selectors are supported back to IE8/9. As always, if you need it, obviously use it. I'm referring to including it by default, just because you've always included it by default.
> This also helps you to learn better javascript, rather than relying on a crutch to string together a lot of convoluted sugar syntax.
I disagree that jquery's API is convoluted.
And what is wrong with sugar syntax? One can argue that most of es7 is sugar syntax, but we are happy to use it since it makes your code more terse while remaining readable
It's not that their API is convoluted, but generally what is being generated by a developer is. It's easy to fall down the jQuery rabbit hole, and start making messy decisions, by just using every possible thing available. Reminds me a lot of early PHP developers, writing spaghetti code because it's easy to do so. I'm currently in the process of converting some of my OWN 10+ year old PHP to Node, and it's difficult to sift through it all. My experience with reading a lot of jQuery stuff is similar. Easy to pick up, and do a lot of magic, which means easy to make a mess.
If anything node is a hugely magnified version of jQuery in that respect. Instead of using 200 different jquery functions to do stuff, you're using 200 different npm libraries to do stuff.
var request = new XMLHttpRequest();
request.open('GET', '/my/url', true);
request.onload = function() {
if (request.status >= 200 && request.status < 400) {
// Success!
var data = JSON.parse(request.responseText);
} else {
// We reached our target server, but it returned an error
}
};
request.onerror = function() {
// There was a connection error of some sort
};
You don't need a reactive front end framework, but not using two way data binding at this point I think is crazy. Binding is an EXTREMELY powerful tool.
I have yet to see something that handles updates from other sources well. Meaning that the page the user is on is updated by some other person or process and those changes are propagated correctly. I still have events that fire when something is saved that check to see if it was modified while the user was in it.
jQuery 3 also isn't doing reactive data binding, and is not compatible with older browsers. Not really a fair comparison, as they are meant for two different things. I just included it as a response to the AJAX stuff. If you're going to be doing AJAX, there is no reason not to use a modern front end framework.
I am not yet sure of it myself, but something like Umbrella JS (http://umbrellajs.com/) may be a good compromise between writing vanilla JavaScript and dealing with its pain points and using jQuery.
I am an author of a jquery plugin (1KLOC) which I need to rewrite in plain js.
There is going to be a handful of things that when converted will need to become helper methods because its not a line to line conversion.
So now Ill be writing a small dom manipulation lib within my lib. This seems wrong to me, since every other thing converted from jquery to native will also need write their own little helper lib.
Now you import all these great native js libs into your project, and because native js code is usually a little bigger than jquery code, you end up with a bigger vendor bundle than if you had just used jquery and all your libs used it too.
Modular vs monolith. Many people would rather require 100 libraries that each do one thing perfectly than one library that does 10,000 things poorly. It also makes everything you do easier to test and run 10+ times faster.
Looks cool. I am personally looking for more reasons to drop jQuery rather than more reasons to depend on it though. As an aside, I did the swipe to see the menu (I'm on mobile) but I am having hard time making the menu go away. (currently using gasp refresh).
I like some of these functions. The cookie function is something i could have used in the past. And the selection function seems handy too. But I think the web site could use a lick of paint.
All of these comments taking a crap on jQuery are hilarious.
It's like saying "Using lodash is bad because then you don't learn real javascript and you rely on another big library to do the job for you".
Becoming an expert DOM manipulator in vanilla javascript won't make you a good developer. DOM manipulation is incredibly trivial but involves a lot of grunt work, and jQuery is just a utility lib that makes the grunt work easier. Just like lodash, moment.js or any other lib.
I think people are just super salty because jQuery is popular, everyone uses it, which means that a lot of bad developers use it, and bad developers produce spaghetti code - which means that jQuery is bad? lol.
You know there's a lot of morons who eat pizza, does that mean that ordering pizza once in a while makes you a moron?
Writing good or bad code has nothing to do with jQuery, lodash, React, or any other library.
If you're a shit programmer you will write shit code. If you're a good programmer you won't.
If you're rendering server side, you're going to use imperative DOM manipulation library - jQuery is a good choice.
If you're rendering client side, you don't need jQuery, you're going to use a rendering library.
I don't get why people have problems with grasping such simple concepts.
With react and redux I haven't needed jQ for anything in ages. Feels fantastic. A whole class of bugs is avoided when you aren't poking at the DOM to get things done.
For all those who suggest, vanilla JS, it sounds quite interesting, but many use ui frameworks like bootstrap which require jquery anyway. So why not go the whole distance and use jquery yourself?
Can bootstrap work without jquery or isolate only the subset of jquery they use?
I've enjoyed using DoneJS. It's a lot like using Vue or using React with Mobx. I really like how it provides a lot of things that I'd normally have to set up myself, like SSR, & fall-through data cacheing, and its packager/build tool has the best API of the ones I've used (but I've only seriously used Browserify, Webpack, & StealJS, and SystemJS a little bit, so I can't speak for the others). It supports using React for the view layer, if that's your thing. Also, full disclosure, because of my past experience with DoneJS-related projects, I got a position at Bitovi last year. It's pretty likely you've used sites that use DoneJS tech, too. I know of at least one in the Alexa top 50. I REALLY like the changes of the next version, which is currently available as a pre-release on npm. I've been using it in my side projects and it has some pretty nice changes to many of the APIs.
Personally I don't try to use jQuery anymore. Don't get me wrong. I use it a lot, even in new projects. Because a lot of third party libraries, applications or components depend on it.
Also jQuery is so much intrenched into our computer infrastructure. You can even install it using your fav package manager `apt-get install libjs-jquery`.
I appreciate that jQuery got us to where we are today, but as far as best practices go, I don't think we should encourage its current use.
The best we could do for a 'replacement' is a site that lets you pick which browsers you're targeting, which DOM APIs you want, and generates a polyfill.
How can I know this is safe (short of reading the downloaded source)? There's (apparently) no relation to the actual jquery project, and the downloads are being served over http.
http://youmightnotneedjquery.com/
This also helps you to learn better javascript, rather than relying on a crutch to string together a lot of convoluted sugar syntax.