[mrath]

More and more frontend frameworks are now somewhat mandating a server part. I know pretty much all(sveltekit, nextjs) say you can do static export, but docs are more focused to use with a server. IMO it appears like this is being pushed by cloud vendors sponsoring those projects.

If you want to build a plain old SPA, the new react docs pretty much have no info. Sveltekit docs discourages it. I have not looked much into vue, but it appears like vue does better here.

Qwik while has a static export, looks like you lose all the good parts of you don’t use a server.

I can certainly see the SEO and other good thing that comes with SSR but not everyone needs it.

[vyrotek]

Yep, not a fan either. A big shift is that where "routing" happens has moved. Routing has traditionally been done within the SPA. Now it's an external concern and part of a build process.

The various hybrid/mpa/spa innovations are great but not everyone needs them. It's sad to see the traditional SPA approach be discouraged so much.

These meta-frameworks crossing into the server-side will raise a lot of architectural questions for teams. For us, we have React SPAs served by ASP.NET backends and using Vite locally. We'd rather not adopt another dependency like Next or Remix. We're definitely not going to adopt any Node on the backend.

The friction we're experiencing with these new static-exports is that we'd have to configure the backends with the front-end framework's routing system in order to serve the split out static files. e.g. ASP.NET needs to know how to serve NextJS's folder/file/path structure. As opposed to today where we just have to serve an index.html file regardless of whether it's Ang, React, Svelte, etc.

[FractalHQ]

A static build in Sveltekit is as simple as changing 1 line in your config:

`import adapter from “@sveltejs/adapter-auto”`

becomes

`import adapter from “@sveltejs/adapter-static”`

Also, Sveltekit was designed as a serverless framework optimized for the edge long before Vercel hired Rich. Doing SSR on the edge right can be a hard problem to solve, so getting it for free “automagically” in Sveltekit is a huge value-add! Static site generation, on the other hand, has long been a solved problem.

That said, I agree that a lot of sites are better off just being static. Nonetheless, being able to change one line in my Sveltekit config to deploy my static site onto Cloudflare Pages, Netlify, or my own node server thanks to Sveltekit’s adapters is pretty awesome in my experience!

[mrath]

I have not said SvelteKit can't do it. In fact having different options(and for free) is a great thing. I was raising the point that messaging [1] is that it is not recommended most of the time, and does not say when it is good to have an SPA.

Also mentions about scenario JavaScript is disabled. I am not too sure if these frameworks help there with SSR. May be it meant the user can still see a pre-rendered page but with almost no interaction possible?

Essentially I was saying there is a push towards server based frameworks.

[1] https://kit.svelte.dev/docs/single-page-apps

[pier25]

> IMO it appears like this is being pushed by cloud vendors sponsoring those projects.

Having a server component is just the natural step after a decade of bloated and unnecessary SPAs.

That said, I do think Vercel has probably influenced the design of Next and SvelteKit so that it fits better with their platform.

[mrath]

> Having a server component is just the natural step after a decade of bloated and unnecessary SPAs.

Not sure I buy that argument. While I am not totally against the idea of server based frameworks, what is disappointing is the frameworks are appearing to plant the above message.

SPAs provided us a good boundary and that is blurred by all these server based frameworks. You now have server for UI, server for BE. While I agree some SPAs are heavy, I think we have reasonable solutions for most. And these server based framework still need all the work that is done in SPA, just that routing and some aspects of bundling are taken care.

[pier25]

There's no conspiracy. SPAs should have never become the default way to make web front end.

Making a good SPA takes a lot of work and almost nobody has time to do it properly. Even Google with all its resources is incapable of making a good SPA for the Google Cloud console.

This article hits the nail in the head:

https://nolanlawson.com/2022/06/27/spas-theory-versus-practi...

"The best SPA is better than the best MPA. The average SPA is worse than the average MPA"

I'm not saying SPAs do not have their use cases. They totally do (Gmail, Twitter, Spotify, etc) and use them daily.

[atoav]

> More and more frontend frameworks are now somewhat mandating a server part. I know pretty much all(sveltekit, nextjs) say you can do static export, but docs are more focused to use with a server.

Sometimes servers just make sense from an architectural sense. You wanna get a bunch of the same stuff to many people? Servers are a good and battle tested way of doing so — with very well known trade offs and costs, minus weird gotchas that you only realize after the fact.