|
I am not sure the author really knows what they're talking about when comparing today's web development with earlier systems. First of all, the reason for useEffect() is not directly asynchronicity. It's mostly an optimization to give React control over what code it needs to run when the state changes. This is because with React, you basically re-render a document with every state change, and in order to speed this up, React needs to know what code depends on what part of the state. Admittedly not pretty, but all of the more automated MVC-like systems have mechanisms to detect or handle model changes. They are completely wrong about asynchronicity. Since the 80s GUIs have been using event loops. Windows 3.x did this, and even really old UIs like GEM did. When using an event loop, you must execute operations asynchronously or the event loop will block. That's not new at all. What's new is that, these days, applications are interacting a lot with the network, and these are blocking operations. They require asynchronicity in an event loop. This wasn't really the case back in the days before the internet, when everything was local. And for longer computations you had to call functions like yield() to give time to the UI. He mentions threads, but they didn't really became a thing before the early 2000s. And threads never worked very well with most UIs (except the good old BeOS?). It's easy to complain about issues with today's development frameworks and easy to overlook the limitations in the past. UI development was always a pain, especially for applications that are larger than the typical demo app. I have worked on apps using GEM, MFC, QT, GTK, TCL/TK, AWT, Swing, JavaFX... it doesn't matter. It always sucks one way or the other. Today's web-based UIs and their dev tools are a marvel in many ways. Like you can easily update them without going from computer to computer, or let user run install programs. They easily adapt to all kinds of screen resolutions and screen orientations. You can easily debug them in the browser, even on an enduser's computer. You have package managers that make it easy to add and later update libraries. Certainly not everything is perfect, I still kind of hate UI development, but it's a huge improvement over everything we had in the past. |
The other thing they've missed in why people moved to react in droves is so simple it's possible we've just forgotten it because it's become such a de-facto approach: co-location of declaration, behaviour and styling.
React took us out of the "X belongs with all the X things" mental model and allowed us to create isolated "X does this and looks like this" things that require far less mental overhead to drop into while making changes to a potential foreign codebase.
This is _exactly why_ Facebook preferred React to the status quo. Engineers changing one thing in one place with predictable effects is wonderful for teams operating at wide/deep scales.
Again, I'm not advocating for any of this, I just don't think skipping over history or twisting it into an unrecognisable ball gives any forward momentum to conversations about the evolution of UI/UX.