My Weird Journey To Next.js
Summary
TLDRIn this video, the creator shares his personal journey with Next.js, a framework he initially disliked but later embraced as the future of web development. He discusses his background in programming, his transition from backend to frontend, and his love for functional programming. The creator details his frustration with the slow process of backend and frontend synchronization and how Vercel's server components, especially the introduction of async support, revolutionized his workflow. His passion for the seamless integration of server and client-side code in one project, along with the efficiency of Vercel's deployment process, transformed him into a staunch advocate for Next.js.
Takeaways
- 😀 The speaker's journey with Next.js started with a love for functional programming languages, which led to an appreciation for the framework's ability to integrate backend and frontend code in a single project.
- 🔧 The speaker initially disliked JavaScript and frontend work but eventually fell in love with React and its component model after being pushed to contribute to Twitch's frontend rewrite.
- 📚 The importance of a well-defined API layer was highlighted through the speaker's experiences at Twitch, emphasizing the need for synchronization between backend and frontend teams.
- 🚀 The speaker's frustration with slow development cycles and the inability to quickly iterate led to the exploration and adoption of Vercel Functions and later, Next.js for their project needs.
- 🛠️ The speaker's initial use of Vercel Functions (then called API Directory) allowed for the addition of backend functionality to a frontend project without needing to change the framework or setup.
- 🔄 The transition to Next.js was driven by the need to reduce build times and improve performance by bundling multiple endpoints into a single Lambda function, enhancing the deployment process.
- 💡 The introduction of tRPC simplified the speaker's codebase significantly, allowing for type-safe and efficient data fetching and server-client communication.
- 🌐 The speaker's advocacy for the T3 stack (Tailwind, TypeScript, tRPC) and its popularity among the developer community demonstrated the appeal of combining these technologies for building applications.
- 🎥 The speaker's YouTube channel took off quickly, leading to sponsored content opportunities and collaborations with companies like Vercel, which aligned with their genuine enthusiasm for the technology.
- 🔄 The evolution of Next.js, particularly the introduction of server components and their asynchronous capabilities, represented a significant shift in the speaker's perspective, transforming them into a strong proponent of the framework.
- 🚀 The speaker's passion for Next.js is rooted in their personal development journey and the evolution of the framework, rather than any financial incentives or sponsorships.
Q & A
What was the speaker's initial impression of functional programming when they first tried Elixir?
-The speaker initially found functional programming with Elixir to be weird but quickly fell in love with it, to the point where they loved coding.
Why did the speaker dislike working with Go?
-The speaker disliked working with Go because they had fallen deeply in love with functional programming and the thought of not doing it hurt, making them unproductive and unhappy.
How did the speaker's experience with React change their perspective on front-end development?
-The speaker discovered the power of the component model in React and composition, which made them fall in love with front-end development quickly, despite previously hating writing JavaScript.
What was the speaker's role in the team that used Elixir at Twitch?
-The speaker joined the team at Twitch without being a qualified developer but ended up contributing significantly, especially after moving from backend to frontend roles.
Why was the speaker frustrated with the API layer in their work at Twitch?
-The speaker was frustrated because the back-and-forth with the backend team to get features shipped was time-consuming and often held up the shipping process, which was a difficult problem to solve.
What motivated the speaker to use Vercel Functions (API Routes) in their project?
-The speaker was motivated to use Vercel Functions to avoid being blocked by the backend team and to have the ability to quickly add backend functionality to their frontend project without changing the framework.
Why did the speaker eventually choose to use Next.js for their video call app?
-The speaker chose Next.js to bundle all the API endpoints into a single Lambda, which reduced build times and improved performance, as opposed to having each endpoint compiled and deployed individually.
What was the speaker's initial opinion on Next.js's data fetching methods?
-The speaker initially disliked Next.js's data fetching methods, particularly getServerSideProps, because they found it to be inconsistent, not type-safe, and not providing the necessary functionality for their pages.
How did the introduction of Next.js's Server Components change the speaker's perspective on the framework?
-The introduction of asynchronous Server Components made the speaker fall in love with Next.js, as it allowed for a more seamless and type-safe way to handle data within components, aligning with the speaker's vision for a better development experience.
What was the speaker's involvement with Vercel and Next.js before becoming a well-known advocate?
-The speaker used Vercel and Next.js in their projects long before becoming a public advocate, and their positive experiences with the technologies led to them promoting them to others and eventually creating content about them.
How did the speaker's content creation journey begin, and what was the impact of their first few videos?
-The speaker's content creation journey began with a live stream to showcase their stack to creators, which eventually led to a video that gained traction. Their first few videos, including a mock interview with Dan Abramov, helped establish their presence and credibility in the developer community.
Outlines
🌟 Journey to Next.js and Vercel Advocacy
The speaker shares their personal journey with Next.js and Vercel, starting as a Python developer at Twitch who transitioned into using Elixir and fell in love with functional programming. They discuss their dissatisfaction with the traditional back-end and front-end synchronization process and how their experience with Vercel functions, initially used for server-side code without affecting the main codebase, led them to become a strong advocate for the platform. The narrative highlights the evolution of their career and their transition from a back-end developer to a front-end enthusiast, all while emphasizing the importance of API layers in complex front-end applications.
🛠 Overcoming Backend Bottlenecks with Vercel Functions
The speaker recounts their frustration with slow backend deployments and how they leveraged Vercel functions to bypass these inefficiencies. They detail their initial use of Vercel functions, then known as the API directory, to create serverless endpoints that allowed them to deploy features faster without relying on the backend team. The speaker also discusses the challenges of local development with Vercel CLI and their efforts to streamline the process, ultimately leading to a more efficient workflow that integrated front-end and back-end functionalities within the same project.
🔄 Transitioning to Next.js for Improved Build Performance
The speaker describes the shift to Next.js as a solution to the growing build times and deployment issues they faced with Vercel functions. They explain how individual API files were compiled and deployed separately, leading to increased build times and inefficiencies. The adoption of Next.js allowed them to bundle all API endpoints into a single Lambda function, significantly reducing build times and improving performance. The speaker also touches on their initial dislike for Next.js features but acknowledges the framework's role in streamlining their development process.
📡 Embracing tRPC for Simplified Data Fetching
The speaker shares their experience with tRPC, a data fetching solution that greatly simplified their codebase and improved type safety. They discuss the transition from traditional API endpoints to using tRPC, which allowed for more efficient and streamlined data fetching within their application. The narrative highlights the reduction in code complexity and the ease of maintaining the application with tRPC, showcasing the benefits of this technology in their development workflow.
🚀 The T3 Stack and the Evolution of Development Practices
The speaker reflects on the rise of the T3 stack, which combines Next.js, tRPC, and other technologies, and its impact on their development practices. They recount their advocacy for using Next.js as a bundler and the community's reception of the T3 stack, leading to the creation of tools like `create-t3-app`. The speaker also shares their experience of engaging with companies behind the technologies they use and the excitement of contributing to the evolution of web development frameworks.
🌐 The Impact of Server Components and the Future of Next.js
The speaker discusses the introduction of Server Components in Next.js and its profound impact on their perspective of the framework. Initially skeptical, they were won over by the asynchronous nature of Server Components, which aligned with their vision for seamless data fetching and rendering in React components. The speaker shares their transition from a critic to a passionate advocate for Next.js and Server Components, highlighting the transformative potential of these technologies for the future of web development.
Mindmap
Keywords
💡Next.js
💡Server Components
💡API Layer
💡Elixir
💡React
💡GraphQL
💡TRPC
💡Vercel
💡TypeScript
💡Remix
💡T3 Stack
Highlights
Personal journey from a Python developer to a fan of functional programming and React.
Initial introduction to Elixir in 2017 and the subsequent shift in programming perspective.
The challenge of working with different languages and not feeling at home with any specific language.
Transition from backend to frontend and the realization of the importance of the API layer.
Experience with GraphQL as a contract between backend and frontend teams.
Frustration with the inefficiency of back-and-forth communication between front-end and back-end teams.
The decision to join a startup and the excitement to build mobile and web apps without constant blocks.
Choice of Expo and React Native for mobile app development to enable fast shipping of updates.
Discovery of Vercel Functions (formerly API Directory) and the benefits of serverless backend functionality.
The impact of Vercel's serverless functions on reducing build and deployment times.
Transition from using Netlify to Vercel for web deployment and the advantages it provided.
The introduction of Next.js to bundle API endpoints and improve build performance.
Adoption of tRPC to simplify code and improve type safety in data fetching.
The significance of server components in Next.js and their ability to handle data fetching asynchronously.
Personal advocacy for the T3 stack and its rise in popularity among developers.
The evolution of the speaker's YouTube channel and the shift in content creation strategy.
Engagement with Vercel and Next.js teams and the influence of server components on personal perspective.
Reflection on the journey from a backend developer to an advocate for modern frontend frameworks and tools.
Transcripts
we talk a lot about nextjs on this
channel how to use it how it works all
the things you can do with it what we
haven't talked about is why specifically
why do I use next how did I get here in
the first place what made me such a huge
Fanboy of next and versell this video is
explicitly not sponsored by versell I
have a couple other sponsored videos
with them coming up they have no idea
making this one I'll be honest I didn't
either until just now I'm filming this
live on the Fly cuz we were talking
about it I realized it was an
interesting topic because my history
with versell is nothing like people seem
to think it goes back quite a bit in
fact all the way back to 2017 when I
first started using Elixir at twitch
when I joined at twitch I was I guess a
python Dev at best but honestly I wasn't
much of a Dev at all I had written a
bunch of plugins in Java for my
Minecraft servers I somehow just barely
managed to pass my data structures class
in C++ and I was working on some things
in Python for the research projects I
was contributing to I even had been
working on iOS apps and specifically
Apple watch apps a bit at the time which
were a massive Objective C and a tiny
bit of Swift but honestly I didn't
really feel at home with any specific
language and barely even considered
myself a programmer I only got into
twitch because the person who ran the
team had the same music taste as me and
decided to offer me a 3-month contract
despite not being qualified at all 6
months later yes I got my contract
extended because I wasn't doing well
enough but at the six-month Mark I was
doing well enough they decided to keep
me fulltime and that team I had randomly
joined this new team that formed was
using Elixir despite the rest of the
company using Ruby and a little bit of
go I did not know what I was getting
into when I tried Elixir which was my
first real functional programming
language and I fell in love fast it went
from oh this is weird to wow I love code
now so fast so fast that when a year
later the team folded and I had to go
write and goang I hated it I hated it so
much I had fallen so deeply in love with
functional programming that the thought
of not doing that hurt it hurt so much
that I just wasn't productive I was so
unhappy that my manager pulled me aside
to subtly let me know that I would have
an issue if I didn't pick up my
performance but also cuz he noticed how
unhappy I was and that I wasn't enjoying
my work he didn't mince words he made it
very clear to me that I was not
performing to the expected bar but also
that he didn't think it was because of
my lack of engineering capabilities just
my lack of content using the tech I was
using he pushed me to contribute to the
rewrite of the twitch site moving us
from Ember to react and I fell in love
fast I did not expect to I was known as
like the front-end hater guy I was
shipping live view in 2017 with elixir
in Phoenix because I hated writing
JavaScript that much I was probably one
of the first production users of live at
the time when I started using react and
I started playing with the composition
seeing how powerful the component model
was I fell in love fast I fell in love
so fast that to this day I'm largely
stereotyped as a front-end engineer
which is really funny to me because I
was a backend for the vast majority of
my career and even today I'm spending
more of my time thinking about servers
than clients although the relationship
between them is something I spend a lot
of time on too so that's my history of
how I got into react how do we end up
here well after years of contributing at
twitch be it the internal tools like the
one we had for the safety stuff as well
as the public facing twitch site I got
to learn a lot about best practices for
building and scaling complex front end
applications one of the things I learned
is the importance of the API layer that
the front end is working with since I
had been backend first and then I moved
to front end I was actually in a really
good position to talk with the backend
teams to make things come together I
spent most of my time talking with the
teams running the back end and the
graphql stuff that we were actually
communicating with and using in our
services in order to make sure our stuff
shipped and worked as we expected that
synchronization was essential and ended
up being a huge portion of my time spent
and honestly I love graphql this because
it gave us a contract to put in the
middle between the back end and the
front end and once we agreed on it we
could all go our separate ways and work
and eventually come back together to
make sure it all combines correctly and
if it doesn't somebody got fired which
was awesome okay we should have fired
more people at that point but you get
what I'm trying to say it was really
cool having a solution that let us as
back end and front end agree on
something and then go do our thing the
harsh reality was if the front end
needed something and backend was too
busy to do it either you did it yourself
which ended up being a ton of work
especially if you weren't working in
that code based regular
or you politely asked and waited until
hopefully someone bothered to ship the
thing that back and forth ended up being
so much of the thing holding up shipping
for us that it frustrated me to no end I
got so tired of waiting in these back
and forths that I ended up doing a lot
of the backend work myself and then
getting blocked in code review and yeah
it was a mess things that should have
taken a few hours to do ended up taking
days if not weeks not because the
process is slow or because big companies
work that way simply because
synchronizing the back end and the front
end properly across teams across
Technologies across code bases was a
difficult problem eventually I left
twitch to join a startup I joined the
startup I took over client fully and I
was really excited to build the mobile
app and the web app specifically I was
excited to not be blocked constantly and
being able to ship updates whenever we
had them so our users could have a great
experience no matter what issues they
ran into and that's why I picked Expo
and react native so we could ship stuff
really fast to mobile but web I didn't
really have a go-to solution yet I was
using netlify for my own personal stuff
but I was having a few issues getting it
to deploy specifically I was using snow
pack not webpack for the faster build
times and it was not doing great with
NFI at the moment eventually I got it
working but I've been hearing more and
more about this forell thing what pushed
me over the edge was very specific this
backend team that used to be the front
end team that didn't like me too much
was taking forever to ship stuff I would
request a change I would wait 12 hours
for them to wake up they'd reply saying
oh no it works fine the way it is look
at our example I would wake up go check
the example it didn't work I would tell
them that wait another 12 hours to which
they reply it totally works you're just
holding it wrong and never once did it
actually work the way they specified so
I was constantly locked by these guys we
had a few random things that we needed
that they kept saying we're going to
take days if not weeks to build that I
knew shouldn't take that long so I need
a way to run a little bit of serers side
code that wouldn't get into their repo
CU as soon as it touched their GitHub I
had no ability to ship anything that
involved this team blocked me immensely
So eventually I convinced the CEO to let
me spin up little small end points that
weren't stateful which meant he said
that they weren't backend his definition
of backend was fully stateful including
the database running constantly but I
convinced him that I could run these
oneoff functions somewhere just to fetch
some data from a backend API and fix it
for me and eventually he caved and said
sure So I started hunting and when I
started hunting I discovered something
really cool and no it wasn't next a
really cool thing I discovered was
versel functions they've had a lot of
different names over the time but when I
was using this in 2021 they were still
called the API directory no this didn't
mean the API directory next it meant
that you could just have a folder named
API in your repo export a function and
now it's an endpoint whatever you export
here can now be used by versell to
handle get post put whatever and when I
realized I don't have to change my
framework I don't have to change
anything I can literally just make this
folder in my frontend project named API
put a file in it hello. TS and just do
something there I was like oh this
is an obvious solution so I made the
move over and that move was awesome
having access to full backend run times
without having to think about the
scaling or any of those things made it a
very obvious choice for me so funny
enough whether or not you believe it I
was using versell years before I had
ever touched next because I was still
super snow pack pilled eventually moved
over to vet but I kept my front and my
back end separate still I just like the
idea of them being in the same code base
so I could make changes at once and have
everything synchronized properly and
having the ability to just add backend
functionality to my frontend repo by
adding one little file in the API
directory was magic and if I go back to
our old code API added let's take a look
at
this here is the code where I was
handling all my off in my API helpers
folder I was still using worker KV for
all of my
storage and it was a mess I like
hardcoded the key just to like get it
working add user to room call off you'll
see I have all these API functions for
the different things so get allowed user
handle request this was before they had
the get post put all of that this was
just request response which were versel
but they were pretty standard request
response from like um the express
request response but in here handle
request room names with query make sure
that it's a string throw we lowercase it
get the value from KV if no perms we
send a 403 otherwise we actually send
you the content I'm almost positive that
worker KV instance is dead and if not
I'll go kill it right after yeah so as
you see here pretty boring old V code I
even added like a port call cuz I was I
one of the Annoying Parts is in order to
run this locally I had to have the API
run through the versel CLI and the
versel CLI is overall pretty good I
honestly don't use it that much but for
this it was nice cuz I could run these
API directory things locally and have V
running locally too the issue was V kept
getting its requests eaten by the versel
runner which was obnoxious I actually
have um my blog part of why I made my
blog originally was to about this
using V on
versel because I went to hell in back to
fix weird things around like query pams
that were being eaten because V doesn't
format them correctly and like that
and I wrote a whole guide on how to make
this all come together so you could have
your API directory work with v in local
Dev it was annoying but I made it all
work but then I ran into another
unexpected issue when you put all of
your routes in the API directory is
individual files like this in order for
them to compile and run safely each one
gets compiled and deployed by itself so
first off I was hitting limits of how
many of those I could have and second
off every new endpoint added like 40 to
50 seconds of build time and deploy time
which was entirely going against the
thing I was trying to do which is make
it as fast as possible to make changes
and fix things so even though this code
base was awesome I had my super client
heavy stuff and I had my super server
heavy stuff we even browse through the
files and I'll show you that it was a
pretty boring V app where I had my react
query client provider which I was using
for just fetching data I had my boring
all pages which were settings home and
call and call mostly was doing client
side stuff because this was an app for
doing video calls so obviously this
one's going to be very client heavy I
had all the different states if not in
call return the join if PR's Channel
return call not found if it's loading
return loading if data if no token on
off and then I actually render the video
call but these types of things were
pretty client heavy so I didn't see a
need to use a serers side framework why
would I ever need nextjs for my video
call app the reason I needed it was
because of those build times and the way
it was deploying since all of those
different end points had become their
own like lambdas my build times at this
point were horrible I wonder if I can
see easily here I don't think that the
has the history for but my build times
doing this had gotten to like 5 to 6
minutes when before they were like 20 to
30 seconds so I wanted a way to easily
bundle all of this into one end point
and after doing a little bit of research
I learned that nextjs just does that for
you when we were in the docs before with
the uh versell functions you'll see
there is the next app next pages and
other Frameworks I was doing the other
framework solution which by the way also
works with other languages I don't know
if it says that here but there are uh
you can use go python Ruby or Edge run
times and there's ways to use PHP and
on this too which is actually
really cool you can deploy any of those
through versal just by putting it in the
API directory so these docs got killed
for the old version that I was using but
I bet I can even find the pr where I did
this this is the pr where I actually
moved us over to nextjs I got at our
routing I moved over to file based
everything I deleted all of these API
helpers because I can move all of these
to the API directory and next I didn't
have to change too much I got to delete
a decent bit of code but the win here
was that all of these Source Pages
things got bundled at once instead of
being bundled independently and if I go
look at the code base at this point in
time this ended up being a pretty basic
app we had our API directory that had
all of the apis in it and rather than
each of these having its own build
process and going out to its own Lambda
all of these things got bundled into a
single end point that was hosted on one
Lambda by forell so my build times went
from like 5 to 6 minutes down to like
two and the performance was a lot better
too because the end points were more
likely to be warm since all of them were
running out of the same Lambda so this
ended up being a massive win for
performance even if the developer
experience was slightly slower because
it had to use webpack which I had been
webpack free for years at that point so
my desire for the next API directory was
so great that I was willing to do things
I didn't like such as use webpack and
deal with their data fetching stuff and
God did I hate versel data fetching get
server side props quickly became the
bane of my existence I hated this so
much it's hard to put into words it just
did not make any sense so much so that I
wrote my second ever real blog post
which was an inconsistent truth next in
type safety because get server side
props was not type safe it was not a
good client experience it was barely
even a functional server experience I
have a lot of videos now where I
complain all about get serers side props
and how awful it was the honest truth is
that most of next was stuff that I hated
like the things that made next different
from V or from other Solutions just
pissed me off to no end I actually
didn't like next at all what I did like
was its ability to collocate my backend
code and my front end code in one
project in a meaningful way where the
server and the client are much more
closely tied even if the methods that
they had provided for sharing things
between the two were things that I hated
and believe me I hated all of those
things to the point where honestly more
often than not I was just calling react
query everywhere so if we find like any
of the actual code which would be in
Source components you'll see here I just
have a bunch of use Query calls where I
am fetching things from my server and I
just do SL API now because I know where
it's going to be which is nice and I
have a bunch of these used query calls
all over the code base where I'm doing a
bunch of like parsing and making sure
the data is the right format and
but it was still better than server side
stuff because get serers side props
didn't really give me the stuff I needed
for most of the pages especially because
it had to be relay Dynamics it was for
video calls next only gave you a
solution for when the page first
rendered from that point forward it was
your problem and I hated that so I used
almost none of next's server s side
stuff for react I used the API directory
to host apis but then I made another
important change in September of 2021 I
moved us to trpc which let me delete
quite a bit of code and made maintaining
all of this hilariously simpler yes this
is when I actually got trpc pilled I
played with it quickly for this project
and almost instantly fell in love and
realized I needed to be using it for
like everything here's my Agora router
Agora was the solution we were using for
our web RTC at the time and it was way
simpler I have my router which has my
off context I have a query which has get
token I have my input which is a room
slug which is now validated this is all
validated here so I could delete all the
validation code and then I have my
resolver which returns n if you don't
have a session and then it Returns the
Agora off token if you do same deal for
getting the embed token all of this code
became hilariously simple to write and
then actually using it was even simpler
trpc usequery give it the string give it
the values and it's all not just working
but type safe I was able to make so
much simpler if we look for the used
call token code I deleted yeah see how
much longer these endpoints were with
all of the checks making sure it's a
post making sure that we have the right
data getting the session making sure we
have a user ID getting their profile
making sure we have the right data and
then finally doing the thing we were
here to do this went from 41 lines of
code to like five and consuming it was
so much easier too like hilariously so
and I was able to delete all of these
giant end points in favor of things that
are way easier to work with oh here's
the call token code so this 33 line get
call token I could just delete entirely
where is the actual use for it though
okay can't find where I deleted the call
token code but I'm sure it's in there
somewhere regardless you get the point I
was not using next the way you probably
think of nextjs because I wasn't using
next the server and client all-in-one
solution in fact I was barely using next
beyond the bundler I found it as a
really convenient way to put my react
client code and my whatever else server
code in the same project all at once and
as we all know from the original T3
stack it was actually a good experience
I had massively advocated for this idea
of using next as a way to make a good
client and a good server that are close
but not tied and using things like trpc
to do that gluing part together at this
point I was really liking my experience
with next in versell even if I wasn't
using next I had gone all in on versell
and the way it let me build and deploy
my Solutions so much so that some of my
co-workers from both ping and other
startups like rose here call it out to
this day cuz I was far from YouTube this
was years before I had started YouTube I
was just trying to build as effectively
as possible and Rose ended up being one
of the first people I converted to using
versell it was weird cuz now there's
literally probably hundreds of thousands
of y'all but at the time I didn't have
influence I had like 50 followers on
Twitter and a few nerdy friends so I
just talked about this with them and
they fell in love too and I love Rose
for calling this out here because yeah I
was obsessed once I realized how much
easier all of these things could be
after spending a decade suffering
through all of these parts the ability
to link a project from GitHub that would
serve all of my apis and all of my
clients the best possible version of my
experience by clicking two buttons to
link my GitHub to my versel project was
magic and I yes I fell in love I sounded
a lot like a shell because it was unlike
anything I'd experienced before but it
was genu as Rose says here I actually
really love this stuff so much
so that when I got into white combinator
I was just seeking people to nerd out
about this with and I couldn't find them
I was desperately looking for people who
wanted to talk about these things with
me because I just was such a nerd so
that's why I did the video that many of
y'all have probably seen the roundest
video this is the video this was my
first Dev video and it also wasn't a
video it was me doing a quick live
stream because I was building tools for
creators and I wanted to better
understand what they needed and I'd been
talking to a few people people on
Twitter who I wanted to explain my stack
to that didn't seem to get it so I made
this to Showcase why I like this text so
much I posted it on YouTube didn't
really do much but then I got lucky
enough to have Dan abramov come on for a
mock interview which did really well and
eventually got this to kick up too to
the point where both of these videos
ended up being pretty close in terms of
viewership long term which is kind of
crazy to think that a brand new YouTuber
was able to get as many views on his
building a video app live as he was
interviewing Dan abramov just
mind-blowing the reason I was able to
have Dan on is I care a lot about how
job interviews work so when he said on
Twitter he was going to be doing some
mock job interviews with YouTubers if
anyone was down to hit him up I
obviously immediately hit him up he was
down I got to do that it was one of the
first pieces of content using ping
because I had to have him call in really
proud of that really proud of that
interview yeah they these were the first
two ever I learned so much from doing
that more importantly I got hooked on
having these deep technical
conversations and sharing the magic of
how these tools were coming together the
beauty of combining next as like a
bundler effectively
with react a wonderful client side
framework with trpc the best way at the
time to connect your server and your
client together and Prisma which was
honestly kind of magical at the time
because there was no good typescript orm
that had that level of type safety built
in Planet scale which broke my brain at
the time oh Planet skill was so cool and
Tailwind because I finally liked styling
having all of this come together in a
way that felt that good was magical and
even 2 years later I almost missed that
moment but the magic wasn't something
only I was feeling because T3 stack took
off there were points where create T3
app which was made by nexil a fan of
mine soon after all of this create T3
app was getting more invocations than
remix which is crazy when you think
about it that a YouTuber's fans built a
boiler plate using their recommended
technologies that became the third most
popular framework for react but that's
how cool this stuff was to use and funny
enough as I've been hinting at this
whole time most of it was built around
avoiding next to the best of your
ability next was the the box that this
all went in but we had basically dumped
the box out shook everything out of it
put back like two parts and then filled
the rest with other things and it was
awesome it was so awesome that I was
starting to talk to versel themselves
and the people who worked on next which
was mind blowings I was just a fan at
the time all of a sudden I get to
actually talk about and work with these
people and then the channel blew up like
really quickly I only started posting
videos for real in April of 2022 I had
done like one or two before then but it
wasn't something I was taking very
seriously and then I started doing
videos with prime then I started posting
more often and it blew up fast and I was
blown away and I realized quickly we had
to change how the channel ran cuz I had
to have an editor helping I had to have
others helping me research topics and
manage the channel and I also had to run
my company so expenses were going up and
my time was going down I also had my
first ever company reach out to talk
about a potential sponsor which was up
stash I also realized at the time I need
up stash for a bunch of stuff so I tried
it I loved it especially the rate
limiter and I did my first ever sponsor
deal which was a huge huge deal for me
the idea of making money off of YouTube
was just mind-blowing at this point I
realized that sponsors were a thing I
could do and as long as I picked ones
that built things I trusted this was a
really good opportunity so I reached out
to all the companies I was shipping in
production including Planet scale
including axium including versel and
they were all down so I ended up for the
first time ever having a set of sponsors
making this content possible not too
long after that versell announces the
app router and server components and my
mind is blown initially I'm actually
quite skeptical you could find my old
videos where I first talk about nextjs
and server components and my responses
yeah I'm not sure but then they made one
really big change that entirely shifted
my tone they made server components asnc
like properly asyn like you could just
await a call there's even a clip from
one of my old videos where I say they
should have done this this is the future
I dream of and this can absolutely
happen like but the the point I wanted
to make here is I dream of a world where
for Server components you can define a
component async do whatever in here and
return yeah I was skeptical but then
they changed it to be async and I
decided to play and boy boy oh boy did I
fall in love remember how before I said
that I B Bally dumped out Hall of next
in favor of my own Solutions I had been
leap frogged many of the things I was
putting my time and effort into suddenly
felt both archaic and worse to use as a
user when I saw how powerful it was just
awaiting some data inside of your
components I knew it was going to be
magical not because I just saw it and it
was obvious because I had put a bunch of
time into Astro as well and the magic of
just awaiting some data and having it
type safe to just us in your markup
without having to make an API endpoint
or handle the types between the back end
and the front end and all of this chaos
just vanished and I realized this was
the ultimate version of what I'd been
seeking this whole time where v0 was
endpoints in some other code base client
code has to guess what data it's going
to be getting to V1 of now the API
endpoints are in the same code base to
the thing I skipped the V2 of what if
the get server side props Returns the
data directly so that was just a mess
and I stuck to like a V1 Plus+ of trpc
doing the bridge instead but now this
third generation of these Solutions of
what if the components could actually do
the server side stuff themselves and
just pass the data down like properties
and when it clicked it clicked hard it
clicked so hard that I got called a
fanboy and specifically I got called a
shill a lot as though versell paid me to
have these opinions despite the fact
that when versel and I first Inked our
deal which by the way the numbers have
not changed since we started despite me
being five times larger I could
reasonably charge them more but I don't
because I don't want to I'm very happy
with the current terms of our deal
things are working out great for
everyone involved the magic of server
components blew me the away and I
went from unsure to one of the biggest
Advocates very quickly seemingly too
quickly because to this day I still get
that verell paid me to believe
these things that I didn't believe in
the past but really what had happened
was I used it in my perspective shift
and that's why I made this video because
I honestly think if you guys knew my
history of going from a disgruntled
backend Dev to a functional Fanboy to
the guy porting twitch from Ember to
typescript all the way to where I am now
I think it makes a lot of sense why I
feel the way I feel none of this has
anything to do with what I've been paid
I included those details because I think
you guys should know them my perspec
effective has not been influenced by the
money that has been spent on my channel
I love next because I went from not
caring about next to not liking most of
next to feeling like this is the
framework of the future and when I
started using next it was barely even
the framework of the past it was such a
mess and what the teams created here is
something truly groundbreaking that I
actually really love so yeah let me know
in the comments about how I'm clearly a
paig shill cuz it's what you guys love
to do until next time maybe we'll have
some opportunities to go ship some next
anyways peace nerds
Посмотреть больше похожих видео
O que é uma arquitetura de uma aplicação web?
The Story of Python, by Its Creator, Guido van Rossum
Behind The Beats with Willy Winarko
My Tech Stack I've Used To Build 10+ Apps Over 2+ Years
#26: Connect React with NodeJS & MongoDB | Stored Registration Form Data in Database in MERN
Как же я ненавидел школу
5.0 / 5 (0 votes)