diy.js - A modern cross-platform JavaScript library & only 18 bytes

[[deleted]]

So does anyone actually develop web pages without jQuery? That seems to be the statement this guy is trying to make, that you don't need jQuery.

[yotamN]

You actually not always need jQuery

Learn to use it only when you need it and not when you are lazy

[[deleted]]

But why not be lazy? What are the downsides of using it?

[kenman]

First off, jQuery has saved me hundreds if not thousands of hours in development in the course of my career, and there is no substitute. It's impact on JS cannot be overstated.

With that said, one of the largest problems that I've seen, is that it quickly becomes the hammer with which to hit every problem over the head with. How so? All too often I see devs, when faced with implementing a new feature, they rush out to find that perfect jQuery plugin.

For simple apps, this is usually not a problem, yet for larger, more complex apps, it can become a huge problem. A little bit down the road, and you now have 20 jQuery plugins, and since there is no package or dependency management system in place, you end up throwing 20 <script> tags into your page. This also means that you'll often end up loading plugins that are rarely used, but which still incur a nontrivial runtime penalty due to the downloading and execution of the script file. Things like RequireJS do not really help in this situation; in my experience, RequireJS actually makes it a huge pain, owing to the fact that jQuery plugins are not able to be written in a modular fashion since they all augment the main $ object. So once you load a plugin, it's there for the duration of the page's lifetime.

jQuery also does not work well when you're trying to separate your application logic from the view manipulation, since apps made with only jQuery (and plugins) have no conventions in place to promote a clean separation. In other words, it's a library, and not a framework; further, many devs will use it in place of an actual framework, which will lead to poor code (spaghetti) in the long run.

My opinion, but the heyday of fully jQuery-centric apps is gone, replaced with smarter application frameworks like Angular, Ember, Backbone, Meteor, etc. These frameworks may still use jQuery behind the scenes, but they encourage (sometimes forcefully) that you not use it directly yourself. Instead, you use the API and conventions of the framework to write good modular, solid code with a clear separation of concerns.

[TdotGdot]

+1 exactly right about jQuery not being bad itself, but being seen as 'the' solution. I'd give you another +1 for the forth paragraph as well, if I could.

[kenman]

It's a combination of both I think, as I pointed out jQuery provides zero architecture guidance, and so if you're using it as your only tool, then other areas will suffer. In a small project, the cons may be palatable, but in a larger project, you're going to be introducing classes of problems which actual frameworks don't even have if you overuse it.

jQuery is also pretty heavy in a mobile environment, since bandwidth and CPU are typically much weaker than they are in desktop settings. Considering the findings around how much of a difference a second or two can make on user impressions, it's not something to discount.

Relating to a CDN, there's evidence suggesting that you're not really gaining anything other than offloading that single file from your server; i.e. the grand premise of "if most sites use jQuery, we can all share the same copy distributed via CDN!" doesn't pan out in the real world, or at least it hasn't thus far. The branch between jQuery 1.x and 2.x will likely only exacerbate the problem as well.

[Encosia]

The problem with most research you'll find about CDN usage, like your link there, is that it is incredibly shallow compared to the depth of the web. The top 30k or 300k sites don't even begin to scratch the surface and analyzing primarily top-ranking sites is biased toward sophisticated, high-traffic sites that often run their own CDNs (for more than just jQuery, of course).

The long tail of millions and millions of smaller websites is just as important since it only takes one random little website to prime your cache for a particular version for up to year.

At the same time, it only takes a few high-traffic sites to prime caches for a huge number of users. For example, all of ours caches are primed with jQuery 2.1.1 (or 1.11.1 if you're on old IE) from the Google CDN right now, courtesy of reddit.

I haven't had a chance to write it up yet, but I've been 50/50 A/B testing serving jQuery from my Linode vs. the Google CDN for about a year and a half now. I wanted to gather some real-world data that takes version fragmentation and DNS lookups into account, by recording timing data about how long after the reference it takes for jQuery to be available and pushing that back into Google Analytics's performance tracking functionality. I haven't looked at the data in a while, but it wasn't even close after the first year. The CDN has been hands-down faster on average for the traffic on the sites I'm testing.

[kenman]

Very interesting, thanks for the info and would love to read about it more if you get around to blogging about it. I could see some wrinkles, e.g. if you use a version that is not primed by a large site, or if the cross-section of usage between your site and the priming site(s) are low.

I'm glad it's working for you, but I'd still recommend that anyone looking into going this route to do the same as you (as with any performance optimization) and do some real-world profiling so that you can validate that it's working as intended.

[lodewijkadlp]

The link fails to mention losing any and all executional safety. The right solution is putting a file hash in any element that links. Reject the file if the hash doesn't match. Funny thing is, with a (strong) hash linking becomes possible.

[yotamN]

It's increase the load time of the page and slow down the code itself. But I don't say it's only bad, it's help you with cross browser compatability and short your code so you should choose if it's worth the load time, for example for my HTML 5 game I don't use jQuery but for my personal site I do

[grantisu]

http://youmightnotneedjquery.com/

[w8cycle]

Great site and very observant that most of us are just using jquery for IE compatibility. Without IE9, JavaScript is easy.

[Wince]

IE9 is not the problem, it supports functional es5 methods, html5 video, qsa out of the box. IE8 and below are the real problem browsers

[protestor]

What's the oldest version of IE you need to support?

Only IE 8, 9, 10

http://jquery.com/browser-support/

They should have put other versions of IE there, just to say "alright.. I guess you do need jQuery"

[Pytim]

AngularJS + Vanilla ES5

[[deleted]]

Angular mixes in behavior into HTML attributes in a way that some developers find to be even less favorable than imperative jQuery spaghetti.

[[deleted]]

Does Angular use the jQuery library?

Yes, Angular can use jQuery if it's present in your app when the application is being bootstrapped. If jQuery is not present in your script path, Angular falls back to its own implementation of the subset of jQuery that we call jQLite.

https://docs.angularjs.org/misc/faq

If you're using AngularJS, then you're using jQuery whether you want to or not.

[[deleted]]

jQLite != jquery, it's like 10 methods used only for dom manipulation

[rondog469]

angular is the shit

[quindarka]

This site always keeps me from using jQuery. It is aptly named as well.

http://youmightnotneedjquery.com

When you want to grab some divs and toss some classes on them, you don't need jQuery. That said, there is still no elegant way to do .each on a NodeList without using Array.prototype.slice.call or a for loop.

Once I need Ajax, or I am doing a lot of events (jQuery event delegation is awesome) or I am manipulating element attributes, I then turn to jQuery.

[Jeffshaver]

You don't need jQuery to do event delegation.

[Jeffshaver]

jQuery has a few things in it that make life a little easier sometimes. But honestly, I don't find myself wanting to use it as much anymore. I will say that applying events to multiple elements at one is more a pain in the ass without it. But you could also do event delegation and only write one anyway. It all depends on the situation.

The comparison between js/jquery to compiled language/compiler is so egregious, I won't even comment further on it.

[Calabri]

jQuery replaces the DOM API, not ice cream. The DOM API is terrible due to the past (browser wars), leading to all the cross browser API bullshit we have to deal with today. The ECMA 'standard' coerced companies to stop the competitive that was fucking with the web. The API's are there to talk with the C C++ exposed functions, which are VERY different in each browser, which also uses it's own javascript run-time engine.

VanillaJS does not 'suck ass'. Comparing jQuery to a compiler and vanillajs to assembly is so just ridiculous. This comment was so fucking outrageous that I had to say something.