2019-12 Frontend frameworks research
this was writtend in 2019. the technology landscape was different, and it was written for a specific dev team and location in mind. the conclusion of this research probably does not apply anymore. i hope you pay attention to the process rather than the conclusion.
It was decided to use web technologies to build [the new] series of products in big part to have only 1 codebase (easier integration and code sharing between products) and partly to support many different devices (computer on board ships, computer on shore offices, etc). Since the codebase for [the new] series of products will likely not be a small codebase (probably in the order of 100K’s LOCs: [product-1] has ~50k LOCs and [product-2] has ~130k LOCs), we will most likely need a front-end framework to reduce boilerplate code for common web front-end development technical use cases.
Use cases
- Easy to hire developers, including some with a lot of experience developing with the chosen framework. Has to be valid now and in the future (next 5-10 years?)
- Documentation/tutorials: easy to find good documentation and tutorials to learn about the front-end framework
- Ecosystem: lots of good libraries and tools that have good integration, documentation and support
- Support/maintenance of the framework: the framework needs to be actively supported and maintained so that it is compatible with future technologies, does not have a lot of bugs and has a way to submit bug reports/issues so that they can be fixed
- Must support many different kind of devices. And therefore support mobile first/responsive design and PWA (offline support, user experience, etc)
- Performance: the application will need a fast enough first load while supporting a lot of business features offline (big codebase and a lot of code to download/execute) and also have good performance when interacting with different features and part of the application.
- Easy development / architecture that scales: It should be easy/quick to develop new features and perform maintenance (refactoring, bug fixes) even as the codebase grows fairly large (in the order of 100K’s LOC).
- Web components: we should be able to write web components to be able to reuse a lot of code (DRY) and encapsulate code in units that have clear/strong contracts (so that we can easily do impact analysis and easily know if/which code/component to re-use).
- Interoperability: easy to communicate/work with other technologies/applications. This allows us to choose the right technologies for the work to be done, even if those technologies are not the same as those initially chosen for the front-end application, because we can create a new application with different technologies and still communicate with the original front-end application. In the same vein of thoughts it allows front-end and back-end to communicate.
- Quality: it should be easy to test an application made with the chosen framework to ensure good software quality (no important bugs, all important features work as expected, etc).
- Usability: should support building interfaces that are easy for humans to use. For instance it should support internalization so that if we want to translate text (or other info) in the future, we can easily do it.
Popularity
There are many front-end frameworks. Since most of our use cases are common in web development, a quick way to filter most of the frameworks and find the few candidates that are most likely the best fit for our needs, is to look at frameworks that are used by big organization that do a lot of development using that framework and also look at frameworks that are used a lot by developers. Big organizations are more likely to take more time analyzing which framework to choose since choosing a framework versus another could have a bigger impact for them. Also, once they have chosen a framework and invested a lot of development into applications using that framework, they are likely to contribute to the framework by adding support for new use cases in the framework (and fix bugs). Also, they usually have more use cases than smaller organizations and potentially need to support new use cases before other organizations. When that is the case, they are likely to add support for those use cases to the framework they most invested in. Developers have an incentive to use frameworks that are easy to develop with and that supports their use cases. For that reason, frameworks that are used by many developers tend to also be interesting frameroks to choose. Additionally, the plan for the [new series of] products is to add many features and support them for the long term (5-10+ years). On that timeframe developers are very likely to change or quit working for an organization; and an organization developing software is likely to want to vary its expenses and development speed by hiring more developers (or hiring someone with expertise on a new use case). For those reasons, choosing a framework that a lot of developers knows is useful for hiring purposes.
List of front-end frameworks worth minimal comparison
Googling for list of “list of front-end frameworks“, “best front-end frameworks“ and the likes, I assembled a list of front-end framework that are listed in more than one text in the first 2 pages of google search results. Then I input that list to Stackoverflow tag trends to have an idea of how much they are used.
- Stackoverflow tag trends: https://insights.stackoverflow.com/trends?tags=reactjs%2Cangularjs%2Cangular%2Cangular-cli%2Cvue.js%2Cvuejs2%2Cember.js%2Cjquery%2Cbackbone.js%2Cmeteor%2Cknockout.js
Ignoring jQuery, which was used a lot historically since it was the first widely adopted front-end library and also since it does not support many of the use cases we have now (for instance web components), we are left with 2 front-end framework that are much more used than all the others: React and Angular.
Validating organization and developer popularity
- Big organizations/project using either Angular or React
- Angular: Google cloud, Microsoft Office, Delta airline, VMware Clarity Design System, Forbes, Australian Department of Home Affairs, Blender video
- React: Facebook, Netflix, Twitter, Reddit, Dropbox, Airbnb, Uber
Looks like there are many big organizations for both framework. There are more “tech“/software development companies working with React.
- What are the new devs learning right now: looking at https://www.codecademy.com/catalog/subject/all and https://www.udemy.com/featured-topics/ it looks like react is much more popular in terms of courses that people follow online
- Stackoverflow 2019 survey: https://insights.stackoverflow.com/survey/2019#technology
- Google trends in [org-city]
Overall it looks like react is a bit more used and is still growing, where angular is staying at about the same popularity. But both framework seems to be used a lot worldwide and in [org-city]. Both framework also seem to be backed by big organizations. For those reason, I only compared those 2 frameworks, React and Angular, in more details.
Detailed use case and feature analysis
Note that since the person doing the bulk of the research and the other front-end devs in [organization] that would be working on [the new series of products] ([name-1], [name-2]) already knew a lot about angular and not much about react, there was more research done on react to be able to compare it to angular. For that reason, there will be a bit less documentation on angular in this research documentation.
- Easy to hire developers
- See the Popularity section: both seems about equal in terms of how many developers work with them, react might be growing more than angular though.
- React applications have more tech choices (since react is only a UI library and the devs have to choose many other libraries to have a complete boilerplate app) so even if more devs know react, maybe less devs know react and the libraries that we will be using with react.
- Maybe senior react developers are paid more than senior angular developers? I could not find a good source of salary for [org-city] on that subject though.
- All of the current [organization] developers that will work on the [new series of] products know angular since that was what was used for the [product-1]. And none of them worked a lot with React. That makes it easier for those developers to teach new developers angular than react.
- Documentation/tutorials
- React application architecture and core concepts
- The basics of building a feature in a react app: https://reactjs.org/docs/thinking-in-react.html
- React hooks: https://reactjs.org/docs/hooks-intro.html
- React context: https://reactjs.org/docs/context.html
- Programming patterns of flux/redux: https://medium.com/javascript-scene/10-tips-for-better-redux-architecture-69250425af44
- When to use react hooks vs redux: https://medium.com/javascript-scene/do-react-hooks-replace-redux-210bab340672
- Anti-patterns for react (that sometimes might be unavoidable): render props (https://reactjs.org/docs/render-props.html) and higher-order component (HOC: https://reactjs.org/docs/higher-order-components.html)
- Pattern used in react instead of angular dependency injection. The question and first answer on stackoverflow: https://stackoverflow.com/questions/30311081/react-dependency-injection-or-similar
- Angular: https://angular.io/docs
- React application architecture and core concepts
- Ecosystem
- compatible with tech for map rendering (openlayers, mapbox, etc) for rendering maps like [product-1], [product-3], [vector-map-tech-1]. : looks openlayers and mapbox do not need special integration in angular or react
- Example of react applications
- Big open-source project that uses react: https://github.com/mattermost/mattermost-webapp/blob/master/package.json
- React boilerplate example app: https://github.com/react-boilerplate/react-boilerplate/blob/master/package.json
- Support/maintenance of the framework
- Support for many different kind of devices.
- Must support mobile first/responsive design
- Looks like both angular and react allow custom HTML+CSS+JS and service workers and therefore supports PWA development and mobile first/responsive design.
- Must support mobile first/responsive design
- Performance
- Both react and angular supports code splitting, preloading and lazy loading of app code
- server-side rendering
- Easy development / architecture that scales
- Web components
- templating
- react: JSX/TSX: https://reactjs.org/docs/introducing-jsx.html
- angular: https://angular.io/guide/template-syntax
- CSS/SASS encapsulation
- react
- looks like its either SCSS with class/tag name scope (and scss component file) or CSS-in-JS. I tend to prefer SCSS since it’s easier to migrate/write/copy paste and it looks like it better supports hot reload
- CSS-in-JS: https://github.com/styled-components/styled-components
- CSS-in-JS: https://github.com/Khan/aphrodite
- CSS-in-JS: https://github.com/FormidableLabs/radium
- SCSS with class/tag name scope: https://hugogiraudel.com/2015/06/18/styling-react-components-in-sass/
- angular: https://angular.io/guide/component-styles
- react
- templating
- State management/data flow
- react: one way data binding with flux/event/MVC architecture
- react hooks: https://reactjs.org/docs/hooks-intro.html
- React context: https://reactjs.org/docs/context.html
- Programming patterns of flux/redux: https://medium.com/javascript-scene/10-tips-for-better-redux-architecture-69250425af44
- When to use react hooks vs redux: https://medium.com/javascript-scene/do-react-hooks-replace-redux-210bab340672
- Other library used with react apps: redux-saga
- angular: two way data binding in template with the addition of services
- Template data binding: https://angular.io/guide/template-syntax#binding-syntax-an-overview
- react: one way data binding with flux/event/MVC architecture
- Dependency injection
- react
- use props or react context: https://stackoverflow.com/questions/30311081/react-dependency-injection-or-similar
- React context: https://reactjs.org/docs/context.html
- angular: https://angular.io/guide/dependency-injection
- react
- Observables (RxJS)
- You can wrap pretty much any JS/TS in observable, at least for react+angular.
- Deployment and packaging (webpack, etc)
- react
- create-react-app: https://github.com/facebook/create-react-app
- “A build script to bundle JS, CSS, and images for production, with hashes and sourcemaps.”
- “An offline-first service worker and a web app manifest, meeting all the Progressive Web App criteria. (Note: Using the service worker is opt-in as of react-scripts@2.0.0 and higher)”
- looks like it does not support server side rendering
- looks like it supports code splitting: https://create-react-app.dev/docs/code-splitting/
- next.js: supports server side rendering?: https://github.com/zeit/next.js
- create-react-app: https://github.com/facebook/create-react-app
- angular: angular-cli: https://angular.io/cli
- react
- Hotswap/reload for local development environment
- react
- https://github.com/gaearon/react-hot-loader (some limitations with react hooks and will be deprecated in favor of react fast refresh when webpack/react-dom supports it)
- https://github.com/pmmmwh/react-refresh-webpack-plugin (experimental)
- angular: supports reload through angular-cli: https://angular.io/cli
- react
- Web components
- Interoperability
- HTTP communication
- react
- react-resolver: https://github.com/ericclemmons/react-resolver
- axios: https://github.com/axios/axios
- angular: https://angular.io/guide/http
- react
- HTTP communication
- Quality
- automated testing (unit, integration and e2e tests; code coverage)
- react
- e2e: should work with selenium since it outputs dev chosen HTML/CSS
- create-react-app supports unit tests with code coverage: https://create-react-app.dev/docs/running-tests/
- angular
- angular-cli e2e: https://angular.io/cli/e2e
- unit testing and coverage: https://angular.io/guide/testing
- react
- automated testing (unit, integration and e2e tests; code coverage)
- Usability
- Routing
- react: react-router: https://github.com/ReactTraining/react-router/blob/v3/docs/Introduction.md
- angular: https://angular.io/guide/router
- Internationalization (i18n)
- react
- angular
- i18n: https://angular.io/guide/i18n
- ngx-translate: https://github.com/ngx-translate/core
- Form validation
- react: https://react-hook-form.com/ (compares formik, react hook form and redux form), supports custom validation
- angular: https://angular.io/guide/form-validation#form-validation
- Routing
Analysis from different roles/perspectives
While researching which front-end framework would be the best to choose for the development of [the new series of] products, at least one person from each role was consulted to validate that the final choice of front-end framework would support the use cases needed according to the perspective of that role. Also, a meeting was held on 2019-12-18 where any person from the P&T department that was interested to attend could attend. The goal of that meeting was that everyone had a chance to name any important consideration when researching which front-end framework to choose.
- DevOps: react and angular supports docker, static site serving and webpack/ng-cli/create-react-app
- QA: Nikita told me that they are probably going to keep selenium and CSS selectors.
- Graphic design: react and angular supports building UI with components
- Data: from my understanding both angular and react allows to load data from HTTP and local storage/local files, which should support data use cases like: having an app to modify the data or server app to read data from SQL DB or geo DB (geoserver).
- Dev: see “Use cases” and “Detailed use case and feature analysis“ sections
Conclusion
On 2019-12-23, the 3 persons that had the most knowledge about front-end frameworks had a meeting with the goal of taking a decision on which front-end framework to choose. The person doing the research had previously presented the result of the research. During the meeting, each person took the time to list the differentiating points between Angular and React; and then argued what they thought were the most important points and which framework should be chosen based on those points. At the end everyone wrote what they thought was the best framework on a piece of paper and everyone revealed their vote at the same time. The vote was unanimous in favor of Angular for [the new series of products] front-end development.
Key distinction between Angular and React for [the new series of] product development
Angular | React |
---|---|
Application architecture and tech choices are already known by [organization] devs | Easier to hire new devs if react is more popular in the future. Although: There is many different technologies in react and even if there is more devs for react there might be less devs that know the exact technologies we use with react. Also, cost of hiring a react expert might be higher than hiring an angular expert |
Already have a lot of knowledge from [organization] devs | More tech/software development companies seems to use react |
We could potentially re-use some code from [product-1] which was built with angular | More freedom when choosing technologies for the boilerplate code |
We could start more quickly adding features for [the new series of] products since we would not have to take time learning react. | Would be good for the career of current front-end devs since they would know both angular and react (after learning react) |
We could teach new developers more easily since we already know angular |