So to me this is one of those things that seems unnecessary when an app is small and/or new but eventually you code yourself into a corner and realize where the idea of separation of concerns came from.
The best example in recent history is wanting to change your front end framework. If you have good decoupling you likely can leave your models in tact and migrate in a new framework in pieces. These days it seems like react is going to take us to the end of the earth but I remember quite painfully buying into a highly coupled angular 1 app, then buying into another highly coupled ember system only for them to die and having to so revolutionary migrations.
It’s also easier for later maintainers who anticipate models and views living differently as they handle different things. Moving these two together on a larger codebase can leave one feeling like they are looking for the glasses in someone else’s kitchen. Some of these conventions help us reason about things and find our way around an unfamiliar code base.
Good decoupling really does pay dividends over time in my opinion. At the outset it seems like a burden but there usually comes a day where you wish you had effectively decoupled different concerns in your code.
Everything you said is valid, but from my experience building a lot of small to medium single-page applications, the "model" in the frontend doesn't contain much business logic.
Since the backend is the source of truth, it has to implement all the business logic, and if there is some logic running in the frontend, it is probably backend logic that we duplicate to make our apps feel more reactive (i.e., optimistic updates).
In my case, since I use JavaScript for both the frontend and the backend, when I need to share some business logic, I implement it into a shared package.
So, in the end, my frontend models are mostly composed of views.
Of course, if my backends were not implemented in JavaScript, or if I was working for Google or Facebook, it would be a completely different story.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So to me this is one of those things that seems unnecessary when an app is small and/or new but eventually you code yourself into a corner and realize where the idea of separation of concerns came from.
The best example in recent history is wanting to change your front end framework. If you have good decoupling you likely can leave your models in tact and migrate in a new framework in pieces. These days it seems like react is going to take us to the end of the earth but I remember quite painfully buying into a highly coupled angular 1 app, then buying into another highly coupled ember system only for them to die and having to so revolutionary migrations.
It’s also easier for later maintainers who anticipate models and views living differently as they handle different things. Moving these two together on a larger codebase can leave one feeling like they are looking for the glasses in someone else’s kitchen. Some of these conventions help us reason about things and find our way around an unfamiliar code base.
Good decoupling really does pay dividends over time in my opinion. At the outset it seems like a burden but there usually comes a day where you wish you had effectively decoupled different concerns in your code.
Thanks, Mike, for your detailed comment.
Everything you said is valid, but from my experience building a lot of small to medium single-page applications, the "model" in the frontend doesn't contain much business logic.
Since the backend is the source of truth, it has to implement all the business logic, and if there is some logic running in the frontend, it is probably backend logic that we duplicate to make our apps feel more reactive (i.e., optimistic updates).
In my case, since I use JavaScript for both the frontend and the backend, when I need to share some business logic, I implement it into a shared package.
So, in the end, my frontend models are mostly composed of views.
Of course, if my backends were not implemented in JavaScript, or if I was working for Google or Facebook, it would be a completely different story.