❄️ Holiday Sale! Now through the New Year, save 40% on Lean Web Club membership, private coaching, and all of my courses and workshops.
This week, we've been looking at harmful complexity in web projects, and why choosing React for mostly static web projects is bad.
These days, it's common for mostly static websites to have a little bit of dynamic content.
And while React can add that content, it's often the wrong choice. Let's dig in!
The problem with React
A lot of DOM interactions just don't require that much JavaScript to work, but React adds tens of megabytes of code that needs to be downloaded, compiled, and parsed. It causes massive delays in UI rendering and interactivity.
Once it is loaded, its internal abstractions add further delays to reaction time from user interactions and state updates.
Vanilla JS is really powerful!
With methods like querySelector()
, addEventListener()
, the classList
API, and attribute methods, you can do a lot with very little code! For more complex tasks, there are lots of great libraries that don't have any external dependencies.
Whether you craft your own or reach for a "vanilla JS" library, the end result is nearly always less bytes of code, a site less prone to breaking, and a code base that's easier to maintain.
Often, the vanilla JS code is actually better at what it does than React plugins are.
Doing things after DOM updates
Tools like React and Vue often batch multiple state updates into a single UI render for better performance. That's a good thing!
But as a result, there's a gap between when you modify the state that updates the UI and when the UI actually changes in the DOM. For interactive patterns that require you to shift focus based on certain user interactions (things like toggle tabs), this requires a lot of weird workarounds and hacks to implement properly.
Vanilla JavaScript provides a much more direct path between updates and DOM changes, making it as trivial as running the Element.focus()
method.
Islands of interactivity
If you islands of interactivity that would benefit from a state-based UI tool, you can still do a lot better than React.
A tool like Preact has the same API but is 1/10th the size and many times faster to both load and render UI updates. There are similar tools with potentially nicer APIs as well, like Solid or my library, Reef.
If you like Vue's syntax, they also created Petite Vue, a tiny subset of the library built for progressive enhancement.
Whatever you choose, you can render most of your static site as HTML sent from the server, and use smaller pockets of JavaScript just for the stuff that requires it.
Making the transition
If you have an app built in React or Vue and want help converting it into mostly static HTML and vanilla JS, I'd love to work with you.
I have one consulting spot left for the start of 2024. Feel free to reach out and start a conversation.
Next week, we'll be chatting about the other type of harmful complexity I often seen in my consulting engagements: using too little tooling for large, interactive, data-driven UI.
Cheers,
Chris
Want to share this with others or read it later? View it in a browser.
0 Komentar untuk "[Go Make Things] A lot of what people use React for would be better handled with vanilla JavaScript"