No it makes the assumption that UI logic provides the best user experience when it is closest to the UI. Services can provide any form of calculation logic that one needs them too. UI logic is removed from the server and placed with the UI while business logic and data services remain with the business systems.

> This makes the assumption that all apps are dumb frontends to a database.

I think the commenter is talking specifically about templating languages, not all server-side logic. In terms of MVC, I think the idea is that now you can move the entire view layer to the client, rather than doing half on the server and half in JavaScript.

Right, my point was that templating was a concern of the UI, yet I wanted to be clear that business logic and data services remain the domain of the application server. Further I try to remove templating from any run-time concern (server or client) by doing all static content templating in a CMS and then publishing it to a web server.

OK, sorry, I misunderstood your point.

Yes, it makes a lot of sense to do Javascript server-side for templating (client-side only is still tricky because of concerns related to crawlers, like search-engines).

But on the other hand, I would prefer the JVM with Rhino, not Node.js ... especially since using Java NIO you can have scalability for I/O bound requests similar to Node.js.

No I don't do any templating server side, it is a waste of server resources. So all of our templating Header, footer, static articles are in a CMS all dynamic elements are done via JavaScript. We use a headless web browser to serve pages to crawlers from a dedicated server. It acts as a parser for the crawlers and when it sees a crawler agent and the hash mark it acts as the client Javascript engine and composites the page. This way, we don't have a hand coded solution for a platform problem that is infrastructure related.

Why? You can have arbitrarily complex logic and computation in client-side JavaScript. Whether it's a good idea is another question.