Perhaps useful to some sites. Assuming Google has issues with Vue. Not useful for someone doing content behind a sign-in that isn’t going to ever be SEOed anyway?
Perhaps useful to some sites. Assuming Google has issues with Vue. Not useful for someone doing content behind a sign-in that isn’t going to ever be SEOed anyway?
There are other points in favor of doing SSR + hydration besides SEO:
1) Reducing the amount of JS you are sending to the client.
2) Not making a SPA and keep the native functionality of back/forward behavior (scroll behavior, cached pages, forms are filled when going back).
3) Simplifying development. You don't need to manage central state anymore as you're dealing with one page at a time. You might not need an API as you're rendering the page from the server. Etc.
I've been making SPAs for years and for my current project I'm doing SSR + hydration (not using Vue) and loving it.
It reduces the JavaScript sent to each page even further because it doesn't have a runtime per se. Basically each component is "compiled" to a set of imperative DOM instructions with some helper functions.
Hopefully they will get there one day but so far it gives me the feeling that I could hit a dead-end with it at any time.
Sometimes I hit a little bump on the road which would be faster/easier to solve in React/Vue/etc but even including those slowdowns I save so much net dev time it's crazy.
Generally, it feels like it strikes a good balance between being fully configurable boilerplate and opinionated framework.
I don’t send JS, my CDN does, so not a big win there.