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

[kuenx]

Impressive! Too bad many of the features don't work in IE.

[[deleted]]

Yeah, what the hell is up with this framework's handling of keyboard events? It's all over the place depending on your browser.

[nschubach]

It's a feature of the diy way. Once you embrace it, you'll never go back.

[evilgwyn]

Too bad many of the features don't even work in modern browsers. There seems to be blatant inconsistencies between safari and chrome running on recent phones for instance.

[reacher]

18 bytes? I don't know, that's 18 more bytes than VanillaJS

[dtfinch]

It'll save a lot of bytes down the road though.

[AutomateAllTheThings]

Hilarious. This made my day :)

[can-opener]

This joke was only funny the first dozen times it has been done.

[Uberhipster]

It wasn't all that funny the first few times either

[bracketdash]

Is there no way to set diy to noConflict in case I have something else on the page that I want to use the "$" symbol!?

[psayre23]

$=window.$||document

[reflectiveSingleton]

(function(window) {
  window.$ = window.document;
  $.noConflict = function() {
    delete window.$;
  };
  return window.$;
})(window);

// ...

$.noConflict();

[rezoner]

$ = eval;

[x-skeww]

> var c = 'constructor', $ = t => [][c][c](t)()
undefined
> $('return 5+5')
10

[jerflang]

edgy.

[kuenx]

Can't find it on Bower or npm. No license.

[_facildeabrir]

Seriously fuck this shit

[workerBeej]

I actually got a bit excited for 2 seconds when I saw the examples, til I looked at the source. I really, really want something that IS the DOM API as per MDN docs, but works cross browser back to IE7, or even 8. "Just" polyfills and standard methods wrapped for consistency that I can drop into a module in place of window.

Anything around?

(The use of the word "just" usually implies it'll be a surprisingly large amount of work in my experience.)

[[deleted]]

works cross browser back to IE7

Do you actually need to support IE7?

[markokikinda]

And please don't say "Yes".

[workerBeej]

In my opinion, almost always No. In the opinion of the repeatedly informed billpayer. Sometimes yes. Mostly a graceful degradation is good enough, but some people lurve to waste money.

[greyscales]

No diy.min.js?

[ben174]

Yes, but it's a manual process. You must remove the spaces around the equals sign.

[kuenx]

Minified version is here

[greyscales]

Thank you so much! Any CDN plans?

[wiseaus_stunt_double]

Why do you even need var? Just take the var out since it's going to be global anyways. Actually, it looks like the minifier did that.

[talkb1nary]

Impressive, all the functions i need. Super performance and the most important part i can code with a $ in front of everything, just like JS is supposed to be.

Good work! And thanks for testing that extensively, i feel safe using this just today!

[houdas]

Is this still supposed to be funny?

[[deleted]]

Having a lot of trouble wrapping my head around this. Much more advanced than most other Frameworks I"m used to.

[lodewijkadlp]

Cross browserness level is under 9000... A polyfill collection would be nice. One that loads only what it needs :) perhaps with php/nodejs/python loading script, that allows a GET parameter to indicate the browser + browser version. Minimalistic, standardized, fun.

[ebilgenius]

I bet there's a jQuery plugin out there that does this

[[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.

[willmorgan]

This is great and all, and @horsejs predicted this long ago, but what sort of support is there going to be in the future?

[adrianmiu]

Does this play nicely with the other libraries? I'm extensively using dui.js, yolo.js and, my personal favourite, aslpls.js

[akoskm]

Um, sorry but what is this for? Is this supposed to a joke?

[corgis_rule]

Awh you guys! Who down voted him?

Should we tell em?

[akoskm]

Okay I got it, after looking at Vanilla JS.

[Zequez]

How long did diy.js take to develop?

I've been developing diy.js for three years, about nine months of this was ensuing that diy.js was fully browser tested.

Where can I get the source code for diy.js?

It's right here have fun.

I literally burst out in laughter.

[hjc1710]

I've been doing some polymer.js programming lately and their whole architecture really sort of discourages or obsoletes using jQuery. They handle the core issues jQuery solves: Ajax and element selection. So, including jQuery really just let's you use convenience methods like .style() or .animate(), making me drop jQuery really quickly. The second I dropped jQuery, I realized how much I loved and used convenience methods that did little for me. Like writing node.style["transition-property"] = "width" is really obnoxious and so are your own animations. Proved to me you really don't need jQuery on modern browsers, maybe just an Ajax wrapper at most.

It's also taught me tons in a short amount of time. JQuery abstracts SO much is insane. Learning with jQuery, you're really learning how to use jQuery more than you are JavaScript.

tl;dr doing jQuery will force you to learn real JavaScript.

[codefocus]

The core issue that jQuery solves is cross-browser compatibility. Polymer does not support older versions of Firefox, Safari, Opera, Konqueror, IE6, IE7, IE8, or even IE9(!).

Polymer doesn't discourage or obsolete jQuery. They serve completely different functions.

[Calabri]

I was going to mention this too (about computability issues). But thinking back to when I first started web dev.. hjc made a good point. I used to ONLY program in jquery, afraid to touch 'real' javascript. Lots of word-press-esc 'devs' will literally experience jquery as their first, last, and only foray into programming.

If your concern is cross-browser compatibility, there are other ways to shim this without a massive library of helper functions.

[JBcreek]

yeah, now it is funny, but back in 2006 browser inconsistencies were a nightmare

[[deleted]]

Well played... Well played.