Eh, I don't think it has to do with being "hand crafted".
I think the notion of declarative is some flawed bunk - to tell the framework "what" to do you need to specify "how" - removing the how and pretending you will magically infer the intention is a recipe for disaster.
"and most engineers probably don't have the skillset to be able to do this"
The irony being declarative languages require a higher bar of skills to use well, without the UI falling over.
"implementing features and shipping customer value"
Again, you can build bad code fast, but eventually more garbage is just more garbage, you have to go back and "fix" it or the value proposition shrinks faster than value added by new features.
If I want an input box to flow to fill the width from its starting point to the right side of the window/display minus a margin... what's so bad about the UI tooling handling this? I mean, I've worked with tools where it's a lot of work to maintain that simple thing, that you wind up doing over, and over again... What value does it really add in spending even a half hour (often more) just handling layout reflows... we're talking about computers in your hand that are more powerful than super computers a couple decades ago, and faster than desktops even a decade ago.
It isn't a new problem, HTML solved it relatively well several decades ago now... not that HTML has been the pinnacle of performance, it's been pretty damned effective at delivering a layout/form that can scale to the user without excessive effort.
That's not what declarative is, though, "imperative" or OO frameworks have layout managers (too).
There is some confusion, i.e. a spectrum (declarative first or imperative first, somewhere in the middle), about what is meant by declarative e.g. this article mentions android as "imperative"
https://medium.com/everything-full-stack/declarative-ui-what...
In addition to layout managers, UIKit and AppKit both have constraint based layouts if you use Autolayout. Autolayout itself follows the declarative paradigm (well unless you use it to manually and directly set every X, Y, width, and height constraint, then I guess you are using imperatively). You can declare that a button be two thirds the width of its parent, for example. It’s also fast (well I guess I mean between Apple’s optimizations and modern cpu speeds, there is only noticeable latency when you do intentionally ridiculous things like trying to layout one view per pixel with nested, relative constraints).
It’s kind of funny comparing it to SwiftUI’s new .layout API. It’s the exact opposite! A declarative UI framework with an imperative layout option.
I think the notion of declarative is some flawed bunk - to tell the framework "what" to do you need to specify "how" - removing the how and pretending you will magically infer the intention is a recipe for disaster.
"and most engineers probably don't have the skillset to be able to do this"
The irony being declarative languages require a higher bar of skills to use well, without the UI falling over.
"implementing features and shipping customer value"
Again, you can build bad code fast, but eventually more garbage is just more garbage, you have to go back and "fix" it or the value proposition shrinks faster than value added by new features.