4 ms·

I always thought the decision was: - Content site = NOT single-page-app - Application = single-page-app Maybe there's more of a gray area between content sit

I always thought the decision was: - Content site = NOT single-page-app - Application = single-page-app Maybe there's more of a gray area between content sites and applications these days, but I think it's still pretty obvious: If most of the user's time is spent reading content, it's a content site.

thehardsphere 9y ago
That's a good starting point. I'd drill down even further and ask "what does the user do with the application?" If the user needs to look at multiple screens at a time (e.g. like a mail client or something of similar complexity), then they're a candidate for an SPA. If the user does not need to do that, the app is probably simple enough to not be an SPA.
motoprog 9y ago
I work in ecommerce and I feel it’s somewhere in between. We need to build for seo optimizations for the category/product experiences yet there is a lot of application like intersections, especially on the category filtering and the product sku selections. Quickshops, In store pickup modals, user specific recommendations trays, add and edit reviews et all. Different caching for server render at the edge vs personalized components adds another layer. Being able to serve with a shared routing scheme both client side (for improved performance) and server side for faster initial page load and seo on non-Google crawlers is a tough problem. Especially when you add in client hydration of the redux store. That parse time is a real killer on mobile. You add in service workers and prefetching and the complexity ratchets up further. The other issue we deal with is marketing pixels and trackers. But that’s another story. There is a ton of complexity in building a highly functioning ecommerce site.
- ccachor 9y ago
  Is it really worth the trade-off? I remember eCommerce sites trying to do similar levels of interactivity with Flash too. I just think, for a catalog site, it seems like you're trying to swim upstream. Especially on mobile.
thinkloop 9y ago
The problem is even content is becoming functional with interactive charts, infographics and figures, videos, media, filtering, sorting - then the site will eventually need comments, ads, subscribing, favoriting, upvoting, login, lazy load next article, infinite scroll, etc. Yes, a pure content site shouldn't be an spa, but how long can you survive running a pure content site? Information is complex and the web allows us to communicate it more richly than the static 2d representations of old.
- debaserab2 9y ago
  What are static 2d representations? You can do everything you mentioned without an spa just fine. Plenty of content sites (the majority, actually) survive just fine.
  - nojvek 9y ago
    Well he’s taking about a hybrid. Each of your pages are essentially little applications on their own.
- fiatjaf 9y ago
  My solution is to use an isomorphic static-site SPA hybrid, as generated by https://github.com/fiatjaf/sitio https://github.com/fiatjaf/sitio, for example. The idea is to load only the React components and the data needed for each route at load time. An example of a page generated with this technique: http://inflacao.org/series/ http://inflacao.org/series/
- same_shit 9y ago
  The problem is, this can all be solved with just a little bit of javascript to make interactive charts, infographics and figures, videos, media, filtering, sorting - then you can still serve static comments, ads, subscribing, favoriting, upvoting, login.
azr79 9y ago
> I always thought and you were right, although, with things like Angular Universal and initial server side rendering of SPAs in general, are changing this.

thehardsphere 9y ago

That's a good starting point. I'd drill down even further and ask "what does the user do with the application?" If the user needs to look at multiple screens at a time (e.g. like a mail client or something of similar complexity), then they're a candidate for an SPA. If the user does not need to do that, the app is probably simple enough to not be an SPA.

motoprog 9y ago

I work in ecommerce and I feel it’s somewhere in between. We need to build for seo optimizations for the category/product experiences yet there is a lot of application like intersections, especially on the category filtering and the product sku selections. Quickshops, In store pickup modals, user specific recommendations trays, add and edit reviews et all. Different caching for server render at the edge vs personalized components adds another layer. Being able to serve with a shared routing scheme both client side (for improved performance) and server side for faster initial page load and seo on non-Google crawlers is a tough problem. Especially when you add in client hydration of the redux store. That parse time is a real killer on mobile. You add in service workers and prefetching and the complexity ratchets up further. The other issue we deal with is marketing pixels and trackers. But that’s another story. There is a ton of complexity in building a highly functioning ecommerce site.

ccachor 9y ago
Is it really worth the trade-off? I remember eCommerce sites trying to do similar levels of interactivity with Flash too. I just think, for a catalog site, it seems like you're trying to swim upstream. Especially on mobile.

thinkloop 9y ago

The problem is even content is becoming functional with interactive charts, infographics and figures, videos, media, filtering, sorting - then the site will eventually need comments, ads, subscribing, favoriting, upvoting, login, lazy load next article, infinite scroll, etc. Yes, a pure content site shouldn't be an spa, but how long can you survive running a pure content site? Information is complex and the web allows us to communicate it more richly than the static 2d representations of old.

debaserab2 9y ago
What are static 2d representations? You can do everything you mentioned without an spa just fine. Plenty of content sites (the majority, actually) survive just fine.
- nojvek 9y ago
  Well he’s taking about a hybrid. Each of your pages are essentially little applications on their own.
fiatjaf 9y ago
My solution is to use an isomorphic static-site SPA hybrid, as generated by https://github.com/fiatjaf/sitio https://github.com/fiatjaf/sitio, for example. The idea is to load only the React components and the data needed for each route at load time. An example of a page generated with this technique: http://inflacao.org/series/ http://inflacao.org/series/
same_shit 9y ago
The problem is, this can all be solved with just a little bit of javascript to make interactive charts, infographics and figures, videos, media, filtering, sorting - then you can still serve static comments, ads, subscribing, favoriting, upvoting, login.

azr79 9y ago

> I always thought and you were right, although, with things like Angular Universal and initial server side rendering of SPAs in general, are changing this.