Forem: mizchi (Kotaro Chikuba)

Writing JS FFI in MoonBit

mizchi (Kotaro Chikuba) — Wed, 24 Dec 2025 06:19:39 +0000

I think MoonBit is a wonderful language, but it's still in early stages and lacks libraries. For AltJS and new languages to gain traction, I believe increasing wrapper libraries and type definitions is important.

This article walks through writing FFI for the MoonBit JS backend, with the hope of learning MoonBit and encouraging more library development.

While MoonBit can generate code for native, wasm, and js, I think targeting JS - which has broad application across web, browser, and server-side - is the quickest path to practical use.

Ideally, you'd eventually move toward pure MoonBit implementations that can run cross-platform.

Getting Started with MoonBit JS FFI

To understand what's possible, I recommend reading this article:

https://www.moonbitlang.com/pearls/moonbit-jsffi

Building on that, I'll summarize techniques I learned while writing React bindings for MoonBit.

The interface differs slightly from this article, but it's essentially the content implemented in this package:

https://github.com/mizchi/js.mbt

The specifics in this article may become outdated, but the fundamental concepts should remain applicable.

Differences from Prior JS FFI Implementations

There are actually multiple MoonBit JS FFI implementations:

mizchi/js.mbt was created with the motivation of "wanting a raw JS API wrapper, even at the cost of safety." Since it's FFI anyway, there are inherent limits to safety.

All libraries share the use of --target js and casting with %identity (described later), so they're interconvertible. That said, you can't use them confidently without understanding the mechanisms, so I'll explain how to call JS while covering MoonBit language features.

Build Configuration for MoonBit JS Backend

When targeting only the JS backend, adding this to moon.mod.json helps:

{
  ...
  "preferred-target": "js"
}

This lets you omit --target js for moon build and moon test defaults. (The default is --target wasm-gc.)

Depending on package structure, running moon build --target js generates code in target/js/release/build/*.js.

To generate JS, one of these settings is needed in moon.pkg.json:

{
  "is-main": true
}

Or:

{
  "link": {
    "js": {
      "exports": ["foo"]
    }
  }
}

With is-main, a function is generated with fn main {} as the entry point. With link, functions specified in exports are exported.

For details, see:

https://docs.moonbitlang.com/en/latest/toolchain/moon/package.html

TypeScript .d.ts files are also generated. Primitive values and simple structs can be called directly from TypeScript. (I'll explain the type conversion rules later.)

A minimal structure looks like:

moon.mod.json
moon.pkg.json
lib.mbt
target/js/build/release/lib.js
target/js/build/release/lib.d.ts
target/js/build/release/moonbit.d.ts # moonbit binding

To use this as a JS library, just import from the entry point:

// index.ts
export { foo } from "./target/js/build/release/lib.js"

To publish as a moonbit package, create a user on mooncakes.io, set {"name": "username/pkg", "version": "x.y.z"} in moon.mod.json according to your namespace, and run moon publish.

First Steps with JS FFI

Define functions available only for the JS backend with extern "js". Libraries containing this can only run with --target js.

(There are ways to design multi-backend libraries while using extern, but that's complex and omitted here.)


///|
extern "js" fn console_log(v : String) -> Unit =
  #|(v) => console.log(v)

fn main {
  console_log("hello")
}

This is special syntax, but learn it as an idiom.

#| is a multi-line string literal equivalent to = "(v) => console.log(v)". It's directly embedded in the generated code.

Output code:

const mizchi$js$examples$js$45$output$$console_log = (v) => console.log(v);
(() => {
  mizchi$js$examples$js$45$output$$console_log("hello");
})();

The function name gets a long namespace prefix, but this is simple code that can be minified with terser etc.

You can see MoonBit's String is generated directly as JS String. (I'll explain conversion rules later.)

Initially you'll write code while checking generated values, but with practice you'll be able to visualize the generated code without checking.

Casting with `#external type` and `%identity`

#external is a directive representing values outside FFI. It's not required for JS, but for wasm-gc it represents references like externref for that backend. I add it as a habit.

https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format

"%identity" is a special MoonBit builtin representing the value or reference itself.

Using this, we prepare a type for arbitrary JS values and a casting function:


///|
#external
pub type JsValue

///|
pub fn[A, B] unsafe_cast(a : A) -> B = "%identity"

///|
fn main {
  let val : Int = 100
  let jsval : JsValue = unsafe_cast(val)
  let val2 : Int = jsval |> unsafe_cast
  let _ = val == val2
}

The right-hand input and left-hand type declaration determine unsafe_cast's A, B, making it a function that (unsoundly) casts any A to B.

Generated code:

(() => {
  const jsval = 100;
  const val2 = jsval;
  100 === val2;
})();

This is really all of it - nothing omitted. %identity's unsafe_cast is removed from generated code with no side effects on values.

This makes JsValue usable as an abstraction for any value. Since %identity's unsafe_cast isn't statically type-checked, you can write incorrect casts.

This also passes MoonBit type checking:


///|
fn main {
  let val : Int = 100
  let jsval : JsValue = unsafe_cast(val)
  let val2 : String = jsval |> unsafe_cast
  let _ = val.to_string() == val2
}

What type to cast to is the FFI writer's responsibility. It's like TypeScript's null as any as number.

FFI writers need to master %identity.

Implementing Value Comparison

In MoonBit, implementing impl Eq for T with equal(self: T, other: T) -> Bool enables value comparison with ==.

Let's implement reference comparison for JsValue:


///|
#external
pub type JsValue

///|
pub fn[A, B] unsafe_cast(a : A) -> B = "%identity"

///|
pub extern "js" fn new_object() -> JsValue =
  #| () => ({})

///|
extern "js" fn object_is(a : JsValue, b : JsValue) -> Bool =
  #|(a,b) => Object.is(a,b)

///|
pub impl Eq for JsValue with equal(self, other) -> Bool {
  object_is(self, other)
}

fn main {
  let obj1 = new_object()
  let obj2 = new_object()
  let _ = obj1 == obj2 // false
  let _ = obj1 == obj1 // true
}

Generated code:

const mizchi$js$examples$js$45$output$$object_is = (v,k) => Object.is(v, k);
const mizchi$js$examples$js$45$output$$new_object = () => ({});
function moonbitlang$core$builtin$$Eq$equal$0$(self, other) {
  return mizchi$js$examples$js$45$output$$object_is(self, other);
}
(() => {
  const obj1 = mizchi$js$examples$js$45$output$$new_object();
  const obj2 = mizchi$js$examples$js$45$output$$new_object();
  moonbitlang$core$builtin$$Eq$equal$0$(obj1, obj2);
  moonbitlang$core$builtin$$Eq$equal$0$(obj1, obj1);
})();

It compares obj1 and obj2 generated from FFI using Object.is.

Let's add code to generate undefined, which doesn't exist as a primitive in MoonBit:


///|
pub extern "js" fn undefined() -> JsValue =
  #| () => undefined

///|
pub extern "js" fn null_() -> JsValue =
  #| () => null

///|
pub extern "js" fn JsValue::is_undefined(self : Self) -> Bool =
  #| (v) => v === undefined

///|
pub extern "js" fn JsValue::is_null(self : Self) -> Bool =
  #| (v) => v === null

///|
fn main {
  let v = undefined()
  let _ = v.is_undefined() // true
}

FFI cannot be implemented as getters.

Implementing Show's to_string

To pass values to MoonBit's println() or inspect(), you need to implement the Show trait. MoonBit's trait is designed to be similar to Rust's trait.

For values other than undefined and null, we'll pass value.toString():


///|
pub impl Show for JsValue with output(self, logger) {
  logger.write_string(self.to_string())
}

extern "js" fn ffi_to_string(v: JsValue) -> String =
  # (v) => v.toString()

///|
pub impl Show for JsValue with to_string(self) {
  if self.is_undefined() {
    "undefined"
  } else if self.is_null() {
    "null"
  } else {
    ffi_to_string(self)
  }
}

Observing Values MoonBit Generates

Here's the FFI correspondence table from MoonBit to JS:

String =>   string
Bool    => boolean
Int, UInt, Float, Double => number
BigInt  => bigint
Bytes   => Uint8Array
Array[T] => Array<T>
Function => Function

These types need no conversion and can be passed directly to JS.

Let's observe them in practice. println() goes through MoonBit's to_string making it hard to inspect JS values, but passing directly to console.log shows actual values.

Define a function like this to get console.log output via FFI:

extern "js" fn ffi_console_log(v : Array[JsValue]) -> Unit =
  #|(obj) => console.log(...obj)

///|
pub fn[T] log(v : T) -> Unit {
  ffi_console_log([v |> unsafe_cast])
}

Pass any T through unsafe_cast to display directly. This lets you see what instances look like inside MoonBit.


///|
fn main {
  struct Point {
    x : Int
    y : Int
  }
  log("hello")
  log(1)
  log(3.14)
  log(true)
  let b1 : Bytes = b"abcd"
  log(b1)
  log(fn() {  })
  log([1, 2, 3])
  log(Point::{ x: 10, y: 20 })
  let mut maybe_value : Int? = Some(42)
  log(maybe_value)
  maybe_value = None
  log(maybe_value)
}

Output:

hello
1
3.14
true
Uint8Array(4) [ 97, 98, 99, 100 ]
[Function (anonymous)]
[ 1, 2, 3 ]
{ x: 10, y: 20 }
42
undefined

Great that struct is also supported.

This means these primitives can be treated equivalently between JS and MoonBit.

Objects That Don't Convert Directly

Objects other than these - like enum, Map, Result, Json - expose MoonBit's internal representation:

fn main {
  enum Color {
    Red = 0
    Green
    Blue
  }
  enum Color2 {
    RGB(r~ : Int, g~ : Int, b~ : Int)
    HSL(h~ : Int, s~ : Int, l~ : Int)
  }
  let result : Result[Int, String] = Ok(42)
  log(result)
  log(Color::Red)
  log(Color2::RGB(r=255, g=0, b=128))
  let show : &Show = "hello"
  log(show)
  let map = { "one": 1, "two": 2, "three": 3 }
  log(map)
  let json : Json = {
    "name": "Alice",
    "age": 30,
    "isStudent": false,
    "scores": [85, 90, 95],
    "address": { "street": "123 Main St", "city": "Wonderland" },
  }
  log(json)
}

Output:

Result$Ok$0$ { _0: 42 }
0
$36$mizchi$47$js$47$examples$47$js$45$output$46$42$main$46$Color2$RGB {
  _0: 255,
  _1: 0,
  _2: 128
}
{
  self: 'hello',
  method_0: [Function: moonbitlang$core$builtin$$Show$output$1$],
  method_1: [Function: moonbitlang$core$builtin$$Show$to_string$1$]
}
// ... (Map and Json internal structures)

These should not be passed directly via FFI.

enum: Only const enums output as constants; otherwise wrapped as MoonBit objects
Parameterized enums don't preserve key names
Trait objects become {self: value, method_0:..., method_1: ...} format
Map type uses MoonBit's internal storage object
Json type is MoonBit's internal Json representation

Implementing get, set, and Function Calls on JsValue

You could write extern "js" for each function call, but that means writing lots of string literals per extern. We also want escape hatches when APIs are missing.

Let's define basic operations on JS values: property access (o[k]), property assignment (o[k]=v), and function calls (o[k](...args)):


///|
#alias("_[_]")
pub extern "js" fn JsValue::get(self : Self, key : String) -> JsValue =
  #| (o,k) => o[k]

///|
#alias("_[_]=_")
pub extern "js" fn JsValue::set(
  self : Self,
  key : String,
  value : JsValue,
) -> Unit =
  #| (o,k,v) => o[k] = v

///|
pub extern "js" fn JsValue::call(self : Self, args : Array[JsValue]) -> JsValue =
  #| (v, a) => v(...a)

///|
pub extern "js" fn JsValue::call_method(
  self : Self,
  key : String,
  args : Array[JsValue],
) -> JsValue =
  #| (o, k, a) => o[k](...a)

///|
fn main {
  let p = new_object()
  p["x"] = 10 |> unsafe_cast
  p["y"] = 20 |> unsafe_cast
  log(p) // => { x: 10, y: 20 }
  log(p["y"]) // => 20
  log(p.call_method("hasOwnProperty", ["x" |> unsafe_cast])) // => true
}

Now we can access, assign, and call property methods.

This doesn't verify whether the target is callable. You could define separate JsObject, JsFunction etc. external types for strictness, but for internal library use and as an escape hatch API, I consider this sufficient.

Use these functions to operate on most JS objects and implement library/environment bindings.

Example: Calling Math.sqrt

Reference the Math object from globalThis and call its sqrt function:


///|
pub extern "js" fn global_this() -> JsValue =
  #| () => globalThis

///|
fn main {
  let r = global_this().get("Math").call_method("sqrt", [16 |> unsafe_cast])
  log(r) // 4
}

MoonBit has builtin arithmetic functions, but depending on implementation, going through FFI may result in smaller build sizes.

Example: Calling fs.readFileSync in Node Environment

moon run --target js runs in Node.js, so calling require() gets external modules. (This obviously depends on node_modules state.)


///|
pub extern "js" fn require(name : String) -> JsValue =
  #| (name) => require(name)

///|
fn main {
  // Cast to function
  let readFileSync : (String, String) -> String = require("node:fs").get(
      "readFileSync",
    )
    |> unsafe_cast
  let content = readFileSync("moon.mod.json", "utf-8")
  log(content)
}

This covers basic MoonBit<=>JS bindings.

Implementing JsValue Conversion with Traits

You can use unsafe_cast extensively, but creating a trait for casting to JsValue is convenient:


///|
pub(open) trait ToJs {
  to_js(Self) -> JsValue
}

///|
/// Example implementing to_js for String
pub impl ToJs for String with to_js(self) -> Val {
  self |> unsafe_cast
}

///|
/// Example implementing ToJs for custom types
struct MyStruct {
  value : Int
}

///|
pub impl ToJs for MyStruct with to_js(self) {
  self.value |> unsafe_cast
}

///|
/// Helper function to convert structs implementing ToJs to JsValue
pub fn js(val: &ToJs) -> JsValue {
  val.to_js()
}
// let v = js("hello")
// let v2 = js(MyStruct::{value: 1})

https://github.com/mizchi/js.mbt/blob/main/src/trait.mbt

Using to_js to call the previously implemented call_method makes implementation easier.

Example implementing bindings for querySelector:


///|
#external
pub type Element

///|
pub impl ToJs for Element with to_js(self) -> JsValue {
  self |> unsafe_cast
}

///|
pub fn Element::query_selector(self : Self, selector : String) -> Self? {
  self.to_js().call_method("querySelector", [selector |> unsafe_cast]) |> unsafe_cast
}

It's full of unsafe_cast, but I accept this as necessary.

Early TypeScript was also full of any. What matters is that the final library user sees natural types, and there are escape hatches when APIs are insufficient.

How strictly to cast is up to the implementer's judgment. After-the-fact jsonschema and TypeScript type definitions have similar challenges.

Interim Summary

Simple types generate JS with TypeScript type definitions
#external type MyType represents values outside FFI
Defining primitive FFI operations like get/set/function calls enables arbitrary JS operations through their combination
Ultimately cast with %identity (that's all)
Once correctly cast, you can operate in MoonBit's clean world

That said, you'll feel language limitations while writing. Here are my current concerns for FFI:

Can't use generics on extern "js" fn
Can't use type parameters on traits (no Rust impl where equivalent)
Can't express variadic arguments
Converting from TS requires re-casting with enum since there's no Union type
No directive to restrict FFI-safe objects when mapping FFI responses to structs (no #external struct)
Reserved words like type, ref often collide with property names, requiring casting workarounds
unsafe_cast passes trait objects {self: value, method_0: ...} as-is (can't set trait bounds)
FFI expands as function expressions, so top-level imports aren't possible
- I submitted a request and was told this will be implemented soon

Advanced: Exceptions and Async

Diving into exceptions and async becomes difficult without MoonBit familiarity. The specification isn't stable yet, so proceed with caution.

This corresponds to mizchi/js/async in js.mbt:

https://github.com/mizchi/js.mbt/tree/main/src/async

Exception and Async Specification

First, let's understand MoonBit's async representation:

https://docs.moonbitlang.com/en/latest/language/async-experimental.html


///|
/// `run_async` spawn a new coroutine and execute an async function in it
fn run_async(f : async () -> Unit noraise) -> Unit = "%async.run"

///|
/// `suspend` will suspend the execution of the current coroutine.
/// The suspension will be handled by a callback passed to `suspend`
async fn[T, E : Error] suspend(
  // `f` is a callback for handling suspension
  f : (
    // the first parameter of `f` is used to resume the execution of the coroutine normally
    (T) -> Unit,
    // the second parameter of `f` is used to cancel the execution of the current coroutine
    // by throwing an error at suspension point
    (E) -> Unit,
  ) -> Unit,
) -> T raise E = "%async.suspend"

///|
#external
type JSTimer

///|
extern "js" fn js_set_timeout(f : () -> Unit, duration~ : Int) -> JSTimer =
  #| (f, duration) => setTimeout(f, duration)

///|
async fn sleep(duration : Int) -> Unit raise {
  suspend(fn(resume_ok, _resume_err) {
    js_set_timeout(duration~, fn() { resume_ok(()) }) |> ignore
  })
}

fn main {
  run_async(() => {
    log("Start sleeping...")
    sleep(1000) catch {
      e => log("Sleep error: " + e.to_string())
    }
    log("Awake!")
  })
}
/// Start sleeping...
/// Awake!

It's a format of wrapping and calling %async.suspend and %async.run in specific ways. (Note: the interface changed when exceptions were introduced and things broke, so be careful.)

Think of suspend as similar to JS's new Promise((resolve, reject) => {...}) interface.

Looking at the async-related parts of the output code:

const mizchi$js$examples$js$45$output$$js_set_timeout = (f, duration) => setTimeout(f, duration);

function mizchi$js$examples$js$45$output$$sleep(duration, _cont, _err_cont) {
  mizchi$js$examples$js$45$output$$js_set_timeout(() => {
    _cont(undefined);
  }, duration);
}
// ... (async driver code)

Looking at the sleep function with async attribute, _cont and _err_cont are added beyond the declared arguments. This transforms into continuation-passing style via callbacks.

This means MoonBit's try-catch and async don't correspond to JS's try-catch or Promise.

So what should you do? The following article introduces wrapping with MoonBit callbacks:

https://www.moonbitlang.com/pearls/moonbit-jsffi

Based on that, I'll implement:

extern "js" fn Error_::wrap_ffi(
  op : () -> Value,
  on_ok : (Value) -> Unit,
  on_error : (Value) -> Unit,
) -> Unit =
  #| (op, on_ok, on_error) => { try { on_ok(op()); } catch (e) { on_error(e); } }

Implementing Synchronous Exceptions

Applying the above article to JsValue:


///|
suberror JsError JsValue

///|
pub fn JsValue::call_method_raise(
  self : JsValue,
  key : String,
  args : Array[JsValue],
) -> JsValue raise JsError {
  let mut res : Result[JsValue, JsValue] = Ok(undefined())
  let op = () => self.call_method(key, args)
  ffi_wrap_call(op, fn(v) { res = Ok(v) }, fn(e) { res = Err(e |> unsafe_cast) })
  match res {
    Ok(v) => v
    Err(e) => raise JsError(e)
  }
}

fn main {
  try undefined().call_method_raise("nonExistentMethod", []) |> ignore catch {
    JsError(e) => log("Caught JsError: " + e.to_string())
  }
}
// Caught JsError: TypeError: Cannot read properties of undefined (reading 'nonExistentMethod')

suberror declares an error type. It takes JsValue as an argument, which should usually be a JS Error instance.

In main we intentionally call undefined.nonExistentMethod() to trigger a JS TypeError. The "Caught JsError:" prefix shows it was caught by MoonBit's try-catch.

Using call_method_raise everywhere while propagating raise is tedious, but accepting some panics and using it selectively in contexts expecting errors like JSON.parse works well.

Async with Non-Synchronous Exceptions

You could extend JsValue, but let's add a new type Promise[T].

We'll wrap Promise callbacks using the earlier suspend function. Design it so Promise[T].unwrap() becomes T raise JsError.

(This code is quite complex. Check the final main function to get the gist.)


///|
pub extern "js" fn ffi_promise_then(
  promise : Promise[JsValue],
  on_fulfilled : (JsValue) -> Unit,
  on_rejected? : (JsValue) -> Unit,
) -> Promise[JsValue] =
  #|(p, ok, err) => p.then(ok).catch(err)

///|
/// Promise abstraction
#external
pub type Promise[T]

///|
pub async fn[T] Promise::unwrap(self : Self[T]) -> T raise JsError {
  suspend((resume_ok, resume_err) => ffi_promise_then(
      self |> unsafe_cast,
      v => resume_ok(v |> unsafe_cast) |> ignore,
      on_rejected=e => resume_err(JsError(e |> unsafe_cast)) |> ignore,
    )
    |> ignore)
}

///|
/// Test function: returns doubled value after 300ms
extern "js" fn lazy_double(v : Int) -> Promise[Int] =
  #| (v) => new Promise((resolve) => setTimeout(() => resolve(v*2), 100))

///|
fn main {
  run_async(() => try {
    let v : Int = lazy_double(21).unwrap()
    assert_eq(v, 42)
  } catch {
    JsError(e) => log(e.to_string())
    _ => panic()
  })
}

Referenced https://github.com/moonbit-community/jmop for implementation.

Converting MoonBit Async Functions to Promises

Sometimes you need to pass Promise-wrapped callback functions to JS. For example, React's useActionState has useActionState(reducer: (state: S, a: Action) => Promise<S>, initial: S): [S, (action: A) => void], which requires Promise wrapping rather than passing async functions directly.

For this, prepare utility functions to wrap MoonBit async functions as JS Promise functions.

Since MoonBit lacks variadic arguments, I define promisifyN functions up to 3 arguments:


///|
extern "js" fn ffi_promise_with_resolvers() -> JsValue =
  #| () => Promise.withResolvers()

///|
pub(all) struct Resolvers[T] {
  promise : Promise[T]
  resolve : (T) -> Unit
  reject : (Error) -> Unit
}

///|
pub fn[T] Promise::with_resolvers() -> Resolvers[T] {
  ffi_promise_with_resolvers() |> unsafe_cast
}

///|
pub fn[R] promisify0(f : async () -> R) -> () -> Promise[R] noraise {
  () => {
    let { promise, resolve, reject } = Promise::with_resolvers()
    run_async(() => try f() |> resolve catch {
      e => reject(e)
    })
    promise
  }
}

///|
pub fn[A, R] promisify1(f : async (A) -> R) -> (A) -> Promise[R] noraise {
  fn(a) {
    let { promise, resolve, reject } = Promise::with_resolvers()
    run_async(() => try f(a) |> resolve catch {
      e => reject(e)
    })
    promise
  }
}

// promisify2 and promisify3 follow same pattern...

I wanted to use T raise? for callbacks to infer raise/noraise, but encountered compiler crashes, so I'm using noraise for now. Explicitly try-catch inside functions.

MoonBit: A Modern Language for WebAssembly/JS/Native

mizchi (Kotaro Chikuba) — Wed, 24 Dec 2025 06:19:37 +0000

Are you frustrated with TypeScript inheriting JavaScript's quirks - no integer types, type erasure at runtime, no pattern matching? Or that Rust is too low-level for writing application-layer code?

MoonBit is a language that addresses these frustrations. It's a statically-typed programming language designed for WebAssembly, with multiple backend targets including wasm-gc, JavaScript, and native. Think of it as Rust with garbage collection - you get Rust-like syntax and safety without the complexity of lifetime management.

https://www.moonbitlang.com/

This article provides a comprehensive introduction to MoonBit, including my hands-on experience building React SPAs with it. The caveat is that, for now, you need to be prepared to write some things yourself without relying heavily on the ecosystem.

https://github.com/mizchi/js.mbt

Here's a taste of what JS interop looks like with my library:

fn main {
  // Get DOM element and modify it
  let doc = @dom.document()
  let el = doc.createElement("div")
  el.setId("app")
  el.setTextContent("Hello from MoonBit!")
  doc.body().appendChild(el)

  // Add event listener
  el.addEventListener("click", fn(_ev) {
    @js.console_log("Clicked!")
  })
}

tl;dr

What Makes MoonBit Great:

Rust-like syntax with GC - easy to learn, no lifetime complexity
Pattern matching and algebraic data types (enums)
Expression-oriented (if, match, for are expressions)
F#-style pipeline operator (|>)
Explicit side-effect control and exception handling
Built-in JSON type with pattern matching
Multiple backends: wasm-gc, JavaScript, native
Built-in test runner with inline snapshot testing
Small generated code size - realistic for npm-publishable libraries
Complete toolchain: LSP, formatter, package manager

Current Limitations:

Still in beta - expect breaking changes (1.0 planned for 2026)
Limited ecosystem and third-party libraries
Async runtime is being integrated into core
Requires developer capability to fill gaps

Why MoonBit?

Limitations of TypeScript

TypeScript, being built on JavaScript, has fundamental constraints:

No distinction between integers and floats (everything is Number)
Types are erased at transpile time - the compiler can't use them for optimization
No pattern matching
Objects used as records lead to patterns like type: "discriminator" everywhere

Rust is Too Low-Level for Applications

Rust excels at systems programming, but lifetime management creates friction for GUI/frontend development. Consider this requestAnimationFrame example with wasm-bindgen:

#[wasm_bindgen(start)]
fn run() -> Result<(), JsValue> {
    let f = Rc::new(RefCell::new(None));
    let g = f.clone();
    *g.borrow_mut() = Some(Closure::new(move || {
        // ... lifetime complexity everywhere
        request_animation_frame(f.borrow().as_ref().unwrap());
    }));
    request_animation_frame(g.borrow().as_ref().unwrap());
    Ok(())
}

MoonBit offers Rust's expressiveness without this overhead.

Installation

Try it in the browser first:

https://try.moonbitlang.com/

For local development:

https://www.moonbitlang.com/download/

# macOS / Linux
curl -fsSL https://cli.moonbitlang.com/install/unix.sh | bash

# Upgrade
moon upgrade

Install the VS Code extension for LSP support:

https://marketplace.visualstudio.com/items?itemName=moonbit.moonbit-lang

Quick Start

Create and run a project:

$ moon new hello
$ cd hello
$ moon run main
Hello, World!

Language Basics

Functions and Pipelines

fn add(a: Int, b: Int) -> Int {
  a + b // last expression is returned
}

test "pipeline" {
  // Pipeline passes result as first argument
  let result = 1 |> add(2) |> add(3)
  assert_eq(result, 6)
}

Structs with Labeled Arguments

struct Point {
  x: Int
  y: Int
} derive(Show, Eq)

// Labeled argument (x~), optional with default (y~)
fn Point::new(x~: Int, y~ : Int = 0) -> Point {
  { x, y } // shorthand for Point { x: x, y: y }
}

test "struct" {
  let p = Point::new(x=10, y=20)
  assert_eq(p.x, 10)

  // inspect provides inline snapshot testing
  // Run `moon test -u` to update the content
  inspect(p, content="{ x: 10, y: 20 }")
}

Having inline snapshots built into the language from the start is remarkably convenient. derive(Show) auto-implements to_string, and unused code tracking warns you about unused functions.

Enums as Algebraic Data Types

enum Shape {
  Circle(radius~ : Double)
  Rectangle(width~ : Double, height~ : Double)
}

fn area(shape: Shape) -> Double {
  match shape {
    Circle(radius~) => 3.14159 * radius * radius
    Rectangle(width~, height~) => width * height
  }
}

test "enum" {
  let circle = Shape::Circle(radius=5.0)
  inspect(area(circle), content="78.53975")
}

Pattern matching lets you extract and process values simultaneously.

Error Handling

MoonBit uses explicit error declarations with raise:

// Declare error type
suberror DivError

fn div(a: Int, b: Int) -> Int raise DivError {
  if b == 0 {
    raise DivError
  }
  a / b
}

test "error handling" {
  let result = try {
    div(10, 2)
  } catch {
    DivError => -1
  }
  assert_eq(result, 5)
}

Functions that can raise errors must explicitly declare it, and callers must handle them.

Async Support

MoonBit uses a coroutine-based approach similar to Kotlin. Async functions are declared with the async keyword and implicitly raise errors.

Two core primitives:

%async.run: Spawn and run a new coroutine
%async.suspend: Suspend the current coroutine, with resume managed via callback

Here's how to implement a sleep function by wrapping JavaScript's setTimeout:

// Declare external JS function
extern "js" fn js_set_timeout(f : () -> Unit, duration~ : Int) -> Unit =
  #| (f, duration) => setTimeout(f, duration)

// Wrap as async function
async fn sleep(ms : Int) -> Unit {
  await %async.suspend(fn(resume_ok, _resume_err) {
    js_set_timeout(fn() { resume_ok(()) }, duration=ms)
  })
}

async fn main {
  await sleep(1000)
  println("Done!")
}

For Promise integration, pass resume_ok as the resolve callback and resume_err as reject. The compiler tracks async-ness statically, and async function calls are shown in italics in the IDE.

For Loops and Iterators

test "loops" {
  let arr = [1, 2, 3, 4, 5]
  let mut sum = 0

  // For-in loop
  for x in arr {
    sum += x
  }
  assert_eq(sum, 15)

  // Functional style
  let doubled = arr.map(fn(x) { x * 2 })
  inspect(doubled, content="[2, 4, 6, 8, 10]")
}

Build Targets

MoonBit supports multiple backends. The wasm-gc target is now part of the WebAssembly baseline - supported in Chrome 119+, Firefox 120+, and Safari 18.2+.

# WebAssembly GC (default, baseline supported)
moon build --target wasm-gc

# JavaScript
moon build --target js

# Native binary
moon build --target native

# Run with specific target
moon run main --target js

# Test all targets
moon test --target all

Set project default in moon.mod.json:

{
  "name": "myproject",
  "preferred-target": "js"
}

Built-in Testing

MoonBit has a powerful built-in test runner:

// Inline tests
test "basic assertion" {
  assert_eq(1 + 1, 2)
}

// Snapshot testing - run `moon test -u` to update
test "snapshot" {
  let data = [1, 2, 3].map(fn(x) { x * x })
  inspect(data, content="[1, 4, 9]")
}

Run tests:

moon test              # Run all tests
moon test -u           # Update snapshots
moon test --target js  # Test JS backend

Package Management

MoonBit uses mooncakes.io as its package registry:

# Add a package
moon add username/package

# Publish your package
moon publish

Import packages in moon.pkg.json:

{
  "import": [
    "moonbitlang/x/json"
  ]
}

Use in code with @ prefix:

fn main {
  let json : Json = @json.parse("{\"key\": \"value\"}").unwrap()
  println(json.stringify())
}

Packages from the core team and active contributors (moonbitlang org and recognized maintainers) tend to be of high quality. Older packages may be broken due to ongoing language evolution.

moon CLI Features

The moon command provides many useful features:

moon check              # Type check with lint warnings
moon check --deny-warn  # Treat warnings as errors (for CI)
moon fmt                # Format code
moon doc Array          # Show type documentation
moon info               # Generate type definitions
moon coverage analyze   # Coverage report
moon bench              # Run benchmarks

Learning Resources

Official Tour

Interactive tutorial covering the basics:
https://tour.moonbitlang.com/

Language Documentation

Comprehensive language reference:
https://docs.moonbitlang.com/en/latest/language/index.html

Weekly Updates

The most reliable source for new features:
https://www.moonbitlang.com/weekly-updates/

Source Code

Both the compiler and CLI are open source:

Compiler (OCaml): https://github.com/moonbitlang/moonbit-compiler
CLI (Rust): https://github.com/moonbitlang/moon
Core library: https://github.com/moonbitlang/core

Practical Examples

Computer science topics implemented in MoonBit:
https://www.moonbitlang.com/pearls/

My Hands-on Experience

After building React SPAs and various tools in MoonBit, here's what I've found:

The Good:

The LSP toolchain is solid. Pattern matching and pipelines make coding enjoyable.
Among OCaml/F#/Haskell, MoonBit is the only one that gave me the same toolchain confidence as TypeScript or Rust.
Type inference allows writing complex code concisely.

The Challenges:

Type inference can make code harder to read - similar to heavily pattern-matched Haskell.
Explicit exceptions feel complex in practice. Wrapping in raise/noraise functions takes getting used to.
Design requires thinking in Rust-style traits and enums rather than TypeScript-style unions.
No higher-kinded types yet - traits can't take type parameters, limiting abstractions like Functor or Monad.
LSP can become unstable when heavily using extern for FFI and switching backends.

Project Structure Notes:

All directories are controlled with moon.pkg.json (migrating to moon.pkg DSL). Files in a directory share the same namespace with no file scope.
Imported libraries are accessed with @ prefix: mizchi/js becomes @js.something().

Is It Ready for Production?

Language Specification

Currently in beta, with version 1.0 stable release planned for 2026. Upcoming major changes include:

Iter deprecation in favor of Iterator
moon.pkg.json migration to moon.pkg DSL

Past breaking changes included:

Exception syntax: ()-> T!E → ()->T raise E
Import syntax: fnalias → using statements

However, moon fmt automatically converts old syntax, and deprecations happen gradually with warnings. Compared to early beta, breaking changes have become much less frequent - MoonBit is now a practically usable language.

Async Runtime

The official moonbitlang/async library provides an async runtime similar to Rust's tokio. It wraps Unix system calls at a low level and works with the native backend. This library is planned to be integrated into the core language.

async test {
  @async.sleep(100)
}

Currently async test works with --target native. The team is also working on --target js support.

Conclusion

MoonBit fills a unique niche: the expressiveness of Rust without lifetime complexity, targeting WebAssembly as a first-class citizen. The toolchain is polished, the language design is thoughtful, and the generated code is impressively small.

If you don't mind some churn from specification changes and ecosystem evolution, MoonBit is worth investing in now. What's lacking is the ecosystem, but that's a chicken-and-egg problem. I'm addressing it by writing JS bindings while waiting for adoption to grow.

About This Article

Written in December 2024. MoonBit is evolving rapidly - check the weekly updates for the latest changes.

I usually write articles in Japanese, but I wanted to introduce MoonBit to a broader audience. Despite its potential, I rarely see MoonBit mentioned on dev.to, X (Twitter), or other tech communities outside of Asia - which feels like a missed opportunity. The community is small but growing, and the development team is very responsive to feedback.

If you find MoonBit interesting, I encourage you to try it out and join the community:

Discord: https://discord.gg/CVFRavvRav - The most active place for discussions
GitHub Issues: https://github.com/moonbitlang/moonbit-docs/issues - Report bugs and request features
Mooncakes: https://mooncakes.io/ - Publish your own packages

The ecosystem needs more libraries and tools. Whether you build something small or contribute documentation, every bit helps. I hope to see you in the community!

Useful Features of MoonBit's moon CLI - Built-in lint, bench, snapshot, coverage, doc

mizchi (Kotaro Chikuba) — Tue, 23 Dec 2025 17:36:02 +0000

Liquid syntax error: 'raw' tag was never closed

Building Incremental Markdown Compiler by Moonbit

mizchi (Kotaro Chikuba) — Sun, 21 Dec 2025 11:22:08 +0000

I've implemented a Markdown Editor for about the fifth time in my life.

You can try it here.

https://markdown.mizchi.workers.dev/

Whether it's truly the fastest on Earth is hard to say since there are various axes of performance, but at least from the perspective of incremental compilation in an editor, I don't think it loses to anything else. (Benchmarks are later in this article)

I may be saying this myself, but it's incredibly fast. Since it uses differential compilation, it can handle large amounts of text. The automatic synchronization between preview and editing is convenient. Even when I threw 20,000 characters at it, there was no display lag and it maintained 60fps.

It's a pure Moonbit implementation without FFI, so it can be used as a library in js/wasm/native environments.

So, I'm writing this article to show everyone the potential of Moonbit implementation. The js build has also been published to npm as @mizchi/markdown, which is used in the playground above.

https://github.com/mizchi/markdown.mbt

https://www.npmjs.com/package/@mizchi/markdown

However, I should mention upfront that CommonMark (the Markdown standard test suite) compliance is a modest 207/542. The reason is that I skipped parts that were difficult to optimize in benchmarks.

That said, the failing cases are mostly nested patterns like *foo [bar](/url)*\n or _____foo_____\n, which I judged to be not problematic for practical use. Instead, I've added more support for GitHub Flavored Markdown extensions like - [x] Tasklists, tables, and footnotes. Those are in higher demand anyway.

The Basic Idea: Building CST Based on Cursor Position

One of the problems with Markdown Editors (and text editors in general) is that the entire text needs to be reparsed with every user input. To maintain 60fps you need to parse and reflect the entire text in under 16ms, and for 120fps it needs to be under 8ms.

With a naive implementation, performance degrades linearly with text size. So what do we do?

First, I decided to adopt CST. This is a data structure used in Tree Sitter and others, and unlike AST, it's a data structure that preserves the original input without losing it.

https://docs.rs/cstree/latest/cstree/

And for the idea of solving differential updates, this article was extremely helpful.

https://josephg.com/blog/crdts-go-brrr/

(This article is really interesting, so please read it)

Here, instead of thinking about programming language parsers, let's think from the perspective of CRDT for collaborative editing. Generally, for simultaneous editing like Google Docs, a data structure/algorithm called CRDT, Conflict-free replicated data type, is used.

https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type

Essentially, it's a structure like a Git branch that can always be merged with FastForward, where change patches are sent back and forth and continuously merged. This allows multiple people to edit simultaneously without locking, even in unsynchronized environments.

The JS implementation of this is yjs, and the CRDTs Go Brrr article is about making a Rust implementation 5000x faster.

I'll skip the detailed techniques, but the content is roughly:

yjs creates a lot of objects on each parse, causing memory fragmentation in JS(V8). This was addressed by allocating efficient data structures
- It's not impossible with ArrayBuffer(Uint8Array) in JS, but it would probably be difficult
For input, reparse based on the edit point, and only rebuild the syntax tree for the parts before and after where changes occurred

Checking only before and after the input is quite heuristic, but it's actually a very effective approach.

Setting aside memory fragmentation, rebuilding the Markdown CST for changes is the key to this implementation.

Identify edit position: EditInfo { offset, old_length, new_length }
Calculate affected range: Identify blocks containing changed lines
Reuse decision: Blocks before the change → reuse as-is
Partial parse: Reparse only blocks containing changes
Merge: Reused blocks + new blocks + subsequent blocks (span adjustment)

// Calling incremental parse
let edit = EditInfo::replace(change_start, old_len, new_len)
let new_doc = parse_incremental(old_doc, old_text, new_text, edit)

Implementing This

So, I built it.

https://github.com/mizchi/markdown.mbt

The actual implementation process was:

Discuss with ChatGPT 5.2 to do preliminary research on algorithms and confirm my understanding
Expand the tests from https://spec.commonmark.org/ into test cases with a script
Create a mechanism to give the same input as remark as a reference implementation and check if the output matches
Have Claude Code read the CRDTs Go brrr article as a reference and verify the algorithm's effectiveness with benchmarks on simple test cases
mizchi: "Do it" Claude Code: "Yes"
Occasionally check failing test cases and prioritize fixes
Periodically take benchmarks to confirm nothing has gotten slower
Let it do things to some extent, but keep implementation decisions in my own hands

Moonbit has a built-in moon bench benchmark command.

https://docs.moonbitlang.com/en/latest/language/benchmarks.html

Once the compiler was mostly complete, I quickly integrated it with preact + vite in the JS build and it was done.

https://markdown.mizchi.workers.dev/

Actual Benchmarks

I prepared small, medium, and large document sizes and compared them with cmark (also Moonbit implementation) and markdown-rs (Rust implementation).

Comparison with Different Libraries

μs/iter, smaller is better.

Parser	Target	small	medium	large
mizchi/markdown	WASM-GC	125	291	1329
rami3l/cmark	WASM-GC	46	120	416
markdown-rs	Rust	202	621	3674

Unfortunately I couldn't beat cmark, but it's faster than markdown-rs. However, these two implementations should be CommonMark compliant, so it's frustrating to lose while cutting corners. cmark is apparently a port of an OCaml implementation, but it's quite fast.

https://github.com/moonbit-community/cmark.mbt

Comparison by Build Target

Next, let's compare mizchi/markdown and cmark mixed across different build targets.

Parser	Target	small	medium	large
mizchi/markdown	JS	134	356	1870
mizchi/markdown	WASM-GC	125	291	1329
mizchi/markdown	Native	81	315	1547
rami3l/cmark	JS	79	195	854
rami3l/cmark	WASM-GC	46	120	416
rami3l/cmark	Native	26	105	513
markdown-rs	Rust Native	202	621	3674

The trend of mizchi/markdown being 2-3x slower than cmark is the same.

Looking at Moonbit backends, Native is faster for small sizes, but the gap with JS narrows as the volume increases. I imagine this is due to V8's JIT.

It's unexpected that wasm is faster. I had the impression that wasm is about 1.5-2x slower than native for the same implementation due to memory barriers, but it's possible Moonbit's native optimization level is lower.

Incremental Parse Benchmarks

This is the main topic. We measure how many μs each parser takes when editing one character in the editor.

Parser	Method	50 paragraphs	100 paragraphs
mizchi/markdown	Incremental	10	10
mizchi/markdown	Full	210	386
rami3l/cmark	Full	146	433
markdown-rs (Rust)	Full	621	3674

mizchi/markdown's incremental parse completes in about 10μs regardless of document size.

Comparing with a 100-paragraph document:

mizchi/markdown (incremental): 10 μs
rami3l/cmark (full): 433 μs → 43x slower
markdown-rs (full): 3674 μs → 367x slower

cmark is fastest for full parse, but for editor real-time preview use cases, incremental parse wins overwhelmingly. Well, that's what I built it for, so it's expected...

mizchi/markdown's full parse is somewhat slow, but from the second edit onwards it only calculates differences, so the actual editor experience is the fastest. The effect grows as documents get longer, and incremental parse complexity approaches O(1).

I think the CST data construction processing overhead is why I'm losing to cmark, but I decided to accept it as a necessary cost.

Once I tuned it this far, as far as Chrome DevTools benchmarks show, the browser's renderer side became the bottleneck rather than JS. The solution would be implementing a virtual table like react-virtualized, but that's a future task.

Thoughts on Moonbit x AI

I really felt that vibe coding performs best when reference implementations and tests are sufficiently prepared. The CommonMark reference collection was a huge help.

It seems that designing APIs and test cases for each module is becoming what humans focus on.

Even if you can't write algorithm details from scratch, it's really important to know how they should behave, and to create mechanisms to get quantitative numbers through benchmarks, and use unambiguous metrics like test coverage. With quantitative metrics to aim for, human intervention decreases and bottlenecks are reduced. Also, compiler error hints and linting richness matter.

AI x Moonbit has insufficient training data so it repeatedly makes syntax mistakes in early stages, but since the compiler error quality is excellent, it gets smarter with long context. Moonbit code itself is concise and readable, making review easy too.

That said, I feel like I spent more time reviewing test cases in unit tests than reviewing implementations. I have a feeling this is how programming will go in the future.

Moonbit's Cross-Target Performance

Since it's developed specialized for wasm-gc, the wasm backend performance is excellent. On the other hand, I thought native could do a bit better.

Even as a TypeScript replacement, the build size is small enough to be practical. Using Map or Double::to_string hits built-in library spots and increases build size, so avoiding that is somewhat tricky.

Bundle size is the most important thing in today's JS frontend, and although I wasn't conscious of it during development, the output was about 92k minified, 20k gzipped. Smaller than remark (112k), larger than marked (42k). It should get even smaller with treeshaking.

The End

I think Moonbit is the best language for someone like me who mainly uses TypeScript and has dabbled a bit in Rust, for use across layers.

Pure Moonbit implementation lets you choose the runtime platform, which is great. Problems I had while writing in TS where I wished I could port to native have been almost completely solved.

The abstraction level is just right - lifetimes and low-level binary operations that frequently appear in Rust are hidden, allowing high-level descriptions, making it optimal not just for systems programming but also for the application layer.

However, to speed things up further I'd want multithreading, and it's a shame Moonbit doesn't support this yet. When I asked the author, they said it won't be possible in the stable 1.0 release planned for next year, but they want to consider it by 2.0.

So everyone, please write Moonbit. It's the best language.

All in on CLINE

mizchi (Kotaro Chikuba) — Sun, 02 Mar 2025 08:54:26 +0000

This is a translation of an article written by a Japanese Node.js engineer. Original source: https://zenn.dev/mizchi/articles/all-in-on-cline

I've been using Cline for about 2 months now.

My intuition tells me that Cline is both the gateway to true innovation and a Pandora's box that should not be opened.

When I refer to Cline here, I'm talking about Cline-type coding agents, which broadly includes tools like Devin, Cursor, and Copilot Agent. However, as I'll explain later, there's a world that only Cline can show us.

I'm going to talk about why I'm all in on this future as a programmer.

The End of Programming as We Know It

Everything important is already written in the following article. Please read this first:

https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/

Steve Yegge points out that it's not junior and mid-level programmers who will be replaced, but programmers who refuse to embrace new programming tools and paradigms and cling to the past.
[...]
This isn't the end of programming. It's the beginning of its latest reinvention.

https://steve-yegge.medium.com/the-death-of-the-stubborn-developer-b5e8f78d326b

I want you to feel the weight of this statement coming from Tim O'Reilly himself.

AI and Programmers Are Now Truly on the Same Playing Field

At its core, Cline is simply a "programming editor running in headless mode" like VSCode.

Cline references environmental information just like human programmers do. It runs code, absorbs the logs, and makes corrections.

However, I feel there's been a fundamental change in this workflow when working with Cline. Cline has strong (and dangerous) execution permissions, and this cycle is overwhelmingly faster than before. This speed drastically transforms the AI programming experience.

I've used Cursor's YOLO mode for command execution permissions, but the experience was more like an extension of Copilot, generally respecting human decision-making.

Cline is like a runaway train, seemingly indifferent to human input beyond the initial instructions. As a result, it achieves a speed that can't be realized any other way, and I can't bear to work without it now. Honestly, it's quite addictive.

This kind of magical power didn't exist in Copilot or Cursor. That's why I use Cline, or more specifically, Roo Code, which is a fork of it.

Perhaps human assumptions have unconsciously imposed constraints until now. Only Cline, freed from these shackles, is showing me the future. I really want you to try it.

How (In)competent Is AI at Programming?

For most professional programmers, the general perception is that AI is poor at programming.

In fact, I too think it's not particularly smart when it comes to "simple" coding performance. The current smartest model, Claude-3.7-sonnet, is probably at the level of a second-year new graduate.

However, I've come to realize that this may have been unfairly underestimated due to the information asymmetry between AI and humans. When you feed data to Cline, you can clearly observe its performance improving. Perhaps it was simply a lack of information until now.

Cline has solved this problem. The result is an overwhelming coding speed, albeit with the caveat that it's within AI's areas of expertise.

Ultimately, humans also have to write code through trial and error in PDCA cycles, but Cline's speed of iteration is reaching a level that no expert can compete with.

Let Cline Do What It's Good At

When I give instructions, it can write about 700 lines of code that passes tests in about 15 minutes.

For example, I had it write a function called dig that extracts data from a specific access path in JSON while inferring types.

https://github.com/mizchi/ailab/blob/main/core/dig.ts

export function dig<T, Q extends Query>(
  obj: T,
  query: Q
): DeepValue<T, QueryToArray<Q>> {
  return digUntyped(obj, query) as DeepValue<T, QueryToArray<Q>>;
}
//...

// Unit Tests
import { expect } from "@std/expect";
import { test } from "@std/testing/bdd";

test("dig - string query basic object access", () => {
  const obj = { a: { b: 1 } };
  expect(dig(obj, "a")).toEqual({ b: 1 });
  expect(dig(obj, "a.b")).toBe(1);
});
// ...

And it's passing tests like this:

$ deno test -A dig.ts               
Check file:///home/mizchi/lab/core/dig.ts
running 17 tests from ./dig.ts
dig - string query basic object access ... ok (1ms)
dig - array query basic object access ... ok (0ms)
dig - string query array access ... ok (0ms)
dig - array query array access ... ok (0ms)
dig - string query wildcard ... ok (0ms)
dig - array query wildcard ... ok (0ms)
digUntyped - regex query ... ok (0ms)
digUntyped - object query ... ok (0ms)
digUntyped - $keys query ... ok (0ms)
digUntyped - $values query ... ok (0ms)
digUntyped - $flat query ... ok (0ms)
digUntyped - $pick query ... ok (0ms)
digUntyped - $exclude query ... ok (0ms)
digUntyped - combined special queries ... ok (0ms)
dig - edge cases ... ok (0ms)
digUntyped - basic functionality ... ok (0ms)
dig - type inference ... ok (0ms)

As I was building it, I gave instructions like "structure the query internally," "I want regex support," and "handle nested objects with self-recursion," and had it write tests each time.

This is clearly letting AI do what it's good at:

No external references or context
Confined to a technical domain
Easy to create mock data
Likely has existing implementations

To be honest, I could write this myself, but the significant factor is that it took only about 5 minutes. If I had written this amount myself, it would probably have taken 30 minutes to an hour. It's also easy to develop further - create mock data and make the tests pass. That's exactly the technique of expressing specifications through tests, which will become a more demanded skill.

I think the number of operations is most important, and we've already reached a phase where humans can't compete in terms of those operations.

And you'll realize: human judgment is the bottleneck. This is a realm that only Cline, which doesn't defer to humans, could achieve - a level that Copilot couldn't reach on its own.

Assigning Difficult Tasks: HM Type Inference for JSON

The dig function was a case where the implementation method was obvious, so let me deliberately assign something more difficult.

I want to infer the type from a typeless JSON and create a zod validator from it.

The specific instruction I gave was to first implement a simple HM type inference, then extract types from it and build a zod validator.

Hindley–Milner type system - Wikipedia

https://github.com/colinhacks/zod

https://github.com/mizchi/ailab/blob/main/scripts/json_type_inference.ts

To be honest, I haven't fully developed this, but it's already implemented this far:

///...
test("Inference for nested objects", () => {
  const env = new TypeEnvironment();
  const json = {
    user: {
      id: 1,
      name: "John",
      tags: ["admin", "user"],
    },
  };

  const type = inferTypeFromJson(json, env);
  const typeStr = typeToString(type);
  expect(typeStr).toBe(
    "{ user: { id: number, name: string, tags: string[] } }"
  );
});

It's working well for simple examples. From here, I could just increase the test cases and have it implement them.

At this point, I think there are several things I've learned:

Insights from the user side are essential as prerequisites. Prior knowledge and context are needed:

What can be expressed with the JSON data structure
Knowledge of type inference, specifically HM type inference
How the structures you want to extract can be represented in JSON
Whether applying HM type inference to JSON makes sense

Frankly, I only vaguely understand HM type inference conceptually, so my evaluation is already ambiguous here. However, the test code that uses it seems relatively easy to evaluate. I think we could probably work it out by adding more test cases.

Implementing something I don't fully understand requires a fairly advanced thought process of "intuition about internal structures that can be reverse-engineered from results." I think this is the feeling that non-programmer people have had when asking programmers to do work.

The Decision and Resolve to Hand Over the Driver's Seat

GitHub Copilot was, as the name suggests, merely a passive navigator. As an end-user experience, it felt like the intellisense that suggests sin,cos,tan,PI... when you press Tab after Math.<Tab> had expanded from static analysis method level to (probabilistically) include function call arguments like .sin(Math.PI/n).

That was impressive enough, but Cline is in a completely different dimension. In pair programming terms, Cline is the driver and the user is the navigator. The roles are reversed.

What humans need to consider is whether the problem involves mathematics, algorithms, or libraries that Cline is good at, and if so, let Cline handle it. You can simply say Implement a distance function that calculates the Euclidean distance between two points.

I just tried it:

// Implement a distance function in TS that calculates the Euclidean distance between two points. Also write Deno tests.
/**
 * Calculates the Euclidean distance between two points in n-dimensional space
 * @param point1 First point as an array of numbers
 * @param point2 Second point as an array of numbers
 * @returns The Euclidean distance between the two points
 * @throws Error if the points have different dimensions
 */
export function distance(point1: number[], point2: number[]): number {
  if (point1.length !== point2.length) {
    throw new Error("Points must have the same number of dimensions");
  }

  let sumOfSquares = 0;
  for (let i = 0; i < point1.length; i++) {
    const diff = point2[i] - point1[i];
    sumOfSquares += diff * diff;
  }

  return Math.sqrt(sumOfSquares);
}

import {
  assertEquals,
  assertThrows,
} from "https://deno.land/std/assert/mod.ts";

Deno.test("distance between identical points is 0", () => {
  assertEquals(distance([0], [0]), 0);
  assertEquals(distance([1, 2], [1, 2]), 0);
  assertEquals(distance([5, 5, 5], [5, 5, 5]), 0);
});

Deno.test("distance in 1D space", () => {
  assertEquals(distance([0], [5]), 5);
  assertEquals(distance([10], [5]), 5);
  assertEquals(distance([-5], [5]), 10);
});

Deno.test("distance in 2D space", () => {
  // Distance between (0,0) and (3,4) should be 5 (Pythagorean triple)
  assertEquals(distance([0, 0], [3, 4]), 5);

  // Distance between (1,1) and (4,5) should be 5
  assertEquals(distance([1, 1], [4, 5]), 5);

  // Distance between (-1,-1) and (2,3) should be 5
  assertEquals(distance([-1, -1], [2, 3]), 5);
});

Deno.test("distance in 3D space", () => {
  // Distance between (0,0,0) and (3,4,0) should be 5
  assertEquals(distance([0, 0, 0], [3, 4, 0]), 5);

  // Distance between (1,1,1) and (4,5,1) should be 5
  assertEquals(distance([1, 1, 1], [4, 5, 1]), 5);

  // Custom 3D case
  const result = distance([2, 3, 4], [5, 7, 9]);
  assertEquals(Math.round(result * 100) / 100, 7.07); // Rounded to 2 decimal places
});

Deno.test("throws error when points have different dimensions", () => {
  assertThrows(
    () => distance([1, 2], [1, 2, 3]),
    Error,
    "Points must have the same number of dimensions"
  );
});

This takes about 15 seconds. It takes me a minute to verify it, but the burden is reduced because there are tests.

(I noticed that it's avoiding floating-point ambiguity to make the tests easier to write.)

However, this coding ability depends on the performance of the model you're actually communicating with. My gut feeling is that the probability of a task ultimately succeeding is about 70%, and the probability that the written code meets my quality requirements is about 70%. As a result, the probability of getting usable code is about half.

So my approach is to first let Cline handle areas it's good at, then refactor and modularize it myself.

This has resulted in these scripts:

https://github.com/mizchi/ailab/tree/main/scripts

If I can come up with an approach, I feel like I can write 700 lines in 15 minutes.

What Cline/Claude Struggles With: Context Retention

I take the approach of "implementing a PoC limited to a single file" or "implementation against explicitly referenced libraries/modules." This is because it struggles with resolving references in environments where context isn't explicit.

We know this will be solved as AI model performance improves and context windows expand.

Regarding context retention, there are makeshift strategies like Memory Bank, MCP, and Agentic RAG technologies, but honestly, I can't fully predict whether context windows or summary generation will be the surviving technology. Currently, we can only choose case by case while considering costs.

https://docs.cline.bot/improving-your-prompting-skills/custom-instructions-library/cline-memory-bank

Introducing the Model Context Protocol \ Anthropic

What Programmers Need in the Cline AI Era

I think it can be organized like this:

Ability to describe context
Ability to describe domains
Intuition about AI performance

Other than intuition about AI, these are about appropriate modularization, extraction of bounded contexts, building ubiquitous language, DDD, and the ability to abstract implementation targets as domain experts.

I end up writing quite a lot of instructions in .clinerules, and I feel that being able to build this according to your own abilities is the value of being a domain expert in programming.

https://github.com/mizchi/ailab/blob/main/.clinerules

I recognize that there's a limit to generic prompts, and it's important to prepare documentation summarizing programming languages, implementation targets, and surrounding technologies.

Separately, in the short term, there's a role as an agent that manually corrects AI mistakes and assists while compressing context to reduce costs.

Cline and Programming Language Aptitude

There's also an aptitude for programming languages. At present, Cline functions with a limited set of languages: high-level languages like TypeScript, C#, and Python that are popular, have a lot of learning data, and have static typing support that can check types before execution.

From what I've tried, the presence of static typing directly affects the speed of iteration. TS has a significantly better success rate than JS.

On the other hand, with languages that have strict compiler constraints like Rust/Haskell, the current Claude has a high probability of struggling to pass compilation/tests without the help of a human expert.

(No matter how much instruction I give, it tends to distort the implementation to pass tests, so I have to scold it every time. This behavior is very junior engineer-like.)

For this, we either need to wait for AI model performance improvements or accompany it as experts.

Why This Is a "Pandora's Box"

Cline tries to execute various commands directly to gather environmental information.

There are safeguards like confirming with the user before executing unknown commands and the ability to create allow lists for auto-execution. This is called the Auto Approver mechanism.

However, as you go along, you'll notice the user's confirmation gets more and more lenient. Once you realize that humans are the bottleneck, you want to give permission immediately.

Cline itself basically executes commands outside the sandbox based on its own ideas, which is dangerous. As a result, it absorbs environmental information and improves coding accuracy...

I imagine the security officers at companies that want to use Cline will have quite a headache.

Since I can anticipate this far, I predict that container security and WebAssembly Sandbox will become hot topics where Cline is headed.

As a small resistance, I run with execution-time permissions like deno run --allow-net, but I'm often lazy and just use -A (--allow-all). Still, I think deno is well-suited for this.

vs. The "Programmers Are Unnecessary" Argument

I don't think programmers will become unnecessary. I believe programmers are not just code-writing workers but specialists trained in abstract thinking to decompose and reconstruct elements of a domain.

And without this way of thinking, programming cannot be realized. This is the level at which AI does programming, so humans need to meet AI's expectations. Areas that cannot be met will be filled with hallucinations.

Advanced AI is like a mirror of oneself, and the performance you can draw from AI is directly proportional to your own abilities. Programming work has just moved a little closer to natural language, but the actual operation level is still programming language, and the level required during debugging hasn't changed, and may even be more difficult.

The profession of programmer isn't ending. It's just changing.

I still don't believe it. Sure, a breakthrough that puts advanced computing capability into the hands of many more people means that ordinary people will be able to execute what was once the realm of highly trained specialists. But that same breakthrough creates new kinds of services and new demand for those services. It creates new sources of deep magic that only a few people can understand.
https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/

However, I also think it's dangerous to be too optimistic due to the sunk cost bias of being a specialist myself.

For example, the following article about translation jobs disappearing felt too vivid to dismiss as someone else's problem:

About human translation that will soon disappear｜Akito Hirano

As of the end of 2024, I have 0 requests coming in for next year.
As a result, my income forecast for 2025 is 0 yen.

This is just one translation story.
In other words, it's one story about translation.
If you think it's not relevant, you don't have to read further.
If it differs from the reality you know, you don't have to believe what follows.

AI coding is probably at the peak of the hype cycle right now, and by destiny, a period of disillusionment will follow. People with low programming proficiency will enter, complain that it doesn't work, and leave. Cline is not set up to be usable for the current AI enthusiasts who don't want to get their hands dirty.

The real competition starts from there, and when Cline-type coding becomes well-established, opened to everyone, and practices are organized, only those on the adaptive side of humanity will survive, at least in terms of productivity.

To put it more simply, you won't be able to win in salary competition based on productivity. Or rather than productivity, you'll need to make AI management pipeline design your core skill. I have such a premonition.

So I'm betting my future programmer life on Cline to survive.

lizod - spiritual successor of zod less than 1kb

mizchi (Kotaro Chikuba) — Tue, 23 May 2023 09:00:35 +0000

(Translated with www.DeepL.com/Translator. Original Japanese version is https://zenn.dev/mizchi/articles/lizod-is-lightweight-zod)

lightweight-zod, hence lizod.

You can use npm install lizod -S.

tl;dr

The build size of zod is getting in the way of various frontends and Cloudflare Workers.
I've created a zod-like validator that discards the method chain and all the useful utilities.
lizod is less than 1kb compared to zod's 57kb

It works.

// Pick validators for treeshake
import {
  $any,
  $array,
  $boolean,
  $const,
  $enum,
  $intersection,
  $null,
  $number,
  $object,
  $opt,
  $regexp,
  $string,
  $symbol,
  $undefined,
  $union,
  $void,
  type Infer,
  type Validator,
} from "lizod";

const validate = $object({
  name: $string,
  age: $number,
  familyName: $opt($string),
  abc: $enum(["a" as const, "b" as const, "c" as const]),
  nested: $object({
    age: $number,
  }),
  static: $const("static"),
  items: $array($object({
    a: $string,
    b: $boolean,
  })),
  complex: $array($union([
    $object({ a: $string }),
    $object({ b: $number }),
  ])),
  sec: $intersection([$string, $const("x")]),
});

const v: Infer<typeof validate> = {
  name: "aaa",
  age: 1,
  familyName: null,
  abc: "b",
  nested: {
    age: 1,
  },
  static: "static",
  items: [
    {
      a: "",
      b: true,
    },
    {
      a: "",
      b: false,
    },
  ],
  complex: [
    { a: "" },
    { b: 1 },
  ],
  sec: "x",
};

if (validate(v)) {
  const _: string = v.name;
  const __: number = v.age;
  const ___: string | void = v.familyName;
  const ____: "a" | "b" | "c" = v.abc;
  const _____: { age: number } = v.nested;
  const ______: "static" = v.static;
  const _______: Array<{
    a: string;
    b: boolean;
  }> = v.items;
}

Why I made it

Recently, there is a high demand to run zod together with remix and others under the 1MB limit of Cloudflare Workers (5MB for paid plans). 220kb of remix is unavoidable since it is a framework, but zod has a size of 57kb. 57kb for a single function validator is a little bit too much.

https://bundlephobia.com/package/zod@3.21.4

bundlephobia says 57kb, but I checked it with my own build and it was about 43kb. However, it is still big.

I need a lightweight zod alternative for Cloudflare Workers, not to mention the build size of the frontend.

So, I made what I think is the best zod alternative.

Why is zod size so big?

In general, libraries that adopt the API style of method chaining do not benefit from the ESM + various bundlers to remove unnecessary code. Imagine jQuery, for example.

Validators such as zod do not need to be method chains and could be represented by function composition, but the Pipeline Operator that allows this to be written naturally is still being hotly debated at Stage 2 and is not expected to be available anytime soon.

https://github.com/tc39/proposal-pipeline-operator

As far as I read the Zod code, there is a lack of optimization for tree shaking by method chaining, and the Locale definition for displaying Error Reporter and Error Message is quite large.

I thought about Forking Zod itself, but I thought I could achieve my goal by implementing the parts I really want in my use case in the way I want.

Features I want in zod

A set of validators at the same level as TypeScript type expressions
An Infer<T> to the synthesized validators

So, I first created it with this kind of API set in mind

import { $object, $array, $union, $number, $string, type Infer } from "lizod";.

const validate = $object({
  v: $array($union($string, $number))
});

type MyType = Infer<typeof validate>

const input: any = {
  v: [1, "hello", "world", 9]
}
if (validate(input)) {
  // type narrowing in this scope
  const v: Array<number | string> = input.v
}

zod does not mesh with TypeScript type expressions in some places due to the merging of existing validators and instruction sets. lizod can be used with the same type sense as TypeScript's A | B and A & B since the instruction levels are $union and $intersect.

Things you don't need

Utilities like email(). It implements $regexp(expr) instead, so the regular expression itself is brought separately.
- One of the reasons why zod is so heavy is because it wraps a lot of this kind of regexp inside...
Method Chain
Clever Error Reporter

In the spirit of "create your own missing validators", only primitive validators are implemented in the main body.

Finally

I think there are many people who think that zod is only possible with a collection of utilities, or that not having an error reporter is a shame, etc. For those people, lizod is a great tool. For those people, lizod's small amount of code may be useful as a foundation to fork and tweak.

At least, I expect this kind of functionality from zod, and when I implemented it, it became lizod. I have been able to create it because I have been getting more and more good at type-puzzling recently.

I am waiting for your comments, feature suggestions, and PR.

https://github.com/mizchi/lizod/issues

Run crossbrowser e2e testing on GitHub Actions

mizchi (Kotaro Chikuba) — Sat, 21 Sep 2019 15:05:13 +0000

GitHub Actions can use windows and mac for ci container so I think, "IE11
and Safari work on CI?". Speaking from conclusion, it works!

I succeeded to run windows/ie11 mac/safari windows/chrome windows/firefox on GitHub Actions.

My working example is here. https://github.com/mizchi/frontend-gh-action-playground

Setup

I use node.js selenium-webdriver and jest(-ts).

yarn add jest ts-jest selenium-webdriver chromedriver geckodriver -D

(... Setup your own jest.config.js. example)

Simple e2e scenario for browsers

// e2e/runWithSelenium.ts
import webdriver from "selenium-webdriver";
import assert from "assert";
import path from "path";

let driver: webdriver.WebDriver;

beforeAll(async () => {
  let capabilities: webdriver.Capabilities;
  switch (process.env.BROWSER || "chrome") {
    case "ie": {
      // HACK: include IEDriver path by nuget
      const driverPath = path.join(
        __dirname,
        "../Selenium.WebDriver.IEDriver.3.150.0/driver/"
      );
      process.env.PATH = `${process.env.PATH};${driverPath};`;
      capabilities = webdriver.Capabilities.ie();
      capabilities.set("ignoreProtectedModeSettings", true);
      capabilities.set("ignoreZoomSetting", true);
      break;
    }
    case "safari": {
      capabilities = webdriver.Capabilities.safari();
      break;
    }
    case "firefox": {
      require("geckodriver");
      capabilities = webdriver.Capabilities.firefox();
      break;
    }
    case "chrome": {
      require("chromedriver");
      capabilities = webdriver.Capabilities.chrome();
      capabilities.set("chromeOptions", {
        args: [
          "--headless",
          "--no-sandbox",
          "--disable-gpu",
          "--window-size=1980,1200"
        ]
      });
      break;
    }
  }
  driver = await new webdriver.Builder()
    .withCapabilities(capabilities)
    .build();
});

afterAll(async () => {
  await driver.quit()
});

it("Google", async () => {
  await driver.get('http://google.com');
  assert.equal(await driver.getTitle(), "Google");
});

You can run this script with BROWSER=chrome jest e2e/runWithSelenium.ts.

Setup workflows

I will use it on github actions on windows and mac.

# .github/workflows/xbrowser.yaml
name: xbrowser

on: [push]

jobs:
  e2e-ie:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v1
      - uses: warrenbuckley/Setup-Nuget@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 12
      - run: yarn install
      - run: nuget install Selenium.WebDriver.IEDriver -Version 3.150.0
      - run: yarn jest e2e/runWithSelenium.test.ts
        env:
          BROWSER: ie
  e2e-safari:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 12
      - run: yarn install
      - run: |
          sudo safaridriver --enable
          safaridriver -p 0 &
      - run: yarn jest e2e/runWithSelenium.test.ts
        env:
          BROWSER: safari
  e2e-firefox:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 12
      - run: yarn install
      - run: yarn jest e2e/runWithSelenium.test.ts
        env:
          BROWSER: firefox
  e2e-chrome:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 12
      - run: yarn install
      - run: yarn jest e2e/runWithSelenium.test.ts
        env:
          BROWSER: chrome

It works like this https://github.com/mizchi/frontend-gh-action-playground/pull/5/checks

Minimum Elm Component with Percel and WebComponents

mizchi (Kotaro Chikuba) — Mon, 17 Dec 2018 19:19:40 +0000

yarn add parcel-bundle node-elm-compiler -D

directories

elements/
  foo.js
  Foo.elm
run.js
index.html # import run.js
package.json

Write elm-foo component

-- elements/Foo.elm
import Html exposing (div, text)
main = div [] [text "foo"]

// elements/foo.js
import { Elm } from "./Foo.elm";

customElements.define(
  "elm-foo",
  class extends HTMLElement {
    connectedCallback() {
      Elm.Main.init({ node: this });
    }
  }
);

Run

Mount this elm-foo element.

// run.js
import "./elements/foo";
document.body.innerHTML = '<elm-foo></elm-foo>'

Minimum flux with useReducer

mizchi (Kotaro Chikuba) — Wed, 28 Nov 2018 12:20:03 +0000

Inject state and dispatcher context by React.Context and useContext

import React, { useReducer, useContext, Dispatch, ReactElement } from "react";
import ReactDOM from "react-dom";

type CounterState = {
  count: number;
};

const initialState: CounterState = { count: 0 };

function reducer(state: CounterState, action: any) {
  switch (action.type) {
    case "reset": {
      return initialState;
    }
    case "increment": {
      return { count: state.count + 1 };
    }
    case "decrement": {
      return { count: state.count - 1 };
    }
    default: {
      return state;
    }
  }
}

// Container
const CounterContext = React.createContext<CounterState>(null as any);
const DispatchContext = React.createContext<Dispatch<any>>(null as any);

function App({ initialCount }: { initialCount: number }) {
  const [state, dispatch] = useReducer(reducer, { count: initialCount });
  return (
    <CounterContext.Provider value={state}>
      <DispatchContext.Provider value={dispatch}>
        <Counter />
      </DispatchContext.Provider>
    </CounterContext.Provider>
  );
}

// Connected component
function Counter() {
  const state = useContext(CounterContext);
  const dispatch = useContext(DispatchContext);
  return (
    <div>
      Count: {state.count}
      <button onClick={() => dispatch({ type: "reset" })}>Reset</button>
      <button onClick={() => dispatch({ type: "increment" })}>+</button>
      <button onClick={() => dispatch({ type: "decrement" })}>-</button>
    </div>
  );
}

ReactDOM.render(<App initialCount={2} />, document.querySelector(".root"));

Mount vue component in react with webcomponents

mizchi (Kotaro Chikuba) — Wed, 21 Nov 2018 23:08:16 +0000

I tried helpers to mount react and vue components via webcomponents.

https://github.com/mizchi/wc-helpers

My goal is to try micro-frontend.

import {
  vueElementFactory,
  reactElementFactory,
  encodeProps
} from "@mizchi/wc-helpers";

// register
customElements.define("my-react-component", reactElementFactory(MyReactApp));
customElements.define("my-vue-component", vueElementFactory(MyVueApp));

// run
const state = { a: 0 };
const encoded = encodeProps(state);
document.body.innerHTML = `
  <my-react-component data-props="${encoded}"></my-react-component>
  <my-vue-component data-props="${encoded}"></my-vue-component>
`;

Mount another platform

my-react-component(depth=n) => my-vue-component(depth=n-1)
my-vue-component(depth=n) => my-react-component(depth=n-1)

HTML

Code

import Vue from "vue";
import Component from "vue-class-component";
import React from "react";
import { vueElementFactory, reactElementFactory, encodeProps } from "..";

// Vue
@Component({
  props: ["depth"]
})
class MyVueApp extends Vue {
  now: number = Date.now();
  render(h: any) {
    const depth = parseInt(this.$props.depth, 10);
    if (depth > 0) {
      return h(
        "div",
        {
          style: {
            paddingLeft: "10px",
            backgroundColor: "rgba(0, 255, 0, 0.3)"
          }
        },
        [
          h("p", {}, `vue: ${depth} createdAt:${this.now}`),
          h("my-react-component", {
            attrs: {
              "data-props": encodeProps({ depth: depth - 1 })
            }
          })
        ]
      );
    } else {
      return h(
        "p",
        {
          style: {
            paddingLeft: "10px",
            backgroundColor: "rgba(0, 255, 0, 0.3)"
          }
        },
        `vue: 0 - createtAt:${this.now}`
      );
    }
  }
}
customElements.define("my-vue-component", vueElementFactory(MyVueApp));

// React
class MyReactApp extends React.PureComponent<{ depth: string }> {
  now: number = Date.now();
  render() {
    const h = React.createElement;
    const depth = parseInt(this.props.depth, 10);
    if (depth > 0) {
      return h(
        "div",
        {
          style: {
            paddingLeft: "10px",
            backgroundColor: "rgba(255, 0, 0, 0.3)"
          }
        },
        h("p", {}, `react: ${depth} createdAt: ${this.now}`),
        h("my-vue-component", {
          "data-props": encodeProps({ depth: depth - 1 })
        })
      );
    } else {
      return h(
        "p",
        {
          style: {
            paddingLeft: "10px",
            backgroundColor: "rgba(255, 0, 0, 0.3)"
          }
        },
        "react 0: createdAt " + this.now
      );
    }
  }
}
customElements.define("my-react-component", reactElementFactory(MyReactApp));

// run
// const root = document.querySelector(".root");

let state = { depth: 4 };
const entry = document.createElement("my-react-component");
entry.setAttribute("data-props", state.depth.toString());
document.body.appendChild(entry);

setInterval(() => {
  state = { depth: state.depth + 1 };
  entry.setAttribute(
    "data-props",
    encodeProps({ depth: (state.depth % 6) + 3 })
  );
}, 1000);

How it works

Encode json to safe string
Define Component
Listen data-props's attributeChangedCallback
re-render

See implementation (114 lines) https://github.com/mizchi/wc-helpers/blob/master/index.ts

Why `wc-helper` needs encode

WebComponents takes properties as string only. If you need to handle event handlers, try lit-html and lit-html/lib/lit-extended.

https://github.com/Polymer/lit-html

react-unite: Editable layout system

mizchi (Kotaro Chikuba) — Sat, 17 Nov 2018 19:02:33 +0000

I just published react-unite to npm.

https://github.com/mizchi/react-unite

Demo

inspired by unity3d layout system.

Example

yarn add react@16.7.0-alpha.0 react-dom@16.7.0-alpha.0 react-unite

TypeScript example.

import React from "react";
import ReactDOM from "react-dom";
import { LayoutData, Windowed, EditableLayout } from "react-unite";

const initialLayoutData: LayoutData = {
  grid: {
    columns: ["1fr", "1fr"],
    rows: ["40px", "1fr", "1fr"],
    areas: [
      ["header", "header"],
      ["preview", "inspector"],
      ["assets", "inspector"]
    ]
  },
  windowMap: {
    "#scene": { displayName: "Scene", id: "#scene" },
    "#project": { displayName: "Project", id: "#project" },
    "#hierachy": { displayName: "Hierachy", id: "#hierachy" },
    "#inspector": { displayName: "Inspector", id: "#inspector" },
    "#services": { displayName: "Services", id: "#services" }
  },
  containers: [
    {
      id: "preview",
      displayName: "Preview",
      selectedId: "#scene",
      windowIds: ["#scene"]
    },
    {
      id: "assets",
      displayName: "Preview",
      selectedId: "#project",
      windowIds: ["#project", "#hierachy"]
    },
    {
      id: "inspector",
      displayName: "Inspector",
      selectedId: "#inspector",
      windowIds: ["#inspector", "#services"]
    }
  ]
};

// To fill window, Set css `html, body { margin: 0;}`
const MyLayout = () => {
  return (
    <Windowed>
      {(width, height) => (
        <EditableLayout
          width={width}
          height={height}
          layout={initialLayoutData}
          renderTab={data => {
            return <span>{data.displayName}</span>;
          }}
          renderWindow={win => {
            return (
              <div>
                {win.id}: {win.displayName}
              </div>
            );
          }}
        />
      )}
    </Windowed>
  );
};

const root = document.querySelector(".root");
ReactDOM.render(<MyLayout />, root);

Sample project

https://github.com/mizchi-sandbox/react-unite-example

redux-workerized - Redux in WebWorker for React and Vue

mizchi (Kotaro Chikuba) — Mon, 12 Nov 2018 06:33:12 +0000

I made experimental modules to use redux in worker.

mizchi/redux-workerized

TypeScript Friendly API
Redux.Store in Worker
React Hooks API and Vue Plugin

Shared Store example

Code

full code is here https://github.com/mizchi/redux-workerized/tree/master/examples/microfront

import "@babel/polyfill";
import { RootState, increment, Increment, INCREMENT } from "./reducer";

const worker = new Worker("./worker.ts");

// React

import React, { useCallback } from "react";
import ReactDOM from "react-dom";
import { createWorkerContext } from "redux-workerize/react";

const { WorkerContext, useSnapshot, useDispatch, ready } = createWorkerContext<
  RootState,
  { value: number }
>(worker, async (state: RootState) => {
  return state.counter;
});

function CounterApp() {
  const value = useSnapshot(state => state.value);
  const dispatch = useDispatch<Increment>();

  const onClick = useCallback(() => {
    dispatch(increment());
  }, []);

  return <button onClick={onClick}>{value}</button>;
}

ready.then(() => {
  ReactDOM.render(
    <WorkerContext>
      <CounterApp />
    </WorkerContext>,
    document.querySelector(".react-root")
  );
});

// Vue
import Vue from "vue";
import Vuex from "vuex";
import App from "./App.vue";
import { workerPlugin, proxy, SYNC } from "redux-workerize/vue";

Vue.use(Vuex);

type CounterSnapshot = {
  value: number;
};

export type State = {
  remote: CounterSnapshot;
};

const store = new Vuex.Store<State>({
  state: {
    remote: {
      value: 0
    }
  },
  mutations: {
    [SYNC](state, payload: CounterSnapshot) {
      state.remote = { ...state.remote, ...payload };
    },
    ...proxy([INCREMENT])
  },
  plugins: [
    workerPlugin(
      worker,
      (state: RootState): CounterSnapshot => {
        return state.counter;
      }
    )
  ]
});

new Vue({
  store,
  el: ".vue-root",
  render(h) {
    return h(App);
  }
});

NOTE: You need react@16.7.0-alpha.0 react-dom@16.7.0-alpha.0

Vuex subscribe remote Redux.Store snapshot

Worker Side

import * as Comlink from "comlinkjs";
import { createStore } from "redux";
import reducer from "./reducer";
import { createWorkerizedStore } from "redux-workerized/worker";

const store = createStore(reducer);
const storeAPI = createWorkerizedStore(store);

Comlink.expose({ ...storeAPI }, self);

What I want to do

For performance by off-the-main-thread
Store in Woker is training wheels to write universal javascript.

Forem: mizchi (Kotaro Chikuba)

Writing JS FFI in MoonBit

Getting Started with MoonBit JS FFI

Differences from Prior JS FFI Implementations

Build Configuration for MoonBit JS Backend

First Steps with JS FFI

Casting with #external type and %identity

Implementing Value Comparison

Implementing Show's to_string

Observing Values MoonBit Generates

Objects That Don't Convert Directly

Implementing get, set, and Function Calls on JsValue

Example: Calling Math.sqrt

Example: Calling fs.readFileSync in Node Environment

Implementing JsValue Conversion with Traits

Interim Summary

Advanced: Exceptions and Async

Exception and Async Specification

Implementing Synchronous Exceptions

Async with Non-Synchronous Exceptions

Converting MoonBit Async Functions to Promises

MoonBit: A Modern Language for WebAssembly/JS/Native

tl;dr

Why MoonBit?

Limitations of TypeScript

Rust is Too Low-Level for Applications

Installation

Quick Start

Language Basics

Functions and Pipelines

Structs with Labeled Arguments

Enums as Algebraic Data Types

Error Handling

Async Support

For Loops and Iterators

Build Targets

Built-in Testing

Package Management

moon CLI Features

Learning Resources

Official Tour

Language Documentation

Weekly Updates

Source Code

Practical Examples

My Hands-on Experience

Is It Ready for Production?

Language Specification

Async Runtime

Conclusion

About This Article

Useful Features of MoonBit's moon CLI - Built-in lint, bench, snapshot, coverage, doc

Building Incremental Markdown Compiler by Moonbit

The Basic Idea: Building CST Based on Cursor Position

Implementing This

Actual Benchmarks

Comparison with Different Libraries

Comparison by Build Target

Incremental Parse Benchmarks

Thoughts on Moonbit x AI

Moonbit's Cross-Target Performance

The End

All in on CLINE

The End of Programming as We Know It

AI and Programmers Are Now Truly on the Same Playing Field

How (In)competent Is AI at Programming?

Let Cline Do What It's Good At

Assigning Difficult Tasks: HM Type Inference for JSON

The Decision and Resolve to Hand Over the Driver's Seat

What Cline/Claude Struggles With: Context Retention

What Programmers Need in the Cline AI Era

Cline and Programming Language Aptitude

Why This Is a "Pandora's Box"

vs. The "Programmers Are Unnecessary" Argument

lizod - spiritual successor of zod less than 1kb

tl;dr

Why I made it

Why is zod size so big?

Features I want in zod

Things you don't need

Casting with `#external type` and `%identity`

Why `wc-helper` needs encode