5 ms·
> 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 s
by toddheasley 16y ago
> 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.
- kls 16y agoRight, 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.
- bad_user 16y agoOK, 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.
- kls 16y agoNo 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.