Comment by vidarh

> The thing is, what you are serving to the browser is always a View-Model. If you serve a Model instead you are just "silently casting" it onto a View-Model because at that moment they are identical. Sooner or later the need will arise to imbue this with some presentation specific information attached on the fly to data from your data layer Model.

There's a huge difference in the level of presentation specific logic you include, though. E.g. between including the publication date of something vs. including the publication date in 4 different ways because it needs to be presented in 4 different ways in different formats and templates. One is about having to ensure a superset of the information required is available, and that superset can often involve very limited overhead (and can even end up being "cheaper" through being able to have fewer, more heavily accessed, cached items), while the other means you need to closely couple it to specific details of the presentation.

> I no longer try to use XSLT either, but I think web components are completely orthogonal tool. Your XSLT could still generate web components if you like. You could even "hydrate" generated HTML with React for interactivity.

Web components alone maybe, but combined with a higher level framework that also lets you do server side rendering, we're back to being able to serve up a single format and choose to transform it either on the server side or client side as needed, without the pain of XSL

> Your XSLT could still generate web components if you like.

Yes, but I wouldn't gain anything at all from that other than the pain of dealing with XSLT.

> What XML+XSLT was solving was basically skipped entirely by programmers.

Because XML+XSLT wasn't solving it in a way that was good enough even for people like me who badly wanted to like it. We got it to work, but neve