Going Simple with JavaScript
snook.ca
snook.ca
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.
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.
No version of Safari supports bind.
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.
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.
Then have a jQuery-like API when it's useful or improves clarity.
What quirks is jquery saving you from dealing with? There are some, but I'd like the reader to actually think about this for a moment.
Many simply defer to jquery now and have lost curiosity about the underlying browsers (which have been rapidly improving).
Oh and try querying for something like this in ie6.
'.class + .other_class > .yet_another_class'
Having css3 query support in legacy browsers is awesome.
Not to mention productivity gains from method chaining and batch assignment such as
$('.somehting').find('*').css({'font-weight': 'bold'});
Do you really want to type the 10-20 lines of JS that are required to make that happen? I don't.
There are still some differences in modern browsers but those can mostly be repaired with polyfills.
Oh, and while I would not recommend doing your chaining operation (chaining just makes it harder to debug), I can write the same thing in one line of JavaScript:
Array.prototype.slice.call(document.querySelectorAll('.something > *')).forEach(function(el) { el.className += ' bold-font'; });Why not just use a extremely well tested library that automatically gives you full browser support? All for the equivalent price of one very small jpeg file.
You had said that it was 10 - 20 lines of code. The reason I posted my original comment is that many jquery abusers don't know about alternatives.
Why not just use a extremely well tested library that automatically gives you full browser support?
You have to justify why you use something additive, not why not to use it.
All for the equivalent price of one very small script file.
Not quite sure why the load time of the script file gets so much attention. It is hardly to real expense of jquery. Many, many, many jquery-crutch sites are horrendously inefficient because they think that the magic of chaining and the robust selector language comes for free. It does not -- it comes at an often significant expense.
You have to justify why you use something additive, not why not to use it.
If your decision not to use jQuery (or another lib that makes your life easier) is because of performance then you're optimising much too early.
Personally I optimise for developer time first and raw performance much further down the line.
And dom querying is not usually the bottleneck in most sloppy sites... its way too many event listeners. And jQuery comes to the rescue once again with extremely easy (to read and write) event delegation.
Sorry I don't mean to offend you or anything... but if you're rejecting jQuery or extjs or zepto etc. on the basis of performance then you're probably doing it wrong. Keystrokes count. Libraries allow you to focus less on plumbing. That's the whole point.
LOL. That's the stupidest thing I ever heard. This is John Resig, isn't it? :)
> Personally I optimise for developer time first and raw performance much further down the line.
Yeah, you just set a new precedent. :(
> And dom querying is not usually the bottleneck in most sloppy sites...
You are allowed more than one bottleneck.
> its way too many event listeners. And jQuery comes to the rescue once again with extremely easy (to read and write) event delegation.
You just have no frame of reference.
LOL. Which library would that be?
Absolutely NOT. The results vary per jQuery version as they have been struggling to grasp the subtle differences for six years.
"event normalization" is another "nice-to-have" that isn't necessary. DOM 0 event handlers (e.g. `node.onclick`) have worked for decades. Each node may only be allowed one handler, but there's more than enough nodes to get the job done. Of course, event delegation can be used to handle more than one event, so this becomes moot.
I can guarantee you that the frivolous "productivity" gains from chaining Frankenstein queries like yours are mitigated by massive speed losses from parsing.
Those 'Frankenstein' queries are ridiculously easy to read and to type.
'massive speed losses from parsing'
Nobody is searching the entire dom for matching nodes.
The single biggest performance killer... far more important than tree traversal is event overhead. As long as you think long and hard before applying a new event handler (and use delegation whenever possible) you'll be fine even with those 'Frankenstein' queries hehe :P
The DOM is not CSS.
What does that even mean in this context?? How does it further your point?
illustrates a continued ignorance of the DOM
enlighten us then...
I test all the way back to IE 5.5. Try browsing a site with a heavy jQuery dependency in IE 5.5 (StackOverflow is a nice example). Those sites tend to implode.
> Those 'Frankenstein' queries are ridiculously easy to read and to type.
You sure about that?
A: `$(someForm).find("input[name=whatever]")`;
B: `someForm.elements.whatever`;
B is quicker to execute, type, and read.
Try running some speed tests on `find`. You'll notice it's pretty inefficient.
> Nobody is searching the entire dom for matching nodes.
I should start counting the number of times I encounter `$(".stupid")` reading source code. The count would probably be in the thousands.
> What does that even mean in this context?? How does it further your point?
Using "CSS selectors" to traverse a tree of nodes is utterly stupid. That's what recursion/tree traversal algorithms are for. What's nice is tree traversal is rarely necessary. Selecting via `id` or `name` (through an `HTMLCollection`) is quick and easy.
> enlighten us then...
I've posted 3 comments now on this topic. Shall I link various DOM specs?
Clearly your opinions differ from the majority of the web community.
Why do you think we now have document.querySelectorAll?
Have a look at the mdn article: https://developer.mozilla.org/en/DOM/Document.querySelectorA...
example given on that page: var matches = document.querySelectorAll("div.note, div.alert");
also :
http://www.w3.org/TR/selectors-api/
Makes perfect sense.
That's what recursion/tree traversal algorithms are for
No. That's what highly optimized browser internals are for.
I test all the way back to IE 5.5
Why? ie5.5 is 12 years old.
> Why do you think we now have document.querySelectorAll?
This is called "argumentum ad populum" (appeal to popularity). The advent of jQuery caused clueless "developers" (along with library authors) to beg for "native" selectors. QS(A) is the result. They were never needed in the first place.
> Why? ie5.5 is 12 years old.
Internet Explorer's Quirks Mode (which still exists in IE 9) is a simulation of IE 5. It's useful for testing against IE's old box model.
ahh now I get it. you're one of those guys. you're just smarter than everyone else right? good luck with that.
You are one of those guys that figures anything popular must be smart. Good luck with that. :)
Granted, the typical Web developer will simply announce they don't care about any browsers deemed inferior (or unknown to them) at the time. History has shown that such carelessness leads to sites that are more likely to break in future (unknown to them at the time of development) browsers.
Often the expected outcome for IE 5 is a static page.
You again. Smart-ass doesn't suit you.
Obviously, you can use standard DOM methods (e.g. gEBTN, gEBCN) with the "closest node" as well.
And, assuming you mean an element node, you just bought yourself a world of hurt. jQuery and the like will use the Selectors API (e.g. QSA) when it suits them, and due to their disagreement with the specs, element nodes don't suit them.
When they use their own query code, performance and compatibility go right down the toilet.
In other words, use QSA with the document node, unless you want to relearn how queries work.
> The single biggest performance killer... far more important than tree traversal is event overhead. As long as you think long and hard before applying a new event handler (and use delegation whenever possible) you'll be fine even with those 'Frankenstein' queries hehe :P
Again, event delegation is unrelated to queries. It's silly to assume you can use wasteful queries with impunity as long as you don't attach too many listeners.
And yeah, those "Frankenstein queries" are the exact opposite of self-documenting code (something jQuery proponents get backwards).
No it isn't as you send all of the supporting junk code to the newer browsers that don't need it.
> Not to mention productivity gains from method chaining and batch assignment such as $('.somehting').find('*').css({'font-weight': 'bold'});
Chaining has nothing to do with queries.
> Do you really want to type the 10-20 lines of JS that are required to make that happen? I don't.
Then learn to write (cross-browser) functions that fit your needs. Leave the ham-fisted queries alone.
Smart aleck doesn't suit you.
Obviously, you can use standard DOM methods (e.g. gEBTN, gEBCN) with the "closest node" as well.
And, assuming you mean an element node, you just bought yourself a world of hurt. jQuery and the like will use the Selectors API (e.g. QSA) when it suits them, and due to their disagreement with the specs, element nodes don't suit them. Some scripted query engines (e.g. YUI) ignore the disagreement, favoring wrong answers fast over right ones slower.
When the libraries use their own query code, performance and compatibility go right down the toilet.
In other words, use QSA with the document node, unless you want to relearn how queries work.
> Having css3 query support in legacy browsers is awesome.
Except that you don't have anything close to that (assuming you are using one of the "popular" libraries). And, even if you did, would you really want to send that crap to an iPhone?
Only way to do it efficiently is to load the library inside conditional comments and use QSA for everything else. That is assuming you can find a query engine that actually works as expected in IE 6/7.
>> massive speed losses from parsing > Nobody is searching the entire dom for matching nodes.
Parsing selectors is parsing selectors, regardless of how they will be used. One element or the entire DOM; it doesn't make a bit of difference.
> The single biggest performance killer... far more important than tree traversal is event overhead. As long as you think long and hard before applying a new event handler (and use delegation whenever possible) you'll be fine even with those 'Frankenstein' queries hehe :P
Again, event delegation is unrelated to queries. It's silly to assume you can use wasteful queries with impunity as long as you don't attach too many listeners.
Oh, but wait, jQuery tangles up queries and event delegation with its "Live" feature. So you are screwed either way. :(
And those "Frankenstein queries" are the exact opposite of self-documenting code (something most jQuery proponents/marketers get backwards).
We've gotten to such a point of jQuery saturation that it seems some of us have forgotten why we use it in the first place. Which is really just the other side of the coin of people blindly using it without knowing why.
I lead a team of developers building web apps day in and day out. I have a number of fairly cutting edge web samples in the wild. A "trust me" on an anonymous board is completely meaningless to me.
As grandparent says, dealing with these quirks is a waste of time and effort.
There are far less quirks than many imagine them to be. Further by providing some trivial syntactical sugar, jquery encourages a development style that is orthogonal with the DOM, incurring a significant performance penalty (horrid abuses like Twitter).
I'm not saying not to use jquery, and we do in several of our projects. But we justify why we use it, and never perversely demand a justification why not.
I used to do a lot of work in Flash, and one of the nicest parts was knowing that what you write works as intended across environments. One of the nice side-effects of the HTML5 mob is that the browser vendors are putting a lot of work into both improving their APIs and doing so in a cross-compatible way.
And if you "enjoy" jQuery, you have no frame of reference. It's far more inconsistent than the DOM implementations and the documentation is terrible.
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.
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.
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\';}
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 :)
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)
"How's" are easily Googleable, "why's" are a little harder and therefore more valuable, IMO.
Especially when I consider that we're delivering a 350KiB minified Javascript hit on initial load just for jquery and a load of plugins.