6 comments

[ 3.1 ms ] story [ 29.4 ms ] thread
Great post. almost a year old but still relevant. most SPA's are poorly implemented. thanks for sharing.
I don't know why SPA's took off like they did. I'd much rather have a site with tons of pages and super-fast page loads between them than a site that loads EVERYTHING all at once for the sake of making the experience more "app-like" or whatever. Hell, even Facebook, the king of user engagement, isn't a single page app.
The major argument is that if you build an SPA, you'll do a bad job. So... don't do a bad job?

This completely misses the major benefit of SPA: reusable web components made with the latest version of JS with a framework that updates the DOM from a view model. I guess you could accomplish that without SPA, but I'm pretty sure we're all here for the frameworks/es6/typescript/compnents, and SPA is just the deployment model. A deployment model which allows all that to happen with a fairly short initial load if you're doing things right.

If you're loading multiple megabytes in your first chunk in 2018, then you're doing it wrong.

All that said, are you making an 'application', or are you making an informational website?

If you're making a simple website, SPA is just silly. If you're making an application, and it just happens to be deployed via a browser, SPA, and more importantly, the things I mentioned going with it, are a huge productivity and organizational boost.

> You can serve the page-specific JavaScript without much extra effort. You can replace the whole components on individual pages without affecting other components - on other pages.

This could also be easily done with an Spa, I've done it on numerous occasions. What enables it is loose coupling between components. Make them only depend on the minimal context and not a central application state.