Frontend developers spend a lot of time focusing on their frontend framework of choice, whether that’s React, Angular, Vue, Ember, Polymer, or something else. If you ask a React developer what they think of it, they’ll probably tell you it’s one of the biggest innovations in frontend. An Angular and Ember dev will say the same about their framework, respectively.
I consider myself a polyglot, both when it comes to programming languages, but also backend and frontend frameworks. Recently, I’ve been spending time learning and using React and Vue on real projects ahead of Ionic’s eventual support for them, and it struck me how similar they are to Angular, both 1.5+ and 2.x+ (p.s. I’m enjoying them both very much!)
In all these frameworks, we have a simple component model (pre-component() angular was a special kind of unique, I’ll give you that). We can set properties on the components, update them in a unidirectional way, and efficiently render them only when necessary, minimizing DOM modifications and avoiding classic frontend performance traps. State can be set on components, whether through a custom state system ala React, or class instance data ala Angular 2.x+ (with help from zone.js). We can even start to target non-DOM environments in most of these frameworks if we like.
It wasn’t until I tried using Redux that I realized that we’ve all been duped: the true 100x innovation in frontend development isn’t at the component level at all, it’s actually at the state management level.
Nearly every classic large frontend engineering project has run into the mess that is poorly managed application state. It causes complex processes and bugs, kills projects, burns out engineers, and makes programming not fun. Since the vast majority of the work building real software involves state management, it’s clear that this was and continues to be the biggest pain point of frontend engineering.
Redux and the systems that preceded and will succeed it, fundamentally change developer’s relationship with state. In many cases, it can completely liberate a developer from having to repeat themselves over and over managing the same kind of state operations (API calls, loading indicators, etc.). Reduces bugs by centralizing state management, and helps developers create pure components that only need to worry about the properties they’ve been passed. Building and implementing these features is nearly identical in all modern frameworks, but is completely different using a system like Redux.
At Ionic, we’ve started to embrace Web Components, primarily because we want every frontend web developer to be able to use our components in their app regardless of the frontend frameworks they like to use. I no longer consider the component level to be something worth siloing by framework, the potential lack of compatibility with other frontend frameworks is a cost I’m no longer willing to bear, now that I know it’s unnecessary.
Instead, my excitement for frontend is almost entirely focused on Redux and better state management. Nothing has improved or changed my relationship with programming as fundamentally as adopting Redux has, and I’m excited that the model is making its way into all major frameworks (examples: vuex, ngrx/Store).
Now that I know that State Management is where the next huge gains in developer productivity and application architecture quality will happen, I’m focusing all my reusable component efforts on generic component systems like Web Components. They aren’t perfect, but by focusing on them, I can reach considerably more frontend developers than ever before, and stop fighting a pointless war over the component model, when the real gains are to be had in state management.
It’s 2017. All the component-focused frameworks are awesome, it’s time to create compatibility and focus on the next major innovations in state management.
