So I feel like the preloading of content here was the main driver of what actually made the site significantly better to use. The other improvements seem much more marginal comparatively, but you make a great point about how those improvements become much more important without a fast connection
I think I remember a Vercel keynote where they showed how to _quite easily_ configure NextJs to use Preact instead of React, in case anyone was wondering if it was possible.
You can, and it's easy. Though, you have to use preact/compat which is a compatibility layer to make it more React like. And this makes Preact "much" bigger. Using "raw" Preact is what really saves on size and speed and that is not available to use with Next. This isn't mentioned a lot, but Preact vs Preact w/ compat is two rather different approaches.
Having used it it cuts out about 40kb from my initial page load. (103kb to 64.5 kb). The problem though is that as of today it’s not compatible with react 18 because of streaming SSR support. There’s an open PR but you have to stick with next 12 or patch next13 and not use the beta features.
Mm. Sort of surprised trpc also has performance implications. I was assuming it was just a typesafe wrapper over REST-calls. Are there any performance metrics out there?
the correct term for the problem is "Overengineering" :) We should always strive to find a simple and elegant solution to our problems keeping in mind the overall features.
Yes, Astro has fast initial page loads with little JS, but at the cost of so many other things. If you navigate the Next docs, every transition feels instant and there is no flickering or layout shifts. Client-side navigation and smart prefetching is the superior approach. Astro page transitions in comparison are noticeably slower and flicker flicker everywhere. I don't get the hype.
I think this boils down to implementation. You can make astro islands hydrate on load to behave just like a react app, most just choose to make it load when the client is idle or when everything else is done. I think it's something that will get refined over time, as Astro is still incredibly new. Package sizes being tremendously smaller is huge for SEO and any web pages concerned with sales or conversion rates. Next JS is still superior for anything that isn't trying to sell you a product or service.
How does it wrk in terms of fetching thins from a backend? Will it be part of rendered DOM or will it be part of he JS virtual DOM so in terms of SEO there will be difficulties? For example I want to fetch posts from the Strapi backend - will it be "server-side rendered"?
I know excalidraw from your streams and another youtube guy I used to work with and I think it's pretty awesome. I don't have enough usage to make it worth paying for. But it's great for little diagrams. Totally worth getting used to!
Great examle, great execution, great video! One could actually make it even FASTER, on ANY stack, have any ideas on what I have in mind? Will post here a gist with demo in a few days..
@@romanmunar this stack with astro instead of next feels good for hobby small apps. I still think anything ssr should use something like next or sveltekit (even though astro does allow ssr) as other frameworks are more mature in ssr, whereas static site generation is like an arena where constantly new players are dropping in to fight. So if I were to make a static site, I would use astro, and if it would require a proper server, I would go with next or deno as deno seems promising and elegant. Not to mention their hosting service is very good.
@@krishgarg2806 I would as well butthey have different selling points. Next is great for js heavy apps that needs to show something to the user fast and handle the rest in the client. In the other hand, Astro is great for sites that just need enough js for interactivity. Theo drew a chart about this he also covered Remix and PWAs there.
Wth Theo?!? You make the site faster... but never pushed it? First load seems to have the t3 version, with cold start, slow loading between votes, and blurred pixel art. Oh, and I'd also make the site fit on a single screen for mobile. One of the Pokémon always gets cut off on my iPhone.
![АЛАУДИНОВ у Скабеевой: эти их ВСУ нас НЕ ДОГОНЯТ 😁 [Пародия]](http://i.ytimg.com/vi/an0anqU4WGQ/mqdefault.jpg)
So I feel like the preloading of content here was the main driver of what actually made the site significantly better to use. The other improvements seem much more marginal comparatively, but you make a great point about how those improvements become much more important without a fast connection
Preloading and dropping getServerSideProps (and thereby skipping the cold starts). Everything else was marginal improvements but fun as a flex
So just dont be poor and pay for no cold starts? /end sarcasm/
@@elraito lol
@elraito don't be poor just hire someone to rewrite your app in zig
I think I remember a Vercel keynote where they showed how to _quite easily_ configure NextJs to use Preact instead of React, in case anyone was wondering if it was possible.
You can, and it's easy. Though, you have to use preact/compat which is a compatibility layer to make it more React like. And this makes Preact "much" bigger. Using "raw" Preact is what really saves on size and speed and that is not available to use with Next. This isn't mentioned a lot, but Preact vs Preact w/ compat is two rather different approaches.
Having used it it cuts out about 40kb from my initial page load. (103kb to 64.5 kb). The problem though is that as of today it’s not compatible with react 18 because of streaming SSR support. There’s an open PR but you have to stick with next 12 or patch next13 and not use the beta features.
Oh snap I'd like to make my NextJS app BLAZINGLY FAST, let's see how he did it...
Oh... he did it by not using NextJS... :(
Mm. Sort of surprised trpc also has performance implications. I was assuming it was just a typesafe wrapper over REST-calls. Are there any performance metrics out there?
Very nice! I’d love to see how this would compare to a resumable implementation with something like qwik or marko.
Voltorb is literally a ball. I think it takes the cake, no?
Would you bring in tRPC if the website has more APIs to call, with complex parameters?
the correct term for the problem is "Overengineering" :) We should always strive to find a simple and elegant solution to our problems keeping in mind the overall features.
Lmao on the Deno has Preact bundled in it comment. Ahahahahahahahahahah
why did you not use cloudflare kv/durable objects and why not cf pages?
Took a lot of notes from this, great job Theo
I think that guy who commented that preact comes in bundled with deno has purchased his tech stack.
I wonder if Fresh with deno deploy would fare better or the same
better.
It was not an optimisation, t3 stack was an overkill for such almost hello world grade app.
True lol
Yes, Astro has fast initial page loads with little JS, but at the cost of so many other things. If you navigate the Next docs, every transition feels instant and there is no flickering or layout shifts. Client-side navigation and smart prefetching is the superior approach. Astro page transitions in comparison are noticeably slower and flicker flicker everywhere. I don't get the hype.
I think this boils down to implementation. You can make astro islands hydrate on load to behave just like a react app, most just choose to make it load when the client is idle or when everything else is done. I think it's something that will get refined over time, as Astro is still incredibly new.
Package sizes being tremendously smaller is huge for SEO and any web pages concerned with sales or conversion rates. Next JS is still superior for anything that isn't trying to sell you a product or service.
Preact, React, Postact, Next.js,Before.js, Post human.js same sh*t same different story.
Ooooooo that ending was incredible- and 20 euros 🔥
25:56 Lmfao why are these not shorts.
How does it wrk in terms of fetching thins from a backend? Will it be part of rendered DOM or will it be part of he JS virtual DOM so in terms of SEO there will be difficulties? For example I want to fetch posts from the Strapi backend - will it be "server-side rendered"?
8:45 how did i not know that shortcut for clearing cache
Wow the speed differences are magnificent 😮👏🏾
i'm not a JS purist, but i think this could have been easily done eith vanilla. faster, and maybe even less code.
I know excalidraw from your streams and another youtube guy I used to work with and I think it's pretty awesome. I don't have enough usage to make it worth paying for. But it's great for little diagrams. Totally worth getting used to!
Great job, small advice all above that - stop using FC like that, just try it :)
the API endpoints are deployed to CF workers? I didn't see any wrangler stuff, how is that deployed?
Hi Theo! When will you be dropping a hair tutorial? And don't say you don't make tutorials
can u share ur terminal configuration?
Great examle, great execution, great video! One could actually make it even FASTER, on ANY stack, have any ideas on what I have in mind? Will post here a gist with demo in a few days..
This was such a feel-good one :)
Fastack should be the stack’s name…..
the videos sound design was kind of odd n so extra fluff could of been cut down, good video tho.
This stack feels more cohesive than t3
It absolutely is not and building this was so much harder than any t3 app tbh
@@romanmunar this stack with astro instead of next feels good for hobby small apps. I still think anything ssr should use something like next or sveltekit (even though astro does allow ssr) as other frameworks are more mature in ssr, whereas static site generation is like an arena where constantly new players are dropping in to fight.
So if I were to make a static site, I would use astro, and if it would require a proper server, I would go with next or deno as deno seems promising and elegant. Not to mention their hosting service is very good.
@@krishgarg2806 I would as well butthey have different selling points. Next is great for js heavy apps that needs to show something to the user fast and handle the rest in the client. In the other hand, Astro is great for sites that just need enough js for interactivity. Theo drew a chart about this he also covered Remix and PWAs there.
I hope to one day have your level of understanding of the technology being used 🙏
Wth Theo?!?
You make the site faster... but never pushed it? First load seems to have the t3 version, with cold start, slow loading between votes, and blurred pixel art.
Oh, and I'd also make the site fit on a single screen for mobile. One of the Pokémon always gets cut off on my iPhone.
faster-round.t3.gg :)
T3 Stack is dead.
Long live PARP Stack !
(Preact Astro Redis Planetscale)
Thank you for your interest in the bleeding edge technology.
Hey Theo, you said "...before I knew how to stream... it's a little cringe, but...'. Can you do a video on tips regarding streaming.
prime will sue
so cool , love your videos.
I subscribe you
💚💚💚
Second comment lol
!typesafety == more perforfamce?