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.
If there's anything Rust takes seriously, it's backward compatibility, so something is definitely wrong with the parent commenter's situation, the code should compile as Rust explicitly lists as one of its main goals the ability to compile code from any Rust version, indefinitely.
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.
It can do SSG while letting you use any framework you want. You don't need to use React. That's a pretty big difference in a thread where people complain about churn.
Personally, I don't see Astro as a must have because SSR + Interactivity can be done with a lot of tech. PHP, C#, etc. But it has a lot of sane defaults around markdown and static generation that I can recommend it.
> 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.
Will WordPress be there in 5 years? Regardless, it has a cost.
It's hard to compound a conversation about cost on the backdrop of agencies. A lifetime ago I worked at agencies that predominantly leaned on WordPress. WP is a complex, dynamic webapp, running 24/7. A long history of security holes both in itself but more in the fleet of community plugins that agencies install by default, and the "one click" hosting software they lean on (cpanel et al) to avoid hiring actual operations teams all cause problems. Deployments are objectively awful and demand scrappy maintenance work over an amount of regular server time.
Once a static Astro site is built, that HTML is static and safe, forever. Cloudflare, AWS, Github, and a hundred others will host it for you, for free. Just pay for the domain.
We charged clients £100pm+ just for treading water with WP and there wasn't profit in that. WP does allow clients to make changes themselves but in my experience agency clients need brand and graphics support. The cost of updating a website is insignificant to regular graphics work.
I can't say what sort of client you are, but we're looking at a cost saving of £6k in five years by not having some underqualified junior babysit a server.
The output is better on Astro too. Usually. I'm sure an agency could find a way to make an awful Astro site.
> Will WordPress be there in 5 years? Regardless, it has a cost.
WordPress will probably be around in 5 years, but I don't think anyone can say that the plugin ecosystem and open source community that WordPress heavily depends on would, especially with what has been going on in the past months.
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.
> 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.
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.
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).
What are you asserting that Angular is doing so special that it specifically prevents sending secrets to the browser in a way that NextJS doesn't already, or couldn't equivalently do?
Next.js combined code which runs on client and server into one thing, by default, then uses a naming convention to avoid disaster to avoid disaster.
That's a massive foot-gun.
Angular, out of the box, is focused on code which runs on the client. Yes you can do some tricks where some code is executed on the server, however the logical model stays the same: it's frontend code. So you wouldn't put tokens which you know belong in a BFF anywhere near it.
It's not just a naming convention it's part of the build/compilation step that will not bundle anything not specifically prefixed for the client, and is safe by default. You have to go out of your way to purposefully prefix an environment value with NEXT_PUBLIC_* to get it into the client bundle. I strongly doubt you've seen anyone screw this up by happenstance, maybe extreme laziness with copy and pasting but even then, the all caps naming requirement that includes "PUBLIC" is a big enough clue that I would consider it malice first.
This is also no worse than literally any SSR tool that's ever existed, going back to the CGI days.
> It's not just a naming convention it's part of the build/compilation
> step that will not bundle anything not specifically prefixed for
> the client, and is safe by default.
Yeah no, it isn't safe-by-default. I caught a frontend team shipping keys in the frontend code. Cause? Typo and using default templates which built-on-deploy.
Can you share a clear example? This still seems like a contrived complaint. How did someone fat finger typing that specific naming requirement prefix?
Or how is leaking a value into a template like that not similarly a risk in Python or a Go backend that renders stuff on the server (like all the HTMX hype). It feels like you're saying that a fat client side SPA is the only answer to anything.
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.
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)
I have looked at it but not updated yet, and I don't think I will.
v5 looks more like React (effect, props), but it still keeps much of the simplicity from Svelte.
I think they wanted to be more explicit so it better supports larger applications with fewer surprises. I don't love the fact that they are creating new abstractions to learn when everyone loved the previous ones, but I can see why they did that.
And I think that I'll still have a pleasant experience with v5, but don't quote me on that.
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.
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.
Just use react.... That's what I do - it is so much easier than trying to fight with Next.js.
I have a large application and I use next.js for the landing pages (landing, tos, privacy, blog, login, etc..) - but for the core application after login, I just use vanilla react with react router. For me I keep these as separate applications as I don't want to load the entire app just for the landing page or login box.
Every time I need to work in the nextjs part of the app I always run into problems and have to read the docs and troubleshoot, sift through which part of the docs apply to my setup versus the app router.
If your entire application needs to be indexed as a static site (e.g. content based versus a web application), then vanilla react isn't a good fit - so it depends on your needs.
Unrelated - but shout out to https://nx.dev. I always prefer using this for all of my projects - made it super easy to have my node backend, react frontend, nextjs landing page, chrome extension, cron jobs, etc.. all in the same codebase where I can share code between all of them via non-publishable libraries.
This approach doesn't work if you need to SSR any of the content of those components.
This is also a terrible solution UX wise. Your users will see some content and after some time (more or less noticeable, depending on resources, network conditions, etc) the rest of the components start to pop up, cause layout shifts and overal jankiness.
You either use and embrace one of these frontend frameworks or you don't and do progressive enhancement using HotWire, Alpine, Unpoly, Livewire or whatever.
The sprinkling of components is the worst of both worlds.
We may be talking about different things. I don't mean that you literally serve it as a static site, I'm illustrating React is just a view library.
The comment you responded to was about not needing NextJS and you said it's impossible to just use React if you need multiple pages or need SSR.
How so? You can have an MPA with React. If you have a server (Even if it's not NextJS) then you can do SSR. Then you can hydrate with React and manipulate as needed. This is what NextJS does.
I didn't interpret the OP to be saying "You don't need a server."
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.
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.
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.
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.
Then for backend stuff it kinda depends on how you deploy it. It could just be a single monolithic server or serverless per API route and probably everything in between.
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.
For sure, but there is room for improvement there. Similar to how the <style> tag has scoping built in. An integrated way to access the data objects directly and a way to reference elements and events would be ergonomic.
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.
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.
Best of both worlds, and a stable and proven foundation to build on top of.
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.
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.
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.
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.
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
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.