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

141–150 of 268 posts

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

#141

Post by nchmy »

deltarholamda wrote: post #132
nchmy wrote: post #105

Earlier quoted context omitted.

"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 lan…

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.

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

#142

Post by aembleton »

deltarholamda wrote: post #132
nchmy wrote: post #105

Earlier quoted context omitted.

"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 lan…

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.

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

#144

Post by kh_hk »

rustc wrote: post #137
kh_hk wrote: post #104

Earlier quoted context omitted.

Setting `client:load` and `client:visible` for (svelte) islands you want to run on the client ends up inlining script type modules all around the html. It looked like a big hack to me. On the positive side their use of web components is a nice bet.

And does it break something? I was replying to "islands work until they don't".

It breaks the third wall.

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

#147

Post by teekoiv »

littlecranky67 wrote: post #121
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 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 hacky catch-all mechanism. For any reasonably large site you probably would SSR for SEO and other purposes. But for completely offline apps I have to do zero extra work to render them as is.

Personally, I much prefer route paths vs query parameters not just because they look ugly but because they lose hierarchy. Also, you can't then just decide to SSR the pages individually as they're now permanently fixed to same path.

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

#148

Post by teekoiv »

littlecranky67 wrote: post #127
teekoiv wrote: post #97

Earlier quoted context omitted.

It doesn't. Those are executed build-time and you can't just set a wildcard so anything outside the given set results in 404. As background, I wanted to make a PoC with NextJS bundled into a static CapacitorJS app somewhat recently and had to give up because of this. You can try tricking NextJS by transforming the pages into "normal" ones with eg query parameters instead of path, but then you need complicated logic c…

Not sure why you gave up. All you need to do, is use query params: /todo?id=123 and use `const { id } = useSearchParams()` in your code. Yes, the urls won't be that pretty, but I don't know if this is a road block. I have a NextJS webapp up and running that is 100% SPA (no SSR, full static export) and uses a C#/.NET REST Backend for data [0]. Works (almost) flawlessly. [0]: lockmeout.online

No. I disagree, you have to refactor all the pages from using [pathId] folder pattern and change all the links including switching to useSearchParams. It's just a huge change, especially if I want to keep the old routes in my web app.

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

#149

Post by voat »

bob1029 wrote: post #122
aswerty wrote: post #99

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 f…

> 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?

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

#150

Post by voat »

sktrdie wrote: post #140

Next.js hydrates only client components - so effectively it's doing island architecture. And it's react end to end. How's that different from Astro? Stating things like "Components without the complexity" doesn't really mean anything unless you do some comparisons?

Client vs server routing
Post reply on HN