My Favorite Open-Source Next.js Project for 2024
JTJosh tried coding@joshtriedcoding · 174K subscribers
- Views
- 43K
- 42,985
- Outlier
- ×1.0
- Median 43.3K
- Length
- 17:33
- Published
- Nov 9, 2024
- Saturday
- Comments
- 101
- 1.5K likes
Script
How it's written
- Words
- 3,260
- Words a minute
- 187
- Reading time
- 14 min
- Segments
- 12
The hook
0:00–0:26what I'm about to share with you is the coolest open-source repository that I have seen this year it's not only the fastest website I have ever seen on its own but it's also built in nextjs I don't use the term coolest open source project of the Year lightly man and in this case I really mean it so how did they do it and that is a good question why is this page so fast I've listed Five Points here now to understand what this page is about we have to understand
Structure
what I'm about to share with you is the coolest open-source repository that I have seen this year it's not only the fastest website I have ever seen on its own but it's also built in nextjs I don't use the term coolest open source project of the Year lightly man and in this case I really mean it so how did they do it and that is a good question why is this page so fast I've listed Five Points here now to understand what this page is about we have to understand what this page is inspired by there was a YouTube video a while ago from West boss where he reviewed this website right here it's like a Car Part website and it seems really old right if we just take a look at this website but as we navigate around even with my pretty bad internet connection you can see the navigations are almost instant there's like a small loading spinner but as we click through things here you can see the navigation happens really really fast on this very old car Part website but even faster in this new open source project that I want to show you called very appropriately next faster right here this is a GitHub repository an open source project made by Ethan niser we're going to go through the website here together and two other people that is Ry Sullivan and arman's code and these three guys have written some amazing code that I want to go through together with you a highly performed e-commerce template using nexs arguably even faster than the car part website that I want to
Watch from 0:00show you right so this is the website let me zoom in here a bit and as we navigate around two things happen first off the navigation is absolutely instant like I don't have good internet and as I click around right here this this video is not sped up like this is real time navigation on this website it's incredibly fast like incredibly fast right and another thing that's happening is that the images are instantly there pay attention to the images on page load right so as I click a category here check out what happens the images don't even load and the way in which they achiev that is really clever really really clever we're going to get there and that is a big part of why this website feels so fast right both the data and the images are both there at the same time which is instantly on navigation so how does that work right how can we learn from this and Implement that into our own apps and step number one to how this is so fast we're going to dive into the code together is partial pre-rendering this is a rendering strategy that this page uses to display the content that you can see on the page right here it's a very new thing and it's been documented in nextjs but only available for the absolutely newest version which is nexj S15 right it's a very new experimental feature that this app is already using and it sounds complicated right partial pre-rendering but all it means is that we split up the entire page into the Dynamic here marked in blue and static
Watch from 1:30sections here marked in purple what this allows us to do is to serve the purple part from a CDN and only send along the dynamic part right here from the server on request and actually calculate the dynamic content how that works in practice is really really easy what we can do is just have static code anywhere like divs or lists or whatever it might be in or component and wrap the dynamic Parts in suspense and the partial pre-rendering will automatically take effect what that means in code for the partial pre-rendering is that for example in the main root layout file that we have in nextjs this is served from The Edge from a CDN if you deploy to versel for example and only the suspense part right here which is equivalent to the blue part that we saw earlier is now dynamically inserted into our page right and that doesn't even go for the fallback the fallback is also served from a CDN and included in the partial pre-rendering so as much content as possible anything that static is served right from a CDN and doesn't even need to be calculated at runtime number two is aggressive prefetching and this is one of the most important parts by far of this app so check out what happens as we navigate the page and I'm going to open up the um Network Tools here so as we hover over elements you can see right here in the all tab the network goes crazy like absolutely crazy right as I hover this you can see it's completely spammed with requests and also if we hover really fast over a
Watch from 3:03category and then move our Mouse away again the requests are going to be cancelled right so only if our Mouse is over a certain category for a certain period of time all the images that come when we click on that category are pre-loaded in our browser to instantly be there when we navigate right and you can see the tradeoff that we take here the trade-off is basically this we want our images to load instantly so we want performance but what we sacrifice for that performance is on the other end infrastructure because we put a lot of load on our infra each request that we make right here in the app is essentially an API call that we make to our own service and you can see how many requests like hundreds of requests per second as I hover over this 1,300 and then 1,550 like 200 requests per second all that load goes to infra but the trade-off is that we basically get instant navigation right so it's choose one right imagine you have a DOT right here and you can move it from the left to the right the more load you put on your infra the more aggressive that you prefetch information pre-load images the more performance you're going to get and if you want the infrastructure to remain chill right to not spam your API with 200 requests per second then of course the performance is going to suffer and the trade-off that this website takes is very interesting because it's the exact end of the spectrum right it's literally full performance and it does not care about infrastructure load which I really
Watch from 4:34admire right because the results are very very clear and how that prefetching is done in code is probably even more interesting so basically how this works is that they have written a custom link component you can see for example where we use this link component is right here for each product card that we have right we've got a link component with a prefetch value of two and this prefetch fetches the images for the path in the link how that's done in code is a bit more complicated but really really interesting so this is the link component it extends on the base nextjs link component and by default we don't prefetch any images right it's an empty array but then as the page loads as we render there's a use effect running with a intersection Observer pre-rendering all images that are in the viewport and we can see that once we refresh the page already a lot of images are PR loaded without me hovering over anything right just on load this use effect is responsible for prefetching the visible pages and their images that's strategy number one we render on visibility and strategy number two is on Mouse enter so when we hover something then we actually go ahead and prefetch these images how the prefetching works is inside of an API route and is super interesting because this literally only works because everything about this app is statically served right we get the HTML for each page directly from the server this is nothing that happens on the client side it's completely static therefore what we can
Watch from 6:06do is in this API route responsible for prefetching images we can just go ahead construct the URL to the page that we want to prefetch and server site pars the HTML extract all the images from the main tag and return all images with their Source set sizes Source alt and loading property back to the client and that's the funny thing once we return them back to the client we just right here put them in our browser and actually render or load them right so they're already loaded and then when we navigate to the page bam they're already going to be pre-rendered right here for us and that's something that the next MasterCard website for example doesn't do right the images are not immediately there they are really fast but you can see they load after in the next shares website this open source project that not the case right here as we hover the only thing that we are preloading our images as we click on these we can see the preview of each image show up right here on the right hand side we're not actually making any database calls right we're just making calls to images and we don't make database calls because we use static prems this is a completely static project right the database call is done once then we save the page statically we don't expect any updates that's why we don't even need to to make database calls at runtime right here cuz all the data is already in there and just revalidates every 2 hours in this app which is really really clever to make this fast this prefetching goes
Watch from 7:39extremely well together with Point number three which is aggressive caching so on both of these fronts we are super aggressive and that pays out but it also comes with a big tradeoff this website is meant to be static users can't insert their own products here or anything like that if they were we would be inside of a dynamic app and this caching could really really backfire because it gets quite complex very fast and that's done in the unstable cache component right here basically we're using a builtin server site nextjs cache which is the next unstable cache or in next S15 the use cache directive and then the react cache that handles the duplication for us and what that allows us to do this unstable cache is well let's see where we use it basically for any database cost when we do have to make a database call which is with postgress in this project under the hood then two things happen first off we cash the result and second off we also give the cash a revalidation period so if we have to make a database call which we really want to avoid to be honest because that is slow right that's the slowness part of this app therefore we make them only every two hours at most and if we are forced to do it then we also cash the result right so it really makes the best of these dat database calls but that's the reason why users can't insert their own products here would really hit the fan because that product wouldn't be visible in the store for at least two hours right and the trade-off here is user
Watch from 9:11experience versus speed right all dials are completely performance focused in this app which I think fits the point but it also comes with a trade-off of dynamic content not really being possible here so that's one thing we have to keep in mind right if you have a dynamic app chances are you can't Implement all the performance from this app as they are into your own app but also that's not really the point of this app fourth point is that this project avoids database joins so if we are actually forced to make a database call not only do we cach it super aggressively but we also make a really simple database calls there are not a lot of joints in here take a look at this there's just a products F many call there's a collections Fight Man call these are as simple as database calls yet pretty much right with a wear condition up here not even a wear condition here just an order by database calls by themselves don't even get much faster than that and we also see that there is one join I believe it was further down here let's search for it yeah right here the left join left join left join this is very unusual to see for this project and they even annotate as a comment I found that really cool could be optimized by storing the category slug on the product table so that we don't need to join it together we avoid even more joints and to be honest man joints are pretty fast right SQL or postgress are really well optimized for joints and even this
Watch from 10:42consideration shows how important speed was for them to even avoid that right to just make a simple query um but that's Point number four and lastly pretty simple point they also use a fast omm they use drizzle if you're not familiar with Drizzle basically um it's unlike Prisma omm it doesn't ship its own huge query engine um but instead we Define our database schema just in typescript right so take a look at this we just Define or postgress tables like this right the categories table has these um properties right here and it's basically faster than Prisma because it doesn't ship a huge query engine and that just adds to the whole speed aspect of this and also by the way makes this project easy to deploy to Cloud FL workers and not just for sale if you want now why did I Mark these two as especially useful because these are the easiest to transfer to your own apps if you don't want experimental features if you don't want to change your database schema heavily just for the sake of performance and if you also don't want to change your orm or are already using a fast orm these are probably the easiest to implement with the biggest impact on your app so let me show you what I did basically I built my own little project here and I think that's under Local Host 300 ,000 yes and let's go to slash people right all that does is and also by the way notice the speed here I'm going to reload the page that is already really really fast but the navigation is the more important part right it's
Watch from 12:12basically a list of people that we can follow just random people names that are made up and as we navigate here let's go to Terry dibert as I click the navigation is almost instant you can see the image is not because that's a challenge of a dynamic app that most apps just are right but as we navigate here let's click Bessie Meyer the navigation check this out happens almost instantly I'm just going to click some names right here you can see how fast this is right it's basically the same as in the next faster app but that's the main difference this website does not have the constraint of being so static right you can do whatever you want in here you can integrate this as is into your own apps right into your Dynamic apps and don't have to change everything for the sake of performance now how does it work basically with the two points that I mentioned right those were the extremely aggressive prefetching and extremely aggressive caching right putting load on or infra and getting speed in return for let's reload the page and see how this works as we hover over entries right here you can see two things happen we prefetch the information about this person we are about to click on and we also pre-load their image so it's loaded faster in the browser to be honest I'm not 100% sure if that even works uh because the image still sometimes loads a bit longer when we're on the site it's not instantly there sometimes but the data always is because we aggressively preload it on Hover so as we click on an entry even if
Watch from 13:44we have never opened it before right here bam it's instantly there fully client side that's what the other app can't do which is also what the other app was never even meant to do it works very similarly in the link component right I just got inspired by that app and kind of wrote my own implementation to prefetch right so we prefetch if the mouse cursor is over an entry for longer than 50 milliseconds right so we don't completely spam if we just go really fast here not all entries are preloaded but as you can see if we go slower they are that's just a personal decision I would make in a production app I would not completely spam the API for every hover but only for the ones above 50 milliseconds that user is actually likely to click on you know for each route right here here we have a query key so we can identify this in or Cache using react query and a query function to get the data that we have on that page which essentially is just right here the name the handle the bio the amount of followers and so on this is just data coming from upsd rdis and that ties into the uh third point right here aggressive caching this is served from a upd r is cache globally distributed and fast anywhere full disclosure I work there this is not like an advertisement is just the solution I actually like to use for this um because it's really fast right so even if we do have to make database queries where preloading is not possible like directly navigating to this page for example then still the data loads really fast because it's loaded from reddis and not a postgress
Watch from 15:14database yo I really hope you enjoyed this video go ahead I encourage you dig through the repository and learn for yourself that's one of the best approaches to learning just going through a repo and see the code for yourself experimenting with it if you find anything where you say hey Josh why didn't you talk about that this makes the website much faster and you missed it in the video yes chances are I missed it let me know in the comments down below and also let me know your thoughts generally did you know this was possible honestly I didn't I really hope you enjoyed the video and take this for your next project cuz that's what it's for man so I'm going to see you in the next one until then have a good one and bye-bye
Watch from 16:47Full transcript
- 0:00
what I'm about to share with you is the coolest open-source repository that I have seen this year it's not only the fastest website I have ever seen on its own but it's also built in nextjs I don't use the term coolest open source project of the Year lightly man and in this case I really mean it so how did they do it and that is a good question
- 0:20
why is this page so fast I've listed Five Points here now to understand what this page is about we have to understand what this page is inspired by there was a YouTube video a while ago from West boss where he reviewed this website right here it's like a Car Part website and it seems really old right if we just take a look at this website but as we
- 0:42
navigate around even with my pretty bad internet connection you can see the navigations are almost instant there's like a small loading spinner but as we click through things here you can see the navigation happens really really fast on this very old car Part website but even faster in this new open source
- 1:02
project that I want to show you called very appropriately next faster right here this is a GitHub repository an open source project made by Ethan niser we're going to go through the website here together and two other people that is Ry Sullivan and arman's code and these three guys have written some amazing code that I want to go through together
- 1:22
with you a highly performed e-commerce template using nexs arguably even faster than the car part website that I want to show you right so this is the website let me zoom in here a bit and as we navigate around two things happen first off the navigation is absolutely instant like I don't have good internet and as I
- 1:43
click around right here this this video is not sped up like this is real time navigation on this website it's incredibly fast like incredibly fast right and another thing that's happening is that the images are instantly there pay attention to the images on page load right so as I click a category here
- 2:04
check out what happens the images don't even load and the way in which they achiev that is really clever really really clever we're going to get there and that is a big part of why this website feels so fast right both the data and the images are both there at the same time which is instantly on navigation so how does that work right how can we learn from this and Implement
- 2:26
that into our own apps and step number one to how this is so fast we're going to dive into the code together is partial pre-rendering this is a rendering strategy that this page uses to display the content that you can see on the page right here it's a very new thing and it's been documented in nextjs but only available for the absolutely
- 2:47
newest version which is nexj S15 right it's a very new experimental feature that this app is already using and it sounds complicated right partial pre-rendering but all it means is that we split up the entire page into the Dynamic here marked in blue and static sections here marked in purple what this allows us to do is to serve the purple
- 3:08
part from a CDN and only send along the dynamic part right here from the server on request and actually calculate the dynamic content how that works in practice is really really easy what we can do is just have static code anywhere like divs or lists or whatever it might be in or component and wrap the dynamic
- 3:28
Parts in suspense and the partial pre-rendering will automatically take effect what that means in code for the partial pre-rendering is that for example in the main root layout file that we have in nextjs this is served from The Edge from a CDN if you deploy to versel for example and only the suspense part right here which is equivalent to the blue part that we saw
- 3:49
earlier is now dynamically inserted into our page right and that doesn't even go for the fallback the fallback is also served from a CDN and included in the partial pre-rendering so as much content as possible anything that static is served right from a CDN and doesn't even need to be calculated at runtime number two is aggressive prefetching and this
- 4:10
is one of the most important parts by far of this app so check out what happens as we navigate the page and I'm going to open up the um Network Tools here so as we hover over elements you can see right here in the all tab the network goes crazy like absolutely crazy right as I hover this you can see it's completely spammed with requests and
- 4:32
also if we hover really fast over a category and then move our Mouse away again the requests are going to be cancelled right so only if our Mouse is over a certain category for a certain period of time all the images that come when we click on that category are pre-loaded in our browser to instantly be there when we navigate right and you
- 4:52
can see the tradeoff that we take here the trade-off is basically this we want our images to load instantly so we want performance but what we sacrifice for that performance is on the other end infrastructure because we put a lot of load on our infra each request that we make right here in the app is
- 5:13
essentially an API call that we make to our own service and you can see how many requests like hundreds of requests per second as I hover over this 1,300 and then 1,550 like 200 requests per second all that load goes to infra but the trade-off is that we basically get instant navigation right so it's choose
- 5:34
one right imagine you have a DOT right here and you can move it from the left to the right the more load you put on your infra the more aggressive that you prefetch information pre-load images the more performance you're going to get and if you want the infrastructure to remain chill right to not spam your API with 200 requests per second then of course the performance is going to suffer and
- 5:55
the trade-off that this website takes is very interesting because it's the exact end of the spectrum right it's literally full performance and it does not care about infrastructure load which I really admire right because the results are very very clear and how that prefetching is done in code is probably even more interesting so basically how this works is that they have written a custom link
- 6:17
component you can see for example where we use this link component is right here for each product card that we have right we've got a link component with a prefetch value of two and this prefetch fetches the images for the path in the link how that's done in code is a bit more complicated but really really interesting so this is the link
- 6:37
component it extends on the base nextjs link component and by default we don't prefetch any images right it's an empty array but then as the page loads as we render there's a use effect running with a intersection Observer pre-rendering all images that are in the viewport and we can see that once we refresh the page already a lot of images are PR loaded
- 7:00
without me hovering over anything right just on load this use effect is responsible for prefetching the visible pages and their images that's strategy number one we render on visibility and strategy number two is on Mouse enter so when we hover something then we actually go ahead and prefetch these images how the prefetching works is inside of an
- 7:20
API route and is super interesting because this literally only works because everything about this app is statically served right we get the HTML for each page directly from the server this is nothing that happens on the client side it's completely static therefore what we can do is in this API route responsible for
- 7:42
prefetching images we can just go ahead construct the URL to the page that we want to prefetch and server site pars the HTML extract all the images from the main tag and return all images with their Source set sizes Source alt and loading property back to the client and that's the funny thing once we return
- 8:02
them back to the client we just right here put them in our browser and actually render or load them right so they're already loaded and then when we navigate to the page bam they're already going to be pre-rendered right here for us and that's something that the next MasterCard website for example doesn't do right the images are not immediately there they are really fast but you can
- 8:24
see they load after in the next shares website this open source project that not the case right here as we hover the only thing that we are preloading our images as we click on these we can see the preview of each image show up right here on the right hand side we're not actually making any database calls right we're just making calls to images and we
- 8:44
don't make database calls because we use static prems this is a completely static project right the database call is done once then we save the page statically we don't expect any updates that's why we don't even need to to make database calls at runtime right here cuz all the data is already in there and just revalidates every 2 hours in this app
- 9:06
which is really really clever to make this fast this prefetching goes extremely well together with Point number three which is aggressive caching so on both of these fronts we are super aggressive and that pays out but it also comes with a big tradeoff this website is meant to be static users can't insert
- 9:27
their own products here or anything like that if they were we would be inside of a dynamic app and this caching could really really backfire because it gets quite complex very fast and that's done in the unstable cache component right here basically we're using a builtin server site nextjs cache which is the next unstable cache or in next S15 the use cache directive and then the react
- 9:50
cache that handles the duplication for us and what that allows us to do this unstable cache is well let's see where we use it basically for any database cost when we do have to make a database call which is with postgress in this project under the hood then two things happen first off we cash the result and second off we also give the cash a revalidation
- 10:11
period so if we have to make a database call which we really want to avoid to be honest because that is slow right that's the slowness part of this app therefore we make them only every two hours at most and if we are forced to do it then we also cash the result right so it really makes the best of these dat database calls but that's the reason why
- 10:32
users can't insert their own products here would really hit the fan because that product wouldn't be visible in the store for at least two hours right and the trade-off here is user experience versus speed right all dials are completely performance focused in this app which I think fits the point but it also comes with a trade-off of dynamic content not really being possible here so that's one thing we
- 10:53
have to keep in mind right if you have a dynamic app chances are you can't Implement all the performance from this app as they are into your own app but also that's not really the point of this app fourth point is that this project avoids database joins so if we are actually forced to make a database call not only do we cach it super
- 11:14
aggressively but we also make a really simple database calls there are not a lot of joints in here take a look at this there's just a products F many call there's a collections Fight Man call these are as simple as database calls yet pretty much right with a wear condition up here not even a wear condition here just an order by database
- 11:35
calls by themselves don't even get much faster than that and we also see that there is one join I believe it was further down here let's search for it yeah right here the left join left join left join this is very unusual to see for this project and they even annotate as a comment I found that really cool could be optimized by storing the
- 11:56
category slug on the product table so that we don't need to join it together we avoid even more joints and to be honest man joints are pretty fast right SQL or postgress are really well optimized for joints and even this consideration shows how important speed was for them to even avoid that right to
- 12:17
just make a simple query um but that's Point number four and lastly pretty simple point they also use a fast omm they use drizzle if you're not familiar with Drizzle basically um it's unlike Prisma omm it doesn't ship its own huge query engine um but instead we Define our database schema just in typescript
- 12:37
right so take a look at this we just Define or postgress tables like this right the categories table has these um properties right here and it's basically faster than Prisma because it doesn't ship a huge query engine and that just adds to the whole speed aspect of this and also by the way makes this project
- 12:57
easy to deploy to Cloud FL workers and not just for sale if you want now why did I Mark these two as especially useful because these are the easiest to transfer to your own apps if you don't want experimental features if you don't want to change your database schema heavily just for the sake of performance and if you also don't want to change your orm or are already using a fast orm
- 13:19
these are probably the easiest to implement with the biggest impact on your app so let me show you what I did basically I built my own little project here and I think that's under Local Host 300 ,000 yes and let's go to slash people right all that does is and also by the way notice the speed here I'm going to reload the page that is already
- 13:39
really really fast but the navigation is the more important part right it's basically a list of people that we can follow just random people names that are made up and as we navigate here let's go to Terry dibert as I click the navigation is almost instant you can see the image is not because that's a challenge of a dynamic app that most
- 14:01
apps just are right but as we navigate here let's click Bessie Meyer the navigation check this out happens almost instantly I'm just going to click some names right here you can see how fast this is right it's basically the same as in the next faster app but that's the main difference this website does not
- 14:21
have the constraint of being so static right you can do whatever you want in here you can integrate this as is into your own apps right into your Dynamic apps and don't have to change everything for the sake of performance now how does it work basically with the two points that I mentioned right those were the extremely aggressive prefetching and extremely aggressive caching right
- 14:42
putting load on or infra and getting speed in return for let's reload the page and see how this works as we hover over entries right here you can see two things happen we prefetch the information about this person we are about to click on and we also pre-load their image so it's loaded faster in the browser to be honest I'm not 100% sure if that even works uh because the image
- 15:04
still sometimes loads a bit longer when we're on the site it's not instantly there sometimes but the data always is because we aggressively preload it on Hover so as we click on an entry even if we have never opened it before right here bam it's instantly there fully client side that's what the other app can't do which is also what the other app was never even meant to do it works
- 15:25
very similarly in the link component right I just got inspired by that app and kind of wrote my own implementation to prefetch right so we prefetch if the mouse cursor is over an entry for longer than 50 milliseconds right so we don't completely spam if we just go really fast here not all entries are preloaded but as you can see if we go slower they
- 15:46
are that's just a personal decision I would make in a production app I would not completely spam the API for every hover but only for the ones above 50 milliseconds that user is actually likely to click on you know for each route right here here we have a query key so we can identify this in or Cache using react query and a query function to get the data that we have on that
- 16:07
page which essentially is just right here the name the handle the bio the amount of followers and so on this is just data coming from upsd rdis and that ties into the uh third point right here aggressive caching this is served from a upd r is cache globally distributed and fast anywhere full disclosure I work
- 16:28
there this is not like an advertisement is just the solution I actually like to use for this um because it's really fast right so even if we do have to make database queries where preloading is not possible like directly navigating to this page for example then still the data loads really fast because it's loaded from reddis and not a postgress database yo I really hope you enjoyed
- 16:49
this video go ahead I encourage you dig through the repository and learn for yourself that's one of the best approaches to learning just going through a repo and see the code for yourself experimenting with it if you find anything where you say hey Josh why didn't you talk about that this makes the website much faster and you missed it in the video yes chances are I missed it let me know in the comments down
- 17:10
below and also let me know your thoughts generally did you know this was possible honestly I didn't I really hope you enjoyed the video and take this for your next project cuz that's what it's for man so I'm going to see you in the next one until then have a good one and bye-bye
Description
This website is stupid fast. Let's take a look exactly how they do it, and which parts we can use to make our own apps (much) faster. I am really excited for this video, big respect to Ethan and 2 other contributors for making this project.
--- links
live website: https://next-faster.vercel.app/
this project on github: https://github.com/ethanniser/NextFaster
-- my links
second channel (in depth videos): / @joshtriedupstash
discord: / discord
github: https://github.com/joschan21
my SaaS: https://crotus.io/
thank you for watching, really appreciate ya
More from Josh tried coding
×1312:00:00Build a Complete Digital Marketplace with Next.js 14, React, tRPC, Tailwind | Full Course 2023
Josh tried coding571K views
×1212:00:00Build a Complete E-Commerce Shop with Next.js 14, Tailwind, React | Full Course 2024
Josh tried coding509K views
×4.44:41My Favorite UI Library Keeps Getting Better
Josh tried coding191K views
×3.76:58Fetching Data Doesn't Get Better Than This
Josh tried coding160K views
