How many times have you finally wrapped

your head around NextGS only for them to

drop another version that renames half

the features, breaks the other half, and

promises to simplify everything? Yeah,

same every single time. But this time,

it's actually worth it. Or is it really?

Hi there and welcome to the Nex.js crash

course where I'll teach you not just the

why and the what behind Nex.js, but also

dive straight into how to build real

projects with it. First, you'll go

through a deep crash course to visualize

and master essential Nex.js concepts

like architecture, rendering, routing,

caching, adapters, API, and its powerful

full stack capabilities.

Then you'll dive into the code, bringing

those ideas to life as you build a

realworld application designed to teach

you how to use these features the way

the top companies do. This crash course

alone will give you a rock solid

foundation. But if you're serious about

mastering NexJS and taking your skills

to a professional level, I've got

something special for you. The ultimate

Nex.js course. Right now, the most

popular Nex.js GS course on the internet

where we go beyond the basics and dive

deep into advanced enterprisegrade

features. And I just launched the

complete Nex.js testing course too. So

if you're watching this video right now,

you can still grab our launch week

bundle at 33% off. This is not a drill.

I repeat, this is not a drill. You're

getting two massive courses, the brand

new testing course and the ultimate

NexJS 16 course, plus a tactical testing

ebook, all bundled together. This deal

will disappear forever and the price

shoots back up. The link is in the

description, but honestly, pause the

video right now and go grab it because

the last time we did this, the early

birds cleaned it up in about 6 hours.

But if you're still wondering whether

NexJS is really worth learning, well,

just ask Netflix, Tik Tok, Twitch, Hulu,

Nike, Notion, or even OpenAI. The NextJS

hype is real, even though it changes

often. And if you don't dive in now, you

could be missing out on careerchanging

opportunities. So yeah, it's the perfect

time to impress employers and build your

portfolio with something that screams

production ready. Here's what you'll

build and learn inside this video.

file-based routing to master the core

structure that makes Nex.js lightning

fast. UI development where you're going

to design and develop beautiful

responsive interfaces that scale

effortlessly. Client and server

components where you'll finally

understand when, where, and why to use

each one. Database modeling with MongoDB

where you'll structure your data the

right way from the start. API routes

where you're going to build robust

backends without leaving your Nex.js GS

project also server actions image upload

and hosting with clouden for proper

asset management use cache the hot topic

of nextgs 16 SEO that works well

analytics powered by post hog an

open-source platform that gives you

product insights web analytics feature

flags AB testing and session replays all

in one place and all these by ensuring

you write production level code with the

help of code rabbit's intelligent

roasting code reviews and AI assisted

development using Warp where you'll be

the architect and AI will do things for

you perfectly mirroring real world

industry workflows. So once again,

everything you need is hiding in the

description like that bug you've been

looking for. Free video kit containing

the codebase, Figma designs, the NexJS

guide, plus the testing course bundle

that's 33% off until it self-destructs

in a couple of days. Seriously, check it

out. I know you never read descriptions,

but this time it's worth it. Time to

cook. Let's go.

Let me start with a very important first

question. What does NexJS have that

React doesn't? In simple terms, Nex.js

simplifies the development process and

optimizes your applications. It does

that through its primary

functionalities. Some of which you have

to actively decide to use and others

that you get out of the box just by

switching to Nex.js. The first of

Nex.js's benefits is its architecture.

Originally, React had two types of

components, functional and class-based

components. But now, components are also

categorized by where they run. If a

component runs in the user's browser,

it's called a client component. And if

it runs on the server, it's called a

server component. This division was

released in React 19. And although

frameworks like Remix and Astro also

support it, Nex.js was the first to

adopt it and fully utilize it. Since

server components are more performant,

Nex.js automatically converts every new

component you create into a server

component, unless you specifically

instruct it not to, only if you need

some browser functionalities, but more

on that later. The second Nex.js benefit

is in the way it handles rendering.

While React 19 supports server

components, Nex.js CS extends them to

more advanced rendering strategies,

allowing you to choose exactly where and

when they'll be rendered, optimizing the

performance even further. First is

client side rendering, which happens on

your browser. The server sends a basic

HTML document and JavaScript code, which

the browser executes to render the

components and display the website. And

the second is server side rendering,

which involves rendering the web page on

the server before transmitting it to

your browser. When you visit a page, the

server processes and renders the

components on the server and sends back

fully rendered HTML and JavaScript code

to the client instantly displaying the

website. But why does this matter? Well,

on top of the fact that your website

will load in 300 milliseconds and have

page speed insights that look like this,

serverside rendering will significantly

improve your website's search engine

optimization. Client side rendering

makes it almost impossible for search

engines to crawl and index your websites

as they're completely empty. Nex.js

solves this issue by sending

pre-rendered code, giving Google plenty

of stuff to rank us on. The next big

Nex.js benefit is of course routing. In

React, you need to install an additional

React router package to create routes.

On the other hand, Nex.js doesn't

require installing a separate routing

package and uses a much more intuitive

approach to routing called filebased

routing. Each folder's name becomes a

routes path. For example, a folder named

about will create a new for/about route.

Super simple, right? And connecting

directly to the routing system. The next

best thing about Nex.js is its evolution

from a simple front-end library to a

full stack framework using the same

file-based routing system I just

described. You can also create

serverless functions to handle native

back-end API requests. This means you

can create an API endpoint by simply

creating a file called route.js JS in a

specific folder without needing to worry

about the server infrastructure. Nex.js

takes care of scaling automatically. And

there are many other scaling features

that Nex.js provides out of the box like

automatic code splitting. While code

splitting in React is possible, it

requires manual configuration,

especially as the application grows.

Nex.js automates code splitting by

default. Well, what does that mean? It

means that when a user navigates to a

different page, only the code for that

page is loaded, which significantly

speeds up page load times. Pretty handy,

right? But that was just one out of many

built-in performance optimizations that

Nex.js provides. Font optimization

reduces layout shift, improves loading

time by pre-loading font files, and

reduces reliance on external services

like Google Fonts. Image optimization

automatically compresses images, and

applies lazy loading, CDN support, and

more. Script optimization optimizes even

third party scripts. And all of these

great optimizations come right out of

the box with Nex.js. And it's not just

performance. Nex.js is the definition of

cutting edge. It supports the latest

features such as React compiler, MDX

file integration, managing most SEO

related tags, analytics that run without

blocking UI, fast refresh server

components, hot module replacement, and

more. Oh, I know that was a lot, right?

That's totally okay. Stay with me and

I'll teach you everything I know about

Nex.js in this crash course.

Let's dive right into the demo and start

using the React framework for the web

used by some of the world's largest

companies, enabling you to create

highquality web applications. You can

either click get started or just copy

this installation command. Now,

throughout the demo, you'll see me use

WebStorm,

a super powerful JavaScript and

TypeScript IDE that as of recently

became completely free for

non-commercial use, which means that us

regular developers can finally get the

benefits of having a powerful IDE and

not just use a regular text editor. So,

feel free to download it. The link is

down in the description. And another

thing that makes working with WebStorm a

breeze is Juny, a smart coding agent.

You can also download it as you'll see

me use it across this project and it

just improves your productivity so much

more. Like you can ask it questions or

you can ask it to do things for you.

Throughout the course, I'll show you

more of what it can do. So once that is

done, we're ready to start from the bare

basics by creating a new empty project.

Webtorm allows you to immediately start

with a Nex.js generator which will

install the latest version of Nex.js for

you. In this case, just so we can all

follow along together, I'll start with

creating a new project and I'll call it

Nex.js demo. And we'll do it using

TypeScript and click create.

Immediately, we'll be right within this

project. So, open up your terminal and

paste the command you copied over from

Nex.js. That is mpxcreate-

next- app and then add the dot slash to

generate it in the current folder. But

for now, I'll just delete this source

folder and the additional files that got

created for me by WebStorm, just so we

have a completely clean slate. Once you

press enter, you might need to install

the installer. But once you do, you'll

be asked a question. Would you like to

use the recommended Nex.js defaults.

See, the installation process for the

new version of Nex.js got streamlined.

You can still customize your settings.

Like if you choose this option, you'll

be given like 10 more questions to

choose exactly how you want to architect

your project. But in this case, the

recommended settings are exactly what we

need. TypeScript, eslint, tailwind CSS,

app router, and turboac. So go ahead and

select the first option. And that's it.

Nex.js just started installing the

dependencies. And there are just a few

of them. React and react DOM and Nex.js.

That's it. When it comes to dev

dependencies, there's also TypeScript,

all the different types, as well as

Tailwind CSS and ESLint. And in a couple

of seconds, your project code is right

here. Before we go ahead and run it,

there's a new feature in Nex.js16 called

Turopac file system caching, which

allows for significantly faster compile

times across restarts. All internal

Versell apps are already using this

feature. So if you'd like to enable it

for your project, head over to next

config and then right at the top you can

say experimental and turn on the turboac

file system cache for dev and set it to

true. Theopac is an actual word. Looks

like webtorm doesn't know about it. So I

will save it to the dictionary.

Now let's talk about the project

structure. Your project is set up and

ready to go. You'll see many files and

folders. So let me walk you through them

from bottom to the top. Starting with

tsconfig.json.

This is the configuration file for

TypeScript. It defines what should be

type checked, ignored and which rules to

follow. After that we have a readme.md

which is a simple markdown file that

explains how to run the project and

provides all other relevant information.

Then there's the post CSS config m.js JS

which is a configuration file for post

CSS which is a tool used to process CSS

with different plugins. You can see here

that it mentions Tailwind CSS as a

plug-in which allows you to use its

utility first classes within your

project. Then there's the package lock

JSON. It's a file that locks the

versions of dependencies and their exact

subdependencies ensuring that everyone

working on the project uses the same

exact versions. Then there's the package

JSON which contains all the project

dependencies and scripts. You can see

that the name of the project is Nex.js

demo. Its version right now it's set to

private. Then we have the scripts such

as mpm rundev which will run the

application in development mode build to

run an optimized production build. And

there's also start and the lint package.

JSON also keeps track of other

dependencies and dev dependencies which

are only ran when we're developing.

After that we have the next env.

This file should not be touched. It's

simply used as a next.js TypeScript

configuration. And then a super

important file is next config.ts

which allows you to configure your NexJS

features such as experimental options.

You can see that there are many that you

can actually use here. Image settings,

build settings, and more. There's the

ESLint config which allows you to

configure ESLint for linting.getit not

get ignore, which allows you to ignore

some files not to be pushed over to

GitHub. And then we have two folders.

The public folder, which is a place for

static assets. You always need to put

your images and other static data right

here. There's also a node modules folder

here, but I've hidden it because I never

actually have to go into it. It's the

heaviest object in the universe, you

know. Well, jokes aside, it's a folder

containing all the dependencies and

packages that are required for your

application to run. And finally, there's

the app folder, which we'll explore

next.

You'll primarily work within this folder

on most feature implementations,

including creating pages, layouts, API

routes, and more. So, before we dive

into the details of the files within

here, let's actually run our application

by opening up our terminal and running

mpm rundev.

This will spin it up on localhost 3000.

And if you open it up, it'll look

something like this. To get started,

edit the page.tsx file. Okay. Okay.

Let's find where that page.tsx is. Looks

like it is here. This file represents

the homepage or the forward/ route of

your page. It contains some boilerplate

code by default. So, let's remove it

entirely. run rafce which is a super

nice snippet that I often use to create

a simple react a functional export

component.

So press enter and we can call it home.

If this snippet didn't work for you, you

must head over to plugins or packages

and then search for react snippets.

Any package should do. In this case, I'm

using modern react snippets. Here we can

say something along the lines of welcome

to Nex.js. GS. No longer in modern

versions of Nex.js is it needed to

import React. It is done by default. So

the view is even simpler. Let's explore

other files right here. There's the

favicon.ico

at the top. Any file with this name in

the root of the app will become your

website's favicon. It's just a naming

convention that allows you to add that

little image that shows next to your

title within the browser tab. There's

the globals.css CSS which is where you

can write all your custom CSS or

Tailwind CSS utilities. Then there's the

layout.tsx.

This is the main entry point for your

application. So anything that you do

here will be applied across all pages

and routes. That's why here we're

importing and setting different fonts as

well as the application metadata. For

example, if you change the metadata from

create next app to welcome to Nex.js,

you can also change the description to

something like check out jsmastery.com

for more. Oh, and this is definitely not

true. JS Mastery is a real word. So,

I'll add it to the dictionary. That's

much better. So, now if you head back to

the browser, you'll see that the title

changed. And you can also see welcome to

Nex.js. If you go ahead and change some

class names, like making the text extra

large, like saying 5XL, or making it

underline, as soon as you get back to

the browser, you'll be able to see

changes instantly thanks to Nex.js's hot

module replacement. So, now that you're

familiar with the entire Nex.js

application structure, in our next

lesson, we'll get our hands dirty.

At the start of the crash course, we

talked about architecture where we can

write two types of components, client

and server components. If you remember,

I said that by default, the React

components you'll write are server

components. But are they really? If I

head over to page.tsx, where we have our

homepage component, let's add a console

log before running this return. I'll say

console.log log and I'll say what type

of a component am I? Sounds like it has

an existential crisis right here. But

don't we all when new versions of Nex.js

drop. Now tell me where do you think

this console log will show up in the

browser? I was about to say no, it won't

appear in the browser because it's a

server component, but in recent versions

of Nex.js, JS they actually extended

that server console log so that it

appears in your browser's console as

well. But don't let this confuse you.

This console log is not happening within

the browser. Nex.js is just sharing it

here with us for convenience. Server

components are rendered on the server.

So this brings me to the topic of React

server components. They're the

components that are rendered on the

server and their HTML output is then

sent to the client. Since they're

rendered in the server, they can access

serverside resources directly like

databases or the file system. This helps

reduce the amount of JavaScript sent to

the client, improving performance.

Server components are excellent when you

need direct access to serverside

resources like accessing files in a file

system or you want to keep sensitive

information well sensitive such as

access tokens and other keys safe on the

server. All right, but if server

components really are better, why can't

everything be a server component?

Well, if your component requires browser

interactivity such as clicking buttons,

navigating to different pages, and

submitting forms, then you need to turn

it into a client component. So, what are

React client components? Client

components are of course rendered on the

client side. And in this case, client

side simply means the browser. To use

them in Nex.js, you must add a use

client directive at the top of the

component. So, back within our demo,

let's create a new component. We can do

it within a new folder called

components. And then within the

components folder, create a new file

called hello.tsx.

Within here, I'll create a new React

functional component like this. And it

doesn't differ from the previous server

rendered one. All until one point when

we give it a use client directive. This

line right here will make sure that this

entire component is client side

rendered. So if we give it a console log

and say something like I am a client

component and now we import it into our

homepage by heading over to page.tsx

and we render it right here below this

div. But first, I'll wrap both of them

within a main tag. And then I will

render the self-closing hello component

which we're importing from app

components hello. Now back within the

browser, we still see this server log

which is fine. And of course, there is

the IMA client component console log,

which makes sense because we're

rendering this client component well on

the client, the browser. But to verify,

let's quickly check out the terminal.

Oh, and what is this? The log of the

client component is also here. But how?

Or more importantly, why? It's making me

question myself now. Well, there is an

explanation. Well, this is because

server components are rendered only on

the server side. While client components

are pre-rendered on the server side to

create a static shell and then hydrated

on the client side. This means that

everything within the client component

that doesn't require interactivity or

isn't dependent on the browser is still

rendered on the server. The code or

parts that rely on the browser or

require interactivity are left as

placeholders during serverside

pre-rendering. When they reach the

client, the browser then renders the

client components and fills in the

placeholders left by the server. I hope

that makes sense. And that answers the

question of what is serverside

pre-rendering, a pretty cool feature by

Nex.js. I hope that's clear now. But if

you're still unsure, take a second to

pause it and rewatch it until it clicks.

You can also add some additional cons

logs or components and then render them

within the page.x.

Don't proceed further if that doesn't

make sense. And for a deeper dive with

clearer explanations and more visuals, I

would recommend checking out the

ultimate Nex.js course where I break

down the entire client server

architecture in detail. So finally, when

should you allow Nex.js to turn your

components into serverside components

and when should you manually change them

to client side? Well, a good rule of

thumb is to leave it as serverside

component until you need some browser

interactivity, at which point you'll

most likely get an error and then you

can add the use client directive at the

top. Now that you understand the React

components and how they work in Nex.js,

there's an important update in Nex 16.

React compiler support is now builtin

and stable. It automatically memorizes

components to reduce unnecessary

rerenders. No more of those use memo and

use callback hooks. The compiler

analyzes your code at build time and

optimizes rendering behavior

automatically. To enable it, we have to

install the plugin. So, open up your

terminal and I'll actually keep this one

for my application running and then I'll

open up another one which I'll call

terminal within which you can run mpm

install babel plug-in react compiler at

latest. Once it installs, we can head

back over to our next config.ts.

And at the top, we can set the React

compiler to true. That's it.

Now, it's time to explore routing in

detail because doing everything in a

single page is boring, right? Like right

now, we only have a homepage, but what

about adding an additional page like

forward/about?

Well, Nex.js GS uses filebased routing

which means that all the pages and

layouts can be right here within the app

folder. Oh, and therefore it's important

to mention the components folder

contains components and not pages which

means that it needs to be outside of the

app folder. Then within the app, create

a new folder and call it about. Within

about you can create a new page called

page.tsx.

And in there, you can render a simple

component

that simply renders an H1 that says

about. Now, if you head back over to

your application and modify your URL to

for/about,

you can see that you'll instantly be

redirected to the about route. It's

being displayed in the UI. That's how

you create routes in Nex.js. As opposed

to a very boilerplate way to do it in

React using React Router, in Nex.js, we

use a filebased routing system where

folders are used to define routes. The

folder name becomes the route name and

the page.tsx renders the UI for that

route. It's like a special file for

displaying the routes content. But

that's not enough. Let's say you're

developing an admin dashboard within

this application and you want to create

a route something like slashdashboard

slash users and forward slashboard

slan analytics. These are two different

pages. Of course, you can't create two

folders with the same name, right? This

is where we use nested routes. So, let

me show you how we would do this. Simply

create a new folder called dashboard.

Inside of which we'll create two more

folders, one named users and the other

named analytics.

Both of these folders will contain their

special page.tsx

within which I'll simply runce.

I'll rename this one to analytics. And

then within users, I'll also create a

page.tsx.

And I'll call this one users.

Now, if you visit both of these routes

by heading over to dashboard and then

users, you'll be able to see users. And

if you head over to dashboard/analytics,

you'll be able to see analytics.

Perfect. That's exactly what we wanted.

Still, this may not be enough because

what if you want to display each user's

profile in the dashboard? Let's say that

we have four predefined users in

dashboard users. So right here, I'll

call it dashboard

users that can be within an H1. And then

right below it, we'll have a ul an

unordered list with a class name of

margin top of 10. and then within it

I'll create an LI with users from one to

four like this. Now let's say that you

want to make each one of these list

items clickable so that when you click

on user one you want to show full user

details on a new page like dashboard

users user one and so on.

You can't create these folders manually

right here within users like user 1,

user 2, user 3. I mean, you could, but

you would not be going anywhere because

the next day there's going to come a

user 5, 6, or 10,000 and your life can't

simply turn into creating folders. I

think you have a bigger purpose than

that. So, this is what dynamic routing

is all about. It's a route where part of

the URL can change or be dynamic,

typically based on the user input or

specific data. And creating a dynamic

route in Nex.js is simple. All you have

to do is wrap the changing part in

square brackets.

In our case, it'll be forward/dashboard/

users. And within users, I'll create

another folder that'll start and end

with square brackets. and within it I'll

say ID.

Then within this weird named folder I'll

add a new page.tsx.

Now we'll modify the general users page

to make each one of these allies a link.

I'll do that by selecting multiple

cursors and render a link component

coming from next link. So make sure to

import it at the top. Then to each one

of these links, I'll give an href of

forward slashdashboard

slash users slash and then their number

like one 2 3 and four. We can now close

this link and then add the user text

within it. That'll look something like

this. Now, before we test these links

out, if you now head over into this ID

page and run rafce and call this user

details

and then you head back over to your

forward/dashboard/

users page, if you try to click on some

of these links, you'll automatically be

redirected to the user details page. 1 2

3 4.

But each one of these just renders the

text of user details. It's nothing

specific. So how should we know which

user's details should we actually

render? Well, exactly for that purpose,

there's a concept of params. See this

part within square brackets, the ID,

whatever it says right here gets

populated within params. So the

structure the params and we can define

their type. params are actually a

promise which gets resolved

in an id which will be of a type string

which means that we can now extract the

ID from params but since it's a promise

we have to await it which means that we

need to turn this entire function into

an asynchronous function. Yep, that's

valid. These are called page params and

you can get these through the next.js GS

page only. If you want to get this info

somewhere else, you either have to pass

it down through a component or use a

hook called use params. So what you can

do now is modify the text right here to

render an H1 and say showing details

for

user number and then we can render the

ID because the ID is actually either 1,

two, three or four. So if you head back

and now switch over to a couple of

users, you can see that each one of

these page will be a new dynamic user.

Right now we're just rendering their

number, but I think you can imagine that

later on we can show entirely different

profile pages, user details, and maybe

the posts they generated on this

platform. So now you know how the

file-based routing in Nex.js works, how

we can do nested routes as well as

dynamic routes through page params.

Great work. Next, let's talk about

layouts. Earlier, I briefly went through

the main layout file. This one right

here in the app. And I call this the

starting point of our application. To

demonstrate that in the concept of

routing, if you go back to that file and

then right here at the top of the body,

you add some piece of text like coming

from the main layout.

And if you go back to your main route,

which is the homepage,

you'll see coming from the main layout,

then the text right here, and then

hello. But if you switch over to

localhost 3000/about,

you'll also see the text that says

coming from the main layout. And this

will happen for every other page,

including dashboard analytics or

dashboard users. Yep, it's here, too.

This is because layout tsx acts as the

parent for all of these routes.

It allows you to share UI elements like

this piece of text right here across

multiple routes. For example, you can

place features like a navbar or a footer

right here. Let me give you an example.

I'll say navbar right here. And then

below the children, I'll render the

footer.

So now if you go back you can see that

it appears across all of these different

pages on the homepage on the about page

and even on the analytics users page.

Simply add them once within the layout

and they'll be available whenever

needed. In Nex.js a root layout like

this one is always required but you can

create additional layouts if necessary.

Let's say you want to render a specific

UI just for the dashboard routes. these

two right here. You can do that by

creating another layout inside of the

dashboard folder. I'll call it the same

layout.tsx.

Don't try to call it something else

because otherwise Nex.js won't recognize

it. Now, within it, you can create

another React functional component

because a layout technically isn't

anything else than just a component, but

it works on the principle of using props

of children. children is nothing else

than a prop that is of a type react

react node. So basically it's another

component that we can pass within this

layout for it to get rendered. So if you

wanted every single component in the

dashboard to have like a special

dashboard navbar, you could create a p

tag here that says dashboard navbar and

then render the rest of the children

which is basically the full pages that

you're trying to render. If you now

visit the users dashboard, you'll see

both the regular navbar coming from the

original layout as well as the dashboard

navbar coming from the second layout.

Hopefully that makes sense, right? But

wait, what if you don't want the root

layout to appear in the dashboard routes

and only be shown in non-dashboard

routes like the homepage? This means

that you need a separate navbar for the

dashboard and another one for the

non-dashboard routes which is very

similar to how things work in real life.

Right? In such scenarios, you can use

route groups. They allow you to organize

your route segments and project

structure without impacting the URL

path. This means you can create folders,

but unlike nested routes, these won't

show up in the URL.

How to do that is by simply wrapping the

folder name inside parenthesis. In our

case, let's create two folders with two

names. The first one will be right here

within the app and I'll call it

dashboard, but this time wrapped in

parenthesis.

It'll be for all the dashboard related

routes. And then I'll create another

folder within the app and I'll call it

root also in parenthesis for other

non-dashboard routes and move the

page.tsx as well as the about folder

within the root folder.

Now remove this navbar and footer from

the original layout. This is the primary

layout. And instead create a new layout

within the root directory.

It'll be called layout.tsx.

You can run rafce. As you know, you're

going to get access to the children. So,

we can even duplicate the layout that we

have within the dashboard

and simply paste it right here. This

time I'll give it just the navbar.

So now we have the root within it. You

have some folder of about and then you

have another layout and page. also move

this layout from the dashboard without

parenthesis into the outside dashboard

folder. So now both of these route

groups so-called have their own layouts.

So with all of those changes, let's

check how everything is working. Now if

you head over to the homepage, you'll

see that here we have the general

navbar. If you head over to about,

there's also the general layout navbar.

But now if you head over to localhost

3000 slashdashboard

slashanalytics for example

here you'll see that we have a dashboard

navbar and this one is also shared

within dashboard users.

Perfect. So why are we using these route

groups in the first place? Well route

groups allow you to create folders

without affecting the URL. See, you

don't have to go to root about or root

page. This is not taken into account

when you go to the URL bar. Rather, it

is still just home or forward slash for

the home and about for the about. And

then you don't have to do the dashboard

dashboard analytics. Rather, it is just

dashboard analytics because this is not

a route group, but this one is. So, even

though creating route groups isn't taken

into account when forming URLs, it still

allows you to add layouts inside of

them. And keep in mind that there has to

be only one single primary homepage.

Since route groups aren't taken into

consideration when forming URLs, if you

create a new page.tsx within dashboard

here and you already have one within

root, that would not work because these

two files would fight on which one would

prevail. So let me give you an example

right now. If I create a new page tsx

within the dashboard and create a new

component within it, you'll get an error

saying that you cannot have two parallel

pages that resolve to the same path.

Check out dashboard and root. So I'll go

ahead and delete this one. And from

Nex.js 16 onward, routing and navigation

have been completely reworked, making

transitions much faster. The biggest

update is layout dduplication. When

pre-fetching multiple URLs that share

the same layout, the layout is

downloaded only once instead of per

link. This optimization will happen

automatically with no code changes

required. That's what I like to see.

Let's talk about error handling. In

Nex.js, there's a special file called

error.js JS or TS if you're using

TypeScript that catches errors and

displays them on the UI. Similar to how

we were able to create multiple layout

files for each folder, be that a route

group or a route folder, we can do the

same for the error.ts file, let's throw

an error on purpose within the about

page. So head over to root about

page.tsx.

And right at the top of the page, I'll

say throw new error. And let's say that

this feature is not yet implemented like

this. Now if you visit the about page,

you'll see what most developer don't

like to see. A huge error popup that

breaks our entire application. Instead

of this, what would have been much nicer

would be to see this error nicely

packaged within a nice UI. To fix this,

we can create a special air.tsx file in

the root folder. So let's do it right

here. And I'll call it error.tsx.

And apparently this error file has to be

a client component. So we have to add a

use client directive. Do you know why?

Well, it's because these errors happen

on the client or user side. So if we

want to show them there, it has to be a

client component. Now, if you check out

the error handling documentation, you'll

see an example of a simple client error.

Just search for error.tsx. I'll go ahead

and copy it and then paste it right

here. It'll look something like this. It

says air boundaries must be client

components. We import use effect for

side effects. We get the error and the

reset coming from props. We console lock

the error within the use effect.

Whenever the error changes and then we

display a message saying something went

wrong and then maybe a button that helps

us reset it. So, if you revisit the

about page now, even though there's

going to be a warning that you can open

up right here, you'll be able to see

something went wrong and then try again

buttons right on this page as well. So,

you can more easily explain to the user

what really happened. If you just want

to have one global error, then you can

do it by creating a global error.tsx

file in the root of the app folder.

Unlike layout.tsx, which displays

everything from its parent, the error

file works differently.

Only the closest error file to the route

takes priority, meaning you won't see

the content both from global error.tsx

and from the root error tsx. Errors will

bubble up to the nearest parent error

file, not all of them. Make sense? And

to talk about something else other than

errors, let's talk about loading UIs.

Loading UIs in Nex.js GS works very

similarly to error handling. You want to

show some kind of a loading progress

while data is being fetched for users

with a slow internet connection. It's as

simple as adding a new loader.tsx

file within the app. And within it, you

can add some kind of a loader or spinner

component.

While the data is loading, Nex.js will

show the content you specified in the

loading file. And once the data is

received, the content in the page you're

trying to render will be shown. It's

super useful and surprisingly easy to

do. I've covered this in more detail in

the Ultimate Nex.js course. As you can

see here, there's an entire section

dedicated to it, complete with

challenges to help you practice. But in

this crash course, you'll also see this

in action in the next segment where

we'll actually do some real world data

fetching. Nex.js XGS16 also introduces

forbidden and unauthorized special

files. They work similar to loading. You

can use them to show a nice UI asking

user to sign in or tell them that they

have no permission to view the page

instead of simply showing an error or

redirecting them. You can explore all of

these within the next.js docs or within

the ultimate next.js course if you want

to go deep.

Data fetching. The most interesting

concept in Nex.js.

There are different ways in which we can

fetch content. A traditional way is

using a use effect. For example, this is

what you would do. Let's say that you

have a homepage where you're trying to

set and fetch some albums. You create a

new empty use state. You declare a use

effect within which you declare an

asynchronous fetching function.

Within it, you have an await fetch where

you're trying to get some albums and

then you return that JSON and set it to

the state. Finally, going a bit down,

you map over those albums and show the

data. But this isn't super efficient.

There is a better alternative to fetch

and it's happening on the server side.

Not only is it faster and more

efficient, the code is also so much

cleaner. Check this out. You declare a

new functional component called home.

And immediately on top of it, you make a

fetch request. You check if it fails. If

it doesn't, you simply declare it and

set its response.json to the album's

variable. You map over it and display

the details. Go ahead, pause this video

and test it out. You don't necessarily

have to do all the styles, but you can

at least try to fetch the data, map over

the albums, and show each album's title.

If you do it, visit the website and see

if it works. You'll not see anything.

You'll have to refresh to see the

result. And it's not because HMR is not

working, but rather HMR is caching your

content. In latest versions of Nex.js,

JS there is a new feature called server

components HMR cache that allows you to

cache fetch responses in server

components across hot module replacement

refreshes in local development. What

this means is you'll have faster

responses and reduced costs for build

API calls. But now coming back to the

difference between server side fetching

versus client side fetching. First of

all, you'll notice the code difference

between the two strategies. With

serverside fetching, you wrote fewer

lines of code, which improves the DX

developer experience. But that's not the

only benefit. Serverside fetching has so

many more benefits like improved initial

load time as a serverside data fetching

allows the page to be rendered with the

data already included. It reduces the

time to first contentful paint FCP. In

the client side example, the user sees

an empty page until the data is fetched

and then rendered. The second and most

important benefit of server side

fetching is better SEO. Search engine

crawers can more easily index content

rendered on the server as the content is

already provided in HTML format.

In contrast, client side fetching may

result in content not being visible to

crawlers right away since it first needs

to be fetched and then displayed on the

UI, which can negatively impact your

SEO. Next, not only is the code shorter,

but the logic is simplified.

Server components allow you to keep data

fetching logic on the server closer to

your data source. This can simplify your

component logic and reduce the need for

use effect and use state hooks. And the

next benefit is not that easy to

understand at first and it is automatic

request dduplication. Nex.js provides

that automatic request dduplication when

fetching data on the server which can

improve performance and reduce

unnecessary API calls. Basically,

request dduplication makes sure that

when the same data is requested multiple

times at once, only one request is sent.

It stops duplicate requests from being

made. And when talking about benefits of

the server side fetching versus client

side fetching, I really can't miss on

improved security. Keeping API calls on

the server allows you to better protect

sensitive information like API keys

which should never be exposed on the

client side. And adding to the list of

benefits, we have reduced network

waterfall. Clientside data fetching

often leads to a network waterfall where

requests are made sequentially.

Serverside fetching can more efficiently

parallelize those requests. I'll teach

you how to do these parallel requests in

our build and deploy project. So, keep

watching. But this isn't just about

fetching. You can server render any

other calls. Maybe a direct database

call to Prisma to get the list of posts

or even with mongoose and MongoDB like

this. That's the beauty of Nex.js.

This is achievable because these

components are React server components

which allow you to access server related

resources directly. This means we can

make direct database calls instead of

needing to create an API and then fetch

that API once again. And if you're still

not convinced, you can always go for

client side fetching. How? Just add use

client to the top, bring back the use

effects, the use states, and you're all

set. Next.js will allow you to do

whatever you think is best. And let's be

honest, this is how we all used to use

Next.js when we first transitioned over

from React. It only feels natural, but

it is the wrong way to use Nex.js. And

that's what made me create the whole

ultimate Nex.js course in the first

place to teach Nex.js the right way. But

now take a moment to test both client

side and serverside rendering. You'll

notice the differences I mentioned such

as seeing the blank page initially with

client side rendering or if you inspect

its source and see that nothing is there

or client side not functioning at all if

you disable JavaScript. In contrast,

serverside fetching will still display

the results even if JavaScript is turned

off in the browser.

I have to tell you a bit about API

routes.

Enough with front-end stuff,

optimization caching performance and

all that. It's time for some backend

work. If you've ever done some backend,

even creating a simple hello world from

server message requires a fair bit of

setup. It involves setting up a project,

installing necessary packages like

Express for Node, writing server code,

setting up Express the port, and then

making that port listen, running it, and

then deploying it using some paid or

free service. so you can finally use it

on the front end.

It might not seem like a big deal when

you're just reading or looking at the

code, but things quickly start getting

complicated when you have to write

various routes, middlewares, and so on.

But in the newest version of Nex.js,

it's super simple, much closer to what

we did on the front end. You just create

a special file within a folder for the

specific route, and you're all set.

There's no need to set up, manage, or

monitor an active server separately. If

you want to show the same message hello

world from backend in nex.js, you simply

need to create a folder with any name

and then create a special file named

route.ds inside it. From there, you can

immediately begin writing server code.

Export async function get return

response.json

message hello world from back end.

That's all there is to it. Your folder

name serves as your API route name with

your business logic neatly encapsulated

within this special route file. If you

now go to the browser, modify the URL

and add hello world to it, you'll see

hello world from back end as a response.

But how can you create other API

endpoints like post, patch, delete, and

more? Well, for that, let's create a

book endpoint with a local array as a

database. A common practice when

creating route handlers is to create a

folder called API and write all the

routes inside it. So create this API

folder in the app directory and add a

database file for storing some dummy

books. Then you can create two routes

get and post in app API books route.tsx.

These are nested routes similar to what

you explored previously in the routing

part for the UI. For the delete and put,

you'll have to create dynamic route

handlers and you already know how to do

that. app API books and then dynamic

square brackets idward slout.ts.

And inside of it, you can export async

function put for the update request and

then export async function delete for

the delete request. And then you can add

the logic. So far this feels good.

Similar to what we did with UI routes,

but this time for writing server code

and creating APIs.

So let's test them one by one to see if

they work or not. And there you go.

Everything works perfectly. This is how

route handlers or APIs work in Nex.js.

It's super simple and straightforward.

And the creation of APIs in Nex.js GS

was nice, but how can you use them on

the UI? Well, it's a simple fetch. Just

create a books route real quick and call

the get API route to fetch the content

const response await fetch localhost

3000 API books. You get them from the

response, set them to the state, and

render them. If you visit the books

route, you'll see all of your books as

easy as it could be. Thanks to the

serverless architecture of Nex.js GS and

React 19 React server components.

And let's talk about caching. Caching

isn't new, but in Nex 16, it's been

completely reworked. So what is caching?

It simply means storing data

temporarily. So it can be reused instead

of refetched or rebuilt. In Nex.js,

caching happens across multiple layers.

There's a browser cache, which saves

static files locally. There's the server

cache, which stores pre-rendered pages

and API responses. And then there's the

data cache, which remembers fetched data

to avoid repeat requests. Together, they

make your app feel instant. So, let's

talk about the new caching model. See,

the old modes like the SSG, ISR, and PPR

still exist, but now they're just

outcomes of how you define cache

boundaries, not separate settings. You

no longer choose SSR or SSG. You simply

define what gets cached and Nex.js

handles the rest. You can enable this

new system by simply adding an

additional flag to your next config.

Caching is disabled by default. So you

must explicitly decide what to cache.

Like use client or use server. You can

mark routes, components, or even

functions with use cache. This tells

Nex.js to store and reuse the output if

inputs haven't changed. For example, you

can define it on a file level, component

level, as well as on a functional level.

Simply placing use cache at the top of a

layout or a page pre-renders it at build

time, stores it in memory, and then

revalidates it automatically every 15

minutes by default. If you want to

fine-tune how cache works, there's the

cache life method which controls for how

long data stays cached. You can write it

something like this. Use cache at the

top, import cache life, and then define

cache life. maybe hours which is going

to cache the data below it for 1 hour.

You can also define custom lifetimes in

your config and you can also use cache

tag to group cached items for easier

invalidation.

Cache life controls when to clear and

cache tag controls what to clear. To

refresh constant instantly you can just

use revalidate or revalidate tag. Now,

when talking about caching, we also have

to talk about partial pre-rendering or

PPR. See, with cache components option

enabled, you don't need PPR set to true.

Static parts marked with use cache are

pre-rendered automatically, while

dynamic parts stream in with React

Suspense. The takeaway here is that this

is a completely new caching mindset.

Same principles, different syntax. It

will take some time to adjust, but once

you do, it'll give you precise control

and better performance. Let's just hope

that we don't see use and next next.

Jokes aside, I already started working

on the new caching module within the

ultimate next.js course.

But now, let's talk about something even

newer, a feature that'll make deployment

and scaling way more flexible. After V16

of NexGS, we also have build adapters.

They're currently in alpha and it's a

big deal for everyone using Next. Until

now, the NextGS build process was

tightly connected to how Versel worked

behind the scenes. That made sense.

Versel created Next, but things are

changing. With a new build adapters API,

you and hosting providers can hook

directly into the build pipeline and

customize it. Think of an adapter as a

small bridge that teaches Nex.js how to

build for different environments.

Adapters can modify your Nex.js is

config before build time. Transform the

final build output or adjust how your

app runs depending on where it's hosted.

Be it Versel, AWS, Cloudflare, Netleifi,

or even your own server. This means zero

config deployments on any platform,

environment specific optimizations, and

most importantly, freedom because now

you're not tied to just one provider.

It's the start of a more open and

flexible Nex.js ecosystem. So, it's

definitely something to keep an eye on.

One final thing I want to teach you

before you're ready to start creating

your NextJS application, and that is

search engine optimization, specifically

how we use metadata in Next.js to

improve our SEO. And when I mention

metadata, I'm referring to the look and

feel of our website when we share it

with others on messaging platforms or

post it on social media platforms or on

internet in general like for example in

search engines. In today's world, we

need to ensure that our content is

sharable. So there are two ways in which

we can manage metadata in our next.js

application. The first one is config

based. All you have to do is create a

JavaScript object in the layout or any

kind of page file and export it. Nex.js

will automatically detect it and turn it

into relevant meta tags for those

routes. Something like export const

metadata is equal to and then in there

you can provide all sorts of different

SEO properties such as title,

description, thumbnail, and more.

because it's higher on the priority

list, it'll override the default

specified in the global layout. This

allows you to either define unique

metadata for each route or rely on the

metadata from the root layout. It's

entirely up to you. But everything we

discussed so far is just static metadata

means that it's not going to change.

Home is always going to be home. But

there are also going to be cases in

which you want to create dynamic

metadata based on some kind of content

on the page such as a blog title. It's

super simple. The only thing you have to

do is export a new async function called

generate metadata which gets access to

params. Params being the same params

that we had before from dynamic routes.

You can extract the ID or the name or

anything else. Based on that ID, you can

get full resource details or user

profile details, whatever it is. Then

you can use those details to formulate

SEO title, descriptions, thumbnails, and

more. And you can simply return a

dynamic object of all of these

properties. That's it. As simple as

that. Are you with me so far? Good. And

the other way in which we can set

metadata in Nex.js is filebased

metadata. As the name suggests, you can

put files like a robot, sitemap,

favicon, open graph images or other site

icons directly inside the app folder and

Nex.js will automatically detect and

generate corresponding meta tags. For

example, you can have an app and then a

favicon and then an icon and then an

open graph image, Twitter image. All of

these properties will get added to your

meta tags. It's just about adding the

files with the right names. They have to

be proper names directly inside the app

folder. It'll work out the same as the

config based approach. You can find the

full list of all files that can be

created to define metadata here. But for

the time being, I still prefer creating

it by exporting the config file from

layouts or individual pages. And it's

worth noting that file-based metadata

has a higher priority and will override

any config based metadata. So if you set

it in a file, it'll be used instead of

the ones that you set in the

configuration. So now you know how to

make your apps sharable, SEO optimized,

and search engine crawable. With that in

mind, I think you're ready. First, there

was a lot of theory, and then there was

more theory disguised in this practical

part, but now you're ready to dive into

code. You're ready to dive right in and

build and deploy your Nex.js GS app with

all of these optimizations, performance

updates, and new features baked right

into it.

And now comes the more exciting and

hands-on part of this crash course.

While understanding the theory is

essential, knowing how to apply it is

what truly sets you apart. So, let's put

everything you've learned into action by

building and deploying dev events.

At first, it might seem like a boring

application, just two pages where users

can browse upcoming events, view

details, and book a spot by entering

their email, like a newsletter signup.

But I've chosen this idea for a reason.

Behind that clean, modern UI lies a full

stack learning experience. See, by

building this app, you'll get practical

exposure to file-based routing, React

server components, client versus server

components to understand when and why to

use each database modeling where you can

design and structure backend data layer

API routes that you can build and

connect your front end to them, server

actions to perform server side mutations

securely. You'll also apply the new use

cache caching model for instant updates

and then we'll also track the analytics

of our platform to understand how our

users interact with it. This project

will walk you through design,

development and deployment all the core

stages that bring any application to

life. So let's dive right in

to start developing your app with the

framework used by some of the world's

largest companies. We can start with a

single command mpx create next app at

latest. But first we have to set up our

coding environment so that we can

actually paste that command somewhere.

I'll be using webtorm as my IDE as of

recently it became completely free for

non-commercial use. I'll leave the link

down in the description so you can

download it and try it out too. Once you

open it up, you'll be able to quickly

create a new project. I'll start with an

empty project and name it Nex.js crash

course. Create it and open it up. Then

you can open up the built-in integrated

terminal and paste the command you just

copied. But make sure to add a dot at

the end which will make sure that the

application gets installed within your

current folder. And then it'll ask you

whether you would like to use the

recommended Nex.js defaults such as

TypeScript ESLint Tailwind CSS App

Router, and Turboac to which we'll say

yes, this is the exact text stack that

we're using. Then it'll proceed with

installing the necessary dependencies

which there are very few of such as

React, Reactdom, and Next, and then also

dev dependencies from TypeScript and the

corresponding types over to Tailwind CSS

and ESLint. Once it installs, you can

run mpm rundev to run it on your local

host 3000 and then open it up. We get

this new and updated boilerplate page

which looks even simpler than before.

And it says looking to get started just

edit the page.tsx file. So let's explore

the app structure. You can see that not

a lot has changed. We still have this

page which contains the bulk of the

content. So let's go ahead and remove

all of it and just run rafce to quickly

spin up a new react air function

component with exports. React imports

are no longer necessary. So we can just

say welcome to Nex.js 16. If this

command didn't work for you, you can

head over to your plugins or packages

and search for React snippets. In this

case, I'm using modern React snippets.

If you made the changes, you should be

able to see that now it says just

welcome to Nex.js16 on your local host

3000. Now throughout this course, I'll

teach you how to build a dev event

next.js application. I found this to be

the perfect project to go over all the

primary but also the latest Nex.js

functionalities. So together we'll

explore what Nex.js GS has to offer

while building a couple of these

beautifully designed and fully mobile

responsive pages. Of course, the focus

of this course is the main star of the

show, which is Nex.js. So, we don't need

to focus too much on the CSS. For that

reason, in the description down below,

you'll be able to find a complete media

kit containing the link to the Figma

design, which you can explore and

rebuild on your own if you want to, a

complete source code, as well as some

snippets that are going to make the

building of our application easier,

allowing us to copy very lengthy and

redundant uh presentational stuff and

allow us to focus only on what matters.

So, let's start with copying this

global.css CSS file and then heading

over within our application

app globals.css.

Select everything and overwrite it with

what we copied over from the globals.css

within the snippets down below. What

we're doing here is just setting up the

base theme of our application with some

styles that we'll be using later on.

modifying the color of the body as well

as adding some helper utility functions

that are going to help us style

different headings, navigation items,

and more. And then some components for

the hero sections, events, cards, and so

on. Now, you can see that this CSS file

also requires us to install TWW,

Tailwind Animate CSS. So, go ahead and

install it, too. It is a dev dependency

that some styles require. So open up the

terminal. In this case, this terminal is

already running the application. But

thankfully, WebStorm allows us to open

up multiple terminals. So I'll say app

and then I'll open up another one which

I'll call just terminal. Within here,

you can run mpm install-save-devtwan

animate CSS. And as soon as it gets

installed, you should be able to see

that this red squiggly line will be

completely gone. There we go. Here it

is. Now, alongside all the styles,

there's also a couple of different icons

and images that we'll need for this

application to look this good. Starting

from this little logo icon to maybe some

images that we can use for the events or

maybe we have some icons that we want to

use here. You can see that we're using

this very cool icon style. So, I took

some time to find them and I'll give

them to you right here within the assets

folder.

So, in the video kit, click on the

assets,

download them. Don't worry, there's no

viruses on there. Once you download

them, you can unzip them. And here

you'll see a public folder. So, what you

can do is delete the current public

folder.

And then simply drag and drop this new

one in, as well as drag and drop this

new favicon that we have for our

application into the app folder to

replace the current one. Now, if you

open up the app, it'll still be more or

less the same as what we had before, but

let's actually put it side by side by

our IDE, so we can see the changes we're

implementing live as we code them. So,

I'll drag and drop it right here to the

side and give it some space. Now, you

can see under the tab name that the logo

changed or the favicon, but the title is

still create next app. So, let's go

ahead and modify that by heading over

into app layout.tsx. tsx where we're

importing different fonts and here's the

app metadata. So what we can do is first

change the metadata to the real app name

such as dev event which actually is the

hub for every dev event

you you mustn't miss. That's exactly

what we'll build. And we'll also be

using a bit more interesting fonts. So

let's go ahead and update these two

fonts that we have not gist and gist

mono rather we'll be importing now bear

with me when it comes to the title

sheisted grotesque. This is the font

we'll be using and we'll also add the

Martian mono. Okay,

from font Google so let's go ahead and

define them right here. This is the

whatever the name is uh grotesque. We

can use the camel case right here and

we'll use this name to create it. I'll

give it the actual variable name just as

the actual name is. And you can see my

webtorm is complaining about this not

being an actual word. Uh but believe me

it is. So we are going to save it to the

dictionary. Same thing for the grotesque

so that in the future it actually knows

that this is a real word. Okay. And the

same thing for the Martian mono. We can

call this font martian mono and we're

going to get the Latin variant of it.

Perfect. Now that we have declared the

metadata, we can change these two fonts

below by saying class name uh shipstead

grotesque as well as the Martian mono.

Uh perfect. And let's fix this uh

variable name right here. So it's

actually Martian mono. Um, so now we'll

be able to use these two fonts across

our application. And we can also add the

minh screen, which means that the whole

body will take the minimum of 100% of

the screen because everything should

actually fit in there. Perfect. So, we

can still see just the regular welcome

to Nex.js 16 test, right? To make it a

tiny bit more interesting, we can head

over to that page and switch it over

into an H1 tag, which will automatically

make it inherit our Tailwind styles.

Why? Because in our globals.css,

if you search for H1, we're applying the

following styles to every single

element. Don't worry, whenever we're

using some complex class names, I'll

always explain how these styles are

actually getting applied, just as we did

right here. And since we're working on

the layout right now, keep in mind that

our design has this very interesting I

don't even know how to call it like a

ray design. You can see rays of sun uh

some bluish greenish sun popping from

the top right corner. So while we're

working on the layout, since every page

has it, we can immediately go ahead and

implement it. For these rays of sun, I

found this uh very cool react bits

library which is a component library for

creative developers and I just want to

give them a quick shout out for this

component. You can see how the rays

actually follow the cursor and they

provide you with the full code for it.

So you can just Google for react bits

light rays or I'll leave the link down

in the video kit then head over to the

code and follow the installation and the

usage. I'll use the CLI installation.

So, it's going to automatically do it

through SHAT CN, which is another huge

advantage. So, switch over from manual

to CLI and copy the command and paste it

within our terminal.

It'll ask us whether we want to install

SHAT CN. That's for sure going to be a

yes. Then, when you get asked some

questions such as whether you want to

create a components JSON file, say yes

to that. And then, which color would you

like to select as the base color? Let's

go over with neutral. It'll add all that

info within our components JSON. Now,

what you can do is create a new

component within the components folder.

So, first generate the folder itself

called components and then a new file

called light rays.tsx.

You can go ahead and automatically copy

the code over from here. But to make it

fit a bit better with the design, I've

made some changes to the component and

provided the updated version to you

within the video kit down below. So you

can just copy it from components UI

light rays. So just go ahead and paste

it into this file we just created. You

don't have to worry that there's so much

code here. You can think of this as a

typical shadian component that you do

not touch. The only thing I've done is

added the top center offset which will

move the trays a bit so it looks exactly

as it does in the design. Now we want to

apply these light rays to the whole

application by putting them inside not

of the page because then we have to do

it for every single page but rather

inside of the layout because what

happens here will actually be translated

over to every single page that is within

this layout. So right here at the top of

the body, go ahead and copy the usage

part of the light rays from the

documentation and paste it right here.

You have to autoimp import it from light

rays component light rays. And we can

change how it behaves starting with rays

origin which I'll set to top center

offset. If you head over to your

application, you should be able to see

how it looks like. We definitely want to

remove this import statement. There we

go. And we don't need to put it into an

additional div. We just want it to be

there right within the body. There we

go. So you can see how the rays are

moving right now. And we can also change

the ray color. I found the color of hash

5DF ECA to work nice. It has this

greenish hue. You can play with the rays

speed. I'll set it to something like 0.5

for them to be a bit slower. The light

spread can be around 0.9. Ray length

will be about 1.4. Follow mouse can be

set to true.

Mouse influence I will lower it

significantly because the goal of this

app is not for the users to play with

the actual rays. Uh it is for them to

check out dev events. So whenever you're

implementing some animations, you want

to make them simple. The noise amount

can be set to zero and distortion can be

set also to a minimal amount with no

need to provide a custom class name. I

will put the rays into a div

like it was before, but I'll provide

some different class names such as

absolute. This is very important because

this will position the light rays

absolutely on the page, which means that

it'll not interact with the rest of the

elements on the page. I'll also insert

it to the top by saying insert zero and

top zero. Giving it an index of Z minus

one. So that way it appears behind the

elements with a min of screen.

Perfect. And I'll also give the children

the main tag. So they'll be wrapped

right within the main of the

application. That is where we'll load

the actual content of the page. Perfect.

So, welcome to Nex.js. The rays are at

the top. Finally, within our page, to

make it look a bit nicer, we can wrap

this into a section. We can give it an

H1 within that section that'll have a

class name equal to text-c center, and

it'll say the hub

for every dev. We can add a break tag in

between

event. you can't miss similar to what we

had in our layout.

And then we can have another P tag right

below it that will say something along

the lines of hackathons,

meetups, and conferences

all in one place. And I like it how

WebStorm actually catches the typos, not

just code mistakes. So I can just hover

over it and automatically fix it. And

I'll give this P tag a class name of

text-c center as well as a margin top of

five to divide it a bit from the main

title. Okay, we have the main content,

but what happened to the styles? It

seems like we don't have that dark

background we used to have. That's

because after we installed this package,

it went ahead and modified our

globals.css. So just once again go ahead

and copy the final one. Head over to the

globals.css file and override it. If you

do that, you'll notice that the styles

will be there. And you'll also see very

light rays at the top. But if you extend

it to full screen, you can see that

they're much more pronounced, but still

not taking away from the overall

experience of the application. So just

like that, we've successfully set up our

project and we can already see something

on the screen. In the next lesson, let's

develop even more parts of the homepage

UI.

Let's start developing the other parts

of our homepage. Starting with this

explore button, we can create it as a

new component. Right here within our

components folder, I'll create a new

file called explore

btn.tsx.

We're creating a separate component as

button is associated with event

listeners that have to happen on the

client side. This kind of thinking is

necessary when developing NextJS

applications because it's all about

serverside rendering. See, I'll run

rafce right here to quickly spin it up

and you'll get a better idea of what I'm

saying. This component will be a button,

specifically a button that we're using

within our page. So, let's immediately

go ahead and import it below our P tag

explore btn as a self-closing tag. There

we go. You can see it right here. Now,

keep in mind that our homepage is

serverside rendered. We're getting all

the benefits of SEO boost as well as

quick load times, but we still need some

kind of functionality for this button

because buttons will eventually have

onclick listeners where for example, we

want to perform an action. For now, that

action can be just saying that we

clicked it. But as soon as you give it

an on click listener, that means that

you have to turn it into a client

component. So that's the reason why I

turned this button into its own

component. So now I can add this use

client directive at the top. You can

read a bit more about server and client

components within Nex.js JS

documentation where it explains how they

work and how these are basically two

entirely different contexts and

environments.

Client refers to browser on a user's

device that sends a request to a server

for your application code and the server

refers to the computer in a data center

that stores your application code.

What's important note that each has its

own set of capabilities and constraints

and I dive super deep into this within

the ultimate Nex.js GS course where we

cover application navigation, the state

management and how we can handle it on

the server side through URL state

management and finally diving into

thinking in backend when it comes to

Nex.js applications. Same things goes

for server actions. How do they actually

work and how do they work on the server

specifically? And then of course

different approaches when rendering

components whether on server or on

client. But with that in mind, we now

have this button that is a client

component inside of another server

component. So this is rendered on the

server. But if you need some extra

functionality, you can render it on the

client. That's all I want you to know

for now. So we can give this button a

type equal to button an id equal to

explore btn with a class name of margin

top of seven to divide it a bit from the

content as well as the margin x of auto.

Within this button we can render an

anchor tag to make it a link pointing to

hash events which will show below the

button. It'll say explore events

and right below it we'll actually render

an image. So this is a Nex.js image. So

we can import it from there with a

source of for/icons/

arrow-down.

SVG with an al tag of arrow-down.

And we can close it right here. We'll

also have to give it a width of

something about 24 and a height of 24 so

it actually appears as it knows its

dimensions. There we go. Explore events.

And it looks like my styles were not

getting applied. So I simply repasted

the final globals.css into the public

and resaved all the files. And it looks

like right now we're good. And I just

want to recap this situation one more

time because it might be

counterintuitive and in this crash

course I don't want there to be any

confusion. The goal is to make this the

best Nex.js crash course you watched

with all the questions answered. So if

at any point you're confused, leave the

timestamp of where you're at at the

video in the comment and then write your

question and I'll clarify it. That way

we'll be helping out each other. I mean

that's kind of like what we're doing in

the ultimate NexJS course uh where in

the architecture lesson if we dive into

client versus server paradigm there's a

complete lesson on the topic and then

below that lesson we have the comments

for example Robin was confused between

serverside rendering and server

components and that allows us to provide

a much more detailed response to his

question specifically as well as other

people can ask questions or just

contribute to the overall learning

process. Okay, but why did I even start

talking about this? Well, that's because

it might feel super weird that we have

already split this explore button into

its own component. Usually, you won't

start by building client components

right away. Instead, you'll create them

as you encounter specific client side

needs, such as the need for an onclick

listener right here. In many cases, most

of your features will run on the server

side, but there will be many times where

certain parts just need to be

implemented on the client. And that's

where this architectural mindset becomes

incredibly valuable. It'll help you

decide exactly which parts should be

rendered on the server and which should

be handled by the client instead of just

defaulting to one side. I'm happy to say

that that's also covered within the

ultimate Nex.js course. Here's a lesson

summary and its full transcript. And

people in the comments are also

discussing how this works on different

types of largecale applications such as

within an e-commerce app. So if you

haven't already, definitely explore the

ultimate Nex.js course now bundled with

the complete testing course. So you can

also later on test these server and

client components. I'll leave a special

discount link down in the description.

But now let's develop the rest of the

homepage.

Below the button, I'll develop another

div. That div will have a class name

equal to margin top of 20 and space Y of

7 to give it some breathing room. And

it'll have an H3 that'll say featured

events. Below it, we can map over a

couple of elements um in an unordered

list with a class name of events where

I'll create a new dynamic block of code

where you can create an array that'll

just have numbers from 1 to 5 and we can

map over them. Each one of these numbers

will later on present a full object

containing that event's data and then we

can automatically return a new list

item. When I say automatically return, I

mean not opening up a function block

with curly braces here, but rather just

putting parenthesis, which means that we

don't even have to define return.

Rather, it returns it by default. Since

we're mapping over this, we have to give

it a key equal to event. And I'll say

event

event. So it should say event 1 2 3 4 5.

So let's create a new component in the

components folder. and I'll call it

navbar.tsx.

Within it, we can run rafce to quickly

spin it up. We'll use semantic elements

such as header in this case and within

it a nav. This helps screen readers and

in general improves your web app and its

SEO because browsers better understand

the elements on your app. Then I'll

render a link component right here. This

link is coming from next link. So you

can automatically import it. And I'll

make it point to forward slash which is

just the homepage with a class name of

logo

within which we can then render an image

also coming from next. It's going to be

forward slashicons/lo.png

PNG, which is the path to the actual

logo with an al tag of logo, a width of

about 24 as before and a height of 24 as

well. If you save it, you won't be able

to see anything yet, of course. That's

because we haven't yet put the navbar to

use. We'll do it very soon. Just after

we add this P tag that'll say dev event,

this will appear next to the logo so

people know the name as well. And below

the link, I'll display a UL, an

unordered list that'll contain

additional links. The first link will

point to homepage for now and it'll say

home. We can duplicate it two more

times. The second one will point to the

events page and the third one to the

create event form.

Now, if you save this, we can actually

use this navbar in our layout, not in

our page, because the layout will make

it appear across all of our pages, which

is another great lesson to be taught

here. Whenever you're seeing something

that appears across multiple pages, such

as this navbar appearing here on the

homepage, on the details page, and on

the admin dashboard, then it's good idea

to put it in the layout. But if

something is appearing just on the

authentication page for example, then

you can put it on that page directly.

These are also some principles taught in

the ultimate nextgs course. Before I

showed you the curriculum, but now I can

actually show you the full app that

we're building as part of that course

and it's Dev Oraflow, the more advanced

clone of the full stack orflow

application with complex sorting,

filtering, search and yeah, here you can

see that we have the global search right

here which searches across all different

types of data in our database such as

questions, users, answers and so much

more. So, for example, on our profile

page, we can still have this global

search and it's also shared across all

the other pages such as collections,

community, homepage. It's everywhere.

But, for example, it's not on the login

and signup pages. That's because these

two use a completely different layout.

So, with that in mind, let's put this

navbar to use right here above our div

containing the light rays. I'll simply

refer to it as navbar and import it from

the proper place. It should look

something like this. On smaller screens,

we can see just the logo and the links.

But when you enlarge it, you can see a

more beautiful version of our dev event

application. Now, let's turn these

boring events, which are just pieces of

text, into actual reusable events cards.

We can do that by creating a new

reusable component in our components

folder which you can call event

card.tsx.

Run rafce to quickly spin it up and then

this component will accept all of the

data that it needs to show as props

because each event card will show us

completely different data. Let me show

you what I mean. We can first make it

accept um well let's do a title and an

image.

These will be of a type props.

We're using these props so TypeScript

knows what this component is accepting.

So right at the top we can say interface

of props and make it accept a title of a

type string as well as an image of a

type string as we'll pass over a URL.

Then we can immediately return a link

because each one of these cards will be

clickable pointing to the full events

details page by having an href pointing

to for example for now we can leave it

as just forward/events. We'll change it

later and an ID of event card within it.

We can display an image with a source

equal to image and right below it a p

tag where we're rendering title with the

class name of title. Don't forget to

import the image coming from next image.

And we also have to give it the alt prop

which is going to be rendering the

title, the width of about 410,

the height of about 300, so it looks

like a banner format and a class name of

poster. Now that we have created this

reusable event card, we can head back

over to our page where we're mapping

over these four events. And instead of

just mapping over the numbers right now,

we can actually create a new events

array which will have two objects for

now. It can have a first one that has an

image of for/im images/vent1.png

and it'll have a title of event one.

I'll duplicate it to create the event 2

and event 2.png respectively. Now we can

map over these two events by saying

events.m mapap. And this time we won't

just be rendering the event number

rather we'll be rendering a reusable

event card like this. That still will be

within its own li. So I'll create a list

item with a key equal to event.title

title and within it we'll render the

event card to which we will spread all

of the event properties like this.

Immediately if you do that you'll be

able to see two new featured events

event one and event two showcasing their

images. Now we have to focus on passing

some other important event data as well

to make each event even more

distinctive. For this, we can refer to

our design like what other important

pieces of info does each event have? So,

we can create those events in the

database later on and then use this

reusable event card component to render

completely different pieces of data. Of

course, we have the location, this one

right here. Then there's the image and

the title as well as the date and the

time. And finally, we need some kind of

an ID or a slug allowing us to redirect

to that events details page. So, let's

go ahead and define those pieces of data

right here. Alongside the image and the

title, we'll also have a slug that's

going to be something like event one.

We'll have a location equal to location

one

as well as a date set to date one and

finally a time set to time one. Pretty

unimaginative, right? But I think this

is really the part where it makes sense

to include an AI coding agent that can

help us when we need help. I typically

use Juny for much more complex tasks

because it can really do a lot. But in

this case, we'll use it to generate some

meaningful data for our events. I'll

leave the link down in the description

so you can download it and use it

alongside WebStorm. It is super

convenient. I press commandshiftp and

just search for Juny. It immediately

pops up right here. You get examples of

what you could ask it to do. But in this

case, we can just ask it to create a new

file which is going to be in lib

constants in the root folder. It should

export an array named events containing

real upcoming conferences. I'll leave

this snippet so you can copy it in the

video kit down below and you can just

paste it here. Now, just before I let

Juny generate things, see here that I

said that we need to make sure that the

data looks realistic and can be directly

imported and used in the event card

component. Since I said this, it's very

important to dive into the event card

and make sure to update the props so it

knows exactly which fields we're

expecting to use. This will include the

slug that we created, also the location.

It'll include the date and finally the

time. TypeScript is super useful not

just for us, but also for AI agents to

know the structure of the application

and to just align the expectations. Now

that this is done, we can go ahead and

let Juny do its job. This typically

takes about half a minute, so I'll let

it do its work and I'll be right back.

And even sooner, it created a new

constants file, so we can head over into

it directly within lib constants. There

we go. Curated list of upcoming popular

dev events. It created and exported an

event item so that we can now easily

import it. So we can easily use it

across whenever it needs to be used. And

then there's some other events right

here. So let's go ahead and easily use

them by heading over into our page.

Instead of creating our own array of

events, we can now very easily just

import these events coming from lib

constants. So we're not cluttering our

view right here. And just like that, you

immediately get all of these other

events listed right here. So now we can

head over into this component to display

all of these additional pieces of data

that we now have. Let's first get all of

these props such as the slug, the

location, the date, and the time. We

will use the slug right here in the URL

so we can point to it. In between the

image and the title, I will also display

a div that'll display the location. So

this div will have a class name equal to

flex flex- row gap of two and we'll

render an image that has a source of

forward slash icons/pin.svg

SVG with an al tag of location. A width

very small of about 14. Height can be

set to 14 as well. And then just below

it, I'll display a P tag. That'll render

the location. There we go. Some are

happening in San Francisco. This one

says Vienna, but I believe it was

actually in Croatia.

There's also Los Angeles, Paris, and

Vancouver. Alongside showing the

location, let's also display some

additional date and time information

below the P tag. So, I'll create a div

with a class name of date time.

And within it, I'll display a div

that'll be very similar to this div.

It'll contain an image for the icon and

then a p tag for the actual info.

But instead of it being a pin, it'll be

a calendar with the al tag of date. And

then this will render the date. The date

is here. Now I can duplicate this div

just below. And this time we'll change

it over to clock for the time. And then

we can render the time. Perfect. This

now feels like a real event card. So now

if I expand our screen, take a look at

this. The navbar looks great on desktop.

So does the hero section. We can explore

the events and then there's a list of

all of the most popular dev events

around the globe. Looking good already.

Now this is the point in time where we

actually have something tangible and

visible on our app. So what do you say

that we follow the best practices of

writing code in general and actually

ship this code over to GitHub? It looks

like GitHub is preparing for their own

conference, but I've closed that because

we have our own app that tells us about

dev events. So now let's go ahead and

create a new repo. I'll do it on my

personal profile and I'll call it dev

events

next.js 16 crash course. Let's go ahead

and create the repo. Once you do that,

you'll be given the steps needed to

connect it to your local repo right now.

So let's just follow them by opening up

the terminal and running get init

commit-m

first commit get branch dash m main to

open up a new branch and then get remote

add origin with the URL of your repo and

finally get push u origin main. This

will take all the existing code and push

it over to GitHub. While we're here, we

can also provide some additional info by

copying it from our layout. The hub for

every dev event you must not miss.

That's the description. For the website,

we'll be able to put it later on once we

actually deploy it. But for now, I'll

say jsmastery.com.

For the topics, we can say Nex.js and

Nex.js16.

And we can hide these to make our repo a

bit cleaner, but I'll make sure to add

https

right here to the URL and save it.

Perfect. Now, as we continue developing

this application, and I would highly

advise you to do this for all the

upcoming applications,

always push over to GitHub. It's super

beneficial for so many reasons. Anybody

can head over to your GitHub profile and

check out your contribution graph. The

more you push, the more active you are.

Your projects can also get noticed. And

most importantly, potential employers

are going to look at your commit

history, not your browser history. Don't

be afraid. Just your commit history

where we need to make sure to use proper

commit names. So for every single

feature moving forward, we will not only

write proper commit names, but we'll

also be opening up different branches

and pull requests so we can verify that

the code that we actually write is of

high quality. Code rabbit here will be

of great help as it'll help us cut that

code review time and bugs well in half,

right? So starting from next feature

onward, you, me, and the rabbit will be

reviewing all of our code. So, click the

link down in the description to start

with a free trial of Code Rabbit. It's

also available in many IDEs and one of

their newer features are CLI reviews,

which means that you can get instant

code reviews directly from your terminal

while you're developing the app. We'll

explore all that and more very soon. But

for now, just so we don't forget, let's

immediately create a new branch for the

feature that we're going to start

developing next. And that is

implementing Post Hog. So you can say

get checkout to immediately move to this

new branch and dashb to automatically

create it implement post hog. There we

go. If you've done that properly, you

can just switch over to this new branch.

Implement post hog. And I think that

gives you a pretty good idea of the

feature that we'll develop next. So

let's do it.

Now that our homepage is up and running,

it's time to shift our focus from what

we've built to how do people actually

use it? Because here's the thing, even

the most beautifully designed app isn't

truly valuable until we understand how

users interact with it. Are they

visiting the pages we expect them to

visit, or are they just randomly

clicking around? Where are they dropping

off? Are there errors happening behind

the scenes that we are unaware of?

That's where Postthog comes in. It's an

open- source analytics and product

insights platform that helps us answer

all these questions and more. With

Posthog, you can automatically track

user behavior, see how different

features are performing, monitor errors

in real time, and even capture valuable

metrics that guide future development.

And I'm actually including this step in

the project because this is how

realworld production apps are built.

It's not just about writing code. It's

about creating something that evolves

based on user feedback and data. But you

might be wondering why are we setting

this up now right after building the

homepage and before diving into the rest

of the features. The reason is simple.

Analytics are most valuable when they're

a part of the development process from

the very beginning. By integrating Post

Hog early, we ensure that every new

feature we add will be measurable and

trackable from day one. This approach

reflects how real world SAS products are

built. Heck, the entirety of

jsmastery.com

is fully tracked by Post Hog. Seeing

what you guys do on the platform, where

you click, how useful specific features

are matters so much to me. So that's why

tracking these data pieces with Post Hog

allows us to continue shaping the

platform. based on user behavior, not

just intuition. So, in this lesson,

you'll learn how to set up Post Hog

inside of our dev events application,

and together we'll explore its features.

This will allow you to integrate Posthog

into every single one of your upcoming

Nex.js applications to make them

intelligent datadriven platforms because

the process is more or less the same.

So, let me show you. To get started,

click the Post Hog link down in the

description. And I mean, just check out

this super unique landing page. I'll

have to just ignore how cool it is for

now and just show you how we can get

started. So, click this link right here.

You'll have to choose your region and

then sign up through one of the

providers. It'll ask you to create a new

organization. So, type JS Mastery. Then

you can select your role. And if you

have a second, you can also tell this

hedgehog that you heard about it from

me. So, say Adrien or a JS Mastery is

fine as well. and let's create the org.

Now it'll ask you which products you

would like to use. You can select

whatever you want. I want to use product

analytics, web analytics, data warehouse

will be useful, session replays. Later

on in upcoming videos, we might even

dive into feature flags and experiments.

Surveys are great if you want to just

get a quick MPS score or user

satisfaction score. And then of course

air tracking. That's what we're here

for. So, I'll actually go ahead and

select everything starting with product

analytics. Let's go. I just realized

that we're still looking at a light

color theme. So, at this point, you can

just switch it over to dark mode. That's

much better. Now, the next step is to

install Post Hawk to make it run with

our application. Believe it or not,

Nex.js is at the top of the list of all

of these frameworks, and that's exactly

what we want to use it with. As I told

you, this course will teach you how to

use Post Hog with every single one of

your upcoming Nex.js applications. Now,

you can copy this AI setup wizard

command. This AI wizard should install

and configure Post Hog automatically.

So, here you have to choose your Post

Hog cloud region. It'll try to

authenticate you. It'll install

PosthogJS, Post Hog Node, review the

documentation for Nex.js, create all the

necessary files, and basically set it up

for you.

If you're using an AI powered IDE,

you'll also be asked if you want to

install the MCP server to use Post Hog

in your editor. That will teach your AI

how to use Post Hog. In this case, I'll

skip it, but that's definitely something

we can explore in the next video. And

that's it. Successfully installed Post

Hog. What this installation did is it

created a new file called

instrumentationclient.ts.

and it also added Post Hog's environment

variables to yourv file. Now, as soon as

Post Hog captures the first event within

your application, it'll let you know

that on the setup page. So, if you head

over to localhost 3000 and try clicking

around a bit, you'll see that it auto

captured an event a few seconds ago. And

with that, the installation is complete.

So, let's continue. Here, it's asking us

what we want to use Post Hawk for to

auto capture front end interactions.

enable heat maps, enable web vitals, and

enable session recordings. I'll say yes

to all because these are all great

features that we don't want to miss.

Let's continue. And now I think this is

the best part. There's both a completely

free plan that allows you to have one

project and then there's also the pay as

you go plan, but with a free tier

included, which starts at zero bucks per

month. And I'm not sure if I'm allowed

to say this, but Post Hog's free tier is

the best in the game. I really mean it.

It is highly likely that if you're using

Post Hog on your personal projects,

you'll never cross the free tier. If you

start using it on your apps that grow

and have so many users, then it's still

super cheap, but then we're hoping that

you're making money off of this app,

right? So, for now, I'll go ahead and

proceed with the free plan. You can

invite teammates if you want to. And

we're in. Now, I've zoomed it out a bit

so you can better see what's happening

here on the screen. On the left side,

there's a left sidebar allowing you to

get to different parts of your

dashboard. In the middle, you have this

browser-l like explorer where you can

see all the different insights. And then

on the right, there's the quick start

guide where you can learn everything

about Post Hog. I would actually advise

you to go through it to learn a bit more

about how it works. For now, I'll skip

inviting a team member because we're

working on this solo. And then we are

ready to create our first insight. So

click on that. What this allows you to

do is to analyze user behavior patterns

in your product. You can visualize

events, actions, and properties to

understand how people use your app. So

let's start by quickly creating a new

insight. Even though we don't yet have

too much data captured, we can already

set up a simple page view inside to see

how many people visited our app up to

this point. So right here at the top you

can say home page views. Then select the

page view and the total count and switch

this option over to a cumulative line

chart. Once you've done that, click

save. And that's your first insight. So

now if you head over to the homepage,

you can see some insights created for us

on your dashboard. But you can also head

over to dashboards and create a new

dashboard that'll have access to this

new insight that you created. So

insights go onto dashboards. There we

go. You're now tracking general app

usage. That can be the name of the

dashboard. And you can see that we have

about four page views since we set up

post hog. Now another thing I want to do

right from the start is to enable error

tracking. So on the left side sidebar

under behavior you can click on error

tracking and enable exception auto

capture. Now later on when you visit

error tracking we'll be able to see all

the errors that are happening. And just

like that you now have post hog

successfully integrated within our dev

events project. This is the first step

toward building truly datadriven

applications. An app that doesn't just