I misread the title and was quite confused about when the F* programming language connection will take a stage in the article. Spoiler alert: it never does, because the title doesn't make a reference to the F* programming language :D
> 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."
I guess I'd argue "Traditional Frameworks" were the ones that never stopped doing this. Laravel, Django, Rails etc. Then the SPA frameworks came along and broke everything.
Also - what on earth is "f*"? I originally assumed it was shorthand for "fuck" but is "fuck dream" a common expression? And wouldn't you normally write it as "f***"?
I can only approve. To me Astro started as "it's just html and css but with includes."
I used it for my personal website, and recently used it when reimplementing the Matrix Conference website. It's really a no-fuss framework that is a joy to use.
Among the things I love about Astro:
- It's still html and css centric
- Once built, it doesn't require js by default
- You can still opt-into adding js for interactivity here and there
- Content collections are neat and tidy
- Astro massively optimizes for speed, and the maintainers know how to do it
- It had a very helpful devbar to help you visually figure out what easy fix can make your website snappier (like lazily loading images if it detects them below the fold)
For the "optimize for speed" bit, an example is that the css minifier cleverly inlines some CSS to avoid additional queries. The Image component they provide will set the width and height attribute of an image to avoid content layout shifts. It will also generate responsive images for you.
I love Astro so much. After 20 years in data and backend, I got back into frontend for a big project. After banging my head with React, I took a leap of faith and choose Astro with Svelte. That includes an initial try with SvelteKit.
It's worked out so wonderfully. By being HTML/CSS centric, it forces a certain predictable organization with your front end code. I handed the frontend to another developer, with a React background, and because it's so consistently and plainly laid out, the transition happened almost overnight.
The best way to do "just html and css with includes" is to run any commonon webserver like nginx and turn on server side includes. It is literally just html and css with includes then. And zero javascript, anywhere, unless you want it.
SSI hasn't changed in 20+ years and it's extremely stable in all webservers. A very tiny attack surface with no maintainence problems. It just does includes of html fragments. The perfect amount of templating power to avoid redundancy but also avoid expoitable backends.
> 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 the only way we built websites with a bit of dynamic behavior. Then SPAs were "invented", and "progressive enhancements" movement became something less and less people did.
Now it seems that is called JavaScript islands, but it's actually just good ol' web pages :) What is old is new again.
I am feeling old reading the phrase "traditional frameworks" as a reference to SPA/Virtual DOM frameworks all while the actual traditional frameworks like Backbone, jQuery, etc. actually worked the way described in the blogpost.
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 Cloudflare, fetches the correct page and from user-perspective works flawlessly. Even though behind the scenes the response was 404 (since that dynamic page was never really compiled). Really nice especially when bundling your app as a webview for mobile.
Maybe i misunderstood you, but I did dynamic routes/pages for Next and Astro static builds. Using contentful or storyblok as a CMS, where the editor defines the routes and the components/bloks per page. Basically, the projects had one slug like [...slug].
Routes and Components per Page are dynamically created while export Next or build Astro static pages. In both frameworks you create the pages / slugs via getStaticPaths. And if ISR/ISP is enabled, even new pages (that are not known during build time) are pre-rendert while running the server.
In Next it is called dynamic routes[1] and in Astro dynamic pages[2].
Catch all slugs in Next and Astro are [...slug] e.g..
>See that code fence at the top? That runs at build time, not in the browser. Your data fetching, your logic - it all happens before the user even loads the page.
I can't with this goddamn LLM blog posts, it just drowns everything.
I spent a small amount of time looking into Astro and I didn’t get the difference with the Fresh framework created by the Deno team.. ? Fresh does this Island architecture already, and benchmarks on Astro website dont include Deno+Fresh to compare. So I’m still wondering what’s the benefit of using Deno+Astro vs. Deno+Fresh
Fundamentals of the Web haven't gone away, anyone still coding across PHP, Spring, Quarkus, ASP.NET MVC hasn't noticed that much how bad things have become with JS frameworks.
Unfortunately in fashion driven industry, it isn't always easy to keep to the basics.
>> See that code fence at the top? That runs at build time, not in the browser. Your data fetching, your logic - it all happens before the user even loads the page. You get brilliant TypeScript support without any of the complexity of hooks, state management, or lifecycle methods.
This is satire, right?
If only there was any other server side language that could do the same and produce static compliant super-light HTML-first pages!
I ported my personal website from Jekyll to Astro a few weeks back and I really liked it. Astro is much easier to build and extend for me (and that is a personal preference point - I (and by I mostly mean claude) - and it's cool to add react components in to create more interactive points (but I haven't deployed that element yet).
Speed is probably the same as jekyll - but relative to my react vite and nextjs apps it's about 10 times faster.
I would definitely use Astro for more complicated websites than content driven - but would probably return to nextjs or more hefty full stack solutions for complicated web apps.
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. And there yes, without doubt, vite is amazing.
I've only heard of Astro before, but I got interested today and it seems like an intriguing framework.
That said, Astro also seems to be developed under a venture-backed company.
Is it still less likely to end up like Next.js and React under Vercel's influence?
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.
Please stop recommending React as the de facto framework, we need some critical thinking back into front-end. HTML, CSS and JS are much better alternatives.
68 comments
[ 5.1 ms ] story [ 66.7 ms ] threadI guess I'd argue "Traditional Frameworks" were the ones that never stopped doing this. Laravel, Django, Rails etc. Then the SPA frameworks came along and broke everything.
Also - what on earth is "f*"? I originally assumed it was shorthand for "fuck" but is "fuck dream" a common expression? And wouldn't you normally write it as "f***"?
I used it for my personal website, and recently used it when reimplementing the Matrix Conference website. It's really a no-fuss framework that is a joy to use.
Among the things I love about Astro:
- It's still html and css centric - Once built, it doesn't require js by default - You can still opt-into adding js for interactivity here and there - Content collections are neat and tidy - Astro massively optimizes for speed, and the maintainers know how to do it - It had a very helpful devbar to help you visually figure out what easy fix can make your website snappier (like lazily loading images if it detects them below the fold)
For the "optimize for speed" bit, an example is that the css minifier cleverly inlines some CSS to avoid additional queries. The Image component they provide will set the width and height attribute of an image to avoid content layout shifts. It will also generate responsive images for you.
It's worked out so wonderfully. By being HTML/CSS centric, it forces a certain predictable organization with your front end code. I handed the frontend to another developer, with a React background, and because it's so consistently and plainly laid out, the transition happened almost overnight.
SSI hasn't changed in 20+ years and it's extremely stable in all webservers. A very tiny attack surface with no maintainence problems. It just does includes of html fragments. The perfect amount of templating power to avoid redundancy but also avoid expoitable backends.
Back in my days we called this "progressive enhancements" (or even just "web pages"), and was basically the only way we built websites with a bit of dynamic behavior. Then SPAs were "invented", and "progressive enhancements" movement became something less and less people did.
Now it seems that is called JavaScript islands, but it's actually just good ol' web pages :) What is old is new again.
Bit of history for the new webdevs: https://en.wikipedia.org/wiki/Progressive_enhancement
Dear God. In 20 years people will hire HTML experts as if they are COBOL experts today.
Whereas with SvelteKit, it builds happily and does this beautiful catch-all mechanism where a default response page, say 404.html in Cloudflare, fetches the correct page and from user-perspective works flawlessly. Even though behind the scenes the response was 404 (since that dynamic page was never really compiled). Really nice especially when bundling your app as a webview for mobile.
Routes and Components per Page are dynamically created while export Next or build Astro static pages. In both frameworks you create the pages / slugs via getStaticPaths. And if ISR/ISP is enabled, even new pages (that are not known during build time) are pre-rendert while running the server.
In Next it is called dynamic routes[1] and in Astro dynamic pages[2]. Catch all slugs in Next and Astro are [...slug] e.g..
[1] https://nextjs.org/docs/pages/building-your-application/rout...
[2] https://docs.astro.build/en/guides/routing/#example-dynamic-...
I can't with this goddamn LLM blog posts, it just drowns everything.
Basically, not suitable for anything complex.
That's a really low bar. Why not static pages? Why even use a framework at all if you're thinking of using Astro?
I was amazed by how easy it was compared to my experience with Wordpress for this several years ago.
And I can host it for free on something like Netlify and I don’t need to worry about the site being hacked, like with WP.
I even built a very simple git-based CMS so that the client can update the content themselves.
Web dev has really come a long way, despite what a lot of people say.
Unfortunately in fashion driven industry, it isn't always easy to keep to the basics.
This is satire, right? If only there was any other server side language that could do the same and produce static compliant super-light HTML-first pages!
Speed is probably the same as jekyll - but relative to my react vite and nextjs apps it's about 10 times faster.
I would definitely use Astro for more complicated websites than content driven - but would probably return to nextjs or more hefty full stack solutions for complicated web apps.
I feel a lot of the hype around Astro has more to do with vite than anything else. And there yes, without doubt, vite is amazing.
That said, Astro also seems to be developed under a venture-backed company. Is it still less likely to end up like Next.js and React under Vercel's influence?
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.
Astro brings a friendly UI to maintain and update the sites? Like the WordPress panel and editor.