
Going Simple with JavaScript - joshuacc
http://snook.ca/archives/javascript/going-simple-with-javascript
======
DanI-S
For those interested in something more lightweight than jQuery that supports
the majority of commonly used functionality, give Zepto a try.

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

~~~
ighost
Yes, Javascript the language is getting better support in browsers, but DOM
manipulation without a framework (like jQuery) is still horrible.

~~~
thissitesucks
That'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.

------
jakejake
It'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
I 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 :)

~~~
huggyface
>I think the point is that learning how to program around all the browser
quirks is such a monumental waste of effort and time.

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

~~~
XLcommerce
you're kidding right? Off the top of my head event normalization is worth its
weight in gold.

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.

~~~
MatthewPhillips
IE6 is below 5% market share. But if you absolutely have to support IE6, then
yeah, use JQuery.

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

~~~
XLcommerce
Yeah sorry that one liner is pretty ugly. Also I don't see the issues with
chaining and debugging. Chrome has a v.good debugger. And to top it off
querySelectorAll requires ie8+.

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.

~~~
thissitesucks
> Why not just use a extremely well tested library that automatically gives
> you full browser support?

LOL. Which library would that be?

~~~
XLcommerce
hehe just came back to check my comment history... dude u really created what
3.. 4? different accounts to reply to my messages?? Lol i really got under
your skin. you are familiar with this right?

<http://www.flickr.com/photos/villagemember/987251565/>

------
mkmcdonald
This 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.

------
overshard
Something 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
Isn'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)

~~~
MatthewPhillips
Speed 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.

------
ck2
If 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.

------
alexchamberlain
Isn't this a massive security risk? You're allowing 3rd party scripts to run
in the comtext of your website.

~~~
pieter
It's not a bigger risk than people loading jquery from google, or including
google maps or analytics or kissmetric or twitter or Facebook code.

------
joshuahedlund
I'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\';}

------
sedachv
If 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>). That's
the way I like to write JavaScript.

------
XLcommerce
I'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 :)

~~~
untog
That'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
Except 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.

------
allbutlost
It seems all dreamhost sites are currently down, including snook.ca. Here's
the cached version ->
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://snook.ca/archives/javascript/going-
simple-with-javascript&hl=en&strip=1)

------
grannyg00se
Love 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.

------
Hovertruck
Maybe 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
The 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.

------
unicron
I 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.

~~~
peregrine
I mean if you use the CDN jQuery the likelihood of loading jQuery up is fairly
low considering its so ambiguous.

~~~
scarmig
Is 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
It's 100% not true. It's also a pain in the arse if you serve everything over
SSL like we do.

~~~
joshuacc
To the best of my knowledge, the only reason SSL could cause a problem is if
you are specifying the protocol (<http://> vs <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.

~~~
unicron
You've obviously never dealt with ancient IE versions and script loading
then...

~~~
joshuacc
I'm happy to be enlightened if you feel like sharing.

