Hacker News Reader

Comment by mikeocool | Hacker News Reader

It’s amazing how many front end frameworks now exist that require running a backend server to even render basic HTML. This, remix, next, Astro, and so many others.

Do the features offered by these really warrant the complexity?

View on HN

> It’s amazing how many front end frameworks now exist that require running a backend server to even render basic HTML. This, remix, next, Astro, and so many others.

---

> This

Yeah, this uses Python and is not specifically an SSG, so it makes sense for a server to be needed. Making an SSG that uses this would probably be possible, though.

> Remix

Remix is a fullstack app framework with a focus on data flow, directly going against the JAMStack current. Makes sense that it needs a backend server.

> Next

NextJS offers static site generation support. https://nextjs.org/docs/pages/building-your-application/rend...

> Astro

Astro started out as an SSG, and even now that server rendering is supported first-class, static site generation is the default and on-demand rendering needs to be opted into by the developer. https://docs.astro.build/en/basics/rendering-modes/#server-o...

Making initial page loads significantly faster, especially on intermittent mobile connections (which is an extremely common situation often underestimated by web developers) is worth a little bit of complexity, yes. And the entire point of these frameworks is to abstract away most of that complexity.

What complexity is needed or helpful? Plain HTML is simple and loads quick.

That's the elevator pitch, but as someone with a middle-tier Android phone and in an area with not that stable mobile connection, those supposely "optimized" pages work much worse than plain old HTML. It's even funny how my phone struggles to even render the home pages of these projects.

Developers always find ways to down-compensate gains due to Moore's law and its infrastructure equivalents.

Of course it's slower than plain HTML being delivered from the server. That's not what we're comparing to, and frankly if that approach fits the needs of your project then go ahead and use it.

The real comparison point is client rendered SPAs, which is the status quo in web app development that SSR frameworks are competing with. If that's your starting point, SSR is a strict optimization and a significant improvement for almost all usecases besides internal admin tools that are only meant to be used on desktop.

Not OP, but I think the point might be that we get served more and more SPAs weighting millions of lines of JS for anything and everything, because it's trendy in a resumé-driven industry, while overlooking the end-users needs and constraints

That's not a relevant or useful point at all. Obviously there will always be people using the wrong solutions for their problems. Doesn't mean that other people don't have perfectly valid problems that need a solution.

Big reason why i love jekyll, it's just a shame that development is so slow it feels abandoned and the plugin ecosystem is lacking

This is nothing new. HTML has always been rendered from a sever.

Served from a server and rendered from a server is completely different.

There's a big difference between serving up static documents (I wouldn't call this "rendering") and dynamic documents. Then there's also a difference between using a templating system for dynamism or a more programmatic and less portable page generation system that's anchored in a specific language like this.

Reply on news.ycombinator.com