|
2 | 2 |
|
3 | 3 | Native implementation of React's server-side rendering (SSR) and React Server Components (RSC) architecture for Reason. |
4 | 4 |
|
5 | | -Designed to be used with [reason-react](https://github.com/reasonml/reason-react) and [Melange](https://github.com/melange-re/melange). Together it enables developers to write efficient React components using a single language, while target both native executable and JavaScript. |
| 5 | +Designed to be used with [reason-react](https://github.com/reasonml/reason-react) and [Melange](https://github.com/melange-re/melange). Together it enables developers to write efficient React components using a single language, while compiling into native code and JavaScript. |
6 | 6 |
|
7 | 7 | ## Features |
8 | 8 |
|
9 | 9 | - **Server-side rendering HTML** with `ReactDOM.renderToString`/`ReactDOM.renderToStaticMarkup` |
10 | | -- Server-side rendering **streaming HTML** with `ReactDOM.renderToStream` (similar to react@18 `renderToReadableStream`) |
| 10 | +- Server-side rendering **streaming HTML** with `ReactDOM.renderToStream` (exactly like `renderToReadableStream`) |
11 | 11 | - Includes **`React.Suspense`** and **`React.use()`** implementations |
12 | 12 | - **server-reason-react-ppx** - A ppx transformation to support JSX on native |
13 | 13 | - All [reason-react](https://reasonml.github.io/reason-react/) interface is either implemented or stubbed (some of the methods, like React.useState need to be stubbed because they aren't used on the server!) |
14 | | -- **React Server Components** - A ReactServerDOM module for streaming RSC payload, an esbuild plugin to enhance the bundle with client-components mappings, a Dream middleware to serve the RSC endpoint and a dummy implementation of a router (still [work in progress](https://github.com/ml-in-barcelona/server-reason-react/issues/204)) |
| 14 | +- **React Server Components** - A ReactServerDOM module for streaming RSC payload, an esbuild plugin to enhance the bundle with client-components mappings, a Dream middleware to serve the RSC endpoint and an implementation of a router |
15 | 15 |
|
16 | | -> Warning: This repo contains a few parts that are considered experimental and there's no guarantee of stability. Most of the stable parts are used in production at ahrefs.com, app.ahrefs.com and wordcount.com. Check each module's documentation for more details. |
| 16 | +> Warning: This repo contains a few parts that are considered experimental and there's no guarantee of stability. Most of the stable parts are used in production at ahrefs.com. Check each module's documentation for more details. |
17 | 17 |
|
18 | 18 | ## Why |
19 | | - |
20 | | -There are plenty of motives for it, the main one is that [ahrefs](https://ahrefs.com) (the company I work for) needs it. We use OCaml for the backend and Reason (with React) for the frontend. We wanted to take advantage of the same features from React.js in the server as well. |
21 | | - |
22 | | -Currently 100% of the public site ([ahrefs.com](https://ahrefs.com)), the shell part of the dashboard ([app.ahrefs.com](https://app.ahrefs.com)) and [wordcount.com](https://wordcount.com) are rendered on the server with `server-reason-react`. |
23 | | - |
24 | | -What made us create this library was mostly: |
25 | | - |
26 | | -- Use the same language (Reason) for both server and client |
27 | | -- Embrace server-client integrations such as type-safe routing, JSON decoding/encoding, sharing types and logic, while keep enjoying functional programming patterns |
28 | | -- Native performance is better than JavaScript performance (Node.js, Bun, Deno) |
29 | | -- Writing React from a different language than JavaScript, but still using the brilliant pieces from the ecosystem |
| 19 | + |
| 20 | +There are plenty of motives for it, the main one is that [ahrefs](https://ahrefs.com) (the company I work for) needs it. We use OCaml for the backend and Reason (with React) for the frontend. The second one is probably because is crazy fun, and the real but the serious lists was mostly: |
| 21 | + |
| 22 | +- Use the same language for both server and client |
| 23 | +- Embrace server-client integrations such as type-safe routing, JSON decoding/encoding, sharing types and logic all in functional programming patterns |
| 24 | +- Native performance is much better than JavaScript performance (Node.js, Bun, Deno) |
| 25 | +- Native development provides a safer architecture |
| 26 | +- Using the brilliant pieces from the React.js ecosystem |
30 | 27 | - Exploration of OCaml effects and React |
31 | 28 | - Further exploration with OCaml multicore, direct-style and concurrency with React features such as async components, React.use or Suspense |
32 | 29 |
|
|
0 commit comments