4 ms·

The high level answer is "absolutely" and the more detailed answer is "it depends how you build them". If built without server-side rendering, they're often ob

The high level answer is "absolutely" and the more detailed answer is "it depends how you build them". If built without server-side rendering, they're often obscenely slow. Browse the Modern Web™ on 2G and it's rage-inducing. A comment I made when this same question came up recently: https://news.ycombinator.com/item?id=13212789 https://news.ycombinator.com/item?id=13212789 If built poorly, all of the browser features you've come to rely on break. Like the back button. And links. And scrolling. Does your website need to be accessible? Better remember to build that in too. How about SEO? AMP? Browser history? Most of this stuff works out of the box with traditional HTML and server-side rendered pages. So even though it's 2017, I think the question you should still ask yourself is, do you plan to re-implement all of this functionality? If not, 10MB of the hottest new JS framework may not be for you... (And this is coming from someone who builds SPAs for clients for a living.)

sbuttgereit 10y ago
I would add to your detailed answer... for what reason you're building a browser based app. There are use cases where a browser delivered application is desirable, but you really aren't targeting "the public" meaning arbitrary consumers or business customers via a website. For example, there are good reasons to build browser based interfaces to certain enterprisy business apps for internal corporate user consumption. In these cases, you may be able to reduce the cost of maintaining full applications by relying on more simple and ubiquitous browsers while trying to keep some of the richer GUI functionality of a full fat client by building an SPA. Nonetheless, your other points do apply (except for SEO and perhaps some of the mobile concerns, context mattering here). How you build them still matters; you just typically have greater control over much of the footprint and whether or not it's the right approach still needs to considered (SPA is not a default). I appreciate that this isn't the typical area of interest for those coming to Hacker News, but it still exists and can be good to think of from time to time.
- rhizome 10y ago
  Have you ever seen an app where the user can choose whether they get server-rendered or client-side?
  - sbuttgereit 10y ago
    No. And I'm not sure I get your point. Individual users, in the context of my comment, don't get a choice... They may well have influence at some point... But it's not a technical preference at login or on ongoing debate. Now I've seen plenty of corporate tech management make those decisions on behalf of their user communities as well as vendors providing offerings to those same corporate institutions/managers which make that choice.
jotto 10y ago
The SPA frameworks and web APIs available to us now are pretty good - browserHistory as you mention, is available via `window.history.pushstate` and abstracted away for you in most SPA frameworks. > If built poorly, all of the browser features you've come to rely on break Alternatively phrased: "you may have to learn some new APIs" But the SEO can be an issue (Google is not consistently executing AJAX) and render performance is definitely an issue. I made https://www.prerender.cloud/ https://www.prerender.cloud/ to address the SEO and rendering performance but that still doesn't make SPA the obvious choice. Do you need a rich client experience? ( a UI that continuously updates to reflect the state of a data store, or more generally, a complicated UI that doesn't do a hard page refresh ) If yes, then SPA is the better solution. If you just need a non-interactive set of pages (a blog), then a SPA probably isn't the answer. > If not, 10MB of the hottest new JS framework may not be for you... What hot new JS framework is 10MB? React is ~60kb gzipped The auth frameworks (auth0.com or AWS Cognito) are large though, ~150KB gzipped. But with code splitting you can eliminate that from your main page. Or you can move the auth part of your app to a subdomain (app.example.com) and keep example.com lightweight w/out auth0/cognito)
- patmcguire 10y ago
  > you may have to learn some new APIs Yeah, but you have to then call those APIs. It's like buffer overflows, which can be prevented with trivial checking, but those checks have to be done everywhere, which is why they're still happening in 2017. It would be actively difficult to break back, links, or scrolling with server side rendering. Even on good SPA I run into bugs I have to work around on a daily basis.

sbuttgereit 10y ago

I would add to your detailed answer... for what reason you're building a browser based app. There are use cases where a browser delivered application is desirable, but you really aren't targeting "the public" meaning arbitrary consumers or business customers via a website. For example, there are good reasons to build browser based interfaces to certain enterprisy business apps for internal corporate user consumption. In these cases, you may be able to reduce the cost of maintaining full applications by relying on more simple and ubiquitous browsers while trying to keep some of the richer GUI functionality of a full fat client by building an SPA. Nonetheless, your other points do apply (except for SEO and perhaps some of the mobile concerns, context mattering here). How you build them still matters; you just typically have greater control over much of the footprint and whether or not it's the right approach still needs to considered (SPA is not a default). I appreciate that this isn't the typical area of interest for those coming to Hacker News, but it still exists and can be good to think of from time to time.

rhizome 10y ago
Have you ever seen an app where the user can choose whether they get server-rendered or client-side?
- sbuttgereit 10y ago
  No. And I'm not sure I get your point. Individual users, in the context of my comment, don't get a choice... They may well have influence at some point... But it's not a technical preference at login or on ongoing debate. Now I've seen plenty of corporate tech management make those decisions on behalf of their user communities as well as vendors providing offerings to those same corporate institutions/managers which make that choice.

jotto 10y ago

The SPA frameworks and web APIs available to us now are pretty good - browserHistory as you mention, is available via `window.history.pushstate` and abstracted away for you in most SPA frameworks. > If built poorly, all of the browser features you've come to rely on break Alternatively phrased: "you may have to learn some new APIs" But the SEO can be an issue (Google is not consistently executing AJAX) and render performance is definitely an issue. I made https://www.prerender.cloud/ https://www.prerender.cloud/ to address the SEO and rendering performance but that still doesn't make SPA the obvious choice. Do you need a rich client experience? ( a UI that continuously updates to reflect the state of a data store, or more generally, a complicated UI that doesn't do a hard page refresh ) If yes, then SPA is the better solution. If you just need a non-interactive set of pages (a blog), then a SPA probably isn't the answer. > If not, 10MB of the hottest new JS framework may not be for you... What hot new JS framework is 10MB? React is ~60kb gzipped The auth frameworks (auth0.com or AWS Cognito) are large though, ~150KB gzipped. But with code splitting you can eliminate that from your main page. Or you can move the auth part of your app to a subdomain (app.example.com) and keep example.com lightweight w/out auth0/cognito)

patmcguire 10y ago
> you may have to learn some new APIs Yeah, but you have to then call those APIs. It's like buffer overflows, which can be prevented with trivial checking, but those checks have to be done everywhere, which is why they're still happening in 2017. It would be actively difficult to break back, links, or scrolling with server side rendering. Even on good SPA I run into bugs I have to work around on a daily basis.