> Progressive enhancement leads to less initial effort.

This is definitely not true across the board. I created a video player for reddit (http://dailyblocks.com) a while back which is completely client side rendered. Having done it this way I didn't need to setup or look for any server side technology. Simply put it up on any host that can serve up an HTML and JS file and be done with it.

> Single page and script heavy applications are more complex and take more time to develop and debug than server side rendered applications.

This also wildly varies depending on skill set and circumstances. Being a completely client side app all of the debugging tools come for free in my browser. If you happen to be more familiar with a different set of debugging tools then it's possible client side code takes more time for you to debug, but that's hardly a universal statement.

> They often duplicate logic between the client and the server.

Not true for isomorphic web apps. But again, depending on skill set this may or may not be more time consuming for you personally.

I suppose this is entirely subjective, but I have to disagree that an SPA is inherently more complex and time-intensive that building equivalent functionality mostly server-side. I split my time about evenly between serverside development (Rails, then PHP before that, then Java before that) and clientside (React, then Angular before that, then Backbone before that, and jquery soup before that). I think it depends on the app, but I definitely find certain kinds of apps are a lot easier in a large clientside framework.

Now, there are cases for each. Building a simple blog, you'd be right: a server-rendered app with a sprinkling of JS for flavor would probably be a lot easier. On the other hand, a site that behaves more like an app might be quicker to build as an SPA. For example, an e-commerce site with complex filtering (you can filter by size, but it goes 0-20 for shoes, sm-xl for t-shirts, 10-70 for jeans, etc) and complex UI interactions available in-page on each item such as one-click buying, searching for similar items, setting up a price-alert, etc). You could do that mostly server-side, but I'd argue your frontend (at least on the item-browsing page) is heavier enough that it may be easier to just build a js-first site to start with.

It all depends on the use case. I'm just trying to refute the parent comment. In some situations, e.g. when you are starting with server side logic and rendering, progressive enhancement is actually less effort. You get it for free since all user agents support html. Some applications might justifiably start out as single page applications. Other make more sense using the metaphor of hyperlinked resources.

Here is my own personal experience: You're fighting user expectations by doing things this way. Your users almost unanimously don't care how you architect your application, but they are used to using Facebook, Gmail, Dropbox, AirBnB, etc. etc. and they will eventually expect and ask you for the same sort of experience, at which point you will put more time into tacking on dynamic features to a static application than you would have spent designing a dynamic application to begin with. Then you'll probably end up re-writing the complex portions (and eventually all portions, because hybrids suck to maintain) in a front-end framework and pulling out the back-end logic into a convenient API, and coming to the conclusion that you would have started that way if you knew you were going to end that way. Then you'll start looking at new applications through that lens of whether your users will ever want that sort of dynamism, and you'll start concluding pretty much every time (because nobody ever asks you to build a blog or publication site) that your users will want that sort of thing, so you're better off going dynamic up front. Now you just have the (smaller, IMO) problem of what to do about the users who don't want the dynamic stuff, and if you're successful enough that you can afford to invest in it, you can put the time into progressive enhancement, which (in my opinion!) is easier than retro-fitting rich front-ends onto static apps.

This may all be wrong at each step, but hopefully it illuminates a bit how a lot of us (otherwise sensible developers) ended up thinking it makes more sense to start most things as rich-front-end+API apps.

Have you built anything with a modern single page application framework? It's really no harder to get started with than e.g. rails - you run a command that sets up a project skeleton, run another command to run the app, and then work on it.

I developed a hybrid mobile app using webpack/react/rxjs/cordova, so I have some experience with the ecosystem.

Unless you are entirely using third party services, your single page application is probably contacting at least one service you also have to write. Now you have 2 applications to worry about, not just one. It adds complexity to your development, build, and release process. That complexity might be worth it.

Hmm. I found it was always worth having a clean separation between frontend and business logic, so I would have built at least two modules anyway. I feel like if you want to smush together the frontend and backend pieces you can do that with node - they're both just javascript files in different folders, you only have one build process, and you just run "gulp run" or whatever during development - but I've only done that on one project so maybe I'm misremembering.