DEV Community: Yao Ding

My Experience with Migrating Create-React-App to Vite/Rsbuild

Yao Ding — Thu, 20 Feb 2025 16:41:51 +0000

Recently, the React team has officially deprecated Create React App (CRA) and recommends moving to either a framework or a build tool. This created some discourse online about whether the React team had been hesitant to recommend a build tool, and I feel like this is the right time to actually test the migration from Create React App. I’m choosing one open-source project I contribute to, which is a rather simple Single Page Application (SPA) and a perfect candidate. In this case, I’m testing Vite and Rsbuild since I’m not really a Parcel user. It’s my grease pass. I'll check all possible angles, including documentation, community support, and overall developer experience.

Vite

To be honest, I’m kind of surprised that the Vite documentation does not have an official guide for CRA migration. That's not really an issue, though, since there are so many good guides from the community. I used the migration guide recommended by the React team, and it roughly follows these steps:

Update dependencies (add Vite, remove react-scripts)
Create vite.config.js with basic settings
Update import path resolution to keep using src as basePath
Move index.html out of the public folder
Install the svgr plugin and update import names
Update environment variable names to follow the Vite pattern
Replace process.env usage with import.meta

The complete details are in this PR. With the above guide and the magic of ChatGPT, I was able to finish the migration in under an hour. The app works fine locally, and I can definitely feel the app startup time being shortened. There are some minor issues, like some asset import paths still not resolving correctly, but I feel pretty good about it in general.

Rsbuild

To be fair, I should say that migrating to Vite already made me familiar with the general process, so I sort of got a head start with Rsbuild. I do want to give the Rsbuild team credit for putting up an official and thorough migration guide, and I didn't really need to look anywhere else. The changes are rather simple:

Update dependencies (add Rsbuild, remove react-scripts)
Create rsbuild.config.ts and add all necessary settings, including SVG, ESLint, environment variables, and build output
Update index.html for import paths

And that's it! I didn't need to make changes in the source code or really any other places besides the config file, so the change set in this PR is ridiculously small. I finished the migration in probably under 10 minutes, and the app runs smoothly locally with no issues at all.

Conclusion

Technically speaking, I didn't finish the migration completely since I have not verified the build version and didn't really touch on tests. Still, this was a good experience and definitely shows the power of modern tooling. I think both Vite and Rsbuild offer an excellent experience, and honestly, Rsbuild wins here for me with thorough official documentation and fewer invasive changes in the code.

Originally published in my personal blog

React Server Component is perfect for Backends-for-Frontends

Yao Ding — Wed, 26 Jun 2024 19:30:20 +0000

By now, you should be familiar with React Server Components (RSC) or at least have heard about them. RSC is the latest addition to React's feature set, offering significant benefits such as reduced client-side JavaScript bundles, improved user experience by eliminating extra network roundtrips, and the ability to run server code directly in React components. As someone who has always worked in a traditional team setup with separate backend and frontend teams, I've been contemplating the feasibility of both teams adopting this paradigm. It's clear that there are some major hurdles to overcome.

How conventional backend/frontend works

Let's first revisit the non-RSC server/client development flow. Suppose you have a list of product features to implement. Typically, the following would occur:

A design review where backend and frontend teams agree upon an API specification that defines server behavior. While implementation is discussed, the focus is usually on the interface.
The Backend team will implement the server behavior with this API spec, and release under a version, like /api/v1/my-product.
The frontend team consumes this API and builds the UI behavior.
Work for backend and frontend teams might happen sequentially, but it could also occur in parallel. Once the API is defined, frontend teams can mock test data based on the API interface.
When new product requirements arise, the API can be enhanced or deprecated in favor of a new version with breaking changes. The frontend team can simply switch to different API versions to opt into different behaviors.

While this flow may seem to have significant overhead, it offers some notable benefits:

Frontend and backend can test their parts completely in isolation and achieve end-to-end testing within their respective boundaries.
API endpoints remain stable as long as the version doesn't change, ensuring consistent server behavior.
Maintaining different versions of UIs is relatively inexpensive, as we can simply replace calls to different endpoints.

Implementing RSC in Conventional Backend/Frontend Setup

Now, let's examine how RSC would work. For a fair comparison, we can assume both backend and frontend teams have domain knowledge of JavaScript and React. We can split work into a server component that handles data fetching and business logic processing, then passes data as props to a client component. Several considerations come to mind:

Fuzzy server responsibilities: Without a clear return from server components, everything becomes an implementation detail. Previously, API endpoints provided a defined contract to follow. With server components, we don't have explicit expectations from the server, requiring code analysis to determine what the server component should fetch and pass down to the client. This lack of clarity might reduce confidence in refactoring server code.
Increased testing complexity: How would you test that a server component is working as expected? With API endpoints, we can perform integration tests to ensure that given certain requests, responses match expectations. For server components, ensuring proper data fetching and return becomes more challenging, likely requiring extensive mocking and tapping into implementation details to test in isolation.
Maintaining stable server behavior: With API endpoints, we have versioning. Do we need to maintain different versions of server components? This could add another layer of ambiguity to server implementation.

For enterprise applications, debugging processes involving backend interactions with datastores can be particularly challenging. When server components handle all aspects, this complexity could increase significantly.

On a positive note, server actions may be easier to adopt as they are pure functions with clear inputs and outputs. We can treat them similarly to API endpoints, with stable and clear interfaces, isolated testing, and version control.

However, in large organizations where backend and frontend teams often work with different stacks or in separate repositories, implementing these approaches can be challenging.

Backends-for-Frontends: A Perfect Fit for RSC

React Server Components (including server actions) could be an ideal fit for the backends-for-frontends(BFF) pattern. In this pattern, we would have dedicated API endpoints for specific UI behavior, and the endpoints will typically be maintained by the UI team. We still have general-purpose backend that connects to datastore and do heavy-lifting business logic, and react server component will just handles the BFF part.

As Sam Newman states:

"The BFF is tightly focused on a single UI, and just that UI."

Since BFF is tightly coupled to a single UI, we needn't worry about strong contracts for server behavior, as the UI is the sole output. We should no longer test backend and frontend in isolation, as they are both part of the implementation details. Instead, we should focus on end-to-end testing.

The benefits of server components shine in this context:

We can skip the overhead of releasing API endpoints.
We achieve better code colocation for all frontend code.
We eliminate multiple network roundtrips to fetch data.
Client bundle size is significantly reduced.

It's a perfect match for the BFF pattern.

Conclusion

Ryan Florence, creator of Remix (a React server framework), aptly described Remix as a center stack. I believe RSC serves a similar purpose, sitting between users and the general backend, bridging the network in the process. With that in mind, the future looks promising for React Server Components.

Originally published at https://yaodingyd.github.io/blog/react-server-component-is-perfect-for-backends-for-frontends/

Data Fetching, HTML Streaming and RSC: the Next Way or the Remix Way

Yao Ding — Fri, 25 Nov 2022 03:07:56 +0000

The recent two big announcements from the React community(or if you only care about React, then that qualifies as the whole web community) is the release of Next.js 13 and Remix joining Shopify. Admittedly, meta frameworks increasingly are like smartphones these days: they look alike, use similarly but are implemented differently to claim they run better benchmarks, and this applies for Next.js 13 and Remix too: a lot similarities (nested route, layout, server side data-fetching) but some fundamentally different implementations.

Next.js 13 is deemed as almost the official React framework by the React core team, with its integration with streaming Server Side Rendering(SSR) and React Server Component(RSC), while Remix, coming from react-router, takes a different approach and leans more on the web platform. Let's look at these differences and learn about the tradeoffs.

Streaming SSR

HTML streaming is not really a new thing. There are posts dated as early as from 2005, and it has been kept mentioned over the years, but just never took off. Taylor Hunt wrote a nice article about why it is not common, and aside from inconsistent naming and poor support, I think another reason on a deeper level is the gain of actual decreased Time to First Byte (TTFB) comparing with heavy implementation effort is just too marginal(see an example here).

Even though this is considered as a core piece of the React architecture and soon will be in Remix too, I still feel like it will end up like web components: everyone knows about it but no one uses it just because there are better alternatives. But if somehow Next.js can make this as ergonomical and practical as possible, and it can be used out-of-the-box and app naturally get optimized TTFB, it might get adopted widely, so let's wait and see.

RSC

The biggest advantage of using RSC is of course to reduce the codes shipped to the client side. On the Remix side, it touts the concept of Progressive Enhancement, that apps will work correctly without JavaScript and all assets are prefetched/preloaded in parallel. So either way the initial runtime should not scale as the application codebase grows. Another big selling point of RSC is that server logic co-locates with corresponding components, and Remix achieves the same goal with route-level loader/actions. In my opinion, this view/logic colocation might be the best thing and drastically improves the developer experience, saving so much back-and-forth when developing APIs and views together.

RSC definitely has its perks, although the mental model of differentiating server and client components could be repetitive and error prone, as mentioned in Shopify's post about why they turn to the Remix model. Developers would need to carefully plan their components structure and pay attention to the constraints of using server and client component, with the incoming change to hooks further increases the cognitive efforts. My two cents is this very much feels like a leaky abstraction which can be solved with something like a compiler -- React would just know if this should be a server or client component, instead of asking user to do the grunt work. Hopefully there will be something like React without memo in the future, but for RSC.

Data Fetching

The key differences for data fetching as summed by the Shopify team is whether the queries are run on route-level (loader in Remix) or component-level (RSC in Next). For each request, for Remix all data fetchers within nested routes are called in parallel, then Remix return a completed rendered HTML; while Next.js returns HTML immediately with placeholders(Suspense), fetching data sequentially following component hierarchy, then returns with a completed rendered HTML. This seems to be a philosophical design differences between these two projects. Each pattern has its use case, as the Remix team describes RSC

has a chance of providing a better UX when your user's network is fast, but your server's data loading is slow.

That means if your server is always fast, and you cannot guarantee your user's network is fast too, Remix might be better. The interesting part about Shopify buying Remix, is that I would assume Shopify is very confident about its API will never be slow, so the server rendering model is better than the streaming model.

Final thoughts

There will never be a perfect web framework, and you should really weigh in the tradeoffs based on the use cases, but generally you can't go wrong choosing either one here. Both are battle-tested, developed by brilliant people and backed by large companies. Next.js might has the upper hand of having the largest community, but since Shopify bought Remix, it might also get more community support. I'm very excited about the future both frameworks bring to us!

What's with All the Runtimes for JavaScript?

Yao Ding — Sat, 13 Aug 2022 23:28:11 +0000

Right now it is an exciting time for JavaScript. We just got a new shiny fast runtime Bun, with the last new kid Deno being released only 4 years ago, and we have edge computing/serverless runtimes like Cloudflare worker and Blueboat. With all these hypes for the JavaScript community, I could not help but ask, how come only JavaScript gets all these fancy new runtimes? Why don’t we hear these more often in other languages?

What is a runtime anyway?

Runtime can mean different things, but here we refer to the runtime environment or runtime system, which is the system where the program is intended to be run. Basically, it means you need to install some libraries or use some executables to run your codes, like how you would use node command to run your JavaScript codes. One thing to note is that you might confuse it with “runtime library“. Sometimes we also talk about “runtime” in certain compiled languages, but more often these are standard libraries that are included during every build to manage heap/stack and garbage collections. Check out some faqs like the one for Go and for Rust.

Some languages don’t need one

The interesting thing about runtime is not all languages require one to run their programs. Let’s take some static-typed, compiled languages for example. Usually they are compiled ahead-of-time into binary executables, and sometimes for modern languages like go, these executables can be even cross-platform. When you run these executables on a computer, you do not necessarily need to pre-install any required libraries on that computer. So for these languages, we don’t even need a runtime.

Others might have a few runtimes, but often with an official implementation

Being a static-typed and compiled language, Java does need a runtime, which is a virtual machine called Java Virtual Machine(JVM). When Java source codes are being compiled, they are transformed into bytecodes, and these bytecodes will be executed in JVM. In some sense, python being an interpreted language is actually quite similar to Java: the Python interpreter would first transform python source codes to bytecodes and these bytecodes would be executed in the Python virtual machine. The difference is for Python the interpreter and virtual machine are both inside the same executable. So for these two languages, they would both require a runtime, to either interpret and/or run the intermediate codes. For Java, there are different JVMs; for Python, there are also alternatives other than the default CPython. These are all different runtimes, but most of the time we always use the default reference implementation.

JavaScript runtime is made of JavaScript engine and implementations of other APIs

Historically being an embedded language, we use JavaScript to perform tasks in the host environment, most of the time being a browser. These tasks, like DOM manipulation, adding event listeners, and fetching HTTP requests, though initiated by JavaScript codes, are all part of Web APIs and not part of the core language. So browser would need an “engine” to run these JavaScript codes to get work done. The term “JavaScript Engine“ echos the other major part of a browser - rendering engine, and is more suitable than “JavaScript interpreter“ since modern engines also use Just-In-Time compilation for performance improvement(Interestingly, only the PHP community uses the word “engine” to refer its interpreter).

So we can think of the JavaScript engine as a minimum runtime that is an implementation of the ECMAScript spec, or the “core JavaScript“, and it will only execute JavaScript synchronously, which is not that useful. The runtime will add all the good stuff that we want: for the browser environment, it’s DOM, Fetch and other Web APIs; for the server environment, it’s file systems, networking and also some Web APIs. If I can use an analogy: the JavaScript engine is like a human brain that can understand instructions, and runtime is the complete human with a brain and a body that can both understand instructions and perform tasks. Just to think that something necessary and simple as the console API is not included in the ECMAScript spec and has be to add by the runtime. To make up these “bodies“, or to implement these APIs, we also need to use other low-level languages, like for Node it’s c++, for Deno it’s Rust, and for Bun it’s Zig. These are all driven by the community; the lack of an official organization or a reference implementation for server-side JavaScript also makes it possible that one cannot overshadow the others.

Conclusion

So there you have it, for other languages, either it does not need a runtime at all, or it has several runtimes but one being predominately used. For JavaScript, with multiple choices for web browsers, we also have several contenders for runtimes, and there always will be newcomers to challenge the status quo. Just like how all the major frontend frameworks compete with each other and make the web better altogether, I believe all runtimes are going in the same good direction for server-side JavaScript, for that we have to thank all the creative and hard-working community contributors, who keep making JavaScript fresh and exciting.