Astro 3.0 | Hacker News Reader

Astro 3.0

astro.build

102 pointsadrian_mrd32 comments

The marketing seems better than the product. With the tutorial it's a lot of setup and you eventually get to the component page where it doesn't really say how it works. https://docs.astro.build/en/tutorial/3-components/2/

I feel like it's more clear what's going on under the hood with SvelteKit, Nuxt, Next.js, Remix, Solid Start, and other ones I've looked at. However I was starting to get a little familiar with Astro, and already a new major version. It feels rushed.

I'll see what happens with Astro 3, I'm not saying I don't like it, just that the marketing is more impressive to me than what I've seen in the tutorials I've tried following thus far.

Also I think it might be time to make it so repos can link to syntax highlighting and be highlighted with them using tools such as GitHub and vscode until you specify one manually. That way new syntaxes can be supported more rapidly. They could be run with WebAssembly to sandbox them.

https://htmx.org/docs/#view-transitions

First time I'm hearing about the View Transitions API

https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...

I don't know exactly who is the "first" but Svelte just announced this a few days ago:

https://svelte.dev/blog/view-transitions

View transition is not such an impressive thing for a front-end framework to have, most do.

Idk why magic move isn't built-in every front-end framework these days.

Huh? View Transitions are an entirely new API supported only by Chrome currently. (And Edge, which is a flavor of Chrome.)

you're being too hung up on native APIs, view transition as a concept is nothing new and has existed in front-end frameworks for ages

I'm not aware of a framework that has first-class support for animating between application states, and I've used all the most prominent ones. But regardless, the fact that it's leveraging a native API is significant; it means (a) the browser engine can optimize for it, (b) less code needs to ship to the browser to use it, and (c) native behavior means a standardized API for a complex task.

In which way does svelte(kit) not have first class support for animating between states?

You can animate items being added to page, removed from page or reordered in a keyed each. This also includes pages themselves in layout files. And you can also animate an item being moved from one place to another by being removed in one place and added in another place.

Do you have an example? My understanding is that without browsers doing the tweening between visible states, it would require complex DOM manipulation and animation to make it look good. The native API is an essential part of making this happen for the web.

I think you need to read the API docs again. View transitions as a concept are not new but the View Transitions API offers functionality not previously available in browsers.

> View Transitions are an entirely new API supported only by Chrome currently. (And Edge, which is a flavor of Chrome.)

https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...

I would prefer if browsers offered more powerful API like this so you don't have to rely on a bloated framework to build modern web applications.

Browsers offering a powerful "std library" for building web application would be great. Similar how Go offers a powerful std library for building server application where most of the time you dont need a framework.

There's no "first". View transitions are an HTML/CSS standard.

https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...

I know, that was from the article.

> Astro 3.0 is the first major web framework to support the View Transitions API.

Sorry to nitpick, but the View Transitions specification is in Candidate Recommendation Snapshot status [1], meaning that [2]:

> These documents MUST NOT be cited as W3C standards and may or may not become W3C standards.

[1] https://drafts.csswg.org/css-view-transitions-1/

[2] https://www.w3.org/standards/types/#CR

Major discussion 23 days ago:

https://news.ycombinator.com/item?id=37108111

(167 points/129 comments)

They have a "showcase" page and I looked at some of the linked sites and could not see where the view transitions were used.

View Transitions are only supported by Chrome amongst the major browsers as of now. Maybe that's why?

Is what?

> Unlike many frameworks, Astro uses standard HTML <a> elements to navigate between pages (also called routes), with traditional page refreshes.

I love it. Truly amazing that this is the exception these days.

Is it possible that that’s the joke? Unless this is unique to Vue, I’d expect that you can use an <a> tag in any framework if you want to trigger a “traditional page refresh” instead of leveraging the router to do it efficiently.

Yes but you still use <a> tag for view transitions native to the browser. That’s the beauty.

That’s great, but I’ve been able to do that with CSS for years.

That’s amazing, but others haven’t so it’s nice when a framework makes things more accessible for the rest of us!

What’s not accessible about CSS? This is already a low bar to pass. I remember adding CSS3 transitions a decade ago at my first internship.

It feels like there is a lot of brigading and shilling of Astro throughout this thread, as typical with web frontend frameworks.

It’s just the time savings, any competent engineer can implement better transitions, it’s just not very high priority these days. A simple one liner built-in is very convenient.

> A simple one liner built-in is very convenient.

Then why do you need bloated web UI that's not performant as React, Vue, Angular, Svelte? You can also just add 1 line of css classes to HTML elements to have transitions if you use a library like Animate.css.

Isn't that just how the view transitions API works?

Yes but this in contrast specifically to <Link to=

There seems to be parity with SvelteKit (nee Sapper), Remix, Next.js, and Solid Start in this. The <Link> is only in the source code, and as the Astro post said, only for some such as SvelteKit and not for others such as Next.js. The generated code still has <a> links that work without the client-side router. Next.js was a bit overly SPA up until recently, but now it has progressive enhancement with forms. https://nextjs.org/docs/app/building-your-application/data-f...

The blink tag is laughing at us from it's grave.

Reply on news.ycombinator.com