

Vanilla JS, fast, lightweight, cross-platform framework - elliotlai
http://vanilla-js.com/
Vanilla JS is a fast, lightweight, cross-platform framework
for building incredible, powerful JavaScript applications.
======
graue
I can't be the only one getting tired of sites like this making the front
page. Really? It would be one thing to see someone write a legitimate article
on why they think the move to JS frameworks is harmful and/or the benefits of
using plain JS, and for that to make it to the front page. I'd be interested
in that perspective. But this is just somebody being snide. It's the internet
equivalent of the kid on The Simpsons that points and goes "ha-ha!" There's no
content. We can't have a discussion around a smartass joke like this.

~~~
reedlaw
Reading the example code I learned enough to become interested in vanilla
javascript. Although satirical in tone, I found it insightful. It lead me to
question the necessity of using jQuery for every project.

~~~
tripzilch
I used to wonder the same thing, but after a while I've found that it already
pays to include jQuery (or similar) as soon as your code reaches a complexity
of "does more than one kind of thing" (roughly).

------
ashray
Fast and lightweight, yes. But vanilla-js is certainly not cross platform ;)
You see, that's actually one of the biggest problems with JS and one of the
main reasons why people use things like jQuery (apart from the pretty API..).

That cross platform bit is the weakest link _sigh_.

~~~
dotborg
jQuery API is not pretty

~~~
dag11
I'll take

    
    
      $('p').text('Hello.')
    

over

    
    
      for (var p in document.getElementsByTagName('p')) { p.innerHTML = 'Hello.'; }
    

any day!

~~~
v413
This enumeration is done the wrong way. You enumerate over a DOM node list
which looks like an array, which includes enumerable properties like "length".
This means that the variable "p" at some point will be "length" and
"length".innerHTML = "..." will produce an error.

The proper way is:

for( var i=0, ps=document.getElementsByTagName('p'), len=ps.length; i < len;
i++) {ps[i].innerHTML = 'Hello.';}

~~~
nailer
That's ES3. You have no reason to choose that way anymore - ES5 loops work
everywhere current, can be polyfilled into IE8, and don't require any
boilerplate stuff.

var paragraphs = document.getElementsByTagName('p');

paragraphs.forEach(function(paragraph){paragraph.innerHTML = 'Hello.';})

~~~
masklinn
Except #forEach is a method of Array, and getElementsByTagName does not return
an Array but a NodeList. Which doesn't have any of Array's methods (it has a
length, it can be indexed, and it has an alternative indexation method - #item
— but it's not an array at all)

~~~
nailer
You're right. I wasn't sure earlier, as I was typing on a phone with no JS
console.

but never mind:

Array.forEach.call(paragraphs, function(paragraph){paragraph.innerHTML =
'Hello.';})

will work fine.

------
kellishaver
This site could actually be made useful if the little area where you check
which "features" you want to include that "generated" the download file
actually caused cross-platform, native JavaScript examples of those bits of
functionality to be included in a real downloadable file.

If you really think more people should be using plain vanilla JavaScript (and
in a lot of places, I think this is actually true and even when a framework is
needed, it's good to have the underlying skill) then the way to get them to do
that is to educate them on it, not patronize.

------
hcarvalhoalves
Raw Javascript is simply not an option. The API is awful, default types are
not powerful enough and cross-platform consistency is a joke. For every
decently sized project you start in JS you have to reinvent a thousand wheels
to even get rolling, so you better just leverage a framework.

------
RandallBrown
Wow, even jQuery is written using vanilla-js.

------
scarmig
Does anyone else find the code examples absolutely damning?

Aside from not being cross-platform, VanillaJS is just plain ugly.

------
Timmy_C
Recently, I was interviewing a front-end developer candidate and I gave them a
simple JavaScript problem. The sad thing was, they didn't recognize
`document.getElementById()` and didn't know any of the parameters to
`addEventListener()`.

We finished the exercise assuming the example used jQuery instead.

~~~
rane
That's a fair assumption since most of front-end development is done using
jQuery as far as the DOM goes.

Did you expect your interviewees to have memorized APIs? There's Google so
that you can look up those when needed.

~~~
paulrosenzweig
I agree. I think it's important to know Javascript as a language well, but
there are very few cases when you'd be using Javascript without some
abstraction from the DOM.

~~~
mistercow
And in point of fact, neither of those examples are actually about JS, the
language. They're about the DOM.

------
paulrosenzweig
Was anyone else surprised by the performance penalty of jQuery? Over 400x hit
for getElementsByTagName! I'm curious whether this is more due to cross
browser checks or determining the what type of selector was used. To the
source!

~~~
masklinn
> Was anyone else surprised by the performance penalty of jQuery? Over 400x
> hit for getElementsByTagName!

Not really. Just replacing document.getElementsByTagName by
document.querySelectorAll (the native, browser-implemented version of what
jQuery does) will generate a 150-200x perf hit depending on the browser.

The reason for that is twofold: first, getElementsByTagName doesn't have to
parse the selector, figure out what is asked for, and potentially fall back on
explicit JS implementation (jQuery supports non-native selectors. In fact, I
believe you can implement your own selectors). But the parsing overhead should
be minor in this precise case.

Second, the real reason for the difference, getElementsByTagName cheats
something fierce: it doesn't return an Array like everybody else, it returns a
NodeList. And the nodelist is lazy, it won't do anything before it needs to.
Essentially, just calling document.getElementsByTagName is the same as calling
an empty function. If you serialize the nodelist to an array (using
Array.prototype.slice.call), bam 150~200x perf hit.

See <http://jsperf.com/vanillajs-by-tag/2> for these two alterations added to
the original "vanilla JS" perf cases.

There is a significant overhead to jQuery, but it's ~3x compared to the
equivalent DOM behavior, not 400x.

------
csaba
<http://vaporjs.com/> is way better, and was here first.

~~~
elliotlai
I prefer semicolon.js, more secure and reliable :)
<https://github.com/madrobby/semicolon.js>

~~~
TazeTSchnitzel
Actually, function.js is vastly superior as readers of "JavaScript: The Good
Parts" will know: <https://github.com/TazeTSchnitzel/function.js>

~~~
csaba
There is an error in the Readme. It begins with "Vapor.js is a much more...".
Should be "Function.js is...".

------
pooriaazimi
Question: is the 'Speed Comparison' for real? I find it really, really hard to
believe. Surely jQuery & co. revert to native implementations (if they exists,
as they do in all modern browsers) for things like `document.getElementById`
and don't iterate over the whole DOM.

~~~
masklinn
> is the 'Speed Comparison' for real?

Depends what you mean by "for real". The document.getElementsByTagName
comparison is bullshit: gEBTN is lazy, just calling it basically doesn't do
any work, it just allocates a NodeList object and returns.

If you serialize the nodelist to an array or use document.querySelector
instead (it returns an array) you get ~3x between the native version and the
slowest libraries, not 400x.

------
chbrown
Not sure why Vanilla JS doesn't require <script> tags, whereas jQuery
apparently does.

~~~
nivla
Both require it. Its just a marketing ploy to improve the aesthetics of
Vanilla JS.

------
suyash
I love pure JavaScript. jQuery is overrated and most libraries are only good
for one thing or the other, nothing can replace the joy and performance of
Vanilla JS!

~~~
kellishaver
jQuery is kind of a big download for mobile, so I often skip it for small
tasks.

What gets me is when people include jQuery and then further bog things down by
loading a lot of plug-ins to do things that could easily be accomplished by
adding a few lines of code of their own. Even if you do need and include
jQuery, it doesn't mean you have to use it for every piece of javascript in
your app.

Many times, a plug-in will do a lot more than you need it to do. If your
primary goal is to just get rid of the 300sm delay translating tap events to
click events, you don't need a library for full gesture support. You need half
a dozen lines to listen for touch events.

If you just need to add some client-side persistence for a few basic things in
LocalStorage, you probably don't need a plug-in with a complex query syntax.

Cannibalize a library if you need to and pull out the bits you need. You don't
have to include the whole kitchen sink.

~~~
masklinn
> jQuery is kind of a big download for mobile, so I often skip it for small
> tasks.

That's what Zepto[0] is for: jQuery's API, 20% of the size (although it drops
some features, e.g. $(selector) is pretty directly proxied to
document.querySelectorAll, so $('> .foo') works in jQuery but blows up in
Zepto)

[0] <http://zeptojs.com/>

~~~
kellishaver
Ah, last I looked at Zepto, it's support for non-webkit browsers was pretty
lacking. It's good to see they're making strides on the cross-platform
comparability front. The supported browsers list looks pretty good now.

~~~
minikomi
Been using it on mobile for about a year. It's small and snappy, and the
people behind it are very responsive & opinionated in a good way.

------
ranza
these sites are getting really old

------
Xorlev
The features generator is a nice touch.

------
pepve
I would have liked a compatibility chart between this and the other
frameworks.

~~~
Terretta
All the others rely on this one, so it wouldn't be a very fair chart.

------
gokulk
$.ajax({ type: 'POST', url: "path/to/api", data: "banana=yellow", success:
function (data) { alert("Success: " + data); }, });

can be written as

jQuery.post('path/to/api',{banana:yellow},function(data){alert("Success:
"+data);});

much simpler and easy than

var r = new XMLHttpRequest(); r.open("POST", "path/to/api", true);
r.onreadystatechange = function () { if (r.readyState != 4 || r.status != 200)
return; alert("Success: " + r.responseText); }; r.send("banana=yellow");

nevermind got the joke. but i think jQuery helps write faster code sometimes

------
phylofx
wow, the list of the companies using vanilla.js is impressive. if those put
their trust in this framework, it surely must be good.

------
Tichy
It confuses me if you describe a JS framework as cross platform. Isn't that
the whole point of using JS?

------
mfenniak
The first book listed on the "Books" link is: JavaScript & jQuery: The Missing
Manual

Heh.

------
aneth4
Given how optimized jquery is, does anyone understand why something as simple
as getting an element by id would be so much slower than Dom methods?

~~~
dgreensp
I'm surprised by the number of comments like this.

jQuery has to parse the selector and figure out that it's of the form "#id".
This requires running a regular expression. A lot more is happening.

The whole jQuery call from start to finish takes 2.85 microseconds, in what is
presumably a real benchmark, but microbenchmarks like this are hard to
interpret and basically meaningless. But yes, if your app needs to do a burst
of 350,000 jQuery calls in a tight loop and you are bummed that the whole
thing takes a full second, you should then optimize using
document.getElementById.

~~~
lukeschlather
> I'm surprised by the number of comments like this.

The sentiment is borne out by the facts when you dig a little deeper. Just
calling document.getElementById without using the return value does not
actually dig into the DOM and find the element according to this comment:
<http://news.ycombinator.com/item?id=4436438>

------
shuzchen
Get back to me when Vanilla.js has a way to handle document ready, and then
I'll believe that it's cross-platform.

------
samvj
If nothing else, the word doc look is pretty amusing :)

------
martin-adams
I want to use vanilla.js, do you think I should minify it and serve with gzip
compression? Anyone know if it will pass JSLint?

------
tjholowaychuk
nope you have to use codesmell jquery and backbone :p

------
carlosd19
hkjk

------
PythonDeveloper
ANYWAY, Lol at that... made me chuckle.

~~~
PythonDeveloper
Haters gonna hate.

------
madmax108
So many JS frameworks, so little time...

