2016 had so many new ideas!
In 2016 I worked only using AngularJS and I was proud of the fact that projects using it were very successful and got results very fast.
At the same time, JS frameworks were competing to replace it. There were concerns about the scalability of AngularJS: it was hard to grow an AngularJS app to enterprise level for large teams also AngularJS was not designed with high performance in mind, which limited its usage on mobiles.
React, Vue and Angular 2 were battling for the minds of developers as well as many other accompanying tools, to build their apps. In 2016, this “Cambrian explosion” of JS libraries and tools made many of the tools I used for less than 2 years, outdated.
Particularly React and Angular 2, had very different ecosystem models. React, counted on a rich ecosystem of plugins was a big pool of ideas and approaches, while Angular, with a “batteries included“ approach drew a less diverse community of users that simply wanted to be productive. React became the Bazaar and Angular, the Cathedral.
Projects based on either ecosystem had to be architected very differently, because the philosophies of development were very different. Certainly, React still has a more vocal and active community, but it seemed to reinvent its own wheels, while Angular failed to excite its users to innovate.
However, keeping up represented a considerable amount of energy. As I moved to another project and team, I realized how “obsolete” my tools had become. If faced with a choice, I had to move to another framework, and there was no clear winner.
I love development, but a feeling of dread took me. I was not able to articulate why, until a came across this article by Jose Aguinaga:
Remaking a similar framework or state management library that proposes little new things or often, making a “lightweight” version of something else is not very useful innovation. But in 2017 some things did change.
React with a new standard open source license, MIT, has won confidence of corporate users. Both NPM and Webpack are very conscious of making any breaking changes; they stay current and useful by providing long terms solutions to specific problems. State management, on the other hand, might get disrupted by GraphQL, but this change will need to onboard back-end developers in many languages as well.
I also see more important innovation where it matters (GraphQL APIs) so we can actually be more productive in our work. I predict happier users (and happier bosses) in this environment of stability.