Hacker News Reader

Comment by andrenotgiant | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

Well he’s taking about a hybrid. Each of your pages are essentially little applications on their own.

My solution is to use an isomorphic static-site SPA hybrid, as generated by 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/

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.

> 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.

Reply on news.ycombinator.com