Real life project experience of selecting UI tech stack
Lately, I started working on a Frontend Migration project where different multiple applications were running on Durandal and Knockout.
This interesting and lovely story started when one of our product architects installed me to understand the product line from a UI perspective. The client requirement was they wanted harmonization across all the different assets, as well as a Single Sign-On (SSO) platform to bring the better user experience.
I found their multiple products running on the outdated technology stack. There is no harmonization across these products. And they also need a single unified platform (SSO) for all the assets. These looks to be a simple requirement but if you break down these, you will get a feeling of complexity
- Technology transformation, new technology should support for the next 5 years, it should scale so that new assets can be added/removed with minimal configurations
- All assets should look alike still they present a unique personality, consider it like a bouquet of flowers, where each flower has its own shine, and fragrance
- SSO, I think this doesn't require any explanation
well, in this post, I am not going to write about the last to requirements as this is not the topic of discussion. will write a different post to nail down those as well.
coming back to our the most requirement, selecting a technology stack which can support for next 5 year is a very complex work, this requires understanding current and future requirements, trade-offs, learning curve workforce availability, expiry date, etc.
Yes, Expiry date is one of the key factors one should define at the start of the development. Nothing is immortal in this world so does software, technologies, and architecture. If you look at Angular, they also mention the version expiry date, “All of our major releases are supported for 18 months”. which mean there is no guarantee of your application if it's built using Angular and running on a version which is 18 months old. Having said that selecting the right choice would not only increase productivity but it also impacts the longevity.
So, I did a comparative analysis between some of the frontline frameworks available in the market like React, Angular, Polymer.
Couple of you may think that why I have chosen only these three items in the analysis:
Well, there are a good number of UI frameworks available in the market which are serving the same purpose with few differences, yet some of these are reliable and popular enough to include in the candidate list of our analysis. I selected to go with Angular & React because both are the reliable framework for building complex UI functionalities, have good community support, the frequency of rolling out new versions is fast, enriched with developer accelerators like CLI, etc. so these were the obvious choice.
On the Polymer front, I see it has a huge potential of building reusable, framework agnostic components, ie. you can build components in Polymer and can be deployed in any of other UI frameworks like Angular, React, Backbone, Vue, etc. Its inbuilt support for building web component stands him out of the line.
Now I had the requirements and technology candidates as well, the next item was to draw the criteria based on which I need to identify the good fit.
This section presents some criteria and drivers which I used in the evaluation. These are mainly driven from the requirement perspective, for ex. how these choices (React, Angular, Polymer)are providing reusability. Do we have some productivity tools/process available built-in? or how these choices perform when we have a complex UI (dirty updates, deeply nested hierarchy) to render?
Let me start this section with a universal truth, there is no silver bullet for solving all the problems. having said that I have chosen Angular for this implementation, why? look below
· Modularity & Manageability comes from Typescript — writing enterprise application/product which has a greater shelf life requires high manageability. With Angular default inclination towards typescript, it becomes easier to write code in Angular using typescript
· Single platform for all needs, fewer integration issues — Don't worry about third-party integrations, Angular team manages version compatibility during the upgrade. you just focus on writing scalable code.
· Driven by industry leaders — Of course, no one has doubt on Google Angular team, they are delivering the best technology sets, toolchain, documentation. Its always better to choose “products with a reputation and reliability”
Some other items which I observed during my evaluation and are worth mentioning under here:
. Brings reusability with support to component-oriented architecture
· Skill standardization & retention: In my team, I was having more of OOP guys who in their past did the heavy lifting in Java or similar OOP platform. With Angular supporting TS as its natural language for development, OOP guys feel like home. On the contrary, I found React closer to a functional paradigm where you majorly write pure functions to create applications.
· Development efficiencies
Every framework/libraries have a profit/loss balance sheet. It's more of a technical/business requirement which guides the decision. In my case, the client need is to support the product for the next 5 year. This needs a reputated product line, so don't go by the industry wave, it may impact your project big time. It's always good to lay down the Functional and Non-functional requirements and then try to figure out the best possible option.