I recently learned about Astro.js, which is very attractive:
- It can build a front-end page with zero runtime, and the page performance is very good
- Components compatible with mainstream UI frameworks (such as React, Vue, Svelte, etc.)
- A large number of plug-ins provided by the official and community can save a lot of effort when implementing many common functions (such as i18n, sitemap, etc.)
- Decoupled from the infrastructure, it can be easily configured and deployed to different PaaS (instead of being strongly bound to Vercel like Next.js)
- The code is more straightforward than React, an astro file is a component, no need to define ClassComponent and export
After reading the documentation, I was thinking about it for several days, so I simply tried to rewrite the front end of my blog using Astro. I still encountered various problems during the development process:
- The cost of compatibility with the stock code is not low
Migrating legacy projects to Astro, if you want to achieve the most perfect effect, it must be rewritten in Astro mode with all the code. But I currently maintain more than one Next.js project, and many components are shared, which cannot be rewritten as Astro.
So can I just import React components into Astro pages? For most cases, yes. But some of my pages directly use Next.js's basic components, such as next/image, next/link, next/navigate, etc. These components that are strongly bound to Next.js cannot be imported into Astro. Of course, Astro also provides corresponding components to achieve the same effect, but as mentioned earlier, the original code is publicly shared. For example, if next/image is replaced with Astro's Image component, other projects that depend on this code will not be able to run.
- IDE support is not good enough
I have been using Goland for development and using pnpmworkspace to maintain a monorepo for front-end code. When I added an Astro project to the monorepo, Goland was able to parse .astro files through the Astro plugin. However, Goland could not correctly parse the Typescript syntax in Astro.
After investigation, I found that this situation will occur in monorepo+Typescript mode. I understand that it is because Astro has a relatively small user base and its overall development ecosystem is still not perfect.
https://youtrack.jetbrains.com/issue/WEB-59503 - Limited revenue
After Next.js13, ServerComponent and ClientComponent are clearly distinguished. If it is a pure static page, you only need to use ServerComponent as much as possible to achieve complete SSR, avoid ClientComponent introducing front-end Javascript, and you can also get very good rendering performance. However, on some pages that have to introduce front-end interactive logic, you can also easily convert a page to Client-Side rendering using "useclient".
On the other hand, Astro pursues static page output as much as possible. For some places that need to introduce client-side logic, you need to use script to wrap the original JavaScript code to operate the DOM. For me, who is used to the binding/hook capabilities in React, this is too troublesome. Of course, I can also convert this kind of interactive logic into React components and introduce them into Astro pages as clientonly components, but this will cause the React runtime to be loaded on the front end, which defeats the purpose of using Astro.
Finally gave up this migration, and will not put the Astro version of the project online or maintain it for the time being. But it does not mean that I do not approve of Astro. There are still many sweet spots after using it, but it is not suitable for my current development needs. If it is a brand new, pure static front-end project, it is very suitable to use Astro for development.