I see (and agree) with most of your points. But with regard to declarative syntax, as it applies to dynamic displays (the kind that have swipes, drag-n-drop, etc.), I'm not sure if I see it as an "issue" in the same way that you do.
You can do dynamic UIs in a declarative syntax... sorta. All you're really "declaring" is the initial state of the UI. All the other dynamic stuff happens at runtime. But I don't feel like that's really much of a problem - because that's essentially the same thing that happens when you code imperatively. You're still just defining the initial state. Once the user starts interacting with the UI, the base code from which the page/app/whatever was rendered is no longer a one-to-one representation of what's on screen.
It seems like part of your quandary comes down to the fact that, in a declarative framework like React, a lot of those actions/events/transitions feel like they're kinda hidden away from us, auto-magically. In the Time of jQuery, we would have to explicitly bind and define any events that we wanted to happen. This could be laborious - but I'll freely admit that sometimes "laborious" is better, if it means that we have more explicit control of everything that's going on. (Kinda like how hardcore C/C++ devs actually LIKE the manual memory management that is required in the language.)
Because html is declarative it indeed only lets you describe a single state. Usually it is the initial state. Sometimes it is the final state (for elements that animate into the screen, for example as the user scrolls).
What I am trying to say is that frameworks like React don't lend themselves at all to creating UIs like the one I show in the video. I am not saying it is impossible to build it with React but it will get in your way all of the time and you will need to constantly work around it.
You might think the app in the video is lame but think about other examples: google maps (how it zooms in and out and flies around with animation when you search); or Trello like drag and drop that makes room as the dragged item hovers over.
There is actually a react library that does proper drag and drop, beautiful implementation, super imperative under the hood (as it has to be) with global event listeners and other React no-no's.
I've used the "react beautiful d-n-d" package (which is every bit as "beautiful" as its name implies) and of course, it's chuck full of imperative stuff as well.
Some of React's shortcoming are actually self-inflicted by the community. In other words, there's this ever-increasing trend to try to wash all of the "logic" out of components. They rant about the "evil" class keyword. And they worship at the alter of pure functions. And now they're in deep, spiritual, romantic love with hooks (which is funny, cuz hooks are basically a way to use functions - while keeping all of the horrible state stuff that everyone wanted to see removed from their classes). But all of that "logic" and all of that "state" in the components is what makes the declarative aspects of the render() function work. Or, to put it another way, everything in that class that's not in the render() function is the imperative spice that makes the declarative dish appealing.
But you're correct that the "faults" of the framework go beyond coding practices and dogma. Some of them are baked right into the fact that React - like every other web-development framework before it - is still jumping through all kinds of hoops to make it "feel" like you have a state-ful environment... but the underlying nature of the web (i.e., HTTP[S] requests) is that it's an inherently state-LESS protocol.
What really made Flex cool wasn't anything to do with ActionScript or FlexML. It was the Flash player. (Obviously, we all know the faults of that same player - but in this context, it was incredibly powerful, because it provided its own runtime environment.)
To make components that aren't forced to live in a box model driven by declarative layout, you'd have to make those components reasonably "self-aware". In other words, those components would have to be more like... objects.
Imagine if your UI components were, let's say, SVGs. And each SVG didn't really "know" about whatever other SVGs already existed on the canvas. But they'd have the logic to "see" if anything was in close proximity (let's say... 50 pixels in all directions). Then, when you drag one of those SVGs somewhere else, as it comes in proximity with other SVGs, each one would perform its own checks to try to scoot outta the way in as graceful a manner as possible. (With many extra style points if that motion was also calculated under a physics-based engine of Newtonian movement.)
I see (and agree) with most of your points. But with regard to declarative syntax, as it applies to dynamic displays (the kind that have swipes, drag-n-drop, etc.), I'm not sure if I see it as an "issue" in the same way that you do.
You can do dynamic UIs in a declarative syntax... sorta. All you're really "declaring" is the initial state of the UI. All the other dynamic stuff happens at runtime. But I don't feel like that's really much of a problem - because that's essentially the same thing that happens when you code imperatively. You're still just defining the initial state. Once the user starts interacting with the UI, the base code from which the page/app/whatever was rendered is no longer a one-to-one representation of what's on screen.
It seems like part of your quandary comes down to the fact that, in a declarative framework like React, a lot of those actions/events/transitions feel like they're kinda hidden away from us, auto-magically. In the Time of jQuery, we would have to explicitly bind and define any events that we wanted to happen. This could be laborious - but I'll freely admit that sometimes "laborious" is better, if it means that we have more explicit control of everything that's going on. (Kinda like how hardcore C/C++ devs actually LIKE the manual memory management that is required in the language.)
Because html is declarative it indeed only lets you describe a single state. Usually it is the initial state. Sometimes it is the final state (for elements that animate into the screen, for example as the user scrolls).
What I am trying to say is that frameworks like React don't lend themselves at all to creating UIs like the one I show in the video. I am not saying it is impossible to build it with React but it will get in your way all of the time and you will need to constantly work around it.
You might think the app in the video is lame but think about other examples: google maps (how it zooms in and out and flies around with animation when you search); or Trello like drag and drop that makes room as the dragged item hovers over.
There is actually a react library that does proper drag and drop, beautiful implementation, super imperative under the hood (as it has to be) with global event listeners and other React no-no's.
I've used the "react beautiful d-n-d" package (which is every bit as "beautiful" as its name implies) and of course, it's chuck full of imperative stuff as well.
Some of React's shortcoming are actually self-inflicted by the community. In other words, there's this ever-increasing trend to try to wash all of the "logic" out of components. They rant about the "evil"
classkeyword. And they worship at the alter of pure functions. And now they're in deep, spiritual, romantic love with hooks (which is funny, cuz hooks are basically a way to use functions - while keeping all of the horrible state stuff that everyone wanted to see removed from their classes). But all of that "logic" and all of that "state" in the components is what makes the declarative aspects of therender()function work. Or, to put it another way, everything in thatclassthat's not in therender()function is the imperative spice that makes the declarative dish appealing.But you're correct that the "faults" of the framework go beyond coding practices and dogma. Some of them are baked right into the fact that React - like every other web-development framework before it - is still jumping through all kinds of hoops to make it "feel" like you have a state-ful environment... but the underlying nature of the web (i.e., HTTP[S] requests) is that it's an inherently state-LESS protocol.
What really made Flex cool wasn't anything to do with ActionScript or FlexML. It was the Flash player. (Obviously, we all know the faults of that same player - but in this context, it was incredibly powerful, because it provided its own runtime environment.)
To make components that aren't forced to live in a box model driven by declarative layout, you'd have to make those components reasonably "self-aware". In other words, those components would have to be more like... objects.
Imagine if your UI components were, let's say, SVGs. And each SVG didn't really "know" about whatever other SVGs already existed on the canvas. But they'd have the logic to "see" if anything was in close proximity (let's say... 50 pixels in all directions). Then, when you drag one of those SVGs somewhere else, as it comes in proximity with other SVGs, each one would perform its own checks to try to scoot outta the way in as graceful a manner as possible. (With many extra style points if that motion was also calculated under a physics-based engine of Newtonian movement.)
Interesting idea about those environment aware objects...
I don't have anything smart to add to it atm but interesting