Bonsai: la biblioteca de UI de Jane Street
La biblioteca de UI Bonsai de Jane Street para OCaml provoca un debate sobre si los frameworks web especializados y fuertemente tipados siguen importando en una era en la que la IA puede generar UIs a medida sobre pilas JavaScript mainstream. Los partidarios destacan la capacidad de Bonsai para compartir tipos entre frontend y backend, su modelo incremental de máquina de estados inspirado en Elm, y su uso tanto para interfaces web como de terminal, especialmente en herramientas de trading con alta densidad de información. Los críticos cuestionan su momento, su pulido visual, su integración con el ecosistema JS existente y la escasa documentación, mientras otros señalan que, para una organización interna con recursos profundos, estos compromisos pueden ser aceptables.
Plataforma y alcance
- Confusión inicial sobre si era “solo web”; se aclaró que también existe una implementación Bonsai_term para terminal.
- La biblioteca central se presenta como un framework genérico, incremental y componible de máquinas de estado; Bonsai_web y Bonsai_term son especializaciones para navegador y terminal.
- Algunos preguntan si puede usarse para informes HTML o TUIs; las respuestas dicen que destaca en UIs interactivas complejas y con estado, no en informes estáticos sencillos.
OCaml, ecosistema y “misma lengua para front/back”
- A muchos les gusta que frontend y backend puedan compartir tipos y lógica de OCaml; otros señalan que esto ha sido posible durante años con esfuerzos previos de OCaml a JS.
- Comparación con js_of_ocaml frente a Melange y otras pilas de “compilar a JS” (Scala.js, F#, ClojureScript, KotlinJS, Fable).
- Tema recurrente: integrar estas pilas con el ecosistema más amplio de JS requiere wrappers e interoperabilidad, lo cual puede ser doloroso.
- Algunos muestran escepticismo de que, en la era de los LLM, las bibliotecas genéricas de UI importen menos; el contraargumento es que mejores frameworks siguen ayudando tanto a humanos como a AIs a evitar errores.
JS, WASM y derivación sobre TypeScript
- Se discuten las limitaciones de optimización de llamadas en cola en JS y la necesidad de trampolines.
- WASM se ve como prometedor, pero actualmente lastran la falta de acceso directo al DOM / a las Web APIs y un tamaño de descarga mayor.
- Se debate TypeScript: algunos dicen que es “solo JS con los tipos eliminados”, mientras otros subrayan que algunos constructos siguen requiriendo compilación y que sigue siendo un lenguaje distinto.
Diseño, estética y densidad de información
- Varios comentarios critican las UIs de ejemplo por estar visualmente poco pulidas o parecer “de los 90”.
- Otros defienden con fuerza la alta densidad de información y el espaciado mínimo, especialmente para flujos de trabajo de trading/finanzas donde la velocidad y las comparaciones lado a lado importan.
- Contraargumento: márgenes cero o inconsistentes pueden perjudicar la legibilidad incluso para usuarios expertos; se destaca la tensión entre la facilidad de descubrimiento para nuevos usuarios y la productividad para usuarios avanzados.
Adopción, herramientas y documentación
- Preocupaciones sobre el bus factor, la velocidad de compilación, el hot reload y el mantenimiento; algunos informan que OCaml compila rápido y es muy mantenible.
- Se describe Bonsai como verboso en comparación con React/Vue, y algunos esperan que los LLM absorban la plantilla repetitiva.
- Se señalan enlaces de documentación rotos y la ausencia de una página pública de demostración; la estrategia de actualización del DOM (directa vs diff) se plantea, pero no se responde con claridad.
- Se confirma un uso interno intenso en producción en la firma de origen; hay incertidumbre sobre su idoneidad como elección de greenfield en equipos de producto típicos.