[ludicrousdispla]

I'll add a secondary, or implicit, criteria that the approach you take should not require a 'build process' for the front end app.

M -> the MODEL is managed by the backend server, or in-browser via WASM

V -> the VIEW is defined by the HTML and CSS

C -> the CONTROLLER can be solely Javascript in the front-end, solely backend server processes, or most likely a mix of the two

[kristopolous]

model is html

view is css

controller is js

that's why there's 3.

[brazukadev]

er... no. html+css is view, js is model and controller.

Maybe, if by html we are saying html+dom+webAPIs (indexeddb, localstorage, sessionstorage, cache API), then yeah, you'd be right.

[kristopolous]

huh I guess abstractions can lead to a break in consensus. You sound as confident as I feel on the matter but we're at different places.

Maybe that's all that "good design" is ... surely there's other systems and architectures where we can confidently reach the same conclusion independently.

For instance, here, I thought we have a well-done separation of concerns that is a bit exotic and people refuse to understand it.

However, as I explored how I disagreed with you, I realized that there's obviously messy concepts that I map differently than you do. So in truth we have an ambiguous design! I'll have to think about this some more.

Maybe usability issues arise not from tools that are "difficult" to use but tools that don't afford a clear mental model on their fit and purpose.

[zlacker]

That's right, MVC is a very simplified model that's actually quite useless in practice. The reality, is as you have reflected, is messy with cross-cutting concerns, and it's often the case that it's not easy or obvious where the lines are drawn.