11 ms·

Arguably, the opposite is true. The view is more washed out across the stack if back-end supplies generic fields, and front-end decides how to use them. Now you

Arguably, the opposite is true. The view is more washed out across the stack if back-end supplies generic fields, and front-end decides how to use them. Now you no longer know who is responsible for which decisions, and have to look for them everywhere in the stack. If back-end provides the entirety of data to build the page, then you limit front-end decisions to UX based on the specific data, and no longer allow them to pull in new functionality or foundational business logic over to their side.

Terretta 3y ago
> arguably... view is washed out across the stack Perhaps to argue this requires munging "view" with "front end"? MVC needn't mean database schema, front end, and logic. It could, but then what is a "view" in the database? Perhaps you're reinventing MVVM? https://en.wikipedia.org/wiki/Model–view–viewmodel https://en.wikipedia.org/wiki/Model–view–viewmodel
- jmilloy 3y ago
  MVVM definitely came to mind as I was writing my comment. The model is clearly in the back end, the view clearly in the front, and the view model contains the explicit link between companyName and pageTitle and can live in either. Here the suggestion is to put it in the backend and serve it as JSON.
  - Terretta 3y ago
    I'd say "kids these days" but all 3 of our accounts joined in 2010.
    - hakunin 3y ago
      I'm suggesting to pass via JSON what we used to pass via HTML back when front-end was templates on the server. I still prefer those days, like I alluded to in the first paragraph of the article. It used to be: write your template by inserting database values into it. Now I'm saying: instead of a template, come up with a neat json structure that kinda represents that template, and insert your database values into it. Name the fields after what page needs, not what you have in the database (following standard practices of object construction). I'm not sure what I might be reinventing, or what it might've been called, because I'm just trying to explain a practice that saves time and reduces complexity in simple language. It's interesting if it already was a thing with a name, but doesn't really change the point.
jmilloy 3y ago
I think if the back end provides generic fields and the front end acts as an independent consumer of the API, then you essentially have two apps each with their own entire MVC (or whatever paradigm you are using), one on the front end and one on the back end. So I wouldn't quite say that "the view is more washed out across the stack" but that you have two views (and two models).
- hakunin 3y ago
  Agree with this. Of course because front-end still gets to build business logic, and back-end still ultimately decides the basis on which to build it, the decision making is spread more equally between them. Perhaps calling it "a washed out view" is not strictly appropriate, but worth acknowledging that the front-end is at the mercy of what back-end decides to provide it.

Terretta 3y ago

> arguably... view is washed out across the stack Perhaps to argue this requires munging "view" with "front end"? MVC needn't mean database schema, front end, and logic. It could, but then what is a "view" in the database? Perhaps you're reinventing MVVM? https://en.wikipedia.org/wiki/Model–view–viewmodel https://en.wikipedia.org/wiki/Model–view–viewmodel

jmilloy 3y ago
MVVM definitely came to mind as I was writing my comment. The model is clearly in the back end, the view clearly in the front, and the view model contains the explicit link between companyName and pageTitle and can live in either. Here the suggestion is to put it in the backend and serve it as JSON.
- Terretta 3y ago
  I'd say "kids these days" but all 3 of our accounts joined in 2010.
  - hakunin 3y ago
    I'm suggesting to pass via JSON what we used to pass via HTML back when front-end was templates on the server. I still prefer those days, like I alluded to in the first paragraph of the article. It used to be: write your template by inserting database values into it. Now I'm saying: instead of a template, come up with a neat json structure that kinda represents that template, and insert your database values into it. Name the fields after what page needs, not what you have in the database (following standard practices of object construction). I'm not sure what I might be reinventing, or what it might've been called, because I'm just trying to explain a practice that saves time and reduces complexity in simple language. It's interesting if it already was a thing with a name, but doesn't really change the point.

jmilloy 3y ago

I think if the back end provides generic fields and the front end acts as an independent consumer of the API, then you essentially have two apps each with their own entire MVC (or whatever paradigm you are using), one on the front end and one on the back end. So I wouldn't quite say that "the view is more washed out across the stack" but that you have two views (and two models).

hakunin 3y ago
Agree with this. Of course because front-end still gets to build business logic, and back-end still ultimately decides the basis on which to build it, the decision making is spread more equally between them. Perhaps calling it "a washed out view" is not strictly appropriate, but worth acknowledging that the front-end is at the mercy of what back-end decides to provide it.