I guess as a software developer, I see it as another tool in the toolbox.
It all depends on the type and scale of application that is being built and what resources(devs and their skills) are there to build the application.
If its a big application with lot of a complexity in the backend requiring different skills/languages then perhaps use an architecture of proper defined contracts/interfaces in the backend that is leverged using API. Hence going with the 'traditional' approach in the frontend. This will ensure modularity, easier management of separate systems without any dependency, ability to use different languages and have different teams working on different things etc.
If its small application with dev skills mainly around JS language then perhaps use SC in this case.
I guess as a software developer, I see it as another tool in the toolbox.
It all depends on the type and scale of application that is being built and what resources(devs and their skills) are there to build the application.
If its a big application with lot of a complexity in the backend requiring different skills/languages then perhaps use an architecture of proper defined contracts/interfaces in the backend that is leverged using API. Hence going with the 'traditional' approach in the frontend. This will ensure modularity, easier management of separate systems without any dependency, ability to use different languages and have different teams working on different things etc.
If its small application with dev skills mainly around JS language then perhaps use SC in this case.