How to choose a Framework — For your Browser based projects
It’s a burning question in any technology, however, for frontend in particular, JavaScript world it is huge due to the availability of thousands of JavaScript Libraries, Frameworks and Platforms. Also, new libraries coming in a regular basis and existing technologies re-defining the standards. For e.g. MVC was very popular pattern but many of the latest libraries and frameworks doesn’t adopt MVC anymore.
Angular is often treated as ‘Platform’ due to it’s rich feature set and out of the box capabilities like Typescript support by default comes with AOT compiler, Reactive Programming using RxJs, Web components with Angular Elements, Server Side Rendering with Angular Universal, Angular CLI, Router, Angular Material, Reactive Forms, Webpack integration(along with features like Differential serving) by default and many more.
The motive behind, shedding some light and sharing my learnings in this post is majorly due to the fact that I have been asked this question repeatedly in many forums by many folks during my interactions. New joiners at the induction, techies met during the conferences, and campus visits, and other platforms I have visited have been posed this question by many! Usually the query is, why React? in my current organisation whereas in my previous organisation it was, why Angular? 🙂
For an organisation with a decent share of revenue coming from the web has all the reasons to invest in building the libraries, frameworks and make it open source to build the strong community. For e.g. Google, Facebook, Airbnb, Netflix and Walmart to name a few follow this approach.
However, I would like to approach this in two-parts. Due to the reason, the majority of the folks who posed me this question are Developers with experiences ranging from Sophomore to 7 years of experience(around 70% of the lot). After a little conversation with them actually turned out to be, their interest is more towards how to master a new technology as there is a change in the technology every now and then! At times, there are changes within the same framework, in terms of Philosophy, Design Patterns. For e.g. Angular.js to Angular(2+) is a paradigm shift, similarly with React, from Class-based components to Hooks(React 16.8)
Part — 1
How to master new technologies as a new developer in the team
I would recommend, 3 Golden rules one need to follow, in order to master the new technologies in one’s new project/organisation
Identify the unknowns from the tech stack
It is very important to list out the tech stack and identify the libraries/tools/frameworks in the new project that one needed to learn or brush up.
A Problem defined well is half solved
Often the tooling done from one project to the other (or an organisation) varies like, for e.g. React versions till 16.3 strongly recommended on Class-based components, later the functional components and Hooks have been introduced(16.8).
Read the documentation(x2) of identified unknowns from their original sources
There are couple of reasons for going through the original documentation,
- Always up-to-date, can be treated as single source of truth.
- Not limited by the understanding of author (tend to happen in other popular forums like blog posts, video tutorials etc.)
- Lesser learning curve by quickly glancing over all the features list and one can go over only the basics given by the scope of project and experience of the developer.
- Going through the documentation for the second time, will help in understanding the philosophy behind the technology or framework as well as Design principles.
Subscribe to mailing lists, particularly “Known Issues”
Now a days, most of the libraries, frameworks are open-source and community driven with the intention of wider acceptance and faster growth.
In order to one evolve along with the community, need to be up-to-date. To achieve the same, be active with the community by subscribing to the mailing lists, slack channels, and most importantly subscribing to the “Issues” section or becoming the part of ‘watchers’ list in the github.
With this, one will be thinking in the same way as language/technology is structured. For e.g. my learning with JavaScript, and it’s best practices, design patterns came from subscribing to jQuery codebase.
Upon subscribing, one’s mail box would look like below screenshot and catching up these discussions daily-basis makes one’s thinking in line with the community and helps in debugging the issues faster in the production.
Part — 2
How to Choose a Framework/Tech Stack/Library
Now coming to the interesting part of the post on selecting a Tech stack. This would be usually done by an Architect or an Engineering head. Given the current market situation with startup eco-system going strong in India, let’s assume a developer with 7+ years experience in industry or in a given technology would be an eligible candidate to take a call on choosing the framework or tech stack.
However it’s very common to see the developers failing to have the relevant experience and tend to commit mistakes in making the decision wisely, often end up in a situation where it impacts the productivity of team, soon hitting the rock bottom where it stops scaling and starts breaking in the production.
The decision making is very crucial for front-end tech stack for the reason, say for e.g., React is library and with the help of third-party libraries like Redux for Store management, React Router for routing capabilities and RxJs for Reactive Programming completes the tech stack. There are many alternatives in the market for the same as well. In these cases, one needs to thoroughly investigate and may have to follow the same steps mentioned below in order to make a selection.
Here, let’s focus on 4-rule approach for choosing tech stack:
List out all the features one’s product needed to develop now and in the future releases
Listing out all the features for current version of release as well as for the future would give one the fair understanding of choosing a single framework, a Platform like Angular with all the features out of the box (otherwise known as “batteries included”) or if the interest is more towards adopting React ecosystem due to it’s popularity and flexibility of choosing different options. In the case of an approach like React ecosystem with variety of options for each and individual tech stack, a recursive approach of following the proposed 4-steps approach on how to choose a framework might help!
Understanding the Design Philosophy, helps in knowing the strengths as well as limitations
Frameworks have to make trade-offs on multiple dimensions
For help, one can look into the main documentation for design principles, here are few popular frameworks/libraries to look out for,
- React Design Principles
- Introduction to Angular Concepts
- Design Principles of Vue 3.0 by Evan You
- Ember — Core concepts
- Svelte — Cybernetically enhanced web apps
One might be wondering, is it necessary to go through all these documentation and understanding of in-depth Design principles for all the options, the answer is YES and NO — depends on one’s use case, project and team.
How active is the community?
An important decision making factor by Architects comes from the size and activeness of the community. Sometimes who is backing this community also plays a key factor, For e.g.,
- React by Facebook
- Angular by Google
- Typescript by Microsoft
- Vue doesnt’ have any big company backed but have a strong community
- Svelte currently maintained by it’s creator, a graphic editor from NYtimes, Rich Harris, contributing during his free time along with a small and active community
A plenty of sources would give a stats around stars🌟, number of issues⚠️, last updated 🛠, size 🏋️♀️ and more details which helps in narrowing down further one’s selection.
For e.g. npmtrends, a popular source for evaluating the different popular options in terms of wider acceptance by developers, number of downloads and other stats.
The more the user base the mature the tech stack would be!
What is the current market in terms of building team within the budget
Finally comes to the money!
Time is money
One has to take a call based on organisation’s current team, learning curve amidst tight schedule of releases in pipeline. For e.g. if I have to build team of 20 developers for my latest requirement, would I able to get them in the market within my budget, with experiences ranging from Jr Developer → Sr Developer → Architect. We are still not talking about code migrations, developer tools and more which goes into decision making.
Conclusion
Overall, these approaches would certainly help in building fault-proof systems for a scale in production from small teams to big organisations. With proper research, one would be able to build projects for longer run without worrying about the changes in the existing tech stack, for e.g. libraries coming to end of life will be nightmare to the developers.
