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
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.
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
- 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.
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.
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…
Data Binding and User Interface
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.
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…
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.
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.
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.
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?
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.
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.
Open Source is a Key Feature
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?
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 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.
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.
Other Posts you might also like