RawJS es una mejor manera de llamar a document.createElement()
Una nueva biblioteca frontend llamada RawJS afirma ser una forma ligera y más ergonómica de llamar a `document.createElement()` y construir UIs sin React ni un virtual DOM. Los comentaristas critican en gran medida su página principal centrada en el marketing, la falta de ejemplos de código claros, la ergonomía incómoda y la dependencia de TypeScript y una estructura de proyecto poco convencional, argumentando que no escala bien para aplicaciones o equipos complejos frente a frameworks consolidados. Algunos valoran el objetivo de minimizar dependencias y mantenerse más cerca del DOM, pero la mayoría ve RawJS como una herramienta de nicho o experimental más que como un reemplazo práctico para frameworks modernos como React, Vue o Svelte.
Página de inicio, demo y documentación
- Muchos comentaristas encontraron la página de marketing vaga: sobre todo afirmaciones, pocos ejemplos de código y una posición poco clara.
- La demo en vivo recibió críticas por problemas de UX: historial del botón Atrás lleno de entradas, modales incómodos (sin botón claro para cerrar, problemas con el fondo), tipografía enorme y, en general, una sensación “poco pulida”.
- Las erratas y un enlace confuso desde “Check out Squares” hacia un repositorio de ejemplo (no el sitio principal) redujeron la confianza.
- Varias personas pidieron un ejemplo simple y canónico (por ejemplo, una app TODO) y comparaciones lado a lado con React/jQuery/vanilla, al estilo de “youmightnotneedjquery”.
Diseño de la API y ergonomía
- Los fragmentos de código compartidos fueron ampliamente vistos como verbosos, imperativos y más difíciles de leer que tanto jQuery como las plantillas de frameworks.
- El estilo de sobrecarga de parámetros (mezclando cadenas, funciones, ayudas de eventos, attrs, arrays) se consideró “magia” y propenso a errores, en contradicción con el marketing de “sin magia”.
- Escribir HTML y CSS mediante llamadas a funciones JS desanimó a muchos que prefieren plantillas o HTML+CSS puro mejorado por JS.
Posicionamiento frente a frameworks y JavaScript vanilla
- Quienes lo apoyan apreciaron la intención: dependencias mínimas, uso directo del DOM, sin virtual DOM y “el DOM como estado”.
- Los críticos argumentaron que construir el DOM no es la parte difícil; la gestión del estado y las actualizaciones escalables sí lo son, donde brillan React/Vue/Svelte/Solid.
- Varios sintieron que RawJS se parece a un “jQuery componentizado” y que no escalaría bien para aplicaciones grandes o equipos.
- Otros señalaron que JSX + React ya sirven como estándar de facto, y que herramientas más simples como htmx, Hotwire, ArrowJS o Vue puro podrían ser preferibles.
Build, dependencias y módulos
- El mensaje del repositorio de ejemplo de “sin bundler/build” frente a “TypeScript construye tu app” confundió a algunos; más tarde se aclaró como “sin webpack/rollup, solo tsc”.
- La recomendación de usar solo dependencias alojadas en jsdelivr y la broma sobre “programadores que hacen npm install” recibieron rechazo, especialmente dado que el propio proyecto usa dependencias al estilo npm.
- La aversión de la biblioteca a los módulos ES y a las listas de importación provocó debate; otros defendieron ESM y las importaciones explícitas como práctica estándar.
Afirmaciones, rendimiento y escala
- Afirmaciones como “sin curva de aprendizaje”, “sin magia rara”, “sin sobrecarga de rendimiento”, “sin errores conocidos” y usar TypeScript mientras se llama “RawJS” se percibieron como demasiado confiadas o engañosas.
- El sentimiento general tendió al escepticismo: objetivos interesantes, pero ejemplos débiles, UX áspera, beneficios poco claros frente a bibliotecas existentes y dudas sobre su viabilidad en frontends grandes y reales.