8 ms·
Going Simple with JavaScript
- unicron 15y agoI agree entirely with this approach. Especially when I consider that we're delivering a 350KiB minified Javascript hit on initial load just for jquery and a load of plugins.
- bkrausz 15y agoWhy are you loading 10x times the jQuery filesize in just plugins? Certainly you have a lot more bloat to trim before you should consider eliminating jQuery entirely.
- unicron 15y agoIt's a very complicated application with a huge amount of HTTP endpoints. We're talking over a million lines of code.
- peregrine 15y agoI mean if you use the CDN jQuery the likelihood of loading jQuery up is fairly low considering its so ambiguous.
- apsurd 15y agoyou want the word ubiquitous https://www.google.com/search?ix=sea&sourceid=chrome&ie=UTF-8&q=define%3A+ubiquitous https://www.google.com/search?ix=sea&sourceid=chrome&...
- peregrine 15y agoThank you for this.
- scarmig 15y agoIs this usually actually true? It makes a ton of obvious sense, but I've seen numbers thrown around that suggest a surprisingly low number of people actually end up taking advantage of the cache.
- unicron 15y agoIt's 100% not true. It's also a pain in the arse if you serve everything over SSL like we do.
- joshuacc 15y agoTo the best of my knowledge, the only reason SSL could cause a problem is if you are specifying the protocol (http:// http:// vs https:// https://). The best way to handle this is to use a protocol-relative URL like "//ajax.googleapis.com/mylibrary". The browser will then infer the correct protocol.
- peregrine 15y agoI mean if you use the CDN jQuery the likelihood of loading jQuery up is fairly low considering its so ambiguous.
- alexchamberlain 15y agoIsn't this a massive security risk? You're allowing 3rd party scripts to run in the comtext of your website.
- pieter 15y agoIt's not a bigger risk than people loading jquery from google, or including google maps or analytics or kissmetric or twitter or Facebook code.
- jakejake 15y agoJSONP is a clever hack to get around browser security so it can be risk, but you would generally use it only with trusted sites.
- overshard 15y agoSomething I'm constantly trying to do is optimize client load times by removing things such at jQuery. It's very difficult for me to do as jQuery just improves my development speed tremendously but I'm getting there. I've started by "stripping out" jQuery and just using Sizzle.js which is the selector engine. Next step is removing Sizzle!
- tomgallard 15y agoIsn't it just wasted effort though? If you're using hosted jQuery from Google or similar, it is likely it is already in the client cache... You may in fact find its faster to use jQuery than just Sizzle (which I imagine fewer have cached)
- pavel_lishin 15y agoAlternatively, this is something that the Application Cache would be ideal for. One-time download, cached forever. (Well, until they clear their cache.)
- MatthewPhillips 15y agoSpeed is not just about page load. JQuery carries the weight of 1) Old browser support and 2) 6 years of backwards-compatibility requirement. Heavy JQuery use is the easiest way to guarantee your app will be sluggish to use.
- deleted 15y ago[deleted]
- XLcommerce 15y agoI've recently thought about going 'Naked' JS, but I'm dubious about the benefits. I haven't dug into the code, but doesn't jQuery already use native methods like querySelectorAll where available? I guess if all you need is to query the document and you know your target audience is running a modern browser... then sure, save yourself 31k :)
- c_t_montgomery 15y agoYes, jQuery does utilize things like querySelectorAll (among other things) when available.
- joesixpack2 15y agoNot exactly correct. It uses QSA only under certain conditions. Unfortunately, the fallback code is not compatible with QSA (and not consistent across their "supported" browsers).
- untog 15y agoThat's why I like the idea (if not necessarily the implementation) of things like zepto.js. Keep the jQuery syntax. Use the tiny, optimised library when you can. Use jQuery when you can't.
- joesixpack2 15y agoExcept you have no reliable to way to know when you can and when you can't (and no good way to swap between libraries). Best you can do is conditional comments to target old IE versions and you sure don't want jQuery on that team.
- masklinn 15y ago> I haven't dug into the code, but doesn't jQuery already use native methods like querySelectorAll where available? Yes. But it still has quite a bit of overhead as it also handles non-standard selectors (implemented in javascript), things like :input. > I guess if all you need is to query the document and you know your target audience is running a modern browser... then sure, save yourself 31k :) If you've got an ever more restricted target audience, you can also use things like Zepto (webkit-only, jQuery's interface in 7k)
- jakejake 15y agoIt's interesting to me since I started out in the days before jquery and had to force myself to learn these new libraries. I have started to notice a new generation coming up that think jquery is required to do any work. I will say though, it sure is nice not having to deal with all of the browser weirdness that you face without a lib like jquery.
- XLcommerce 15y agoI think the point is that learning how to program around all the browser quirks is such a monumental waste of effort and time. So in reality i'd say jquery (or any other lib like it that smooths out inconsistencies) is required. Unless you enjoy pain or have something to prove :)
- scarmig 15y agoWhat I'd really like is something that fixes browser quirks and provides a consistent API that's identical to the ecmascript standard, instead of something entirely new. Then have a jQuery-like API when it's useful or improves clarity.
- stdbrouw 15y agoNitpick: you probably mean the HTML/HTML5 DOM API, because the ECMAscript standard only regulates the language, not the host (a.k.a. browser). There are small differences in how browsers run JavaScript or what version of JavaScript they run, but those are much less painful to deal with than DOM API and other API quirks.
- MatthewPhillips 15y agoYou're talking about polyfills. This is increasingly the way to do quirk-normalization. One example of the Function.prototype.bind polyfill on MDN: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/bind https://developer.mozilla.org/en/JavaScript/Reference/Global....
- huggyface 15y ago
- Hovertruck 15y agoMaybe I'm being unnecessarily harsh here, but this seems to have about the same level of substance as a low-level JS tutorial you'd find on Nettuts or something.
- aarondf 15y agoThe code may be something you could find on Nettuts but I think the point is to challenge the belief that we should all "just use jQuery". Not to show you how, but rather to explain why. "How's" are easily Googleable, "why's" are a little harder and therefore more valuable, IMO.
- ck2 15y agoIf you are going to go that simple, then why even pass function formatCurrency on the main page, you can pass the whole function back with the document.body.appendChild method. Then instead of 628 bytes, you'll have just 100 or so. Then make the script loader a re-usable function for other data on the page.
- DanI-S 15y agoFor those interested in something more lightweight than jQuery that supports the majority of commonly used functionality, give Zepto a try. http://zeptojs.com/ http://zeptojs.com/ It has a compatible syntax at a third of the weight. It's very well suited to mobile. With regards to the original post; it's fantastic to be doing things efficiently, but in the vast majority of circumstances I would presume that forcing the user's browser to download some additional kb of libraries is preferable to forcing the user to Google a currency conversion.
- maratd 15y agoAs this article points out, we're past the point where we need frameworks for small/medium projects. Animation is now handled by CSS3. JavaScript has been updated in all major browsers and now supports bind/each/map/filter right out of the box. If you're starting now, you can build effectively in JavaScript alone. That said, you may still benefit from a framework if you're doing a very large, long-term project.
- winstonm 15y agoJavaScript has been updated in all major browsers and now supports bind/each/map/filter right out of the box. No version of Safari supports bind.
- ighost 15y agoYes, Javascript the language is getting better support in browsers, but DOM manipulation without a framework (like jQuery) is still horrible.
- thissitesucks 15y agoThat's completely contrary to what I've experienced. Only browsers that "need" a little extra JS/CSS are the old IE versions. Quotes indicate you don't necessarily need to enhance pages in those browsers at all these days. If your experiences indicate otherwise, you are simply doing something wrong. PS. jQuery is horrible. Every time you think you've figured out all of their undocumented quirks, they change the logic. It's famously inept in IE 6/7.
- joshuahedlund 15y agoI've had similar thoughts recently. I'm fairly new to jQuery, so maybe I just still don't know how to use it properly, but sometimes I don't feel that the costs of adding another 'plug-in' and requiring another server call for another js file is worth it when my needs for the feature are low. For instance, just recently I was looking into plug-ins for automatically changing text and color of input fields, but I only needed it once, and I ultimately decided it was much more efficient to just manually code this into the onclick: > if(this.value==\'Search Products\'){ this.value=\'\';this.style.color=\'#000\';}
- mkmcdonald 15y agoThis post is moving towards the right direction, but not far enough I'm afraid. Selectors are completely unnecessary. Class "selectors" are tar pits as they have to search every single node in the current context (usually the entire DOM) and then have to check for a class match amongst a possibility of multiple classes. Quite simply, if you're using a class "selector", you're doing the user—and yourself—a great disservice. Use `id` hooks where possible and `HTMLCollection`s like `HTMLDocument::forms` and `HTMLFormElement::elements` when `id`s are unnecessary. The speed gains are huge. Moreover, jQuery completely loses its appeal once the selectors are eschewed. The only legitimate options I see are the `classList` abstractions along with the animation methods. Both are easily replaced with far more modular options (I prefer David Mark's My Library). In short, please learn about the DOM and how it operates. The browser "weirdness" tends to sort itself out once you realize what's going on.
- grannyg00se 15y agoLove this. I don't like to include addons just to use a small subset of their functionality. On the other hand, I hate including cross browser hacks in my code. I think jQuery has a place, but is widely over used.
- allbutlost 15y agoIt seems all dreamhost sites are currently down, including snook.ca. Here's the cached version -> http://webcache.googleusercontent.com/search?q=cache:http://snook.ca/archives/javascript/going-simple-with-javascript&hl=en&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://...
- sedachv 15y agoIf you want to do this style of JS development and get backwards compatibility for 2005-era browsers (AJAX and event differences, basically) and no other "utilities" that just rename DOM functions and helpfully put them under 10 layers of property access indirection, Peter Michaux's Fork JavaScript is highly recommended (mirror: https://github.com/vsedach/fork-0.1.1 https://github.com/vsedach/fork-0.1.1). That's the way I like to write JavaScript.