Comment by unclebucknasty
5 years ago
The problem with each of these frameworks is that they make the mistake of surfacing the underlying standards like HTML and the DOM. This is why they look remarkably similar and can only possibly be incrementally better, at best.
HTML and the DOM are still essentially modeled on static documents. Building apps that deal directly with these standards is an impedance mismatch that, remarkably, people keep trying to solve by adhering to those same standards, but in a slightly different way.
Why should we know or care about HTML or the DOM?
A robust, event-driven, component-based framework that manages the low level Web standards could offer true advancement.
What would that look like for you? Something like SwiftUI or Flutter (which feel React inspired) or a totally different thing?
Yes, these are moving in the right direction, but have a ways to go and are heavy for what they do. Visual Basic of old may actually be a better example.
Even reactive models are built around matching data to the DOM, essentially. And there's still too much wiring that's required.
I think where we'll see the innovation here is in the no-code and low-code platforms, which will move away from the model of code frameworks to better componentize and abstract away the low-level details. They'll surface high-level interactions via an elegant event model, and automatically handle reactivity through easy to specify component-to-database bindings.
The concept of a lower-level code framework will be replaced by that of a simplified abstract "environment" in which devs work.
I like the database-to-component binding idea. If you squint, that‘s what a GraphQL/React app simulates (with mountains of boilerplate).
I‘m not so sure about moving up the level of abstraction in the direction of no code tools. You can make it super easy to build the 1000s of CRUD apps we need today, but a dominant UI toolkit needs to be low-level enough so we can also build the kinds of apps we don‘t know about yet and the no code tools to make those apps. I think the component model popularized by react is here to stay for a while, especially because it fits in perfectly with the low/no-code tools, but everything around I can see improving.
perhaps you are right about DOM but isn't HTML/XML just a way of representing an object tree... I don't see anything inherently wrong with this?
Yes, but while great for telling a browser how to render that tree, it's not an efficient way of mentally representing a frequently-updating app-driven UI.
What devs are really rendering is a tree of components, laid out on a canvas. There's no reason they should have to think in terms of how those components are managed or represented in lower-level HTML, any more than in binary.