This Why we should ditch React talk is must-watch stuff. Chris Hawkes, is a Senior Software Engineer with over 15 years of experience working for Fortune 500 companies. He has been coding on React for 5 years. He has coded on Angular, Vue.js, and all the smaller ones (jQuery). Itâs a interesting chronology of JavaScriptâs history.
Highlights
I was so into this, I transcribed it. These are mostly his words, with mine mixed in.
-
Framework Hell - âAll the frameworks & libraries try to accomplish the same thing, from jQuery on.â
- âGlobal Scope problemsâ
- âToe-stepping from CSS rules bleeding into other elements. So we stuck
!important
s everywhere, which is an anti-pattern. Now everything isimportant
and youâre back to the first problem again.â - âDOM updates from JS sometimes bleed into other elements you didnât expect.â
- âThe problem compounded further when 6 different JS libraries are all doing DOM updates simultaneously. We had little control over which one âwonâ.â
- My Input: All your code now coupled to that Framework or libraryâs code.
-
Web Components - âSolves the Global Scope (bleed) problem.â Solves the Element-idempotency problems.
-
Virtual DOM
- âJavaScript-based, in-RAM DOM layer in front of actual DOM. Queues updates until you call .render(). Performance gains. Also the Virtual DOM is smart about preventing no-op updates. Itâs provides Idempotency. It wonât update elements that didnât need to happen because the Element was already as you specified.â
- âReact & Vue.jsâ
- My Input: Hefty. Lots of code, transpilers, new tools, new workflows. Sharing state between siblings is tricky, etc.
-
Shadow DOM
- âNative in browsers. The browser manufactures solved these issues natively. The ShadowDOM has existed for years, but they are just exposing it to Devs so Devs have a way to do this âComponent Patternâ natively.â
- âNo longer need a JS lib like React to do your Virtual DOM.â
- Browser-Native Web Components
- My Input: Uses real DOM manipulation. There will be time before all browser manufacturers agree on specs an implement. Currently all Major ones support except legacy Edge. Latest Edge that is a Chrome instance does support it.
-
Virtual DOM
- âReact was very successful because of Angularâs failure.â
-
Angular - Created by Google.
- âAngular reacted to what React was doing and decided to rewrite their entirely library. Version 2.0 scrapped everything from 1.0. It wasnât backward-compatible. They decided to use something new and young at the time, TypeScript. Devs lost their minds. They had to completely rewrite their libraries, completely relearn Angular, etc.â
-
JSX / TSX - Uses JS to write HTML. Has way to embed CSS using inline styling.
- âThis was a big problem for a lot of devs. The Golden Rule was to always separate your JS from HTML and CSS.â
- âAll this learning had to be done. Now we have to use all these tools to transpire everything: WebPack, Babel, etc.â
-
React - âGreat encapsulation. No more bleeding DOM elements. Widgets are easily reusable in other systems.â
- My Input: Communicating events across sibling Elements is tricky. You have to bubble it up to a Root-level State, then Event it out to the other components using Properties.
- My Input: Too complex. You donât know which feature to use for which use case.
-
My Input: Not learnable thru experimentation.
- You have to take a 100-hour Udemy course because itâs a:
- Proprietary framework with a very creative implementation.
- Svelte to me minutes to learn at my last job because itâs a conventional implementation. So did CoffeeScript. Producetive in days
- My Input: Not opinionated. Project structure gets very disorganized quickly, each dev doing radically different things in different parts of the codebase. You often see 3 or 4 different implementations in 1 repo. There is nothing enforcing the implementation of the dev who first rolled it out.
-
Flux Architecture âsolvedâ that
- âFacebookâs approachâ
- âNightmare: The architecture sucked. And it RAELLY did. I really did not like that experience.â Many developer threads out there about this problem.
-
Redux - Redux promised to be a âmuch easier to reason about State than Fluxâ.
- âOne centralized State Store. How did it achieve this?â
- âSynchronously.â Huge problem
- Problem: It breaks down if you tried to do anything with Promises. If you had an AJAX that used Promises, and you needed to update your State, you couldnât do that. Even to this day, Redux doesnât do that. To solve that, they brought out:
- ReduxFunc library. Workaround / hack. Thereâs also one called âReduxSagaâ, and âall this other crapâ. His words.
- âShort-sighted React architecture gave way to all these other hacky tools.â
- Devs bitched: âThis is too much work for all these different components to work with each other. Itâs too much code to write these Class-based Components.â
-
âReact reacted to that by creating Functional Components.â
- âEveryone has to pump their breaks, figure out Functional Components, rethink how theyâre doing Components, and rewrite everything to Functional.â
- âYou donât use Functional Components, youâre an asshole.â
- Functional were deigned to live along side (not replace) Class based, and be used in tandem depending on the use case. If you need State, use Class based. If you donât, use Functional.
- Since Functional components are not objects, you must use React hooks to manage State and lifecycle events. Hooks were not introduced into React until version 16.8, but they have effectively made Class components redundant.
- More cost porting the whole repo to Functional.
-
Svelte
- âInstead of Reactâs library that you download into the browser, that has to do all sorts of internal manipulation and handling and DOM DIFFing. All this logic to determine whatâs been updated so it minimizes re-updating.â
- âSvelte comes along and says âWeâre going to do all that work in advance. Weâre going to compile all that into JS in advance.â
- âSmaller footprint. Easier on Client browser.â
- React reacts to Svelte
-
React Hooks
- âWrite Func Components in a completely new way.â
- âNow Devs had to completely rethink and relearn the way they use Reactâs lifecycle.â
- âYou donât use React Hooks, youâre an asshole.â
- âMore rewriting, etc.â
- âThe whole point, behind this video, is that maybe we should ditch React because of its shortsighted architecture.â
- âMaybe we should stop being these herded animals following each other from one side of the field to the other. We keep going around in circles and getting nowhere.â
- âEmber, Glimmer, etc. All the same thing.â
- âWe keep having to rewrite our architectures.â
- âNative HTML and CSS and JavaScript essentially do what most of this stuff does.â
- âTons of companies out there using Redux, and they have no idea why.â
- âAnd we wonder why we have to pay Developers $140k a year.â
- âWhen we first started using React Components, they werenât encapsulated. So we had to start using all these CSS libs that styled the Component specific to that style. Nothingâs worse than a bunch of inline styles, whether itâs in the Component or not. Granted, with React you can centralize the CSS. Even if we have tools that allows us to write CSS outside of the component, thereâs all kinds of new problems to solve. When we were trying to solve the problems with the ShadowDOM 10 years ago.â
- Commenter on that YT video: âFacebook never intended for React to be used as an application framework. They created React to be the "V" in their "MVC" variant called "Flux." For some reason, the developer community started using React as a stand-alone framework, which introduced the problem of defining models inside views, then using all kinds of spaghetti code to make those models accessible to other view (props drilling, context wrapper hell, etc..). Groupthink is truly fascinating.â
- Another commenter, Dan Levin: âSvelte is the only one so far that got it right. I started learning React recently for a job and I was pretty shocked from the amount of unintuitive convoluted code just to implement a glorified global variable. This problem that React has been trying to fix for a long time doesn't even exists in Svelte, Can you imagine? a framework that implement a global variable that whenever you change it all components update accordingly.â
- Framework Hell
- THE SOLUTION TO THIS MESS! Browser-native, or extremely light components.
Solution: Lit, Slim, or Vanilla-JS Components
-
Lit - Formerly:
- Polymer - Polymer was created by Google, and became Lit.
- âWhen Polymer first came out, it was a âutter piece of crap pre-1.0â. It was so large, you had to use all these Polyfills to support it. Itâs much better now.â
- Best thing about this project: Itâs goal is to not exists one day. Eventually go away, and be replaced by the native-browser Shadow DOM.
- Itâs a small Polyfill for the older browsers that donât have a full Shadow DOM yet, and to abstract away differing implementations from you.
- Itâs analogous to the old HTML5 âshimâ library. Its purpose was to go away once the browsers caught up.
Also similar to how we can write ES6 today, and Babel and WebPack abstract that away from us by transpiling to legacy JS. When ES6 browser support is wide enough, you can lose Babel, Vite, etc.
Conclusions
- There are better alternatives to React.
- We can use native-browser Web Components now!
- Never have to rewrite our components in the future.
- When they do become browser-native, think how light (in RAM) and fast theyâll be. No heaps of abstraction between your code and the Component.
Lightweight đȘ¶ JS Frameworks Are đ
-
Lit libraries are awesome - formerly Polymer
- Not immature. Polymer has been in development since 2013.
- Google's "Material Design" libs for widgets. I used them in my React project and liked them.
- Polymer is used by a number of aGoogle services and websites, including the redesigned YouTube, YouTube Gaming, the redesigned Google Earth, Google I/O websites, Google Play Music, redesign of Google Sites and Allo for web.
- Some non-Google cos using it: Netflix, Electronics Arts, Comcast, Nuxeo, ING, Coca-Cola, McDonald's, BBVA, IBM and General Electric. Not that âbecause Compony X use itâ is any reason to adopt. Thatâs just me researching its legitimacy myself.
- Preact - My personal site is built on it.
- Vanilla
- Slim
- Mithril
Top comments (1)
Very interesting to read. Though, I don't think React's usage is going anywhere soon.