Early this year, I began on a self-righteous (but approved, of course 😉 ) journey to make things right for my project — to break all shackles and limitations that the team faces in working with older technologies, methodologies and guidelines. When I started off, my aim was to make as minimal-but-essential changes to the system as possible, keeping in mind that my project is a live one, having at least 100 MegaBytes of code, with around 16 developers contributed to this application — in batches, of course — in the past 8 years, each having their own signature style of coding. Needless to say, there were more than a few tasks for research in this journey of mine.

One such, important analysis was to decide what UI methodology should the team adopt going forward. This blog post will focus on the analyses and decision-making process that made it happen and finally helped me decide on Angular 2.

Problem Statement

Setup a robust system to keep my front-end application development well-defined, efficient, maintainable and scalable.

• Well-defined: A well-defined philosophy on software design and development
• Efficient: A system that aids speedy yet accurate software development
• Maintainable: Writing code is very easy, maintaining it is what bursts the bubble
• Scalable: As in, be there only 3 developers or 30, only 3 features or 3000

Environment and Constraints

My application environment and associated technical and business constraints:

1. Long running project — stable, live and profitable business with active customers
2. Large codebase — code maintainability more important than flexibility
3. Current front-end tech stack (high-level) — Server-side: Classic ASP.NET v4 using C# & VB; Client-side: Vanilla JS, JQuery, Knockout JS; Extensive iframe usage
4. Existing front-end structure and infrastructure does not support modular, component-based front-end development in a clear, easy way
5. Less experienced UI developers — never worked on full-fledged front-end frameworks
6. Resource constraints — team of 1 lead, 3 developers and 1 QA; having a full-time senior system designer/gatekeeper is not currently feasible
7. Lack of automated testing infrastructure for front-end
8. Backward compatibility with existing application — any revamp or overhaul has to happen in phases; cannot be all-or-nothing.

Development principles

Following are some core values and qualities that I would want my team members to have:

1. Design and write quality code with modularity and reusability as primary focus
2. Be able to separate/decouple technical components from business logic
3. Know when it is OK, or essential, or NOT, to couple logic/make a trade-off
4. Create super fast and scalable pages without manual supervision
5. Write testable code and test cases without excuses or exceptions

In general, every developer does want to follow good development practices, but may lack expertise, guidelines or project infrastructure to do so. Although, the above qualities get refined only with experience, that is too much for a manager or system designer to bet on. Working with a good framework helps set the right tone early on. Hence the push.

Front-end framework checklist

To build good, clean, reusable user interfaces for my web application, following are the qualities I chose to have in my front-end framework-to-be:

1. Should have dependency resolving capability, including dynamic dependency injection (optional on-demand loading instead of compiling everything into one resource)
2. Should have good, straightforward and flexible Router API
3. Should easily integrate existing modules, features and libraries, etc. of the application
4. Should not be rigid or incur too much learning curve for the team
5. Should have a clean templating system (model-view binding)
6. Debugging production code should be straightforward
7. Deployment process should be straightforward
8. Should have (automated) capability to minify and version JS code
9. Should have browser cache-buster mechanism
10. Should have good community support
11. Should have easy integration with a testing framework
12. Should help set a sustainable development environment, even if at the cost of flexibility, i.e. convention over configuration

Round I: Lemme bake a custom framework

My first attempt was to build a custom, application-specific framework. My app is built on ASP.NET v4.0 with traditional .NET code in VB and C#, server-side content rendering is predominant, with JavaScript libraries and micro-frameworks used at various places as felt needed, not necessarily always considering the big picture. Hence, to incur minimal changes to the existing application, it made sense to build a totally custom system. Coincidentally, around that time, I read about no more frameworks too, and it inspired me all the more. However, there were two important findings:

1. When trying hard not to use any existing frameworks, you end up creating a framework anyway (yours!). Combining everything together is a major undertaking as you have to know all these concepts and their corresponding libraries.
2. Once you do have your system set up, maintaining it (technical gaps, debts, communication between two modules, etc.) may be a huge liability in the long run.

Was the team ready for that? No. Hence, I had to move on.

It is worth mentioning another key realization: You are better off rendering your content either server-side or client-side, but not both; else you end up having your code and business logic in both places — server and browser. This is the reason why my perspective changed altogether from making minimal changes to installing the right system, even if it required a rewrite of the application.

In a perfect world, my decision would have been simple: Stick with server-side rendering — .NET provides a comprehensive set of tools and utilities to achieve almost everything. But, back to reality, server-side is too snail-paced when compared to front-end frameworks. The latter wins hands down.

Round II: My rundown of popular JS frameworks

As obvious, my next alternative was to check out the available frameworks out there — Ampersand, AngularJS, Angular 2, Backbone, Ember, and React. I have added links to some articles in Appendix I at the bottom that helped me theoretically analyze the Pros and Cons of each framework. They also helped me choose or eliminate each candidate quite decisively at an early stage, instead of me having to try each one hands-on and then make my decision.

Not going into details, let me just say that most of them did not make the cut for various reasons, like not being wholesome or now older technology or unimpressive community support.

I could not React either

I think ReactJS needs a special mention though, as it is a really wonderful library and is preferred by a lot of people. Talentica also did a research on available frameworks recently and liked React a lot. Anyway, so let me take a point-by-point dig at it based on my requirements.

1. (CON) Framework and setup: First, React is not a framework — it is a view layer library. Sure, there is Redux and other micro-frameworks or libraries in the React ecosystem that would fulfill my other criteria, but, given a choice, I would prefer not to try fit all pieces of the puzzle myself.
2. (CON) Learning curve: To make best use of this system, learning Babel and the ins and outs of this framework would be a necessity.
3. (NEU) The amazing templating system (modal-view binding along with JSX) of React is somewhat now available in Angular 2 as well. So, it is not a USP anymore. (Although, there are other views suggesting that React has still got it right.)
4. (NEU) Ease of adoption: React is very easy to adopt in an existing application. Its flexibility to fit it in anywhere is what makes it so popular and loved. But flexibility or ease of adoption is no longer my primary criteria, because my application requires a restructure anyway.
5. (PRO) Virtual DOM: I would definitely miss this USP. However, it is not a necessity for my application as it does not contain a lot of complex views and workflows that I need to worry about speed.
6. (PRO) Maturity: React is now a few years old. It is totally stable and reliable today. (Personal opinion: But it somehow failed to impress me with its future plans.)

Round III: An acute Angular 2 analysis

I’ll cut right to the chase.

1. (CON) Learning curve: of this new framework (and language) is definitely going to be a little steep at the beginning; a little more than other frameworks. (I have to plan to transition and execute this in a streamlined manner.)
2. (CON) New framework argument: Agreed, Angular 2 is a new framework that has not been battle-tested. But, I think my optimism is reasonable that this framework will not have catastrophic failures, given that Google has its back.
3. (CON?) Typescript: The future of this language (superset of JS) is unknown. Will the developer community embrace this new language or will it fail? If you listen to what is being said about this language over internet, most of them are positive, but only time will tell. Worst case, if it does not serve me well, I will have to make a decision to switch to the JavaScript version of Angular 2. Given that Typescript compiles to JS eventually, I’m hoping the decision to move to the JS version will not be earth-shattering, if at all.
4. (NEU) Beta argument: Angular 2 was still in Beta phase back then (May 2016). If you go by popular views, Beta = Bad for production. But here is a slightly different, practical perspective:
   My project is not going to start until Sep 2016. Even by considering a worst case release date of 1 year, I would still be fine having a Beta Angular 2 app in production already, as it is highly unlikely that the most basic elements (which practically will be the only things my team would use in the near future) will have breaking changes after Angular’s full release. So the amount of work/rework would not have been an issue.
5. (NEU) Ease of adoption: Converting existing application components and libraries is definitely not going to be easy. But, in all fairness, I would have had to do it with any other framework too.
6. (NEU) Lock-in argument: usually goes like, “Your developers are now locked on to this platform with closed boundaries and constructs. Nor will you be able to readily integrate other libraries or tools.”
   1. For an old and ongoing project with limited number of developers, having convention over configuration will be helpful than detrimental in the long run.
   2. Point taken about integrating libraries. Sure, it will be slow, but this is where community support is going to make a difference. See the contributions already within a month since A2’s first full release.
7. (PRO) Performance: Angular 2 has made sure to learn from its mistakes in v1. You can expect your app to scale stably enough.
8. (PRO-10) Framework and setup: Overall, referring to my criteria again, Angular 2 satisfies almost all of them, except #3 and #4 criteria. I get a wholesome framework, end-to-end, and I think that is really exciting.
   (PRO-10 is my nerdy way of saying 1o Pros, 1 for satisfying each criteria of mine 😛 )

Ding-ding-ding!

And there’s my winner: Angular 2

A more generic ending note

As an ending note, I would like to repeat my earlier statement: You are better off rendering your content either server-side or client-side, but not both. And, in my opinion, the latter would be the better choice in today’s world. On a side note, by any chance, if you are worried about search engine crawlers, Don’t be! This is not the 90’s. Crawlers today can crawl pure JS-based websites flawlessly — I’ve seen proofs myself.

Second advice: For an already or soon-to mature application, you must consider convention over configuration. You, as a technology or system design gatekeeper, cannot afford blaring gaps in your application cropping up time and again.

Having said all this, a wholesome single page app still has the potential to become a performance and/or maintenance nightmare if not used correctly, and Angular 2 is no exception either. But, I think this is applicable to any language, tool or technology. Hence, strictly speaking, it is up to the senior designers and developers to maintain application structure well and raise flags whenever they find any systemic issues, instead of finding a quick workaround.

Finally, I cannot stress enough that using a front-end framework in an application is not just about making cool, snappy UI — it is much more about providing the right direction to developers so that they can develop solutions better, faster.

Angular 2 being the right fit for me does not mean it will be for YOU too. So, choose the framework that works for you best. Just make sure you do your analysis right.

Vote of thanks

In order of people whom I have chronologically bugged for discussions and answers — Abhinandan Bansal, Sowmyanarayan R, Manju Madabushi, Ashish Waghmare, Rakesh Pathak, Sanjeevan Biswas, Chetan Verma and Gaurav Shankar. (Sorry if I forgot any other names.)

Reference articles

Following are some other references to articles and documents that helped me during my analyses. Happy to pass them along.

1. JavaScript Design Patterns
2. Best practices for speeding up your website
3. No more frameworks
4. Building a JavaScript framework
5. Development Guidelines — Best Practices
6. QA metrics explained

Appendix I

Few articles on comparison between currently available front-end frameworks.

1. Opinionated rundown of JS frameworks
2. Angular 2 vs React – there will be blood
3. https://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks
4. http://www.slideshare.net/mraible/comparing-hot-javascript-frameworks-angularjs-emberjs-and-reactjs-springone-2gx-2015
5. https://www.lullabot.com/articles/choosing-the-right-javascript-framework-for-the-job
6. https://www.airpair.com/js/javascript-framework-comparison

Apendix II

Angular 2 community contributions.

1. Angular 2 Bootstrap 4
2. Kendo UI for Angular 2
3. CKEditor
4. Built with Angular 2 – Showcases
5. Twitter trends on #angular2
6. A ton of tutorials — it’s frankly overwhelming at times