Hacker News Reader

Comment by aswerty | Hacker News Reader

It's clear to me that the frontend conversation space is broken. Not even just the ecosystem being a mess.

Boiling down the conversation I see in the article, it just seems to be: the browser as a HMI vs the browser as a an application runtime. Depending on what you want to do one might be a better fit than the other. But the points it puts forward are fluff arguments like "it's a breadth of fresh air" or "it loads faster".

It's difficult to articulate the source of just how broken the discussion space is; nor have I made a particularly strong argument myself. But I think it's important to keep pushing back on conversations that position framework's like they are brands winning hearts and minds. Ala the fashion industry.

View on HN

> Ala the fashion industry.

The fashion industry is the best analogy I've seen so far for frontend frameworks. It's obvious that the amount of technical rigor involved with declaring something "content-driven" and "server-first" is approximately zero.

Care to explain?

Astro is trying to position itself in opposition to things like Next.js or Nuxt wich are specifically marketed as application frameworks?

And the architecture is more suited to something like a content site, because of the content collections, built-in MDX support, SSR, image handling, and server routing?

Sure, but maybe you need to go first.

What do you mean when you say "a content site"?

To me, "content" == "literally anything that resides in the DOM".

But, clearly we aren't talking about that (I hope).

They are referring to static non-interactive content (basically images and text) in sites like blogs, marketing site, docs, etc. as opposed to highly interactive, and dynamic components, think Facebook, Figma, etc.

> But the points it puts forward are fluff arguments like "it's a breadth of fresh air" or "it loads faster".

Fluff arguments do exist, but you can also measure. The site is static with minimal JS on the one page, and a bit more JS on the other page, so nothing surprising in the numbers, and nothing you can say was achieved thanks to the magic of Astro, but I wanted to shared them:

HOME PAGE

TTFB: .024s

SR: .200s

FCP: .231s

SI: .200s

LCP: .231s

CLS: 0

TBT: .000s

PW: 108KB

DEMOS PAGE

TTFB: .033s

SR: .300s

FCP: .281s

SI: .200s

LCP: .231s

CLS: 0

TBT: .000s

PW: 174KB

"Loads faster" is fluff? How so?

Write some straight HTML pages and serve it from bog standard Apache. Heck, get really fancy and do some server-side includes for your CSS or something.

It's really fast, you can edit it with Notepad, and you can probably saturate your bandwidth with a consumer level PC.

It's fluff because, well, our expectations are so unbelievably low. By the time you've bolted on every whizbang dingus leveraging four different languages (two of which are some flavor of Javascript), your twelve page site takes a couple of minutes to compile (what?), and it chokes your three load-balanced AWS compute nodes.

Web applications are hard. I get that. Web sites? They were, by design, incredibly simple. We make them complicated for often unclear reasons.

I appreciate what the Astro folks are trying to do, and it's very clever. But your basic Web site need not require freaking npm in order to "return to the fundamentals of the Web".

But astro literally generates straight html which can be cached wherever you want...

As for build time, I don't have a clue - I haven't used astro (and don't plan to. Datastar + whatever backend framework you want is better). But I'm generally in favour of the direction they're bringing JS frameworks.

Astro will generate those HTML pages you can serve 'from bog standard Apache'.

You can then use all of those npm packages to do whatever processing on your data that you want to do to generate the content and the pages and then just serve it as HTML.

I'm a backend dev, but Astro is the first time a front end framework has made sense to me for years. It fits my mental model of how the web works - serving up HTML pages with some JS just like we did 20 years ago. Its just that I can have it connect to a DB or an API to pull the data at build time so that I can have it generate all of the pages.

Reply on news.ycombinator.com