Cover image for The Journey That Finally Led Me To React

The Journey That Finally Led Me To React

steveblue profile image Steve Belovarich Updated on ・7 min read

I didn’t learn React because it is popular. No, I didn't just take a deep dive into Context, React.memo, and Hooks because companies are only hiring engineers with React experience. Angular engineers are in high demand. The Angular community is very strong. I found out in 2020 it is possible to tweet you are available for an Angular gig and someone may tweet back. The next day I found myself being onboarded 100% remote on an Angular project. I didn't just learn about React because I think it's fast or even sustainable front end solution. To the contrary, I've heard plenty of my engineer friends grumble over the performance of their poorly architected React applications.

Nope, I didn’t learn React to watch Dan Abramov start arguments with engineers on Twitter. So why did I just choose to switch to React after several years developing with Angular?

How React Led Me To Angular

When React was in prerelease, I learned how to code components with the library. I'm always interested in trying new things. After coding with AngularJS and jQuery for several years, I was ready for a fresh start. I was learning more vanilla JavaScript at the time, preparing for the eventual release of ES2015.

React.createClass didn’t appeal to me at first because of my fascination with the upcoming ES2015 classes. I was mainly interested in how the React team claimed Virtual DOM was performant. I even went so far in those early days to architect a Virtual DOM for a library I was prototyping during the fallout from another JavaScript library called Famous. The company just halted development on Famous one day, leaving engineers in the lurch. I was experimenting with creating another Virtual DOM just to see if I could reap the same performance benefit.

Eventually React became more interesting when the library could work seamlessly with ES2015 modules. You could extend from React.Component and use TypeScript. Th I did find that React's Virtual DOM was performant, however took issue when they had to create a whole other standard to make it work: JSX. Another framework was released that promised to be closer to the features in ES2015 I wanted to explore and potentially be able to deliver even more performance gains.

Angular 2.0.0 was released. The way Angular applications are coded with TypeScript really appealed to me. The architect and performance junkie in me loved how that framework is so methodical, predictable, and when used responsibly, fast. So blazingly fast that I could reliably animate SVG by manipulating attributes through one-way data binding in Angular.

Alt Text

I was coding a waveform monitor that needed to animate bezier curves while WebGL was rendering beneath it. The results with Angular were faster than any other library I tried. Angular would animate the SVG at ~60fps, faster than even d3. Angular has solid rendering performance, sustainable patterns for development, excellent tooling, a fantastic community. Why would I need anything else? I can't speak enough about how welcoming the Angular community has been, by far the greatest group of engineers I've had a chance to hang out with post college.

I spent a few years honing my skills with Angular while React grew in popularity. Around the time React engineers were refactoring their applications to use Context, I would be grumbling at all the experts and their blog posts that extolled the virtues of React by making false comparisons to Angular. For example, bloggers will tell you Angular is slower because of two-way data binding, however Angular prefers unidirectional data flow. The default when binding to DOM attributes in Angular is actually one-way.

The Sustainable Path

I’ve never been someone who does what is popular. I tend to follow the path least travelled or even blaze my own trail. In 2019 I published a library on npm for developing Web Components with TypeScript Decorators. Readymade minifies down to ~1Kb for a "Hello World" and scales rather nicely. In my opinion, Web Components are the view layer we should be working with now and into the future. With the release of the latest Edge browser, all evergreen browsers support the spec. Staying as close to spec is the most sustainable approach for UI components in order to increase their longevity. In the corporations I’ve worked for we couldn’t afford the churn involved with JavaScript frameworks in the 2010s. We needed something that would stick.

The Lifespan of a JavaScript Framework

Some people think there is no better time to learn React but I disagree. The best time to invest in any JavaScript framework is early. You have the greatest opportunity to make an impact on the open source library early in development and can make a greater impact on the community down the line by adopting a framework sooner than later.

If you think React will always be popular, think again. JavaScript frameworks come and go. I have no crystal ball, but it's highly probable React will be no different than any other JavaScript library that came before it. There is no reliable statistic that can drive any prediction. No survey that can reliably ascertain when React will fall. npm downloads of React keep climbing however, so do downloads of jQuery, a library most web engineers would think is in decline.

This trend probably has to do with the shift to CI/CD pipelines over the last few years combined with the deprecation of legacy client-side solutions and surge in popularity of JavaScript as a programming language. It's nearly impossible to gauge when we hit the peak, because even when we do it will seem like downloads of React keep going up when probably what the graph is partially depicting is the accumulated technical debt of corporations over time: React being downloaded and installed across many servers as a dependency even when engineers are simultaneously hyping another JS framework. I wonder if React will inevitably have the same fate as jQuery and maintain skeptical any of these charts should drive any decision making whatsoever.

Why Am I Learning React Now?

Whenever I stick with one JavaScript framework for too long I get anxious. I feel like I have exhausted a lot of what there is to know about Angular. I could be growing as an engineer and part of that growth could mean applying my architectural design experience to React applications. This next month I start a job where React will be in play. I want to be the MVP of the team and eventually mentor someone else to be MVP.

JavaScript frameworks are just tools. Use the tool to get the job done.

I already understand the performance implications of global state with Redux and the pitfalls of prop drilling, even to be aware that Context may cause superfluous rerenders. I just lack some of the practical day-to-day knowledge having been invested in other frameworks and libraries.

The past couple weeks I coded some simple React applications from scratch. No tutorial, just doing. Sometimes I reference documentation or open source code examples. Over the next month I plan on scaling one of this applications while keeping it performant, using the usual bag of tricks I have accumulated from other enterprise grade web applications.

How Did I Start Out?

I started out with create-react-app, but became largely underwhelmed by the experience. It's 2020 and I want to be using the fastest tooling for building React. I also don't want to be monkeying around with Webpack when I am experimenting with building React. I ended up bootstrapping some starter code using Parcel, a build tool that is fast and has zero configuration.

Earlier this week I published some React starter code built with Parcel on Github. In a minimal amount of time I was able to get the following features baked into the starter repo.

  • ✅ TypeScript
  • ☄️ Server Side Rendering
  • ⚡️ Hot Module Replacement
  • ⛱ Lazyloading
  • 🧪 Unit Tests
  • 📖 Storybook
  • 👄 SASS
  • 🏝 PostCSS
  • 💇‍♂️ Prettier
  • 🌎 i18n

The speed I was able to bake all these features into a custom repo speaks volumes to the versatility of the React ecosystem.

I feel much more comfortable now that I know how everything is built and configured. I can experiment and learn how to integrate Redux from scratch, build out a library of components with Storybook, or even learn some of the pitfalls of server-side rendering React right out of the gate. I could have done these things with create-react-app, but if I just read a tutorial and integrated some of these features by copying and pasting I wouldn't have really learned anything. I learn by doing.

Even though I have some reservations with learning React at this point in time, I am willing to put those aside so I can excel at my next job. I could have accepted a job offer where I led a team of Angular engineers, but right now I feel like I need to learn something new.

If you've only been coding with React, I implore you to also take some time this year and learn another JavaScript framework. You may be surprised by what you find. I find it interesting how aspects from one JavaScript framework can help inform another and visa-versa. Some level of skepticism is healthy when learning a new JavaScript framework. I am optimistic React will surprise and delight.

During the next few months I may share some revelations. I really look forward to becoming a part of the React community. I hope to see you at a meetup or conference in 2020!

Do you have any tips for someone getting started with React in 2020? If you have any feedback for my first React starter repo, please share.


Editor guide