My Weird Journey To Next.js

Summary

In 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

00:00

🌟 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.

05:00

🛠 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.

10:02

🔄 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.

15:03

📡 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.

20:03

🚀 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.

Keywords

💡Next.js

Next.js is a JavaScript framework for building user interfaces, particularly for server-rendered React applications. It is central to the video's theme as the creator discusses his journey from skepticism to becoming a 'fanboy' of Next.js. The creator describes how Next.js evolved from being a simple bundling tool to a framework that supports advanced features like Server Components, which he finds groundbreaking.

💡Server Components

Server Components are a feature in Next.js that allows developers to fetch data and perform server-side operations within a React component. The video emphasizes the creator's excitement about this feature, noting it as a game-changer that simplifies data fetching and reduces the complexity of server-client communication, as he mentions how it 'clicked' for him after trying it out.

💡API Layer

The API layer refers to the set of protocols and tools used to build software applications, defining how software components should interact. In the context of the video, the creator discusses the importance of a well-defined API layer for synchronizing backend and frontend development, highlighting how it was a significant part of his work at Twitch and influenced his appreciation for frameworks like Next.js.

💡Elixir

Elixir is a functional, concurrent, general-purpose programming language that runs on the Erlang VM. The creator mentions his initial experience with Elixir in 2017 as a turning point in his career, where he fell in love with functional programming, setting the stage for his later appreciation of other technologies and frameworks.

💡React

React is an open-source JavaScript library used for building user interfaces, maintained by Facebook and a community of individual developers and companies. The video describes the creator's initial dislike for front-end work and JavaScript, which changed dramatically when he started using React, appreciating its component model and leading to a reevaluation of his career path.

💡GraphQL

GraphQL is an open-source data query and manipulation language for APIs, and a runtime system for executing queries with existing data. The creator discusses his experience with GraphQL at Twitch, where it served as a contract between the front end and back end, allowing for efficient and synchronized development work.

💡TRPC

TRPC is a framework for building serverless APIs with TypeScript and React. The creator mentions TRPC as a solution that simplified his codebase and made maintaining server-client connections much easier, highlighting its role in his transition to a more streamlined development process.

💡Vercel

Vercel is a cloud platform for websites and web services that offers a global CDN, automatic HTTPS, and a unified workflow for developers. The video script discusses the creator's positive experiences with Vercel, particularly its ease of deployment and integration with Next.js, which contributed to his enthusiasm for the framework.

💡TypeScript

TypeScript is an open-source programming language that builds on JavaScript by adding static types. The creator's transition from various languages to TypeScript is noted in the script, framing it as a significant upgrade in his development experience, especially in conjunction with React and other modern tools.

💡Remix

Remix is a framework for building web applications, similar to Next.js but with a different approach to routing and architecture. The creator mentions Remix in the context of comparing the popularity of different frameworks, indicating the competitive landscape within the JavaScript ecosystem and the growing interest in modern development tools.

💡T3 Stack

T3 Stack refers to a combination of technologies including TypeScript, TRPC, and Next.js, which the creator advocates for building efficient and scalable web applications. The video describes the T3 Stack's rise in popularity, reflecting the creator's belief in its effectiveness and the community's adoption of the 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