I started using Next.js in 2018. From 2018 to 2020, I independently created content and taught the React community. And then for the past 5 years, I helped manage and grow the Next.js community at Vercel.

This is a post I’ve wanted to write, but felt I could only write it after stepping away from my official Next.js role.

The overwhelming positive side

React is “boring tech” at this point.

Every year, React continues to grow and gain adoption. The “React way” clicks with many developers, and that has led to it becoming one of the largest ecosystems of developers, packages, and educational content for building on the web.

This comes down to two main things for me: composition and stability. The composition model of React was the right architecture choice in the beginning, and continues to have benefits. For example, AI models are able to generate encapsulated components you can drop into your app without affecting global state. Local reasoning is awesome.

React is also stable. The core APIs rarely change and there’s great backwards compatibility, and most of the innovation comes from other tools or frameworks trying new ideas on top of the core React foundation. You could argue that ecosystem thrash reflects on React itself, but I’m not so sure. It’s popular enough that some people are bound to use it incorrectly.

With that being said, you might have felt that the React of today is not the same as the React of 2015-2020. Why is that?

Communities are hard

Let me start with a personal note. Five years of managing the Next.js community was hard. There are so many great things to reflect on, but also a lot of unneeded stress and frustration. I’m proud of the work I did and the community that we all built together, but at the same time, it does feel good to step away and write this.

It takes dedicated people to persevere in growing a large, open-source project over 10 years like React. This is why some of the most successful OSS projects have BDFLs (Benevolent Dictator For Life). DHH has some great rants on this. He’s building Rails as a gift back to the community, not as a commercial OSS project. He doesn’t mind telling people no when they make their demands. “PRs are welcome” as they say.

The reason I’m starting by talking about community management, is that I can empathize with the React team (this includes current and former members, those at Meta and outside). They built something incredible and poured their heart into it. Showing up and having a voice in the community takes a lot of time and energy. I get why some have tuned out and stopped engaging.

The problem to me is that React isn’t a self-governing community. It requires work.

Listening to feedback

As the size of the React community has grown, so has the amount of feedback. Some of that feedback is good, some bad, but in both cases community members are taking time to share how they feel about a piece of technology. That’s a gift, even if there is a signal/noise filter that needs to be applied to some percentage.

Now, if we take the most pessimistic view, you could argue: Lee, none of that community management stuff matters. Clearly React continues to grow and get more popular, even without the React team being active in community discussions. They built a great tool and that’s all that matters. Why waste time on all of those discussions? They know the right thing to build and all of that feedback is just noise.

There’s some truth to that. Will React continue to grow even if the team never responds to another tweet, GitHub discussion, or Reddit post? Yep, definitely. There’s also the human side of that argument. It is draining to process and filter negative feedback into something constructive that can be used to push an OSS project forward.

But when you separate yourself from the community as a tool author, it means other voices will fill the void. Those voices have their own incentives and don’t have the best knowledge about how React works. This can lead to FUD (fear, uncertainty, doubt) and topics running on for much longer than they need to.

A few recent examples that come to mind are the CRA deprecation drama and the “Vite isn’t as prominent in the docs” drama. Did both the community and React core team have some good points? Yeah. Did it need to escalate that far? No. Were there good intentioned people on both sides? Yes.

If for nothing else, one of the reasons to have DevRel for OSS projects, is so that it is someone’s full time job to do this work. If it’s not their job, then other stuff rightly comes up and gets in the way, like building the actual library. Core developers don’t want to sink a bunch of emotional and mental energy into wording the right response, knowing they will invariably get negative feedback.

Commercial vs non-commercial OSS

React is not a commercial project. Meta/Facebook made React and give it away for free.

You can try to argue the other side that React is beneficial for them: React brings talented developers to Meta, it helps improve their core product experience, they get bug fixes and improvements from outside the Meta team, and more.

And yes, some of that is true. I’d argue there’s not that many React bugs being fixed outside the core team. My larger point is that those benefits are tiny in comparison to the cost of employing people who work on React. Think about how many R&D dollars were spent on the React Compiler, just for them to give it to everyone 100% free.

Meta isn’t making money off React. They are not financially incentivized to grow the project. They built something amazing and gave it back to the community. We should be thankful for that.

Where things start to get tricky is when there are commercial OSS projects built on top of React. Their incentives are different. They do want to grow their project, because it is usually relevant to the growth of the company. For example:

• Gatsby, which was a React framework, had an infrastructure business called Gatsby Cloud. They were incentivized to grow the usage of Gatsby in the hope that some percentage would choose to use Gatsby Cloud. Their business ultimately did not work and they were acquired by Netlify.

• Remix, which was a React framework, had a business model where you would pay for access to the framework. This was probably one of the clearest incentive structures possible. It did work, and they were acquired by Shopify.

• Astro, which is a general web framework, took funding and eventually launched a managed database from the backing company. The DB was spun down. I haven’t caught up on the latest there.

• Redwood, which is a React framework, had an initial business model to help support startups. It was funded by the founder of GitHub. They have since pivoted to be a framework specifically for Cloudflare. There is prior art with Flareact, and then Hono, which is built by a Cloudflare employee.

And then there’s Next.js. The business model of Vercel is to primarily provide managed infrastructure, or a “platform as a service”, which aligns with the incentive to grow Next.js.

Both of these things are true: Vercel doesn’t need to monetize Next.js to have a successful infrastructure business, as they support many different frontend and API frameworks. But also, as Next.js becomes more popular, some percentage of that usage does end up on Vercel.

As if getting eyeballs and usage of your OSS project wasn’t enough, you must also build a sustainable business on top. And if you take funding from venture capital, the goal isn’t a business that just does well, but a business that does exceptional in the category on both adoption and revenue metrics.

Companies have tried the Vercel & Next.js business model, but almost always fail. Vercel has been an exception at $200M in revenue and growing, not the rule to follow going forward. Expo is another successful example.

So why did I give all of that context? Because commercial and non-commercial OSS have different relationships with the community. React doesn’t have a financial obligation to respond to GitHub issues. It’s more like “read-only OSS”. Next.js does. If Next.js doesn’t do right by the community, the project will not succeed.

This is why you continue to see Next.js growing and evolving based on community feedback. I spent a lot of energy helping people self-host Next.js successfully, and Next.js will soon have deployment adapters to make it easy to deploy to any managed cloud provider.

React Server Components (RSC)

The React team had the ambition to extend React’s composition model across the network boundary, bringing the React you love on the frontend to the backend as well.

This was a massive project. One that would require financial backing to build out. As mentioned above, Meta was not incentivized to build this. So what can the React team do to make this vision a reality?

This is how Vercel got more involved in helping contribute to React core going back to 2021. Some members of the React team joined Vercel, and React evolved from a single-company to multi-company project. There are other independent, non-Meta folks on the React team as well, but Vercel was now the biggest outside corporate backer.

So, Vercel invests millions of R&D dollars into building new React features. This includes React Server Components, Actions, any other features eventually included in React 19 years later.

Many of these new React APIs weren’t yet usable by the broader community until they had been validated in the real world. This meant being integrated into frameworks and getting deployed in customer-facing applications. Like I mentioned, this wasn’t happening at Meta.

This is why the pairing with Next.js made a lot of sense. The React APIs were being co-created and validated in the Next.js App Router, such that they could then be released more generally on React stable channels for the broader community. My favorite example of this are React Actions, which work without a server or framework!

Now, we can litigate exactly how these improvements were communicated and released to the world. There’s plenty of missteps here, including those made by yours truly. The App Router was likely marked stable too soon, with the intention of declaring the API surface area as stable (not that it was generally bug-free). Obviously that was a mistake, as people felt it was pushing a sub-par RSC experience too soon.

Further, the incentive structure here meant that it was unlikely and/or difficult for other frameworks to invest the same amount of time and energy into integrating these APIs as the Next.js team did. I do think the React team could have done a better job of bringing the community along for this ride in the open, and at the same time, I understand their hesitation.

Ideas are fragile. I’m sure the React team felt like everyone would have strong opinions about RSC and the API design, and that led them to be more reserved in what they shared. Plus, they probably felt burned from sharing Suspense and Concurrent Features work early in the past. Sure, there were some React Labs posts every now and then, but RSC was developed quite differently than say Svelte adding async support. I see both sides.

I wish I had been more vocal in the community about how RSC was being built. I did talk about this at conferences, which had calm, intentional, and thoughtful discussions with members of the React community.

Posting online, I’d get feedback like “you’re a shill stop pushing RSC to sell more Vercel”. This made me more reserved sharing openly, even though I did believe we were building something amazing for the entire React community.

RSC in 2025

Now in 2025, we have RSC stable and related features like Actions and Transitions shipped. But putting technology out into the world doesn’t mean the community is immediately going to run with it and build an ecosystem on top.

Again, this is likely a place I could have done better with Next.js. Most of the “RSC innovation” happening in the ecosystem was from those building on Next.js. It was still very difficult to build non-Next.js RSC things, largely because RSC is a bundler feature.

Some savvy developers were able to build their own bundler hacks, or build off the webpack plugin, but there weren’t docs and any guidance for how to navigate that journey¹. Moment of vulnerability here, this was also not my strong suit. I’m not a bundler developer and in fact, part of the reason I liked Next.js was because I never wanted to think about bundlers again. Shoutout to Dan for his great writing on RSC.

The result of this was that it took many years before there was a community-led effort to get RSC in other places besides Next.js, in a production-like way. There were plenty of experiments and side projects, like Waku and others, but Parcel was the first bundler to give us an abstraction that you could ship to prod with.

Since then, many of the Vite plugin authors building their own RSC implementations collaborated on building an official Vite plugin for RSC. And thanks to hi-ogawa and others, we now have @vitejs/plugin-rsc. We also have RSC for React Router. Nature is healing?

Community burnout

One of the most frustrating parts of my previous job working on Next.js was trying to explain the above context to the React community. It was a far easier story for people to say “Vercel is taking over React so they can sell more compute in the cloud”. Nuance didn’t scale there. Maybe a skill issue on my part.

And I can understand the hesitation, especially when you re-read the list above of other React frameworks trying to do something similar. As I mentioned, the Next.js and Vercel business model is not one that normally works.

So eventually, I stopped trying to fight this fight, and then ultimately stopped engaging. You might say: but Lee, there are millions of Next.js developers who are happy building things and never contributing to the discourse. And sure, that is true! I did appreciate those people.

My bigger issue was that other prominent people in the React community never took the time to fully grok what I was saying above. It often felt like I was talking to a brick wall trying to convince others what we were doing at Vercel and Next.js was good for the community and worth their time.

In the fullness of time, I expect this to change. I have confidence RSC will be incredibly impactful and be largely regarded as the third generation of React (if you consider hooks the second). I expect a lot of people who dogged on RSC will eventually come around. But hey, now I get to watch how the story plays out from the sideline.

My call to action for anyone in the React community today, and hoping to grow with it over time, is the following: remember there are humans working on the software, and they want to be treated with kindness and respect just like you. Remember that OSS is a gift and you are not entitled to make demands without putting any energy forward yourself. And above all else, be the optimistic change you want to see in the world.

1. After 5 years at Vercel, I finished up earlier this month.

2. I joined Cursor to teach developers about AI and the future of coding.

3. I wrote about making personal software.

4. I wrote about things I believe on my updated website.

5. I blinked and my daughter is 10 months old 🤯

Like many of you, I’m finding that AI is changing how I build software. It started out as a fancy autocomplete, but has since become a core part of my coding workflow.

And that’s… strange, if I’m being honest. The way I wrote software 10 years ago feels archaic. You mean I can just ask an agent to code the feature and it will work!? Wild times.

But this new world has a lot of problems, too. Especially for beginners. I start debugging a problem with them, and they tell me how they use AI to write code, only to realize they don’t actually know how AI models work.

And I don’t mean the machine learning part (although that doesn’t hurt). They don’t understand determinism vs. non-determinism. When they don’t get good answers one day, they think the tools are broken. Wrong. They are missing the correct mental model.

It’s made me realize there is a massive gap in AI education. More people are becoming developers because of AI, but they’re not learning the right skills to actually succeed. They vibe code their app in a few days, but then next week they’re in a death spiral of errors with no path to escape.

I don’t have the answers, but I do want to start contributing some solutions. So expect to see more content explaining the fundamentals of AI models, how to actually use them to get work done, and hopefully I can start to help push things forward.

I’d say it was mostly correct, so I wrote down some thoughts on what was accurate and what has changed.

1. Svelte is pushing React

Compilers are great, actually. Why not let the computer optimize your code instead of humans? Svelte has always innovated with a compiler-first approach.

Svelte 5 continues to evolve with Runes, an explicit way of defining reactive state. On the React side, the React Compiler is finally available for use (now in beta) after many years of development.

Compiler-friendly directives like 'use client' and 'use server' have become core to the React Server Components programming model. And React frameworks like Next.js are also adding their own directives, like 'use cache'.

2. Remix is pushing Next.js

When my original tweet was posted, the Next.js App Router wasn't even released. I remember two of our top requests for the Pages Router were better support for layouts and global data fetching (e.g. _app.js).

Remix iterated on the getServerSideProps model of Next.js, allowing more granular data fetching, and adding built-in conventions for layouts. Ultimately, there's been a convergent evolution towards the Server Components and Server Actions model, with Remix helping shape some of the React 19 features as well.

The outcome has been, in my opinion, a better ecosystem for all React developers.

3. Prisma is pushing ORMs

Prisma has raised the bar for how the JS/TS ecosystem works with databases. Having great TypeScript support is now table stakes. For example, Drizzle has taken this a step further by being able to define your schema and relations in TypeScript (versus the Prisma schema file).

Prisma should also get credit for helping push the entire "data layer" forward to be more lightweight and runtime-agnostic. More libraries and vendors now use Web standard APIs, which means better interoperability between platforms.

With that context, it makes sense that you now see a Prisma-managed Postgres database that connects over HTTP.

4. Deno is pushing Node.js

This was an understatement. Node.js has improved so much in the past three years.

I'd amend this original statement to add Bun as well. Multiple runtimes has meant more visibility and work towards performance, developer experience, and solving long-standing papercuts.

For example, can you believe we have native support for CJS/ESM interop in Node.js 22? Amazing. Notably, Deno 2 is now stable and has backward compatibility with Node.js.

5. Supabase is pushing Firebase

I haven't kept up as much with Firebase, because Supabase has largely replaced it (for me). That’s not to say Firebase is bad; I still see it frequently used, especially when building web and mobile apps together.

More so that Supabase has won the heart and minds of developers — and they've been able to ride the wave of Postgres love. I'd amend this to say Supabase has pushed the entire BaaS (backend-as-a-service) category forward.

6. esbuild / SWC are pushing JS tooling

After my original tweet, I wrote an article about how Rust was becoming the future of JavaScript tooling infra. That prediction turned out to be true.

Now in 2024, we have Biome, Rspack, Rolldown, Oxc, Lightning CSS, Turbopack, and more. This includes Vite/Rolldown/Oxc raising funding to continue investing in Rust tooling.

Notably, Turbopack Dev is now stable in Next.js 15. The team wrote up a very detailed post talking about the journey.

7. Bun is pushing SWC

Bun has pushed package managers, compilers, test runners, and other runtimes forward. It's shown there's many places to speed up the JavaScript ecosystem, if we try hard enough.

It's already been a year since Bun 1.0, and adoption seems to continue to rise. The iteration velocity of the team is incredibly high.

Now in 2024, what tools are pushing other tools? What will we look back on and compare in three years?

• I became a dad (6 weeks in, with a happy daughter and wife — so thankful)

• I shipped a SaaS template, music player, books inventory, and other new apps

• I got a new domain (leerob.com) and refreshed my site

• I made a bunch of demos, tutorials, and quick tip videos

• I learned Vim and changed editors to Neovim

My SaaS template

Four years ago, I made a React and Next.js course showing how to build a SaaS application.

I wanted to show how an individual developer could go from zero to a real product that accepts money on the internet. There’s of course many other ways to achieve this same outcome — whether it be PHP (Laravel), Ruby (Rails), and others. But the React component model meshed with my brain, and has been my preference for writing UIs since 2015.

Next.js enabled me to write my entire application in one programming language (TypeScript) and write code for both the client and server. Now four years later, it’s even easier to build this same application with React Server Components, Server Actions, and other new features.

So, I built a new template. It uses the latest Next.js and React patterns. These patterns simplify common tasks like building forms, talking to your database, and more.

The app uses Postgres (with Drizzle ORM), Stripe for payments, and Tailwind CSS (with shadcn/ui). There’s a bunch of goodies to dig into. Cookie-based authentication, RBAC with different roles, global middleware to protect logged-in routes, local middleware to protect Server Actions and validate schemas, and more.

Try out the demo or view the repo (now at 5,000 GitHub stars 🤯). I hope you find it helpful or interesting. I wrote more about how it’s built here.

My new portfolio

I’ve wanted leerob.com for a long time, but it was taken with a redirect. Hilariously, from a guy named Rob Lee. As fate would have it, the domain expired and I was able to purchase it — which seems to be good timing as .io domains might have some issues in the future.

As tradition goes, I spend time rebuilding my site instead of writing an update. I wanted to focus on simplicity and remove a lot of cruft that had accrued over the years. Simple design, clean typography, and refreshed content.

I’m using the View Transitions API with the Next.js App Router for smooth animations between pages. It’s minimal and I love it.

Check it out or view the code. I also wrote two new posts:

• On Community Moderation

• My Stack

My minimal music player

I have a love/hate relationship with Spotify. It has great playlists. Also, hours of listening data to intelligently recommend new songs to me. But wow, the interface leaves a lot to be desired.

So I started trying to build a better, information dense version of a music player inside of v0. I didn’t plan make it real at the start, but was impressed by how far I got thanks to AI. So, v0 helped me finish the job and get a working MVP.

The repo might be interesting to look at. It again uses Postgres (and Drizzle ORM) to save songs and playlists. Album art and playlist images are stored in Vercel Blob storage. It’s a Progressive Web Application (PWA), so I can install it like an app on macOS or iOS.

Try out the demo or view the repo. I also wrote about some other interesting details building it, if you’re curious to learn more.

My books inventory app

I wanted to build a demo of searching, filtering, and pagination with Next.js — and needed a very large dataset for the demo. So, I took a Goodreads database of 600,000+ books and dumped it into Postgres.

This was a fun challenge. Even writing the seed script to get a CSV of that many books into the database was interesting. After some tweaking of database indexes, I’m pretty happy with the outcome.

The app uses URL state exclusively. For example, when you search, the query param updates and causes a React Server Component to re-run, look at the searchParams, and query the database. Same idea for pagination and adjusting filters in the left sidebar.

If you type into the search, or adjust the filters, your input is preserved when navigating to a book page. This gives it an app-like feel. Similarly, with scroll position — if you navigate to the 20th page, scroll down, and then click into a book, going back will take you back to your exact spot.

Try out the demo or view the repo. One interesting bit to explore is the generation of the blur-up placeholder images for the books using “thumbhashes”.

Learning Vim

I am surprised I have never learned Vim until now.

I’ve fumbled around in vi before, but never actually gave it a proper go. Since I had some free time, I decided to quit VS Code cold turkey and jump straight into Neovim.

It’s been awesome. Vim motions are magic.

Moving to Neovim shows how slow VS Code is. Further, a lot of the “magic” of VS Code is just integrations with Language Server Protocols (LSPs). With a proper Neovim configuration (which didn’t take long thanks to the Kickstart repo), I was able to match the floor of what VS Code provides, but with a higher ceiling for complete customization.

To help myself learn Vim, I started writing down notes and a cheat sheet. After tweeting about Vim and my progress, I got a lot of replies asking about resources to learn and my configuration. So I made a quick, free course if you’re interested in trying it out.

And more!

Lots of other smaller ships, like improving the Next.js docs, or quick tip videos showing how a feature works.

• Next.js Docs: Progressive Web Apps

• Next.js Docs: Data Fetching

• Next.js Docs: Examples

• Next.js Docs: Incremental Static Regeneration

• Next.js Tip: How next/image works

• Next.js Tip: Active state for nav links

• Next.js Tip: Route Groups

• React Tip: server-only package

• React Tip: Colocated components

• React Demo: React 19 Features

• Vercel Demo: v0

• Vercel Demo: Firewall

• Vercel Demo: Skew Protection

• Vercel Demo: Toolbar

• Vercel Demo: AI SDK Chatbot

• Next.js Demo: Self-Hosting

• Next.js Demo: Optimistic UI

Until next time ✌️

Trust. The tools they adopt and advocate for impact their reputation. You might have heard “no one ever got fired for buying IBM” in reference to making good choices.

But picking older, well-adopted tools can be at odds with how fast the industry moves. Is there a newer alternative that solves my needs better? Ask your developer.

Keeping up the latest trends is part of their job. They need to know what's a fad and what's here to stay. This is why experienced developers become skeptical of almost everything. It's hard to earn their trust.

Developer marketing is about building trust. Here's what's worked for me.

How can I improve my developer marketing?

1. Don’t publish content you wouldn’t share yourself.

2. Always consider how you can build developer trust. It’s not a one-time transaction. It’s reflected in every product and marketing decision you make.

3. When something sucks with your product, own it. Don’t try to hide the failure. Lean into it. Bring the community along for the continuous iteration of your product. “You told us this was bad, and we fixed it”. Follow up with people after you ship.

4. Get involved in the community. Host, attend, or sponsor a hackathon or meetup. Spend time talking to developers 1:1. Their feedback drives product improvements and content ideas. Where are people struggling? Write about that.

5. Create a developer experience so good that it does marketing for you. Write docs worth sharing, filled with helpful diagrams and detailed descriptions. Create code examples and templates that help developers get started quickly.

Throw out the old playbook

Developers love great marketing, but most companies get it wrong.

They’re trying to apply the enterprise marketing playbook to the wrong audience.

• Enterprise Marketing

  • Goal: Grow pipeline and revenue

  • Audience: Directors, VPs, or C-suite

  • Buyer Interests: Increased efficiency, cost savings, innovation

  • How: Sales-served, sign a yearly contract for a discount

• Developer Marketing

  • Goal: Grow retained signups and community awareness

  • Audience: Individual developers

  • Buyer Interests: Transferable skills, affordable, great developer experience

  • How: Self-serve, start free then swipe a credit card

What does great developer marketing look like?

I’m a developer who works at the intersection of engineering, product, and marketing. Based on my experience, the best developer marketing:

1. Teaches how to build great products

2. Builds and retains trust

3. Uses precise language

How did they build that!?

When I see a great developer tool, my first thought is: how did they build that?

There’s a natural curiosity. I want to reverse engineer the product and learn new tools or skills I can apply to my work.

The best developer marketing shows how to build great product experiences. Bonus points if you capture the “current thing” – a new AI tool, or a popular style of app (TikTok clone).

Great developer marketing is invoking this response as a service.

Zero days since the latest JavaScript framework

Developers don’t try your product the first time they hear about it. They certainly don’t want to talk to someone to get access first.

They need to hear positive feedback several times before they trust it enough to try. That's why building, growing, and retaining developer trust is everything.

Trust comes from your marketing being helpful regardless of the product. And retention comes from making something developers actually want.

Individual developers are tired of enterprise marketing being used on them. They’re the wrong audience—they don’t want the cold calls or unhelpful emails. And if you lose their trust, they’re quick to move on to other products.

Trust is built (or lost) through the content you create and put out into the community. It’s a reflection of what you stand for.

Here are some of my red flags when reading developer content:

• Buzzwords and acronyms: Sometimes these are necessary, but there’s a lot of copywriting that looks like “cutting-edge, LLM-powered RAG platform” when it should really be “bring knowledge to your AI model”. Acronyms also alienate newcomers.

• Misusing technical terms: "Our JavaScript framework helps you make responsive websites” – does it though, or is that CSS? This can degrade trust because it shows the author might not have a deep understanding of the subject. Another example is broken or incorrectly formatted code examples. Did they even check that it works?

• Overpromising simplicity: The developer ecosystem is too obsessed with simplicity. I’m guilty. While “get started in one click” might be good sometimes, it can also be harmful. Maybe I want more options? "Simply install our SDK" might not be as simple as it sounds.

• Vague explanations: Developers want a practical example of what your product does. “Utilizing the latest technology to supercharge your development process”. Is this an editor, framework, database, or something else?

Developers are more likely to trust open-source tools. These tools likely have a community of other developers learning together. They can take their knowledge of the tool from job to job as they grow in their career.

Show, don’t tell

Great developer marketing is both concise and precise.

It values your time—every word matters. Show them how to build interesting things, don’t fill a post with 1000 words of garbage.

Consider an email announcing a new version of your product. The pricing has changed, and there's a data migration.

• How can I make it concise?

  • Put the bottom line up front: If I stop reading after the first paragraph, did I get what I needed to know? Is there action required? Put that in the email subject line.

  • Make it easy to scan: The visual flow of the content is as important as the words you choose. They should be able to quickly scan for landmarks (like code examples or commands they need to run).

• How can I make it precise?

  • Address their fears directly: This email mentions a migration. Am I going to lose my data? Do I need to make changes right away? Am I going to be charged more?

  • Personalize the content: Show them their team name, the date the migration starts and finishes in UTC, exactly how much their price was before and after, and how they can take action (maybe a CLI command that shows their usage).

What do you want them to remember?

Your product is competing between thousands of others for developer mindshare. You believe yours is better. How do you share that message?

Let the product speak for itself. Listen to customer feedback and iterate. If your marketing isn’t working, their feedback should tell you why.

This tweet is provocative, but it makes a point: you can't fix a bad product with more marketing and sales. When you believe in the product, you don’t need to speak down against others. I prefer to do the opposite.

I believe in optimism for software, the web, and the community I’m building. I want people to remember I was helpful, positive, and enthusiastic about the product.

Wait, what about DevRel?

Developer Relations is more than only developer marketing. It's the intersection between product, engineering, marketing, and sales.

For early companies, you might only need DevRel. They are generalists. But as you grow, you need to specialize. Get the right leaders for both developers and enterprise marketing.

Developer marketing leaders come from non-marketing roles (engineering, developer relations). They love showing developers how to build amazing things.

Enterprise marketing leaders come from traditional marketing roles (content, product marketing, growth). They can sell to developers, even if not one, and know how to build a pipeline generating engine.

It’s possible for one person to do both sides of marketing well, but rare.

• Cross-browser support for nesting, :has(), container queries, and more1

• Powerful and fast new CSS tools

• Many frameworks and compilers to help optimize CSS loading performance

This post will be a collection of my notes and thoughts about the CSS ecosystem and the tools I'm currently using.

Design Constraints

User Experience

What does a great experience look like loading stylesheets when visiting a website?

1. Stylesheets should load as fast as possible (small file sizes)

2. Stylesheets should not re-download unless changed (proper caching headers)

3. The page content should have minimal or no layout shift

4. Fonts should load as fast as possible and minimize layout shift

Developer Experience

Our tools must help us create better user experiences. The developer experience, while important, can't come before the user experience.

How can the DX of the styling tools we use help us create a better UX?

1. Prune unused styles, minify, and compress CSS for smaller file sizes

2. Generate hashed file names to enable safe, immutable caching2

3. Bundle CSS files together to make fewer network requests

4. Prevent naming collisions to avoid visual regressions

What about to help us write more maintainable, enjoyable CSS?

1. Easy to delete styles when deleting corresponding UI code

2. Easy to adhere to a design system or set of themes

3. Editor feedback with TypeScript support, autocompletion, and linting

4. Receive tooling feedback in-editor to prevent errors (type checking, linting)

CSS in 2024

It's never been easier to write great styles without any additional tooling.

This example I created uses many of the latest CSS features supported cross browser without any build step. You might not need Sass or Less anymore!

Does that mean the tooling is no longer necessary? For some people, yes.

Build Steps

To meet the design constraints above, you'll likely need a build step.

It's unlikely all your users are on the latest browser versions. But more importantly, there will always be newer syntax that isn't yet supported cross-browser you will want to use.

You can manually write @supports rules to check for browser support, but that's only solving some of the problems. Rather than leaving the CSS optimization to humans, why not let the machines handle it?

Compilation

Compilers make the following workflow easy:

1. Automatically remove any unused styles, bundle files together to make fewer network requests, add vendor prefixes, and minify the output by removing white spaces and comments

2. Automatically generate unique file names, allowing frameworks to set caching headers like immutable signaling to browsers the content will never change

3. Specify target browsers (browserslist) and have syntax lowering to compile modern CSS features to work with those browsers

Streaming CSS

You visit Google to book a flight. It can't precompute your intent, so you're given a search bar for the initial UI. You search "Flight SFO to NYC" and the server streams in a flights widget to select dates.

There is no way Google could have included every possible widget ahead of time. Currency conversions, timers, live sports scores, you name it. The UI and styles for these widgets need to be dynamically streamed in.

React (and Next.js) now support this pattern with streaming SSR and CSS. In the React model, you define your UI as components which have dependencies on styles. How can we safely stream in styles for the a widget without affecting anything on the page?

Styles need to be scoped, or atomic, so that if they load earlier than the DOM content they're intended to style, they don't alter the style of elements already on the page.

For example, CSS Modules have styling rules scoped to the component that imports it. Tailwind uses atomic utility classes, which are compiled into a single stylesheet that's loaded before any classes are used. StyleX generates atomic classes as well. Global styles don't work well with streaming unless loaded at the beginning of the stream.

My Recommendations

CSS Modules

CSS Modules are a small but impactful enhancement on top of vanilla CSS.

They achieve our desired UX constraints and most (but not all) of our DX constraints. They're available in almost every modern bundler and framework. You can copy / paste existing CSS selectors and they'll work in a CSS Module without any changes.

They can't generate atomic styles. They don't support using many themes (just CSS variables). And because the styling code lives outside your TypeScript files, you don't get type safety and autocompletion. But those constraints might be fine for you.

Lightning CSS, which supports CSS Modules, is used by Vite, and soon by Tailwind and Next.js. Tools like postcss and autoprefixer are being replaced by faster, all-in-one Rust toolchains.

Tailwind CSS

Tailwind uses a compiler to generate only the classes used. So while the utility CSS framework contains many possible class names, only the classes used (e.g. "font-bold text-2xl") will be included in the single, compiled CSS file.

Assuming you only write Tailwind code, your bundle will never be larger than the total set of used Tailwind classes. It's extremely unlikely you would use them all. This means you have a fixed upper bound on the size of the generated CSS file, which is then minified, compressed, and cached for the best performance.

You don't have to only write Tailwind styles. Tailwind classes are just utilities for normal CSS that adhere to a design system. You can mix and match Tailwind with CSS Modules, for example.

Tailwind doesn't come without tradeoffs. There's a bucket of tools that pair with it:

• VSCode integration for autocompletion, linting, syntax highlighting, and more

• Prettier integration for automatic sorting of class names

The most controversial part about Tailwind is the syntax. It's both loved and hated. I didn't appreciate Tailwind until I built something with it, so I'd recommend trying that if your initial reaction is adverse.

Here’s another version of the first example, but written in Tailwind.

StyleX

There are two issues with most CSS-in-JS libraries:

1. Performance: Components must convert the styles written in JS into CSS to be inserted into the document when rendering. This can have a significant cost and is why libraries are moving to “zero runtime” libraries like StyleX.

2. Compatibility: Many existing CSS-in-JS libraries have added support for React's streaming server-rendering, but are still incompatible with other performance optimizations like moving parts of your application to React Server Components.

To solve these issues, “zero runtime” CSS-in-JS libraries like Vanilla Extract and others have been created.

StyleX is the latest CSS-in-JS library, which solves these problems and more. I'd recommend reading through “Thinking in StyleX” if you want to dig in.

Here’s another version of the first example, but written in StyleX. This was my first time using it. While it's still new to open-source (and the ecosystem reflects that), it's not a new library. It powers all the Meta sites: Facebook, Instagram, WhatsApp, and Threads.

You still have to name things though 🫠 Enter buttonWrapperContainer.

Conclusion

Is CSS... fun for me now? I guess so. I'm excited to see what the next few years bring.

Would you have picked something different? Did I miss anything? Respond and let me know what you think.

• Frontend developers are no longer just writing HTML, CSS, and JavaScript. It's now common to see a frontend-focused developer build an entire web application from scratch. They integrate and connect to databases, handle authentication, and more.

• Backend developers are often forced to choose between two paths: writing more frontend code to support their backend, or moving closer towards managing, maintaining, and building software infrastructure used by the former developers.

• AI-enhanced developers have shifted the focus from simply writing code to creating great products. Startups are increasingly feeling this shift, running a more lean engineering team that uses LLMs and coding copilots to move faster.

Consider two different verticals: Product and Platform Engineers.

What are Product Engineers?

Product Engineers work backwards from the desired product experience to the set of technologies that enable it. They consider the frontend, backend, design, and everything in between to create a great user experience.

They don't need to understand every part deeply, a common misconception of "fullstack". Instead, they have a broad understanding of the available tools and deep experience applying those tools to build products.

Some qualities of a great Product Engineer:

• Iterative: They value iteration velocity and incremental correctness. They'd rather ship, get feedback from customers, and adjust along the way—rather than building in a silo.

• Customer focused: They aren't afraid to engage with customers and learn how to improve the product. At a larger company, the Product Manager might specialize here, but should work closely with the engineer to apply those learnings to the correct solutions.

• Pragmatic: They understand that technology choices are all means to an end. Choosing the latest JavaScript library doesn't matter if no one uses your product. They are willing to remove tools if they aren't helping fulfill their product goals.

Okay, so what does that leave the other half of the software engineers?

Product vs. Platform Engineering

While Product Engineers focus on building and enhancing features that solve end user problems, Platform Engineers focus on the infrastructure that supports the product.

Platform Engineering teams are building or buying tools to support Product Engineers and make them more efficient, productive, and happier. They're typically making the infrastructure choices for the Product teams.

Typically, platforms teams were only something accessible for larger organizations. Increasingly, a small but effective group of Platform Engineers can make incredibly impactful decisions, even for smaller teams. They are thoughtful about evaluating and purchasing software to grow with the scale of their product team.

Finding Talent

Most startups are looking for Fullstack Engineers but actually need Product Engineers.

The best Product Engineers share two common qualities:

1. A passion for building high-quality experiences

2. A constant drive to learn and explore new ideas

They're not pixel-pushers; they're creators who take pride in their work and are not afraid to stand behind their products. They should have plenty of examples of their work, because so much of it is user facing.

They understand web fundamentals, such as browsers, accessibility, animations, CSS, HTML, and JavaScript. The tools they use—be it React, Svelte, or something else—are secondary. What truly matters is their ability to use these tools to build the best product possible.

The title shift from Fullstack → Product Engineer has some prior art.

Design has seen a similar shift. Titles like UI/UX Designer and Graphic Designer are increasingly being replaced by Product Designer.

Great Product Engineers don't stop at visually complete. They carefully consider the user journeys. What happens if there's slow (or no) internet connection? What if this API returns an error? How does this experience work on touch devices? What latency numbers should we strive for?

What seems like an excessive amount of polish to others is normal for these developers.

Conclusion

When I tweeted "Product Enginner > Fullstack Engineer", I was surprised by the response.

At Vercel, we updated our job descriptions to change references from Fullstack to Product Engineers. I've noticed others doing the same.

Product Engineers represent a shift in web development. Especially with the rise of AI, there's a growing need for developers who do more than "just write code" — developers who understand the bigger picture, who can work across various technologies, and who focus on delivering exceptional products to the end user.

Further Reading

• The Product-Minded Software Engineer

• PM at Atlassian on Product Engineers

• Stop just using “Frontend” or “Backend” to describe the Engineering you like

It's simple and direct—relentlessly focus on your customer.

However, when those customers are developers, I'd argue the execution of this advice looks different and might be counter-intuitive from what people generally want.

Here's what you should do to make something developers want:

1. You should embrace open-source

2. You should have a free tier

3. You should have excellent documentation

4. You should be able to get support from developers

5. You should be part of a community

1. You should embrace open-source

Experienced developers love open-source products because they've seen the opposite. They've struggled to debug a “black box” closed-source tool, or worse, had a previously open tool change licenses or close its source code.

New developers love open-source products because they're learning skills that help them advance in their career—their knowledge transfers from company to company.

Open-source developer tools often have better documentation and educational material, too.

2. You should have a free tier

Developers don't want to talk to your sales team. They want to try out the product with as little friction as possible. Start free, then grow, once they've validated the product works and will solve their needs.

There are exceptions to this rule. You might have procured software that required months of negotiations, license keys to get access, and hand guided provisioning of resources from a human. But ask your developer—they would have preferred if they could have started self-serve.

“Try it before you buy it” isn't novel sales advice, but developers are outliers in this demographic.

3. You should have excellent documentation

The better the documentation, the more likely the developer is to try your product.

This isn't about specific UI features like dark mode or ⌘+K search dialogs. How quickly can they find an answer to their problem? Great documentation is either a reference guide or an educational tool.

Educational material should be equally compelling for both beginners and experts. Experts love to hear concepts explained in a simple way. Beginners want new concepts progressively explained. Don't drop ten new concepts and five acronyms right away. Write like you're teaching beginners.

Here's more thoughts on what makes a great developer experience.

4. You should be able to get support from developers

When developers can't find the answer in your documentation, they'll reach out to support.

They want to talk to someone who empathizes and understands their problems. It's easy to tell whether the support person actually “gets it”. Minimize the number of hops between problem and solution, ideally cutting out layers of humans in the middle.

This is why roles like Developer Advocates or Customer Success Engineers exist. Developers expect to talk to developers.

5. You should be part of a community

Where do developers go to hang out? Online and in-person communities.

This doesn't mean you need to start a community for your product. In fact, you probably shouldn't. Instead, look at where the developers are already spending time. Go there. Talk to them and contribute to the discourse.

Communities are not a transactional relationship. You are there to provide value. This is a long game, sometimes taking years to materialize value back, but then obvious in hindsight.

This post will be an overview of databases that pair well with modern application and compute providers.

Criteria

I'll focus on transactional1 workloads instead of analytical2 workloads.

The “backend” space is vast: search, analytics, data science, and more – so I'll niche down here. The primary criteria of this overview is:

1. Services that work exceptionally well when paired with serverless and edge compute

2. Services that work with JavaScript and TypeScript codebases

Disclaimer: I work at Vercel, which partners with companies in this post. I also have personally used many of these tools for my own personal projects. My site currently uses PlanetScale and I'm also an angel investor in Supabase (mentioned below).

A new programming model

Relational databases have been around for 25+ years.

While there are new companies creating serverless-first storage solutions, a new programming model is required for workloads to be compatible with serverless compute and modern runtimes.

These solutions must be:

• Connectionless: Developers don't want to think about manual connection management. Traditional database protocols are stateful, whereas HTTP is mostly stateless, making it easier to use with scale to zero compute. Exposed through an SDK or HTTP API, “connectionless” solutions provide an abstraction over connection pooling.

• Web native: Browser data-fetching APIs (e.g. Web fetch) and protocols are eating the world. New databases use HTTP APIs or WebSockets, rather than opening direct connections to the database. This makes them compatible with all forms of compute (including the lighter runtime used in edge compute).

• Lightweight: Client libraries (and drivers) are becoming thin. Complexity is shifting to the database vendor, taking on the burden as part of their global infrastructure. For example, their gateway might handle connection pooling or provide caching infrastructure. This has led to a new wave of ORMs (i.e. abstractions to query data) both as standalone libraries and as integrated database SDKs.

• (Bonus) Type-safe: TypeScript developers are favoring databases or libraries which provide tooling to enable type-safe access to your data. For example: Prisma, Kysely, Drizzle, Contentlayer, and Zapatos.

Consider databases like Postgres. New solutions like Neon and Supabase abstract connection management, providing you with a simple way to query and mutate data. In the case of Supabase, there's a client library that uses an HTTP API built on PostgREST:

import { createClient } from '@supabase/supabase-js'

let supabase = createClient('https://project.supabase.co', 'key')
let { data } = await supabase.from('countries').select()

And for Neon:

import { Client } from '@neondatabase/serverless'

let client = new Client(process.env.DATABASE_URL)
let { rows: [{ now }] } = await client.query('select now();')

Neon's solution is particularly interesting.

The basic premise is simple: our driver redirects the PostgreSQL wire protocol via a special proxy. Our driver connects from the edge function to the proxy over a WebSocket, telling the proxy which database host and port it wants to reach. The proxy opens a TCP connection to that host and port and relays traffic in both directions.

Using WebSockets, instead of HTTP, does have tradeoffs. There might be additional latency on the first request setup, but subsequent requests are faster. There's an RFC for WebSockets with HTTP/3 which would remove that extra network roundtrip.

The connection management isn't going away – it's just being handled by the vendor now.

There's even solutions like PlanetScale which can handle up to a million connections, which also allows you to effectively never think about managing connections.

Trends

This new programming model has created emerging trends for database companies:

• Databases are increasingly becoming data platforms, including other adjacent solutions like full-text search and analytics.

• The decoupling of storage and compute, popularized by Snowflake (and more), is enabling new players (e.g. Neon et al.) to massively reduce the cost of a “database at rest”. This pairs well with frontend git branch-based workflows, where you want to scale to zero when not being used.

• Increasingly developers don't want to “dial the knobs”. Solutions like DynamoDB (and in some ways S3) provided infinite scale without needing to tweak memory, storage, CPU, clusters, and instances.

• The dream of global data is here, but not how it was predicted. Trying to replicate all data to every network edge is probably not the correct solution most times. Instead, we're seeing specialized data APIs and the emergence of user-specific data stores (e.g. for shopping cart data).

• More databases are embracing serverless, but what “serverless” means to them varies. There are different vectors of autoscaling: connections, storage, compute, and more.

Databases

I'll bucket these into “established” and “rising” categories, serverless/serverful, as well as generally available (GA) and pre-GA. I'll also mostly talk about managed vendors.

For example, you can of course run MySQL or Postgres on major cloud providers like AWS. There's a long tail of niche data storage solutions, so some will definitely be missing that I haven't heard of or used.

Established serverless solutions

• Firebase

  • Firestore: Over 10 years old now, Firestore is a well-adopted document database. One unique advantage Firebase is its built-in support for authentication, real-time workloads, and cross-platform support for mobile.

• MongoDB

  • Atlas Serverless: MongoDB has an entire data platform, including search / analytics / etc. Their recent investment into serverless is very exciting, with Atlas Serverless now generally available. Their Data API makes them a fantastic pair for serverless / edge.

• MySQL

  • PlanetScale: MySQL through Vitess. Can easily handle quite a large scale and also includes some nice features to speed up and monitor queries. Their serverless driver (@planetscale/database) has been easy to use, but I prefer Kysely.

• PostgreSQL

  • AWS Aurora: One of the first serverless Postgres offerings.

  • CockroachDB: Autoscales and distributes data across multiple nodes. Focused on high data consistency and integrity. Supports most of Postgres but not stored procedures and extensions.

• Redis

  • Upstash: Offers durable/consistent Redis, global replication options, and Kafka. Fantastic @upstash/redis HTTP/REST client library.

Rising serverless database solutions

• Generally Available (GA)

  • Fauna: They were an early mover in the serverless data space. I've had success with their GraphQL APIs before, but feel mostly indifferent on FQL.

• Pre-GA

  • Convex: Fantastic for real-time workloads, but also a very simple, type-safe interface for querying/mutating data. You write (and think) in functions. Pairs well with React's mental model.

  • Grafbase: If you love GraphQL, Grafbase is worth exploring. Designed to integrate into branch-based workflows + fast reads globally. Realtime and full-text search are in the works.

  • Neon: Postgres with separation of storage and compute. Uniquely designed for serverless and works with the native Postgres driver + supports database branching workflows.

  • Supabase: Open-source, built-on pure Postgres. Database + Auth + Storage and more. Scales up on pay-as-you-go, and working on scale to zero.

  • Xata: Not only a database, but search / analytics as well. I'm a fan of their spreadsheet-like UI, which is approachable for a wider audience.

• + Long tail of new providers that can do DB hosting (Railway, Render, Fly, etc).

Stateful backends and other solutions

• Generally Available (GA)

  • AlloyDB: Very exciting innovation coming from Google. AlloyDB is unique because it can handle both transactional and analytical workloads.

  • Ably: Realtime infrastructure with queues support and other message durability options.

  • Crunchy Postgres: Crunchy Postgres is "just Postgres". Focused on performance and availability, cost-effectiveness, and supporting all native Postgres features.

  • Hasura: Makes it easy to connect data from many different sources and expose it as a GraphQL API. Can use Neon under-the-hood as the database provider.

  • Liveblocks: Realtime building blocks, they have a “storageblock” in Beta, and offer persistence for presence. Beautiful design and documentation.

  • Replicache: More of a database synchronization engine that can be coupled with other solutions with no real-time solution. We use this for comments on Vercel previews.

  • TimeScale: For both transactional and analytical workloads. Adds many features found in NoSQL databases to Postgres, and also integrates with S3 for storage.

• Pre-GA

  • ChiselStrike: Write your TypeScript class, generate an API. Really leaning into the “infrastructure from code” approach, you write and think in functions, somewhat similar to Convex.

  • EdgeDB: EdgeDB is challenging the status quo. Particularly the “merger” between ORM / database, more than just a query builder, but a way to optimize queries.

  • Nhost: Firebase, but with GraphQL. Built on Hasura, Postgres, and S3.

  • Rowy: Low-code, spreadsheet-like backend (almost like an open-source Airtable) but they also have the ability to write functions to mutate data.

  • SurrealDB: Has its own SQL-flavored syntax, also trying to provide the spreadsheet-like UI for viewing data (still waitlist access, haven't used it).

  • Tigris: Document database, focused on real-time and also includes full-text search.

  • WunderGraph: Trying to lead with an excellent ORM / client library (end-to-end type safety, GraphQL support) and wedge into a cloud product (still waitlist access, haven't used it).

• Other Solutions

  • Caching Engines: Stellate, Prisma Accelerate, ReadySet.

  • Cloud Provider Offerings: AWS Dynamo, Azure SQL, Azure CosmosDB, Google Cloud SQL, Google BigTable, and more.

  • Content Management (Headless CMS): These can still act as a database, just a different domain-specific solution. Sanity, Contentful, Sitecore, and more.

Okay, that wraps up this overview. I’d love to hear your feedback – who did I miss? Of the services above, which have you tried, and what did you like about them? This is an early preview before I share this post on social media, suggestions are welcome!

Thanks to Guillermo Rauch, Paul Copplestone, Fredrik Björk, Anthony Shew, Craig Kerstiens, Jamie Turner, Nikita Shamgunov, Yoko Li, Pratyush Choudhury, Stas Kelvich, Enes Akar, and Steven Tey for reviewing this post.

You should consider using a framework (instead of building your own) because:

1. Less time connecting tools, more time building products

2. Easier onboarding and training of new developers

3. Flexibility for different rendering strategies (server, client, or static)

4. Opinionated choices prevent bikeshedding

5. Deploy anywhere and incrementally adopt

6. It’s still just React

But before we explore why you should use a framework, it’s helpful to step back and look at the evolution of React.

React is evolving

React changed how developers build for the web, popularizing breaking down UI into reusable components and emphasizing incremental adoption.

While it’s certainly still a library that can be sprinkled into any webpage, the React architecture is a blueprint for frameworks to follow to create interactive, resilient, and performant frontend patterns.

Consider React Server Components. This architecture is designed for frameworks to implement. Some aspects have been standardized between React frameworks (e.g. "use client") and others are being incubated (e.g. async/await in Server Components) during beta periods. Frameworks can still choose their own conventions (e.g. special filenames).

Implementing the React architecture, and ultimately great UI patterns, requires deep integration between all parts of your frontend: data fetching and loading states, code splitting and bundling, routing and rendering, and more.

This is where frameworks come in.

P.S. I talked about this evolution during the Reactathon keynote.

Less time connecting tools, more time building products

React has been around for almost 10 years – and the web has grown with it.

Every aspect of frontend development has seen innovation: linting, formatting, compiling, bundling, minifying, deploying, and more. Developers want to spend less time configuring their tooling and more time writing React code, while still taking advantage of these latest advancements.

Teams who build with React frameworks can focus on components and business logic, and lean on battle-tested open-source solutions for routing, rendering, data fetching, styling, authentication, testing, and more.

Further, teams can update to the latest versions of these frameworks and instantly receive both performance benefits and new tools to help them improve the end-user experience. In some cases, you add a command line flag and take advantage of multi-year and multi-million dollar investments into Rust-based JavaScript tooling. It’s harder to justify investments into developer experience and tooling when building an internal framework (for most teams).

Easier onboarding and training of new developers

Frameworks help you spend more time writing React code.

Compiling, bundling, minifying, code splitting, server-rendering, routing – by using a framework, your team spends less time building and maintaining solutions that are solved problems.

For example, moving from React + Express + Webpack to a framework resulted in removing 20,000+ lines of code and 30+ dependencies – while improving HMR (Hot Module Reloading) from 1.3s to 131ms.

Companies who choose to build with open-source React frameworks benefit from:

• Immediate knowledge ramp-up: New engineers can ship code on day one, bringing existing knowledge of popular frameworks from their last role or hobby projects.

• Up-to-date documentation: When developers are stuck, they’re able to reference documentation that’s updated daily or easily search Stack Overflow for their stack trace2.

• Best-in-class security: Bugs and security vulnerabilities are reported and patched by communities of thousands of developers instead of overworked platform teams.

Meta (the creators of React) have their own closed-source web framework. Many innovations in React have come from years of dogfooding new features (like Server Components) on Facebook.com through this framework.

Using an open-source React framework, built on top of the latest React UI primitives, is the closest way to emulate the tools developers at Facebook use to build one of the largest web applications in the world.

Flexibility for different rendering strategies

React, by itself, is primarily used on the client (in the browser).

In a standard React application, the browser receives an empty HTML shell from the server along with JavaScript instructions to construct the UI. This is called client-side rendering because the initial rendering work happens on the user's device.

While this is a valid pattern for certain types of applications (especially those behind a login), React’s widespread usage for any type of web page made developers also want to prerender content from the server. The HTML is generated in advance rather than computed on the user's device.

Sending HTML from the server (or how most sites work) can provide some benefits:

1. It’s typically faster to do expensive work on a powerful server than on a user’s device.

2. It’s a better user experience to see more content on the initial paint versus a loading spinner.

3. It’s a better user experience when running A/B tests or experiments, preventing layout shifts.

React does give you APIs to render content to HTML, which might work for your use case. However, the developer is still left with connecting many pieces together for the rest of the application experience. This is where frameworks provide a cohesive experience on top of React when you need to prerender content.

It might sound like all React apps should be server-rendered. The reality is, of course, more nuanced. For certain routes, it’s likely better to generate a static asset and distribute it around the world using an Edge Network (placing the assets closer to your users).

For other pages, the client-only model might be better. You can download the JavaScript for the page once, cache the assets on the device (which have a unique hash in the file name for the given version), and then quickly navigate between pages (giving you the single-page application feel). This might be a better solution for applications that require offline support.

There’s no silver bullet or single rendering strategy that works. Static, server, or client rendered – all are valid options depending on the requirements. Frameworks can empower you to make this decision on a per-route basis, rather than needing to make the entire application a static site or server-rendered.

Opinionated choices prevent bikeshedding

Picking React is one decision of many frontend architecture choices.

You will likely also need to consider:

• How should we handle routing? (i.e. using the file system or through some configuration)

• How should we only load the JavaScript needed for the current page? (i.e. code splitting)

• How should we prevent regressions in our codebase? (e.g. using conformance and linting)

• How should we load data for a given page? (i.e. server or client)

• How should we deploy our React application? (e.g. using Docker, Node.js, or static files)

• How should we style our code? (e.g. CSS modules, Tailwind CSS, etc.)

• How should we handle authentication?

Frameworks make many of these decisions for you, as well as provide you with tools and components to solve common problems on the web. For example, you will probably need to use images, fonts, or third-party scripts when building a website. Frameworks can give you tools to help optimize your usage of these primitives, building on top of React, JavaScript, and the web platform.

Building with an open-source framework that’s well adopted gives you access to many contributors creating, maintaining, and documenting common issues – codifying them into conformance rules and ESLint configurations. There are sometimes even suggestions built into common web performance measurement tools like Lighthouse.

It’s important for frameworks to be opinionated, but still have ways to eject or give access to the underlying primitives to allow developers to not feel a loss of control. For example, maybe this is a robust plugin system, or maybe this is running arbitrary routing logic before each request.

Deploy anywhere and incrementally adopt

It’s not uncommon to have internal platform teams supporting the delivery of bespoke React applications at larger companies. Since their tooling is not built on established, open platforms, developers often end up wasting time working on solved infrastructure problems.

One of the benefits of using a framework is that they all have support for either self-hosting on your own infrastructure (either through Docker, Node.js, or other means like uploading static assets) or by using managed platforms, which automate every process of the iteration and delivery of the software.

Additionally, many React frameworks have extensive documentation on how to incrementally adopt their tool, including providing low-level features like URL proxies, allowing you to rewrite some incoming requests to your new framework to your existing application.

It’s still just React

While frameworks provide abstractions and opinionated choices, at the end of the day, you spend the majority of your time writing React code. And that React code is portable between other React-based frameworks. This optionality is great for developers.

Further, React frameworks are increasingly aligned with the web platform. As patterns for building React applications have emerged and solidified, we’re now seeing stronger recommendations from both the official React documentation, as well as frameworks and libraries in the community.

While the innovation in the React and single-page application space has been abundant, we’re now seeing frameworks use the best of the client, and the best of the server, all while taking full advantage of the web platform.

Conclusion

React has evolved. It’s now a:

• Library: Sprinkle interactivity into any webpage

• Architecture: UI patterns and primitives for frameworks to build with

• Community: Well used and documented, incrementally adoptable

• Ecosystem: Learn once, write everywhere (web, native, 3D, and more)

If you’re building with React, you should probably use a framework to spend more time writing product code, and less time connecting toolchains. The specific framework you use doesn’t matter as much as the benefits from not reinventing the wheel building your own.

I’m optimistic about JavaScript.

Developers want to write JavaScript – and they want it to run everywhere – in the browser, on the server, or at the edge.

With all its quirks and imperfections, JavaScript continues to rise in adoption due to its built-in growth hack (it’s in the browser), its massive ecosystem of tools and libraries, and the continued growth and adoption of TypeScript. And increasingly, developers are able to learn an API (like Request or Response) and reuse that same knowledge everywhere.

Having an agreed-up common set of APIs (i.e. standards) and platforms that all support that same interface (e.g. cross-browser support) means web developers can now learn once, write everywhere.

This post will outline recent improvements to the web platform across the browser, server, and edge.

JavaScript: In the Browser

Web developers today spend less time writing vendor-specific JavaScript or vendor-specific CSS selectors than ever before.

function isIE11() {
  return !!window.MSInputMethodContext && !!document.documentMode;
}

We’ve escaped the world of padding hacks for maintaining an element’s aspect ratio:

@supports not (aspect-ratio: 16/9) {
  .aspectRatio {
    overflow: hidden;
    padding-bottom: 56.25%;
    height: 0;
  }
}

Two converging trends are making this possible:

• The death of Internet Explorer: Now that IE 11 is officially retired, web developers can write less vendor-specific CSS, leading to smaller stylesheets and fewer hacks.

• Browser engine alignment: The three major browser engines (Chromium/Chrome, Gecko/Firefox, and Webkit/Safari) now have the best cross-browser support for JavaScript, CSS, and Web APIs we’ve ever seen. Kudos to the Interop project.

Now, of course, it’s not perfect across browser engines, nor will it likely ever be. But it’s the best it’s been and I’m optimistic. Thousands (or millions) of developer hours will be saved cumulatively by not spending a week digging into esoteric IE bugs.

Here’s an example of how this alignment can benefit all web developers. Imagine you are a framework author trying to write a reusable image component to help thousands of developers achieve great performance when using images. In 2020, just a few years ago, you need to work around the web platform.

Loading an image without causing a layout shift, correctly maintaining the aspect ratio, and not degrading initial page load performance due to image size/weight was difficult to implement with support across all major browsers. This led to developers either ignoring the issues, or the frameworks writing component abstractions that produced code like:

<span> <-- needed to maintain aspect ratio
  <span> <-- needed to maintain aspect ratio, CSS padding hacks
    <img src="" style="" /> <-- inline styles to prevent layout shift
    <noscript>...</noscript> <-- JS needed for IntersectionObserver
  </span>
</span>

It’s a different story in 2022. There’s cross-browser support for: aspect-ratio, width/height attributes to prevent layout shift, native image lazy-loading, and pure CSS/SVG-based blur-up image placeholders. The above code can drop the wrapping elements and work without runtime JavaScript needed.

<img
  alt="A kitten"
  decoding="async"
  height="200"
  loading="lazy"
  src="https://placekitten.com/200/200"
  style="aspect-ratio: auto 1 / 1"
  width="200"
/>

JavaScript: On the Server

Isomorphic JavaScript, or code that could run on both the client and the server, has been the ideal state for many web developers. Learn once, write everywhere, right? Until recently, Node.js and the web platform were out of alignment.

Consider fetching data over HTTP. In the browser, we had the Web Fetch API. Prior to Node.js 18, there was no built-in solution for fetching data. Making a fetch required using packages like node-fetch or undici, which had a similar but slightly different API, often in non-obvious ways.

This lack of alignment between platforms meant that tools for writing isomorphic JavaScript, like Next.js, needed to add polyfills so developers could use fetch on both the client and the server. With Node.js 18, these tools can now remove additional JavaScript needed to polyfill platform differences, ultimately resulting in less JavaScript needed.

I’m optimistic about JavaScript (and TypeScript) on the server. It’s not just fetch, either. It’s Request, Response, and 100+ other APIs that are now available in both the browser and in Node.js. Browser vendors and companies building server infrastructure are now working closer than ever to provide a standard set of APIs that can run everywhere, including edge computing platforms.

JavaScript: At the Edge

Edge computing, the often misunderstood and newest target for running JavaScript, has had the least standardization of the three (browser, server, edge).

It’s helpful to think about edge as the highest level of abstraction, where you’re spending all of your time on business logic.

Edge isn’t something completely new, but rather a deliberate and intentional tradeoff from the existing Node.js world.

You want to write JavaScript, but edge compute infrastructure requires a lighter subset of the (quite large) Node.js API surface area. By making this tradeoff for a subset of Node.js APIs that also run in the browser, you can have consistently fast cold boots and more cost-effective compute workloads. That sounds pretty nice.

Let’s look at an example. In this case, I’ll use a Vercel Edge Function. But it could also be other edge computing platforms like Cloudflare or Deno. For me, the best part of this code is actually that it’s fairly boring. It looks like Node.js.

export const config = {
  runtime: 'edge'
}

// Web standard Request API
export default function handler(req: Request) {
  // Web standard URL API
  const { searchParams } = new URL(req.url)
  const name = searchParams.get('name')

  // Web standard Fetch API
  const req = await fetch('https://...', { body: { name } })
  const data = await req.json()

  // Web standard Response (.json is new)
  // https://github.com/whatwg/fetch/issues/1389
  return Response.json(data);
}

Here’s the kicker: it’s not just about the infrastructure. It’s about the frameworks that are embracing these same Web APIs and helping thousands of new developers learn once and write everywhere.

This code could work with Next.js. Or SvelteKit. Remix. Fresh. Or the next, new web framework that builds upon the same set of standard APIs.

What an incredible time to be a web developer.