Really?

There’s a fresh debate raging in the JavaScript community. The battle lines are drawn between those who like all-in-one solutions for app development, and those who prefer to assemble the pieces themselves. Really, the fight is more between those who make these things, not those who use them.

A site for the little libraries

The recent ugliness was sparked by microjs.com, a small project which aims to list some of the more useful tiny (5K or less) code libraries out in the wild.

Then the flames started spewing over Twitter. The brunt of the griping was focused on @thomasfuchs (of script.aculo.us and zepto.js fame) and @ded (ender.js and about 100 other handy things). Arguments generally centered around the size limit (5K): “that’s so arbitrary, why can’t my lib get listed too” (generally followed by much wailing and gnashing of teeth).

Short answer: it’s their list. Hand picked from their own survey of useful-yet-small projects out there and from selecting submissions from library creators. I’m going to repeat that first part: it’s their list. It got attention, and those small-yet-useful libraries in there are going to get some exposure. Those of us with libraries or frameworks which are larger and lean towards providing a bigger bundle of useful things should chill (don’t make me name names, cause wow).

I have a couple things up on GitHub: Jo (~15K gzipped) and TurtleWax (~0.7K gzipped). Guess which one got on the list? Yeah, the tiny, single-purpose library. Did I try to get Jo in there, even though it’s arguably the smallest of the mobile app frameworks out there? Hell no, it’s 10K over the limit.

Both sides argue simplicity is a big part of their approach

There are just differing ideas of “simple”.

Some developers prefer building things from scratch. I do, too; that’s why I often make my own libs, even for in-house projects. Most of these folks prefer the simplicity of a blank canvas on which to work, and will only occasionally use something small and useful written by someone else. They generally don’t want to have to learn a large framework, because it’s an added layer of complexity which could make their apps bigger, sluggish, and potentially more buggy than if they did it all themselves.

Other developers prefer to code less, or at least spend less time fiddling with things that in many cases should already be built into browser engines. The drive here is also simplicity, but from a time-to-market standpoint. The idea is, pick a framework which seems to do as much or more than you need, test it out a little, then ride that horse from then on. If there’s a bug in the framework, work around it; or better, fix it and contribute back to the project.

My lib is smaller than your lib

Does size matter? Actually, it kind of does. Generally, the smaller the file size, the easier the lib is to learn, and the less load time your app is going to have if you use it. Plus, the idea is your app will have just what you need to get the job done, and little else.

This idea can even spill over to the framework side of the equation. One of the hard requirements I have for Jo is to keep it under ~20K gzipped. Is that arbitrary? You bet. The thing is, setting a limit like that makes me a better product manager and a better coder. I’m mercilessly against feature creep and I work hard to keep cruft out of my codebase. Who benefits? The developers who use it (bless their coding fingers).

The best approach…

…is your approach. Look very closely at what’s out there, and go with what suits you and your project best. Every single lib out there will have bugs, or something extra you didn’t expect, or something that might take some getting used to. It’s all about finding things that are natural to your way of doing things.

Hell, there’s no reason you can’t dip from all ends of the code pool. You might even dig something frameworkish like Jo or Sencha Touch, and still have a yearning for some special feature or two. And hey, one of the little libraries listed in microjs might fill that void.

Advertisement