1. It's the most flexible yet easily configured static site generator I've used to date
2. It's reliable. The docs are well maintained and, mirabile dictu, the real behavior of the system matches its documented behavior
3. It's stable. Lots of new features are getting added, but (so far) upgrades don't break things
4. It has good tooling for editors like vscode
5. Many of my current projects take the form of "big data pipeline, followed by intermittent job to rebuild a static site and push it live"; astro fits very nicely in this role
Caveat: I use exactly none of Astro's backend features. I understand why they've added them but, for me, it's all about static site generation.
About the only thing I don't like is the weirdness of the boundary between astro components and framework components. I get it, but still. It's something to carefully consider when building each new astro site.
> 5. Many of my current projects take the form of "big data pipeline, followed by intermittent job to rebuild a static site and push it live"; astro fits very nicely in this role
Front end is a young person’s game because of the endless churn. It’s where I started and I love delivering a tight, next-level UX. But I’ve spent the last decade in enterprise distributed, microservices, integration, data etc with a ton of complexity but far less BS churn. Now I need to decide on a web stack and have been leaning TS, React, Next etc. But there’s no foundation you can rely on. It’s shifting as we speak, with the endless gyrations and new abstractions, and waves of complexity and simplification and breaking changes. I’ve never minded learning but in front end you basically zero your knowledge every few years. This is now an area I’ll happily delegate to an AI.
Of course I’m heavily into LLM’s etc right now so maybe I should stop whining. That makes JS seem like a glacier.
No foundation? What do you think all these libraries and frameworks are built on???
The true path to having a "deep" front-end toolbox is in learning things that are not libraries. Here is a "long-lasting" frontend list that really just scratches the surface:
- CSS(animations, advanced layouts etc...)
- HTML(canvas, accessibility, svgs...)
- websockets, advanced networking
- advanced browser APIs(indexdb, mouse/touch events, events in general, WebGL...)
- high performance js, perf monitoring
Its really just DOM/state manipulation, and different levels of caching that frameworks provide.
I take your point but keeping an app current enough to maintain the ability to hire, is hardest in this area. Not like SQL or C for example. Knowing that can be useful for decades. You build knowledge that persists - experience is a good thing. I can’t tell you the front end stuff I’ve not used in a long time because the list is very long. Much of that knowledge isn’t useful and the code has long changed. I can get involved but I’m not as interested.
It’s like in a war when the new guy shows up. Don’t get too friendly; he’s probably not going to make it.
I have quit the React/Node/JavaScript ecosystem. I'm going all in on backend. I also feel all the time invested in front end has always wither and vanish. It is hard to accumulate knowledge in the front end field when it is always changing. I'm probably going to lose money on this bet (going from senior front end), but I'm already feeling a lot happier.
Rust, I've been experimenting with it, and (tutorial) code written a year ago doesn't compile anymore.
If there's something you shouldn't use, it's Rust, at least for the time being. Maybe in 10 years.
I think if they were willing to let go of type safety, PHP + jQuery could unironically work just fine for them. I wonder if it's possible to sanely use PHP with TypeScript + Vite with SSG, without making your tooling too complex.
Anyway, congrats to them, sounds like they reduced costs and even kept engineers happy with an interesting technical challenge.
Maybe, but that does that devalue the positive progress today?
I understand what you're saying, people framework hop and what's popular does change frequently, but we're not all using Frontpage still, are we? That process of changing to something better (as evidenced by TFA) has value in itself.
One thing is framework hopping, which one can decide to do or not do.
The problem here is that even staying within the same framework it feels like you're changing it every 6 months. Look at Next (pages vs app router) or Remix (now react-router).
There's literally zero stability and you need to rewrite everything constantly.
The worst part, as it happens at my job, is when you have people newer to the industry that think that if you're not on the latest and coolest then "everything is shit" and they live in this mindset where everything has to be rewritten constantly or otherwise they cannot be happy at work. Fuck your users, your product and everything else. Latest cool trend is the only thing that matters to them.
> I understand what you're saying, people framework hop and what's popular does change frequently, but we're not all using Frontpage still, are we?
yeah, we switched to WordPress. I am glad we didn't follow up on our web agency 5 years ago to switch to gasby. Our wordpress is still running fine. I am glad we are not considering switching to Astro, since wordpress will still be there in 5 years.
I think that Next.js in its current form is not great for DX.
I've recently tried out both React-Router v7 (which is sort Remix 3? it is confusing), and TanStack/Start and found them both to have better developer DX than Next.JS.
React-Router v7 was the simpler of the two and my app had less code as a result, but a little less flexible than TanStack/Start. But both seemed acceptable.
Astro has been recommended so I will try it out next.
These guys love to create chaos. We used to “joke” with the fact they change the way to do routing in each RR release, now they change the entire framework with each release.
The complexity fatigue is something that I can certainly relate to. Things like caching, request deduplication and incremental static regeneration across multiple pages can easily lead to site that’s harder to reason about than I would like.
This is how I see it. You need to be a nextjs expert to produce a nextjs website. Astro you just need to understand basic concepts and can produce a website. I tried nextjs, and the complexity for a SPA was off the charts. Switched to Astro and never looked back.
NextJS isn't ideal if you just want a SPA, just stick any frontend router in if you want that.
If you aren't using it for SSR/SSG then you probably don't need it. If you are writing a really dynamic app with a few thousand users you probably don't need it. It is crazy good for blending dynamic/static pages together, preloading data for page responsiveness and making dependency management less of a nightmare. Things like e-commerce are where it really shines because it can blend thousands of cached SSG product pages with dynamic elements and data in a relatively straightforward way.
I would not recommend it for any project where you are going to have fairly few static pages and relatively few users, it isn't worth the complexity.
I completely agree with this sentiment. I will say this, vercel was easy to use and v0 is pretty cool too. I can appreciate what they're doing, I just don't have time to become a nextjs expert.
Both vercel and next keep breaking APIs. I just blank out stopped touching anything coming from there.
I still have a client on next + vercel/ai and it's a constant shitshow of broken updates.
It's not an environment you can be productive with.
I moved to solid from now on: they don't have as much money but applications built years ago still work today
I wonder how Kamal compares to Dokploy or Coolify, both have GUIs as well in those times I don't want to mess with the command line just to fix something in production.
Readit News
1. It's the most flexible yet easily configured static site generator I've used to date
2. It's reliable. The docs are well maintained and, mirabile dictu, the real behavior of the system matches its documented behavior
3. It's stable. Lots of new features are getting added, but (so far) upgrades don't break things
4. It has good tooling for editors like vscode
5. Many of my current projects take the form of "big data pipeline, followed by intermittent job to rebuild a static site and push it live"; astro fits very nicely in this role
Caveat: I use exactly none of Astro's backend features. I understand why they've added them but, for me, it's all about static site generation.
About the only thing I don't like is the weirdness of the boundary between astro components and framework components. I get it, but still. It's something to carefully consider when building each new astro site.
You may be interested in Observable Framework [0]
[0] https://observablehq.com/framework/
Page speed and SEO scores for astro sites are off the charts.
And Bolt.new and Cursor do really well with it.
Of course I’m heavily into LLM’s etc right now so maybe I should stop whining. That makes JS seem like a glacier.
The true path to having a "deep" front-end toolbox is in learning things that are not libraries. Here is a "long-lasting" frontend list that really just scratches the surface:
- CSS(animations, advanced layouts etc...)
- HTML(canvas, accessibility, svgs...)
- websockets, advanced networking
- advanced browser APIs(indexdb, mouse/touch events, events in general, WebGL...)
- high performance js, perf monitoring
Its really just DOM/state manipulation, and different levels of caching that frameworks provide.
It’s like in a war when the new guy shows up. Don’t get too friendly; he’s probably not going to make it.
[1]: https://www.solidjs.com/
I think if they were willing to let go of type safety, PHP + jQuery could unironically work just fine for them. I wonder if it's possible to sanely use PHP with TypeScript + Vite with SSG, without making your tooling too complex.
Anyway, congrats to them, sounds like they reduced costs and even kept engineers happy with an interesting technical challenge.
We switched from Astro to SkibidiJS
I understand what you're saying, people framework hop and what's popular does change frequently, but we're not all using Frontpage still, are we? That process of changing to something better (as evidenced by TFA) has value in itself.
The problem here is that even staying within the same framework it feels like you're changing it every 6 months. Look at Next (pages vs app router) or Remix (now react-router).
There's literally zero stability and you need to rewrite everything constantly.
The worst part, as it happens at my job, is when you have people newer to the industry that think that if you're not on the latest and coolest then "everything is shit" and they live in this mindset where everything has to be rewritten constantly or otherwise they cannot be happy at work. Fuck your users, your product and everything else. Latest cool trend is the only thing that matters to them.
yeah, we switched to WordPress. I am glad we didn't follow up on our web agency 5 years ago to switch to gasby. Our wordpress is still running fine. I am glad we are not considering switching to Astro, since wordpress will still be there in 5 years.
I've recently tried out both React-Router v7 (which is sort Remix 3? it is confusing), and TanStack/Start and found them both to have better developer DX than Next.JS.
React-Router v7 was the simpler of the two and my app had less code as a result, but a little less flexible than TanStack/Start. But both seemed acceptable.
Astro has been recommended so I will try it out next.
We use it at work with a Rails backend, and we are about to start a new project with an Adonis.js backend.
Give it a try. It’s the best way to use React, by far.
These guys love to create chaos. We used to “joke” with the fact they change the way to do routing in each RR release, now they change the entire framework with each release.
Dead Comment
If you aren't using it for SSR/SSG then you probably don't need it. If you are writing a really dynamic app with a few thousand users you probably don't need it. It is crazy good for blending dynamic/static pages together, preloading data for page responsiveness and making dependency management less of a nightmare. Things like e-commerce are where it really shines because it can blend thousands of cached SSG product pages with dynamic elements and data in a relatively straightforward way.
I would not recommend it for any project where you are going to have fairly few static pages and relatively few users, it isn't worth the complexity.
Even the devs involved don't have their heads around what they've built, considering responses in github issues.
It's not an environment you can be productive with.
I moved to solid from now on: they don't have as much money but applications built years ago still work today
[1] http://kamal-deploy.org