Improved JSX transform for Server-Side Rendering

[arthurfiorette]

🔍 Search Terms

jsx precompile jsxAttr jsxEscape jsxTemplate Fastest Fast(est) JSX transform preact react jsxs jsxDEV typescript node deno runtime custom configuration ts

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

I'd like to propose the implementation of a new JSX transform optimized specifically for server-side rendering (SSR).

This proposal draws inspiration from a recent release in the Deno runtime, which introduced a highly efficient JSX transform for SSR purposes.

Traditionally, JSX has relied heavily on the Garbage Collector (GC) due to its origins as a templating engine primarily designed for client-side rendering (CSR). However, for SSR scenarios where performance and memory efficiency are critical, this reliance on the GC can lead to suboptimal performance and increased overhead.

The proposed JSX transform works by serializing the HTML parts of a JSX template into static string arrays at compile time. This approach significantly reduces the number of short-lived object allocations and minimizes the workload on the GC during runtime.

Expected benefits as observed in the official deno blog post:

• Improved Performance: Significant reduction in rendering times (observed around 7-20x faster rendering times).
• Reduced GC Overhead: Approximately 50% reduction in Garbage Collection times.
• Framework Agnostic: Designed to be independent of any specific framework, providing flexibility for integration with various SSR solutions.
• Customizable Configuration: Users can specify a custom JSX runtime module via configuration, enabling seamless integration with existing projects.

Library adoption:

Currently, only Preact has integrated support for this optimized JSX transformation, as evidenced by its recent pull request (and Flesh which doesn't count as it uses preact under the hood).

Given TypeScript's potential adoption of this feature, widespread support across various libraries is foreseeable, including popular frameworks like React, all of which stand to gain significant performance benefits.

Moreover, extending this optimization to other JSX runtimes could yield substantial improvements across the ecosystem.

As this feature is implemented, it could be highlighted as a major improvement in future releases, potentially under titles like: "New Typescript JSX for server-side rendering -> 20x Performance Boost." and other things the marketing team needs and likes to hear.

📃 Motivating Example

Consider the following input:

const pClass = 'foo ' + 'bar';
const name = 'world';

const html = (
  <div class="foo">
    <h1>this is a demo</h1>
    <p class={pClass}>some cool content {name}</p>
  </div>
);

Current output

import { jsx } from 'preact/jsx-runtime';

const pClass = 'foo ' + 'bar';
const name = 'world';

const html = jsxs('div', {
  class: 'foo',
  children: [
    jsx('h1', { children: 'this is a demo' }),
    jsxs('p', { class: pClass, children: ['some cool content ', name] })
  ]
});

With the new "jsx": "precompile"

(output copied from deno bundle for this repository)

import { jsxAttr, jsxEscape, jsxTemplate } from 'preact/jsx-runtime';

const pClass = 'foo ' + 'bar';
const name = 'world';

const $$_tpl_1 = [
  '<div class="foo"><h1>this is a demo</h1><p ',
  '>some cool content ',
  '</p></div>'
];

const html = jsxTemplate($$_tpl_1, jsxAttr('class', pClass), jsxEscape(name));

💻 Use Cases

1. Server-side rendering (SSR) applications: Improve performance and reduce garbage collection overhead in SSR applications with TypeScript and Node.js.

2. Large-scale applications: Enhance performance for projects handling extensive JSX content, like complex UIs or dynamic content generation.

3. Microservices architecture: Boost overall system performance by optimizing JSX rendering across multiple SSR services.

4. Real-time applications: Achieve smoother user experiences in applications requiring frequent updates or real-time data rendering.

5. Custom JSX runtimes: Allow developers to integrate with custom JSX runtimes for specific project needs, enhancing flexibility and modularity.

Good reads:

• Original Deno blog post:
  https://deno.com/blog/v1.38#fastest-jsx-transform

• A precompile repository using Deno see how it works:
  https://github.com/marvinhagemeister/deno-jsx-precompile-preact-demo

• Bun's feature request to the same feature:
  Improve JSX transform using tsconfig jsx precompile for server side rendering oven-sh/bun#6878

• React RFCs about createElement stuff:
  https://legacy.reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html
  https://github.com/reactjs/rfcs/blob/createlement-rfc/text/0000-create-element-changes.md#motivation

• Preact implementation:
  feat: support precompiled JSX transform preactjs/preact#4177
  feat: add support for precompiled JSX preactjs/preact-render-to-string#322

[RyanCavanaugh]

What's the advantage of creating a second implementation compared to using jsx: preserve and the existing precompiler?

[arthurfiorette]

Which precompiler are you referring to? Deno now handles it automatically at runtime. The deno bundle CLI, used for pasting precompiled output above, is deprecated. Deno focuses on running TypeScript directly and deno bundle CLI merely "mimics" the actual code executed.

Also, a "official" TS implementation could be used in any JS runtime.

[RyanCavanaugh]

If Deno's just doing a code transform, then that should be usable as a standalone API, I would hope. If it's not, then it seems kinda weird for TS to be on the leading edge of JSX SSR. We're a type checker.

[RyanCavanaugh]

I'm not seeing the need for a second implementation with identical constraints. If this transform can be done from syntax only, then it doesn't make sense for TS to be doing it -- it can be a general tool that takes in any JSX, and belongs in a bundle/minify/etc step (and if it needs type info, type-directed emit is explicitly out of scope). React Compiler should be out soon and would presumably be the most logical place for this kind of functionality to live.