Re:Microjs: an index of javascript micro frameworks
by derefr on Saturday March 17, 2012 @01:56PM
(#3717636)
> there is no necessity to load huge JS libraries with lots of utility functions which one might not be using.
I think we really need to see a tracing link-time-optimizer for Javascript code that can be run as part of an asset pipeline. Dump in your huge JS library, run your client scripts (with a thorough test suite) to detect what functions of the big library are or aren't called, then cull off the functions that aren't when writing out the final "compiled-and-linked" client library.
Re:Microjs: an index of javascript micro frameworks
by firefoxman1 on Saturday March 17, 2012 @02:12PM
(#3717682)
That's a really good idea. In the meantime you could use jquip which cuts out a lot of the commonly-unused jQ stuff. https://github.com/mythz/jquip
Re:Microjs: an index of javascript micro frameworks
by chi_h on Saturday March 17, 2012 @04:22PM
(#3718086)
Google Closure and GWT both do exactly that - they use static analysis to cull code which never gets called. You can't use them with standard JS libs though - JS code needs to be specially marked up to use that feature in Closure, and GWT development is in Java.
GWT takes the idea one step further - the code splitting functionality lets you define split points, and code that only ever gets called behind the split point does not need to be downloaded on page load, but can instead be downloaded when that split point is first reached.
Re:Microjs: an index of javascript micro frameworks
by revorad on Saturday March 17, 2012 @03:11PM
(#3717894)
Unless the optimizer made sure that it didn't inadvertently break any cross-browser compatibility, you would lose one of the biggest benefits of libraries like jQuery.
Re:Microjs: an index of javascript micro frameworks
by derefr on Saturday March 17, 2012 @03:44PM
(#3717969)
Right; I imagine library authors would have to adopt some sort of conventional annotation on functions declaring something like "if you execute any function in the set {X,Y,Z}, you have to include all of {X,Y,Z}, because they're cross-platform equivalents for one-another."
Re:Microjs: an index of javascript micro frameworks
by edwinnathaniel on Saturday March 17, 2012 @04:24PM
(#3718090)
GWT solves this problem a few years ago.
Re:Microjs: an index of javascript micro frameworks
by ramanujam on Saturday March 17, 2012 @04:30PM
(#3718107)
When we strip out or modify parts of a library's code we bring onto ourselves an unwanted task of patching it whenever there is a update. Living with the old working version is fine but not very optimal. Say if you made a custom version from jQuery 1.4 i bet it would be painful to update the custom version to use the current release ensuring cross browser compatibility.
Re:Microjs: an index of javascript micro frameworks
by derefr on Saturday March 17, 2012 @04:53PM
(#3718164)
You don't strip it out manually; you run the compiler on it. When you get the new version of the library, you update that library to the newest version (by simply replacing it) and then run the compiler again. You're never manually touching/modifying/updating any of the "object code" coming from the compiler, just regenerating it from scratch.
Re:Microjs: an index of javascript micro frameworks
by mhansen on Sunday March 18, 2012 @08:08AM
(#3719564)
This is what Closure Compiler does, without the need to even dump in a large test suite.
Re:Microjs: an index of javascript micro frameworks
by stdbrouw on Saturday March 17, 2012 @03:35PM
(#3717951)
Considering jQuery is available on Google's CDN, and lots of websites just fetch it from there, it's not necessarily true that using a smaller library will actually translate into slower load times in most cases. Similarly, if you concatenate all your javascript together, that gets rid of the main culprit where slow page loads are concerned, which is latency, not file size.
Re:Microjs: an index of javascript micro frameworks
by pamelafox on Sunday March 18, 2012 @01:08AM
(#3719167)
I ended up porting from jQuery to Zepto for my mobile PhoneGap app, where the files are stored locally. Porting to Zepto resulted in performance gains due to the browser taking less time to actually parse the JavaScript. Here's a blog post I wrote with more info and performance comparison: http://blog.pamelafox.org/2011/11/porting-from-jquery-to-zep...
Re:Microjs: an index of javascript micro frameworks
by timc3 on Saturday March 17, 2012 @03:54PM
(#3718002)
That's not the whole point, even if it's in your cache it takes time to evaluate. Jquery and jqueryui together are taking 300ms in my chrome - blocking the page painting
MicroJS is a good resource. I am wondering how many of the frameworks listed there are actively developed/maintained. Adding the last commit date information might be super useful.