👹🔥 How to Escape JS Framework Hell (Including React) 🔥👹

#react #javascript #lit #webdev

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 !importants everywhere, which is an anti-pattern. Now everything is important 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.
“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