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.
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.
seriously Google probably put a couple billion person-hours just into V8 optimizations, we could have just had a language that makes sense, is efficient, and doesn't have endless footguns.
Probably not billions. Each person (at a 40-hour workweek) works about 2000 hours a year. V8 has been around for about 16 years. 1 billion hours would mean (1 billion / (16*2000)) = 31,250 people full-time on V8 optimization. A google search seems to suggest that the actual headcount for the full V8 team (not just the optimization team) is probably in the 3-digits.
Huh, well, clearly that's impossible. It was first released in 2008, and I'm still an 18-year-old with a full head of hair, faith in humanity, and hope for the future, so it can only have been around for a year or two at most.
A few years ago before ES2015 sure. But JavaScript has come a long way, it’s a much more pleasant language to work with nowadays. Typescript also plays a strong role with that. Lua used to be marginally better than JS, now JS is better and it’s not even close. Also Lua metatables suck.
I don't think both things compare well: optimizations are a clear target for software and computer science professionals while languages add a personal preference: I love Python but don't like C++ while I prefer Rust over Go.
The evolution is Gleam + Lustre (its main FE framework).
You get all of Gleam's advantages compared to TS (simple, truly type safe, errors as values, exhaustive match, etc), and Lustre is great because you get an Elm that can be run on both the client and server, using whatever fits that specific part of your website best (unlike HTMX or LiveView which are server-only).
The reason why there's churn in the web ecosystem isn't because Javascript is missing some minor syntax changes that Python has. It's because UI development is a constant workshop for discovering better abstractions, particularly in bridging the gap between server and client-side code in the browser.
Personally, I think the real problem with the web ecosystem is HTML. HTML is for printed documents as web "pages," literally. It even has <figure> which is for "fig. 1" kind of things.
HTML is so bad that we NEED Javascript because CSS isn't enough. For example, there is no way to define a layout in HTML for different screen sizes and then SEPARATELY define the content of that layout. Nor is there a way to define in HTML that a div should jump from one part of the screen to another if there isn't enough space. We spent years telling the lie that we're supposed to split semantics and presentation, but in reality CSS simply doesn't provide enough power to actually ignore the structure, since you can't tell div1 to align itself to div2 if div2 isn't an ancestor or sibling of div1. Now every website looks extremely simple because if they made it even a tiny bit more complicated it would be impossible to make the flexboxes wrap right with just CSS.
Well, we "need" Javascript because it provides programming capabilities that HTML, being a markup language, cannot provide on its own. HTML is just the substrate for representing the UI.
All you would be doing is creating another programming language while taking another swing at coming up with yet another abstraction for UI dev like everyone before you.
Not really HTML2. Almost all current UI engines uses an xml variant, and they have a much lower number of components and a simpler foundation. And they provide you with a easy-to-use 2d context when you need to do custom components. What we need are better primitives for web applications. And separated from the web as documents.
data-star isn't a successor to htmx, it's a pretty different take on hypermedia, using SSE for a streaming, dynamic hypermedia driven system. cool, definitely capable, but significantly different
htmx generalizes hypermedia controls, and that's all it will do, forever
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.
> 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.
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.
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 (https://gohugo.io/), but I'm starting to tire of the magic and gotchas I keep running into.
Can someone that has used Astro and an older static site generator framework explain the pros/cons of Astro in that context?
Next.js is like what you'd get if you didn't want to use Angular because it's not "cool", only you took the guy in the back of the class who spent all day smoking weed, pumped him full of Ritalin then told him he'd only get his weed back if he designed a new javascript framework.
Only said dude also happened to be the son of the CEO so everyone was forced to use it and a large marketing team would be put together and bankrolled to make everyone else use it.
It's not that Angular isn't cool, it's not productive and very cumbersome.
Rxjs gets in the way and ngrx has too much boilerplate.
It's for large teams and companies that can afford to move slowly.
It depends on what you're doing. When I've used Angular I generated a lot of that boilerplate which reduced a lot of friction between frontend/backend.
If you can't do that then taking a simple approach (pulling in the libraries you need) makes more sense
My experience with Next.js is that it's an order of magnitude slower than Angular and makes it very easy to make massive security blunders (I have more than once found developers accidentality sending secrets to the browser).
I think Astro enables component based architecture and higher interactivity than a typical static site generator. This is sometimes easier to manage complex designs, and or when working with bigger development teams.
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.
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.
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.
Only Ruby-on-Rails was kinda good for some time. Next.js is one of those frameworks which put all of their stat points in Thought Leader Marketing and none in solving problems.
I would argue that Next.js pre app router was a solid and helpful framework for rendering React components on the server side (as long as your setup wasn’t too complex or you were using their own hosting service anyway). But in the recent years they really seem to have screwed up the ease of use and reliability. Nowadays, I wouldn’t recommend Next.js to anyone anymore.
What would you recommend? I’m building a fairly complex app with lots of state management. Next seems to be a good way to go, but I’d be interested if there are any better alternatives.
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.
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.
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.
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.
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.
You could still decide to do SSR by "wrapping" your Vite project in Astro. Astro is basically "just" a wrapper around Vite with additional support for executing code (Astro files) server-side and some other neat features.
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.
1. Wire up a route in your index.server.js file (the main app startup file). That calls to a res.render() function that receives the component you want to render.
2. When that route is hit, send the HTML/CSS/JS to the client and auto-hydrate in the browser (no need for developer to hand-write that), let the client-side do the rest.
Rinse and repeat for moving between routes. No client-side slop, just one easy to understand source of truth on the server.
There's (sadly) been a chase in the JS world to cram everything into the browser but you really don't need to. The above is insanely productive and stable, yet a lot of people I talk to about it poo-poo it (or at best, seem disinterested).
I'd say that depends on the complexity of the page but yeah, it is a real possibility. What tools like Astro (and also the recent Vue 3.5) provide here is an escape hatch in the form of opportunistic/lazy hydration and rendering. Just yesterday I shaved 200ms off of my hydration time by converting a Vue component to an async component that gets hydrated upon interaction.
Nuxt.js felt pretty straightforward to me, with a few minor hiccups. Haven't revisited Next in a while, but it seemed a bit overblown at the time and now. I think people just glob on to whatever their influencer of choice is doing much of the time.
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.
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.
I've just spent past week building a medium complex web app for editing configs at $work, so I can chime on this.
Having worked with earlier versions of sveltekit in the past, I have to say the new reactivity system is not that bad and pretty easy to wrap your head around. Once you're used to the runes (there's like 4 you have to remember) you can just focus on building stuff and it's really quite a pleasant and productive dev experience. I've gotten multiple compliments from people about the speed and quality I was able to deliver this with and that's in large part due to sveltekit.
I do have to give a shout out to good ol' bootstrap for allowing me to build something that looks good, works on mobile and is just easy.
I've been working with svelte 5, and to be honest, I was also quite put off initially by the change in syntax. Over time though I feel like the changes are quite intuitive and helps remove a lot of complexity especially with stores etc. (Also thank god svelte 5 is cross comaptible with svelte 4)
> Next, Nuxt, and SvelteKit are built with complex, runtime browser rendering engines — a massive overhead for content-driven websites with minimal interactive elements.
This 100%. I just don't understand why all modern frameworks aren't doing islands by now.
Sending, parsing, and executing JS for non interactive components is a massive waste.
I'm not very familiar with Nuxt or SvelteKit but this is exactly what React and NextJS provide with server components. Any JS related to server components isn't shipped, only client components which effectively represent the islands. The only real difference is you're not mixing technologies, it's all React.
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]
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.
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.
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.
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.
What I like about Astro is the same as you, but coming from the opposite side. Day job is writing interactive web apps in react. When making some more static web pages on the side, it feels too much to use react and go the SPA route, especially if it should just be fast and easy to load, and friendly for search engine to crawl. But writing plain html&js makes me miss components for all the reusable parts, or whenever I want some small interactivity (like wanting to add a filter to a large list) it's nice to use what I know, and render it during build time, but possibly ship the components themselves to the browser for interactivity.
I think the work being put to modernize it is showing results, but it needs to catch up in a few areas. Integrating Vite on it would go a long way, even if their syntax for dynamic imports stops being supported in the browser.
I still believe it's a very productive framework for building a B2B SPA with Node.js. It has an accounts system built-in. Reactivity just works and it's also built-in, and IMO it's way more useful for a SPA with a modest amount of users than SSR.
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
There are many older codebases running those well-established frameworks, but a lot of job positions, new code, and I bet half the recent YC batch web apps, are Next.js. JSX for frontend is so much better than the other templates imo
There are trends and vibes and Next.js winning. Will it be the thing we will use in three years? Who knows, but I would not necessarily bet on it, because all those technologies eventually are replaced by something else.
Next.js in particular is well known already at this point that some people are intentionally choosing not to use it (because they ran into some of the challenges at their previous company).
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.
You can just sprinkle in some <script> tags and not have to rely on UI frameworks. I appreciate that Astro let's you do this rather than invent it's own way of doing things.
I also work at a startup that switched from Next.js to Astro.js.
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.
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.
But Astro.js is being used by Ikea, plus a number of other e-commerce retailers.
These large companies use all kinds of tech across a huge number of projects. I hardly see how that can really be taken as a signal of the target audience. Most of these companies are using React in some capacity, so does that fall into the same category?
We're building an e-commerce retailer platform optimized for SEO so it makes sense for us since the objectives are the same.
I also wouldn't compare an Ikea to a Walmart or a Target. The latter surface massive catalogs that span multiple brands. Ikea is no small startup, but I don't put them at the same scale as Walmart and Target in terms of e-commerce.
For anyone else that wants to use React (I also advise against this), I'd personally recommend a React Vite SPA.
I've been getting into React recently, because of entgo and relay on the server.
React with vite for SPA/PWA is lovely.
React as a SSR with Next is a nightmare, because next auth.
Graphql with GLUID aka Relay is awesome. React-oidc-context is awesome. It's all a joy to work with.
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.
I haven't tried Astro. And the article ended when it came to the "juicy bits" aka the interesting stuff.
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.
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.
Idk what graphql thing exists for Astro. I won't read the followup posts because I'll forget about it.
I really like Astro:
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.
The docs are soooo good.
Page speed and SEO scores for astro sites are off the charts.
And Bolt.new and Cursor do really well with it.
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.
seriously Google probably put a couple billion person-hours just into V8 optimizations, we could have just had a language that makes sense, is efficient, and doesn't have endless footguns.
That's precisely what the creator of V8 did; he created Dart. See the context from munificent, who currently works on Dart:
https://news.ycombinator.com/item?id=33524437
That would just end up being another Adobe Flash which one company controls. Always bet on web standards.
Probably not billions. Each person (at a 40-hour workweek) works about 2000 hours a year. V8 has been around for about 16 years. 1 billion hours would mean (1 billion / (16*2000)) = 31,250 people full-time on V8 optimization. A google search seems to suggest that the actual headcount for the full V8 team (not just the optimization team) is probably in the 3-digits.
> V8 has been around for about 16 years.
Huh, well, clearly that's impossible. It was first released in 2008, and I'm still an 18-year-old with a full head of hair, faith in humanity, and hope for the future, so it can only have been around for a year or two at most.
Lua would be a strong contender.
A few years ago before ES2015 sure. But JavaScript has come a long way, it’s a much more pleasant language to work with nowadays. Typescript also plays a strong role with that. Lua used to be marginally better than JS, now JS is better and it’s not even close. Also Lua metatables suck.
Would you mind giving examples of why.
Genuinely curious.
Would below be examples you were thinking of:
https://stackoverflow.com/questions/1022560/subtle-differenc...
I think a lot of people would reject any dynamically typed language at this stage.
I don't think both things compare well: optimizations are a clear target for software and computer science professionals while languages add a personal preference: I love Python but don't like C++ while I prefer Rust over Go.
Elm was a pretty noble attempt—all things considered.
The evolution is Gleam + Lustre (its main FE framework).
You get all of Gleam's advantages compared to TS (simple, truly type safe, errors as values, exhaustive match, etc), and Lustre is great because you get an Elm that can be run on both the client and server, using whatever fits that specific part of your website best (unlike HTMX or LiveView which are server-only).
Wrote a blog post about it:
https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...
Does Elm support SSR?
Elixir
Imagine the world if <script type="text/python">
The reason why there's churn in the web ecosystem isn't because Javascript is missing some minor syntax changes that Python has. It's because UI development is a constant workshop for discovering better abstractions, particularly in bridging the gap between server and client-side code in the browser.
Personally, I think the real problem with the web ecosystem is HTML. HTML is for printed documents as web "pages," literally. It even has <figure> which is for "fig. 1" kind of things.
HTML is so bad that we NEED Javascript because CSS isn't enough. For example, there is no way to define a layout in HTML for different screen sizes and then SEPARATELY define the content of that layout. Nor is there a way to define in HTML that a div should jump from one part of the screen to another if there isn't enough space. We spent years telling the lie that we're supposed to split semantics and presentation, but in reality CSS simply doesn't provide enough power to actually ignore the structure, since you can't tell div1 to align itself to div2 if div2 isn't an ancestor or sibling of div1. Now every website looks extremely simple because if they made it even a tiny bit more complicated it would be impossible to make the flexboxes wrap right with just CSS.
We need HTML2.
Well, we "need" Javascript because it provides programming capabilities that HTML, being a markup language, cannot provide on its own. HTML is just the substrate for representing the UI.
All you would be doing is creating another programming language while taking another swing at coming up with yet another abstraction for UI dev like everyone before you.
We don't need another version of HyperText Markup Language.
We need something else. I don't know what it is, but another way to markup text doesn't sound like a great fit for a new way to build user interfaces.
Not really HTML2. Almost all current UI engines uses an xml variant, and they have a much lower number of components and a simpler foundation. And they provide you with a easy-to-use 2d context when you need to do custom components. What we need are better primitives for web applications. And separated from the web as documents.
It kind of exists.... as a js library - ofc.... Who would have thought.
It is called HTMX and its successor data-star.dev
HTMX addresses none of the issues GP mentioned.
... I was listening to a podcast about HTMX as a new thing to take a look at this last summer, and there's already a successor to it?
Jfc, it hasn't been a year yet.
data-star isn't a successor to htmx, it's a pretty different take on hypermedia, using SSE for a streaming, dynamic hypermedia driven system. cool, definitely capable, but significantly different
htmx generalizes hypermedia controls, and that's all it will do, forever
That's much scarier to me.
Okay, what if we just use Java instead of Java"script"?
Java applets were a thing. Emphasis on "were"
They were security nightmares.
Now you are just crazy
I can relate to the complexity fatigue.
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.
(12 months from now)
We switched from Astro to SkibidiJS
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.
Yes there's value in changing to something better. The frequency of change is the real issue here.
"better" is just fashion nowadays. There's nothing astro does that NextJs can't. Worked with both and still work with both.
> There's nothing astro does that NextJs can't.
That's exactly the Turing tarpit argument.
When was the last time datocms changed?
The Nextjs site lasted 4 years. Before that we had a Gatsby one: https://github.com/datocms/old-website/
A 4-year lifespan for a marketing website doesn't seem so bad
> 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.
Or more like: to AIJS, which automatically rewrites your site to the latest trendy framework. :-)
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.
Remix is getting renamed and merged into React Router.
I am confused because I was mostly able to replicate Remix 2 functionality in React-Router v7. What would Remix add to that?
If you create a vite project with rr7 and a new remix project, it's the same project that gets created
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.
[dead]
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.
You can't even become a next.js expert because it is constantly changing.
Even the devs involved don't have their heads around what they've built, considering responses in github issues.
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.
[1] http://kamal-deploy.org
From Datocms here :) We are also actively experimenting on porting our main app. We are doing progress, so far so good!
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 (https://gohugo.io/), but I'm starting to tire of the magic and gotchas I keep running into.
Can someone that has used Astro and an older static site generator framework explain the pros/cons of Astro in that context?
Next.js is like what you'd get if you didn't want to use Angular because it's not "cool", only you took the guy in the back of the class who spent all day smoking weed, pumped him full of Ritalin then told him he'd only get his weed back if he designed a new javascript framework.
Only said dude also happened to be the son of the CEO so everyone was forced to use it and a large marketing team would be put together and bankrolled to make everyone else use it.
It's not that Angular isn't cool, it's not productive and very cumbersome. Rxjs gets in the way and ngrx has too much boilerplate. It's for large teams and companies that can afford to move slowly.
It depends on what you're doing. When I've used Angular I generated a lot of that boilerplate which reduced a lot of friction between frontend/backend.
If you can't do that then taking a simple approach (pulling in the libraries you need) makes more sense
My experience with Next.js is that it's an order of magnitude slower than Angular and makes it very easy to make massive security blunders (I have more than once found developers accidentality sending secrets to the browser).
I think Astro enables component based architecture and higher interactivity than a typical static site generator. This is sometimes easier to manage complex designs, and or when working with bigger development teams.
They also have a good doc on their page
https://docs.astro.build/en/concepts/why-astro/#content-driv...
any recommendations for themes in astro? i want following landing page+blog+docs with toc and related content.
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.
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.
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.
Only Ruby-on-Rails was kinda good for some time. Next.js is one of those frameworks which put all of their stat points in Thought Leader Marketing and none in solving problems.
I would argue that Next.js pre app router was a solid and helpful framework for rendering React components on the server side (as long as your setup wasn’t too complex or you were using their own hosting service anyway). But in the recent years they really seem to have screwed up the ease of use and reliability. Nowadays, I wouldn’t recommend Next.js to anyone anymore.
What would you recommend? I’m building a fairly complex app with lots of state management. Next seems to be a good way to go, but I’d be interested if there are any better alternatives.
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.
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.
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.
But that's so ugh. Templates and the endless helper functions. No interactivity, all the if else blocks. No just no, not again.
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.
That should definitely not be the case. Did you compile it with a different edition, or different 3rd party dependency major versions, perhaps?
Thanks for the warning! I’ve been meaning to check it out.
the technical blogpost i'm really waiting with bated breath for is "We switched from Next.js to Remix (and why)" from chatgpt.com
Rejoice, as Remix effectively no longer exists (it’s now all react-router) you won’t get that slop article :)
I know it's just branding, but I think it's the other way around: react-router is now all remix.
I suppose it depends on framing, but as I understand it in a few years there will be no “remix” as it’s all absorbed by “react-router”.
Interesting, this does indeed seem to be the case:
> What we planned to release as Remix v3 is now going to be released as React Router v7.
https://remix.run/blog/merging-remix-and-react-router
Yeah that migration came out from the left field.
As someone who likes Remix, I would also be interested in learning why OpenAI made that switch
ive talked to them offline about it and they have promised a writeup is coming. will try to get a podcast too
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.
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.
You could still decide to do SSR by "wrapping" your Vite project in Astro. Astro is basically "just" a wrapper around Vite with additional support for executing code (Astro files) server-side and some other neat features.
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.
The way I do it in my framework [1]:
1. Wire up a route in your index.server.js file (the main app startup file). That calls to a res.render() function that receives the component you want to render.
2. When that route is hit, send the HTML/CSS/JS to the client and auto-hydrate in the browser (no need for developer to hand-write that), let the client-side do the rest.
Rinse and repeat for moving between routes. No client-side slop, just one easy to understand source of truth on the server.
There's (sadly) been a chase in the JS world to cram everything into the browser but you really don't need to. The above is insanely productive and stable, yet a lot of people I talk to about it poo-poo it (or at best, seem disinterested).
[1] https://cheatcode.co/joystick
The issue with that approach to hydration is that it causes the browser to freeze.
I'd say that depends on the complexity of the page but yeah, it is a real possibility. What tools like Astro (and also the recent Vue 3.5) provide here is an escape hatch in the form of opportunistic/lazy hydration and rendering. Just yesterday I shaved 200ms off of my hydration time by converting a Vue component to an async component that gets hydrated upon interaction.
I've yet to see it with a wide range of sites. If you're getting browser freeze, something is wrong with your actual JS, not the framework.
In the case of Joystick, because it's sending SSR'd HTML to the browser automatically, you typically don't even see the hydration take place.
Nuxt.js felt pretty straightforward to me, with a few minor hiccups. Haven't revisited Next in a while, but it seemed a bit overblown at the time and now. I think people just glob on to whatever their influencer of choice is doing much of the time.
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.
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.
Have you looked at svelte 5 yet? Still happy with Svelte?
https://svelte.dev/docs/svelte/v5-migration-guide
I've just spent past week building a medium complex web app for editing configs at $work, so I can chime on this.
Having worked with earlier versions of sveltekit in the past, I have to say the new reactivity system is not that bad and pretty easy to wrap your head around. Once you're used to the runes (there's like 4 you have to remember) you can just focus on building stuff and it's really quite a pleasant and productive dev experience. I've gotten multiple compliments from people about the speed and quality I was able to deliver this with and that's in large part due to sveltekit.
I do have to give a shout out to good ol' bootstrap for allowing me to build something that looks good, works on mobile and is just easy.
I've been working with svelte 5, and to be honest, I was also quite put off initially by the change in syntax. Over time though I feel like the changes are quite intuitive and helps remove a lot of complexity especially with stores etc. (Also thank god svelte 5 is cross comaptible with svelte 4)
> Next, Nuxt, and SvelteKit are built with complex, runtime browser rendering engines — a massive overhead for content-driven websites with minimal interactive elements.
This 100%. I just don't understand why all modern frameworks aren't doing islands by now.
Sending, parsing, and executing JS for non interactive components is a massive waste.
I'm not very familiar with Nuxt or SvelteKit but this is exactly what React and NextJS provide with server components. Any JS related to server components isn't shipped, only client components which effectively represent the islands. The only real difference is you're not mixing technologies, it's all React.
Thanks. I wasn't aware Next had already shipped RSC support.
Yeah I also don’t think this is correct for SvelteKit.
Astro is simple and nice.
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]
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.
[1] https://github.com/easy-astro-blog-creator/easy-astro-blog-c...
[2] https://shelbyjenkins.github.io/
Nuxt Content v3 is out, not tried it yet, but for those familiar mostly with Vue it looks pretty good: https://content3.nuxt.dev/
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.
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.
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.
Out of curiosity, do you hand-code or do you use a tool like Bootstrap Studio?
By hand but in VS Code, autocomplete does a lot.
I'm just now getting up and running with Cursor though.
What I like about Astro is the same as you, but coming from the opposite side. Day job is writing interactive web apps in react. When making some more static web pages on the side, it feels too much to use react and go the SPA route, especially if it should just be fast and easy to load, and friendly for search engine to crawl. But writing plain html&js makes me miss components for all the reusable parts, or whenever I want some small interactivity (like wanting to add a filter to a large list) it's nice to use what I know, and render it during build time, but possibly ship the components themselves to the browser for interactivity.
Remember Meteor?
They just had a new release a few days ago: https://dev.to/meteor/meteorjs-31-a-new-dawn-for-full-stack-...
I think the work being put to modernize it is showing results, but it needs to catch up in a few areas. Integrating Vite on it would go a long way, even if their syntax for dynamic imports stops being supported in the browser.
I still believe it's a very productive framework for building a B2B SPA with Node.js. It has an accounts system built-in. Reactivity just works and it's also built-in, and IMO it's way more useful for a SPA with a modest amount of users than SSR.
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
> but right now it's a bit too new
Too new? It's 8 years old!
Next.js is already winning: https://trends.stackoverflow.co/?tags=next.js,ruby-on-rails,...
There are many older codebases running those well-established frameworks, but a lot of job positions, new code, and I bet half the recent YC batch web apps, are Next.js. JSX for frontend is so much better than the other templates imo
There are trends and vibes and Next.js winning. Will it be the thing we will use in three years? Who knows, but I would not necessarily bet on it, because all those technologies eventually are replaced by something else.
Next.js in particular is well known already at this point that some people are intentionally choosing not to use it (because they ran into some of the challenges at their previous company).
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.
You can just sprinkle in some <script> tags and not have to rely on UI frameworks. I appreciate that Astro let's you do this rather than invent it's own way of doing things.
I think that this recent post makes a nice accompaniment to TFA: https://news.ycombinator.com/item?id=42279172
I also work at a startup that switched from Next.js to Astro.js.
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.
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.
But Astro.js is being used by Ikea, plus a number of other e-commerce retailers.
These large companies use all kinds of tech across a huge number of projects. I hardly see how that can really be taken as a signal of the target audience. Most of these companies are using React in some capacity, so does that fall into the same category?
We're building an e-commerce retailer platform optimized for SEO so it makes sense for us since the objectives are the same.
I also wouldn't compare an Ikea to a Walmart or a Target. The latter surface massive catalogs that span multiple brands. Ikea is no small startup, but I don't put them at the same scale as Walmart and Target in terms of e-commerce.
For anyone else that wants to use React (I also advise against this), I'd personally recommend a React Vite SPA.
This is refreshing as I just built a website using astro with dato
I've been getting into React recently, because of entgo and relay on the server.
React with vite for SPA/PWA is lovely.
React as a SSR with Next is a nightmare, because next auth.
Graphql with GLUID aka Relay is awesome. React-oidc-context is awesome. It's all a joy to work with.
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.
I haven't tried Astro. And the article ended when it came to the "juicy bits" aka the interesting stuff.
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.
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.
Idk what graphql thing exists for Astro. I won't read the followup posts because I'll forget about it.
So yeah, quite useless article tbh, no offense
[dead]
I hope I will never have to write Server-Side generated application. I left PHP and Ruby a long time ago, and I don't miss this madness.
Everyone has their own preference. Here it's exactly the other way around :-)