When it comes to Web development, JavaScript frameworks have moved front and center in the mainstream in the last year and a half or so. When looking at building modern Web applications, the bar has been raised significantly by what is possible in large part due to the more accessible mainstream frameworks that are available today to build rich client and mobile Web applications. Although full featured end to end front end JavaScript frameworks have been around for quite a bit longer than just the last couple of years, it seems in the last year and half they really established themselves in the Web developer mainstream with extremely wide ranging uptake that happened very quickly. Clearly these JavaScript frameworks have a hit a nerve with the developer mainstream, scratching an itch that developers have wanted to scratch for some time, but didn’t quite have the tools to do so easily. Frameworks have filled that niche and caused a lot of developers that previously avoided complex JavaScript development to jump in head first.
In this post I describe my thoughts on how we’ve arrived here and why I think that frameworks are the new baseline that we will work and build on top of in the future. This post talks in the context of the current crop of the various frameworks that I call the V1 round that are based on current crop of shipping technologies and EcmaScript 5. In Part 2 of this series I’ll talk the V2 round that describes the new versions that framework providers are working on and that take advantage of the latest and greatest technologies built around EcmaScript 6, new and more complex build systems and a general refactoring of what we’ve learned from the V1 round. While the V2 round looks to bring many improvements, none of these frameworks are released yet and are barely even beyond the prototype stage. In some ways these updated frameworks use a much more complex eco-system which affects app integration and getting started. I’ll tackle that touchy subject in the Part 2 post.
Fast Adoption of Frameworks
It's amazing to me how quickly JavaScript frameworks like AngularJS and Ember and recently also ReactJs (which technically isn’t a framework) and even commercial frameworks like KendoUI and Wijmo have caught on and have permeated into to JavaScript developer mainstream. There are also a host of JavaScript based mobile frameworks like Ionic, Onsen Ui, Telerik’s Application Platform and NativeScript that are very mobile centric and based on complex frameworks as well.
Traditionally JavaScript components and libraries have had a lengthy uptake curve when it comes to the mainstream developers. I’m not talking about the bleeding edge developers here, but rather about the typical developer in the mainstream building business applications who typically picks tools and sticks with the technology for some time.
Framework uptake for the latter has been very quick and wide and that has been a big surprise. The last time that there was a huge spike like this was when jQuery started gaining serious momentum in the late 2000’s to the point that almost 90% of all Web sites were using jQuery. Frameworks haven’t quite reached that level yet and the spread is not as unipolar as jQuery, but at the rate framework adoption is going things are heading that way.
JavaScript frameworks have raised the bar so much that I think it’s safe to say, that a framework of some type has now become the new baseline for JavaScript development of rich client applications. In the not so distant future you may still use jQuery (or fully native JavaScript) style development for single pages or little page helpers, but as far as full client side application development goes, frameworks are going to become the norm if they haven’t already done so.
Some of the most popular frameworks in use today with the current crop of framework technology are:
For mobile frameworks there are
Several of the Mobile frameworks – namely Ionic, Onsen and KendoUI also work in combination with AngularJs or are built directly ontop of AngularJS. There’s a lot of choice out there at the moment with more choices. Currently AngularJs and derived frameworks are easily the most popular among developers, but with the V2 round of frameworks on the horizon that could very well change.
The current crop of frameworks succeed because they:
- provide a coherent framework model for development
- provide a module system that allows for code separation
- provide for easy, declarative data binding
- allow you to create components
- provide for URL based and declarative routing
- provide the support features nearly every application needs
- form validation
- HTTP services
- animation
- intra application messaging
- event management
These may seem pretty obvious now, but if you think back a few years these were all very difficult problems to tackle individually and even more difficult to manage collectively in an application.
This is where frameworks shine – they can integrate these features in a comprehensive way that is consistent and more seamless than individual components would be. On the downside you have to buy into the frameworks development model and mindset, but overall the benefits of a coherent whole far outweigh the pieced together model.
Why now?
Full blown client frameworks have really hit a nerve, solving a problem that needed solving for a long time. For years we have built client side applications without a plan it seems and it’s really surprising in retrospect that we didn’t end up here much sooner.
Patterns
In the past there wasn’t much guidance on how to build large client side applications, which often resulted in mountains of jQuery (or raw JavaScript) spaghetti code. While many of us managed this process successfully, it was also very ugly for most and involved continually learning and doing a lot of trial and error to find what worked… and what didn’t. I speak from experience when I say that I really hate looking at 3-5 year old client application code I wrote and trying to decipher what the heck I did back then. The code definitely was not as clean as I would want it to be even though at the time of building it I thought of it as following some of the good concepts and best practices I’d arrived at.
It wasn’t for the lack of trying to make things maintainable either, but somehow the nature of applications that were built using jQuery and a host of support libraries, with manual data binding and event hookups just always ended up being very messy no matter how hard I tried to organize that code. Raise your hand if you were also in this boat… I expect to see a lot of hands! Those of you that had the foresight and skill to not end up there – congratulations your are the proud few…
Not only did code often end up getting tangled very easily but it was also daunting for many developers to jump in, because in the old way there wasn’t much in the way of structure or guidance. Getting started involved mostly starting with a blank screen and then letting you figure out everything from structure to library choice to code patterns to manage application logic. How do you set up your JavaScript properly? How do you manage large code files? How do you break up complex logic? How do you split large code pieces up into separate code files and load them effectively? These are all things that are very unique to JavaScript – in other languages compilers or official build system provide some structure in terms of pulling all the pieces together and providing some mechanism for modularity as part of a UI framework for a coherent whole. JavaScript and HTML don’t have such a thing natively.
JavaScript frameworks address these issues by providing guidance in the form of a somewhat rigid pattern implementations required to lay out an application. Most frameworks provide ways to modularize code and break complex code into smaller, more testable and more maintainable modules using a pre-described syntax. While there is some ceremony involved with this today, it does provide consistent structure to modules that make it easy to separate code and understand what you are looking at.
I can admit that code modularity was probably the biggest hindrance for me in the past when building complex applications. Today you don’t need a framework for this – you can use any of the many module systems (AMD, CommonJs, system.js etc.) independently of a full framework, but frameworks abstract all of this away even further into their own integrated module systems that combine both the module loaders and other features like dependency injection in a single step. ES6’s native module system should make all of this much easier and more consistent in the V2 round for frameworks but also for those that stick with plain JavaScript.
Data Binding and User Interface
Without a framework you also have to deal with UI and application issues like how do you consistently manage assigning and reading data out of the DOM with manual data binding. There are literally dozens of ways that you can do this and often you do end up using a few different ways of doing it in an application. The fact that there’s no built in UI framework in HTML/JavaScript applications is somewhat unique and we’ve had to struggle with this since the begging of the Web.
Most other development platforms have built in support for user interface and data binding abstractions. Think about a desktop framework like WinForms or WPF or Visual Basic for that matter – in those frameworks you don’t have to worry about how the various pages are strung together or how code is loaded or how data is bound to controls – the base framework handle all that for you. In JavaScript and HTML this is not the case, so inherently there were always a million choices to make and lots of up front learning involved to pick the pattern du jour – which seems to be changing every month or so.
It’s not surprising that in those days many developers were turned off by complex JavaScript development and decided to just not go there – or at least not go the full client centric SPA application route. It is difficult to manage complex applications without some bedrock foundation and a base blueprint especially if you are new and starting from scratch. Even if you end up reading up you are likely to get confused by all the choices available.
Although there were a few solutions out there at the time – Backbone came around in those early years – those solutions tended to be esoteric and also very low level with a whole new level of complexity added on top of the existing mess. To me the very early frameworks seemed to make things more difficult rather than ease the process of building complex client side logic which is why I built my own subset that made sense to and addressed the specific problems I had to solve.
In the years preceding the current framework round I had built my own mini framework that provided base services and features I use everywhere. Some of it wasn’t optimal and while it all worked, it took constant maintenance to keep it up to do date, tweak it and deal with minor little incompatibilities amongst browsers and various other libraries. While it helped me tremendously in understanding how a lot of the underlying technologies worked, it really wasn’t anywhere near the best use of my time to screw around with this low level stuff. And I know I wasn’t the only one – nearly any JavaScript dev who was doing anything reasonably sophisticated was in a same boat building their own micro-libraries of utilities and helpers to perform many common tasks. Parallel development of the worst kind…
You might have mitigated some of this by using and combining multiple JavaScript libraries but that too had risks – integration issues and style differences and learning this or that library out of context and then dealing with the overhead of pulling in many large dependencies for a small subset of features you’d actually use. And after all that you then move to a different client and all of that learned stuff goes out the window because they’re using a difference set of customized tools.
For me and my tools it worked well enough, but it was a major pain to build and maintain that code. It’s not a process I want to repeat…
Frameworks Blitz
But all of that started to change with the advent of more capable and much more comprehensive frameworks that started arriving on the JavaScript scene a few years back.
My journey with frameworks started about 3 years ago and it took me a while to pick and choose something that worked for me. More so I was waiting out the initial pain of these then new’ish JavaScript frameworks getting over their 0. blues.
Early Days
Backbone was the earliest of these frameworks that attempted to provide a common development patter for building complex applications. When it arrived it made quite a stir by providing a relatively small blue print for how you can package application logic to build more complex applications. Personally I never got into Backbone because at the time it seemed quite complex and low level. At the time I didn’t quite get it yet because it seemed that in a lot of ways it took more code to write stuff that I was already writing which seemed a step back. But Backbone did provide the first step in providing a common and repeatable project structure that in retrospect makes a lot of sense, but didn’t really show its value until you got into building fairly complex applications.
Growing up
A couple of years later Angular and Ember started showing promise. I remember watching a demo of both frameworks on a conference video and although the frameworks looked very rough at the time, I immediately got excited because it was much closer to what I would expect of a full featured framework that provides enough functionality as to replace my own micro framework. The value over what I had cobbled together myself was immediately obvious to me, and right then and there I knew that my micro-framework development days were done. It was always meant to be a hold over until proper frameworks arrived to me, but it just took a lot longer before worthwhile contenders actually arrived on the scene.
I kept watching progress on the frameworks for a while before I tried out both frameworks and eventually started creating some internal applications with AngularJs. While both Angular and Ember have many things that are not exactly intuitive or obvious, both of these frameworks address most of the key features I mentioned earlier. The key is that they provide an end to end development solution that should be more familiar to developers coming from just about any other development stack.
Huge Productivity
Using Angular was able to build a few medium sized mobile apps in a ridiculously small amount of time compared to how long it took me to do the same thing with my old home grown toolkit. I ported over a couple of small apps from my old stack to the new and the amount of code reduced into less than a quarter of the original code. The amount of time to build the same app from scratch roughly took a third of the time which included learning the framework along the way. In terms of productivity the improvements were quite dramatic and the resulting application was much more functional to boot as new features were added. The real bonus though was letting the app sit for a few months and coming back to it and not feeling like I had to rediscover my own code all over again. Because of the modularization it was reasonably easy to jump right back in and add bug fixes and enhancements.
Modularity and Databinding are the Key
When it really comes down to it to me the two biggest reasons for productivity for me were the ability to easily modularize my code and for having a non-imperative way for data-binding. Being able to create small focused modules to back a display view or component, and the ability to describe your data as part of a model rather than manually assigning values to controls is a huge productivity win. Both of those were possible before of course (module systems abound today, and data-binding libraries like Knockout were around before frameworks started to rise), but the frameworks managed to consolidate these features plus a host of other support infrastructure into a coherent and consistent whole.
It’s not all Unicorns and Rainbows
It’s still possible to shoot yourself in the foot when you do something stupid like binding too much data into a form or using inefficient binding expressions or filters, or creating inefficient watches. I’ve run into funky databinding issues where updated model values fail to update the view or where model updates fire watch expressions in recursive loops. Stuff does go wrong and then requires some sleuthing into the framework.
Sometimes you have to fight the framework when you’re doing things slightly different than it wants you to do things. But in my experience that is rather rare, and when it does happen I can always fall back to low level JavaScript at that point and manipulate the DOM manually. The way I see it you’re not giving up very much – you still have all the low level control even if that is often frowned upon in the framework guidelines.
Frameworks have brought in a ton of new developers to JavaScript including a lot of them who know very little about the esoteric nature of how JavaScript works. Lets face it – JavaScript is one func’ed up language, but it is what we’re stuck with in the browser – I’ve given up fighting it and try to make the best of it by understanding as much of its esoteric nature as possible although my rational mind struggles with many of the illogical language ‘features’. For developers inexperienced with JavaScript it can be difficult to understand where the seam is between framework and underlying language and JavaScript’s funky behavior makes it easy to get into trouble when you don’t know the language quirks. The best advice I have to developers new to JavaScript is spent some time reading up on the core features of JavaScript. Still the best and most concise book to start with is still Douglas Crockford’s JavaScript: The Good Parts. And then spent a few hours coding through some of the scenarios mentioned in the book. Understanding closures and variable scoping, floating point number behaviors and the DOM event loop are probably the most relevant issues you have to understand when working with these frameworks.
JavaScript frameworks bring to mind the old adage: With great power comes great Responsibility and when you give very powerful tooling to developers who may not understand the underlying principles or even core components of the JavaScript language, it’s easy to end up with complex applications that are badly engineered and look 
like steaming piles of spaghetti code. Functional – yes. Maintainable – not so much. But compared to managing the complexity without a framework the level of spaghetti-ness is actually more manageable because at least there are isolated piles of spaghetti code in separate modules. Maybe that’s progress too…
Much of this is due to the fact that the current crop of frameworks – while very powerful are very much 1.0 versions. Their first implementations of a general vision and the developers of these frameworks initially focused on making things possible rather than making them easy or maintainable. The latter concepts have come much later and while improvements have been made to improve maintainability, performance and usability in many cases a lot of the improvements have been bolted on. Version 2.0 of most of these frameworks which are under construction, are all from the ground up re-writes that aim to fix many of these early implementation issues. Whether that’s the case we’ll have to wait and see (and I’ll talk about this topic in Part 2).
What took us so long?
If I had to summarize why this wave of frameworks has been so successful I’d argue it’s because they’ve provided us with a base blueprint for how to structure an application as well as providing a powerful and easy way to handle data binding. That has been one of the huge missing pieces that has made JavaScript development of anything non-trivial in the past such a pain.
In retrospect it really seems crazy that it’s taken us this long to get to this point. Navigation, data binding, form validation, event management, http services, messaging – those are all things that any even moderately sophisticated application needs, so why the heck were we constantly reinventing the wheel over and over again each in our own individual ways?
It’s amazing that we’ve come this far in client side Web development and have made due without a base framework layer. Most other UI platforms provide you a base framework. Just think about tools like Visual Basic and FoxPro in the old Win32 days, WinForms and WPF on Windows, Cocoa on the Mac – all of these provide base frameworks to build applications along with build systems that know how to bundle stuff so you can run things. You don’t worry about how to modularize your code, or handle databinding – it’s part of the system itself.
JavaScript is more like a raw language like C# or Java, but one that never had a proper UI framework to go along with it. Would you build your own UI framework in C#, C++ or Java? I doubt it – but that’s exactly what we’ve done with JavaScript in the Browser until recently. A UI framework and general organizational abstraction layer is generally accepted as a standard part of a development platform and JavaScript has just never had that until recently.
The advent of more capable – and also bigger – JavaScript frameworks has brought a renewed interest in JavaScript development. Frameworks have caused a lot of developers that were previously deferent of JavaScript to jump in head first.
I’ve been surprised to see uptake of frameworks – especially AngularJS – in companies that previously were ferociously anti-JavaScript. I’ve also seen relatively inexperienced JavaScript developers able to build fairly complex and very functional applications with these frameworks. I work with quite a few developers who are very slow to adopt new technologies, but quite a few of those who have ignored a lot of other technology trends in the past, are all of a sudden very gung-ho and are jumping in with both feet into JavaScript frameworks and producing good results.
It’s not hard to see why: Client side application development in the browser has been on everybody’s radar for a long time all the way back from the early days when IE first rolled out the XHR object and DHTML forms in the late 90’s (which all other browser vendors snubbed at until 10 years later). It’s something that most developers can clearly identify with but it’s something that’s been really difficult to do right for a long time.
JavaScript frameworks provide a much easier point of entry to build rich client Web and mobile applications and that is a good thing.
Open Source is a Key Feature
JavaScript frameworks abstract some of the hard-won experiences about what works and what doesn’t when it comes to DOM manipulation, JavaScript quirks and best practices regarding performant JavaScript. Much of this information is hard won from the experience of thousands of users that use the code and often report as well as fix bugs. The fact that all of the big frameworks are open source and developed by a large number of developers is no accident – it’s a necessity to deal with the complexity that is involved in managing so many different browser execution environments that we still have to run in. It’s made it possible to take advantage of the group mind to build better solutions. So many more people can be involved in this process of reporting and also fixing issues that simply transcends what a single developer or even a private or corporate entity accomplish.
These projects uniquely benefit from the open source development model and it’s a key component to the success of these frameworks.
Too much, too big?
There are those that decry JavaScript frameworks as bloated, do-too-much pieces of software and the truth is you can do all of these things yourself today either by writing your own or piecing together various components to provide similar functionality. It’s easier today than it was 5 years ago, as lots of new libraries have sprung up to provide support for key features that you see embedded in frameworks today.
It’s a viable option to build your own micro-framework, but the problem is that it takes a much higher level of JavaScript developer to work in this space and even then I’m not sure that you would build something that is as capable and certainly not as competitive. As developers we should strive for a sense of unity, not rampant individualism so that code is more portable and more understandable across applications. This approach might still make sense to a small subset of developers, but for the mainstream I cannot point to any serious downsides of using a framework.
I also find the size argument dubious at best. Most sophisticated applications use a ton of functionality that these frameworks provide. And while their script footprint is not small, if you were to piece together even half of the feature set from other more specific libraries you’re just as likely to use the same or bigger script size footprint. Yes there’s a price of admission but at the same time it’s worth it. For example as of Angular 1.4 the size of the minified and compressed gzip file is 45k which is hardly a deal breaker in my book. Anybody who complains about that – especially after subtracting whatever size a custom set of libraries would take – is micro optimizing in the wrong place. Granted you may still have to add a couple of additional small support libraries for routing and miscellaneous specific add-on features, but the overall footprint is still anything but large for the amount of value you get from roughly the size of a medium sized image.
The argument that building your own tools and frameworks helps you learn more about the stack you work on certainly is a valid one. I’ve followed that approach for much my developer life, but I’m finding it’s getting too damn difficult to keep up with the changes in technology and especially in JavaScript where things are changing too fast to keep up with. The level of complexity of what we’re trying to build these days has also ratcheted up considerably from what we built just a few years ago and it’s difficult to build that level of complexity from scratch. The latest rounds of upheavals – leading to ES6 and all the new build system technologies are making my head spin. If you’re component or library developer you have to keep up with all of this in order to keep your code compatible.
The way forward is to be a part of something bigger and contribute rather than to reinvent the wheel in a different way yet again.
We’re not going back
There's clearly a lot of demand to build rich client side applications on the Web and all of these frameworks address the sweet spot of providing enough structure and support features to make it possible to build complex applications with relative ease.
To me it’s obvious that the days of low level JavaScript for front end applications for the average developer are numbered and baseline frameworks are going to be the future for the majority of Web developers that need to get stuff done. The productivity gain and the fact that the frameworks encapsulate hard-won knowledge and experience about quirks and performance in the DOM and JavaScript, make it impractical to ‘roll your own’ any longer and stay competitive in the process.
As time goes on these frameworks are only going to get more sophisticated and provide more functionality which will become the new baseline of what is expected for typical Web applications. As is often the case technology ends up sorting itself out and building on top of the previous generation to extend new functionality. We’re building a tower of Babel here and we’re already seeing that happening with the next generation of several of these frameworks like AngularJS 2.0, Ember 2.0 and Aurelia all of which are seriously overturning the apple cart by moving into the latest technologies involving EcmaScript 6 language and build system features. We’re in for a rough ride for this next iteration of frameworks.
But – we’ll leave that discussion for Part 2. In the next part I’ll address the complexities that I see with the next generation of these JavaScript frameworks that attempt to bridge a whole new slew of JavaScript standards and functionality along with new tooling and to help build us the next generation of sophisticated client side applications.
Stay tuned…
Read: The Rise of JavaScript Frameworks - Part 2: Tomorrow
Other Posts you might also like