22 puntos por GN⁺ 2025-05-29 | 7 comentarios | Compartir por WhatsApp
  • El desarrollador reescribió Desktop Docs, que antes era una app para Mac hecha con Electron, en Rust, y concluyó que fue la decisión correcta
  • La app inicial hecha con Electron era grande, con un tamaño de 1 GB, y tenía problemas de rendimiento que hacían que se cerrara con frecuencia
    • En particular, había problemas de degradación de rendimiento al procesar imágenes y videos a gran escala
  • Tras reconstruirla con Rust + Tauri, el tamaño de la app se redujo 83%, la velocidad de indexación mejoró más de 3 veces y también aumentó la estabilidad
    • Tamaño de la app: 1 GB → 172 MB (83% menos)
    • Instalador: 232 MB → 69.5 MB (70% menos)
    • Indexación de video: para un video de 38 minutos, 10~14 minutos → 3 minutos
    • Ejecución mucho más estable en comparación con la inestable app en Electron
  • Proceso de reconstrucción y decisiones
    • En la app de Electron, incluso en segundo plano, Chromium por sí solo usaba más de 200 MB de memoria, e incluso las videollamadas provocaban fallos
    • En la nueva app se siguieron usando las incrustaciones CLIP y el almacén vectorial de Redis
    • Pero en Rust se reescribió por completo el pipeline de procesamiento de imágenes/video y de file I/O
    • La UI tampoco se portó desde el código anterior, sino que se rehizo desde cero, logrando al final una interfaz más limpia y simple
  • Dificultades técnicas
    • La curva de aprendizaje de Rust es alta y la comunidad de Tauri todavía no está tan madura como la de Electron
    • Al empaquetar Redis dentro de la app hubo problemas de manejo de permisos y distribución
    • Aun así, frente a Electron hubo mejoras generales en control y rendimiento
  • Conclusión
    • Aunque todavía no hay una equivalencia funcional completa, las funciones clave operan de forma mucho más rápida y estable
    • El código que funciona, pero está mal hecho, hay que desecharlo sin miedo

7 comentarios

 
choyunsung79 2025-06-02

Electron integra Chromium y Tauri usa el motor instalado en el sistema operativo, así que ahí está la diferencia.

Tauri (OS WebView)** es ventajoso cuando se necesita una distribución ligera y un rendimiento rápido,
pero en servicios donde la seguridad, la confiabilidad y el control de funciones son importantes, el enfoque de Electron (con Chromium integrado) es más adecuado.

No conozco bien el problema del código, pero creo que las características de la plataforma influyen bastante.

 
bus710 2025-05-30

Si usas Flutter, rinf también está muy bueno.

 
aer0700 2025-05-29

He usado Electron, pero nunca he trabajado con Tauri; creo que debería probarlo al menos una vez.

 
GN⁺ 2025-05-29
Opiniones en Hacker News
  • Estoy creando una app de escritorio con Rust y egui, pero como es mi primera vez tanto con Rust como con desarrollo de escritorio, siento que es difícil aprender demasiados conceptos al mismo tiempo. Mi área son las herramientas de análisis para ingeniería mecánica, así que el backend necesita alto rendimiento y el frontend requiere visualización de datos. Me pregunto si al usar Tauri no fue complicado gestionar varias stacks a la vez, como rust, js y html

  • Hace poco tuve la experiencia de mover un proyecto de Tauri a Electron. Fue un dolor de cabeza por las diferencias de renderizado de las webviews usadas en distintas plataformas. Me pregunto si alguna vez has sufrido bugs de UI cross-platform. Los requisitos de UI son simples y los cálculos son complejos, así que incluso si hay costo de QA, creo que lo vale. Me pregunto si mi experiencia fue algo inusual o si las diferencias de renderizado realmente son un problema común. Y también me da curiosidad si usaste Tauri 1.0 o 2.0. La versión 2.0 salió estable justo cuando yo estaba cambiando desde v1, la migración fue una pesadilla y la documentación era realmente escasa. Me pregunto si ahora ya está mejor documentado

    • Nosotros en kreya.app usamos una webview del sistema implementada directamente por nuestra cuenta, o sea, no Tauri, y en la práctica las diferencias entre plataformas casi no han sido un problema. La mayoría se resuelve con polyfills y corremos pruebas automatizadas end to end en Linux para encontrar la mayor parte de los problemas. Lo más difícil es saber qué tan desactualizada está la versión de la webview del usuario. Esto es un problema grande en Linux y Mac, y en Windows está mucho mejor gracias a WebView2
    • En realidad todavía no hemos distribuido la versión de Tauri de forma cross-platform, así que eso lo veremos más adelante. Por suerte, los requisitos de UI son simples. Me da curiosidad qué diferencias de renderizado tuviste con Tauri. También quisiera saber en qué plataforma tu app funcionó mejor o mostró más problemas. Nosotros también queremos soporte para Windows. En la versión de Electron tuvimos problemas para ejecutar binarios empaquetados en Mac con Intel, y fue tan problemático que al reconstruir con Tauri decidimos enfocarnos primero en una sola plataforma: Mac con Apple chip. Lo hicimos con Tauri 1.4 y hasta ahora no hemos tenido problemas. También revisaré después la documentación de migración a 2.0
    • Sobre si tuve bugs de UI cross-platform, en realidad no aplica porque por ahora solo damos soporte para Mac. Si hubiéramos intentado soportar también Windows y Linux, creo que este post ni habría existido. La UI cross-platform es realmente difícil, y todavía más si intentas mantener la misma UI y conjunto de funciones pensando también en una versión online. Por eso todos se movieron de lo nativo a Qt, y luego a stacks web. En mi experiencia, trabajo en una empresa que desarrolla una app de escritorio cross-platform con millones de usuarios, y no me imagino hacerlo de otra manera
    • Cuando usé Tauri V2 hace como 6 meses, la documentación era un desastre total. El proyecto en sí es prometedor, pero como casi no había material de referencia, fue realmente un suplicio implementarlo bien
    • Hace poco Tauri anunció algo sobre esto: publicaron en Discord que este año piensan presentar nuevas tecnologías, incluyendo webviews basadas en CEF y SERVO
  • Yo también pasé por un camino parecido. Hice un visor de webcam simple optimizado para microscopios USB, porque no había nada decente y terminé haciéndolo yo mismo. Implementé casi todas las funciones en el renderer. Cuando me preparaba para enviarlo al App Store, me puse a pensar si de verdad tenía sentido un visor de webcam de 500 MB, así que lo porté a Tauri V2 y bajé el tamaño a casi 15 MB

    • Me da curiosidad la diferencia entre Tauri y Electron. Según entiendo, ambos usan un navegador para renderizar, pero Electron trae empaquetado su propio navegador completo y Tauri usa el navegador que ya existe en el sistema
    • Me parece realmente impresionante. Me da curiosidad qué producto es. Nosotros también nos estamos preparando esta semana para enviar al App Store
  • Me encanta la idea de esta app. Otras apps de este sector suelen sentirse demasiado lentas e incómodas, así que me interesa mucho este rewrite. Pero como soy fotógrafo, gran parte de mi material está en formato RAW, y no me queda claro si eso está soportado o no, o quizá no si RAW quedó fuera de “todos los principales formatos de imagen y video”. Me pregunto si hay documentación oficial, foro de usuarios u otro canal donde se puedan confirmar estos detalles

  • No soy usuario de Mac y en nuestro equipo tampoco estamos considerando reescribir en Rust, pero aun así me alegró mucho este post. Eso es exactamente lo que espero ver en “Show HN”: textos de esta longitud que resuman los trade-offs técnicos necesarios para resolver problemas reales. Gracias

    • Me da gusto poder compartir la experiencia. No fue fácil tomar la decisión de reconstruir algo que ya funcionaba, pero al final estoy satisfecho con el resultado
  • Estaría buenísimo contar con benchmarks actualizados que comparen Tauri, Flutter, Electron, React Native y otros frameworks modernos cross-platform. Las métricas clave serían tamaño del bundle, uso de memoria (RAM), tiempo de arranque, uso de CPU bajo carga y espacio en disco. Especialmente en frameworks como Tauri, donde el renderizado y el rendimiento dependen de la versión de la webview, también sería ideal incluir una matriz de compatibilidad por plataforma, como WebView2, WKWebView, etc. Si estas diferencias se organizaran visualmente en una tabla, a los desarrolladores les ayudaría mucho a tomar mejores decisiones

    • Hay una comparación reciente publicada hace 2 semanas. Se puede ver en web-to-desktop-framework-comparison. Electron es bastante competitivo en rendimiento de runtime. Creo que hay que preocuparse más por el uso de memoria que por el espacio en disco.
      • Uso de memoria en Windows (x64), build release, una sola ventana:
      1. Electron: aprox. 93 MB
      2. NodeGui: aprox. 116 MB
      3. NW.JS: aprox. 131 MB
      4. Tauri: aprox. 154 MB
      5. Wails: aprox. 163 MB
      6. Neutralino: aprox. 282 MB
      • Mac (arm64):
      1. NodeGui: aprox. 84 MB
      2. Wails: aprox. 85 MB
      3. Tauri: aprox. 86 MB
      4. Neutralino: aprox. 109 MB
      5. Electron: aprox. 121 MB
      6. NW.JS: aprox. 189 MB
      • Linux (x64):
      1. Tauri: aprox. 16 MB
      2. Electron: aprox. 70 MB
      3. Wails: aprox. 86 MB
      4. NodeGui: aprox. 109 MB
      5. NW.JS: aprox. 166 MB
      6. Neutralino: aprox. 402 MB
    • Me gustaría ver más comparativas de este tipo
  • En una empresa anterior me tocó dar mantenimiento a una app de escritorio en Electron para Windows y Mac. La app era demasiado pesada y actualizar con Squirrel era un suplicio.
    Al final dejamos la GUI como una SPA web basada en Inferno, pero reemplazamos la carga de la webview y demás con apps nativas pequeñas para cada plataforma, en C# y Swift. Gracias a eso, el tamaño de descarga y el uso de memoria bajaron alrededor de 90%, y pasamos a distribución y actualizaciones por medio de las tiendas de apps de cada plataforma. Creo que fue una excelente decisión

    • Creo que es la primera vez que veo a alguien elogiar la distribución y actualización a través de tiendas nativas.
      Me preocupa el tiempo de aprobación y la incertidumbre de las actualizaciones, así que me da curiosidad qué mejoró al pasar de Squirrel a lo nativo
    • Me da curiosidad cuánto tiempo tomó la transición
  • Si la app final es para Mac, realmente me da curiosidad por qué elegiste Rust/Tauri en lugar de Swift/SwiftUI

    • Gracias por revisarlo. El objetivo de Desktop Docs es ser cross-platform. Como hemos recibido muchas solicitudes de soporte para Windows, terminamos eligiendo Rust pensando en una futura versión para Windows
    • Yo también quería hacer la misma pregunta. Swift es un lenguaje bastante bueno y creo que tiene muchas ventajas similares a Rust. También me interesa el tema de la integración con CLIP, y la historia del port fue muy buena
    • A mí también me da curiosidad. Estoy por hacer una app de escritorio, hace mucho que uso Swift y sé apenas un poco de Rust. Tauri se ve muy atractivo. Las apps de Electron arrancan demasiado lento incluso en PCs rápidas. Gracias por compartir tus ideas
  • Me da curiosidad qué te hizo elegir Tauri en vez de egui. ¿Fue por tu experiencia con Electron? Yo también estoy intentando portar una app de Python Qt a Rust, pero me preocupa que las librerías GUI de Rust todavía no estén tan completas como Qt y que al final me quede atorado

    • Me da curiosidad cuál fue la razón de fondo para considerar el port en primer lugar
  • Al ver el botón "Try" en la página principal, uno siente que habrá una versión de prueba, pero en realidad lleva directo a la compra. Estaría bien aunque sea una prueba de una semana.
    Soy fan de la política de licencia de respaldo para uso perpetuo. Los $99 son una barrera de entrada algo alta, pero si el objetivo son creadores y estudios tiene sentido; para consumidores generales, quizá $20-$25 estaría bien.
    En el post se enfatiza el rendimiento, pero en la landing page no se menciona en absoluto. Igual que en ese video de 38 minutos, también importan datos como benchmarks, trabajo en paralelo y requisitos de VRAM. Me da curiosidad cómo se comporta en la práctica al procesar cientos o miles de horas de material.
    Me sorprende que una tarea que en Electron tomaba entre 10 y 14 minutos haya bajado a 3 minutos en Tauri. Si Electron solo hacía la orquestación de CLIP y ffmpeg, me pregunto de dónde salía semejante overhead.
    Yo antes también hice en Electron una herramienta de búsqueda de medios basada en transcripción de video, y no tuve muchos problemas de rendimiento.
    Normalmente se elige Electron o Tauri por ser cross-platform, así que me da curiosidad por qué desde el inicio es solo para Mac, sobre todo si para procesamiento pesado de medios también podrías aprovechar NVIDIA.
    Yo también volví a usar Swift recientemente después de 10 años y estaba entre Tauri y Swift para un proyecto nuevo; terminé eligiendo Swift, y comparado con 2014, ha mejorado muchísimo y fue una experiencia bastante agradable.
    Si la sección sobre usuarios activos es real, parece que ya han tenido cierto éxito, así que me da curiosidad si ya tenías red o audiencia previa en la industria de estudios/creadores. También me gustaría escuchar sobre la parte de marketing

    • Gracias por el feedback. Por temas de infraestructura todavía no hemos podido implementar una versión de prueba, pero pensamos considerarlo en el futuro.
      Como dijiste que tú mismo hiciste una herramienta parecida, me da curiosidad por qué no la lanzaste.
      Las versiones para Windows y Linux también están planeadas para los próximos meses si hay demanda.
      Conseguimos usuarios por HN, lanzamiento en reddit y algo de promoción en LinkedIn. La mayoría ha sido por boca a boca.
      Sobre el rendimiento de Electron y el procesamiento de video, si entramos a fondo hay mucho que decir. Yo tampoco soy experto en Electron, así que quizá el cuello de botella vino de que no usamos bien los workers.
      Al pasar a rust, también introdujimos scene detection para reducir la cantidad de frames que había que indexar, lo que bajó bastante la carga de procesamiento. También agregamos opciones de aceleración por GPU en ffmpeg y eso mejoró bastante el rendimiento. La generación de embeddings de imágenes también se optimizó con procesamiento por lotes. Aunque si lo fuerzas demasiado, la instancia del modelo puede crashear
 
secret3056 2025-05-29

En la tabla comparativa de rendimiento enlazada en HN, parece que Electron supera a Tauri en la mayoría de los casos....

 
majorika 2025-05-29

La comparación de rendimiento en los comentarios da bastante la impresión de haber recortado de ese repositorio los valores que favorecen a Electron. Aunque las cifras difieren un poco, el dato más parecido parece ser la parte donde se compara la “diferencia entre la memoria libre antes de ejecutar y la memoria libre después de ejecutar”. Sin embargo, en el apartado inmediatamente superior, donde se registra la suma de la memoria del proceso principal y los procesos hijos mientras está en ejecución, Electron aparece con 258M, así que cuesta aceptar la parte que dice que el cambio en el uso de memoria entre antes y después de ejecutar fue de 91MB. En una respuesta en HN también se menciona que la app hecha con Tauri tardó más de 7 segundos en arrancar, lo que refuerza la idea de que es difícil confiar en las cifras medidas del repositorio.

 
wfedev 15 일 전

Bueno, parece que la mayoría de los problemas provienen más de temas del motor WebView + el SO/controladores que de las diferencias entre Electron o Tauri.