GUI w/ MVC: Xerox Alto, 1974 (info)
// TODO: add Vincent Price meme
Because
MVC was pioneered by GUIs and revolves around constant transparent interaction with a data model (e.g. window management).
It has since been adapted for other systems and is on of the most widespread paradigms for interfaces.
— Jean-Jacques Dubray: Why I No Longer Use MVC Frameworks, 2016
A typical MVC explanation from the API viewpoint goes: For a single data model, we can produce multiple view variants, as in “skinning”.
A typical MVC explanation from the API viewpoint goes: For a single data model, we can produce multiple view variants, as in “skinning”.
From a UI perspective, more often than not, the same template/component is applied on multiple models – think Wordpress post types with different data but a identical layout.
While things like data-binding are surely hard problems, they don't make up great parts of most web applications.
Tellingly, a lot of examples for applications teaching the MVC model revolve around controller-heavy interfaces like todo lists and form dashboards, while even complex apps usually don't feature heavy two-way-communication.
fetchUser(id).then(user => {
// Got my user!
if(!user || !user.name)
throw new Error('wat')
}
})
//Later
if(user && user.name){
render(user.name)
}
— Nicholas Kariniemi: Fear, trust and JavaScript, 2018
— Sam Newman: Backends For Frontends, 2015
— Katherine Senzee, 2019
— Jeff Eaton, 2019
— Model–view–viewmodel (John Gossmann, 2005)
— Heydon Pickering: Reluctant Gatekeeping: The Problem With Full Stack, 2018
This being a living standard can produce blurry specs.
But the trouble with MVC lies not in the concept but the overly broad and unreflected application across domains of different crafts.
There is not only a semantic gap but an artisanal one – see the frontend divide pretext.
While sounding a bit grumpy, the that MVC-critique article inspired me to question my setup more confidently.
And make up an architecture that fits my domain better – my “small stack”.
Using the MVC pattern, concept and backend can deliver a wireframe that answers these questions:
MVC semantics fit the editor experience: The model is supposed to be fully transparent on backend views which make use of controller logic.
Acknowledging the differences between systems stops sabotaging two otherwise elegant concepts with deep interoperability needs.
Acknowledging the differences between systems stops sabotaging two otherwise elegant concepts with deep interoperability needs.
Yeah, this sounds a lot like decoupling.
But we're not talking routers on the UI side.
slides:
- img:
750: /promo/slides/cta-welcome-square.jpg
1440: /promo/slides/cta-welcome.jpg
- img:
750: /promo/…/promo-foobar-BF20190318-square.jpg
1440: /promo/slides/2/promo-foobar-wide.jpg
tiles:
- img: /promo/tiles/1/tour.jpg
- img: /promo/tiles/2/promo-foo.jpg
- img: /promo/tiles/default.jpg
'id' => 'foobar',
'slot' => 'tile_3',
'img' => [
{
'path' => 'public:/tiles/test.jpg',…
},…
],
'filters' => [
{
'id' => 'to',
'value' => 1552392082,…
},…
]
Fellow frontenders, sit your ass down:
Fellow frontenders, sit your ass down:
create your –own– API and map data yourself.
You have the “stack” knowledge to design your own systems.
Accompagny every component class with a mapper that speaks to backend.
Fill in missing UI content (copy, labels, legends …) yourself.
You have the “stack” knowledge to design your own systems.
Actually, even duct-tape-spaghetti-code will do – you're bothering nobody but yourself.
post-people.php
echo component('tiles', $people);
post-events.php
switch ($view) {
case 'grid':
echo component('tiles', $events); break;
default:
echo component('list', $events);
}
Slides:
stolzenhain.net/slides/post-view
Opinions:
feedback@stolzenhain.net
—
ⓒ 2019, Florian Stolzenhain