Design and Implementation of a JavaScript Automatic Binding Tool for the iQIYI RND Framework

This article introduces the design and implementation of a new JavaScript automatic binding tool created to satisfy the batch‑binding requirements of iQIYI's RND (React Node Desktop) framework. By researching existing open‑source solutions and combining their successful ideas, the authors built a flexible binding system that supports multi‑inheritance binding, Wrapped pointer conversion, and multiple JavaScript engines (V8, JavaScriptCore). The tool defines an ABI‑stable JS Common API layer that isolates the underlying engine and is being ported to JavaScriptCore.

What is RND? RND stands for React Node Desktop. It combines a React‑style JavaScript framework, a Node.js runtime, and a native UI engine to provide a lightweight, cross‑platform solution for desktop applications. During RND’s evolution, a large number of C++ classes from iQIYI’s proprietary UI engine Lyra need to be exposed to JavaScript, and the sheer volume makes manual binding impractical.

Technical background of existing solutions. The authors examined WebKit’s IDL‑based binding and Cocos Creator’s libclang‑driven approach. WebKit uses Web IDL and Perl scripts to generate engine‑specific code, but still requires hand‑written glue for many cases. Cocos Creator parses C++ headers with libclang, generates a generic interface, and then renders binding code from templates, avoiding duplicated work but lacking fine‑grained IDL control.

Why a new tool? Neither solution met RND’s needs: Cocos Creator’s binding rules are not granular enough to describe per‑method property descriptors, it cannot handle multiple inheritance, and its generated prototypes are not uniform across engines. Therefore a custom tool was developed.

Binding concepts. The article distinguishes three categories of JS APIs:

ECMAScript standard APIs provided by the engine.

Native APIs exposed directly by the host (e.g., DOM, Node.js process.binding, RND’s _setTimeout).

Higher‑level APIs built on top of the previous two (e.g., React, RND’s setTimeout).

The focus is on the narrow definition (category 2) – the actual binding of native C++ functions and classes to JavaScript.

Example binding workflow. A simple C++ class Foo is defined in foo.hpp and foo.cpp :

#include <string>
class Foo {
public:
  std::string ToBind(std::string msg);
  int NotBind(int input);
};

std::string Foo::ToBind(std::string msg) { return msg + " world!"; }
int Foo::NotBind(int input) { return input; }

A YAML rule file foo.yaml declares the class and the method to bind:

# foo.yaml
classes:
  - wrapped_class_name: Foo
    bind_type: class
    methods:
      - wrapped_method_proto: |
          std::string ToBind(std::string msg);

Running the tool with foo.yaml and foo.hpp produces the following binding snippets:

#include "foo.hpp"
class FooWrappable : public Mate::WrappableObject
{
public:
  Foo* impl_;
  FooWrappable(v8::Isolate* isolate, v8::Local
wrapper);
  ~FooWrappable();
  std::string ToBind(std::string msg);
  // ... other generated members ...
};

FooWrappable::FooWrappable(v8::Isolate* isolate, v8::Local
wrapper) {
  impl_ = new Foo();
  InitWith(isolate, wrapper);
  SetTrack(isolate, wrapper, impl_);
}
FooWrappable::~FooWrappable() {
  ClearTrack(impl_);
  delete impl_;
}
std::string FooWrappable::ToBind(std::string msg) {
  return impl_->ToBind(msg);
}

JavaScript can now use the class directly:

var foo = new Foo();
foo.toBind("hello"); // -> "hello world!"

Tool pipeline. The binding generation consists of five steps:

Parse C++ headers with libclang to obtain an AST.

Extract class, method, property, and type information from the AST.

Match the extracted information against user‑provided YAML rules, filtering out unwanted symbols.

Refine the matched data (merge overloads, resolve inheritance, detect conflicts) to produce a model suitable for template rendering.

Render the final binding code using pre‑written templates.

Binding rule format. Rules are written in YAML because of its readability and ability to embed raw C++ snippets without escaping special characters. The rule file can specify bind type (interface, object, class), custom method prototypes, static flags, and property descriptors.

Mate framework. The generated wrapper classes inherit from Mate::WrappableObject , a thin abstraction over the underlying engine. Mate provides automatic conversion between C++ and JavaScript types via templated Converter classes (e.g., Converter<uint32_t>::FromV8 and Converter<uint32_t>::ToV8 ). This eliminates repetitive boilerplate in hand‑written bindings.

Challenges and solutions.

Multi‑inheritance binding is not directly supported; the tool duplicates parent methods in child wrappers to avoid unsafe pointer casts.

Callbacks from C++ to JavaScript require manual conversion to base::Callback before being passed to native code.

Pointer or reference parameters for primitive types need explicit hand‑written glue.

Binding non‑class functions and global variables is currently unsupported.

Extending to multiple JavaScript engines. Since Mate originally targets V8, the authors propose three strategies to support other engines:

Mate for JSC – re‑implement Mate on top of JavaScriptCore.

JSCShim – adapt V8‑style APIs to JSC (similar to Node‑ChakraCore).

JS Common API – introduce a thin, engine‑agnostic layer (Node‑Addon‑API/N‑API) and fold Mate’s functionality into it.

The chosen path is the third one: a JS Common API built on Node‑Addon‑API, which retains ABI stability and allows a single binding implementation to work with both V8 and JavaScriptCore. A JavaScriptCore port is under development.

Future work. The roadmap includes completing the JavaScriptCore port, auto‑generating simple converters, providing a visual rule‑authoring tool, adding options for raw pointers, smart pointers, and reference‑counted objects, and supporting non‑class functions/variables.

For more details on the RND framework, readers are encouraged to consult the other articles in the iQIYI RND series.