Molecule: a VSCode-style workbench UI as a React framework

The workbench without the editor product around it

Visual Studio Code is a good model for an interface and an awkward thing to reuse. Its workbench layout, the activity bar, the panel arrangement, the command palette, the settings tree, the status bar, all of that is the part a product team actually wants, while the parts they do not want are the language servers, the debug adapters and the extension marketplace.

Molecule is DTStack's attempt to separate the two. The README describes it as a lightweight Web IDE UI framework built with React.js and inspired by VSCode, with Extension APIs designed to resemble the VSCode ones so that extending the workbench is a familiar exercise. The claim is that it has been applied to many products in DTStack, and the online preview link points at a hosted example application, with a separate molecule-examples repository for the code.

The audience is therefore a team building a data platform console, a SQL workbench, a query editor or a code review tool. The topics list makes the lineage clear: monaco-editor, react, vscode, workbench, ide, sql, web-ide, storybook and typescript.

What ships inside the framework is a defined set of pieces. The Visual Studio Code workbench UI is built in, and it is compatible with Visual Studio Code colour themes, which means an existing theme file can be reused rather than a palette designed from scratch. The workbench can be customised through React components. The Monaco editor is built in, and with it the command palette and keybinding features. Internationalisation is supported, with Simplified Chinese, Korean and English included. Settings are built in and can be edited and extended through an extension. Basic Explorer and Search components are built in and can be extended through an extension. And the whole thing is TypeScript ready, with type definitions shipped in the package.

What is not in that list matters as much: no language server, no terminal, no debugger, no source control. Those are the parts a product team has to supply.

The create() entry point and how extensions attach

The integration model is small on purpose. A host application calls create with a configuration object, gets back an instance, and renders the Workbench component through that instance. The extensions key is the extension application's entry, and the documentation points to the Quick Start for the details of the extension model.

The whole of the basic usage in the README is this:

import React from 'react';
import ReactDOM from 'react-dom';
import { create, Workbench } from '@dtinsight/molecule';
import '@dtinsight/molecule/esm/style/mo.css';

const moInstance = create({
    extensions: [],
});

const App = () => moInstance.render(<Workbench />);

ReactDOM.render(<App />, document.getElementById('root'));

Three things in that snippet carry the design. The stylesheet is a separate import, so the framework ships CSS as an asset rather than injecting it. The extensions array is empty in the starter, so an application can begin with the bare workbench and add pieces. And rendering goes through moInstance.render rather than by exporting a ready-made component, which is what lets the instance hold the state, the extension registry and the command dispatch that the workbench UI depends on.

The call to ReactDOM.render at the end is worth a second look, because that API is the legacy one in React. The framework is built on React and the example targets it, but a team starting a new product on a current React release will want to check the compatibility story for themselves, because the README does not state a React version requirement.

Extensions are the extension point that the VSCode resemblance is built around. They register contributions rather than components, in the same spirit as VSCode, and the workbench pieces named in the feature list, settings, explorer and search, are all described as extensible that way.

Installing the package and running it locally

The package is published to npm under a scoped name:

npm install @dtinsight/molecule
# Or
yarn add @dtinsight/molecule

The scope matters for consumers, because the published artefact is not called molecule but @dtinsight/molecule, and the style import path in the example confirms the same layout, with the stylesheet living under an esm/style directory inside the package.

For working on the framework itself, the README gives the clone command and then a small set of yarn commands:

git clone [email protected]:DTStack/molecule.git
yarn # Install dependencies
yarn dev # Start dev mode

The dev mode runs Storybook, and the README names the address explicitly, http://localhost:6006/. The port also appears in the package scripts, where dev is defined as start-storybook -p 6006. Components are developed in isolation in Storybook, which is why the repository has a .storybook directory and a stories directory next to src.

The test and build commands are:

yarn test -u

yarn build # Compile to ESM
yarn web # Web Preview Mode

The build compiles the source into ES6 modules and writes them to an esm folder, and the package manifest confirms it by pointing module at ./esm/index.js and typings at ./esm/index.d.ts, with esm and build/preinstall.js as the published files. The web preview mode serves those ES modules directly, so the thing you test in the browser is the same artefact that ships.

One packaging detail is easy to miss in the manifest: a preinstall script runs node ./build/preinstall.js when the package is installed. Anything that script does runs on every consumer install, and the README does not explain its purpose, so it is worth reading that file before adding the dependency to a locked-down build pipeline.

Settings, explorer, search and the Monaco command palette

The built-in components are what make this a workbench rather than a layout.

Settings are built in, editable and extensible through an extension. That means the settings UI is not a read-only panel, and an extension can contribute new setting entries, which is how a product adds a panel-specific option without forking the framework. Search and the Explorer follow the same pattern: basic implementations are included, and the README states that both support extending via the Extension mechanism.

The command palette and keybinding features come from the built-in Monaco editor, which is pinned in the dependencies at monaco-editor ^0.31.0. That matters for two reasons. The first is that the palette in an IDE is not a separate widget, it is the same command registry the keyboard shortcuts and the menus use, so having it come from the editor gives consistent dispatch. The second is that the version is old enough that the pinned major version predates a fair amount of change in that library, and a product that wants newer editor features has to reconcile that with what the framework expects.

The workbench is also compatible with Visual Studio Code colour themes, so a team with an existing theme can point at it rather than restyling every panel by hand.

On the documentation side, the site at dtstack.github.io/molecule carries an introduction, a quick start, an API reference, a guide on extending the workbench and a link to the examples repository. The README also notes that the extension documentation is where the detail lives, and that the README itself is a starting point, with a Chinese and a Korean translation of it kept in the repository alongside the English one.

The core question any adopter has to answer is how much of this survives contact with their own product. The workbench is a React tree with a specific structure and its own CSS, and a team that wants a materially different layout is fighting the framework rather than using it.

A UI framework rather than a development environment

The clearest boundary is the one the feature list draws. Molecule provides the shell, the editor widget, the command dispatch and the extension surface. It does not, in the documented feature set, provide a language server, a terminal emulator, a debugger or source control integration.

That is a defensible division. A team building a SQL console, for instance, has a query execution service on its own side and needs an editor, a result pane, a schema explorer and a way to save snippets. A team building an internal code review tool needs a diff view and a comment thread. Neither needs a compiler toolchain, and neither wants to take one. For those cases, taking the workbench saves a great deal of work.

The opposite case is a team that wants a browser-based development environment. There, the missing pieces are not details, they are the product, and adopting Molecule means sourcing or building a language server integration, a terminal and a file system abstraction on top of a framework that does not offer them. The README does not document any extension points for language servers, terminals or file systems, and it is fair to read that absence as a sign they are out of scope for this project.

The other limitation is the dependency floor. The dependencies include monaco-editor, react-dnd and react-dnd-html5-backend for drag and drop, a set of rc- components for dialogs, tooltips and textareas, lodash, immutability-helper and dt-utils. The rc- family in particular tends to move with the React major version, and the README does not state a supported React range, so a product on React 18 or 19 has to verify compatibility itself.

Finally, the framework is a component of a larger product ecosystem at DTStack rather than a general purpose project, and the communication channels listed in the README, a DingTalk group and a Discord server, are vendor community channels rather than an independent project community.

Licence, release status and what an upgrade would involve

The licence terms are the confusing part of this repository. The README states that the code is licensed under the MIT licence, with copyright held by DTStack, and the package manifest records the licence as MIT. The repository's own licence field, however, is classified by GitHub as a custom licence it cannot categorise. Since the LICENSE file is the document that governs, that file is what to read, and the MIT statement in the README and the manifest is a useful cross-check rather than the authority. This description covers the published terms rather than legal advice.

On releases, the version in the manifest is 1.3.6, and the tag list shows v1.3.6 from 2024-06-24, v1.3.5 from 2024-02-20 and v1.3.4 from 2023-06-12. The repository is not archived and the last push was on 2026-06-02, so work has continued well after the last published tag. The gap between the two is the first thing to understand about this project: the npm version most teams install is more than two years old, while the main branch has moved on. A team that wants current behaviour is looking at a source build, not at a published package.

The CHANGELOG.md and MIGRATION.md files at the top level are where that movement would be recorded, and the presence of a migration guide suggests the extension API has changed across versions. That is the main upgrade cost: the extension API is the surface your product code actually touches, so a version gap is not a routine dependency bump but a migration project.

The repository also carries the usual quality infrastructure, a GitHub Actions workflow, a Codecov configuration, an eslint and stylelint setup, a jest configuration, a commitlint config, prettier and storybook, and a Core Infrastructure Initiative badge. The website directory holds the documentation site, and the scripts directory holds the release script that the manifest invokes through zx.

None of that changes the evaluation: Molecule is a well-organised framework with a public API, an extension model and a documentation site, whose practical constraint is the age of the published package relative to the state of the repository.

Editorial conclusion

Adopt Molecule when you are building a browser IDE, SQL console or code editor for an internal product and want the workbench layout, editor and extension model without rebuilding a VSCode look, and stay on it only if you are prepared to own the parts it does not provide. It is a poor fit if you need a working development environment out of the box, because nothing in the documented feature list covers a language server or a terminal. Before building on it, check that the pinned monaco-editor version and the 1.3.6 release from 2024-06-24 still match the browser and React versions your product uses, and read the LICENSE file, since the repository's licence classification disagrees with the MIT terms stated in the README and package.json.

Frequently asked questions

Official sources

1. DTStack/molecule on GitHub
2. Issues
3. Project website
4. README
5. Releases