Unpopular opinion: I honestly don't know why frameworks creators focus so much on gaining few ms on page load. I mean, yes TTI is important. But who cares about getting from 40ms to 10ms? Not the users. Of course users want fast TTI, but Angular/React/Vue/Svelte already provide that! Users want bug-free apps and great UX. And these come with frameworks that provide great DX. We, developers, want to add/modify/delete features fast and with no side effects. We want to manage our states between components/pages with ease and without spaghetti code. We want to be able to make our apps to SCALE!
Hi! Is there a way to save the data fetched from the server to the client state? I don't want to make use of prop drilling. And I also need getStaticPaths. In Nextjs, I receive the value from the server and save it in the client context
Sure, but in NextJS you do that by taking the props and funneling them into the context. So you are using the props since that is the hydration mechanism of NextJS. You can't set the context in getStaticPaths directly. The same is true with Astro. The hydration mechanism is Astro.props, and then you send those props to any components that need the data, client loading or not, but it's only the client loading components that get those props through hydration as well. Within those components you could then use a context mechanism in frameworks that support context.
@@jherr Okey, maybe you can help me with this please. Check this code: --- export async function getStaticPaths() { ... } const { slug } = Astro.params; const { siteSetting } = await fetchCMSData(slug) --- But then I cant access siteSetting inside a NavBar's child, because it's undefined on the client (not in the server). I can only access it via prop drilling, but I don't want to, I want to use the react context
@@julianblanco8735 RUclips comments are not the ideal place for this. The discord server discord.gg/3pnS9P6g is better for talking about coding problems with specific examples. But just on its face, Astro only knows to use hydration when you've hinted it with the `client` property. So give that, should Context be getting hydrated on the client?
Astro + Solid is really the BEST experience I can think of when it comes to Islands. The way Solid provides exportable reactive primitives completely solves any global state issues you run into w Islands. It just makes a ton of sense.
Hmmmm…. My company moving our web frontend to Astro is a definite possibility now. It’s a complex and highly interactive web app with a backend, a lot of reactive state both local and global, conditional rendering based on hundreds of different combinations of data, and a lot of pop-up menus and modals. We’re on NextJS with a mix of CSR for our homepage (basically a feed a la the Facebook feed) and SSR for our [detail] pages. Our performance numbers are in the gutter right now (12 SECOND TTI with slow 3G and 4x throttling and that’s WITH route-based code splitting and many of our components dynamically imported) so a move to Astro is something we would consider to get our performance numbers up but it’s gonna take a lot of research and prototyping to see if Astro can meet the current and future demands of our web frontend. EDIT: to clarify, I've identified many other optimizations we can do on our current frontend before taking the very drastic step of changing frameworks and as I've said we would have a lot of prototyping to do before we went through with such a thing
Thanks Jack, discovered your videos the past week and absolutely love it!! In my mind the "perfect" front end stack at this moment would be runtime integrated MFEs (using Module Federation) built with React, Astro and Nano Stores (or Jotai if it works in Astro); all deployed on Vercel. My only concern is how a runtime integrated MFE would work with Astro and I am struggling to find anyone having done this. Maybe try this for a future video?
Between Theo interviewing Fred just a few days ago and this amazing cross-examination, there is so much well deserved hype over Astro right now! Thanks so much for taking the time to create such meaningful content, Jack!
Thanks for the video and also for providing the code, @jherr. My results comparing the SSR are as follows: Astro: 22 requests, 33.3kb tx, finish: 7.9s, DOMLoad: 0.183s, Load: 0.500s; LCP avg: 0.93s, FCP avg: 0.4. TBT: NextJS: 25 requests, 1.6MB tx, finish: 9.0s, DOMLoad: 1.040s, Load: 1.380s; LCP avg: 1.1s, FCP avg: 0.23s. Astro showed a very small edge over Next in overall LightHouse performance score (98 vs 97) and that primarily is because of better LCP. However Next performed better in Speed Index, and Time to Interact.
Astro shows a lot of potential, but it's still too buggy imo to use outside of personal projects. But this might be my go to framework in the future to build websites once it has become more stable
Hi Jack, did you know, that you can disable the client runtime in Next.js? Just add the following export to your page file "export const config = {unstable_runtimeJS:false}"
Just reading through the Astro Docs for the first time... When using React and Astro together it looks like there will be some context switching due to the differences in JSX and Astro templates.
For people like me, living in the Mexican jungle and having at best a 3G connection (which is standard for most humans on earth btw), this is a very welcome speed-up! :)
Not sure currently, but when I made this video it was either/or you were either server rendered (SSR) or static (SSG). You couldn't have both at the same time.
@@jherr Thank you for the answer, but at least it seemed pretty easy to switch if necessary. One remark: I was hoping for a little perfomance comparison at the end. I mean to compare the Astra and NextJs apps at the end, when both were SSR 😅. Besides that I really liked the video, because of it I subbed :)
@@stillready6405 Hmm, I thought I gave those numbers. As I recall when Astro was changed to SSR the numbers were similar to NextJS. That being said, total "time to interactive" (TTI) should be much better on Astro, in particular with preact, because of the reduced bundle size and reduce amount of hydration work on the client. And that time to interactive is actually the truly important score.
Thanks for the nice explanation. I don't think the comparison is very fair because you can disable JS and Next will still load the site the same way as Astro does it. Using the "Load" measure in network tab of Chrome (as you did) only calculates the downloaded resources. But Next will still show content even before the JS is loaded/parsed. So effectively they should be the same. The reason your second test is slower is because of the extra JSON that Nextjs needs to have in the HTML directly as per hydration. This is an ongoing topic in the Next community. Once you add some kind of real-world interactivity with Astro you will want to somehow access the data on the page - say the list of pokemons. This will anyway require a server roundtrip to get the JSON; whereas with Next it's already there.
With respect, I disagree. I bent over backwards to make this test as fair as possible. In regards to disabling JS, I suppose you could do that, but that would disable the JS on the Login button. It's a sledgehammer approach. And would we want tell customers to disable JS on their browsers? As for the accessing the list of Pokemon, sure, that would normalize it. But that wasn't the test. The "report" of Pokemon is non-interactive. NextJS makes me pay the freight on non-interactive content and doesn't give me the choice. Astro gives that choice. Of course I get that NextJS and the React core team are working on this, but that doesn't change the fact that this is the state of the technology choices today.
bro I have one doubt that is we are integrating ssr with redux toolkit. So for example crud application is there , in create method we are giving dispatch in getserversideprops and here comes my doubt in handlesubmit how to give the dispatch
IMHO, the either/or static vs ssr problem is real. It's a huge architecture win that Next can do SSR on some routes, and SSG/ISG on others. Also Astro currently doesn't have a deployment or ISG story the way Next/Vercel does. Also, it's not like NextJS is unaware of the hydration issue. They are working on their own partial rehydration/islands architectural option as well. Also, the DX of Astro needs work. It's in 1.0.
NextJS would always be better than this in many circumstances- regardless of what this shows. They have a huge team working on it and an even larger community and it’s always improving. They have just to ensure things are done properly before they get publicly release. For Astro to match it it’d be very difficult
@@clublati That's demonstrably untrue. As a community we've been waiting for over a year for Vercel/NextJS to make the minor changes required to support Module Federation. They have even committed to doing so. But it hasn't happened. I am a NextJS fan. I chose and use NextJS on my current project at work. But I am under no illusion that I (or honestly the community) is in control of the direction of NextJS. Vercel is. And if what you are making aligns well with that architecture then you'll have an easier time of it. But if not, then there are very decent alternatives, like this one. And those alternative projects should not be written off just because of the size of the backing company or community.
@@jherr with Vercel's Build API, Astro might narrow the gap even more. And they can do some pretty wild things with deployment and Astro. They've got it working in service workers, web workers, edge functions and all of that.
Hi Jack, thank you very much for the amazing content 😍 I have question about nx monorepo How I can run next js app within the monorepo silently in the background something like pm2 or detached Thank you very much in advance Best, Ghassan
@@jherr Damn, I already started my most recent project or work on NextJs 🤣. But imo I feel like NextJs will be here in 5 years while Astro... not sure.. so the assurance of maintainability in the future sort of outweighs performance right now.
@@underflowexception Yeah, I'm certainly not saying don't use NextJS. I'm just saying that at this point (6/22/23) Astro is still outperforming NextJS. Take from that what you will.
They already do. Vercel support a ton of frameworks, and have been making moves to share some of the previously Next.js-only features with any framework that's willing to implement them. It all drives traffic and support to Vercel, so it makes sense.
Would like to see a video with sharing state across components and pages in Astro. Not sure if it's possible, I checked out their documentation, and I think it's possible unless I'm wrong.
Within a page, it's very possible, they have a whole section of their documentation that talks about using nanostores to do state sharing. Between pages would need to be accomplished using cookies or session state or something like that. I don't think Astro is a SPA by default.
@@jherr I briefly read about nanostores inside the Astro documentation, reminded of Jotai in some ways. It's one of those things I just got to get my hands wet with to see what is like and invest some time into it when I get time 🙂
@@quelchx Oh, it's exactly a Jotai, but better in some ways. Jotai is hard-bound to React, which means you can't use it in preact/vue/etc. like you can Nanostores. And I also think that some of the nanostores API, like computed, is a little easier to reason about. That being said, nanostores doesn't have the integrations that Jotai does. So you win some, you lose some. But great libraries all around. And a great model for state storage.
@@jherr oh i thought the answer was gonna be that u still had to fetch the data from the SSG'd site, but so there is actually a way how to build all the pages, data included? I would be really interested in a video about this! How to integrate CMS's in my workflow has been the biggest struggle i have been facing lately. There is very little content about it, in comparison w other web-related stuff. It's also such a wasteland, w so many over expensive solutions, or abandoned projects. I recently played around w payloadcms and quite liked it, as it is for free as you can self-host, and quite like how you can write the schemas to describe the data/UI.
@@bigmistqke yeah, that's way the whole `getStaticPaths` thing is about. You are returning to astro a list of all of the pages to statically generate along with the data for each page. NextJS has exactly the same mechanism. But Vercel/NextJS also have the infrastructure to request that a single page is refreshed, as opposed to all the pages. That is called "Incremental Static Generation".
My argument would be if we nowadays have fast connections what is the use in cutting off an extra few kilobytes when we have extremely fast internet? Seems this is useful for 1998 connections and 3G phone services. Your opinions go!
It's not just a few extra KB though. The browser has to parse all the JS (including all of the React library) then run your app, create a VDOM and compare it against the existing DOM. So it's now _just_ about slow connections, it's also about slow devices. Not everyone has the latest iPhone.
@@jherr I understand and I'm all for performance but is it really going to be an issue in 2 years from now? I feel these technologies are awesome but a bit too late to the party, would have been nice to have this in 2008
@@yehudz Certainly for small companies and apps that's probably true. For the big eCommerce that look at performance vs conversions metrics then they will care about that stuff. Universally though I think React folks should understand hydration and where and when the processing is done so that they can move the bulk of the heavy lifting back to the server.
Almost convinced to port my nextjs portfolio to Astro, then calmed myself down, I have other things to do. Great video as always.
😂😂😂
Your day have only 24h? How usual it is... 😁
Since mine is nuxt i think i will port.. nuxt is bad...
Unpopular opinion: I honestly don't know why frameworks creators focus so much on gaining few ms on page load. I mean, yes TTI is important. But who cares about getting from 40ms to 10ms? Not the users.
Of course users want fast TTI, but Angular/React/Vue/Svelte already provide that!
Users want bug-free apps and great UX. And these come with frameworks that provide great DX. We, developers, want to add/modify/delete features fast and with no side effects. We want to manage our states between components/pages with ease and without spaghetti code. We want to be able to make our apps to SCALE!
Answer: Page Experience Signals
So what was the owerall performance comparison? Was watching till the end to see the results after you refactpred whole code 😂😅
how does Qwik compare to astro? is it even better?
Hi! Is there a way to save the data fetched from the server to the client state? I don't want to make use of prop drilling. And I also need getStaticPaths.
In Nextjs, I receive the value from the server and save it in the client context
Sure, but in NextJS you do that by taking the props and funneling them into the context. So you are using the props since that is the hydration mechanism of NextJS. You can't set the context in getStaticPaths directly. The same is true with Astro. The hydration mechanism is Astro.props, and then you send those props to any components that need the data, client loading or not, but it's only the client loading components that get those props through hydration as well. Within those components you could then use a context mechanism in frameworks that support context.
@@jherr Okey, maybe you can help me with this please. Check this code:
---
export async function getStaticPaths() { ... }
const { slug } = Astro.params;
const { siteSetting } = await fetchCMSData(slug)
---
But then I cant access siteSetting inside a NavBar's child, because it's undefined on the client (not in the server). I can only access it via prop drilling, but I don't want to, I want to use the react context
@@julianblanco8735 RUclips comments are not the ideal place for this. The discord server discord.gg/3pnS9P6g is better for talking about coding problems with specific examples. But just on its face, Astro only knows to use hydration when you've hinted it with the `client` property. So give that, should Context be getting hydrated on the client?
@@jherr I'll send you a message through discord. Thanks
Awesome, this will push Nextjs to improve their performance!
😂😂😂
@@flavien.bonvin that's right!
Astro + Solid is really the BEST experience I can think of when it comes to Islands. The way Solid provides exportable reactive primitives completely solves any global state issues you run into w Islands. It just makes a ton of sense.
Ok fine, I'll do Astro + Solid on a livestream. :)
Ooooo i was wondering about if that would still work w astro, that's really good to know!
@@jherr yes solid+astro is what I'm looking for as well.
Solid + Astro + a Zero-Runtime CSS framework like Linaria!
@@jherr Thank you!!! :D Linaria? or Mantine?
If you compress your results it'll be even faster. Use astro-compress to do so.
Hmmmm…. My company moving our web frontend to Astro is a definite possibility now. It’s a complex and highly interactive web app with a backend, a lot of reactive state both local and global, conditional rendering based on hundreds of different combinations of data, and a lot of pop-up menus and modals. We’re on NextJS with a mix of CSR for our homepage (basically a feed a la the Facebook feed) and SSR for our [detail] pages. Our performance numbers are in the gutter right now (12 SECOND TTI with slow 3G and 4x throttling and that’s WITH route-based code splitting and many of our components dynamically imported) so a move to Astro is something we would consider to get our performance numbers up but it’s gonna take a lot of research and prototyping to see if Astro can meet the current and future demands of our web frontend.
EDIT: to clarify, I've identified many other optimizations we can do on our current frontend before taking the very drastic step of changing frameworks and as I've said we would have a lot of prototyping to do before we went through with such a thing
Thanks Jack, discovered your videos the past week and absolutely love it!! In my mind the "perfect" front end stack at this moment would be runtime integrated MFEs (using Module Federation) built with React, Astro and Nano Stores (or Jotai if it works in Astro); all deployed on Vercel. My only concern is how a runtime integrated MFE would work with Astro and I am struggling to find anyone having done this. Maybe try this for a future video?
Remember that what makes faster sites is the person between the chair and the PC 😂. However great content Jack as always, thanks for this JS news.
Astro vs Fresh please
Between Theo interviewing Fred just a few days ago and this amazing cross-examination, there is so much well deserved hype over Astro right now! Thanks so much for taking the time to create such meaningful content, Jack!
Look out for an interview that I'm doing on Theo's show i the coming weeks.
@@jherr Met Fred at a small workshop in a smaller town in Sweden. Those guys really do their best to make Astro as good as it possibly can be.
Hi Jack! I am super interested on the performance results after the SSR for astro vs nextjs, could you please share it?
Feel free to download the code and check for yourself.
Thanks for the video and also for providing the code, @jherr. My results comparing the SSR are as follows:
Astro:
22 requests, 33.3kb tx, finish: 7.9s, DOMLoad: 0.183s, Load: 0.500s; LCP avg: 0.93s, FCP avg: 0.4. TBT:
NextJS:
25 requests, 1.6MB tx, finish: 9.0s, DOMLoad: 1.040s, Load: 1.380s; LCP avg: 1.1s, FCP avg: 0.23s.
Astro showed a very small edge over Next in overall LightHouse performance score (98 vs 97) and that primarily is because of better LCP. However Next performed better in Speed Index, and Time to Interact.
@@jherr Thank you for all the hard work. I have posted my stats to this comment.
Interesting video as always! Love your enthusiasm. Congrats on 70k ;)
Thanks so much!
Astro is insanely good :D This might be the next big thing in the front-end dev world :D
~90k downloads per week after a year is sad i think, but still it has potential.
This content is awesome, i would love to see a Astro course!!!
First it was React, then Nextjs, then Solid... sign... here I go redesigning my website again 🤗
Astro shows a lot of potential, but it's still too buggy imo to use outside of personal projects. But this might be my go to framework in the future to build websites once it has become more stable
Hi Jack, did you know, that you can disable the client runtime in Next.js? Just add the following export to your page file "export const config = {unstable_runtimeJS:false}"
Sure, but that would get rid of all the code on the page. So it's all or none. What if we want some of the JS? Selectively.
Astro vs Fresh vs Hugo ???
developers ain't loyal 🤣
Just reading through the Astro Docs for the first time... When using React and Astro together it looks like there will be some context switching due to the differences in JSX and Astro templates.
Mr.jack, Hope u & your family doing good😊.. worth watching, thanks for making this ❤️
Thank you so much for the quality content Jack, We love you.
you need a time complexity of O-450000 to even see a tiny difference in performance for an average user. useless
Astro is an offramp if I've ever seen one (Surma: The cost of convenience). Warning, Gen 3 (Igor Minar) approaching!
Great stuff Jack as always.
Exactly what I needed. You da man. Subscribed
thanks for sharing this
ohhh no Pokemon again!!
exactly what i was waiting for
Can we create large scale projects with astro like dashboards and saas projects?
Love the content you're putting out Jack! Very informative and straight forward, love it. Video idea: show us your setup (computer, accessories etc!)
For people like me, living in the Mexican jungle and having at best a 3G connection (which is standard for most humans on earth btw), this is a very welcome speed-up! :)
Fantastic to see what's the fuzz about with astro. It looks really nice to work with. Thx Jack for making this video 💪
The only thing I don't like here is the syntax of Astro, it looks pretty weird to me
Apart from the --- it's pretty standard jsx-like html and js no?
@@bigmistqke it's also similar to Svelte
Hmmm, not allowing to do on a per route choice of which rendering technique is really a bummer :(
I know this video is almost a year old but have you done a similar comparison between Astro with Svelte island and SvelteKit?
I'm gonna hold off upgrading till it's something other than 1.0
Wow! Thank you! I am old school and have been trying to get into newer tech. This helped give me great context as well as got me off the ground.
Jack, thank you for the video. It's interesting as always.
Could you share your dotfiles, please?
Which dotfiles are you looking for?
Has the app to be server side rendered after installing Node? So I can't have static pages then anymore?
Not sure currently, but when I made this video it was either/or you were either server rendered (SSR) or static (SSG). You couldn't have both at the same time.
@@jherr Thank you for the answer, but at least it seemed pretty easy to switch if necessary.
One remark:
I was hoping for a little perfomance comparison at the end. I mean to compare the Astra and NextJs apps at the end, when both were SSR 😅. Besides that I really liked the video, because of it I subbed :)
@@stillready6405 Hmm, I thought I gave those numbers. As I recall when Astro was changed to SSR the numbers were similar to NextJS. That being said, total "time to interactive" (TTI) should be much better on Astro, in particular with preact, because of the reduced bundle size and reduce amount of hydration work on the client. And that time to interactive is actually the truly important score.
but component query is very good but u r so late that i sucide
Can u please make a video on preserving and resetting the state in react
6.69 second time to interactive. Nice
Who doesn't like a pokey site?
Next 13 vs Astro
which one will be better, specifically faster for static sites?
Static sites? Astro. Astro + preact.
Thanks for the nice explanation. I don't think the comparison is very fair because you can disable JS and Next will still load the site the same way as Astro does it. Using the "Load" measure in network tab of Chrome (as you did) only calculates the downloaded resources. But Next will still show content even before the JS is loaded/parsed. So effectively they should be the same.
The reason your second test is slower is because of the extra JSON that Nextjs needs to have in the HTML directly as per hydration. This is an ongoing topic in the Next community. Once you add some kind of real-world interactivity with Astro you will want to somehow access the data on the page - say the list of pokemons. This will anyway require a server roundtrip to get the JSON; whereas with Next it's already there.
With respect, I disagree. I bent over backwards to make this test as fair as possible. In regards to disabling JS, I suppose you could do that, but that would disable the JS on the Login button. It's a sledgehammer approach. And would we want tell customers to disable JS on their browsers?
As for the accessing the list of Pokemon, sure, that would normalize it. But that wasn't the test. The "report" of Pokemon is non-interactive. NextJS makes me pay the freight on non-interactive content and doesn't give me the choice. Astro gives that choice. Of course I get that NextJS and the React core team are working on this, but that doesn't change the fact that this is the state of the technology choices today.
From 9:38 it’s a déjà vu. Wasn’t Fresh doing that? If Fresh chose to imitate Astro with islands, means that Astro is worth be investigated.
Islands architecture is just an architecture. It's good to see that there are multiple implementations of it.
@jack you totally look like donald trump👍
Hey just wondering how to have a dev setup like urs Jack?
I will definitely do a video on that some day. Maybe after 100K subs.
@@jherr btw what is the editor theme u are using ?
@@RudraSingh-pb5ls Night Wolf [black] and JETBrains Mono
Does Next.js use Express under the hood in these samples? If so, that could explain some of the slow response times.
The static response is very fast and only a small fraction of the overall TTI. So even a much faster server would only make a tiny dent.
this is awesome. thanks for sharing.
This reminds me of aspx
Ouch?
bro I have one doubt that is we are integrating ssr with redux toolkit. So for example crud application is there , in create method we are giving dispatch in getserversideprops and here comes my doubt in handlesubmit how to give the dispatch
hold up you didn't even compare the performance between the larger apps. Come on Jack
Came here after watching your talk with Theo, it’s been VERY satisfying so far 😎
You’re awesome @jack!
great. Instead of learning astro lets wait until nextjs matches his time to this and finally crushes Astro xD
Can you make a video comparing Qwik to Astro?
how does your vscode terminal look like that? fancy 🥵
My favorite thing solidjs 🤩🤩🤩
good stuff
Jack! Check out $mol framework - pure reactivity
7:21 pure joy
Wohoo new video..
yet another amazing content
Is there a situation where Next would be better than Astro?
IMHO, the either/or static vs ssr problem is real. It's a huge architecture win that Next can do SSR on some routes, and SSG/ISG on others. Also Astro currently doesn't have a deployment or ISG story the way Next/Vercel does.
Also, it's not like NextJS is unaware of the hydration issue. They are working on their own partial rehydration/islands architectural option as well.
Also, the DX of Astro needs work. It's in 1.0.
NextJS would always be better than this in many circumstances- regardless of what this shows. They have a huge team working on it and an even larger community and it’s always improving. They have just to ensure things are done properly before they get publicly release. For Astro to match it it’d be very difficult
@@clublati That's demonstrably untrue. As a community we've been waiting for over a year for Vercel/NextJS to make the minor changes required to support Module Federation. They have even committed to doing so. But it hasn't happened.
I am a NextJS fan. I chose and use NextJS on my current project at work. But I am under no illusion that I (or honestly the community) is in control of the direction of NextJS. Vercel is. And if what you are making aligns well with that architecture then you'll have an easier time of it. But if not, then there are very decent alternatives, like this one. And those alternative projects should not be written off just because of the size of the backing company or community.
@@jherr with Vercel's Build API, Astro might narrow the gap even more.
And they can do some pretty wild things with deployment and Astro. They've got it working in service workers, web workers, edge functions and all of that.
@@IainSimmons Exciting times!
Excellent content 👍🏼
Hi Jack, thank you very much for the amazing content 😍
I have question about nx monorepo
How I can run next js app within the monorepo silently in the background something like pm2 or detached
Thank you very much in advance
Best,
Ghassan
Nice!
nextjs and nestjs deploy on vercel video upload please
two are different things . how can you compare server side rendered next js to static site builder astro lmao
Did you watch the video? I put Astro into SSR mode.
@@jherr sry my bad. later I watched the video and understood.
this to me looks like the server and client components React and NextJS they are trying to do
maybe smbd already ask it, but what is is ur editor theme?
Frameworks war!
Look like on Speed they already won
awesome video Jack, as always .Can we use state management packages, since its mostly SSR, I suppose we can't share state across pages?
Look for Indexed DB and packages wrapping it (e.g. idb-keyval, Dexie.js).
@@PeerReynders thanks mate!
Looks faster than Remix
31:27 the perfect that's what she said
is this argument still valid with the latest version of next?
Yes. App Router in NextJS 13.4 is going towards an island architecture, but from a performance standpoint still isn't there.
@@jherr Damn, I already started my most recent project or work on NextJs 🤣. But imo I feel like NextJs will be here in 5 years while Astro... not sure.. so the assurance of maintainability in the future sort of outweighs performance right now.
@@underflowexception Yeah, I'm certainly not saying don't use NextJS. I'm just saying that at this point (6/22/23) Astro is still outperforming NextJS. Take from that what you will.
So. Is Vercel going to support Astrojs? 🤣
They already do. Vercel support a ton of frameworks, and have been making moves to share some of the previously Next.js-only features with any framework that's willing to implement them.
It all drives traffic and support to Vercel, so it makes sense.
Would like to see a video with sharing state across components and pages in Astro. Not sure if it's possible, I checked out their documentation, and I think it's possible unless I'm wrong.
Within a page, it's very possible, they have a whole section of their documentation that talks about using nanostores to do state sharing. Between pages would need to be accomplished using cookies or session state or something like that. I don't think Astro is a SPA by default.
@@jherr I briefly read about nanostores inside the Astro documentation, reminded of Jotai in some ways. It's one of those things I just got to get my hands wet with to see what is like and invest some time into it when I get time 🙂
@@quelchx Oh, it's exactly a Jotai, but better in some ways. Jotai is hard-bound to React, which means you can't use it in preact/vue/etc. like you can Nanostores. And I also think that some of the nanostores API, like computed, is a little easier to reason about. That being said, nanostores doesn't have the integrations that Jotai does. So you win some, you lose some. But great libraries all around. And a great model for state storage.
@@jherr thanks for the information. I think maybe I will dive into and see what I can do with it and have some fun
your vidoes are the best
How would you combine SSG w a CMS?
You'd want the CMS to post to a webhook whenever the context change to trigger a build of the relevant page and a push to the static host.
@@jherr oh i thought the answer was gonna be that u still had to fetch the data from the SSG'd site, but so there is actually a way how to build all the pages, data included? I would be really interested in a video about this!
How to integrate CMS's in my workflow has been the biggest struggle i have been facing lately. There is very little content about it, in comparison w other web-related stuff. It's also such a wasteland, w so many over expensive solutions, or abandoned projects. I recently played around w payloadcms and quite liked it, as it is for free as you can self-host, and quite like how you can write the schemas to describe the data/UI.
@@bigmistqke yeah, that's way the whole `getStaticPaths` thing is about. You are returning to astro a list of all of the pages to statically generate along with the data for each page. NextJS has exactly the same mechanism. But Vercel/NextJS also have the infrastructure to request that a single page is refreshed, as opposed to all the pages. That is called "Incremental Static Generation".
@@jherr gotcha! Thanks for the fast reply!
@@bigmistqke This is how we do it. open.spotify.com/track/6uQKuonTU8VKBz5SHZuQXD?si=ee12c4b357aa44e7
This all sound amazing! Next.js is ok but so much unnecessary Javascript
My argument would be if we nowadays have fast connections what is the use in cutting off an extra few kilobytes when we have extremely fast internet? Seems this is useful for 1998 connections and 3G phone services. Your opinions go!
It's not just a few extra KB though. The browser has to parse all the JS (including all of the React library) then run your app, create a VDOM and compare it against the existing DOM. So it's now _just_ about slow connections, it's also about slow devices. Not everyone has the latest iPhone.
@@jherr I understand and I'm all for performance but is it really going to be an issue in 2 years from now? I feel these technologies are awesome but a bit too late to the party, would have been nice to have this in 2008
@@yehudz Certainly for small companies and apps that's probably true. For the big eCommerce that look at performance vs conversions metrics then they will care about that stuff.
Universally though I think React folks should understand hydration and where and when the processing is done so that they can move the bulk of the heavy lifting back to the server.
Think about SEO as well. Google rewards faster sites.
Interesting! Things could change if React Server Components ever see the light