4 ms·

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 m

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.

smadge 11y ago
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.
- sanderjd 11y ago
  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.

smadge 11y ago

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.

sanderjd 11y ago
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.