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 would thinking F**ing, to delve deeper into the meta discussion
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've never used Astro so forgive my ignorance, but isn't that just creating a .html file, a .css file and then optionally provide a .js file? What does Astro give you in this case? You'd get the same experience with a directory of files + Notepad basically. It's also even more optimized for speed, since there is no overhead/bloat at all, including at dev-time, just pure files, sent over HTTP.
> an example is that the css minifier cleverly inlines some CSS to avoid additional queries
Is that a common performance issue in the web pages you've built? I think across hundreds of websites, and for 20 years, not once have "CSS queries" been a bottleneck in even highly interactive webpages with thousands of elements, it's almost always something else (usually network).
For the first one, the main benefits of Astro over static html and css (for my use cases) are the ability to include components and enforce the properties that must be passed. A typical example would be [here][0] where I define a layout for the whole website, and then [on each page that uses it](https://github.com/matrix-org/matrix-conf-website/blob/main/...) I have to pass the right properties. Doable by hand, but it's great to have tooling that can yell at me if I forgot to do it.
Content Collections also let me grab content from e.g. markdown or json and build pages automatically from it. The [Content Collections docs][1] are fairly straightforward.
As for performance issues, I've spent quite a bit of time on the countryside where connectivity was an issue and every extra request was definitely noticeable, hence the value of inlining it (you load one html file that has the css embedded, instead of loading an html file that then tells your browser to load an extra css file). The same can be true in some malls where I live.
[0]: https://github.com/matrix-org/matrix-conf-website/blob/main/... [1]: https://docs.astro.build/en/guides/content-collections/
I don't know that there's a serious solution to it because complexity can't come with zero friction but just my gut feeling was to back out and go with something else for now.
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
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 to debug with PHP on the frontend? I wouldn’t want to go back to that. SPAs have their place, most so in customer dashboards or heavily interactive applications, but Astro find a very nice balance of having your server and client code in one codebase, being able to define which is which and not having to parse your data from whatever PHP is doing into your JavaScript code is a huge DX improvement.
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 logic into templates...) and then putting that behavior under unit tests. Basically being better at enforcing proper MVC split was the way to solve that.
The DX wasn't horrible outside of that, even early 2010s which was when I was dealing with that for the first time.
Modern PHP development with Laravel is wildly effective and efficient.
Facebook brought React forth with influences from PHPs immediate context switching and Laravel’s Blade templates have brought a lot of React and Vue influences back to templating in a very useful way.
True, don't remember doing much unit testing of JavaScript at that point. Even with BackboneJS and RequireJS, manual testing was pretty much the approach, trying to make it easy to repeat things with temporary dev UIs and such, that were commented out before deploying (FTPing). Probably not until AngularJS v1 came around, with Miško spreading the gospel of testing for frontend applications, together with Karma and PhantomJS, did it feel like the ecosystem started to pick up on testing.
> Astro find a very nice balance of having your server and client code in one codebase, being able to define which is which and not having to parse your data from whatever PHP is doing into your JavaScript code is a huge DX improvement.
the point is pretty much that you can do more JS for rich client-side interactions in a much more elegant way without throwing away the benefits of "back in the days" where that's not needed.
How much of the frontend and how much of the backend are we talking about? Contemporary JavaScript frameworks only cover a narrow band of the problem, and still require you to bootstrap the rest of the infrastructure on either side of the stack to have something substantial (e.g., more than just a personal blog with all of the content living inside of the repo as .md files).
> while avoiding the hydration performance hit
How are we solving that today with Islands or RSCs?
In terms of the front-end, there’s really no limit imposed by Next.js and it’s not limited to a narrow band of the problem (whatever that gibberish means), so I don’t know what you’re even talking about.
> How are we solving that today with Islands or RSCs?
Next.js/RSC solves it by loading JavaScript only for the parts of the page that are dynamic. The static parts of the page are never client-side rendered, whereas before RSC they were.
Isn't that basically just what Symfony + Twig does? Server-side rendering, and you can put JS in there if you want to. Example template:
<html>
<head>[...]</head>
<body>
{% if user.isLoggedIn %}
Hello {{ user.name }}!
{% endif %}
</body>
</html>
That is a perfect description of it, released 1996. So far ahead of its time it’s not even funny. Still one of the best programming environments I’ve ever used almost <checks calendar> 30 years later.
I think we are overdue for a rediscovery of object oriented programming and OOP design patterns but it will be called something else. We just got through an era of rediscovering the mainframe and calling it “cloud native.”
Every now and then you do get a new thing like LLMs and diffusion models.
Another one: WASM is a good VM spec and the VM implementations are good, but the ecosystem with its DSLs and component model is getting an over engineered complexity smell. Remind anyone of… say… J2EE? Good VM, good foundation, massive excess complexity higher up the stack.
I’m not sure javascript islands is that but I appreciate a new approach to an old pattern.
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 client with preloaded data from the server.
TFA is trying to explain that value to someone who wants to use React/Svelte/Solid/Vue but only on a subset of their page while also preloading the data on the server.
It's not necessarily progressive enhancement because the HTML that loads before JS hydration doesn't need to work at all. It just matches the initial state of the JS once it hydrates. e.g. The <form> probably doesn't work at all without the JS that takes it over.
These are the kind of details you miss when you're chomping at the bit to be cynical instead of curious.
Nicely sums up a lot of interactions these days
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.
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.
You see the same thing in political conservative/traditional circles, where basically things were good when they were young, and things today are bad, but it all differs on when the person was born.
when things decline that's still an accurate represenation, not just an artifact of subjectivity
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.
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 changing the pages as well as rewriting links. As you of course want the normal routes in web app. Just a huge PITA.
[0]: lockmeout.online
[0]: `https://docs.astro.build/en/guides/routing/#static-ssg-mode
Now, these are just the limitations I can think of, but there are probably more. And to be fair, why "break" the web this way, if you can just use query params: /todo?id=123. This solves all the quirks of the above solution, and is exactly what any server-side app (without JS) would look like, such as PHP etc.
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.
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" :)
I can't with this goddamn LLM blog posts, it just drowns everything.
Sucks when everything you write sounds like a bot because you're autistic.
Feeling less-than-human isn't great.
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.
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.
>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. Want to add interactivity? Easy, but only where you need it. Want to use your favourite framework? Go ahead, Astro won't judge.
>Developer experience that actually delivers
I am downvoted so I guess I'm wrong. It's just bland and form in a way ChatGPT usually outputs. Sorry to the author if I'm wrong.
Speak your truth, poster!
My understanding is that Astro is able to more-or-less take a component from any combo of popular frameworks and render it, whereas Fresh is currently limited to just Preact via Deno. I think the limitation is to optimize for not needing a build step, and not having to tweak the frameworks themselves like Astro does (did?).
I'm not affiliated; I've just looked at both tools before.
Basically, not suitable for anything complex.
What makes it so great is not that it serves a particular niche (like "content-driven websites") but that it provides a developer experience that makes it incredibly easy to scale from a static website to something very complex and interaction-heavy without compromising UX.
Same thing happened with microservice architecture.
That's a really low bar. Why not static pages? Why even use a framework at all if you're thinking of using Astro?
Using a framework has upsides over writing static pages manually. Most notably, you can decompose your website into reusable components which makes your implementation more DRY. Also, you can fluently upgrade to a very interaction-heavy website without ever changing tech or architecture. But that's just what I value. I whole-heartedly recommend trying it out.
If you use static pages, how do you make sure that shared UI like navbars all update if you decide to make a change?
<html>
{% include "components/head.html" %}
<body>
{% include "components/navbar.html" %}
...
</body>
</html>
{% include "components/button.html" text="example" url="https://example.com" %}[1] https://htmx.org/essays/template-fragments/#known-template-f...
Yes, I've used stuff like Templ for Go or Razor Pages for .NET.
Even if the raw HTML rendering performance is significantly better, there are other factors to consider in terms of dx.
1) Most backend languages will not hot reload modules in the client which is what Vite gives you.
Very often the whole backend application needs to be recompiled and restarted. Even with something like the .NET CLI which does have a hot reload feature (and it's absolute garbage btw) the whole page needs to be reloaded.
PHP has an advantage here since every request typically "runs the whole application".
But even with PHP, JS and CSS assets do not have hot reload unless you're also running Vite in parallel (which is what Laravel does).
With Astro you can run a single Vite dev server which takes care of everything with reliable and instant hot reload.
2) With Astro you will get islands which are simply not feasible with any non-JS backend. Islands are so much more powerful than old school progressive enhancement techniques. When we were using eg jQuery 15+ years ago it was a massive pain to coordinate between backend dynamic HTML, frontend JS code, and CSS. Now with islands you can encapsulate all that in a single file.
3) You also get CSS co-location. Meaning you can write an Astro server component with its own CSS scoped to the particular piece of markup. Again, CSS colocation is a huge win for dx. These days I write vanilla CSS with PostCSS but with Astro it's trivial to integrate any other CSS workflow: Tailwind, SCSS, etc.
4) Finally, you have to consider bundling of frontend assets. I don't think it's an exaggeration to say that solutions like Vite are really the best you can get in this space. Internally it uses Go and Rust but it's all abstracted for you.
If you have a use case where you really need exceptional HTML rendering performance in a monolithic application, Astro (or really anything in JS) is definitely a bad fit. But you can easily run an Astro server app on eg Cloudflare Workers which could would work in many of those use cases too and reduce latency and adapt dynamically to load.
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.
But at least in Germany there are some agencies doing nothing else.
$550/TB for those who want to save a search.
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.
Like when?
On the positive side their use of web components is a nice bet.
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?
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.
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.
Eg. https://www.gatsbyjs.com/docs/glossary/headless-wordpress/
I prefer htmx and, better yet, datastar as they're backend-agnostic.
Datastar does everything htmx does and much more. And, iirc, is also smaller. Just explore their site, docs, essays etc
Me? I’m using Html + css + xslt.
It’s php for javascript devs?
And, also, "php" in your question could be ruby, go, C or anything else that runs on the server.
I prefer htmx or, better yet, Datastar which are both small, backend agnostic, js libraries for making ssr html interactive to varying degrees. You could, in theory, use astro with them but probably better to just use something else.
Astro needs to run on a server that can run node etc
And php can equally have its html cached.
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 faster".
It's difficult to articulate the source of just how broken the discussion space is; nor have I made a particularly strong argument myself. But I think it's important to keep pushing back on conversations that position framework's like they are brands winning hearts and minds. Ala the fashion industry.
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 languages (two of which are some flavor of Javascript), your twelve page site takes a couple of minutes to compile (what?), and it chokes your three load-balanced AWS compute nodes.
Web applications are hard. I get that. Web sites? They were, by design, incredibly simple. We make them complicated for often unclear reasons.
I appreciate what the Astro folks are trying to do, and it's very clever. But your basic Web site need not require freaking npm in order to "return to the fundamentals of the Web".
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.
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.
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.
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?
But if my "website" is an application, Javascript makes the whole user experience better, if implemented well. It doesn't matter that the user will wait for 1 more second if they will have to spend the entire day working on it.
Still, yes, I prefer other tooling in the backend. But astro is a good thing for JS devs
Seriously. This is how things are done in most nonjs frameworks
tomashubelbauer•6h ago
diggan•6h ago
stevoski•6h ago
diggan•6h ago