I have some experience with it both as a user and a developer. Code used to save the order of columns, stuff you entered the last time a dialog was displayed,

I have some experience with it both as a user and a developer. Code used to save the order of columns, stuff you entered the last time a dialog was displayed, and the convenient data structures (i.e. easy, not best) for the front end leak into the back end As a user, I want the column order to persist when I’m moving between PCs or browsers or private windows. You lose focus on your other users: developers who integrate and build on your product Having done enough integrations, I prefer “what you see is how you work with it” mode. Because requirements usually come in a form of “there’s a button on page X, it produces a table, take it”. But when you approach it from the API side, this user story appears smeared across complex frontend code with numerous API calls and you basically have to reverse-engineer this part. Includes hours of comparing sparse docs against the network activity tab in the inspector pane. Very tempting to just $.click() the button and rip these <tr>’s out of it. That said, I don’t think you don’t need APIs. But your either-or dichotomy is wrong. If you need an API, then build it. But it has nothing to do with how pages work. Because if pages do something clever, and there’s value in it, your API users will have to repeat it. Why not push that cleverness back to where it belongs. And finally, Front end and back end become conflated It’s a whole system. Drawing an arbitrary line between graphics and logic not where the boundary between them is and repeating it in company’s structure – that creates a point of view where they conflate. If you don’t do that, there’s no conflation. Everyone just does the whole task like “add an input there from this db column”, without having to start complex interactions or negotiations. This separation is synthetic.