alt Hacker NewsI overlooked Astro for a long time, I didn't really get it, and my journey back to it went something like this:
- 1 Getting burned out by Nextjs slowness in a complex production project that shouldn't be that complex or slow on the dev side, (this was 2022 approx)
- 2 Taking a break from React
- 3 Moving back to classic server side rendering with python and Go and dealing now with template engines. Hyped with HTMX and loving it, but my conclusion after so many years of react was that template partials don't feel right to me and templates engines are somewhat not maintained and evolved as used to be. I found my self not feeling naturally inclined to reach for the htmx way and just let the coding agent do it the way they wanted AND stating to notice again the burn out.
- 4 Looking with some envy to co-workers using shadcn how fast they are getting things done and how good they look.
- 5 Wondering would be a way to use JSX with HTMX server side, I miss components, I don't want partial templates.
And then I found Astro, ahhh now I get it, Astro prioritizes generation over run time, and that unlocks a lot of gradual complexity where you can choose how to mix things ( islands ) you get something way more interesting than a template engine, and it uses JSX so you can benefit from React ecosystem.
This where I am now, but yet I have to complete a side project with it to know if I fully get it and love it.
So far seems to me is the answer I was looking for.
Replies
> 5 Wondering would be a way to use JSX with HTMX server side, I miss components, I don't want partial templates.
I'm playing with JSX, Hono, and Bun right now to do just that. It's early but will see how it goes.
Astro is great. If you are familiar with React, you can pick it up pretty much instantly. The design is simple enough to extend when needed as well for custom things.
Last time I dabbled in a front-end I tried out Astro but felt like it just added another layer of complexity without much gain when all my components were just wrapping React in different ways. I went with react router instead.
I can see the value of the "islands" concept when you have a huge front-end that's grown over generations of people working on it.
For my constrained front-end debugging Astro errors on top of React errors on top of whatever all the turtles down felt a like a step too far.
Am I in my Rust centered back-end driven brain missing something?
This is what doesn't get discussed enough around htmx, in my opinion. So much of the difficult steps are left for the templating system, and template systems aren't great in general. You need to track a lot of identifiers for htmx to work properly, and your template and view logic needs to make that make sense. For the templating systems I've seen, that's not so simple to do.