Well, I'd argue that old fashioned PHP sites are structurally really similar to modern declarative client-side UIs, in that in both cases your're basically just constructing a series of functions that (deterministically) convert the current state to HTML.
Client-side rendering without declarative framework (say jQuery or vanilla) is different, in that you also need to consider state transition. This gets complicated fast.
And of course, the trade-off between the old fashioned approach and modern declarative revolves around how much interactivity is required.
If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously!
Yeah fair call and it's more the combination of PHP + jQuery I'm referring to as being non-deterministic rather than either on their own - you can definitely write deterministic PHP and jQuery code, but the implicit integration between them (PHP rendering HTML which becomes a DOM which jQuery imperatively operates on) is what I'm saying makes it non-deterministic. I'm mostly talking about the part you mentioned in managing client-side state using a non-declarative paradigm, where you either end up with a stupid amount of unnecessary complexity (conditions checking the prior state of literally any and everything you touch, I've never really seen this in a production project) or making naive assumptions about the DOM which means non-deterministic and potentially unexpected behaviour.
> If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously!
Fair point but there's also a flip-side to this though. You can write a client-side PWA with all your async state and data persistence magically handled by a service like Firebase Cloud Firestore, so just writing the UI declaratively and not having to worry at all about servers or databases, which generally requires a lot more upfront planning (figuring out models/schemas to represent your data, service architecture etc) than just slapping a UI together and wiring inputs up to a production-ready persistence layer API in front of a schemaless NoSQL DB like Firebase.
Client-side rendering without declarative framework (say jQuery or vanilla) is different, in that you also need to consider state transition. This gets complicated fast.
And of course, the trade-off between the old fashioned approach and modern declarative revolves around how much interactivity is required.
If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously!