Wednesday, May 11, 2011

Unsolvable Problems – Why micro libs suck.

OK, actually I like micro libs. The title of this post is only part of my Hacker News Optimization (HNO) strategy, developed by my PR agency.
There has been some heated discussion in my Twitter feed over the last days and following #jsconf about the benefit and usability of micro libs.
Now one can make many good points pro and contra using micro libs but one stood out to me the most
Micro libs suck because they have weak cross browser compatibility.
As should be obvious, this is a classic bullshit argument. I can prove it wrong easily: The ultimate micro lib Vapor.js has the best cross browser compatibility of all JavaScript code that has ever been written.
Coming back to the original argument, even joking aside, it is still wrong. There might be individual micro libs with certain bugs but that is true for all environments. Roughly 99% of all jQuery modules are badly written and contain massive bugs. The situation might be better in big toolkits such as quooxdoo, dojo and Ext but why is that really?
Right, these guys actually test their stuff.
Cross browser or interoperability problems between micro libs are actually a problem of insufficient testing. Now the good thing is that we, as the JavaScript community have one pretty unique feature that will help us solve the testing dilemma:
The founding myth of the JavaScript community is not based on Perl-Angst.
Thus we may copy everything that made CPAN successful without falling prey to not-invented-here-syndrom that made gems, pips and all the others only sub-par competitors.
Izaac showed great vision at #nodeconf when he described the future of npm using TAP in the testing layer. TAP, which comes from the Perl community but really hasn't anything to do with it, is a protocol for test-runner output. It is really easy to produce, human readable and fairly easy to consume as a machine. With TAP everyone can use their favorite testing framework, even cucumberish natural language comprehension using regexes, if only it supports TAP output. On the other side we are able to build awesome tools that process the TAP output of your tests to do awesome things with it.
See for example this page that shows automated test results gathered from people installing Archive::Zip. So it mostly passes everywhere but there are some weird outliers that go wrong. Does that sound familiar? Yes, this is just like things happening in browsers.
Imagine if the awesome by Mr. Thomas Fuchs had an extra select box like this:

Using our unified testing infrastructure each library would be tested in all possible browser environments. The select-box now allows you to select which environment is important for you and only modules compatible with that environment will be shown to you. Remember, it is perfectly valid that zepto.js chooses not to run in IE. If that is important to you, update your selection and it will no longer be recommended.

Closing words
Lets build this infrastructure. I for one donate my free time starting now.

PS: Everytime I say "micro lib" you may read "module" instead :)


evilhackerdude said...

The world still has to end because of smaller, composable libraries. *cough*

In node land everything is fine due to the excellent dependency management of npm 1.0 (again, we’re not sure yet but it seems to be working pretty well so far).

The only big thing that’s different in browser land is the inconsistent underlying platform but I’m sure we will learn (if we even need to) and adjust.

I mean let’s go back to static typing. Just kidding.

John-David said...

I'm glad you mentioned the "jQuery plugin" quality problem. That is exactly the same issue devs face with microlibs. Each have different quality/features/support priorities. This puts the burden on devs to wade through the muck to find quality microlibs. The burden is even heavier when using microlibs to compose your app's core (events, dom, ajax, selector engine).

In my screencast, Microlibs: The FUD Challenge, I suggest that consistent cross-browser support is easier to achieve by using a modular/buildable framework instead of a bunch of independent microlibs. I believe this is true, in part, because mainstream/mature libs have lots and lots of unit tests :D

Malte said...

John, cool that you agree with my points. The thing is that this isn't really a debate of micro lib Vs. macro lib. Any given toolkit will never solve all known problems that are worth putting in their own module. Thus even if you use MajorToolkit2.0 you will always need extra modules on the side which again shows the need for the infrastructure described above.

John-David said...

@Malte Yep, I agree. I was just explaining my concern of using microlibs (esp for an app's core) and the compatibility issues that may result.

Anonymous said...

If they want people to use TAP freely, why is all the documentation under a restrictive license instead of a permissive one? That is only gonna cause people to avoid it; I know I will.

Isaac said...

@Anonymous Which documentation are you referring to? Oh wait, I forgot, Anonymous users are stateless...