Hacker News new | ask | show | jobs
by chiliap2 3419 days ago
> For example, the profile page could be potentially very light, and there would be no reason for that if someone is linked directly to the profile page; it should load every single piece of Javascript in our project.

There are plenty of ways to do that with single Page apps; it's not a great argument against all single page apps, just poorly designed ones.

5 comments

Yet much easier to do by avoiding a single page app all together.
Is there anything meaningfully different between a site made up of a number of discrete single page apps and one built with Vue?
Sure! Multiple discrete single page apps are simpler to develop and maintain, especially for apps that have a lot of dependence on the backend. IMO it promotes a healthy (aka obvious) separation of concerns and provides flexibility. A UI framework like Vue helps us cut a lot of corners when we need to, but no doubt, not every problem needs to be solved using the framework, the ability to retreat to vanilla when you can is hugely underrated IMO, especially given the _promising_ future of vanilla.
You would need vue-router (or equivalent) for the latter, which can be "meaningful" depending on the app.
I mean our profile page, there's hardly anything to it and it doesn't need JS. So there really isn't any reason for it to be a page of a single page application, let alone a JS app at this point. But with Turbolinks it was all part of one giant SPA.
An SPA has to be an "all in" thing though. If visiting the profile page then going back to the rest of the app is a possibility then the page load time is too high. SPA load times are only accepted because they are a one time cost.
That's not correct. A well-written SPA can lazy load components, take advantage of code splitting, load in modules asynchronously after the initial load. There are plenty of strategies to push the time-to-interactive timing right down. Webpack 2 supports multipage apps with individual dependency graphs for each page. SPAs have progressed considerably over the past few years.
Exactly.

The Polymer CLI by default builds SPAs that only loads the resources needed for each page. It doesn't require a very complex toolchain or advanced knowledge.

Open question: how well does Vue handle isomorphism? Our standard React template now for new projects is isomorphic, and we're porting old projects when/where we can.
I haven't experienced personally, but I remember seeing SSR in Vue docs (https://vuejs.org/v2/guide/ssr.html) for a start. This also looks pretty sweet https://github.com/vuejs/vue-hackernews-2.0