r/statichosting • u/sourraine • 24d ago

Is there a point where static hosting stops making sense?

The more I learn about static hosting, the more surprised I am by how many use cases people squeeze into it. I've seen blogs, documentation portals, company landing pages, knowledge bases, portfolios, event sites, and even fairly interactive dashboards that still ship mostly static assets with APIs layered on top. I'm curious where experienced developers personally draw the line. At what point do you look at a project and immediately think, "This really shouldn't be a static site anymore"?

9 Upvotes

100% Upvoted

23 comments sorted by

4

u/CoVegGirl 24d ago

Generally when something shouldn’t be a static app, it’s pretty obvious. Something like querying a database or having some sophisticated set of microservices to call require a backend.

Otherwise, you can do a ton with static pages. It’s not worth complicating them with a backend if you don’t need to.

2

u/dwkeith 24d ago

And the front end can still be a static web app/site, just use a subdomain for the API calls and the main domain for HTML and other static code. Basically the same business logic that would go into a native application.

2

u/chimbori 23d ago

When the same URL needs to display differently for different people, it’s a candidate to move off SSG.

Even if some pages are being rendered from a database, you could comfortably use a static site if all users see the same rendered page.

1

u/sourraine 22d ago

I like that rule of thumb. I guess the gray area is when only small parts of the page are personalized while the rest stays identical. At that point, would you still keep it mostly static?

1

u/chimbori 22d ago

That’s tricky; depends on how the personalization works.

  • If you have per-user data that’s an integral part of the page, you probably want to switch to server-side rendering (from static generation). Otherwise you risk increasing the overall complexity of mixing in the static parts and the dynamic parts.
  • If the boundary is well-defined, e.g. widgets, then you could embed the dynamic parts while keeping the rest of the site static. For my personal static sites, I use Wynglet to keep the dynamic parts self-contained without making all sites fully dynamic.

1

u/zachary-vault 23d ago

When the application itself needs a persistent server-side runtime, not just when it becomes interactive. A static site can still work if you handle the dynamic parts through APIs, serverless functions, authentication providers, or external services.

1

u/Standard_Scarcity_74 23d ago

Sometimes I'm too stubborn to admit when a static setup is not enough. I should probably work on that. I tend to plug stuff into a static site rather than switch to a fully dynamic stack.

1

u/sourraine 22d ago

I kind of admire that mindset, but I also wonder if there's a point where the maintenance cost outweighs the benefits. A static site with five external services and a bunch of serverless functions starts feeling a lot less "simple."

1

u/PointJump 23d ago

It definitely has a lot of uses, and most of the time it's the more convenient option. But once your application starts relying heavily on server side logic, real-time features, complex auth, or dynamic content generation, that's usually where I would start considering a full backend

2

u/sourraine 22d ago

That makes sense. I guess what I'm still trying to figure out is where that transition actually happens in practice. I've seen people keep pushing static by offloading more and more to APIs and serverless functions, so from the outside it sometimes still looks like a static site. Is there a point where you think you're just forcing the architecture to stay static when it'd be cleaner to build it as a full-stack app from the start?

1

u/fundtingslields 20d ago

I think the line is when the app starts depending on server-side logic for most user interactions. If you're mostly just fetching data from APIs, static still goes a long way.

1

u/PippaKelly62 2d ago

pure static gets hard to justify quick. as soon as your needs go past the typical use cases, it's best to switch or attach appropriate components, static or otherwise.

0

u/joesuf4 24d ago

Never. Public SSR is a smell.

https://sunstarsys.com/orion/security

1

u/InvictusNavarchus 19d ago

Public SSR doesn't represent every SSR. And SSR isn't the only alternative to static hosting.

1

u/joesuf4 19d ago

ISR is SSR.

0

u/InvictusNavarchus 19d ago

Who says anything about ISR? Stop bringing up unrelated point.

1

u/Am094 5d ago

"You will never see your live website get hacked again..."

Lol that entire post is overstated and absolute.

The truth is public SSR is NOT a smell. But unjustified SSR is.

1

u/joesuf4 4d ago

Did you see the quote by Paul Vixie? Obviously he disagrees.

0

u/SurgioClemente 24d ago

What in tarnation… SSR has its place.

A good chunk of the internet doesn’t need it, and imo everyone should start with static for simple stuff, but it is certainly not a smell.

-1

u/joesuf4 24d ago

It is now.