Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Astro is a return to the fundamentals of the web

websmith.studio

Post reply on HN
Print view View original

151–160 of 268 posts

Re: Astro is a return to the fundamentals of the web

#151

Post by nchmy »

nchmy wrote: post #106
teekoiv wrote: post #20

It's baffling to me why more SSR frameworks, Astro and NextJS namely, can't adopt static pages with dynamic paths like SvelteKit. So for example, if you have a page /todos/[todoId] you can't serve those in your static bundle and NextJS straight-out refuse building your app statically. Whereas with SvelteKit, it builds happily and does this beautiful catch-all mechanism where a default response page, say 404.html in C…

I might not be understanding you (or the various frameworks) completely, but are Astro's server Islands what you're looking for? https://docs.astro.build/en/guides/server-islands/

Or, actually, https://docs.astro.build/en/guides/on-demand-rendering/

Re: Astro is a return to the fundamentals of the web

#153

Post by esseph »

aaronbaugher wrote: post #138
SideburnsOfDoom wrote: post #51

Earlier quoted context omitted.

> Some of us actually write like that The fact that LLMs write like that is proof of that people write like this too, as LLMS produce statistical averages of the input writings.

It kind of surprises me that they never confuse "it's" and "its" and common mistakes like that, when it seems like most human writers today swap them randomly. I suppose that's thanks to a lot of the text in the training data predating the collapse of English education. I'm not sure why em dashes are so popular, though. I don't think I've ever seen human writing that had as many em dashes as LLMs use.

I add them where it makes sense, in more of a way to mimic natural conversations.

Re: Astro is a return to the fundamentals of the web

#154

Post by nchmy »

wackget wrote: post #146

"The fundamentals of the web" does not include a build step or the use of a package manager.

Backend stuff is orthogonal to web fundamentals. What matters is ssr html.

Still, yes, I prefer other tooling in the backend. But astro is a good thing for JS devs

Re: Astro is a return to the fundamentals of the web

#155

Post by esseph »

owebmaster wrote: post #83
esseph wrote: post #39

Earlier quoted context omitted.

Maybe you've never been told you sound like a robot, then. Feeling less-than-human isn't great.

Are you the post author?

No, just a human getting tired of things I type online being thought of as LLM spam.

Re: Astro is a return to the fundamentals of the web

#156

Post by nchmy »

aembleton wrote: post #143
user____name wrote: post #87

How is this different from something like PHP? I don't get it.

PHP needs to be hosted on a server that can parse PHP. Astro generates HTML so can be hosted anywhere that can serve HTML.

What?

Astro needs to run on a server that can run node etc

And php can equally have its html cached.

Re: Astro is a return to the fundamentals of the web

#157

Post by esseph »

ansc wrote: post #61
esseph wrote: post #26

Earlier quoted context omitted.

Some of us actually write like that... :/ Sucks when everything you write sounds like a bot because you're autistic.

I doubt it to be honest. It's so distinct and non-existing. >With Astro you're not locked into a single way of doing things. Need React for a complex form? Chuck it in. Prefer Vue for data visualisation? Go for it. Want to keep most things as simple Astro components? Perfect. >What struck me most after migrating several projects is how Astro makes the right thing the easy thing. Want a fast site? That's the default.…

Damn, first it sounds like a robot, then it's bland.

Speak your truth, poster!

Re: Astro is a return to the fundamentals of the web

#158

Post by blackhaj7 »

hombre_fatal wrote: post #125
diggan wrote: post #10

> Traditional frameworks hydrate entire pages with JavaScript. Even if you've got a simple blog post with one interactive widget, the whole page gets the JavaScript treatment. Astro flips this on its head. Your pages are static HTML by default, and only the bits that need interactivity become JavaScript "islands." Back in my days we called this "progressive enhancements" (or even just "web pages"), and was basically…

You're making the opposite mistake: you're seeing someone's description of a tool's feature and confusing it with the way we've already done things without even checking if the tool is transformative just because it kinda sounds similar. Astro's main value prop is that it integrates with JS frameworks, let's them handle subtrees of the HTML, renders their initial state as a string, and then hydrates them on the clien…

> you're chomping at the bit to be cynical instead of curious.

Nicely sums up a lot of interactions these days

Re: Astro is a return to the fundamentals of the web

#159

Post by littlecranky67 »

teekoiv wrote: post #147
littlecranky67 wrote: post #121

Earlier quoted context omitted.

I partly agree with you, but it is a design decision that comes with a drawback. A URL /todos/123 cannot be resolved in a SPA in a hard-reload. I.e. if a user were to bookmark /todos/123 or press reload in the browser, the browser would ultimately ask the underlying HTTP server for that file. As you mentioned, you would need a 404 page configured to fetch that - but that requires a configuration in the HTTP server (n…

Interesting. You can set up the server to respond with 200.html as the catch-all so the requests would return 200. There was some issue with it—can't remember what—which is why I switched to 404.html. After the initial load though the subsequent navigations would go through pushState so I think they'd be cached. But I don't see this is as big of a problem. With this I can switch and choose—SSR dynamic pages or use ha…

I tend to agree that you could come up with a solution using server-side catch-all and custom 200/404 routes - and actually I do, as I use nginx with a single line of try_files customization. But this is optional. It shouldn't be required to mess with the server config, if you want a static deployment.

Besides, if you catch-all to a 200.html page, how would you serve 404s? Yes, you can integrate a piece of JS in the 200.html file and have it "display" 404, but the original HTTP response would have been 200 (not 404). A lot of bending web standards and technology, and I can see how framework authors probably decide against that. Especially given how much shit JS frameworks get for "reinventing the wheel" :)

Post reply on HN