In Part I, we described the massive expansion of web framework options and acceleration of their lifecycles through the past decade. The technology industry–already caffeine-addled and browbeaten–now has yet another object of obsession and destabilization. Times are exciting!
In this installment we will compare some of the better known options and provide you with links to educate yourself. It’s easy to get lost in the wilderness, so we will try to keep it succinct and relevant. As you begin this journey, start with the “why?” question and return to it often. It will be your compass.
Why do I need to do this?
Before researching any technology or starting any decision-making process, leaders should channel their inner five-year-old self, asking “why?” naively and incessantly. If you’re a brainstorming type of person, make it an exercise for yourself or with your team, writing down everyone’s ideas and later putting them into categories. If you’re more of a top-down thinker, start with the holy trinity of cost, quality, and time. Since we’re talking about web frameworks, allow yourself a fourth category for user experience. You can derive the questions as follows:
- How will adoption lower my costs? (think total cost of ownership)
- How will adoption improve my software quality? (don’t fall into the trap of believing that the technology itself has built-in defect prevention)
- How will it increase my speed to market? (be sure to factor in time for refactoring/rewriting, learning curve, and potentially hiring new talent)
- How will it impact my customers?
Be careful with these “how?” questions because you’re not yet trying to write detailed plans. Instead, use your answers to substantiate the larger “why?” question. Coming out of this exercise, you should have a set of categories and underlying details for what you need out of a new web framework. Keep it at tree-top level but make it relevant and specific to your organization, legacy product, customers, etc.
Those of us who are not developers can take comfort knowing that there is a consensus in the community that React, Angular, and Vue will not fizzle out anytime soon. However, staying power is not the only important criterion. Below is a comparison table that aims to draw contrast among these three frameworks without getting too far in the weeds.
|Who develops and supports?||Founded by former Google employee and supported by the Vue community|
|Market adoption||Second strongest||Strongest||Third strongest|
|Developer popularity||Surpassed Angular||Popular but declining, with negative views becoming stronger||Fastest up and coming|
|Model||Virtual DOM||Full-fledged MVC; two-way data binding||Virtual DOM|
|Native mobile support||Through React Native||Through NativeScript||Currently under development (through Weex)|
|Ideal for||Modern web development and native-rendered mobile||Large and full featured web apps||Web development and small to medium sized apps/teams|
|Drawbacks||Only provides the “V” of MVC; needs Redux or other libraries to manage state||Angular is very opinionated; not everyone wants to use/learn TypeScript||Lack of imposed structure requires teams to define their own and stick to it|
|Ease of hiring experienced developers||Very hard||Very hard||Very hard|
For Further Reading
Having the right rationale, success criteria, and well researched options, you’re off to a good start but are barely past square one. In the final installment in our series, we will discuss:
- How to discover and defuse implementation landmines before stepping on them
- Selecting a candidate framework, followed by proof of concept
- Planning and executing a pilot project, and using lessons learned to scale the technology and sustain its support
If you’ve taken the time to compare all the framework options, but are still struggling with channeling your inner five-year-old, let Rivers Agile help you make an educated decision while respecting the holy trinity of cost, quality, and time. Contact us!