|
The other day, I mentioned that I'm joining Nebula.tv as a developer, working on their streaming platform. One of my students mentioned that they were disappointed that I was giving up and taking a React-based job despite telling people not to learn React for nearly a decade… Except that's not what I actually tell people. Let's dig in! Vanilla is very capableI love vanilla JavaScript. I think it's incredibly capable. I think a lot of stuff people claim is hard with vanilla JS isn't anymore, and hasn't been for quite some time. I think the browser-native web is growing in good, meaningful ways. That hasn't changed. But there is still one thing the native web doesn't really have yet… Why state-based UI?State-based UI, as a concept, is pretty neat. You define some data, and how the UI should look based on the "state" of that data. For example, here's a list of Where state-based UI shines is that it's typically reactive. Whenever the data or state is updated (in this case, the You can absolutely do the same thing with manual DOM manipulation, but you have to do a lot more if/else conditional work to account for how the UI in the DOM currently looks. In many apps, I think it's a worthwhile tradeoff, but as the complexity of the UI increases, the value of state-based UI goes up. And it becomes even more valuable when you have multiple pieces of UI tied to the same data. Imagine a checkout cart UI where adding or removing an item in your cart updates the count in the upper right-hand corner and adds a new row to the checkout table and updates the total cost and the tax amount and the shipping. Vanilla JS doesn't have a good solution for that (yet)There's no native reactivity in JavaScript (yet). You can technically whip up your own reactive data solution with Proxies. And there's a native Signals API as a proposal right now. But where libraries really shine is with DOM diffing. When you update the UI using React or Preact or Vue or Solid or Svelte, the whole UI isn't re-rendered. Just the part that changed is. To do that with vanilla JS, you need to write a DOM diffing library, at which point you're basically recreating a state-based UI library. Libraries are good, actually!I've never been advocated against libraries in general. I speak often about picking the right tool for the job. We as an industry tend to reach for one-size-fits-all Swiss Army knives, when often a basic spoon is the tool we actually need. And I think it's fair to say that React is a Swiss Army knife. Today, I think libraries like Preact or Svelte—with their smaller footprint, modern web APIs, and fewer abstractions—are generally a better choice for performance, resilience, and even developer ergonomics. But… It's never that simple!I wasn't at Nebula when they chose React. I'm not even at Nebula yet to ask that question. But after doing dev work for over a decade, I know that the tradeoffs that lead to tech decisions often aren't as black-and-white as they appear on the outside. Sometimes, they are just because someone got caught up in the hype cycle. But for complex apps (and streaming apps are complex), state-based UI can be a really boon. And once you're locked in on a tech stack, the cost of switching is often not worth it. There's way too many things that could break as a result of switching. It's a risk that, in my experience, is rarely worth taking. No job is perfectI have an established record of saying that there are jobs out there that don't require React. There are also plenty of recordings of me very specifically saying that if getting a job is your top priority, React is probably a worthwhile thing to learn. What I'm finding in today's market is that there are also plenty of jobs in WordPress, PHP, Drupal, Python, and so on. You could absolutely get hired as a developer without React. But for me, personally, using React was a small tradeoff in exchange for working with a team I really hit it off with on a product that I love for a company that fairly compensates its creators with a co-op model and treats their employees like adults instead of children. This job is, for me, about as close to perfect as it gets. Your math might be different, and that's fine, too! Cheers, Want to share this with others or read it later? View it in a browser. |
0 Komentar untuk "[Go Make Things] The when and why of state-based UI"