Angular and Tensorflow Rewrites Retrospective
When AngularJS framework was released, it sky rocketed to being the most popular front-end development framework. But after a few years, React, a competing front-end framework open sourced by Facebook, quickly gained traction and is now the most popular one.
A big difference between the 2 is that React took a more loosely coupled approach to front-end development and provided sets of components you could use with more freedom, to sum it up React was less opinionated. It also made different design choices (JSX and static code analysis etc). AngularJS team changed course and released Angular, which was a complete rewrite of AngularJS, basically opting for roughly the same abstraction strategy than React. Angular was not backward compatible with AngularJS, and I myself was quite bothered by it and ended up learning React instead of Angular, even though I knew AngularJS.
A few years later, I began working on deep learning projects and began using the most popular framework at the time, Tensorflow 1.0, open sourced by Google. Google announced early 2019 the release of Tensorflow 2.0, which is a major, non-backward compatible rewrite of TF1.0. One of the most important changes is that TF2.0 default mode is now “ eager execution “, which basically means you write your neural networks as functions and not as graphs. This pattern (procedural rather than declarative) is widely considered to be more intuitive (at least for python people who are numerous in deep learning community) and closely follows PyTorch, a competing deep learning framework open sourced by Facebook, that is progressively overtaking Tensorflow as the most popular framework.
Once again, the rewrite is not backward compatible, once again it aligns on the usage pattern of a competing framework, and once again this competing framework comes from Facebook. Since I’m a 2nd time victim of a google framework rewrite (angularjs and now tensorflow), I thought it would be interesting to dig into the matter a bit.
Let me get this straight first: I’m not implying that Google software engineering is less good than Facebook’s. There are so many factors influencing product roadmaps (software engineers, product owners, top management etc) that the reasons that led to those rewrites are probably more organizational than craftmanship-related.
AngularJS was a spin-off of a side project from a Google software engineer. When it was released, it had never been used in production by Google, but the Google hype was so powerful than most people overlooked this fact. On the contrary, Facebook’s React framework had been widely used in production before being released, which may explain why they made the right abstraction choices before everybody.
On the contrary, Tensorflow was born out of a refactoring of a deep learning library used in production by several different departments at Google. Pytorch was created by Facebook AI research group, and didn’t have a vast production history. But since Pytorch is more pythonic (python being the language of choice in the deep learning community), and simpler to operate, it is now quickly gaining traction.
What’s interesting is that in AngularJS case, the project probably suffered from a lack of production experience, which means wrong design choices could not be uncovered soon enough. In Tensorflow case, I’d say it’s the contrary: the fact that it was used in production at Google meant that many things necessary for Google (large-scale computation distribution etc) made the framework unnecessarily complex for a majority of potential users.
In the long run, the popularity of a given framework heavily depends on the ease of its learning curve, and the size of the community using it in production. Tech giants release open source projects to gain influence in tech ecosystems, and set future standards. Sometimes it takes massive commitment to stay relevant (popular and used in production), and from the look of it, Google is not backing down anytime soon. I just hope the next Google framework I learn does not end up rewritten again!
Originally published at http://fruty.io on October 21, 2019.
