weex-native-directive
Weex native directive design
A design proposal for Weex that moves long list rendering to native iOS/Android code, reusing screen cells instead of building a virtual DOM node per item.
Weex Native Directive
This project proposes a way to make long scrolling lists much faster and less memory-hungry on mobile apps. The core idea is to shift responsibility for rendering lists from the JavaScript framework to the native (iOS/Android) side, which can reuse and recycle list cells more efficiently.
Normally, when a JavaScript framework like Vue renders a long list, it creates a separate virtual DOM node for every item—if you have 1,000 items, you get 1,000 nodes in memory, even if only 10 are visible on screen at any moment. This is slow and wasteful. The new approach instead sends the raw list data and a template to the native side, letting the native platform handle the actual rendering and reusing cells as users scroll (similar to how UITableView works on iOS or RecyclerView on Android).
The syntax introduces a new ` component that takes an array of data and one or more templates. You tell the framework which data field determines which template to use, and the native side takes it from there. Alongside this, the proposal defines a new language for templates: directives like [[match]] for conditional rendering, [[repeat]] for loops, and a binding syntax using @binding` expressions so the native layer knows which data fields map to which UI properties. Event handlers can also pass arguments by binding them to data fields.
The README is the design document itself, written primarily in Chinese, so it lacks implementation details. It's clear the authors wanted backward compatibility—existing list components still work—but code that tries to directly manipulate the DOM or fetch data from UI won't work with this optimization. The proposal also carefully restricts expression syntax (math, comparisons, logical operators, but no function calls) to keep native parsing simple.
This is a framework-level feature that would require changes to Vue, Rax, and the JavaScript-to-native bridge, not a general-purpose library. It's most relevant to Weex developers building mobile apps with long data-driven lists where performance matters.
Where it fits
- Render very long lists in a mobile app without creating a DOM node per item.
- Recycle native list cells the way UITableView or RecyclerView do.
- Adopt the recycle-list component and cell-slot templates in a Weex-based app.
- Design a JS-to-native binding layer for high-performance list rendering.