El proyecto de Electron realizará una pausa para el mes de diciembre de 2024, para después regresar a toda velocidad en enero de 2025.

via GIPHY

Lo que será igual en diciembre​

1. Los lanzamientos de día cero y los lanzamientos principales relacionados con la seguridad se publicarán según sea necesario. Los incidentes de seguridad se deben reporar a través de SECURITY.md.
2. Los reportes relacionados con el Código de conducta continuarán.

Lo que será diferente en diciembre​

1. 2024's last stable branch releases for the year, which include Electron 31, 32, and 33, will occur the week of December 1st. There will be no additional planned releases in December.
2. No Nightly and Alpha releases for the last two weeks of December.
3. Con algunas excepciones, no se realizará la revisión o fusión de pull requests.
4. No se actualizará el rastreador de incidencias en ningún repositorio.
5. No se ayudará con la depuración en Discord por parte de los encargados.
6. No se publicarán actualizaciones de contenido en las redes sociales.

See you all in 2025!

El proyecto de Electron se pausará para el mes de diciembre de 2023, para luego regresar a toda velocidad en enero de 2024.

vía GIPHY

Lo que será igual en diciembre​

1. Los lanzamientos de día cero y los lanzamientos principales relacionados con la seguridad se publicarán según sea necesario. Los incidentes de seguridad se deben reporar a través de SECURITY.md.
2. Los reportes relacionados con el Código de conducta continuarán.

Lo que será diferente en diciembre​

1. Electron 28.0.0 se publicará el 5 de diciembre. Luego de Electron 28, no se realizará el lanzamiento de versiones estables en diciembre.
2. No Nightly and Alpha releases for the last two weeks of December.
3. Con algunas excepciones, no se realizará la revisión o fusión de pull requests.
4. No se actualizará el rastreador de incidencias en ningún repositorio.
5. No se ayudará con la depuración en Discord por parte de los encargados.
6. No se publicarán actualizaciones de contenido en las redes sociales.

Avanzando​

This is our third year running our quiet period experiment, and we've had a lot of success so far in balancing a month of rest with maintaining our normal release cadence afterwards. Therefore, we've decided to make this a regular part of our release calendar going forward. We'll still be putting a reminder into the last stable release of every calendar year.

See you all in 2024!

El primer commit en el repositorio electron/electron fue el 13 de marzo de 2013¹.

10 años y 27.147 commits más de 1192 colaboradores únicos después, Electron se ha convertido en uno de los frameworks más populares para crear aplicaciones de escritorio hoy en día. Este hito es la oportunidad perfecta para celebrar y reflexionar sobre nuestro viaje hasta ahora, y para compartir lo que hemos aprendido en el camino.

No estaríamos aquí hoy sin todos los que han dedicado su tiempo y esfuerzo a contribuir al proyecto. Aunque los commits del código fuente son siempre las contribuciones más visibles, también tenemos que reconocer el esfuerzo de la gente que informa de errores, mantiene módulos de usuario, proporciona documentación y traducciones, y participa en la comunidad Electron a través del ciberespacio. Cada contribución tiene un valor incalculable para nosotros como mantenedores.

Antes de continuar con el resto de la entrada del blog: gracias. ❤️

¿Cómo hemos llegado hasta aquí?​

Atom Shell se construyó como la columna vertebral para el editor Atomde GitHub, que se lanzó en beta pública en abril de 2014. Se construyó desde cero como alternativa a los frameworks de escritorio basados en web disponibles en ese momento (node-webkit y Chromium Embedded Framework). Tenía una característica estrella: contiene Node.js y Chromium para proporcionar un potente tiempo de ejecución de escritorio para tecnologías web.

Al cabo de un año, Atom Shell empezó a crecer enormemente en capacidades y popularidad. Grandes compañías, startups y desarrolladores individuales habían empezado a construir aplicaciones con él (algunos de los primeros adoptores incluyen Slack, GitKraken, y WebTorrent), y el proyecto fue renombrado correctamente a Electron.

Desde entonces, Electron no ha parado de crecer. Aquí tienes un vistazo a nuestro recuento semanal de descargas con el tiempo, cortesía de npmtrends.com:

Electron v1 se lanzó en 2016, prometiendo una mayor estabilidad de la API y mejores documentos y herramientas. Electron v2 se lanzó en 2018 e introdujo el versionado semántico, lo que facilita a los desarrolladores de Electron a los desarrolladores hacer un seguimiento del ciclo de lanzamiento.

En Electron v6, cambiamos a una cadencia regular de lanzamientos principales de 12 semanas para ajustarnos a la de Chromium. Esta decisión supuso un cambio de mentalidad para el proyecto, haciendo que "tener la versión más actualizada de Chromium" pasara de ser un "nice-to-have" a una prioridad. Esto ha reducido la cantidad de deuda técnica entre actualizaciones, lo que nos facilita mantener Electron actualizado y seguro.

Desde entonces, hemos sido una máquina bien engrasada, lanzando una nueva versión de Electron el mismo día que cada versión estable de Chromium. Cuando Chromium aceleró su calendario de lanzamientos a 4 semanas en 2021, pudimos encogernos de hombros y aumentar nuestra cadencia de lanzamiento a 8 semanas.

Ahora estamos en Electron v23 (y contando), y seguimos dedicados a construir el mejor tiempo de ejecución para aplicaciones de escritorio multiplataforma. Incluso con el auge de las herramientas para desarrolladores de JavaScript en desarrolladores de JavaScript en los últimos años, Electron se ha mantenido estable y ha de escritorio. Las aplicaciones de Electron son omnipresentes hoy en día: puedes programar con Visual Studio Code, diseñar con Figma, comunicarte con Slack y tomar notas con Notion (entre muchos otros casos de uso). Estamos increíblemente orgullosos de este logro y agradecidos con todos aquellos que lo hicieron posible.

¿Qué aprendimos en el camino?​

El camino hacia la marca de la década ha sido largo y sinuoso. Aquí hay algunas claves que nos han ayudado a mantener un proyecto de código abierto grande y sostenible.

Escalando la toma de decisiones distribuida con un modelo de gobernanza​

Uno de los desafíos que tuvimos que superar fue manejar la dirección a largo plazo del proyecto una vez que Electron explotó en popularidad. ¿Cómo manejamos ser un equipo de varias docenas de ingenieros distribuidos en diferentes empresas, países y zonas horarias?

En los primeros días, el grupo de mantenimiento de Electron dependía de la coordinación informal, lo que es rápido y ligero para proyectos más pequeños, pero no es escalable para una colaboración más amplia. En 2019, cambiamos a un modelo de gobernanza donde diferentes grupos de trabajo tienen áreas formales de responsabilidad. Esto ha sido fundamental para optimizar los procesos y asignar porciones de propiedad del proyecto a mantenedores específicos. ¿De qué es responsable cada Grupo de Trabajo (WG) en la actualidad?

• Sacar las versiones de Electron (Releases WG)
• Actualizar Chromium y Node.js (Upgrades WG)
• Supervisar el diseño de la API pública (API WG)
• Mantener Electron seguro (Security WG)
• Administrar el sitio web, documentación y herramientas (Ecosystem WG)
• Alcanzar a la comunidad y a las empresas (Outreach WG)
• Moderación de la comunidad (Community & Safety WG)
• Mantener nuestra infraestructura de compilación, herramientas de mantenedor y servicios en la nube (Infrastructure WG)

Alrededor de la misma época en que cambiamos al modelo de gobernanza, también trasladamos la propiedad de Electron de GitHub a la OpenJS Foundation. Aunque el equipo central original todavía funciona en Microsoft hoy, son sólo parte de un grupo de colaboradores más grande que forman la gobernanza de Electron.²

Si bien este modelo no es perfecto, nos ha funcionado bien a través de una pandemia global y vientos macroeconómicos en curso. En el futuro, planeamos renovar la carta de gobernanza para guiarnos a través de la segunda década de Electron.

Comunidad​

La parte de la comunidad de código abierto es difícil, especialmente cuando tu equipo de divulgación está compuesto por una docena de ingenieros disfrazados con una gabardina que dice "gerente de comunidad". Dicho esto, ser un proyecto de código abierto grande significa que tenemos muchos usuarios, y aprovechar su energía para construir un ecosistema de usuarios para Electron es una parte crucial para mantener la salud del proyecto.

¿Qué hemos estado haciendo para desarrollar nuestra presencia en la comunidad?

Construyendo comunidades​

• En 2020, lanzamos nuestro servidor de Discord. Anteriormente teníamos una sección en el foro de Atom, pero decidimos tener una plataforma de mensajería más informal para tener un espacio para discusiones entre mantenedores y desarrolladores de Electron, así como para obtener ayuda general de depuración.
• En 2021, establecimos el grupo de usuarios de Electron China con la ayuda de @BlackHole1. Este grupo ha sido fundamental para el crecimiento de Electron en usuarios de la floreciente escena tecnológica de China, proporcionando un espacio para que colaboren en ideas y discutan sobre Electron fuera de nuestros espacios en inglés. También nos gustaría agradecer a cnpm por su trabajo en apoyar las versiones nocturnas de Electron en su espejo chino para npm.

Participar en programas de código abierto de alta visibilidad​

• Desde 2019 hemos estado celebrando el Hacktoberfest cada año. Hacktoberfest es una celebración anual de código abierto organizada por DigitalOcean, y desde 2019 hemos estado participando en ella. Cada año recibimos docenas de entusiastas contribuyentes que buscan dejar su huella en el software de código abierto.
• En 2020, participamos en la primera iteración de Google Season of Docs, donde trabajamos con @bandantonio para reorganizar el flujo del tutorial de usuario nuevo de Electron.
• En 2022, mentorizamos a un estudiante en el programa Google Summer of Code por primera vez. @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.

¡Automatiza todas las cosas!​

Hoy en día, la gobernanza de Electron cuenta con alrededor de 30 mantenedores activos. Menos de la mitad de nosotros somos contribuidores a tiempo completo, lo que significa que hay mucho trabajo para compartir. ¿Cuál es nuestro truco para mantener todo funcionando sin problemas? Nuestro lema es que las computadoras son baratas y el tiempo humano es caro. Al estilo típico de los ingenieros, hemos desarrollado una serie de herramientas de soporte automatizadas para facilitar nuestras vidas.

Not Goma​

La base de código principal de Electron es un gigante de código en C++, y los tiempos de compilación siempre han sido un factor limitante en la velocidad con la que podemos implementar correcciones de errores y nuevas funcionalidades. En 2020, implementamos Not Goma, una plataforma personalizada específica para Electron para el servicio de compilador distribuido de Google llamado Goma. Not Goma procesa las solicitudes de compilación de las máquinas autorizadas de los usuarios y distribuye el proceso en cientos de núcleos en el backend. Además, Not Goma también almacena en caché el resultado de la compilación para que alguien más que compile los mismos archivos solo necesite descargar el resultado precompilado.

Desde que lanzamos Not Goma, los tiempos de compilación para los mantenedores han disminuido de varias horas a unos pocos minutos. ¡Una conexión estable a internet se convirtió en el requisito mínimo para que los contribuyentes pudieran compilar Electron!

Autenticación de Factor Continuo​

Autenticación de Factor Continuo (CFA) es una capa de automatización en torno al sistema de autenticación de dos factores (2FA) de npm que combinamos con semantic-release para gestionar lanzamientos seguros y automatizados de nuestros diversos paquetes npm de @electron/.

Mientras que semantic-release ya automatiza el proceso de publicación de paquetes de npm, requiere desactivar la autenticación de dos factores o pasar un token secreto que evita esta restricción.

Construimos CFA para entregar una contraseña de un solo uso basada en el tiempo (TOTP) para el 2FA de npm a trabajos de integración continua (CI) arbitrarios, lo que nos permite aprovechar la automatización de semantic-release manteniendo la seguridad adicional de la autenticación de dos factores.

Usamos CFA con una interfaz integrada en Slack, lo que permite a los mantenedores validar la publicación de paquetes desde cualquier dispositivo en el que tengan Slack, siempre y cuando tengan su generador de TOTP a mano.

Sheriff​

Sheriff es una herramienta de código abierto que escribimos para automatizar la gestión de permisos en GitHub, Slack y Google Workspace.

La propuesta de valor clave de Sheriff es que la gestión de permisos debe ser un proceso transparente. Utiliza un único archivo de configuración YAML que designa los permisos en todos los servicios mencionados anteriormente. Con Sheriff, obtener el estado de colaborador en un repositorio o crear una nueva lista de correo es tan fácil como obtener la aprobación y la fusión de una PR.

Sheriff también cuenta con un registro de auditoría que se publica en Slack, alertando a los administradores cuando ocurre actividad sospechosa en cualquier lugar de la organización Electron.

... y todos nuestros bots de GitHub​

GitHub es una plataforma con una amplia extensibilidad de API y un marco de aplicación de bot de "first-party" llamado Probot. Para ayudarnos a enfocarnos en las partes más creativas de nuestro trabajo, creamos una suite de bots más pequeños que nos ayudan a realizar el trabajo sucio. Aquí hay algunos ejemplos:

• Sudowoodo automatiza el proceso de lanzamiento de Electron de principio a fin, desde el inicio de compilaciones hasta la carga de activos de lanzamiento en GitHub y npm.
• Trop automatiza el proceso de retroportar para Electron al intentar seleccionar parches a ramas de lanzamiento anteriores basadas en las etiquetas de PR de GitHub.
• Roller automatiza las actualizaciones rodantes de las dependencias de Chromium y Node.js de Electron.
• Cation es nuestro bot de verificación de estado para las PR de electron/electron.

¡En conjunto, nuestra pequeña familia de bots nos ha dado un gran impulso en la productividad de los desarrolladores!

¿Qué sigue?​

Al entrar en nuestra segunda década como proyecto, es posible que te preguntes: ¿qué sigue para Electron?

Vamos a mantenernos en sincronía con el ritmo de lanzamiento de Chromium, publicando nuevas versiones principales de Electron cada 8 semanas, manteniendo el framework actualizado con lo último y lo mejor de la plataforma web y Node.js mientras mantenemos la estabilidad y seguridad para aplicaciones de calidad empresarial.

Generalmente anunciamos noticias sobre próximas iniciativas cuando se vuelven concretas. ¡Si quieres estar al tanto de futuros lanzamientos, funciones y actualizaciones generales del proyecto, puedes leer nuestro blog y seguir nuestros perfiles en redes sociales (Twitter y Mastodon)!

Electron finalizará el soporte de Windows 7, Windows 8 y Windows 8.1, iniciando en Electron 23.

En línea con la política de obsolencia de Chromium, Electron finalizará el soporte para Windows 7, Windows 8 y Windows 8.1 iniciando en Electron 23. Esto coincide con el final de soporte de Microsoft para las actualizaciones extendidas de seguridad (ESU) de Windows 7 y Windows 8, ampliadas el 10 de enero de 2023.

Electron22 será la última versión principal de Electron en brindar soporte para las versiones de Windows más antiguas que 10. Windows 7/8/8.1 no será soportado en Electron 23 y los próximos lanzamientos principales. Las versiones más antiguas de Electron continuarán funcionando en Windows 7, y nosotros continuaremos con el lanzamiento de parches para las series 22.x de Electron hasta el 30 de mayo de 2023, cuando Electron finalizará el soporte para 22.x (de acuerdo a nuestra línea de tiempo de soporte).

¿Por qué la obsolencia?​

Electron follows the planned Chromium deprecation policy, which will deprecate support in Chromium 109 (read more about Chromium's timeline here). Electron 23 will contain Chromium 110, which won’t support older versions of Windows.

Electron 22, which contains Chromium 108, will thus be the last supported version.

Línea del tiempo de la obsoletización​

The following is our planned deprecation timeline:

• December 2022: The Electron team is entering a quiet period for the holidays
• January 2023: Windows 7 & 8 related issues are accepted for all supported release branches.
• February 7 2023: Electron 23 is released.
• February 8 2023 - May 29 2023: Electron will continue to accept fixes for supported lines older than Electron 23.
• May 30 2023: Electron 22 reaches the end of its support cycle.

What this means for developers:

• The Electron team will accept issues and fixes related to Windows 7/8/8.1 for stable supported lines, until each line reaches the end of its support cycle.
  • This specifically applies to Electron 22, Electron 21 and Electron 20.
• New issues related to Windows 7/8/8.1 will be accepted for Electron versions older than Electron 23.
  • New issues will not be accepted for any newer release lines.
• Once Electron 22 has reached the end of its support cycle, all existing issues related to Windows 7/8/8.1 will be closed.

What's next​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. You can also find community support in our official Electron Discord.

The Electron project will pause for the month of December 2022, then return to full speed in January 2023.

vía GIPHY

Lo que será igual en diciembre​

1. Los lanzamientos de día cero y los lanzamientos principales relacionados con la seguridad se publicarán según sea necesario. Los incidentes de seguridad se deben reportar a través de SECURITY.md.
2. Los reportes del Código de Conducta y moderación continuarán.

Lo que será diferente en diciembre​

1. No new Stable releases in December. No Nightly and Alpha releases for the last two weeks of December.
2. Con algunas excepciones, no se realizará la revisión o fusión de pull requests.
3. No se actualizará el rastreador de incidencias en ningún repositorio.
4. No se ayudará con la depuración en Discord por parte de los encargados.
5. No se publicarán actualizaciones de contenido en las redes sociales.

¿Por qué sucede esto?​

With the success of December Quiet Month 2021, we wanted to bring it back for 2022. December continues to be a quiet month for most companies, so we want to give our maintainers a chance to recharge. Everyone is looking forward to 2023, and we expect good things to come! Animamos a otros proyectos a considerar medidas similares.

El mes pasado, el grupo encargado de mantener Electron se reunió en Vancouver, Canadá para discutir la dirección del proyecto para el 2023 y más adelante. Durante cuatro días, en una sala de conferencias, los encargados del mantenimiento del núcleo y los colaboradores invitados debatieron sobre las nuevas iniciativas, los problemas de mantenimiento y el estado general del proyecto. invitados debatieron nuevas iniciativas, problemas de mantenimiento y la salud general del proyecto.

En el futuro, el equipo todavía está totalmente dedicado a lanzar rápidas y normales actualizaciones de Chromium, arreglando fallos, y haciendo Electron más seguro y eficiente para todos. ¡También estamos trabajando en algunos proyectos interesantes que nos gustaría compartir con la comunidad!

Nuevas API transformativas​

Las principales propuestas de API en el proyecto Electron que requieren consenso pasan por un proceso de solicitud de comentarios (RFC), que revisan los miembros de nuestro grupo de trabajo sobre API.

Este año hemos impulsado dos importantes propuestas que tienen el potencial de desbloquear una nueva dimensión de capacidades para las aplicaciones Electron. Estas propuestas son muy experimentales, pero he aquí un de lo que puede esperar!

Nuevas mejoras de complemento nativo (C APIs)​

Esta propuesta esboza una nueva capa de APIs de Electron C que permitirá a los desarrolladores de aplicaciones escribir sus Native Node Addons que interactúen con los recursos internos de Electron, de forma similar a la propia Node-API de Node. de Node. Puede encontrar más información sobre la nueva API propuesta aquí.

Ejemplo: Supercargando aplicaciones con recursos de Chromium​

Muchas aplicaciones Electron mantienen sus propias bifurcaciones para interactuar directamente con las funciones internas de Chromium que, de otro modo, serían inaccesibles con Electron vainilla (sin modificar). Al exponer estos recursos en la capa API de C este código puede vivir como un módulo nativo junto con Electron, reduciendo potencialmente la carga de mantenimiento del desarrollador de aplicaciones.

Exposición de la capa UI de Chromium (Views API)​

Bajo el capó, las partes no web de la interfaz de usuario (IU) de Chrome, como las barras de herramientas, las pestañas o los botones, se construyen con un marco llamado Views. La propuesta de la API Views introduce partes de este marco como clases de JavaScript en Electron, con el objetivo final de permitir a los desarrolladores crear elementos de interfaz de usuario no web para sus aplicaciones Electron. Esto evitará que las aplicaciones tengan que piratear contenidos web.

Actualmente se están sentando las bases para hacer posible este nuevo conjunto de API. Estas son algunas de las primeras cosas que puede esperar en un futuro próximo.

Ejemplo: Refactorización del modelo de ventana con WebContentsView​

Nuestro primer cambio planeado es exponer WebContentsView de Chrome a la superficie API de Electron, que será la sucesora de nuestra actual API BrowserView (que, a pesar del nombre, es código específico de Electron no relacionado con Chromium Views). Con WebContentsView expuesto, tendremos un objeto View reutilizable que puede mostrar contenidos web, abriendo la puerta a convertir la clase BrowserWindow en JavaScript puro y eliminando aún más complejidad de código.

Aunque este cambio no aporta muchas funciones nuevas a los desarrolladores de aplicaciones, se trata de una gran refactorización que elimina mucho código bajo el capó, lo que simplifica las actualizaciones de Chromium y reduce el riesgo de que aparezcan nuevos errores entre versiones principales.

Si eres un desarrollador de Electron que utiliza BrowserViews en tu aplicación: no te preocupes, ¡no nos hemos olvidado de ti! Planeamos convertir la clase BrowserView existente en un shim para WebContentsView con el fin de proporcionar un amortiguador durante la transición a las nuevas API.

Ver: electron/electron#35658

Ejemplo: Contenido web desplazable con ScrollView​

Nuestros amigos de Stack han estado impulsando una iniciativa para exponer el componente ScrollView de Chromium a la API de Electron. Con esta nueva API, cualquier componente View hijo puede hacerse desplazable horizontal o verticalmente.

Aunque esta nueva API cumple una única funcionalidad menor, el objetivo final del equipo es construir un conjunto de componentes de utilidad de View que puedan utilizarse como conjunto de herramientas para construir interfaces no HTML más complejas.

Participar​

¿Es usted un desarrollador de aplicaciones Electron interesado en alguna de estas propuestas de API? Aunque aún no estamos preparados para recibir más RFC, manténgase atento para conocer más detalles en el futuro!

Electron Forge v6 versión estable​

Desde la creación del framework, el ecosistema de herramientas de compilación de Electron ha sido impulsado en gran medida por la comunidad y ha consistido en muchos paquetes pequeños de un solo propósito (por ejemplo, electron-winstaller, electron-packager, electron-notarize, electron-osx-sign). Aunque estas herramientas funcionan bien, a los usuarios les resulta intimidante montar un proceso de compilación que funcione.

Para ayudar a construir una experiencia más amigable para los desarrolladores de Electron, construimos Electron Forge, una solución todo en uno que combina todas estas herramientas existentes en una sola interfaz. Aunque Forge ha estado en desarrollo desde 2017, el proyecto ha permanecido inactivo durante los últimos años. Sin embargo, dada la retroalimentación de la comunidad sobre el estado de las herramientas de construcción en Electron, hemos estado trabajando duro para lanzar la versión principal estable de próxima generación de Forge.

Electron Forge 6 incluye compatibilidad de primera clase con TypeScript y Webpack, así como una API extensible que permite a los desarrolladores crear sus propios plugins e instaladores.

Mantente atento: anuncio próximamente​

Si te interesa crear un proyecto con Forge o crear plantillas o plugins con las API extensibles de terceros de Forge, estate atento a nuestro anuncio oficial sobre la versión estable de Forge v6 en algún momento de este mes!

¿Qué sigue?​

Aparte de lo anterior, el equipo siempre está pensando en un montón de proyectos exploratorios para hacer que la experiencia Electron sea mejor para los desarrolladores de aplicaciones y los usuarios finales. Estamos experimentando con herramientas de actualización, procesos de revisión de API y documentación mejorada. Esperamos tener más noticias que compartir en un futuro próximo!

Electron 21 and later will have the V8 Memory Cage enabled, with implications for some native modules.

In Electron 21, we will be enabling V8 sandboxed pointers in Electron, following Chrome's decision to do the same in Chrome 103. This has some implications for native modules. Also, we previously enabled a related technology, pointer compression, in Electron 14. We didn't talk about it much then, but pointer compression has implications for the maximum V8 heap size.

These two technologies, when enabled, are significantly beneficial for security, performance and memory usage. However, there are some downsides to enabling them, too.

The main downside of enabling sandboxed pointers is that ArrayBuffers which point to external ("off-heap") memory are no longer allowed. This means that native modules which rely on this functionality in V8 will need to be refactored to continue working in Electron 20 and later.

The main downside of enabling pointer compression is that the V8 heap is limited to a maximum size of 4GB. The exact details of this are a little complicated—for example, ArrayBuffers are counted separately from the rest of the V8 heap, but have their own limits.

The Electron Upgrades Working Group believes that the benefits of pointer compression and the V8 memory cage outweigh the downsides. There are three main reasons for doing so:

1. It keeps Electron closer to Chromium. The less Electron diverges from Chromium in complex internal details such as V8 configuration, the less likely we are to accidentally introduce bugs or security vulnerabilities. Chromium's security team is formidable, and we want to make sure we are taking advantage of their work. Further, if a bug only affects configurations that aren't used in Chromium, fixing it is not likely to be a priority for the Chromium team.
2. It performs better. Pointer compression reduces V8 heap size by up to 40% and improves CPU and GC performance by 5%–10%. For the vast majority of Electron applications which won't bump into the 4GB heap size limit and don't use native modules that require external buffers, these are significant performance wins.
3. It's more secure. Some Electron apps run untrusted JavaScript (hopefully following our security recommendations!), and for those apps, having the V8 memory cage enabled protects them from a large class of nasty V8 vulnerabilities.

Lastly, there are workarounds for apps that really need a larger heap size. For example, it is possible to include a copy of Node.js with your app, which is built with pointer compression disabled, and move the memory-intensive work to a child process. Though somewhat complicated, it is also possible to build a custom version of Electron with pointer compression disabled, if you decide you want a different trade-off for your particular use case. And lastly, in the not-too-distant future, wasm64 will allow apps built with WebAssembly both on the Web and in Electron to use significantly more than 4GB of memory.

Preguntas más frecuentes​

How will I know if my app is impacted by this change?​

Attempting to wrap external memory with an ArrayBuffer will crash at runtime in Electron 20+.

If you don't use any native Node modules in your app, you're safe—there's no way to trigger this crash from pure JS. This change only affects native Node modules which allocate memory outside of the V8 heap (e.g. using malloc or new) and then wrap the external memory with an ArrayBuffer. This is a fairly rare use case, but some modules do use this technique, and such modules will need to be refactored in order to be compatible with Electron 20+.

How can I measure how much V8 heap memory my app is using to know if I'm close to the 4GB limit?​

In the renderer process, you can use performance.memory.usedJSHeapSize, which will return the V8 heap usage in bytes. In the main process, you can use process.memoryUsage().heapUsed, which is comparable.

What is the V8 memory cage?​

Some documents refer to it as the "V8 sandbox", but that term is easily confusable with other kinds of sandboxing that happen in Chromium, so I'll stick to the term "memory cage".

There's a fairly common kind of V8 exploit that goes something like this:

1. Find a bug in V8's JIT engine. JIT engines analyze code in order to be able to omit slow runtime type checks and produce fast machine code. Sometimes logic errors mean it gets this analysis wrong, and omits a type check that it actually needed—say, it thinks x is a string, but in fact it's an object.
2. Abuse this confusion to overwrite some bit of memory inside the V8 heap, for instance, the pointer to the beginning of an ArrayBuffer.
3. Now you have an ArrayBuffer that points wherever you like, so you can read and write any memory in the process, even memory that V8 normally doesn't have access to.

The V8 memory cage is a technique designed to categorically prevent this kind of attack. The way this is accomplished is by not storing any pointers in the V8 heap. Instead, all references to other memory inside the V8 heap are stored as offsets from the beginning of some reserved region. Then, even if an attacker manages to corrupt the base address of an ArrayBuffer, for instance by exploiting a type confusion error in V8, the worst they can do is read and write memory inside the cage, which they could likely already do anyway. There's a lot more available to read on how the V8 memory cage works, so I won't go into further detail here—the best place to start reading is probably the high-level design doc from the Chromium team.

I want to refactor a Node native module to support Electron 21+. How do I do that?​

There are two ways to go about refactoring a native module to be compatible with the V8 memory cage. The first is to copy externally-created buffers into the V8 memory cage before passing them to JavaScript. This is generally a simple refactor, but it can be slow when the buffers are large. The other approach is to use V8's memory allocator to allocate memory which you intend to eventually pass to JavaScript. This is a bit more involved, but will allow you to avoid the copy, meaning better performance for large buffers.

To make this more concrete, here's an example N-API module that uses external array buffers:

// Create some externally-allocated buffer.
// |create_external_resource| allocates memory via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Wrap it in a Buffer--will fail if the memory cage is enabled!
napi_value result;
napi_create_external_buffer(
    env, length, data,
    finalize_external_resource, NULL, &result);

This will crash when the memory cage is enabled, because data is allocated outside the cage. Refactoring to instead copy the data into the cage, we get:

size_t length = 0;
void* data = create_external_resource(&length);
// Create a new Buffer by copying the data into V8-allocated memory
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// If you need to access the new copy, |copied_data| is a pointer
// to it!

This will copy the data into a newly-allocated memory region that is inside the V8 memory cage. Optionally, N-API can also provide a pointer to the newly-copied data, in case you need to modify or reference it after the fact.

Refactoring to use V8's memory allocator is a little more complicated, because it requires modifying the create_external_resource function to use memory allocated by V8, instead of using malloc. This may be more or less feasible, depending on whether or not you control the definition of create_external_resource. The idea is to first create the buffer using V8, e.g. with napi_create_buffer, and then initialize the resource into the memory that has been allocated by V8. It is important to retain a napi_ref to the Buffer object for the lifetime of the resource, otherwise V8 may garbage-collect the Buffer and potentially result in use-after-free errors.

Electron está cambiando su S3 bucket principal, es posible que debas actualizar tus scripts de construcción

¿Qué está pasando?

A significant amount of Electron's build artifacts are uploaded to an S3 bucket called gh-contractor-zcbenz. As part of ongoing infrastructure/ownership migrations that started way back in 2020, we will be changing everything that used gh-contractor-zcbenz from its old home in S3 to a new storage system hosted at https://artifacts.electronjs.org. The path prefix that most of our assets use is changing slightly as well. Los ejemplos se incluyen a continuación:

Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib After: https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib

The important things here are the Hostname changed and the /atom-shell prefix changed. Another example, this time for debug symbols:

Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb After: https://artifacts.electronjs.org/symbols/path/to/symbol.pdb

Again, the hostname changed and the /atom-shell prefix was changed.

¿Cómo puede influir en ti?

Anyone using standard build tooling such as electron-rebuild, electron-packager or @electron/get won't have to do anything. This should be the majority of people.

For anyone directly referencing the S3 bucket, you must update your reference to point at the hostname and update the path as well.

¿Qué pasa con los datos existentes?

Most data that existed on the gh-contractor-zcbenz bucket has been cloned into the new storage system. This means all debug symbols and all headers have been copied. If you relied on some data in that bucket that hasn't been copied over please raise an issue in electron/electron and let us know.

The current gh-contractor-zcbenz S3 bucket will not be actively deleted. However, we can't guarantee how long that bucket will be left alive. We strongly recommend updating to target the new bucket as soon as possible.

El proyecto de Electron realizará una pausa para el mes de diciembre de 2021, para después regresar a toda velocidad en enero de 2022.

vía GIPHY

Lo que será igual en diciembre​

1. Los lanzamientos de día cero y los lanzamientos principales relacionados con la seguridad se publicarán según sea necesario. Los incidentes de seguridad se deben reportar a través de SECURITY.md.
2. Los reportes del Código de Conducta y moderación continuarán.

Lo que será diferente en diciembre​

1. No se publicarán versiones estables o de prueba en diciembre. No se publicarán las versiones anticipadas durante las últimas dos semanas de diciembre.
2. Con algunas excepciones, no se realizará la revisión o fusión de pull requests.
3. No se actualizará el rastreador de incidencias en ningún repositorio.
4. No se ayudará con la depuración en Discord por parte de los encargados.
5. No se publicarán actualizaciones de contenido en las redes sociales.

¿Por qué sucede esto?​

En resumen, mientras los mantedores están felices y conectados con el proyecto, EL MUNDO ESTÁ CANSADO. Diciembre es un mes tranquilo para la mayoría de las compañías, por lo que queremos darle a los mantenedores una oportunidad de recargar. Animamos a otros proyectos a considerar medidas similares.

¿Debo preocuparme por el futuro de Electron?​

No. Somos capaces de tomar este paso porque el proyecto se encuentra en buena forma. Todos esperan el 2022 y ¡esperamos que vengan buenas cosas!

A partir de septiembre de 2021, Electron lanzará una nueva versión principal estable cada 8 semanas.

En 2019, Electron comenzó un ciclo de 12 semanas para cada lanzamiento para coincidir con el ciclo de 6 semanas de Chromium. Recientemente, tanto Chrome como Microsoft anunciaron cambios que nos hicieron reconsiderar la cadencia de lanzamiento actual de Electron:

1. Chromium planea lanzar un nuevo hito cada 4 semanas, comenzando con Chrome 94 el 21 de septiembre de 2021. Esta frecuencia también añade una nueva opción de Estabilidad Ampliada cada 8 semanas, que contendrá todas las correcciones de seguridad actualizadas.

2. La tienda de Microsoft exigirá que las aplicaciones basadas en Chromium no tengan más de dos años de antigüedad. Por ejemplo, si la última versión principal publicada de Chromium es la 85, cualquier navegador basado en Chromium debe estar al menos en la versión 83 o superior. Esta norma incluye las aplicaciones Electron.

Empezando en septiembre de 2021, Electrón lanzará una nueva versión mayor estable cada 8 semanas, coincidiendo con las 8 semanas de Extensión de Lanzamientos Estables de Chromium.

Nuestro primer lanzamiento con la Extensión de Lanzamientos Estables de Chromium será Electrón 15 en el 21 de septiembre de 2021.

Sabiendo que un cambio en la frecuencia de lanzamiento afectará a otras aplicaciones posteriores, queríamos informar a nuestra comunidad de desarrolladores lo antes posible. Siga leyendo para conocer más detalles sobre nuestro calendario de lanzamientos para 2021.

Electron 15: Alpha temporal​

Dado que nuestro lanzamiento original de Electron 15 apuntaba a una versión no estable extendida (las versiones estables extendidas de Chromium se basan en sus versiones pares), tuvimos que cambiar nuestra fecha original de lanzamiento. Sin embargo, una aplicación de Electron debe utilizar las dos versiones principales más recientes de Chromium para ser aceptada en la tienda de Microsoft, lo que hacía insostenible la espera de dos versiones de Chromium.

Con estos dos requisitos, nuestro equipo se enfrentó a un dilema de tiempos. Mover Electron 15 para incluir Chromium M94 permitiría a los desarrolladores de aplicaciones entrar en la primera versión estable extendida de Chromium; sin embargo, también acortaría el ciclo de beta estable a solo 3 semanas.

Para ayudar con este cambio, Electron ofrecerá una construcción alfa temporal, solo para la versión de Electron 15. Esta versión alfa permitirá a los desarrolladores disponer de más tiempo para probar y planificar el lanzamiento de Electron 15, con una versión más estable que las actuales versiones.

La compilación del canal alfa se lanzará para Electron 15 el 20 de julio de 2021. Pasará a una versión beta el 1 de septiembre de 2021 con un objetivo de lanzamiento estable el 21 de septiembre de 2021. Las siguientes versiones de Electron no tendrán versiones alfa.

Plan 2021 para lanzamientos​

A continuación se muestra nuestro calendario de lanzamiento actual para 2021:

La incorporación del canal alfa amplía el tiempo de desarrollo antes del lanzamiento de Electron 15 de 3 a 9 semanas, más cerca de nuestro nuevo ciclo de 8 semanas, sin dejar de cumplir los requisitos para la presentación en la tienda de Windows.

Para ayudar aún más a los desarrolladores de aplicaciones, durante lo que queda de 2021 hasta mayo de 2022, también ampliaremos nuestra política de versiones soportadas de las últimas 3 versiones a las últimas 4 versiones de Electron. Eso significa que, aunque no puedas modificar inmediatamente tu calendario de actualizaciones, las versiones más antiguas de Electron seguirán recibiendo actualizaciones y correcciones de seguridad.

Responder a las inquietudes​

Hay una razón por la que publicamos este post mucho antes de que esté previsto este cambio de ciclo de lanzamiento. Sabemos que un ciclo de lanzamiento más rápido tendrá un impacto real en las aplicaciones de Electron, algunas de las cuales ya pueden encontrar nuestra frecuencia de lanzamiento mayor agresiva.

A continuación hemos tratado de responder a las preocupaciones más comunes:

¿Por qué hacer este cambio? ¿Por qué no mantener la cadencia de publicación de 12 semanas?​

Para entregar las versiones más actualizadas de Chromium en Electron, nuestro programa necesita seguir el suyo. Puede encontrar más información sobre el ciclo de lanzamiento de Chromium aquí.

Además, la cadencia actual de publicación de 12 semanas sería insostenible con los nuevos requisitos de presentación de Microsoft Store. Incluso las aplicaciones en la última versión estable de Electron experimentarían un período de aproximadamente dos semanas en el que su aplicación puede ser rechazada bajo los nuevos requisitos de seguridad.

Cada nueva versión de Chromium contiene nuevas características, correcciones de errores / correcciones de seguridad y mejoras de V8. Queremos que usted, como desarrolladores de aplicaciones, tenga estos cambios en el momento oportuno, para que nuestras fechas de lanzamiento estables sigan coincidiendo con todas las otras versiones estables de Chromium. Como desarrollador de aplicaciones, tendrás acceso a las nuevas características de Chromium y V8 y los arreglos mucho antes.

❓ El programa de liberación de 12 semanas existente ya se mueve rápidamente. ¿Qué pasos está dando el equipo para facilitar la actualización?​

Una ventaja de lanzamientos más frecuentes es tener versiones más pequeñas. Entendemos que actualizar las versiones más importantes de Electron puede ser difícil. Esperamos que los lanzamientos más pequeños introduzcan menos cambios importantes en Chromium y Node, así como menos cambios de ruptura, por lanzamiento.

❓ ¿Habrá una versión alfa disponible para futuras versiones de Electron?​

No hay planes de soportar una versión alfa permanente en este momento. Este alfa sólo está pensado para Electron 15, como una manera de ayudar a los desarrolladores a actualizarse más fácilmente en el período de lanzamiento acortado.

❓ ¿Electron extenderá el número de versiones soportadas?​

Ampliaremos nuestra política de versiones soportadas desde las últimas tres versiones hasta las últimas cuatro versiones de Electron hasta mayo de 2022, con el lanzamiento de Electron 19. Después de que Electron 19 sea lanzado, volveremos a soportar las tres últimas versiones principales, así como los lanzamientos beta y nocturnos.

¿Preguntas?​

📨 Si tienes preguntas o preocupaciones, por favor envíanos un correo electrónico a info@electronjs.org o únete a nuestro Discord. Sabemos que esto es un cambio que afectará a muchas aplicaciones y desarrolladores, y tus comentarios son muy importantes para nosotros. ¡Queremos saber tu opinión!