HTML Streaming Over the Wire 🥳: A Deep Dive

In our earlier article within the collection, we launched the Diff DOM Algorithm briefly with out delving into its technical intricacies. On this installment, we current the diff-dom-streaming library, an open-source resolution designed to facilitate HTML Streaming Over the Wire utilizing the Diff DOM Algorithm. This library is meant not just for use inside different frameworks and libraries but additionally as a standalone resolution.

Why HTML Streaming Over the Wire?

Provided that trendy browsers have supported HTML streaming for years, why restrict ourselves to preliminary web page masses? Why not lengthen HTML streaming to server interactions as nicely? Finally, reverting to HTML (HyperText Markup Language) restores the online’s basic ideas (HyperText Switch Protocol).

For a while now, I have been immersed in creating Brisa, an experimental framework slated for public launch this summer time (If you’re considering understanding extra, subscribe to my weblog publication for now). One in all our main targets has been to reduce client-side JavaScript code for server interactions. Drawing inspiration from server actions and HTMX ideas, we have achieved the aptitude to construct single-page functions (SPAs) with simply 800 bytes—equal to the RPC (Distant Process Name) for server communication. In instances requiring consumer elements, they seamlessly rework into internet elements with alerts, increasing the code to a mere 3KB.

Moreover, now we have aimed to leverage the online platform to its fullest extent. For server actions, we opted to transmit Hypertext. As for consumer elements, they rework into internet elements and, coupled with alerts, reply dynamically to doc modifications with out knowledge transmission.

To grasp the distinction between the server interactions that we’re conversant in lately, let’s evaluation how we’re doing these server interactions by JSON:

Interplay with JSON

Historically, server interactions entail:

• Capturing a consumer occasion and writing code to serialize knowledge, sending JSON to an endpoint (increasing client-side code).
• Writing an endpoint, deserializing/serializing each enter and output knowledge to return JSON.
• Processing the response on the consumer facet, deserializing JSON, and sustaining it in reminiscence for UI library rerendering, thereby additional growing client-side bundle measurement.

It is a very foolish instance about debouncing an enter textual content and validating a code, however to indicate you you can be conversant in doing all this logic on the consumer to do a server interplay:

Consumer code:

operate debounce(func, delay) {
  let timeoutId;
  return (...args) => {
    const fn = func.bind(this, ...args)
    clearTimeout(timeoutId);
    timeoutId = setTimeout(fn, delay);
  };
}

export operate ClientComponent() {
  const [showContent, setShowContent] = useState(false)

  async operate handleInputOnClient(e) {
    const code = e.goal.worth;
    const res = await fetch(/* some endpoint */, {
      methodology: 'POST',
      physique: JSON.stringify({ code })
    })
    if(res.okay) setShowContent(true)
  }

  if (showContent) return 'some content material'

  return <enter kind="textual content"  onChange={debounce(handleInputOnClient, 300)} />
}

Server code:

export operate POST(request: Request) {
  const knowledge = await req.json();
  return new Response(null, { standing: knowledge.code === 'foo' ? 200 : 401 });
}

Is not this cumbersome? Having to repeat this course of for every server interplay solely bloats client-side code.

Interplay with HTML Streaming

With HTML Streaming Over the Wire, the workflow in Brisa transforms:

• Upon capturing a consumer occasion inside a server part, the method resembles that of an endpoint, the place entry to the browser occasion serialized from the server is obtainable due to Brisa’s RPC.
• Upon finishing occasion processing throughout the server part, the RPC runtime on the consumer facet updates solely the modified parts of the online, streaming HTML generated from the rerender executed on the server.

Server part:

export operate ServerComponent({}, request: RequestContext) {
  async operate handleInputOnServer(e) {
    if(e.goal.worth === 'foo') {
      request.retailer.set('display-content', true);
      rerenderInAction();
    }
  }

  if (request.retailer.get('display-content')) return 'some content material'

  return <enter kind="textual content" onInput={handleInputOnServer} debounceInput={300} />
}

On this workflow, there may be debounce[Event] attribute impressed by HTMX to make the RPC consumer do the debounce, the remaining is code that runs solely on the server, and the shop lives on request time.

This new workflow provides zero bytes of client-side code for every server interplay. Why add client-side JavaScript to carry out the identical DOM replace process? That is the essence of the RPC code, which stays fixed over time. The server actions are in control of streaming HTML for the consumer RPC to replace the UI.

By eliminating JSON transmission, we will leverage streaming for considerably sooner and extra progressive UI updates, even enabling “suspense” with out extra client-side code.

Diff DOM Algorithm with Streaming

The Diff DOM (Doc Object Mannequin) algorithm has been utilized for years to simulate React’s “Digital DOM” with out virtualization. As a substitute, it operates immediately on the “Browser DOM,” evaluating two HTML nodes effectively and updating the primary DOM tree based mostly on the modifications current within the second.

In essence, HTML Over the Wire (with out streaming) has been achievable for years due to the Diff DOM Algorithm, extensively adopted by many trendy libraries and frameworks.

React, as an illustration, avoids utilizing HTML for transmission between server elements (RSCs) to facilitate streaming in single-page functions and communication with server actions. It depends on progressively loaded JSON with “holes”, which should be processed earlier than using the Digital DOM. Dan Abramov elucidated this in a tweet a couple of months in the past. I inquired additional in one other tweet concerning the feasibility of HTML Streaming, to which he cited two obstacles:

1) doesn’t assist with passing new knowledge to stateful stuff (like a listing of todos to an already mounted todo checklist part)

2) you’d need to both parse HTML your self (non-trivial to do appropriately) or create throwaway DOM nodes

Upon evaluation, I discovered these obstacles to be surmountable.

Relating to the primary level, Brisa obviates the necessity to cross knowledge for stateful elements, as consumer elements make the most of actual DOM components, particularly internet elements. When attributes are modified, they react to modifications utilizing alerts, updating their content material whereas preserving the state. Therefore, use native constructs—internet elements, alerts (at the moment as a proposal in TC39 with stage 0), and HyperText Markup Language—made extra sense.

Relating to the second level, browsers supply a local “hack” for parsing nodes from a stream. This method is elucidated in a video on the “Chrome for Builders” YouTube channel right here.

Subsequently, to assist the Diff DOM Algorithm with HTML Streaming, three features should be thought of:

1. DFS (Depth-First Search): As a substitute of implementing breadth-first search (BFS) for analyzing the DOM tree, DFS should be employed to synchronize with streaming, as HTML chunks throughout streaming all the time arrive in DFS order.
2. Parsing HTML String Chunks to HTML Nodes: Environment friendly parsing of every incoming node throughout streaming is important, together with traversal among the many arriving nodes.
3. Cease and Look ahead to Lacking Chunks: Figuring out situations the place comparability includes knowledge but to be acquired, ready solely as mandatory with out blocking.

Present me the code

I’ve open-sourced diff-dom-streaming, a library weighing solely 1KB. More often than not, you will load it lazily since consumer interplay triggers its want, eliminating the need of loading it upfront.

import diff from "https://unpkg.com/diff-dom-streaming@newest";

// ...

const res = await fetch(/* some url */);

// Apply diff DOM between the present doc
// and the stream reader:
await diff(doc, res.physique.getReader());

This library heralds the truth of HTML Streaming Over the Wire, accessible not simply to Brisa however to quite a few different libraries and frameworks. You possibly can even make use of it in vanilla JavaScript with none extra libraries.

Neighborhood Assist and Adoption

In case you see potential in HTML Streaming Over the Wire and want to contribute to its progress, contemplate giving the diff-dom-streaming library a star on GitHub. Your assist helps to advertise its visibility and encourages additional improvement on this revolutionary strategy to internet improvement.

Present me some instance

Here is the demo of the packing containers you may check out with none framework.

Conclusion

HTML Streaming Over the Wire, empowered by the Diff DOM algorithm, guarantees a return to the online’s core ideas, paving the way in which for a sooner, extra responsive, and scalable internet expertise for all. The way forward for this expertise holds immense potential, and I am desirous to see the way it unfolds in additional frameworks and libraries.