I really like Astro:<p>1. It's the most flexible yet easily configured static site generator I've used to date<p>2. It's reliable. The docs are well maintained and, mirabile dictu, the real behavior of the system matches its documented behavior<p>3. It's stable. Lots of new features are getting added, but (so far) upgrades don't break things<p>4. It has good tooling for editors like vscode<p>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<p>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.<p>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.
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.<p>Of course I’m heavily into LLM’s etc right now so maybe I should stop whining. That makes JS seem like a glacier.
I can relate to the complexity fatigue.<p>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.<p>Anyway, congrats to them, sounds like they reduced costs and even kept engineers happy with an interesting technical challenge.
I think that Next.js in its current form is not great for DX.<p>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.<p>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.<p>Astro has been recommended so I will try it out next.
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.
I love that they're using Kamal[1] outside of a Rails context. I've seen that promised in the docs, but hadn't encountered it in real life.<p>[1] <a href="http://kamal-deploy.org" rel="nofollow">http://kamal-deploy.org</a>
> <i>Next, Nuxt, and SvelteKit are built with complex, runtime browser rendering engines — a massive overhead for content-driven websites with minimal interactive elements.</i><p>This 100%. I just don't understand why all modern frameworks aren't doing islands by now.<p>Sending, parsing, and executing JS for non interactive components is a massive waste.
We are doing something similar. Moving from NextJS to Vite. We export our webapp and get static assets that get cached by the web browser. When loaded the app makes a single GraphQL call that loads up all the data needed for the initial page.<p>We don't do any SSR. We did not realize that NextJS isn't a good option for use case like ours. It does do static exports and you can do client side routing. But it adds a lot complexity to support SSR that isn't relevant to us. And DX compared to Vite is painfully slow. Annoyingly slow.
Like some other commenters here who started with Bootstrap/jQuery/etc., I feel stuck in the stone ages at times. My most recent content-based site uses Hugo (<a href="https://gohugo.io/" rel="nofollow">https://gohugo.io/</a>), but I'm starting to tire of the magic and gotchas I keep running into.<p>Can someone that has used Astro and an older static site generator framework explain the pros/cons of Astro in that context?
Svelte keeps getting mentioned as part of next/nuxt/svelte, but my experience with it has been great. I've used it for projects of varying complexity like a personal blog and a SPA.<p>I believe much of the complexity fatigue the author described is more related to React and its woes than to frameworks and JavaScript in general. Not that JavaScript doesn't have its own set of problems.
Maybe it's because I'm late enough to the party that I didn't have any applications that needed to be migrated from pages router to app router, but I really cannot relate to so many of these recent articles bemoaning the state of Next.js. Preferring server components, going back to HATEOAS principles, and going back to using forms whenever possible has been great.
next.js reminds me of Ruby on Rails, main pain point is they keep changing how they do things, but docs, examples etc can't keep up so I'm constantly seeing the wrong answers to my problems.<p>An example of this is how they implemented sitemap.xml, but half arsed doing a sitemap index properly (which really wasn't much work), so they will end up doing it properly in some version, in the mean time you have to work around the framework (it would be better if they didn't even have this feature), and when the release a proper implementation new users will struggle to find the answers on how to do it.<p>This all adds friction to upgrade, I'd like to move to v15 as it has a feature I really need, but they have changed the bloody confusing caching system, not sure it's worth the work. Creating web frameworks that are volatile is fine if your just building short lived projects, but not anything more complex and longer lived, this is the same pain and why I gave up on RoR.
Astro is simple and nice.<p>I built a github sites blog template for my friends to use that you can run and publish fully in browser. [1] I also use it for my personal blog. [2]<p>Astro made it simple for someone with little frontend framework experience (me) to get started and build something useful. The site itself only uses javascript for light/dark mode, but even that is optional. What Astro solves for me is best practices for the build step.<p>[1] <a href="https://github.com/easy-astro-blog-creator/easy-astro-blog-creator">https://github.com/easy-astro-blog-creator/easy-astro-blog-c...</a><p>[2] <a href="https://shelbyjenkins.github.io/" rel="nofollow">https://shelbyjenkins.github.io/</a>
Honestly I came back to frontend after a few years away and then recently got on next.js project. It seems like this has become the way to build SPA applications ? It feels like a major step backwards - the huge complexity of having frontend split between server/client for very questionable benefits feels entirely not worth it to me. There has to be simpler ways to prerender some basic entry points and leave the rest to frontend. Or just do SSR with partial updates. Don't know maybe I'm getting too old but I see no world in which next.js is the optimal solution or frankly even an improvement over what was going on in frontend a few years ago - feels like a regression.
I'm an HTML & CSS web developer, my skills started in the 2010s with Bootstrap and have (purposely) stayed there. Yes, I know the advantages of React et al. but I have made a nice niche with my deliberately luddite-ish web development style. My brochure-site level business doesn't necessarily need the latest and greatest thing, as long as I don't skimp on security.<p>Until I read about Astro. I'm finally entering the 2020s and just starting to learn Astro. It's a bit daunting with my (intentional) gaps in skills but I'm finding my way.<p>I'm impressed with the speed and SEO capabilities out of the box. Using markdown is nice. And it meshes with the "next new big" thing when the time comes for me to venture out of the stone age. I'm on board.
Nuxt Content v3 is out, not tried it yet, but for those familiar mostly with Vue it looks pretty good: <a href="https://content3.nuxt.dev/" rel="nofollow">https://content3.nuxt.dev/</a>
Could someone give me a quick run down on what Astro is good for please? Looking at the website it seems to cater heavily towards "marketing sites, blogs, e-commerce websites". I'm wondering if this is reflected in the design and dev experience or if it could be used for "generic" websites too.
I recently evaluated web tech stacks and my thesis is that Next.js is the most powerful and will win in the long run, but right now it's a bit too new for most web projects -- the ones that are low-traffic, simple apps. Migrating your codebase to another version is just not that fun, and I deemed that still too common in Next.js
I feel like astro needs some light state event handling. While building my site recently I wanted to filter & sort some lists and I either had to add in react or something or do a bunch of wrangling manually on the html.
I think that this recent post makes a nice accompaniment to TFA: <a href="https://news.ycombinator.com/item?id=42279172">https://news.ycombinator.com/item?id=42279172</a>
I also work at a startup that switched from Next.js to Astro.js.<p>It was around the time of Next.js 12 -> 13 transition. The overall DX was really bad for us when 13 came out and we had struggled with integrating some third party libraries with 12 (Algolia) and decided to move on.<p>If you look at who's using Next.js, you'll see dotcoms like Target.com and Walmart.com are both on Next.js as well as many big name e-commerce retailers. That should tell you about the target audience for Next.js. If you balk at using SAP, Oracle, SharePoint, Teams, or Documentum, then you probably shouldn't use Next.js either.
I've been getting into React recently, because of entgo and relay on the server.<p>React with vite for SPA/PWA is lovely.<p>React as a SSR with Next is a nightmare, because next auth.<p>Graphql with GLUID aka Relay is awesome. React-oidc-context is awesome. It's all a joy to work with.<p>Today I tried remix with remix auth.
I have to manually check token expiration, do refresh, decode the jwt, can't seem to have optional auth routes it's all or nothing.<p>I haven't tried Astro. And the article ended when it came to the "juicy bits" aka the interesting stuff.<p>I tried Svelte with Houdini. Compared to React Svelte is so barebones. You have to do everything on your own, I mean compared it's just less comfortable, less developed, but it has come a long way, no denying that. Houdini in theory was great but in praxis, it can't do "on Query" fragments and the maintainer or developer didn't help, so I abandoned the project with Svelte kit and Houdini. I even added a repo for him to look at, just a link to the docs about fragments and nothing else. Yeah but on Query fragments are also a part of the Graphql spec. Ah well.<p>Apollo, last time I used it, it was complicated, maybe it's different now that I have finished one project with Relay and understand more.<p>Idk what graphql thing exists for Astro. I won't read the followup posts because I'll forget about it.<p>So yeah, quite useless article tbh, no offense
Yeah, and we switched from all these meta frameworks that change their mind and get rewritten every Tuesday into using real full stack batteries included frameworks and then use React through Inertia.js.<p>Best of both worlds, and a stable and proven foundation to build on top of.<p>I don’t trust any of these meta frameworks anymore.
For all of the JavaScript frameworks/libraries/toolchains that were supposed to solve front-end development woes, we could have had a language that actually did that.