Optionality — The Front End Edition
8 MIN READ
Choosing the right technology stack for a product is an important step in controlling outcomes in product reliability and development agility. In 2017 we are spoilt (and overwhelmed) for web development technology choices. Sifting through the options can be challenging but well worth it for a start-up’s requirements for rapid innovation.
For product reliability performance and potential defects, surface areas are key factors to consider when exploring technology options.
Having non-responsive webpages as well as long page loading and render times will degrade the user experience and satisfaction; this must be avoided as much as possible. No software is perfect and bugs will inevitably creep up. What is in our control is minimising the surface area from which bugs can creep into our system. We can minimise the surface area of bugs by improving code reuse, applying suitable patterns, ensuring consistency across the codebase, and having appropriate test coverage at the unit, integration, and end to end levels.
Development flexibility is a key enabler of development agility, that is how ‘easy’ it is to build something on top of an existing codebase.
If you take the case of making use of a existing fully fledged framework for your requirements, you’ve saved yourself a lot of decision and development pain compared to building full infrastructure or integrating systems yourself. This enables high flexibility for extending your application. However, due to the size of the framework, you may be locked in. It may therefore be very inflexible to get out if something down the line comes along that offers significant benefits for your product. This is particularly true if support is dropped for the framework you’re relying on.
On the other hand, if you make use of a selection of libraries and lightweight frameworks, you’re not heavily invested into one particular system and can more easily pick and choose appropriate technologies as they come. Sadly, this may present a decent amount of decision fatigue and integration pain to get through.
For our Cradle web application, which at this stage is an administration portal for managing users and call configurations, we considered the following technologies: AngularJS, Angular, React, and Polymer . While there are other good options such as Vue, Riot, and Ember we narrowed down our options to technologies that are well backed by large companies, with a sizeable population of developers and web applications in production.
AngularJS is a widely popular Model-View-Controller (MVC) framework that reduced the pains in building Single Page Applications (SPAs) after emerging from Google in 2012. Angular aka Angular2 and now Angular4 is the non-backwards compatible successor to AngularJS. Angular2 just went final in September 2016 and Angular4 has a final target for March 2017. From that you can actually see the current state of Angular is not great as it’s in high flux, and does not appear to sufficiently stable for our web application’s requirements. This is a shame, but regardless there’re still some great points to talk about.
AngularJS is the oldest and most mature of the technologies considered, which gives us a positive stamp of stability for our development. Unfortunately for AngularJS, Angular offers significant performance and design benefits over AngularJS and offer a much brighter future as Google tries to push AngularJS users over to Angular and remove its support.
Polymer is a library for building web components based off of the W3C spec, built by Google with 1.0 released in 2015. The component based approach is pleasant to develop with, along with the use of shadow DOM, which basically enables ease of isolated DOM manipulation via local component scoping. Polymer also has the potential to easily integrate with Angular should you want more out of the box.
The downside is that the full feature-set of Polymer web components are not yet natively supported by all browsers, and while polyfills are used to work around this lack of support, it comes at a cost of degraded performance. Another important downside is that the Polymer community is small in comparison to the other technologies considered and there’s not a large number of production sites out in the wild to validate its effectiveness. Google for example only has 4 of its comparatively minor sites using Polymer, which includes YouTube Gaming.
React is an awesome and wildly popular view library built by Facebook and released back in 2013. React features one way flow. While this can be a pain when coming from the two way binding land of AngularJS for development, it helps isolate the control and manipulation of state, ultimately helping us reduce bugs, headaches and localising data flow control. Another feature is the use of the virtual DOM which basically allows React to only rerender the subcomponents which correspond to state changes.
React also offers React Native from which you can build cross-platform native mobile applications, so joining the React ecosystems opens possibilities to maximising code sharing across both mobile and web platforms. This offers not only development efficiency, but also localisation of bugs should they occur. Aside from Facebook, other notable users of ReactJS include Airbnb, Netflix, and Imgur.
It’s important to look at the communities and production applications that are making use of the technologies that you consider applying. Google Trends, StackOverflow activity, Github activity, job boards, and Wappalyzer are all good sources for measuring a technologies’ use in the wild. In this entry we’ll gloss over all but Github and Wappalyzer, but from those other sources the trend is similar across the board in that React and AngularJS are significantly more popular in terms of community size and use in production compared to Angular and Polymer.
In terms of GitHub stars and production applications sampled by Wappalyzer, React comes out as the clear winner. While we’re not basing our decision on the above metrics they’re worth discussing. Google trends and Stack Overflow activity may reveal a different picture, but let’s not go too deep when based on the previous yarns we appear to have a winner.
The comparatively large detection count of React from Wappalyzer is likely attributed to React’s high flexibility. Being a lightweight library, one can easily incorporate it into small scale applications as well as on top of large scale legacy systems. This could explain its high adoption rate in contrast to AngularJS, which is more suited to new projects of medium size, as incorporating existing systems into the AngularJS framework would involve significant rework.
The significantly large detection count for React is attributed to its flexibility for being lightly and highly pluggable into legacy systems as well as for building new applications. Meanwhile AngularJS detection count is attributed to being more a result of being applied for the development of new applications, as the migration path from a legacy systems to AngularJS would involve significant rewrites. With React you can just build new views and components on top of existing infrastructure and continuously convert chunks of legacy code to React, making full use of the testability and reusability of the resultant components.
We’ve decided to go with React for our web application. Its lightweight implementation and modular approach works well with our product and will enable high optionality, stability, and agility for present and future development. It was unfortunately an unfair fight in React’s favour, due to the transition phase of Angular and lack of Polymer user and browser adoption. It will however be exciting to see how Angular and Polymer turn out in the near future!