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.
Source : http://codebrief.com/2012/01/javascript-frameworks-are-too-small/
