6 ms·

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 othe

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?

avarun 3y ago
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.
- cuu508 3y ago
  What complexity is needed or helpful? Plain HTML is simple and loads quick.
- drowsspa 3y ago
  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.
  - avarun 3y ago
    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.
    - ezst 3y ago
      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
      - avarun 3y ago
        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.
FinalBriefing 3y ago
This is nothing new. HTML has always been rendered from a sever.
- hanniabu 3y ago
  Served from a server and rendered from a server is completely different.
- smolder 3y ago
  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.
hanniabu 3y ago
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
FireInsight 3y ago
> 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/rendering/static-site-generation 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-output-modes https://docs.astro.build/en/basics/rendering-modes/#server-o...

avarun 3y ago

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.

cuu508 3y ago
What complexity is needed or helpful? Plain HTML is simple and loads quick.
drowsspa 3y ago
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.
- avarun 3y ago
  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.
  - ezst 3y ago
    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
    - avarun 3y ago
      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.

FinalBriefing 3y ago

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

hanniabu 3y ago
Served from a server and rendered from a server is completely different.
smolder 3y ago
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.

hanniabu 3y ago

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

FireInsight 3y ago

> 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/rendering/static-site-generation 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-output-modes https://docs.astro.build/en/basics/rendering-modes/#server-o...