Hacker News Reader

Comment by overcast | Hacker News Reader

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.

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.

View on HN

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.

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.

Yep. Knowing how to get the most out of jQuery, in 2016, mostly means knowing when not to use it.

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.

A victim of its own success, but a success that everyone benefits from.

Amen. When jQuery hit the scene, it was the greatest thing since sliced bread. It's ubiquitous for a reason.

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.

> hide the guy you hit

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?

Now I know how I got here... Thank you.

Yes, "hire". Can't edit anymore...

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.

https://www.w3counter.com/globalstats.php

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.

One reason I still use jQuery is because its ajax() API is much nicer than the XMLHttpRequest API.

Edit: another reason: slideUp() / slideDown() are very useful and not easy to implement with native code.

True, I hope these pains will be gone 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.

Essential? Why?

The big use-case I can think of is file uploads. If someone is uploading a large file, you wanna be able to cancel it.

Cancel the requests, or cancel the callback chain that's set up to fire when they complete?

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.

[1] https://github.com/stefanpenner/es6-promise/issues/70#issuec...

[2] https://github.com/ded/reqwest

[3] http://requirebin.com/?gist=8f13d5147c1c252ab1691115bfa8b7c5

I don't know why they pushing Observables AND Promises in ECMAScript. Observables a much more flexible and don't have these problems :/

>All easily done without it.

I think that's the thing. Unless you write your own utility library or use someone else's it's often more verbose, more fragile and less intuitive.

And if you do use a library, probably one for each feature, why is it better to have a handful of dependencies than one?

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.

I would rather have one single large dependency than a handful of small, regularly abandoned, ones.

In a year I will be able to reach out to the community for support on jQuery. Will I for all of these small tools?

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.

> I'd be REALLY interested to hear what you're doing that you couldn't do fairly easily without jQuery.

Cross browser compatibility and legacy IE support.

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.

Ajax is the last thing keeping me in jquery.

https://github.com/mzabriskie/axios

https://github.com/github/fetch

Among countless others. Please don't bring in all of jQuery if you're just going to use one function from it.

From my original link above.

http://youmightnotneedjquery.com/

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 };

request.send();

Even better, you should just use a reactive front end framework. https://vuejs.org/ combined with https://github.com/vuejs/vue-resource is currently my fave.

You're mistaken, Vue doesn't provide any XHR helpers. Look into fetch or superagent, if you need an abstraction.

https://github.com/vuejs/vue-resource is what you use.

Glad to see Vue mentioned :) However, Vue is just the view layer. If you want it to communicate with a server, I recommend looking into Vue-Resource.

yes, vue-resource is what I use. Works well.

You don't need jquery!!! You need... these other things that fewer people use and/or care about.

Just use jQuery. Please.

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.1.0.min.js is 84k.

vue.min.js is 75k. vue-resource.min.js is 13k.

So jquery is smaller.

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.

are you aware of html5 fetch? It suffices most of the time but again not compete replacement(if you want to get xml for example)

Yes, I'm aware of it. Support is not good.

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.

Reply on news.ycombinator.com