> What we planned to release as Remix v3 is now going to be released as React Router v7.
As someone who likes Remix, I would also be interested in learning why OpenAI made that switch
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.
I'm just now getting up and running with Cursor though.
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.
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
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).
Too new? It's 8 years old!
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.
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?
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.
Most app router applications can't handle something as simple as a timed out server function.
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).
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.
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.
We use it at work with a Rails backend, and we are about to start a new project with an Adonis.js backend.
Give it a try. It’s the best way to use React, by far.
Can someone that has used Astro and an older static site generator framework explain the pros/cons of Astro in that context?
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.
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).
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.
They also have a good doc on their page
https://docs.astro.build/en/concepts/why-astro/#content-driv...
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.
Page speed and SEO scores for astro sites are off the charts.
And Bolt.new and Cursor do really well with it.
You may be interested in Observable Framework [0]
If you aren't using it for SSR/SSG then you probably don't need it. If you are writing a really dynamic app with a few thousand users you probably don't need it. It is crazy good for blending dynamic/static pages together, preloading data for page responsiveness and making dependency management less of a nightmare. Things like e-commerce are where it really shines because it can blend thousands of cached SSG product pages with dynamic elements and data in a relatively straightforward way.
I would not recommend it for any project where you are going to have fairly few static pages and relatively few users, it isn't worth the complexity.
Even the devs involved don't have their heads around what they've built, considering responses in github issues.
Genuinely curious.
Would below be examples you were thinking of:
https://stackoverflow.com/questions/1022560/subtle-differenc...
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.
They were security nightmares.
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.
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.
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.
It is called HTMX and its successor data-star.dev
Jfc, it hasn't been a year yet.
htmx generalizes hypermedia controls, and that's all it will do, forever
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...
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.
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.
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.
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.
We switched from Astro to SkibidiJS
I understand what you're saying, people framework hop and what's popular does change frequently, but we're not all using Frontpage still, are we? That process of changing to something better (as evidenced by TFA) has value in itself.
That's exactly the Turing tarpit argument.
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.
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.
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.
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.
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 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...
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.
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.
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
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.
https://astro.build/blog/astro-5/#server-islands
So you can mix static rendered along with server side rendering pieces and get the benefits of both.
Also it's frontend framework agnostic and you can mix and match.
So you can have a dynamic react component, with a static Astro component, svelte component all in the same page on theory.
https://docs.astro.build/en/concepts/islands/
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.