This is where I think Astro shines, with its "islands of interactivity" approach. Keep things as simple as reasonably possible, and provide an idiomatic, first-class mechanism for supporting more complexity where appropriate.

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

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.

1000% this. I actually am using htmx at ${JOB} and this is essentially the only downside to htmx. I want to know which template partial is getting swapped. My IDE doesn't know. I need to track countless html ids to know what will be swapped where... how? It hasn't been a big deal because I alone write the frontend code so I have all my hacks to navigate and my intimate knowledge of the code, but if we need more devs on the frontend, or if the frontend drastically grows feature wise, i will need to tackle this issue post haste. I think template partials could help, but then we also would end up with giant template files and that would also be annoying.

> 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?

Thanks for this! A brilliant insight, which I don't think I ever encountered before.

Hmm, I've been doing webdev for a living since 1998, intimately familiar w/ the complete history and modern practices, and I respectful disagree. Pretty sure it's a good thing we're not all forced to do things the same way. And the new SSR with CSR capabilities is not at all the same as the old SSR. You're right that auth is kind of a hot mess though.

> And the new SSR with CSR capabilities is not at all the same as the old SSR

Yea I know its just a display of the industries indecisiveness. Everytime we need something new and fresh some old favorite is revived until after 5 years its old again. I like being able to do things differently, I hate having to implement "security" features knowing all too well that they aren't secure at all. Minimizing attack surface should not be the default. And its not like this is a new problem. For some reason web devs love to work around a problem instead of fixing it.

Sorry, no, you seem to have misunderstood that I'm disagreeing with you. Modern SSR is not just a return to the same old thing.

It most definitely is. Same old shit with a twist. Also apparently all web devs are cloudslaves nowadays as well. Webdev is dead.

Yeah, checklists are great. Further, they're even precursors to automation.

Yes, this, 100%. Take your pick: "Haste makes waste", "Measure twice, cut once", "Slow is smooth, smooth is fast", etc.

4.2% for bots? Wat. No way. In 2012 it was easily 50%. In the era of GenAI scraping it's surely only gone up.

I share your preference. (I also mourn the loss of the word "vibe" for other contexts.) In this case there were apparently hundreds of commit messages stating "generated by Claude Code". I feel like there's a missing set of descriptors -- something similar to Creative Commons with its now-familiar labels like "CC-BY-SA" -- that could be used to indicate the relative degree of human involvement. Full-on "AI-YOLO-Paperclips" at one extreme could be distinguished from "AI-IDE-TA" for typeahead / fancy autocomplete at the other. Simon, you're in a fantastic position to champion some kind of basic system like this. If you run w/ this idea, please give me a shout-out. :)

Thanks for sharing. This kind of "color" isn't always easy to ascertain, but (for me, at least) it plays a part in vendor selection.

This same week, Egghead (https://egghead.io) started offering $500 lifetime access to everything they ever made or will make. There's definitely some excellent material in their catalog. But the signals sure seem to point toward the decline of centralized human-created coursework.

Egghead.io is not worth it, the courses there have a shelf life even shorter than frontendmasters. Authors mostly use it to dump their wares then never update the course afterwards while breaking API changes litter their backlog making most content, unless it was released in the last 3 months, worthless.

Absolutely not worth it since the courses are on par with random youtube tutorials IMO.

Also really dislike the pattern of some popular frontend frameworks selling basic documentation in the form of "courses."

Thanks for replying. Agreed on shelf life, but IME at least some of the egghead materials, at the time of publication, have been worthwhile to me. But that experience (5+ years ago) is quite possibly out of date.

Whose lifetime?

(meta: genuinely curious why my observation was downvoted. I may take a further karma hit for mentioning it but worth it if it elicits a meaningful response. what gives?)

At a guess, because it sounds like a product pitch and these 'lifetime payment things' are ALWAYS curtailed if the product actually survives.

I didn’t downvote you, but lifetime offerings tend to be a red flag.

Agreed! (That's why I mentioned it in the context of TFA.) Thanks for replying tho

Thanks for referencing Helium -- it looks great!