Filosofía: CrossFly vs. declarativo-reactivo

Antes de las tablas de traducción por origen, el contrato mental que vale para todas.

El único cambio que importa

Los frameworks declarativo-reactivos (Flutter, Compose, SwiftUI, React Native) describen la UI como función del estado y la reconstruyen cuando el estado cambia. CrossFly es imperativo y orientado a objetos: creas objetos Component mutables una vez (en onShow()), guardas referencias, modificas propiedades y llamas a repaint().

No hay build() reejecutado, no hay setState, no hay async/await. El punto en común con Flutter/Compose: todo se renderiza vía GPU (OpenGL/WebGL), sin widgets nativos — la apariencia es idéntica en todas las plataformas.

El mapeo de los 4 pilares

En tu framework	En CrossFly
`build()`/`body` reejecutado	se monta una vez en `onShow()`; después mutas objetos
`setState`/`@State`/`useState` → rebuild	cambiar campo + `repaint()` (+ `setValidLayout(false)` si el tamaño cambió)
widgets de layout anidados	`add(valor, comp)` — `LAY_AUTO`(0f) / `LAY_FILL`(-1f) / fracción
`async`/`await`/`Future`	`Thread` + `Component.onUI(...)` (threading explícito)

El contador, los dos modelos

// Declarativo-reactivo (pseudo): el estado cambia → la UI se reconstruye sola.
// CrossFly: tú guardas la referencia y actualizas a mano.
public class Contador extends Window {
   private int n = 0;
   private Label display;
   @Override public void onShow() throws Exception {
      super.onShow();
      setLayout(new VerticalLayout());
      add(LAY_AUTO, display = new Label("0"));
      Button mais = new Button("+");
      mais.onAction(c -> { n++; display.setText(String.valueOf(n)); });  // muta + repinta
      add(LAY_AUTO, mais);
   }
}

Trampas universales (valen para todo origen)

Guarda referencias a los componentes que vas a actualizar (campos de la Window) — no hay forma de “reencontrarlos” por reconstrucción.
Padding/margen no son widgets: son ingap/outgap en el estilo del componente.
Sin hot-reload — es Java compilado (en el escritorio el ciclo es rápido; ver platforms).
La i18n de textos es manual — no hay catálogo de strings incorporado (ver i18n).
Los colores son int ARGB 0xAARRGGBB — no hay clase Color (usa UIConstants/ColorUtils).

Elige tu origen

Flutter · Jetpack Compose · SwiftUI · React Native · TotalCross/SuperWaba

Véase también

Concepto: Estado y flujo de datos · Todo es un Component