- Electron es un framework basado en HTML, CSS y JS que permite crear aplicaciones de escritorio con soporte simultáneo para Windows, Mac y Linux, y muchas apps como Slack, Discord y VS Code lo utilizan
- Sin embargo, como cada app incluye su propio motor Chromium, el tamaño es grande, se presentan problemas de latencia y falta de respuesta, y la integración con funciones del sistema operativo también es limitada
- Con la llegada de los agentes de programación, que pueden realizar generación de código nativo por plataforma a partir de especificaciones y pruebas, parecería que las ventajas de Electron se están reduciendo
- Pero en la práctica, los agentes solo pueden automatizar hasta el 90% del desarrollo, y el último 10% de manejo de excepciones y mantenimiento sigue siendo difícil y dependiente del trabajo humano
- Por eso, incluso con el avance de la tecnología de agentes, siguen existiendo razones prácticas para usar Electron, como en el caso de la app de Claude de Anthropic
Ventajas y límites de Electron
- Electron permite crear apps de escritorio multiplataforma con tecnologías web
- Un solo codebase para Windows, Mac y Linux
- Se puede reutilizar el código de una web app existente, lo que mejora la eficiencia de desarrollo
- Entre sus desventajas están el aumento del tamaño de la app y la caída de rendimiento
- Cada app incluye su propio motor Chromium, por lo que puede llegar a ocupar cientos de MB
- Surgen problemas como menor velocidad de respuesta y poca integración con funciones del sistema operativo
- Algunos de estos problemas pueden mejorarse con optimización por sistema operativo, pero las ventajas estructurales de Electron no incentivan activamente ese esfuerzo
La aparición de los agentes de programación y las expectativas
- Recientemente, los agentes de programación han mostrado capacidad para automatizar implementaciones entre lenguajes y plataformas a partir de especificaciones (spec) y pruebas
- En teoría, con una sola especificación y un conjunto de pruebas sería posible generar apps nativas para cada plataforma
- Esto plantea la posibilidad de que equipos pequeños y enfocados puedan ofrecer apps nativas de alto rendimiento a un mercado amplio
El caso de Claude y Anthropic
- Anthropic implementó con un agente de programación un compilador de C basado en Rust, pero chocó con límites en la etapa final
- Al agregar nuevas funciones o corregir bugs, se repetía el problema de que se rompían funciones existentes
- El resultado era impresionante, pero fue evaluado como no apto para uso real
- La app de escritorio de Claude también fue creada sobre Electron, y se la menciona como una app lenta, con muchos bugs y de gran tamaño
La dificultad del “último 10%”
- Los agentes de programación pueden resolver rápidamente el 90% inicial del desarrollo, pero
el manejo de excepciones y el mantenimiento en entornos reales siguen siendo complejos y requieren intervención humana
- En entornos reales de usuarios, se acumulan escenarios inesperados y el desarrollo nunca termina realmente
- Si se crean apps separadas para cada plataforma, los bugs y el alcance del soporte se triplican, aumentando la carga de mantenimiento
- Electron alivia parcialmente este problema mediante un wrapper común
Por qué se sigue usando Electron
- Aunque el desarrollo basado en especificaciones sea posible, el costo del último 10% del desarrollo y la carga de mantenimiento siguen existiendo
- A pesar del avance de la tecnología de agentes, la ventaja de un solo codebase de Electron sigue siendo válida en la práctica
- En el momento actual, Electron sigue siendo una opción razonable
- Los agentes de programación muestran avances sorprendentes, pero todavía no son un sustituto completo
1 comentarios
Comentarios en Hacker News
Soy Boris del equipo de Claude Code
Antes había ingenieros que trabajaban en Electron, así que preferían construirlo de una forma no nativa.
Eso permite compartir código entre web y escritorio y mantener la misma UI/UX.
Claro, todo es una cuestión de trade-offs, así que en el futuro podría cambiar.
Parece algo que podría resolverse con optimización de rendimiento sin cambiar de stack. Lo mismo aplica para apps móviles.
La lección es que hay que mirar las acciones, no las palabras.
Si es así, entonces podrían simplemente pedirle a Claude: “haz que esto no se vea tan chafa”.
los agentes de IA podrían mantenerlas usando solo especificaciones y pruebas.
Sobre todo considerando las limitaciones de modelos como Opus 4.6, da curiosidad ver qué pasaría.
Está claro por qué el código no es gratis.
Nuestro equipo también usó mucho Claude durante 6 meses, pero la tasa de bugs sigue ahí.
La IA no es una solución mágica.
Si tercerizas el pensamiento a la IA, pierdes el mapa mental del sistema.
Aun así, ya salen con “¿por qué no reescriben todo con IA?”, lo cual da risa.
Ver enlace de Imgur.
Los agentes de programación con IA todavía no están del todo en ese nivel, pero hay que cuidarse de los errores rápidos.
El navegador de OpenAI ya lleva 4 meses desde su lanzamiento y sigue siendo solo para macOS.
Incluso corriendo sobre un motor multiplataforma, resulta extraño que la expansión vaya tan lenta.
La frase “Free as in puppy” estuvo muy ingeniosa.
Al parecer el título original empezaba con “If code is free,”.
Este artículo y el hilo en general parecen el típico patrón de debate de HN.
“La IA es mala”, “JavaScript es malo”, “Electron es malo”: el mismo guion de siempre.
Electron es prácticamente una ‘cuarta plataforma de sistema operativo’, pero muchos desarrolladores no lo entienden.
Las apps actuales parecen sitios web parchados, y tienen muchas inconsistencias de estilo y bugs.
Hacer una app nativa para Mac se siente mucho mejor.
Electron tiene ventajas, pero casi no se hace optimización específica por sistema operativo.
También hay muchas UI nativas malas; al final todo depende de cómo escribe el código la gente.
Si Claude ya ofrece una herramienta CLI, elegir Electron parece razonable.
Reconocí las ventajas de Electron y expliqué por qué lo eligieron.
Solo que el hecho de que sea lento incluso en una Mac Studio con 64 GB de RAM es interesante.
Incluir hasta dependencias de npm por defecto parece una falta de orgullo técnico.
No encaja con el eslogan de “contratamos al mejor talento”.
Me gusta JavaScript, pero el uso de RAM está fuera de control.
Anthropic nunca dijo que “el código es gratis”.
Ellos hablaron de mejoras de productividad, y de hecho escriben la mayor parte del código con LLM.
Si los vas a criticar, hay que señalar problemas reales y no un hombre de paja.
¿por qué el resultado no es mejor?”.
Ver la entrevista en Lenny’s Newsletter.
Parece que este artículo va dirigido a ellos.
Soy Felix. Estoy a cargo de las apps de Electron de Claude Code Desktop y Claude Cowork.
Nuestras apps también incluyen bastante código en Rust, Swift y Go.
Las razones para usar Electron y distribuir nuestro propio motor están explicadas en detalle en la
documentación oficial.
Electron es solo una herramienta, y si hace falta podemos usar otra cosa.
El CEO dijo que “programar es casi un problema resuelto”, así que dan ganas de preguntar por qué el resultado es este.
Tuve problemas para iniciar sesión en Claude.
El navegador se queda cargando eternamente y al hacer clic en iniciar sesión te manda al registro.
Que una función tan básica sea inestable deja mal parada a esta supuesta “futuro de la programación”.
El código nunca es gratis.
Al final, de una forma u otra, terminas pagando el costo.
Aunque la IA escriba todo el código, sigue haciendo falta alguien que lo entienda.
La capacidad de leer manuales es una fortaleza del hacker,
y una empresa que no entiende cómo funciona su propio producto es riesgosa.
Creo que el hecho de que Claude use Electron no es un tema técnico sino cultural.
Para una startup, Electron puede ser razonable,
pero una empresa grande debería invertir en calidad y UX de apps nativas.
Aunque ya sea posible automatizar la programación, el hecho de que sigan sin hacerlo
muestra que la cultura de desarrollo actual ha perdido la voluntad de hacer el mejor software posible.