Rebuilding remote-ui with the DOM

[lemonmade]

TL;DR: remote-ui has been completely rewritten to use native DOM APIs. You can install the new @remote-dom/core package to get started, review the new examples to get a feel for how the project works, and read the migration guide from remote-ui if you’ve used the @remote-ui libraries in the past.

History

When I originally wrote remote-ui, I was most heavily inspired by react-reconciler, the package that allows developers to transform React’s “virtual DOM” into any number of natively rendered targets. I felt it was critical to choose a model that maintained a “pure” JavaScript representation of a tree of UI components, and allowed that representation to be translated before finally being rendered in the host application. @remote-ui/core was the result of this design.

react-reconciler and @remote-ui/core both look awfully familiar to anyone who has done web development. That’s because they both lean heavily on another JavaScript representation of a tree of UI components many of us are familiar with — the DOM. Though I added more DOM-like APIs to remote-ui over time, remote-ui is totally independent of the DOM today. I avoided the DOM for two main reasons:

• The DOM is not available in most of the JavaScript environments I wanted to run remote-ui in, like Web Workers and iOS’s JavaScriptCore framework.
• The DOM API is large and, for some common operations, not particularly ergonomic.

Since I wrote the first version of remote-ui, I have seen changes in the web development ecosystem that have made me second-guess my original design:

• Cloudflare Workers, Deno, and other JavaScript runtime environments have demonstrated that developers benefit tremendously from applying their knowledge of modern DOM APIs to new problem spaces.
• I spent a lot more time with Preact. Preact is a demonstration in how you can get the same great developer experience as tools like React in a fraction of the size by leaning in to the DOM, rather than abstracting it.
• React, Vue, and other frameworks provide an abstraction layer that allows translating their components to an alternative rendering target like @remote-ui/core, but not all frameworks do. In contrast, all web frameworks provide first-class support for binding to the DOM. Even in packages that do support custom renderers, the provided APIs have often been unstable and difficult for other developers to contribute on. As a result, remote-ui’s integrations with frameworks have been maintained fairly poorly, especially for Vue, which I do not personally use on a regular basis.

Today

Today, I’m happy to re-release remote-ui under a new name: Remote DOM. The name change is more than a coat of paint — the entire repo has been rewritten to be powered entirely by the DOM. “Remote component” are now just custom elements that you can render in the “remote” DOM environment, and any library built to work with the DOM now works without any special adaptors. We’ve also written a small DOM polyfill, so you can continue to run sandboxed code in Web Workers and other environments without a native DOM. Many thanks to @developit for the inspiration to pursue this approach, and for his initial implementation of the DOM polyfill.

If you’re new to remote-ui and Remote DOM, we believe this DOM-based library will make it much easier to get started, and opens up a wider range of libraries for use in your “remote” application code. We’ve prepared a collection of new examples that shows how to create both the “host” and ”remote” environments Remote DOM expects. Once you’ve understood these basic examples, the @remote-dom/core package contains documentation for most of the key features of the library.

If you have an existing setup using remote-ui, the migration will be a bit more involved. We’ve prepared a detailed migration guide to help you understand the new equivalents of older APIs.

If you have any questions about the transition, please post them below.