10 ms·
Vanilla JS, fast, lightweight, cross-platform framework
Vanilla JS is a fast, lightweight, cross-platform framework
for building incredible, powerful JavaScript applications.
- csaba 14y agohttp://vaporjs.com/ http://vaporjs.com/ is way better, and was here first.
- elliotlai 14y agoI prefer semicolon.js, more secure and reliable :) https://github.com/madrobby/semicolon.js https://github.com/madrobby/semicolon.js
- csaba 14y agoI don't know... It has no tests, no generators, no ports. Not that realiable to me. :)
- leeoniya 14y agodoesn't minify or gzip at all - talk about code golf. does it lint?
- TazeTSchnitzel 14y agoActually, function.js is vastly superior as readers of "JavaScript: The Good Parts" will know: https://github.com/TazeTSchnitzel/function.js https://github.com/TazeTSchnitzel/function.js
- csaba 14y agoThere is an error in the Readme. It begins with "Vapor.js is a much more...". Should be "Function.js is...".
- PythonDeveloper 14y agoANYWAY, Lol at that... made me chuckle.
- PythonDeveloper 14y agoHaters gonna hate.
- Xorlev 14y agoThe features generator is a nice touch.
- pepve 14y agoI would have liked a compatibility chart between this and the other frameworks.
- Terretta 14y agoAll the others rely on this one, so it wouldn't be a very fair chart.
- phylofx 14y agowow, the list of the companies using vanilla.js is impressive. if those put their trust in this framework, it surely must be good.
- deleted 14y ago[deleted]
- ashray 14y agoFast 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 14y agojQuery API is not pretty
- dag11 14y agoI'll take $('p').text('Hello.') over for (var p in document.getElementsByTagName('p')) { p.innerHTML = 'Hello.'; } any day!
- deleted 14y ago[deleted]
- aaronblohowiak 14y agoinnerHTML is an easy one, try setting an attribute -- you have to create a new attribute node, set its value and then add that to the element..
- mibbitier 14y agosetAttribute()?
- aaronblohowiak 14y agoIE8 =(
- masklinn 14y ago> you have to create a new attribute node, set its value and then add that to the element.. Erm... no you don't: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-F68F082 http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-F68F082
- Timmy_C 14y agoRecently, 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.
- madmax108 14y agoIt's a common problem nowadays I guess. I honestly don't remember the last time I worked on a project with plainjane javascript. There always is either underscore or backbone or require or dojo or prototype or yui or jquery... Don't really know if this is good or bad!
- jfaucett 14y agomaybe I'm mistaken, but I think this is more of "jquery programmer" problem. jQ really abstracts away from the nitty gritty of the dom api and also for any beginner / intermediate frontend guys the source is not very readable. In comparison dojo for example, requires you know what you're doing and also to have pretty extensive knowledge about js, the dom, etc. Also, in my opinion, its source code is very clean in comparison.
- rane 14y agoThat'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 14y agoI 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 14y agoAnd in point of fact, neither of those examples are actually about JS, the language. They're about the DOM.
- ranza 14y agothese sites are getting really old
- madmax108 14y agoSo many JS frameworks, so little time...
- suyash 14y agoI 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!
- TazeTSchnitzel 14y agoIf you listen to HN a lot you'll believe everyone uses jQuery or some other framework, but that's not true. I use vanilla JS and I love it!
- kellishaver 14y agojQuery 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 14y ago> 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/ http://zeptojs.com/
- kellishaver 14y agoAh, 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.
- graue 14y agoI 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.
- rgbrgb 14y agoIf you'll look at the comment below, you'll see a rather interesting discussion going on. Jokes can be an effective way to start a dialogue.
- graue 14y agoYou're right. And now I feel bad that my whiny comment is the top-rated one, edging out that interesting discussion, but oh well. Hopefully I motivated people to prove me wrong. :)
- pacomerh 14y agoActually accepting that you had a whiny comment is what's keeping you on top, hehe. Anyways, I felt the same way, oh man another fake library that complaints about frameworks & libraries. It's alright these have to repeat from time to time, not everybody saw the last one, etc.
- pooriaazimi 14y agofrom time to time, not every other day.
- reedlaw 14y agoReading 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.
- RandallBrown 14y agoWow, even jQuery is written using vanilla-js.
- paulrosenzweig 14y agoWas 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!
- jdlshore 14y agoIt may just be illustrating the problems with micro-benchmarks.
- masklinn 14y ago> 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 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.
- SwellJoe 14y agoI suspect the benchmark is flawed, and charging jQuery for one-time penalties for every function. i.e., if you make a page that has nothing but a getElementById call, vs. loading jQuery and executing the query on the DOM, it's obviously going to be a lot slower. Even if that's not the case, "fast enough" is fast enough...and jQuery has proven itself to be fast enough for a lot of stuff. And, most developers working in JavaScript and building their own helper libraries and such are extremely likely to make worse libraries than jQuery. So, it's probably smarter to use a library that's getting a lot of vetting by really smart people. Whether it's jQuery or something else, I'm not gonna go back to hand-written JavaScript (I'm in the midst of converting an app to use jQuery from handwritten functions, and the new version is either faster or similarly fast, and maintenance of the frontend is getting vastly simpler with every element that gets converted from the handwritten functions to jQuery+Bootstrap...hell, sometimes, I'm able to just use markup with no JavaScript on the page at all...and that's like magic).
- martin-adams 14y agoI want to use vanilla.js, do you think I should minify it and serve with gzip compression? Anyone know if it will pass JSLint?
- otneusnocuh 14y agoOps/sec is a great way of benchmarking hardware and interpreters but is a poor way of rating framework vs no framework performance and usefulness. I get the point, you might not need a JS abstraction in modern browsers for some things, but the trade-offs for not being able to reference 12 million dom nodes per second are pretty substantial. And extending these frameworks usually happens in a pretty standard and predictable way which is super useful. TLDR: I'll keep this in mind next time i need to reference 12 million dom nodes in one second.
- tjholowaychuk 14y agonope you have to use codesmell jquery and backbone :p
- Tichy 14y agoIt confuses me if you describe a JS framework as cross platform. Isn't that the whole point of using JS?
- scarmig 14y agoDoes anyone else find the code examples absolutely damning? Aside from not being cross-platform, VanillaJS is just plain ugly.
- mfenniak 14y agoThe first book listed on the "Books" link is: JavaScript & jQuery: The Missing Manual Heh.
- chbrown 14y agoNot sure why Vanilla JS doesn't require <script> tags, whereas jQuery apparently does.
- nivla 14y agoBoth require it. Its just a marketing ploy to improve the aesthetics of Vanilla JS.
- eagsalazar 14y agoSites where js performance of this kind is worth the substantial increase in engineering effort and decrease in maintainability are 1 in 1000. This guy reminds me of the people who used to say they just wanted a phone when talking about smartphones or who just wanted a command line on Linux when talking about DEs.
- kellishaver 14y agoThis 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.
- pooriaazimi 14y agoQuestion: 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.
- Timmy_C 14y agoYeah, Sizzle will grab an element using `document.getElementById()` but only after checking the nodeType of the context, ensuring the selector is a string and running the selector through a regular expression.
- jfaucett 14y agoI just looked at the latest jquery and its each statement does not do a native fallback, which really surprised me. Also you have to keep in mind that a simple $('a.active').each(someFunc), has to run through the a lot of jq luggage, plus the initial http fetch of the library (which has come under criticism for its size).
- masklinn 14y ago> 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.
- hcarvalhoalves 14y agoRaw 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.
- aneth4 14y agoGiven 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 14y agoI'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 14y ago> 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 http://news.ycombinator.com/item?id=4436438
- aneth4 14y ago> 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 Seems like you might have some other optimization work to do at that point :)
- badabam 14y agothis is like being rick-rolled.... but in a more nerdy way.
- samvj 14y agoIf nothing else, the word doc look is pretty amusing :)
- gokulk 14y ago$.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
- shuzchen 14y agoGet back to me when Vanilla.js has a way to handle document ready, and then I'll believe that it's cross-platform.
- carlosd19 14y agohkjk