A TypeScript reader brings habits from objects, structural types, unions, undefined, promises, imports, npm packages, and prototype-shaped history. That helps with flexible shapes and fast feedback from type tooling, but the Musi page asks a narrower question: what contract should this generic behavior contracts example make visible?
type Box<T> = { value: T };
const boxedName: Box<string> = { value: "Nora" };let Box [T] := data {
value : T;
};
let boxedName : Box[String] := {
value := "Nora"
};
boxedName.value;Reading Generics and Type Parameters from JavaScript/TypeScript
On the Musi side, Musi classes name behavior a type can provide, instances provide it, and laws document promises callers rely on. Read the shared example through JavaScript/TypeScript eyes: keep the useful instinct, then let Musi name shape, behavior, absence, and outside work in separate places.
False friend
Do not confuse a Musi class with stored object state, inheritance, or a metatable. Shape and behavior are separate. For a TypeScript reader, the trap is assuming runtime object shape and compile-time behavior contract are the same thing; Musi class is not a JS constructor or TS class; it is a behavior contract implemented separately from record/data shape.
When this pays off
Use classes when many types share an operation such as compare, show, step, encode, or measure. The JavaScript/TypeScript instinct still helps here: Keep the TypeScript habit of reading the shape before reading implementation details.