DEV Community: Nextjser

I'm developing a new note app. It's in testing now. Come try it!🚀

Nextjser — Mon, 14 Apr 2025 03:39:15 +0000

Hi everyone, I’m the creator of Cogo, a next-generation note-taking app designed to transform how we create, share, and grow knowledge together. Let me walk you through what makes Cogo more than just another note-taking tool.

Cogo at a Glance

Cogo is a bidirectionally linked Markdown note app that blends personal knowledge management with collaborative learning. While it lets you organize thoughts with familiar features like backlinks and Markdown formatting, its true power lies in its public knowledge ecosystem. Every note you create can be shared as a link, published to Cogo’s communal space, and even spark conversations with others. Think of it as a hybrid between your private notebook and a dynamic, crowd-sourced encyclopedia.

Core Features

Bidirectional Link
Create connections between ideas effortlessly. Click any highlighted term to dive deeper into related concepts, definitions, or community discussions.
Public Knowledge Commons
Share notes to Cogo’s open platform, where others can read, discuss, and remix your ideas into their own work. Public notes become building blocks for collective understanding.
Collaborative Learning
Ask questions, crowdsource answers, refine ideas, and even co-author content with like-minded learners.

Why Share Knowledge on Cogo?

When you publish your notes to Cogo’s public space, you’re not just storing information—you’re contributing to a living, evolving knowledge network. Here’s how it works:

🌱 Build a Collective Brain

Every shared note becomes a node in Cogo’s interconnected knowledge graph. Bidirectional links let users expand on ideas, creating rich, layered explanations. Over time, this grows into a self-improving repository of wisdom.

🎯 Grow Your Influence

Share expertise to attract followers. When others reference your notes, your ideas spread organically—and your audience grows.

❓ Solve Problems Faster

Stuck on a question? Post it publicly. Someone with the right knowledge might already have the answer (or collaborate with you to find it).

⚡️ Amplify Your Impact

If your note helps others, they can embed it directly into their work. No rewriting, no credit battles—just seamless knowledge reuse. You gain visibility; they save time.

🤝 Co-Create & Refine

Turn brainstorming into a team sport. Share drafts, invite feedback, or crowdsource perspectives to refine ideas collectively. Even errors become opportunities: the community can fact-check and improve your notes over time.

Cogo’s Vision

Imagine a world where knowledge isn’t trapped in silos but flows freely, connecting curious minds. Cogo aims to be more than a tool—it’s a movement toward open, collaborative learning. Whether you’re a student, professional, or lifelong learner, your contributions shape this ecosystem.

Ready to Join the Evolution?
Click the login and start building the future of knowledge—one linked note at a time. ✨

Cogo Beginner's Tutorial

This Next.js blog template is awesome.

Nextjser — Fri, 11 Oct 2024 16:28:35 +0000

Introduce

Let me introduce to you a user-friendly personal blog template for Next.js, called Tailwind Nextjs Starter Blog.

This is a Next.js, Tailwind CSS blogging starter template. Comes out of the box configured with the latest technologies to make technical writing a breeze. Probably the most feature-rich Next.js markdown blogging template out there. Easily configurable and customizable. Perfect as a replacement to existing Jekyll and Hugo individual blogs.

Features

Next.js with Typescript
Contentlayer to manage content logic
Easy styling customization with Tailwind 3.0 and primary color attribute
MDX - write JSX in markdown documents!
Near perfect lighthouse score - Lighthouse report
Lightweight, 85kB first load JS
Mobile-friendly view
Light and dark theme
Font optimization with next/font
Integration with pliny that provides:
- Multiple analytics options including Umami, Plausible, Simple Analytics, Posthog and Google Analytics
- Comments via Giscus, Utterances or Disqus
- Newsletter API and component with support for Mailchimp, Buttondown, Convertkit, Klaviyo, Revue, Emailoctopus and Beehiiv
- Command palette search with Kbar or Algolia
Server-side syntax highlighting with line numbers and line highlighting via rehype-prism-plus
Math display supported via KaTeX
Citation and bibliography support via rehype-citation
Github alerts via remark-github-blockquote-alert
Automatic image optimization via next/image
Support for tags - each unique tag will be its own page
Support for multiple authors
3 different blog layouts
2 different blog listing layouts
Support for nested routing of blog posts
Projects page
Preconfigured security headers
SEO friendly with RSS feed, sitemaps and more!

Use the template

Best Switch Games is what I created with this template. Find the best Nintendo Switch games all in one place. Looks good, doesn't it?

June Programming Language Rankings

Nextjser — Tue, 10 Sep 2024 07:30:59 +0000

The latest TIOBE Programming Community index for June 2024 has been released, as shown in the figure:

The TIOBE Programming Community index is calculated based on the number of engineers worldwide, courses, popular websites, and third-party vendors, and it reflects the popularity and trends of programming languages. It does not represent the superiority or inferiority of the languages.

Here are the key changes in this ranking:

June 24 Programming Language Ranking Changes

1. Python remains at the top

A long time ago, Python had already secured its position at the top of the rankings, and this time it has increased by 2.93%. What does that mean? The score it gained this month is higher than the total score of the Go language!

This was predictable, as Python, with its simple and easy-to-learn syntax and wide range of applications such as data science, machine learning, web development, and web crawling, has attracted a large number of developers. The recent boom in AI has also given Python another boost.

For friends who are learning programming languages as a hobby, Python is a good choice. However, considering job prospects in China, there are many fewer positions for Python in web development compared to Java, making it more suitable for those interested in big data, algorithms, and product development.

2. C++ Surpasses C Language for the First Time in History

The most significant change in this ranking is that C++ has surpassed the C language for the first time, jumping to second place.

C++ can be understood as the "advanced version" of C language, offering not only high performance but also support for object-oriented programming and many new features.

I believe it is inevitable that C++'s popularity has surpassed that of C, just as the relationship between Java and C++. In today's environment, languages that are easier to use are more likely to be favored by the majority of developers.

The rise of C++ is mainly due to its high performance and modern features. Although it is more difficult to learn than Java, its key position in high-performance application scenarios such as system programming, game development, image processing, and audio and video processing is unshakable. In addition, C++ is also a mainstream language for embedded development and desktop client development.

As for whether to choose C++ or Java for job prospects in China, it depends on individual perspectives. I wrote an article a long time ago to share my views.

The TIOBE index change chart for C++:

3. Go Language Breaks into the Top 7

In the past year, the ranking of Go language has rapidly climbed from 14th to 7th, which is also worth our attention.

The advantages of Go language are its concise syntax and high performance. Its built-in concurrency mechanism makes concurrent programming simple and efficient, which is why it is widely used in the development of network programming, cloud computing, microservices, and distributed systems.

For most of our developer friends, an obvious advantage of Go language is the incredibly fast project startup speed. Traditional Spring Boot Java projects may take more than ten seconds to start, while Go language might take less than 1 second, making it very suitable for rapid scaling in cloud-native scenarios. We are familiar with projects like Docker, K8S, and Etcd, all of which are developed using Go language.

Java has also long felt the threat from Go language, hence the introduction of cloud-native development frameworks like Quarkus. I have played around with it for a while, and the project startup speed is also very fast, but the ecosystem is not yet mature.

Nowadays, the community and ecosystem of Go language are becoming more and more prosperous, with many libraries, frameworks, and tools already in place. Therefore, more and more companies both domestically and internationally are using Go language, and this ranking is not surprising.

As a result, there is a voice in the domestic community forums: Should we switch from Java to Go language?

My suggestion is not to switch blindly. Students with strong self-learning abilities, if you have not yet touched Java, can start learning from Go; but students with average self-learning abilities, it is better to stick with learning Java, because the resources for learning Java in China are too abundant, with various tutorials, projects, and experience posts, which Go language cannot compare with. Moreover, both Java and Go are currently mainstream in backend development scenarios. For backend development, the language is just a tool and foundation. In addition to the language itself and the corresponding development frameworks, other backend development technologies to be learned are universal, such as databases, caching, queues, search engines, Linux, distributed systems, high concurrency, design patterns, architectural design, and so on. So, it is more helpful to learn the more resource-rich Java first to quickly get in touch with other technologies.

4. Some Emerging Languages

By comparing with last year, we can identify some rapidly developing programming languages, such as Rust, which has reached its highest historical ranking of 17th place. Known for its memory safety and high performance, Rust is increasingly taking a share in the systems programming domain that has traditionally been dominated by C/C++.

In addition, the rankings of languages like Swift, Kotlin, and Fortran have also significantly improved, as shown in the comparison chart between 2024 and 2023:

Other Rankings

Finally, let's share the other rankings from the TIOBE Programming Community index to help everyone understand the development trends.

Programming languages ranked 21st to 50th.

Programming languages ranked 51st to 100th:

ABC, ActionScript, Apex, APL, AutoLISP, bc, CFML, Chapel, CHILL, CLIPS, Clojure, COMAL, Crystal, cT, Elixir, Erlang, Forth, Groovy, Hack, Icon, Inform, Io, J, JScript, Ladder Logic, Lingo, LPC, M4, MEL, Modula-2, Mojo, NATURAL, NetLogo, OpenCL, OpenEdge ABL, PowerScript, Programming Without Coding Technology, Q, RPG, Smalltalk, Smarty, SNOBOL, SPARK, SQR, VHDL, WebDNA, Wolfram, X++, X10, yacc

It's a bit of a pity about Erlang; despite having a well-known product like RabbitMQ, it hasn't quite caught on.

Historical Programming Language Rankings

The evolution of popular programming language rankings from 1989 to 2024:

OK, that's it for the share. What are your thoughts on the June programming language rankings? Feel free to speak your mind in the comments section~

Why is Next.js's routing so odd?

Nextjser — Wed, 04 Sep 2024 03:54:47 +0000

Next.js is a full-stack framework for React, primarily focused on server-side rendering (SSR). It has a very powerful, yet somewhat unusual, routing mechanism. What does this routing mechanism look like? And why is it considered strange? Let's try it out and see. First, let's create a Next.js project:

npx create-next-app@latest

Run create-next-app and enter some basic information, and your Next.js project will be set up.

Next, navigate into the project directory and run npm run dev to start the development server:

If you can see the page in your browser, that means it’s running successfully:

In the project directory, you'll find an app folder under src, which contains a page.tsx file:

Let's add a few directories:

/nextjser/handsome/page.tsx

export default function Handsome() {

return <div>handsome</div>

}

/nextjser/nice/page.tsx

export default function Nice() {

return <div>nice</div>

}

Then visit the following link in browser:

You can see that by adding a few directories, several corresponding routes are automatically created.

This is Next.js's file system-based routing.

Having just learned that page.tsx is used to define pages, what if multiple pages have common parts?

For example, what about menus and navigation like this:

Definitely not one copy per page.

This kind of definition goes inside layout.tsx.

app/layout.tsx is for defining the outermost layout:

That is, the HTML structure, as well as information like title and description:

You can see these in the HTML source code of the web page:

Not only can the root route define a layout, but every level can as well:

export default function Layout({
    children,
}: Readonly<{
    children: React.ReactNode;
}>) {

return (
    <div>
        <div>Left menu</div>    
        {children}
    </div>
);

}

Next.js will automatically wrap the page.tsx components with the layout.tsx components on the outer layer.

Some friends might notice a gradient background, which is defined in global.css. Let's remove it:

Then continue to look at:

We can use the Link component to navigate between different routes:

Dynamic Routes

Some friends might say, "This is all quite normal."

So let's look at something not so normal next:

If I want to define a page for a route like /dong/111/xxx/222 (where 111 and 222 are parameters in the path), how should I write it?

You could like this:

interface Params {
    params: {
        param1: string;
        param2: string;
    }
}
export default function Xxx(
    { params }: Params
) {
    return <div>
        <div>xxx</div>
        <div>params：{JSON.stringify(params)}</div>
    </div>
}

Parameters in the path are named using the [xxx] notation.

Next.js will extract the parameters from the path and pass them into the component:

This is called a dynamic route.

Catch-all Segments

What if you want both /dong2/a/b/c and /dong2/a/d/e to render the same component?

You can code it like this:

interface Params {
    params: {
        dong: string;
    }
}
export default function Dong2(
    { params }: Params
) {
    return <div>
        <div>dong2</div>
        <div>params：{JSON.stringify(params)}</div>
    </div>
}

The syntax [...slug] is used to define routes with arbitrary depth, known as catch-all routes.

You can see that any route under /dong2 will render this component.

Optional Catch-all Segments

What if I directly access /dong2?

You can see that it results in a 404 error.

But this can also be supported; just add another set of brackets to make it [[...slug]], and it will work:

With this change, /dong2 will also render this component, although the parameters will be empty.

This type of route, [[...dong]], is called an optional catch-all.

Route Groups

You can see that the directories in a Next.js project are not just simple directories; they have corresponding routing implications.

But what if I just want to add a plain directory that is not included in the routing?

You can write it like this:

I added a directory called "(dongGroup)" outside of both dong and dong2; will the previous routes change?

I tried it, and it remains unchanged.

This means that as long as you add a () around the directory name, it won't be included in the routing; it's just for grouping purposes, which is called a routing group.

Now, we have rendered a single page under one layout.

Parallel Routes

But what if I want one layout to render multiple pages?

You can write it like this:

Under the parallel directory, there are 3 pages: page.tsx, @aaa/page.tsx, and @bbb/page.tsx.

They will be passed into layout.tsx with the parameters children, aaa, and bbb, respectively.

layouts

export default function Layout({
  children,
  aaa,
  bbb
}: {
  children: React.ReactNode,
  aaa: React.ReactNode,
  bbb: React.ReactNode
}) {
  return (
    <div>
        <div>{children}</div>
        <div>{aaa}</div>
        <div>{bbb}</div>
    </div>
  )
}

page.tsx

export default function Page() {
    return <div>page</div>
}

@aaa/page.tsx

export default function Aaa() {
    return <div>aaa</div>
}

@bbb/page.tsx

export default function Bbb() {
    return <div>bbb</div>
}

The rendering will look like this:

You can see that in the layout, the contents of 3 pages are included, all rendered out. This is called parallel routing.

Some friends might ask, can I access /parallel/@aaa?

No, it is not possible.

Additionally, Next.js has a very powerful routing mechanism:

Intercepting Routes

There was such a route before:

We define a route at the same level as it:

import Link from "next/link";

export default function Go() {
    return <div>
        <div>
            <Link href="/nextjser/liu">to nice</Link>
        </div>
        <div>go</div>
    </div>
}

Clicking the link will take you to http://localhost:3000/nextjser/nice

There's no problem with that.

But what if I add a directory named (..)nice under go:

At this point, try it again:

You can see that this time the rendered nice component has been replaced, but if you refresh, it's still the previous component.

Many people might wonder, what's the use of this?

A scenario example will make it clear.

For instance, with a table, when you click on each item, an edit dialog pops up. This edit page can be shared, and when the shared link is opened, it shows the complete edit page.

That is to say, in different scenarios, you can override the component rendered by this URL, which is the use of route interception.

The usage is also very simple. Since you want to intercept the /nextjser/nice route at the upper level, you need to add (..) in front.

Similarly, (.)xx represents intercepting the route of the current directory, (..)(..)xx intercepts the route of the parent's parent directory, and (...)xxx intercepts the root route.

This kind of route interception is very useful in specific scenarios.

These are the routing mechanisms related to pages, which are quite powerful, aren't they?

APIs

Of course, these routing mechanisms are not only for pages; Next.js can also be used to define APIs such as Get and Post.

Just replace page.tsx with route.ts:

import { NextResponse, type NextRequest } from 'next/server';

const data: Record<string, any> = {
    1: {
        name: 'guang',
        age: 20
    },
    2: {
        name: 'dong',
        age: 25
    }
}

export async function GET(request: NextRequest) {
    const { searchParams } = new URL(request.url);
    const id = searchParams.get('id');

    return NextResponse.json(!id ? null : data[id]);
}

We have defined the GET method for the /guang3 route, which retrieves data based on the id.

Let's visit it:

The routing concepts we learned earlier can all be applied to route.ts.

For example:

[id] defines a dynamic route parameter, and [...yyy] matches arbitrary routes.

In the GET method of route.ts, you also retrieve them through params:

import { NextResponse, type NextRequest } from 'next/server';

interface Params {
    params: {
        id: string;
        yyy: string;
    }
}

export async function GET(request: NextRequest, { params }: Params) {
    return NextResponse.json({
        id: params.id,
        yyy: params.yyy
    });
}

App router & Page router

Do you feel why Next.js is called a full-stack framework rather than just an SSR (Server-Side Rendering) framework?

This is because, in addition to rendering React components, it can also define APIs.

In this way, we have gone through the routing mechanism of Next.js.

This kind of routing mechanism is called the app router, which means the top level is the app directory:

Previously, there was also a page router, where the top-level directory was pages.

These two are just two different file and directory naming conventions; we only need to learn app router, as it is the latest routing mechanism.

Summary

Let's summarize what we've learned:

aaa/bbb/page.tsx can define the route for /aaa/bbb.
aaa/[id]/bbb/[id2]/page.tsx contains [id] as dynamic route parameters, which can be accessed within the component.
aaa/[...xxx]/page.tsx can match any route like /aaa/xxx/xxx/xxx, called a catch-all dynamic route. However, it does not match /aaa.
aaa/[[...xxx]]/page.tsx is similar to the above but matches /aaa as well, called an optional catch-all dynamic route.
aaa/(xxx)/bbb/page.tsx where (xxx) is just for grouping and does not participate in routing, called a routing group.
aaa/@xxx/page.tsx can be included multiple times in layout.tsx, called parallel routing.
aaa/(..)/bbb/page.js can intercept the /bbb route, rewrite the corresponding component, but after refreshing, it still renders the original component, called an intercepting route.

These routing mechanisms may indeed seem quite peculiar, and they can make a Next.js project look like this:

Compared to this file system-based routing, many might be more familiar with the programmatic routing style of React Router:

Next.js's declarative routing is actually quite convenient once you get used to it.

There's no need to maintain separate routing logic; the directory structure itself defines the routes, making it clear at a glance.

Moreover, these seemingly strange syntaxes actually make sense when you think about them:

For example, [xxx] is a common syntax for matching parameters in a URL.
[...xxx] simply adds ... to it, which in JavaScript signifies an arbitrary number of arguments, so it's used to match routes with arbitrary segments.
Adding another set of brackets [[...xxx]] indicates that the route can be optional, which is also a natural design choice.
(.)xx and (..)xxx use . and .., which are symbols in file systems, making them quite natural for intercepting routes.
Routing groups are denoted by parentheses (xxx) to indicate grouping, and parallel routes are indicated by @ in @xxx to show that multiple pages can be included, all of which are intuitive designs.

So, Next.js's implementation of this routing mechanism based on the file system, with these seemingly strange syntaxes, are actually quite reasonable designs.

We've learned about Next.js's routing mechanism, which is defined based on the file system for interfaces or page routes.

Next.js's routing mechanism is quite powerful, supporting many features, These syntaxes may seem a bit odd at first glance, but upon closer consideration, they are quite reasonable designs.

How to understand the concepts of Next.js such as CSR , SSR, SSG, ISR, RSC, SPA, and Streaming SSR?

Nextjser — Fri, 30 Aug 2024 10:20:54 +0000

In this article, we explain the concepts of CSR, SSR, SSG, ISR, RSC, SPA, Streaming, and Navigation in the context of a Next.js project, helping you gain a clear understanding of Next.js.

SPA

Let's kick things off with something we're all familiar with: SPAs. According to MDN, here's the lowdown on SPAs:

An SPA (Single-page application) is a web app implementation that loads only a single web document, and then updates the body content of that single document via JavaScript APIs such as Fetch when different content is to be shown.
This therefore allows users to use websites without loading whole new pages from the server, which can result in performance gains and a more dynamic experience, with some tradeoff disadvantages such as SEO, more effort required to maintain state, implement navigation, and do meaningful performance monitoring.

So here's the question: Are projects created with frameworks like Next.js or SvelteKit considered SPA? Let's take a look at a Next.js project to find out.

This is the official website of Next.js. When you click on a link, the page doesn't refresh, but the main content does get updated, and the route address changes. So, is this kind of project a SPA?

It's hard to say and can be controversial.

If you go by MDN's definition of "loading a single web page and then updating the main content with JavaScript," then it's considered a SPA. But usually, people think of SPAs as having pure client-side rendering and not updating the URL when the content updates (which is why SPAs have SEO issues).

However, Next.js projects both update the URL and use SSR, which makes up for the SEO issues that SPAs have. In fact, neither the Next.js nor the Svelte official websites use the term SPA directly when introducing themselves; instead, they use words like "Navigating" to describe content updates through JavaScript.

So, it both is and isn't. When it is, the term traditional SPA is also used to make a distinction.

Navigation

How is an SPA implemented? That brings us to the concept of Navigation, which is essentially the process of moving from one URL to another.

In the case of the Next.js official website, Navigation primarily refers to client-side navigation. This is where JavaScript intercepts the link clicks, fetches the address of the target route, and then updates the route accordingly.

CSR

CSR, which stands for "Client-side Rendering". As the name suggests, the rendering work is mainly carried out on the client side.

The traditional way we use React is an example of client-side rendering. The browser first downloads a minimal HTML file along with the necessary JavaScript files. Within the JavaScript, operations such as sending requests, fetching data, updating the DOM, and rendering the page are executed.

There are mainly two issues with CSR:

Performance issues, as rendering on the client side is subject to the client's environment, such as internet speed and device performance. The page will not be fully rendered until the JavaScript is downloaded, parsed, executed, and the data requests are returned.
SEO issues, although modern crawlers are generally capable of supporting pages rendered with CSR, the level of support varies.

SSR

SSR, which stands for "Server-side Rendering," is a method where the rendering of web pages is done primarily on the server. Here's a translation of the provided text into conversational English:

SSR, short for "Server-side Rendering," is all about doing the heavy lifting of rendering on the server side. Imagine loading a blog post page; instead of making the client handle the request every time, which might be slow due to their internet connection, the server can take the initiative. It can directly fetch the data from the API, render it into a static HTML file, and then send that back to the user.

Even though it's still making a request, the server typically has a more robust environment in terms of network and hardware, which usually results in faster rendering times, especially for the first screen load.

While the overall speed is often faster, SSR might take longer to respond compared to CSR. This is because SSR has to request the data, render the HTML, and then send it back. In terms of performance metrics, specifically TTFB (Time To First Byte), SSR takes more time. That's why in development, you can't just throw all the APIs into SSR; doing so could actually make things slower.

On the plus side, SSR is great for SEO. It solves many of the SEO issues that can come up with client-side rendering.

SSG

SSG, which stands for "Static Site Generation". Compiles pages into static HTML files during the build phase.

For example, when opening a blog post page, since the content displayed to everyone is the same, there's no need for the server to make a request to an API every time a user requests the page. Instead, the data can be fetched beforehand and compiled into an HTML file in advance. When the user visits the page, the HTML file is served directly, resulting in faster loading speeds. Additionally, pairing this with CDN caching can make it even faster.

ISR

ISR, which stands for "Incremental Static Regeneration". Imagine you're opening a blog post page: the main content might stay the same, but things like likes and bookmarks are always changing. With SSG, once the HTML file is generated, these dynamic data points can't be updated accurately, so you might end up switching to SSR or CSR.

To address this, Next.js introduced ISR. When someone visits the page, they see the old HTML content at first. Meanwhile, Next.js generates a new static HTML file in the background. The next time you or another user visits the page, it’ll show the updated content.

Streaming SSR

Traditional SSR, while solving SEO issues, still has a lot of problems. First, SSR needs to fully render the page on the server before sending it to the client. Second, to keep the server and client component trees consistent, all the component code has to be bundled into the client-side package. Lastly, once hydration starts, the entire process is blocking, meaning the user can’t interact with the page until hydration is fully complete.

To address these issues, Streaming SSR, or what’s commonly known as "streaming rendering," was introduced. Next.js uses HTTP's chunked transfer encoding to implement this. With chunked transfer encoding, data is sent in a series of chunks from the server to the client, allowing the page to be progressively rendered as it’s received.

In simple terms, the server keeps sending content to the browser, and the browser renders it as it comes in. React uses the Suspense component to make this work. Suspense cleverly uses a placeholder while the data is loading, and once the data is ready, it streams the real content into the HTML, replacing the placeholder and allowing for progressive rendering.

This approach solves two main issues:

Components don’t have to be fully rendered on the server before being sent to the client—they can be streamed progressively, which improves the user experience.
Selective hydration: the page can be hydrated in parts, and even prioritize hydration based on user interactions.

However, it doesn’t completely solve all the problems. The client still has to download all the component code and hydrate everything, even if some components only need static rendering and don’t require any client-side interaction, which wastes performance. The current ultimate solution to this is React Server Components (RSC).

RSC

RSC, which stands for "React Server Component," introduces a new way to think about rendering pages. Previously, concepts like SSR (Server-Side Rendering), CSR (Client-Side Rendering), SSG (Static Site Generation), and ISR (Incremental Static Regeneration) applied to entire pages, meaning the whole page had to be rendered using one method. But let’s rethink how we want to render a page.

Take a blog post page, for example. It has purely static parts, like the article content, and interactive parts, like the like and bookmark buttons. If we break it down by components, we can define the static parts as server components. Why server components? Because they render faster on the server, are SEO-friendly, and produce HTML + CSS, which is perfect for static content.

On the other hand, the interactive parts are client components because they require client-side interaction, meaning they need browser DOM events. This requires hydration (the process of adding event handlers) on the client side after rendering.

Since server and client components are handled differently, they need to be distinguished. Client components are marked with a use client directive. Once you break down a page into multiple server and client components, it becomes difficult to label the entire page as SSR or CSR. This is why, after Next.js 13 introduced the App Router, the official documentation de-emphasized these terms. If you still want to think in those terms, you could simplify it by saying that server components are SSR and client components are CSR.

Now that the components are split, how do we render the page? Server components are straightforward—they’re rendered on the server as HTML + CSS. Client components also go through an SSR process initially because they might return some content, but they’re marked as client components (a process some refer to as "marking holes"). The libraries and code dependencies for server components stay on the server, while the client components’ dependencies are bundled and sent to the client, where hydration and rendering take place.

In simple terms, all components initially go through SSR. The client components are marked, and the output is HTML + CSS, while the client components’ dependencies are bundled into JS. Both the HTML and JS are sent to the client, where the JS runs and hydrates the client components, adding the necessary interactive events, thus completing the initial page rendering.

I believe RSC solves two major problems:

Bundle Size Reduction: By splitting components into server and client components, server components are rendered on the server, and the client only needs the final rendering result. This means the server component dependencies don’t need to be bundled into the client JS, reducing the size of the client bundle.
Selective Rendering and Hydration: In traditional SSR, all component code had to be downloaded to the client for hydration. But with RSC, since components are clearly differentiated, only the client components need hydration.

When navigating to a new page, instead of fetching data on the client side like in traditional CSR, RSC handles the rendering on the server. Directly replacing the current HTML with the target route’s HTML would break the page’s state, so RSC uses a custom format called RSC Payload. This payload includes the rendered result of the server components, placeholders for client components, references to files, and the data passed from server components to client components. The client then uses this payload for partial rendering and updates, allowing the state to be maintained.

Summary

RSC doesn't conflict with SSR or Streaming; it's actually a blend of these technologies in Next.js. For instance, all components, whether client or server, are rendered on the server, and the HTML is streamed to the client. During navigation, the RSC Payload is optimized for streaming too. RSC and SSR complement each other, working together to boost app performance.