DEV Community

loading...

Discussion on: Conceptual Gaps in Declarative Frontend Frameworks - Part 2 - Animations and Transitions Are Not "Nice To Have"

Collapse
isaachagoel profile image
Isaac Hagoel Author

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.

Collapse
bytebodger profile image
Adam Nathaniel Davis

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.)

Thread Thread
isaachagoel profile image
Isaac Hagoel Author

Interesting idea about those environment aware objects...
I don't have anything smart to add to it atm but interesting

Collapse
bytebodger profile image
Adam Nathaniel Davis

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.