We switched from Next.js to Astro (and why it might interest you)(datocms.com)
datocms.com
We switched from Next.js to Astro (and why it might interest you)
https://www.datocms.com/blog/why-we-switched-to-astro
165 comments
> 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
You may be interested in Observable Framework [0]
[0] https://observablehq.com/framework/
You may be interested in Observable Framework [0]
[0] https://observablehq.com/framework/
Yes! I’ve had my eye on it but haven’t had a chance to use it (yet).
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.
Page speed and SEO scores for astro sites are off the charts.
And Bolt.new and Cursor do really well with it.
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.
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.
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.
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.
But that's so ugh. Templates and the endless helper functions. No interactivity, all the if else blocks.
No just no, not again.
SolidJS[1] took the best from React and seems to be quite stable, check it out. It is fairly small and doesn't try to be everything at once.
[1]: https://www.solidjs.com/
[1]: https://www.solidjs.com/
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.
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 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.
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.
Inertia.js
(12 months from now)
We switched from Astro to SkibidiJS
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.
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.
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.
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.
That's exactly the Turing tarpit argument.
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.
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.
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.
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.
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.
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.
My brain has been so fried from working in frontend for several years that I actually googled SkibidiJS before I realized it was a joke.
Or more like: to AIJS, which automatically rewrites your site to the latest trendy framework. :-)
This new stuff is bussing, no cap! Astro is so last year, cringe.
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.
I've recently tried out both React-Router v7 (which is sort Remix 3? it is confusing), and TanStack/Start and found them both to have better developer DX than Next.JS.
React-Router v7 was the simpler of the two and my app had less code as a result, but a little less flexible than TanStack/Start. But both seemed acceptable.
Astro has been recommended so I will try it out next.
We moved to Inertia.js. All our problems with meta frameworks are gone.
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.
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.
Remix is getting renamed and merged into React Router.
This is such a mess.
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.
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.
They did change it with React-Router v7. The built-in file/directory-based routing that was available in Remix 2 is not available in React-Router v7.
That's not true, it is still available [1].
[1] https://reactrouter.com/how-to/file-route-conventions
[1] https://reactrouter.com/how-to/file-route-conventions
I am confused because I was mostly able to replicate Remix 2 functionality in React-Router v7. What would Remix add to that?
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.
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.
Even the devs involved don't have their heads around what they've built, considering responses in github issues.
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
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 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
[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!
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.
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.
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?
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.
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).
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.
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.
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.
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.
They also have a good doc on their page
https://docs.astro.build/en/concepts/why-astro/#content-driv...
They also have a good doc on their page
https://docs.astro.build/en/concepts/why-astro/#content-driv...
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 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
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.
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.
I mean pages router resulted in much more sound applications.
Most app router applications can't handle something as simple as a timed out server function.
Most app router applications can't handle something as simple as a timed out server function.
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.
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.
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.
Except you can't "just use react". Especially if you have more than one page, or you need to do SSR.
? You can serve a public app that is just static files that uses React in some places. It's no different from using JQuery.
> or you need to do SSR.
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.
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."
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."
> Then you can hydrate with React and manipulate as needed. This is what NextJS does.
:facepalm:
Tell me you're a backend developer with little to no experience on this stuff without telling me you're a backend developer.
:facepalm:
Tell me you're a backend developer with little to no experience on this stuff without telling me you're a backend developer.
Inertia.
It's just a thin layer of glue between your frontend (React, Vue, etc) and a real batteries included fullstack framework such as Laravel/Rails/Adonis.
It's just a thin layer of glue between your frontend (React, Vue, etc) and a real batteries included fullstack framework such as Laravel/Rails/Adonis.
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/
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/
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
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.
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.
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
> 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
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.
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.
Nuxt Content v3 is out, not tried it yet, but for those familiar mostly with Vue it looks pretty good: https://content3.nuxt.dev/
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 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.
[deleted]
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.
You can use it for anything especially with its new server islands.
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.
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.
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
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 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).
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).
> but right now it's a bit too new
Too new? It's 8 years old!
Too new? It's 8 years old!
Your thesis isn't very good. Nextjs has a huge marketing budget and that's it
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 love Astro and I’ve tried every SSG. I use it for my personal site.
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.
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?
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 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.
So yeah, quite useless article tbh, no offense
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
This is refreshing as I just built a website using astro with dato
any recommendations for themes in astro? i want following landing page+blog+docs with toc and related content.
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.
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.
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
https://news.ycombinator.com/item?id=33524437
Pretty sure big Google products like Maps are written in Dart, no?
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.
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.
There are two kinds of languages: ones that everyone complains about and ones that no one uses.
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.
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...
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.
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...
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...
Didn’t know… awesome!
Does Elm support SSR?
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.
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.
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.
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.
Whatever it is, it should have a readable plaintext format. Maybe a DSL of sorts.
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
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.
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
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"?
Elixir
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 :-)
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.