Ditching the Framework

Why you need vanilla web components in React

The Case for Web Components

React has become the dominant force in web development today. “2019 Stats on Top JS Frameworks: React, Angular & Vue” paints a pretty clear picture of industry dominance for React, with Angular looking relatively flat and Vue trending up. But is this a good thing for developers, and more importantly the companies they work for?

React was created fundamentally as a component model. It drives what Facebook has described as component driven development (my words not Facebook’s). While this method has tremendous benefits, one has to ask why we need React when we have web components. Further, senior leadership needs to ask itself “are Facebook’s problems our problems” (literally). Do we want to spend time and money refactoring code and training developers on Facebook’s technology, or should we align with the staying power of standards. Personally I want my risk tied to the lowest possible value stage, and that is not where React sits.

Consider that virtually every startup is almost guaranteed to fail. Most starups fail due to under capitalization, but a close second is velocity. Funding is a problem that is easily solved compared to velocity. Frameworks like React provide a springboard into moderate success that has proven indispensable for short term growth. However this is largely due (in my opinion) to poor staffing decisions. Even with these frameworks the amount of tech debt accumulated by most startups in the zero to three year mark looks like Everest. While the biggest tech debt is racked up in the testability column (making change management impossible), a close second is the improper use (and abuse) of frameworks like React. Experience is often a better way to solve the velocity problem than a poorly implemented framework.

If you still aren’t convinced let’s consider three simple laws of software development:

1. Don’t optimize for someone else’s scale (also known as premature optimization). If you’re adopting React because it will help you scale your engineering team to thousands of engineers in dozens of countries, consider that you are far more likely to scale to a dozen engineers in your current office (if you are lucky).
2. Simplicity wins. There is a famous quote from Rich Hickey: “Simplicity is hard work. But, there’s a huge payoff. The person who has a genuinely simpler system — a system made out of genuinely simple parts, is going to be able to affect the greatest change with the least work. He’s going to kick your ass. He’s gonna spend more time simplifying things up front and in the long haul he’s gonna wipe the plate with you because he’ll have that ability to change things when you’re struggling to push elephants around.” React is not simple!!! If your home grown 15k framework can get your next killer app to market then use it. In my experience almost all front ends do data entry (same thing we’ve been doing for 30 years). You can build a command map, data store, service locator, router, and component registry in a few thousand lines of code if you know what you are doing. Why in the world do you need something as complex as React to make a few screens?
3. No cargo cults. My previous boss taught me this one. If you don’t know what an API does you are not allowed to use it. If you can’t use the native APIs to produce web components, service workers, or do DOM manipulation you have a knowledge gap that needs to be addressed. Once you understand the underlying APIs you start to realize that frameworks need to do a better job of justifying their existence.

The Benefits of Vanilla Web Components

Assuming you are willing to jump off the cliff and into the world of standards based development (and no React is not a standard even though it may rely on them), what might the actual tangible benefits be?

1. Portability: software components based solely on standards run anywhere those standards are implemented. You don’t need version X of framework Y, and you don’t need to refactor your code to conform to the latest software fashion that framework is pushing.
2. Composition: Building on the principle of portability above, you can compose applications much faster when you are not hindered by framework dependencies. Reducing the list of dependencies to zero should be a goal (even if it might be practically impossible). New product ideas and changing markets often mean small teams doing skunk works. Composition is a critical aspect of flexibility, and hindered if you need to “move Elephants around” just to consume your domain specific libs.
3. Stability: React, like all frameworks, are babies in the grand scheme of things. There was a world before React, and there will be a world after React, much like Facebook. It’s been said once a standard is adopted it’s almost impossible to remove it. Standards also evolve very slowly with very few breaking changes. This is not the case with today’s leading frameworks. A responsible leadership team should always try to minimize risk and align with foundations that are not easily pulled out from under them.
4. Velocity: This is a direct result of points one, two, and three. It’s often hard work, much like simplicity, but worth every ounce of blood, sweat, and tears you put into it. You only get sustained high velocity by focusing all your effort on delivering features that matter to your end user. You can only achieve this through testable code that is laser focused on solving the problems that matter most to your product team.

Practical Example: A Vanilla Web Component

I’ve created a sample React application using a vanilla web component based on lotus-components@2.0.0. You can checkout and run the application to get familiar with the approach. But the gist is you just use refs to allow view mediation in React.

Conclusion

Do you want to be a web developer, or do you want to be a React developer? Do you want to solve for your problem domain, or Facebook’s? I would argue that the undifferentiated heavy lifting frameworks like React supposedly solve is negligible, especially now that we have web components. It’s far more valuable for a company to be in total control of its own destiny with senior engineers who can write their own boilerplate than in the hands of cargo cults and their gods.

Further Reading

Design Patterns

Custom Elements MDN

Using Web Components in React