Astro is super simple. It's so well documented. I love it. It's documentation is what allowed me to pick it up easily and learn web development terminologies. It really made me fall in love with web development because I could get up and running so quickly.
I like Astro, and I use it often. The docs are very good, but I can see signs of "over reaching"., and I can see how for someone who was not working with it since the beginning it is becoming increasingly complex. It is loosing a bit 8f the pure simplicity it had in the beginning. At some point, it doesn't make sense anymore and you look into Nuxt or Next.
No? You cannot do SPA stuff like Next or Nuxt. You still can do the same stuff you used to do at the beginning. Astro is a competitor for Gatsby, not for Vitepress, Jekyll, Hugo or any other overly pure static site generator.
I've been wondering this for some time as I work on building out with Astro. My main concern with complexity is when a config file is needed. There are for the DB, the Content Collection, and ENV schemas (currently experimental). Astro has put a lot of thought into making everything typesafe so the additional time it takes to learn how to write out these schemas will help development speed up a lot faster down the line. There are a lot of great features coming up to have both worlds of dynamic interactive sites while still being blazingly fast. I'm hoping that as the DB gets more mature we have Ruby on Rails-like commands like scaffolding to speed up development time.
That's a good callout. I was just working on a project today jumping back and forth between several different configs. Thankfully, they're commitment to zod at least makes these all very similar right now. So once you learn the basics, it's fairly straightforward in all locations.
I am often times guilty of this too - but I dislike it when online discussions on web frameworks take the form of "this is too complex" when in reality the underlying complaint seems to be "this is too hard I don't want to learn it" ( I know that you gave a charitable view of someone not wanting to migrate to a newer paradigm )
Agreed…my actual response I posted on Twitter when I saw this included this sentence… "You can build an overly complex project with Astro; you can build a simple project with React, but that’s a design decision." (so I backed down a bit by the time I got to recording a video ha)
Astro has amazing documentation. However when it comes to complexity - Astro scales well in complexity but it can surpass React etc. in complexity, that is when you need to share state across different islands. Just know which framework to use for which purpose.
Agreed on the progressive enhancement points. I've also a few astro projects I haven't touched in a long time and any time I bump dependencies, things just continue to work.
People need to understand that if they want cool features then they need to put effort to learn it. Otherwise best of luck with vanilla JS, CSS and HTML.
@@CodinginPublic I have to go back to docs every so often to clarify things because there is too much magic for example. Images that you mentioned, I struggled to figure that out. I tried integrating few html templates into Astro and it was difficult and it wasn't obvious what the problem is. I like Astro obviously, I like Markdown integration especially because it really makes it easy, but sometimes errors will be that are not clear why, npm packages out of the blue are required. Things like that give me impression that things are way more complex then they should be.
I don't think it's getting too complex to be honest. All of the new features are pretty cool, but so far for me - building static sites and experimenting with different libraries using Astro is still pretty nice, and I can spin something up if I ever have a lightbulb moment in my brain - not a bad way to improve my front-end skills ^^
It's not complex at all. The problem I see is that people jump to adding react etc without taking the time to understand what Astro is and what in can do
I last tried Astro about a year ago and the main thing I didn't like was the custom compiler and editor tooling. It was incredibly buggy and there really is no reason to add proprietary syntax in the first place, jsx gets the job done just fine.
Editor tooling is exactly the biggest problem right now. I use neovim and in one of my projects and the lsp just kinda stops working at one point... if I want to continue work i have to restart neovim
Astro has a lot of "things" that can make it look complex. If you want to optimize images you have to import them in a page so an article will have frontmatter, imports then content. Never seen this before. Then collections are for markdown, JSON, not for HTML so it's more for coded apps, with specific content structure and not for more plain static sites. JSX inspiration makes templating look odd for people used to templating systems used on the backend or frontend ones inspired by Jinja. The templates are also lacking blocks structures and the frontmatter has to be passed manually through templates inheritance tree and the API differs between markdown or .astro HTML page. Writing HTML articles would require using .astro files which can interpret some of the content as invalid JS/template syntax and break/require escaping. I would say it's for node developers not for "outside" fullstacks/webdevs. ViewTransitions are already supported by modern browsers, so no need for Astro stuff.
Bro, is there no demand for frontend development because now the company's are hiring frontend developers with AI and in the next 2 years frontend development jobs will be completely eliminated.
I have the opposite experience. I worked with NextJS for several years. But at the beginning of the year I tried Astro and since then I can't even see NextJS and I'm trying to migrate all my web projects to Astro as soon as possible.
The problem with Astro is the same problem that Sveltekit and Nextjs has that is the build system is too complex and gets slow really quick as the app grows I had one documentation app in Astro and it got 15 seconds to compile and after some time it stop working on production with a circular reference, but in development the problem did not exist at app, so I decided to drop it
@@CodinginPublic It will very likely has some scalability problems, but the problem about build complexity is that sometimes because it has many layers of build step it is really difficult to fix and debug Just to understand, if a build bug happens, how do you know it is related to esbuild, vite SSR, the astro compiler? And it is only in the frontend or in the backend? In my case it only happens in production and in the frontend In relation to features, the Astro team is incredible, they deliver many quality stuff really quick
Astro is super simple. It's so well documented. I love it. It's documentation is what allowed me to pick it up easily and learn web development terminologies. It really made me fall in love with web development because I could get up and running so quickly.
Can’t agree enough with the quality of the docs. Just absolutely the best. They make me hate all other docs ha.
I like Astro, and I use it often. The docs are very good, but I can see signs of "over reaching"., and I can see how for someone who was not working with it since the beginning it is becoming increasingly complex. It is loosing a bit 8f the pure simplicity it had in the beginning. At some point, it doesn't make sense anymore and you look into Nuxt or Next.
I think it’s possible it gets that way, but feels simple compared to Next/Nuxt. I do think they need to be careful though.
No? You cannot do SPA stuff like Next or Nuxt. You still can do the same stuff you used to do at the beginning. Astro is a competitor for Gatsby, not for Vitepress, Jekyll, Hugo or any other overly pure static site generator.
I've been wondering this for some time as I work on building out with Astro. My main concern with complexity is when a config file is needed. There are for the DB, the Content Collection, and ENV schemas (currently experimental). Astro has put a lot of thought into making everything typesafe so the additional time it takes to learn how to write out these schemas will help development speed up a lot faster down the line. There are a lot of great features coming up to have both worlds of dynamic interactive sites while still being blazingly fast. I'm hoping that as the DB gets more mature we have Ruby on Rails-like commands like scaffolding to speed up development time.
That's a good callout. I was just working on a project today jumping back and forth between several different configs. Thankfully, they're commitment to zod at least makes these all very similar right now. So once you learn the basics, it's fairly straightforward in all locations.
if Astro is too complicated Drupal is a Satan Hell with gun point on my head
lol
Amazing summary! I‘m just getting started with Astro so I hope I will stay as simple as it is right now.
Glad you found it useful! Astro is 🔥 and I really trust the maintainers. Hoping they stay the course!
I am often times guilty of this too - but I dislike it when online discussions on web frameworks take the form of "this is too complex" when in reality the underlying complaint seems to be "this is too hard I don't want to learn it" ( I know that you gave a charitable view of someone not wanting to migrate to a newer paradigm )
Agreed…my actual response I posted on Twitter when I saw this included this sentence… "You can build an overly complex project with Astro; you can build a simple project with React, but that’s a design decision." (so I backed down a bit by the time I got to recording a video ha)
Astro has amazing documentation. However when it comes to complexity - Astro scales well in complexity but it can surpass React etc. in complexity, that is when you need to share state across different islands. Just know which framework to use for which purpose.
Well said.
The only thing i don’t like in Astro is file based routing when using i18n and not having simple way to rename i18n routes
I could be wrong, but I think they added this option in a config recently? I can't remember off hand though.
Agreed on the progressive enhancement points. I've also a few astro projects I haven't touched in a long time and any time I bump dependencies, things just continue to work.
clean and clear! always the best astro tutorial
🙏
People need to understand that if they want cool features then they need to put effort to learn it. Otherwise best of luck with vanilla JS, CSS and HTML.
lol I mean, you're not wrong
I use it for multiple sites, to simplify things :) and yes it is. It has good dev support which helps debug things but yes it is getting to complex.
What do you feel like is too complex?
@@CodinginPublic I have to go back to docs every so often to clarify things because there is too much magic for example. Images that you mentioned, I struggled to figure that out. I tried integrating few html templates into Astro and it was difficult and it wasn't obvious what the problem is.
I like Astro obviously, I like Markdown integration especially because it really makes it easy, but sometimes errors will be that are not clear why, npm packages out of the blue are required.
Things like that give me impression that things are way more complex then they should be.
I don't think it's getting too complex to be honest.
All of the new features are pretty cool, but so far for me - building static sites and experimenting with different libraries using Astro is still pretty nice, and I can spin something up if I ever have a lightbulb moment in my brain - not a bad way to improve my front-end skills ^^
Agreed!
Thoguhtful and well done video. Thanks.
Glad you found it helpful!
It's not complex at all. The problem I see is that people jump to adding react etc without taking the time to understand what Astro is and what in can do
This is both a selling point for Astro for many…and the thing that prevents people from learning the basics of Astro :)
in which video you explained how to solve white flash with dark theme and view transitions?
Build a Dark Mode without a White Mode Flash!
ua-cam.com/video/I6ynSVZdX04/v-deo.html
@@CodinginPublic I will have a look, thank you.
Astro too complex? Skill issue.
lol boom roasted
I last tried Astro about a year ago and the main thing I didn't like was the custom compiler and editor tooling.
It was incredibly buggy and there really is no reason to add proprietary syntax in the first place, jsx gets the job done just fine.
What didn't you like about the syntax? It's very similar to standard JSX, so I'm curious.
Editor tooling is exactly the biggest problem right now. I use neovim and in one of my projects and the lsp just kinda stops working at one point... if I want to continue work i have to restart neovim
Astro has a lot of "things" that can make it look complex. If you want to optimize images you have to import them in a page so an article will have frontmatter, imports then content. Never seen this before. Then collections are for markdown, JSON, not for HTML so it's more for coded apps, with specific content structure and not for more plain static sites. JSX inspiration makes templating look odd for people used to templating systems used on the backend or frontend ones inspired by Jinja. The templates are also lacking blocks structures and the frontmatter has to be passed manually through templates inheritance tree and the API differs between markdown or .astro HTML page. Writing HTML articles would require using .astro files which can interpret some of the content as invalid JS/template syntax and break/require escaping. I would say it's for node developers not for "outside" fullstacks/webdevs.
ViewTransitions are already supported by modern browsers, so no need for Astro stuff.
Agreed. They look complex, but thankfully the docs are really clear and the implementation is simple for most things (IMO)
You absolutely can write plain HTML in the pages directory.. so it's not complex I'm that regard
Bro, is there no demand for frontend development because now the company's are hiring frontend developers with AI and in the next 2 years frontend development jobs will be completely eliminated.
maybe
IT IS. It's too complex. Everytime I start an astro project, it go back to nextjs. Client load?
What do you find too complex?
I have the opposite experience. I worked with NextJS for several years. But at the beginning of the year I tried Astro and since then I can't even see NextJS and I'm trying to migrate all my web projects to Astro as soon as possible.
@@CodinginPublic Pagination, routing, react-querying...
The problem with Astro is the same problem that Sveltekit and Nextjs has that is the build system is too complex and gets slow really quick as the app grows
I had one documentation app in Astro and it got 15 seconds to compile and after some time it stop working on production with a circular reference, but in development the problem did not exist at app, so I decided to drop it
That doesn't make any sense
I'm not sure I'm understanding. Are you saying it's not scaling because the build time is too long or because the features don't keep up?
@@CodinginPublic It will very likely has some scalability problems, but the problem about build complexity is that sometimes because it has many layers of build step it is really difficult to fix and debug
Just to understand, if a build bug happens, how do you know it is related to esbuild, vite SSR, the astro compiler? And it is only in the frontend or in the backend? In my case it only happens in production and in the frontend
In relation to features, the Astro team is incredible, they deliver many quality stuff really quick
@@andreilucasgoncalves1416 it's a declarative framework. If you're debugging you've already done something wrong