Javascript Frameworks Are Too Small

by Gordon. 5 Comments

A while back I stumbled upon a great post by Jean-Baptiste Queru. It describes the incredible depth of the modern technology stack. Layers upon layers of complex science, hardware, and software, each layer creating a simpler abstraction around the previous. This ultimately enables our paltry human brains to create amazing things that would otherwise be impossible (or really difficult). This is, in my opinion, the lifeblood of modern software development.

For some reason, however, when it comes to front-end web development – meaning javascript – the stack is extremely shallow. Most websites are built on top of native browser functionality with a sprinkling of jQuery and little else. Moreover, this is true even to the extent that it is embedded in the developer culture itself. Javascript frameworks are lauded for their small sizes and even smaller feature sets. Sites exist exclusively to categorize and compile lists of these “micro-frameworks”, exacting requirements of less than five kilobytes.

This is not to say that significant value can’t be created by a framework with a small codebase. However, given the choice between two frameworks with equally well-written code, I would probably opt for the larger framework1. Choosing a framework for its small size is a premature optimization. Taking this a step further, given a choice between tying together two unrelated “micro-frameworks” and one larger framework, I would definitely opt for the latter.

Tom Dale begins a similar post with the following:

Why does it take big teams, big budgets, and long timelines to deliver web apps that have functionality and UI that approaches that of an iPhone app put together by one or two people?

Although I’m not going to comment on the number of people required in either case, I completely agree with the implicit assertion that mobile development is more efficient. As a developer who has been building desktop, web, and mobile applications for years, I have always felt that, specific to web development, a larger amount of energy goes towards dealing with the frameworks involved, rather than the problem being solved. There is also an uncomfortable, almost nauseating, feeling that my code is not as modular and reusable as I would like and have come to expect from other development stacks.

The reason for this is that javascript frameworks are simply too small and unstructured. Client-side web developers are not building atop strong enough abstractions to bring their efficiency up to par. Even backbone.js, the web’s darling client side javascript framework, weighs in at a mere 4.6kb. Having built an application against backbone, I can attest to the fact that it more closely resembles a philosophy or set of guidelines to develop against rather than a full fledged UI framework.

Yes, I know larger javascript web frameworks exist. SproutCore, Cappuccino, and Google Web Toolkit come to mind. I hear good things about all of these frameworks. However, none of them have come to the level of ubiquity that one would hope. They all suffer from similar ailments: being constraining and forcing a particular native-like paradigm. For instance, there is no reason for a web framework to implement it’s own layout manager. HTML 5 is probably the richest layout system in existence and most modern heavily-designed web applications prefer direct access.

I am constantly searching for a modern client-side javascript framework that has the right level of abstraction. Today, I am extremely excited about Ember JS (formerly SproutCore 2.0). It adds some deep layers of functionality without the constraints and bloat of the original SproutCore. I think it will continue to evolve into an amazing framework. For the future, I am excited about initiatives such as DART. Despite receiving a lot of negative criticism, DART looks promising as a new language for the web (although I would have preferred a raw VM). Particularly, I feel that the awkwardness around implementing packages and re-usable code in Javascript is partly to blame for the current state.

In any case, as web applications continue to become increasingly complex, the emergence of larger and richer frameworks is inevitable – and it’s about time.

1. It is important to clarify this choice with respect to size and horizontal bloat. Here I am using the term larger to denote a framework which has a stronger abstraction/more utility for what I am actually using it for (as opposed to a bunch of unnecessary features).

  • Kirk Is

    Interesting article link you posted. Why don’t we have as many layer of abstractions for web development? One answer might be, each of  levels Queru describes is built on a REALLY reliable and well-engineered level beneath it, and there isn’t that kind of solidity under JS/HTML5. But I think the other answer is: it’s not necessary, at least for a certain kind of developer.

    I can’t even tell you how foreign I find your proclamation ”given the choice between two frameworks with equally well-written code, I would probably opt for the larger framework”  

    There’s a valid outlook that’s the opposite of this: it says, I want to learn as little new as possible to get the job done, to minimize the mental load my tools are causing me. Toolkits with lots of abstraction often don’t have good power/weight ratios; they’re not much more expressive than more basic toolkits, but there’s a lot more you new unique knowledge you have to keep in your head to use them properly (lest you become one of those Microsoft-y types, who can do decent stuff but have NO idea what’s going on under the hood, or how to fix it when it goes wrong in a deep way.)

    I think more abstract toolkits tend to program in nouns… “configure me correctly/learn which of my calls will do your bidding, and I’ll do all the “tough work” and you can keep commanding on high rather than dirtying your hands in the trenches”. But the cost of that comes in debugging, where suddenly the result of your bug is more likely to be farther away — “physically” in the files, mentally in the abstraction — than if you kept your toolbox nice and light and focused on the solving the problems that are actually a pain in the butt to keep resolving. (jQuery being one of the shining examples of awesomeness for the latter.)

    I agree that “a larger amount of energy goes towards dealing with the frameworks involved, rather than the problem being solved” but not in the sense you mean: finding people who know the intricacies of a new stack, or training up people to get that knowledge, is the expense…

  • http://www.facebook.com/d4tocchini Dan Tocchini

    great article. we’re mostly on the same page…

    concerning your statements on larger javascript web frameworks.  i agree that they fail b/c such monolithic systems have rigid paradigms, i.e. its impossible to add simple custom UI abstractions.  they require you to use their components, try and make one yourself, and its way worse than the  HTML / CSS stack.  That’s why Ember is so cool, it’s mustache templates + simple js object binding = which allows custom UI stuff.  and, if you’re building an ‘app’ you need solid, customizable UI abstraction.

    I actually disagree with your statement that larger js frameworks shouldn’t EVER handle layout.  first off, by HTML5 layout, i’m assuming you mean CSS3, and any good ‘layout manager’ would just do the CSS3 stuff for you, like Masonry / Isotope.js.  go ahead try to do that with CSS, you’ll need a shit load of javascript to abstract it for you.  second of all, CSS3′s layout mechanisms are antiquated and impotent.  To quote Alex Russell, from http://infrequently.org/2012/02/misdirection/:

    “CSS is absolutely the worst, least productive part of the web platform” 

    “CSS has the weakest escape hatches to imperative code and demands the most world-view contortion to understand its various layout modes and their interactions. Imagining a more congruent system isn’t hard — there are many in the literature, might I humbly suggest that now might be a good time to read Badros & Borning?”

  • http://www.logopearl.com/ Logo Design Service

    So use html5 frameworks it satisfy your work. Custom Logo Design

  • http://www.logopearl.com/ Logo Design Service

    html5 framework will get you out of this problem. Custom Logo Design

  • Chandan Kumar Sah

    Such a nice information you shared in this article, I really like it and I must share that company which I have used for my Company Logo Design & for my website Explainer Video. Standalonemarkerts, They worked very well.