If you're digging Astro, I'm working on a course to teach you how to handle all sorts of production use cases with it. Sign up for updates at astro.party !
@@TerriTerriHotSauce HTMX works really well *with* Astro, actually! I went over it with @jherr in this video: th-cam.com/users/liveC5DHnG8W0ts?si=bWoVRzz-NItZjq3w
Astro to me is the most revolutionary technology in web/front ecosystem, it's really unique and it acts like: *"Do whatever you wan to, I'm here to support you no matter what"* when in other cases you always have tons of rules or limits and astro is incredibly open-minded and flexbile + tons of configurations. The fact that we can mix react component with other tools components in one place without any headache is crazy to me cuz we can build specific part of our project in react, other one in vue and the 3rd one in plain html css and we can mix it together and it gives me such a huge microfrontends vibes, altho i dont use astro on daily basis, it's my favourite technology in web/frontend ecosystem and next to it stays tailwind and alpine, really lovely, but I'm kinda scared that vercel will destroy astro somehow, anyways i cant wait what more will come from astro, its defo the default pick for any web, especially static one, no reason to use plain vite with css and html, it doesnt makes sense when we got astro and we can build components, layouts and other stuff, amazing!
Dude you I just got to your channel after studying more about Astro (I'm designing my first landing page on it to test it), and what an amazing explanation. Thank you so much for how you put things clearly, straight to the point but given important context. Thanks.
Very well explained. Hugo and Gatsby was the reason I never went with the static site generators. But pushed me into wp, and got me to play around with grav then publii. I’m really looking forward to digging into Astro.
That is a very good to watch Jason, thanks. I totally understand your point of view - I think right now, in dev's mind, Astro is just made for static, not dynamic. They communicated so much on this, that it's good to make clear you can do DYNAMIC with Astro (hybrid mode).
Everything you said applies for Qwik as well * It ships nearly zero JS by default (same as in astro, because if you have a dark mode toggle -> it needs to execute JS before rendering to prevent a white flash) * It can be used for content heavy sites * It is even better in a way, where it only ships JS then clicking/hovering a button * But I quess its a little more complex
5:47 I posted a screenshot of your statement on my instagram today, with a note telling me to look back at it in 5 years. I'm pretty sure you're right.
I like it too, I built a couple sites with Astro, but if you are relying heavily on AI to do the coding even if you give it all the documentation for Astro it's still not as good as next, in terms of generating non buggy code. By next year it should have caught up. I just don't have the chops to debug the code and manually add code to fix things. Mainly the issues come from GSAP, three.js, and having it all modular and in components. Then referencing those components in a page and having all those components play really nicely together I find especially with parallax scroll or scroll trigger, I'm sure competent developers probably don't have any problem whatsoever about calling stuff client side or making references hydrating Islands that kind of stuff.
2 หลายเดือนก่อน
I'm using Astro to create a SSR blog, it was very easy with dynamic routes and content collection. It's even better with Astro's image optimization and view-transitions API.
4:12 Best argument for Qwik. You don’t even need to think about static or dynamic portions of your page, and you send less JS, and don’t need to hydrate anything. I don’t get why anyone would choose Astro over Qwik? Qwik can even use the React ecosystem with qwikify-react.
@@learnwithjason yeah but unless you’re already locked in to using Astro, there’s arguably no point in using Qwik with Astro compared to simply just using Qwik City.
I think it depends on the use case. if I remember correctly, QwikCity doesn’t have a Markdown-as-page construct, right? so in many pages that really just need to display text (legal, privacy, etc.) I can see a good argument for leaning on Astro there, while using Qwik for the more dynamic portions. always depends on the project’s needs
@@learnwithjason I just saw that Qwik seamlessly integrates markdown, and you can embed Qwik components in markdown files. So it seems to cover thst use case too.
The beauty of astro is that if it's your foundation then that makes choosing the additional CSR/SPA framework like svelte or react or solid is basically a zero-weight commitment. You could use all three on different pages and it won't hurt your app performance or even your bundle size. It's such a unifying framework, that any other framework can freely come and/or go on top of it.
Next has two things for static sites that other tools dont, and after trying which it feels really strange to work with other tools. It is caching (+ deduplication) and revalidation. Imagine this use case: you have cms and you want to update one particular page in your fully static site. - Next? Very easy, just send webhook from cms and page is already updated for you. - Astro? Well, good luck with that. Either you have to make it dynamic page and implement caching+revalidation yourself (which, even with perfect implementation, is still inferior in terms of speed) or you have to rebuild whole app manually after each change in cms.
this is very much My Opinion, but manually managing caches is a recipe for pain always and a disaster if more than one developer is touching it. I've already found subtle ways that Next's caching breaks sites or delivers incorrect data using just their defaults. I understand why people like the idea, but I don't think it survives contact with reality unfortnately
I'm really liking Astro/Preact or Astro/HTMX for smaller side projects. My larger app, this stack is unfortunately a nonstarter for because you can see JSON data/raw object data in the astro-island props and my larger app is an aggregator app in a competitive space with a lot of copycats and making our raw data visible is not an option (we specifically spent time upgrading this app to Next /app router for this reason). Definitely would use this stack for certain other use cases though.
fwiw you can server-render Astro pages to avoid passing data in - same general flow as Next or other frameworks. they have both a "server" output which is all SSR, or a "hybrid" output that defaults to prerendered, but you can opt into SRR using `export const prerender = false;` in the frontmatter of the page
I ate a chunk of my own time to migrate a primarily static (with some dynamic) content-focused client site from NextJS to Astro when NextJS started getting all incomplete-paradigm-shift-a-week with their devs and I haven't looked back I use Astro all over the place now.
I've always wanted to use Astro for more complex apps instead of Next, but I've been hesistant because of their claim of being focused on content sites. What would you consider a feature / functionality of Next where you would be better served than using astro, if you were building Facebook? 😊
I'm not sure there's any app where I would use Next.js these days, honestly. too many weird gotchas and bits of magic for my comfort. I'm reaching for Astro or Vite + react-router (Remix) depending on the project's needs
Astro is like me - silently and economically overtaking the others (sitting confidently in their 250 HP SUV) in rush hour traffic with my small but sporty electric moped.
Giving more context and answering question: 1. You could build API endpoints in Astro and just get rid of your REST framework Yes, I know... with all the respect of the good work done on Astro, I'd still would like to keep the best practices and knowledge about my favourite HTTP framework. 2. You could build all your pages as pre-rendered static pages in Astro and then just serve them via your routes in the REST framework Yes... but I am aiming at a DX similar to the one that Next offers, where you have a monolyth (not a mono-repo) that runs both client and server. There are some attempt to re-use the running Vite serve to transpile also backend code (vite-plugin-node, vavite, @lomray/vite-ssr-boost) that I believe will give more freedom for handling these cases.
You can use api endpoints to handle form submissions for example and initial rendering of the page. For all other use cases ajax suffices or am I missing something? for highly interactive pieces of page the concept of islands allows you to build things in any framework you prefer in way akin to client components in react - which is also the only way to build highly interactive experiences with nextjs 💪🏼 Also tbh separating your FÉ from Pure BE is a good idea and I actually use turborepo to achieve this with a NestJS backend and tRPC and works quite well
@@rafaelrocha3991 With monorepos and deploying separate apps we can achieve good setup, I am not going to argue on that. But we are moving away from a simple starting point that a monolyth offers, which is something that I like to have in my toolbelt. Something simpler also to deploy and monitor.
yes! you can use plain JS client-side to fetch, or you can bring in your framework of choice. the default rendering mode of Astro supports your use case
I heard page to page routing does a full refresh including nav-bar and to fill this gap they use page animations. If this is so, then it stops me wanting to use it. But maybe it's not as bad as I think.
you can opt into SPA-style routing if you want, which works more or less through the same mechanisms as any other client-side routing library. by default it's MPA-style (full page refresh). there are trade-offs to both solutions, so it depends on what you're optimizing for
Astro are best with static sites, but not really a great choice for complex, dynamic data like table, queries, crud... Imo, but of course these still can be possible in Astro, however the effort taken compared to other ssr framework is not worth it
I think the latest improvements change that narrative a bit. I found myself struggling a lot more with the hidden complexities and non-standard features of Next more than I did with making Astro handle dynamic use cases. ultimately, though, the best tool is the one that makes YOU productive and gets the best outcome for the people who’ll use the thing you’re building - the tool doesn’t really matter except for the outcome it makes possible
it's fairly simple, but I built an Astro app for this episode: th-cam.com/video/b4HZpv61V1U/w-d-xo.html it's got API routes, Clerk for auth, and a database for keeping track of each user's progress I do have more plans for Astro apps, both as part of 4D1A and beyond. stay tuned!
how does it fit with htmx? that's what I'm using and it's great but I know nothing about Astro and curious if Astro would be easier or it's just you mix abd match kind of situation
it definitely depends on what you’re building. you can use them together: github.com/xstevenyung/astro-htmx - mixing and matching is definitely an option!
What would you say, then, is the key difference between 11ty and astro? It sounds a lot like they both fight for similar use cases, though I haven't heard the same emphasis made for 11ty, I doubt that 11ty can't opt into some more dynamic stuff in a structured way.
11ty is great! I think it’s possible to do some of what Astro does in 11ty, but I don’t believe it’s a primary focus in the same way. I could be wrong though! I should check back with Zach and team
@@learnwithjason I appreciate the response! It'd be interesting to hear since the description in this video is quite sharp and on point based on the sufferings of today's developers. It makes me wonder if I can get a similar quality comparison about 11ty vs Astro.
Astro is nice and maybe some things work better out of he box - but 11ty feels more simple. Not necessarily in a bad way. I am personally still torn between the two.
SvelteKit is very cool and I'm a big fan. I think if I was using Svelte daily I might feel differently correct me if I'm wrong, but there's no option in SvelteKit to ship no client JS if the page has no interactivity, right? you always get the SvelteKit bootstrap bundle?
the demo from the Next team is shipping 327kB of compressed JS: app-router.vercel.app/ if that's what the Next team is shipping by default, I'd assume yes?
@@learnwithjason Just checked my Network tab after wiping out all the cache, it's 92kB JS on a fresh Next install. It also works fully with JS disabled. So it's more of a progressive enhancement if a browser can load JS. Which is fair in the era of modern browsers. The reason I am choosing Next today, is the community and ecosystem. Also, no need to switch framework no matter what I am building. It scales smoothly from a small to big project. In the end, best to use what you're already comfortable with:) And I'm staying open minded going forward;)
it depends on what your success criteria are and what the skill set of the team looks like. both are very good tools. I lean toward Astro most of the time because it ships less overall code to the browser, but my skill set is also priming me to feel more productive in Astro
@@learnwithjason I haven't had the chance to try out Astro yet, but I really appreciate Remix's Nested Routing feature. Through 'Nested Routes', It allows for nearly every loading state to be eliminated, which is a huge plus. Most web applications fetch data within components, causing slower load times and potential issues. With Remix, data is loaded in parallel on the server and sent as a fully formed HTML document, resulting in a much faster and smoother experience. Does Astro have anything similar to Nested Routes to load the site faster?
you can set up API endpoints using Astro for sure. if that's the only thing you're using it for, it might be a bit of an odd use case but nothing wrong with it
@@learnwithjason well i'm using these two massive frameworks only because i lack the skills to "do it my self" I only use a small part of each of them and now i would like to have a full stack Astro app with static content as well as vue components and also the api directly in Astro with like Fastify/plain Node, postgres, drizzle orm, zod, redis, nanostore and what not. I would like to not have to keep up with all different releases in Quasar/Adonis and just focus on Astro changes. Maybe also Fastify if that is what i have to use for the api part?
@@PeterCarlsson-k7n oh, gotcha! yeah, you'll be able to do this with Astro and simplify the stack for sure. Astro has API routes (docs.astro.build/en/core-concepts/endpoints/#server-endpoints-api-routes) which replace the need to use Fastify/Node directly, and you can access your DB/ORM inside those routes and/or in the frontmatter of your static pages. the Vue integration is great. and if you need any of your non-API pages to be dynamic, you can use Astro's hybrid mode to opt-in specific pages to server-side rendering have fun!
@@learnwithjason thank you so much. I will start migrating my stuff and "add as little as i can" until i get all i need working. Fastify looks nice but again, i want to keep it with in Astro and not have to lean on external frameworks that i have to maintain. I'm now a paying member of your chanel "YPC.SMHK-W42Q-LDUW-A93Q".
isn't next14 SSR doing the same? by default every this is server rendered and then we can use 'use client' to make it client side, if I am wrong please let me know
as far as I understand Next still ships client-side JS in every mode, and it approaches defaults backwards in my opinion (starts with app directory, which has the most moving parts / required context to use safely)
Take a look at something like next-theme (popular way to implement dark mode on nextjs) -- hundreds of lines of code to deal with NextJS invented SSR server bullshit -- and it does what? **adds a class to the body tag**. In an Astro app, even a react one, if your framework getting in the way, write the one line of actual VanillaJS it takes to do that and job done. Astro so blatantly exposes the sometimes-hidden sinkhole of BS makework some of these frameworks create for devs.
For me (using both on web dev) the mental model is very simmilar. Most components would be static and server rendered, and only the interactve ones would be send to client. I found Astro better for content sites (content collections are amazing) while i prefer Next for a fully dynamic site (like a dashboard)
you can use any framework for dynamic content inside astro. You can even use them at the same time, one component rendered with React, another with Vue, another with Svelte. Does not make sense (unless you are transitioning etc.) but it is possible.
Today hardware is so accessible thats why client/dev doesnt care about extra things they are adding by default even though they dont need it (no optimization)
Im no fan of Js on the server side but when reaching the point where you want to use a js fullstack framework youll need remix or nextjs anyways. If you site is static why use javascript in the first place? That sound like a lot of over engineering to me. Also Astro boasts about being content first but in the real world customers want to edit their own content and 99.9% of the time they are not programmers. If you tell them they have to type ### for a level3 heading in markdown they will tell you to f*ck of.
If one wants to develop a full blown interactive application with state needed from one end to another (i.e. no islands if I understand correctly), how good is it DX wise, and performance wise, compared to NextJS, and Qwik? I have seen the recent Qwik integration, does Astro+Qwik stand its own against Qwik City for developping complex apps?
you can share state between islands (TanStack Query is great for this) or ship an embedded SPA. even in a full-blown interactive app, though, there are lots of things that fall outside of the app part (privacy, legal, about, the blog, etc.) that have me leaning toward embedding the "app" part as an SPA in Astro - because if it's highly dynamic, it probably won't work without JS anyways, and if it's changing for every user it doesn't make sense to make it SEO-friendly, so an SPA reduced complexity for maintenance without losing required functionality DX-wise, I'd say one codebase + less complexity leans in favor of Astro. Astro's performance baseline is higher than Next's and doesn't require learning the additional complexity of Next's custom implementations of things. I don't know how it compares to Qwik, though
@@learnwithjason I agree with most of the points, although I am more and more interested in Qwik which seems to have the same functionalities as any meta framework, with better performance than anything else, and probably with great SEO by default, as it is mostly SSR. Still Astro intrigues me a lot, so thank you very much for your answer!
I just feel its still kinda clunky to host sanity on the same url, and to get preview to work perfectly, maybe you could do a tutorial on your workflow with it?
the badass.dev team uses a template for their landing pages and they standardized on Next.js. it's not what I would have chosen but I'm also not going to ask them to overturn their whole process for me
If you're digging Astro, I'm working on a course to teach you how to handle all sorts of production use cases with it. Sign up for updates at astro.party !
Please compare it to HTMX.
@@TerriTerriHotSauce HTMX works really well *with* Astro, actually! I went over it with @jherr in this video: th-cam.com/users/liveC5DHnG8W0ts?si=bWoVRzz-NItZjq3w
the website is legit Jason.
Cool to watch Like Button group in the video control bar light up as Jason says 'Like Button' in the video.
1:00
Is that a youtube thing? Automatic or you set it?
This is THE way you explain things! Thanks for such great content Jason
Astro is freaking awesome, they definitely spotted an underserved segment. Congrats and many thanks 👍
Astro to me is the most revolutionary technology in web/front ecosystem, it's really unique and it acts like: *"Do whatever you wan to, I'm here to support you no matter what"* when in other cases you always have tons of rules or limits and astro is incredibly open-minded and flexbile + tons of configurations. The fact that we can mix react component with other tools components in one place without any headache is crazy to me cuz we can build specific part of our project in react, other one in vue and the 3rd one in plain html css and we can mix it together and it gives me such a huge microfrontends vibes, altho i dont use astro on daily basis, it's my favourite technology in web/frontend ecosystem and next to it stays tailwind and alpine, really lovely, but I'm kinda scared that vercel will destroy astro somehow, anyways i cant wait what more will come from astro, its defo the default pick for any web, especially static one, no reason to use plain vite with css and html, it doesnt makes sense when we got astro and we can build components, layouts and other stuff, amazing!
Dude you I just got to your channel after studying more about Astro (I'm designing my first landing page on it to test it), and what an amazing explanation. Thank you so much for how you put things clearly, straight to the point but given important context. Thanks.
This was a fantastic video!
thank you!
First video I’ve seen on Astro that really made me want to try it out. Great work!
Astro became the thing I was needed for a long time
I've been rebuilding a website in Astro, and loving it so far. Will definitely check out your course.
Very well explained. Hugo and Gatsby was the reason I never went with the static site generators. But pushed me into wp, and got me to play around with grav then publii. I’m really looking forward to digging into Astro.
That is a very good to watch Jason, thanks.
I totally understand your point of view - I think right now, in dev's mind, Astro is just made for static, not dynamic. They communicated so much on this, that it's good to make clear you can do DYNAMIC with Astro (hybrid mode).
This is the best and also the most concise explanation of Astro I've seen, thank you!
I'm glad it was helpful! thanks so much 💜
Just a few years from the first version, it revolutionized. Imagine five years from now, even ten years from now
Everything you said applies for Qwik as well
* It ships nearly zero JS by default (same as in astro, because if you have a dark mode toggle -> it needs to execute JS before rendering to prevent a white flash)
* It can be used for content heavy sites
* It is even better in a way, where it only ships JS then clicking/hovering a button
* But I quess its a little more complex
I love Qwik! there’s a live show coming up where Steve from the Qwik team will join me to show off their Qwik+Astro integration
I used to use Next JS a lot, but I have recently switched to Astro and I think Astro is actually better at this point.
5:47 I posted a screenshot of your statement on my instagram today, with a note telling me to look back at it in 5 years. I'm pretty sure you're right.
I like it too, I built a couple sites with Astro, but if you are relying heavily on AI to do the coding even if you give it all the documentation for Astro it's still not as good as next, in terms of generating non buggy code. By next year it should have caught up. I just don't have the chops to debug the code and manually add code to fix things. Mainly the issues come from GSAP, three.js, and having it all modular and in components. Then referencing those components in a page and having all those components play really nicely together I find especially with parallax scroll or scroll trigger, I'm sure competent developers probably don't have any problem whatsoever about calling stuff client side or making references hydrating Islands that kind of stuff.
I'm using Astro to create a SSR blog, it was very easy with dynamic routes and content collection. It's even better with Astro's image optimization and view-transitions API.
I like astro because, every html i drop into the apps folder it works its the best and timeless js framework that ships html first 🥇!
I’m fighting to get Astro buy in in more places. Thank you for giving me a succinct video to spread the gospel
but nextjs does ssg out of the box too since recently. and you use „use client“ inside a component or page to make it interactive.
I'm excited to hear that. does it work anywhere other than Vercel without needing a bunch of manual config?
@@learnwithjason yea!
Plus Astro uses the View Transitions API which is a cool new - experimental still - feature
Important part that was shipped in Astro 3 is that now you get HMR in React 🤯
4:12 Best argument for Qwik. You don’t even need to think about static or dynamic portions of your page, and you send less JS, and don’t need to hydrate anything. I don’t get why anyone would choose Astro over Qwik? Qwik can even use the React ecosystem with qwikify-react.
Qwik and Astro work together. I've got Steve from the team joining in a few weeks to show how it works! check my upcoming livestreams
@@learnwithjason yeah but unless you’re already locked in to using Astro, there’s arguably no point in using Qwik with Astro compared to simply just using Qwik City.
I think it depends on the use case. if I remember correctly, QwikCity doesn’t have a Markdown-as-page construct, right? so in many pages that really just need to display text (legal, privacy, etc.) I can see a good argument for leaning on Astro there, while using Qwik for the more dynamic portions. always depends on the project’s needs
@@learnwithjason Yeah, that’s a good point. Markdown sites is likely the sweet spot for Astro.
@@learnwithjason I just saw that Qwik seamlessly integrates markdown, and you can embed Qwik components in markdown files. So it seems to cover thst use case too.
Extremely clear and instructive ! Great video !
💯 such a great explanation of this space and advice for folks. Thanks for this video 👍
thanks for watching!
Astro and Svelte(Kit) for 2024 🎉
I do love Svelte
You said it! 👏🏻👏🏻👏🏻
The beauty of astro is that if it's your foundation then that makes choosing the additional CSR/SPA framework like svelte or react or solid is basically a zero-weight commitment. You could use all three on different pages and it won't hurt your app performance or even your bundle size. It's such a unifying framework, that any other framework can freely come and/or go on top of it.
The unemployed tech stack
@@adreto2978this made me laugh hard😂
Love it! I'm also a huge fan of Astro 🌟
Next has two things for static sites that other tools dont, and after trying which it feels really strange to work with other tools. It is caching (+ deduplication) and revalidation. Imagine this use case: you have cms and you want to update one particular page in your fully static site.
- Next? Very easy, just send webhook from cms and page is already updated for you.
- Astro? Well, good luck with that. Either you have to make it dynamic page and implement caching+revalidation yourself (which, even with perfect implementation, is still inferior in terms of speed) or you have to rebuild whole app manually after each change in cms.
this is very much My Opinion, but manually managing caches is a recipe for pain always and a disaster if more than one developer is touching it. I've already found subtle ways that Next's caching breaks sites or delivers incorrect data using just their defaults. I understand why people like the idea, but I don't think it survives contact with reality unfortnately
Wouldn’t you have to do that anyways if you’re hosting with Netlify and pulling from a repo?
Love these types of videos!
Very nice inspiration. Thx a lot!!
I'm really liking Astro/Preact or Astro/HTMX for smaller side projects. My larger app, this stack is unfortunately a nonstarter for because you can see JSON data/raw object data in the astro-island props and my larger app is an aggregator app in a competitive space with a lot of copycats and making our raw data visible is not an option (we specifically spent time upgrading this app to Next /app router for this reason). Definitely would use this stack for certain other use cases though.
fwiw you can server-render Astro pages to avoid passing data in - same general flow as Next or other frameworks. they have both a "server" output which is all SSR, or a "hybrid" output that defaults to prerendered, but you can opt into SRR using `export const prerender = false;` in the frontmatter of the page
nice explanation!
Astro and Solidjs is match made in heaven ❤
The best framework.
I ate a chunk of my own time to migrate a primarily static (with some dynamic) content-focused client site from NextJS to Astro when NextJS started getting all incomplete-paradigm-shift-a-week with their devs and I haven't looked back I use Astro all over the place now.
very well said
Hey, can you do the same analysis for htmx?
have you used Astro in combination with a CMS? If yes, what was the CMS?
I currently use it with Sanity on my site, but any headless CMS will work!
I've always wanted to use Astro for more complex apps instead of Next, but I've been hesistant because of their claim of being focused on content sites. What would you consider a feature / functionality of Next where you would be better served than using astro, if you were building Facebook? 😊
I'm not sure there's any app where I would use Next.js these days, honestly. too many weird gotchas and bits of magic for my comfort. I'm reaching for Astro or Vite + react-router (Remix) depending on the project's needs
Astro is like me - silently and economically overtaking the others (sitting confidently in their 250 HP SUV) in rush hour traffic with my small but sporty electric moped.
I'd be happy to use Astro in my app to if they made it easier to integrate with a rest API framework like Fastify, Nest or others
could you say more about what you're running into? I'm looking for more video ideas and might put something together if you've got a use case 👀
Giving more context and answering question:
1. You could build API endpoints in Astro and just get rid of your REST framework
Yes, I know... with all the respect of the good work done on Astro, I'd still would like to keep the best practices and knowledge about my favourite HTTP framework.
2. You could build all your pages as pre-rendered static pages in Astro and then just serve them via your routes in the REST framework
Yes... but I am aiming at a DX similar to the one that Next offers, where you have a monolyth (not a mono-repo) that runs both client and server.
There are some attempt to re-use the running Vite serve to transpile also backend code (vite-plugin-node, vavite, @lomray/vite-ssr-boost) that I believe will give more freedom for handling these cases.
You can use api endpoints to handle form submissions for example and initial rendering of the page. For all other use cases ajax suffices or am I missing something?
for highly interactive pieces of page the concept of islands allows you to build things in any framework you prefer in way akin to client components in react - which is also the only way to build highly interactive experiences with nextjs 💪🏼
Also tbh separating your FÉ from Pure BE is a good idea and I actually use turborepo to achieve this with a NestJS backend and tRPC and works quite well
@@rafaelrocha3991 With monorepos and deploying separate apps we can achieve good setup, I am not going to argue on that.
But we are moving away from a simple starting point that a monolyth offers, which is something that I like to have in my toolbelt.
Something simpler also to deploy and monitor.
What about SSG + some data fetching on client side, is it possbible? (no I can't do SSR because of shared hosting)
yes! you can use plain JS client-side to fetch, or you can bring in your framework of choice. the default rendering mode of Astro supports your use case
I heard page to page routing does a full refresh including nav-bar and to fill this gap they use page animations. If this is so, then it stops me wanting to use it. But maybe it's not as bad as I think.
you can opt into SPA-style routing if you want, which works more or less through the same mechanisms as any other client-side routing library. by default it's MPA-style (full page refresh). there are trade-offs to both solutions, so it depends on what you're optimizing for
@@learnwithjason
Thank you for explaining Jason.
Heart still breaks for Gatsby. :-(
They fumbled, just add graphql to astro
Astro are best with static sites, but not really a great choice for complex, dynamic data like table, queries, crud... Imo, but of course these still can be possible in Astro, however the effort taken compared to other ssr framework is not worth it
I think the latest improvements change that narrative a bit. I found myself struggling a lot more with the hidden complexities and non-standard features of Next more than I did with making Astro handle dynamic use cases. ultimately, though, the best tool is the one that makes YOU productive and gets the best outcome for the people who’ll use the thing you’re building - the tool doesn’t really matter except for the outcome it makes possible
I would still love to see a full-featured app built with Astro. Maybe Astro with API routes and Auth for 4 Devs 1 Project??
it's fairly simple, but I built an Astro app for this episode:
th-cam.com/video/b4HZpv61V1U/w-d-xo.html
it's got API routes, Clerk for auth, and a database for keeping track of each user's progress
I do have more plans for Astro apps, both as part of 4D1A and beyond. stay tuned!
Awesome. I thought I had seen you build it somewhere didn't realize it was already in the 4D1A! Thanks for sharing it ❤ @@learnwithjason
how does it fit with htmx? that's what I'm using and it's great but I know nothing about Astro and curious if Astro would be easier or it's just you mix abd match kind of situation
it definitely depends on what you’re building. you can use them together: github.com/xstevenyung/astro-htmx - mixing and matching is definitely an option!
Well explained
Do you think astro is suited for building modern e-commerce sites/online shops ?
I do!
What would you say, then, is the key difference between 11ty and astro? It sounds a lot like they both fight for similar use cases, though I haven't heard the same emphasis made for 11ty, I doubt that 11ty can't opt into some more dynamic stuff in a structured way.
11ty is great! I think it’s possible to do some of what Astro does in 11ty, but I don’t believe it’s a primary focus in the same way. I could be wrong though! I should check back with Zach and team
@@learnwithjason I appreciate the response! It'd be interesting to hear since the description in this video is quite sharp and on point based on the sufferings of today's developers. It makes me wonder if I can get a similar quality comparison about 11ty vs Astro.
Astro is nice and maybe some things work better out of he box - but 11ty feels more simple. Not necessarily in a bad way. I am personally still torn between the two.
Well said.
Where can I get the Astro merch?!!
shop.astro.build
Didn't find any selling feature when compared to Sveltekit, but I'm subjective here.
SvelteKit is very cool and I'm a big fan. I think if I was using Svelte daily I might feel differently
correct me if I'm wrong, but there's no option in SvelteKit to ship no client JS if the page has no interactivity, right? you always get the SvelteKit bootstrap bundle?
@@learnwithjason that's true, it can be prerendered but there's still js modules connected.
Does the new /app router and RSC ship that much client side JS though?:)
the demo from the Next team is shipping 327kB of compressed JS: app-router.vercel.app/
if that's what the Next team is shipping by default, I'd assume yes?
@@learnwithjason Just checked my Network tab after wiping out all the cache, it's 92kB JS on a fresh Next install.
It also works fully with JS disabled. So it's more of a progressive enhancement if a browser can load JS. Which is fair in the era of modern browsers.
The reason I am choosing Next today, is the community and ecosystem. Also, no need to switch framework no matter what I am building. It scales smoothly from a small to big project.
In the end, best to use what you're already comfortable with:) And I'm staying open minded going forward;)
Could you help me decide between Astro and Remix for a homepage and web application?
it depends on what your success criteria are and what the skill set of the team looks like. both are very good tools. I lean toward Astro most of the time because it ships less overall code to the browser, but my skill set is also priming me to feel more productive in Astro
@@learnwithjason I haven't had the chance to try out Astro yet, but I really appreciate Remix's Nested Routing feature. Through 'Nested Routes', It allows for nearly every loading state to be eliminated, which is a huge plus. Most web applications fetch data within components, causing slower load times and potential issues. With Remix, data is loaded in parallel on the server and sent as a fully formed HTML document, resulting in a much faster and smoother experience.
Does Astro have anything similar to Nested Routes to load the site faster?
Hi Jason, i'm using Quasar in front and Adonis in back. Will i be able to use Astro as full stack in a "api like way"?
you can set up API endpoints using Astro for sure. if that's the only thing you're using it for, it might be a bit of an odd use case but nothing wrong with it
@@learnwithjason well i'm using these two massive frameworks only because i lack the skills to "do it my self" I only use a small part of each of them and now i would like to have a full stack Astro app with static content as well as vue components and also the api directly in Astro with like Fastify/plain Node, postgres, drizzle orm, zod, redis, nanostore and what not.
I would like to not have to keep up with all different releases in Quasar/Adonis and just focus on Astro changes. Maybe also Fastify if that is what i have to use for the api part?
@@PeterCarlsson-k7n oh, gotcha! yeah, you'll be able to do this with Astro and simplify the stack for sure. Astro has API routes (docs.astro.build/en/core-concepts/endpoints/#server-endpoints-api-routes) which replace the need to use Fastify/Node directly, and you can access your DB/ORM inside those routes and/or in the frontmatter of your static pages. the Vue integration is great. and if you need any of your non-API pages to be dynamic, you can use Astro's hybrid mode to opt-in specific pages to server-side rendering
have fun!
@@learnwithjason thank you so much. I will start migrating my stuff and "add as little as i can" until i get all i need working. Fastify looks nice but again, i want to keep it with in Astro and not have to lean on external frameworks that i have to maintain.
I'm now a paying member of your chanel "YPC.SMHK-W42Q-LDUW-A93Q".
thank you so much!
isn't next14 SSR doing the same? by default every this is server rendered and then we can use 'use client' to make it client side, if I am wrong please let me know
as far as I understand Next still ships client-side JS in every mode, and it approaches defaults backwards in my opinion (starts with app directory, which has the most moving parts / required context to use safely)
Take a look at something like next-theme (popular way to implement dark mode on nextjs) -- hundreds of lines of code to deal with NextJS invented SSR server bullshit -- and it does what? **adds a class to the body tag**. In an Astro app, even a react one, if your framework getting in the way, write the one line of actual VanillaJS it takes to do that and job done. Astro so blatantly exposes the sometimes-hidden sinkhole of BS makework some of these frameworks create for devs.
For me (using both on web dev) the mental model is very simmilar. Most components would be static and server rendered, and only the interactve ones would be send to client. I found Astro better for content sites (content collections are amazing) while i prefer Next for a fully dynamic site (like a dashboard)
i had no idea you could use react with astro
you can use any framework for dynamic content inside astro. You can even use them at the same time, one component rendered with React, another with Vue, another with Svelte. Does not make sense (unless you are transitioning etc.) but it is possible.
nailed it
Is Astro good for e-commerce development?
yes, in many cases. it depends on the specifics, but I have build ecomm sites in Astro and would do it again
Astro + Qwik🥳
Today hardware is so accessible thats why client/dev doesnt care about extra things they are adding by default even though they dont need it (no optimization)
Im no fan of Js on the server side but when reaching the point where you want to use a js fullstack framework youll need remix or nextjs anyways. If you site is static why use javascript in the first place? That sound like a lot of over engineering to me.
Also Astro boasts about being content first but in the real world customers want to edit their own content and 99.9% of the time they are not programmers. If you tell them they have to type ### for a level3 heading in markdown they will tell you to f*ck of.
I hear you. fwiw any CMS can power Astro, so while Markdown is an option, it’s not required. I run my Astro site off Sanity, for example
If one wants to develop a full blown interactive application with state needed from one end to another (i.e. no islands if I understand correctly), how good is it DX wise, and performance wise, compared to NextJS, and Qwik?
I have seen the recent Qwik integration, does Astro+Qwik stand its own against Qwik City for developping complex apps?
you can share state between islands (TanStack Query is great for this) or ship an embedded SPA. even in a full-blown interactive app, though, there are lots of things that fall outside of the app part (privacy, legal, about, the blog, etc.) that have me leaning toward embedding the "app" part as an SPA in Astro - because if it's highly dynamic, it probably won't work without JS anyways, and if it's changing for every user it doesn't make sense to make it SEO-friendly, so an SPA reduced complexity for maintenance without losing required functionality
DX-wise, I'd say one codebase + less complexity leans in favor of Astro. Astro's performance baseline is higher than Next's and doesn't require learning the additional complexity of Next's custom implementations of things. I don't know how it compares to Qwik, though
@@learnwithjason I agree with most of the points, although I am more and more interested in Qwik which seems to have the same functionalities as any meta framework, with better performance than anything else, and probably with great SEO by default, as it is mostly SSR.
Still Astro intrigues me a lot, so thank you very much for your answer!
Astro and angular for 2024
Please compare this to HTMX.
Astro can be used as the server for HTMX endpoint. Astro pages can generate the HTML responses.
I will. When it becomes easier to use with sanity.
what are you running into with Sanity? I use Astro + Sanity for lwj.dev and I like it
I just feel its still kinda clunky to host sanity on the same url, and to get preview to work perfectly, maybe you could do a tutorial on your workflow with it?
{2024-05-22}
astro party has everything you said is a no brainer for you to build with astro but the website is built with next js, wtf 😂
the badass.dev team uses a template for their landing pages and they standardized on Next.js. it's not what I would have chosen but I'm also not going to ask them to overturn their whole process for me
soo... Astro is better than Svelte? doubt
you'd use Svelte *in* Astro. You may compare SvelteKit with Astro.
you can use Svelte in Astro, so weird comparison
imo astro + svelte *chefkiss
@@vee.mcouldn't agree more! :)
@@vee.m But way Astro when you have Sveltekit?
jQuery ❤