How it feels to enter the React Ecosystem in 2024

February 16, 2024

Foreword

Starting a Frontend Project in React this year? Fun times are ahead of you! The following, fictional conversation should help get you into the spirit.

(obviously this is a complete ripoff… ahem, “homage” to: How it feels to learn JavaScript in 2016)

A conversation

Hey, my boss said you’re the guy to talk to about building a state-of-the-art Web app.

- I’m that guy, yes.

Great, thanks! This shouldn’t take long. All I need is to display a list of items from our API on a web page. We’ll also need CRUD: the user should be able to add new items, and edit or delete existing ones.

- That’s easy!

I thought so! I last touched Frontend 8 years ago. It was dynamic then - new frameworks and libraries every week!

Backbone, Ember, Angular. And React was the cool new kid on the block. I can’t imagine how much better things are now! What do you use in 2024?

- React

Still? Well, I remember React was great because it was so unopinionated, it did only one thing well!

- Exactly.

OK, so I’ll just create a new JavaScript project and just include React in there…

- No, you need to use a framework.

I thought React is a framework?

- It’s a library. You need a framework to handle bundling and all that other stuff.

OK, so maybe Create React App?

- Yes, but no one uses that anymore.

Ah yes, now I remember Create React App was really hard to customize - it abstracts away the configuration. The frameworks you have now must be really flexible!

- They still abstract away everything. They’re a bit faster but you won’t know the difference on a small project.

So really it’s the same thing…

OK, I’ll just go with this “Vite” Framework I keep hearing about.

- Vite is not a Framework.

What is it?

- It’s a bundler.

You said bundling is why I need a framework.

- I said “bundling and all that other stuff.”

What other stuff?

- SRR for example.

What’s SSR?

- Server-side rendering. Your HTML is built on the server and delivered on the initial render. It’s important for SEO and performance.

I don’t care about SEO, and performance. It’s a tiny internal app.

- This stuff is important. You’ll end up implementing it anyway. Be smart and use a framework that has it. Don’t reinvent the wheel.

Something about the “server” bit in “server-side rendering” bugs me. I thought we were building a frontend app.

- Absolutely we’re building a frontend app.

But it needs to run on a server?

- Hey, what app doesn’t run on a server, amigo?

The kind that’s a single bundle served from a CDN and runs in the browser?

- (hesitates) This has server-side rendering.

What about if I want to make it Offline-First?

- Not important. Don’t worry about it.

But if I’m “rendering on the server” it sounds like I’ll just be using React as a templating engine? Like EJS in Express?

- Yes, but then you hydrate the app on the client.

Hydrate?

- Yes. It means to “attach” React to existing HTML that was already rendered by React in a server environment.

Sounds complicated.

- Yes, but you won’t have to worry about it with React Server Components.

And those are?

- What does it sound like? It’s React components that only run on the server.

You mean the server-side rendering you told me about just now?

- Yes. But not really. Technically it’s all server-side rendering. But non-Server Components run on the client too. Unless you’re just using the React DOM server API to render HTML. Then it’s a like a templating engine.

But React Server Components are different?

- Yes, you can use them to fetch data.

But any React Component can fetch data.

- Yes, but these only run on the server.

You can run the React Dom server API on the server.

- But that’s not a component. It just converts JSX to HTML. It doesn’t run anything. Server Components can run code and fetch your data.

So they can execute side effects just like a client-side React component?

- They don’t have a “useEffect” hook, if that’s what you mean.

useEffect hook?

- Yes, React switched from class-based components to “functional” components. Your write your component like a function that return JSX and you pass your side effects (like data fetching) as callbacks to this useEffect function inside.

So “useEffect” is like the “componentDidMount” from back in the day?

- Yes, but you can “subscribe” to changes in state and props so it runs when they change.

But the callback itself is changing the state? Sounds like Infinite Loop City…

- I get my Post forwarded to Infinite Loop City.

OK. Let’s park Infinite Loop City for now. Back to the frameworks: if these “Server Components” don’t have “useEffect” where does the logic go?

- Right in the component body:

export async function ServerComponent() {
    const items = await getItems()
 
    return(
        <>
            {items.map((i, index) => {
                <Item key={index} data={i} />
            })}
        </>
    )
}

Just some async logic right in the component body? And how does this run on the client?

- It doesn’t. It runs on the server. It’s a Server Component. “Server” - get it? It’s whole new paradigm, everything that can run on the server, runs on the server

So what runs on the client?

- “Client Components”. You mark them with ‘use client’.

So React, the unopitionated Frontend Library now has a special designation for code that’s supposed to run in the browser?

- Yes. You can mix your Server Components with your Client Components. Just not in a single file.

What do you mean “not in a single file”? Never mind. Anything else I should know about using Server Component.

- If you’re going to be accessing libraries - they need to support Server Components.

Which ones support it?

- Here’s a list I found for you.

That’s like 5 libraries. What about the rest of them?

- ‘use client’

And every one of the frameworks, one of which I absolutely need to use, runs on this Server Component paradigm?

- No, just NextJS.

Oh. So I could just pick a different framework?

- Yes, but the React team collaborates with NextJS. So it comes recommended. Then you deploy it on Vercel.

What’s Vercel?

- It’s the company that maintains NextJS. They are a hosting service provider for web apps.

But NextJS is open-source?

- It is. They just maintain is, is all.

And I can deploy the app I developed with their framework on their hosting service?

- Yes.

But I don’t have to? I could host it somewhere else too? Cloudflare Pages, Netlify? It’s just a NodeJS app at the end of the day, right?

- Netlify open-sources its own React Framework: Gatsby.

Maybe I’ll use that instead?

- No. Everyone’s switching over from Gatsby to NextJS. Be smart. Make the choice everyone is making.

Will Netlify run NextJS or not?

- Netlify will generally run NextJS but there might be missing features.

What about Cloudflare Pages?

- On Cloudflare Pages you have to configure NextJs to run on Edge Runtime.

The Microsoft browser?

- No, not the browser. The Edge Runtime is a NodeJS lite environment. It supports some Node apis. But not all.

Who came up with this Edge Runtime?

- Vercel.

Right. Anyway so I just put

{runtime: 'experimental-edge'}

somewhere in the settings and I can deploy on Cloudflare Pages?

- Yeah, but expect missing features and errors. In fact, you’re better off just deploying to Vercel. Be smart. Keep it simple.

Stop saying “be smart”. Also, “simple” is not a word I would use to describe any of this.

- No? Anyway, Vercel is great.

You sure seem to be pushing Vercel a lot.

- Yeah? I hadn’t noticed.

…and seems like they (Vercel) recently picked up $300 million in Venture Capital funding to “drive adoption”…

- I’m not on the payroll, if that’s what you mean. But the adoption seems pretty driven to me.

OK. I think I’m done here. I’ll go build this in ASP .Net and host it in Azure. At least I know what I’m getting into.

Discuss on 𝕏 · Edit on GitHub