3 ms·

If you need SEO and (to a lesser degree) performance, you're likely serving content rather than an application and likely could've done with SOR (a new moniker

by hnov 5y ago

If you need SEO and (to a lesser degree) performance, you're likely serving content rather than an application and likely could've done with SOR (a new moniker I've come up with, Server Only Rendering).

trinovantes 5y ago
Except that many applications have public content that you want to be indexed and interactive for the user e.g. forums and ecommerce
- tored 5y ago
  For e-commerce probably checkout and perhaps the buy button needs to be interactive. Rest of it can be normal pages. You can use different approaches depending on what you serve.
- ryanbrunner 5y ago
  I've never seen an ecommerce or forums app that wouldn't be done better by more traditional techniques vs. an SPA. Interactive doesn't need to mean "driven entirely by Javascript", and also sites that use entirely HTML generated by a server can still use Javascript (there's even frameworks for this!)
- hnov 4y ago
  I'd say if it's timely content, e.g. you have a stream of comments flowing from the server to the client on a livestream then doing it all in JS is warranted, but the content has poor long-term value and indexing is pointless. Conversely if it's comments on Reddit, you can do any number of things that stop short of rendering everything in JS and I don't think your users will even notice. I think the overarching theme is that you end up having to think about these things: if it was clear-cut we wouldn't even be having these discussions. Do you want to think about wiring event handlers to DOM elements rendered on the server or about how your JSX renders on the server vs browser? A similar conundrum exists in mobile development, do you want to be thinking about implementing everything twice in standalone iOS and Android apps or do you want to think about how to get Xamarin/ReactNative/Flutter to do the thing you want.

3 ms·

If you need SEO and (to a lesser degree) performance, you're likely serving content rather than an application and likely could've done with SOR (a new moniker

by hnov 5y ago

trinovantes 5y ago
Except that many applications have public content that you want to be indexed and interactive for the user e.g. forums and ecommerce
- tored 5y ago
  For e-commerce probably checkout and perhaps the buy button needs to be interactive. Rest of it can be normal pages. You can use different approaches depending on what you serve.
- ryanbrunner 5y ago
  I've never seen an ecommerce or forums app that wouldn't be done better by more traditional techniques vs. an SPA. Interactive doesn't need to mean "driven entirely by Javascript", and also sites that use entirely HTML generated by a server can still use Javascript (there's even frameworks for this!)
- hnov 4y ago
  I'd say if it's timely content, e.g. you have a stream of comments flowing from the server to the client on a livestream then doing it all in JS is warranted, but the content has poor long-term value and indexing is pointless. Conversely if it's comments on Reddit, you can do any number of things that stop short of rendering everything in JS and I don't think your users will even notice. I think the overarching theme is that you end up having to think about these things: if it was clear-cut we wouldn't even be having these discussions. Do you want to think about wiring event handlers to DOM elements rendered on the server or about how your JSX renders on the server vs browser? A similar conundrum exists in mobile development, do you want to be thinking about implementing everything twice in standalone iOS and Android apps or do you want to think about how to get Xamarin/ReactNative/Flutter to do the thing you want.