3 ms·

I think it's an interesting question. One use case example: if I'm looking up resources to learn about cryptocurrencies, I want a web 2.0 style experience. If

I think it's an interesting question. One use case example: if I'm looking up resources to learn about cryptocurrencies, I want a web 2.0 style experience. If I'm on an exchange and trading those cryptos, I'd rather have a real-time single-page experience (I think poloniex does a decent job as an example). Even single page apps seem to have a lot of additional 'web 2.0 style' pages supporting them, so the entire thing can become blurred. Even with 'single page apps' you'll often have separate interfaces for user admin, splash pages, etc. multi-page sites seem superior if you're more concerned with things like search engine traffic, maximum compatibility, smallest size, lowest maintenance, interacting with standard browser functionality (i.e. letting users bookmark pages in your app, browser extensions, etc). Single page seems better if you're more interested in feeling like a desktop app, more interested in UI/UX, serving notifications, showing live feeds, letting the user 'sit back' while you deliver content.

GeneralMaximus 9y ago
> multi-page sites seem superior if you're more concerned with things like search engine traffic, maximum compatibility, smallest size, lowest maintenance, interacting with standard browser functionality (i.e. letting users bookmark pages in your app, browser extensions, etc). Building single-page applications is my bread and butter, and I totally agree with this sentiment. If you're building something that's purely content and doesn't require too much interactivity (which is true for most websites on the web today), SPAs are not worth the hassle. However, it's worth noting that most SPA frameworks support server-side rendering. For one of my clients, I built a server rendered React website that behaved less like a SPA and more like a regular server rendered website, i.e, navigating to a link within the website caused a full page reload. The performance numbers weren't too different from your average Django/Rails/PHP website, and making sure everything worked on Node as well as the browser wasn't as hard as we imagined. The advantage was that we could write the whole thing with React, as opposed to using some kind of templating language to generate HTML and then using JS to inject the interactive bits. It's an interesting strategy that I wouldn't mind exploring again. Why did we do it? Because we had to integrate with a bunch of legacy code and this was the only way we could do it sanely.

GeneralMaximus 9y ago

> multi-page sites seem superior if you're more concerned with things like search engine traffic, maximum compatibility, smallest size, lowest maintenance, interacting with standard browser functionality (i.e. letting users bookmark pages in your app, browser extensions, etc). Building single-page applications is my bread and butter, and I totally agree with this sentiment. If you're building something that's purely content and doesn't require too much interactivity (which is true for most websites on the web today), SPAs are not worth the hassle. However, it's worth noting that most SPA frameworks support server-side rendering. For one of my clients, I built a server rendered React website that behaved less like a SPA and more like a regular server rendered website, i.e, navigating to a link within the website caused a full page reload. The performance numbers weren't too different from your average Django/Rails/PHP website, and making sure everything worked on Node as well as the browser wasn't as hard as we imagined. The advantage was that we could write the whole thing with React, as opposed to using some kind of templating language to generate HTML and then using JS to inject the interactive bits. It's an interesting strategy that I wouldn't mind exploring again. Why did we do it? Because we had to integrate with a bunch of legacy code and this was the only way we could do it sanely.