4 ms·
Some of the arguments the author mentions are not really good arguments. Basically it boils down to how much you care about the user experience. I designed and
by photonios 9y ago
Some of the arguments the author mentions are not really good arguments. Basically it boils down to how much you care about the user experience. I designed and developed a SPA for a large real-estate portal in <6 months. I think we've nailed all of the points the author mentioned:
- Initial request is rendered server-side, so TTI is extremely low. Even if the JS hasn't kicked in, the website is already usable.
- Back button works perfectly fine. We use the HTML5 `history.pushState` method to add new entries to the history stack.
- Links are always rendered as anchor tags. So even if the onClick handler fails or the JS crashed, the link will still work.
- Compress the hell out of the bundle. Clocking in at 190KB compressed. (Edit: should do something about this, should be <100KB)
Basically, we have most of the advantages of rendering "static" pages, yet also get all of the advantages of an SPA. We can do pre-loading in search results for example. If you click a link in search results, we immediately render the page and use the data from the search result to show a basic page and then slowly enhance it.
This powers a large real-estate website that receives hundreds of thousands of visits a week. For this kind of business, a lot of stuff is important to get right. SEO related optimisations are extremely important. Hence, we server-side render everything to make sure the GoogleBot can read it all. The same applies to links. We keep our bundle size as small as possible to keep things speedy.
Oh, and I personally got a kick out of spending a weekend to make the website function perfectly well without JS.
- JohnnyCrazy 9y agoDo you mind telling which stack you're using?
- photonios 9y agoReact 16, Redux, Webpack, a custom router. All transpiled using Babel. On the back-end we also use Python/Django. Nothing out of the ordinary :)
- OffTheRails 9y agoThis is great to see. I've been developing in Rails for the last 5 years, and am about to build my own products, and am opting for this kind of setup.. though have decided to hop over to Elixir on Phoenix, and will swap out Redux for Mobx. The application is mostly a dashboard (SaaS). Could easily be an MPA, but I want to move into more responsive UX, and wouldn't mind leveraging the portability for when I develop mobile or desktop apps. It seems majority of these responses against SPAs are, as you said, all based on bad design, not because the architecture itself is fundamentally flawed -- though it is obviously going against the grain by breaking a lot of this functionality in the first place. Having said that, the fact that browsers are providing native features to support SPAs, while bridging mobile-native features, is a massive sign of things to come. They're not going away, and support will only get better, and they will only become easier to develop. Anyway, I'd be interested to hear about your custom router! Any particular reason you rolled your own? I was planning to just use react-router, but if there are headaches down the road in terms of managing a hybrid SPA with SSR, I'd appreciate the heads-up.