Have you looked at this from the angle of object constructor or function parameters? Let's say you build an object called Person. They have first_name, last_name, phone_number. That's what you probably will pass into a new Person. Now let's say you build an object called BusinessCard. Most people will be tempted to pass in BusinessCard.new(first_name: person.first_name, last_name: person.last_name, phone_number: person.phone_number) or simply BusinessCard.new(person). What I suggest is that you should pass in BusinessCard.new(main_text: person.first_name + ' ' + person.last_name, secondary_text: person.phone_number). This, but for webpage. Your front-end defines the constructor parameters for the page, and back-end passes them in.
> your backend will now do what was doing before AND also will need to handle UI elements and relation between them.
So you have duplicate data architecture/knowledge in UI
I don't think it will need to handle any elements, it will only need to construct the page by passing in what the page needs, not what the backend has. Just like constructing any other object or calling any other function.
In a way yes, you can say that any caller that constructs any object couples itself to said object, because it passes the specific arguments needed for its construction. Instead, we could provide access to the entire database, and allow objects to construct themselves by fetching any data they like. I guess I can agree with your characterization, but this would be considered an unjustifiable anti-pattern in any other context, because it makes it easy to lose track of dependencies, and makes it hard to optimize things. "Let's have objects auto-construct themselves from global state."
> it will be like saying in a traditional simple HTML app that I should name tables and columns in DB as they are in the UI
This part seems incorrect. Just because you pass parameters to construct an object, doesn't make it like having said parameters live in a database in the same format as the object constructor that accepts them. The entire point is that they are not the same, and need to be adapted to construct various things (pages in the front-end among them).
> your backend will now do what was doing before AND also will need to handle UI elements and relation between them. So you have duplicate data architecture/knowledge in UI
I don't think it will need to handle any elements, it will only need to construct the page by passing in what the page needs, not what the backend has. Just like constructing any other object or calling any other function.
In a way yes, you can say that any caller that constructs any object couples itself to said object, because it passes the specific arguments needed for its construction. Instead, we could provide access to the entire database, and allow objects to construct themselves by fetching any data they like. I guess I can agree with your characterization, but this would be considered an unjustifiable anti-pattern in any other context, because it makes it easy to lose track of dependencies, and makes it hard to optimize things. "Let's have objects auto-construct themselves from global state."
> it will be like saying in a traditional simple HTML app that I should name tables and columns in DB as they are in the UI
This part seems incorrect. Just because you pass parameters to construct an object, doesn't make it like having said parameters live in a database in the same format as the object constructor that accepts them. The entire point is that they are not the same, and need to be adapted to construct various things (pages in the front-end among them).