I’ve been an advocate of JavaScript client-side frameworks for some time. Their true value is in managing complexity: as an application grows more complex and incorporates more functionality, frameworks provide a level of guidance and consistency across the codebase. They enforce the right abstractions, encapsulate reusable and generalizable components, which ultimately serve to keep the site maintainable. At least, that’s what JS developers ought to be thinking about in picking frameworks.
When I read this article pointing out supposed problems with the AngularJS framework, I was hoping for some points on whether Angular fulfills those needs of abstraction and maintainability, correctly balanced with its flexibility and ease of use. As far as I can tell however, the author dismisses Angular as a framework that appeals to Java developers, while insisting that front-enders have developed their own coding styles and are thus resisting the Angular Way™. Throw in a few well-publicized performance shortfalls, and it’s easy to dismiss the framework as lacking.
Fallacies aside, the article did make me step back to identify this so-called “front-end coding style.”
One interpretation would be that many front-end developers have cobbled together their own coding style from various preferences and best practices, and feel comfortable with essentially their custom framework. Building one’s own JavaScript framework is a quintessential rite of passage1, and any perceived deficiencies can be patched or worked around in an ad hoc fashion. This attitude is simply Not Invented Here rebranded, though it’s unusually strong with front-end coding, I suspect due to how easy it is to weave arbitrary structure from nothing.
A kinder interpretation is that high quality web sites/apps require low-level coordination between its HTML, CSS, and JavaScript, and most frameworks either abstract away these relationships or just provide raw APIs. JS MVC frameworks tend to care about organizing an application’s components more than the intricacies of delayed animation events and precise DOM structures2, and so digging into frameworks to increase animation performance or fighting its structure to modify pieces of internal state become frustrating exercises. That is, most JS frameworks are built at still too high of an abstraction level.
Another…less kind way to interpret resistance to adopt MVC frameworks is that most front-end coders are happy writing and consuming unstructured code. The vast majority of JavaScript written in the world are mashups of jQuery plugins and event callbacks, and making a loose approach to code organization sacrifices long-term maintainability for immediate gratification. That said, simple functionality should only require simple code, and jQuery spaghetti is perfectly serviceable for small sites that aren’t looking to survive redesigns. In these cases, implementing an MVC structure is admittedly over-engineering.
None of these scenarios, however, exclude the legitimate need for the standardization and modeling of code in complex web applications3. Forgoing frameworks for the sake of simple functionality should be a measured engineering tradeoff, not a refusal to understand the underlying principles.
I’m only half-joking; I have interviewed a handful of folks who proudly show off their portfolio of sites built on top of their own creations. It’s serviceable as a learning exercise, but not as a showcase of good engineering practice.↩
Though not a JS framework per se, Google Web Toolkit (GWT) focused on abstracting away the browser client at such a high level that even just getting to the DOM was an unpleasant experience.↩
Despite the accusation that Gmail and Google Plus don’t use Angular – they’re giant apps that were written way before the framework was even conceived – the style they’re written in, with the Closure library, resembles Java code and embodies many of the same best practices.↩
