Firstly, when you provide a normative assertion, at least couch it in positive terms.
“If you want X, then you should do Y.”
That way people at least know the tradeoffs you’re opting them into. I really can’t tell what trade offs the author is proposing are better for me.
Secondly, if you can’t build a system that actually decouples the frontend and the backend, that’s a “you” problem, not a technology problem. I have successfully designed and implemented many APIs that operated completely independently of the UI, allowing both the UI and power users to interact with our platform through a shared service.
I do get so tired of people presuming their specific issues are everyone’s issues. I have zero problem with the tooling of an SPA, my ability to customize is increased, not decreased, when I use an SPA, and when I’m working with other people, they often prefer not having to think about the whole stack, which makes them happier.
This is one of those articles you read that shows up “unplugged” from the culture in which it originated. The author demonstrates the value of talking to others in a given field, and the pitfalls that one can get trapped in when one doesn’t socialize enough professionally.
Building a public API and having your frontend consume it is quite easy and would result in a decoupled design.
"But then the frontend is 'coupled' to the backend!" you might say, but you would misunderstand the definition of "coupled," as both the frontend and the backend would need to be connected together for that term to apply.
“Couples” means two-way. Of course your front end will depend on your backend, the problem arises when they become interdependent; when you can’t develop one without making changes to the other.
In this sense a frontend and a backend can be entirely independent, and in every sense the backend should be independent of the frontend.
Firstly, when you provide a normative assertion, at least couch it in positive terms.
“If you want X, then you should do Y.”
That way people at least know the tradeoffs you’re opting them into. I really can’t tell what trade offs the author is proposing are better for me.
Secondly, if you can’t build a system that actually decouples the frontend and the backend, that’s a “you” problem, not a technology problem. I have successfully designed and implemented many APIs that operated completely independently of the UI, allowing both the UI and power users to interact with our platform through a shared service.
I do get so tired of people presuming their specific issues are everyone’s issues. I have zero problem with the tooling of an SPA, my ability to customize is increased, not decreased, when I use an SPA, and when I’m working with other people, they often prefer not having to think about the whole stack, which makes them happier.
This is one of those articles you read that shows up “unplugged” from the culture in which it originated. The author demonstrates the value of talking to others in a given field, and the pitfalls that one can get trapped in when one doesn’t socialize enough professionally.