Merge pull request #2621 from appwrite/fix-headings

Author: atharvadeosthale

src/routes/blog/post/remix-3-whats-changing-and-why-it-matters/+page.markdoc

@@ -15,7 +15,7 @@ But in May 2025, the team [announced Remix 3](https://remix.run/blog/wake-up-rem
 
 It's a big step. The framework now runs directly on the Fetch API (using standard `Request` and `Response` objects), instead of Node's proprietary `req` and `res` system. This means it can run on any JavaScript runtime; Node, Deno, or Bun, without adapters. It still supports the same patterns developers liked in Remix 2, but without depending on React's lifecycle or its virtual DOM. The team calls this a move toward being "closer to the web itself."
 
-### Why the Remix team chose to rebuild in version 3
+# Why the Remix team chose to rebuild in version 3
 
 When Remix started, React was the natural foundation. Its component model, rendering flow, and community gave Remix an instant head start. But over time, that foundation began to limit what the team could do.
 
@@ -25,7 +25,7 @@ Remix 2, meanwhile, had thinned out. Most of its core logic had moved into React
 
 This rebuild also reflects a return to the web's own strengths. Browsers already know how to handle navigation, forms, and requests. The Fetch API, URL, Request, and Response objects are now available on both the server and client. Remix 3 builds directly on these features instead of wrapping them in extra abstractions. The goal is to make web development less about "framework rules" and more about the platform that's already there.
 
-### The six principles guiding Remix 3
+# The six principles guiding Remix 3
 
 The team described six principles that define Remix 3's direction:
 
@@ -38,7 +38,7 @@ The team described six principles that define Remix 3's direction:
 
 Together, these principles explain why Remix 3 looks so different. The team wants a system that's modular and flexible internally, but simple and predictable on the surface.
 
-### A new architecture built on web standards
+# A new architecture built on web standards
 
 Remix 3's architecture centers on the Fetch API. Every incoming request, whether from a browser, a test, or an edge worker, is a standard `Request` object. Every response the framework sends is a `Response` object.
 
@@ -55,7 +55,7 @@ export const routes = route({
 
 From there, Remix can infer types and generate helpers like `routes.books.show.href({ slug: "gatsby" })`. This keeps links type-safe and prevents mistakes. It also lets the router generate correct URLs for any environment.
 
-### The new rendering model
+# The new rendering model
 
 The biggest change is that Remix 3 no longer uses React. You still write JSX, but it's handled by a custom component model built specifically for Remix. There's no virtual DOM. When something changes, you update state directly and call `this.update()` to refresh that part of the UI. Events use the browser's native event system instead of React's synthetic one.
 
@@ -65,7 +65,7 @@ To handle partial updates, Remix 3 introduces a feature called Frames. A Frame i
 
 For example, a comments section could live inside a Frame. When a user submits a new comment, the server renders updated HTML for that frame and sends it down. The rest of the page stays untouched. It feels like client-side interactivity, but it's still server-driven and progressively enhanced.
 
-### Data loading and actions
+# Data loading and actions
 
 The loader and action pattern that defined Remix 2 is still here. Each route can export handlers for different HTTP methods. A `GET` handler fetches data to render; a `POST` (or `PUT`, `DELETE`) handler performs a mutation.
 
@@ -94,23 +94,23 @@ This is a key advantage: Remix runs JavaScript on the server but leverages exist
 
 This pattern keeps the app predictable. Data always comes from one place, the loader for that route, and every action leads to a clear revalidation path. No client-side fetching hooks or state libraries are needed.
 
-### Error handling
+# Error handling
 
 Error handling in Remix 3 continues the route-based model from Remix 2. Each route can define its own error boundary so that failures stay local. If a child route fails to load or render, only that section shows an error message, while the rest of the page remains intact.
 
 When a loader throws a `Response` with an error status, Remix automatically triggers the matching error boundary. For example, if a loader throws `new Response("Not found", { status: 404 })`, Remix will show the Not Found UI for that route but keep parent layouts mounted.
 
 This approach prevents a single broken component from blanking the entire page (a common problem in many SPAs) and helps developers handle network or data errors cleanly.
 
-### TypeScript and developer experience
+# TypeScript and developer experience
 
 Remix 3 is written in TypeScript from the start, so every route, loader, and action is strongly typed. Route parameters and return types are inferred automatically. For example, if `routes.books.show` has a `:slug` parameter, TypeScript will know that `params.slug` is a string inside its handlers. You can pair this with schema validation libraries like [Zod](https://zod.dev/) to validate form data and API inputs at runtime.
 
 Because Remix avoids code generation, you don't need a separate typegen step. The framework infers everything from the code you already write. The same runtime-first philosophy also means you can run your app directly in `ts-node` during development, without waiting for a full build.
 
 The development workflow is simpler, too. The [preview demos](https://remix.run/blog/remix-jam-2025-recap) show a single `remix dev` command that starts a local server, watches files, and reloads automatically, no webpack config or complex bundler setup required. While Remix 3 is still in preview, you can follow the [official blog](https://remix.run/blog) and [GitHub repository](https://github.com/remix-run/remix) for early access and updates.
 
-### Deployment and environment support
+# Deployment and environment support
 
 Remix 3's platform independence is one of its biggest selling points. Since it's built on the Fetch API, the same app can run on Node, Deno, or Bun with almost no changes.
 
@@ -127,15 +127,15 @@ That pattern works in Node, [Appwrite Sites](https://appwrite.io/sites), Netlify
 
 This also makes Remix 3 easier to scale. You can deploy it as serverless functions, edge workers, or a long-running Node process depending on your needs. The framework doesn't force a specific host or vendor. That independence is deliberate; the team wants Remix 3 apps to run anywhere, without lock-in.
 
-### Trade-offs and what to expect
+# Trade-offs and what to expect
 
 Rebuilding a framework from scratch comes with trade-offs. Dropping React means losing direct access to its huge ecosystem. Libraries like Material UI or React Query won't plug in directly. Developers will either use plain web components, small JS libraries, or future Remix-specific packages.
 
 There's also a learning curve. Without React's hooks or automatic rendering, you'll manage updates yourself. That's simpler in concept but different in habit. It's a shift from "declare and forget" to "update when needed."
 
 Still, the potential benefits are clear: less complexity, less JavaScript on the client, and better performance out of the box. The approach brings Remix closer to the strengths of the web, fast first loads, resilient forms, and consistent server logic, while keeping the conveniences of a single framework.
 
-### Looking ahead
+# Looking ahead
 
 Remix 3 is still in preview, but it's already one of the most interesting moves in web development right now. It reflects a broader shift in how developers think about the web: away from heavy client frameworks and back toward simplicity, standards, and server-driven logic.