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

171–180 of 268 posts

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

#171

Post by gbalduzzi »

zelphirkalt wrote: post #161
hombre_fatal wrote: post #125

Earlier quoted context omitted.

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…

What is the value in first sending dysfunctional HTML and then fixing it with later executed JS? If you do that, you might as well do 100% JS. Probably would simplify things in the framework. Sending functional HTML, and then only doing dynamic things dynamically, that's where the value is for web _apps_. So if what you point out is the value proposition for Astro, then I am not getting it, and don't see its value.

Dysfunctional HTML in the sense that interactivity is disabled, but visually it is rendered and therefore you can see the proper webpage immediately.

Just compare the two cases, assuming 100ms for the initial HTML loading and 200ms for JS loading and processing.

With full JS, you don't see anything for 300ms, the form does not exists (300ms is a noticeable delay for the human eye).

With frameworks such as Astro, after 100ms you already see the form. By the time you move the mouse and/or start interacting with it, the JS will probably be ready (because 200ms is almost instant in the context of starting an interaction).

This is not new at all, old school server side processing always did this. The advantage is writing the component only once, in one framework (React/vue/whatev). The server-client passage is transparent for the developer, and that wasn't the case at all in old school frameworks.

Note that I'm not seeing this is good! but this is the value proposition of Astro and similar frameworks: transparent server-client context switching, with better performance perceived by the user.

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

#172

Post by throwaway77385 »

rasmus1610 wrote: post #80
steve_taylor wrote: post #40

Earlier quoted context omitted.

Be careful with Netlify. Their bandwidth charges are even more egregious than Vercel’s.

Yes, good point. Although the traffic for these websites is so small, that I think I‘m good there for a long time.

Until you get DDoS'ed and they won't let you set a billing cut-off -.-

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

#173

Post by throwaway77385 »

Zealotux wrote: post #55

Please stop recommending Next.js as the de facto React framework, we need some critical thinking back into front-end. Remix (React Router v7) or TanStack are much better alternatives.

Second this. Next.js had potential, but it feels like it's gone downhill majorly since Vercel got involved.

Been on the Next.js journey since v10, lived through the v13 debacle and even now on v15, I've very much cooled on it.

I find both React and Next.js move way too fast and make incredibly radical changes sub-annually. It's impossible to keep up with. Maybe it could be justified if things improved from time to time, but often it just feels like changes for changes' sake.

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

#174

Post by gbalduzzi »

diggan wrote: post #21
chrisldgk wrote: post #18

Earlier quoted context omitted.

I agree with that it’s not a new concept by itself, but the way it’s being done is much more elegant in my opinion. I originally started as a web developer during the time where PHP+jQuery was the state of the art for interactive webpages, shortly before React with SPAs became a thing. Looking back at it now, architecturally, the original approach was nicer, however DX used to be horrible at the time. Remember trying…

> Remember trying to debug with PHP on the frontend? I wouldn’t want to go back to that. I do remember that, all too well. Countless hours spent with templates in Symfony, or dealing with Zend Framework and all that jazz... But as far as I remember, the issue was debuggability and testing of the templates themselves, which was easily managed by moving functionality out of the templates (lots of people put lots of log…

The main difference is as simple as modern web pages having on average far more interactivity.

More and more logic moved to the client (and JS) to handle the additional interactivity, creating new frameworks to solve the increasing problems.

At some point, the bottleneck became the context switching and data passing between the server and the client.

SPAs and tools like Astro propose themselves as a way to improve DX in this context, either by creating complete separation between the two words (SPAs) or by making it transparent (Astro)

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

#175

Post by aembleton »

nchmy wrote: post #156
aembleton wrote: post #143

Earlier quoted context omitted.

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.

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

It needs to run on your computer to generate the HTML, but you can just run npm run build then copy the contents from the dist folder to your apache server, or whether you want to host it.

At least, thats how I do it.

I haven't used PHP for about 20 years so I'm sure its changed a lot.

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

#176

Post by mceachen »

rustc wrote: post #74
kh_hk wrote: post #50

To me no, it's not. It works well for some of the use cases, but if all you needed was offline rendering of your js in a build step to generate static html then you really didn't need all that js to begin with. islands work until they don't, and a lot of stuff gets inlined too. I guess it's fine if you stop caring about the final build. I feel a lot of the hype around Astro has more to do with vite than anything else…

> islands work until they don't Like when?

Not the op, but I’d guess islands become a PITA when there is user-visible state that must be synchronized and rendered coherently across multiple islands.

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

#177

Post by owebmaster »

esseph wrote: post #155
owebmaster wrote: post #83

Earlier quoted context omitted.

Are you the post author?

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

This sounds like what a bot programmed to engage in HN would do, honestly.

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

#178

Post by c-hendricks »

Zealotux wrote: post #69
vidyesh wrote: post #59

Earlier quoted context omitted.

Remix/React Router v7 was/is on a right path. I hope whatever they are planning with Remix with preact and using web standards will bring back the robust way of building websites. I did not like how Remix to RR7 transition was made though, my project built using Remix was not an easy upgrade and I am rewriting a lot of it on RR7 now.

Absolutely agree, the Remix/RR7 move was awkward and they have a thing for breaking changes, TanStack seems more reasonable on that part.

We're still on RR5 since they decided to change how nested routes work, a nested router doesn't get all params from parent routes, and after advocating absolute paths they switch to advocating relative paths, which are a mess when you want to use a component in multiple places and harder to debug / verify (all our routes are fully typed safe)

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

#179

Post by exiguus »

I think the main benefit is that you are not forced to use any other library or framework like React or Vue on top of it. You can simply use HTML or Web Components. However, Astro can perform similar tasks to Next or Nuxt, such as SSR, ISR, static site generation, and middleware.

Another differences and benefit of Astro is the island architecture, compared to other frameworks. This means you can implement micro frontends. Island architecture and micro frontends are features that companies or projects may want if they have multiple teams. For example, one team could be working on the checkout process, another on the shopping basket, and another on product listings.

Now, you can use Astro to combine these components on a single route or page. And you control how this components are rendered. Astro also allows you to share global state between these islands.

This approach is beneficial because teams can develop and ship a single feature while having full responsibility for it. However, it also has downsides, and similar outcomes can be achieved with non-island architectures.

For instance, if all teams use React, it is common for each team to use a different version of React, forcing the browser to load all these versions. The same issue arises if one team uses Vue, another uses Angular, and another uses React or any other framework.

I'am not fully convinced that it will change the web. It is basically a Next or Nuxt without the library/framework login. And it overs the Island-Architecture, that is usually only beneficial for very huge projects.

But, you should try it. I work with Astro since there first release, now for several years, and I can recommend you to give it a try.

It is also a nice tool, if you want to get ride of React or Vue and move to web-components or if you want to replace Next or Nuxt. You can do this with Astro, step by step.

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

#180

Post by bob1029 »

voat wrote: post #149
bob1029 wrote: post #122

Earlier quoted context omitted.

> 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).

Post reply on HN