Simple problems call for simple solutions. The vast, overwhelming majority of webpages are simple problems, solved by a server serving HTML. A 'simple API serv

Simple problems call for simple solutions. The vast, overwhelming majority of webpages are simple problems, solved by a server serving HTML. A 'simple API server' sounds lovely, but it's not getting your website to anybody without a frontend - and the complexity of the frontend offsets any savings made by simplifying the backend. I'd also very respectfully push back on this 'simple API server' business - serving /fie/fo/fum.json really isn't very much simpler than serving /fie/fo/fum.html; you have identical business logic, plus you've now got messy bi-directional JSON objects and hundreds of Ajax calls over unreliable end-user connections to contend with. It's the voluntary introduction of hundreds of unnecessary failure points. For most 'simple API servers' there's an alternative, and much simpler, much safer, much saner HTML server. For that tiny number of websites that do require accompanying apps (mobile, etc), 97% of these could be solved with a thinly wrapped web-view. Those that cannot generally have special needs, and therefore cannot be solved by simply serving the same API endpoints across web and app anyway. If you're already separating your web and app APIs, plus now you've got a tangled web frontend to contend with, I'm really not seeing the benefits of reorienting your backend around APIs to begin with. A backend serving HTML to web, and a custom API to mobile is much more elegant and flexible (and doesn't actually require a soup of Javascript anywhere). But we're already in the 3% of the 3% here - truly unusual applications. The vast, vast, vast majority of use cases were already solved by a server serving HTML.