Estrella del Norte

De niño, estaba obsesionado con el espacio. Me encantaba venir a lugares como este. En noches despejadas, salía al jardín trasero con mi padre, él mismo un poco fanático del espacio, y él me enseñaba a leer el cielo. Me enseñó los nombres de las estrellas y las constelaciones. Me enseñó que las cosas que parecen más fijas no lo son, pero que a través de una cuidadosa observación puedes comenzar a predecir sus movimientos. Y me enseñó cómo encontrar la Estrella del Norte.

En una noche clara, si puedes encontrar la Osa Mayor, entonces puedes extender esta línea un poco más para encontrar Polaris, llamada así porque una línea trazada desde el Polo Sur hasta el Polo Norte y extendida al espacio casi la alcanzaría. Es el punto fijo alrededor del cual giran los cielos y siempre apunta hacia el norte. Los antiguos marineros usaban Polaris para cruzar los océanos. En los primeros Estados Unidos, los esclavos fugitivos la seguían hacia la libertad. Hoy en día no tendemos a depender de la navegación celestial, tenemos Google Maps. Pero he estado pensando mucho últimamente sobre este concepto de poder orientarnos en un entorno por lo demás incierto y cómo se aplica a otras áreas de nuestras vidas. ¿Qué significa estar apuntando en la dirección correcta?

Me llamo Rich Harris, puedes encontrarme en richharris.dev en Blue Sky, esta es una charla sobre encontrar dirección y propósito en el código abierto. Como muchos de ustedes, escribo software para ganarme la vida. Más específicamente, trabajo en una interfaz de usuario llamada Svelte. Comencé a trabajar en Svelte hace ocho años y tres días. Comenzó como un proyecto paralelo inocente y divertido que no tenía idea de que tomaría el control de mi vida. La gran idea era esta. ¿Qué pasaría si un framework, en lugar de ser código que se ejecuta en el navegador, fuera un compilador que transformara tu componente en JavaScript autónomo? Lo llamamos el framework mágico que desaparece y en comparación con React, producía paquetes asombrosamente eficientes. Porque movía el trabajo fuera del navegador y dentro de tu proceso de construcción, podíamos hacer que tus aplicaciones fueran realmente pequeñas y realmente rápidas.

Svelte tres salió en 2019 y planteó una pregunta diferente. ¿Podemos usar el compilador para hacer que el desarrollo web en sí sea más rápido? Si no estamos limitados por las reglas de JavaScript, ¿podemos hacer que los componentes sean más fáciles de escribir con menos código repetitivo? Ese fue el punto en el que la gente realmente comenzó a prestar atención a Svelte.

Resulta que aunque la mayoría de los desarrolladores se preocupan profundamente por el rendimiento y el tamaño del paquete en teoría, en la práctica elegimos las herramientas que disfrutamos usar. Algunos líderes de opinión intentarán avergonzarte por esto. Pero creo que es bastante razonable que si vas a pasar 40 horas a la semana trabajando en algo, también podría ser divertido. Y con los compiladores, una mejor experiencia de desarrollador no tiene por qué venir a expensas de la experiencia del usuario. Y Svelte tiene una muy buena experiencia de desarrollador, al menos según encuestas como el estado de JavaScript. No sé cuánto tiempo podemos mantener esta racha, pero estoy emocionado de averiguarlo.

Svelte por sí solo solo resuelve una pequeña parte del problema de construir una aplicación web. A saber, mantener el DOM en sincronía con tu estado de aplicación. Y deja todo lo demás para ti, como configurar tus herramientas de construcción, organizar tu código, definir tus rutas, generar paquetes óptimos y desplegar en diferentes entornos y muchos, muchos otros problemas. En 2020, comenzamos a trabajar en un proyecto complementario llamado SvelteKit, que fue el primer gran framework construido sobre Vite. Está diseñado para resolver esos problemas por ti.

Todo lo cual es para decir que el proyecto ha tenido muchas identidades a lo largo de su vida. El mes pasado, lanzamos Svelte 5. En un nivel, es muy una continuación. Es una versión compatible hacia atrás, que puedes incorporar en un proyecto existente con mínima interrupción. Pero en otro, es el cambio más radical que el proyecto ha experimentado hasta ahora. Así que en este punto, permíteme tomar un momento para presentarte o reintroducirte al nuevo Svelte.

A diferencia de React, Svelte es innegablemente HTML primero. JavaScript es un lenguaje de propósito general decente. Pero como lenguaje para describir interfaces de usuario, es una mala combinación. Cuando escribes JavaScript, te preocupas principalmente por los cambios entre estados que resultan de la interacción del usuario. Pero cuando describes una interfaz de usuario, te preocupas principalmente por los estados mismos. Los frameworks colocan una capa declarativa sobre JavaScript que te permite fingir. Pero a menudo te encuentras trabajando en contra de la corriente del lenguaje.

Svelte toma un enfoque diferente. Toma HTML como punto de partida. Si tienes algún HTML válido, ya sea que lo escribiste tú mismo o co-pilot lo escribió por ti o lo encontraste en CodePen o StackOverflow o incluso en las DevTools de tu navegador, puedes colocar eso en un componente Svelte y funcionará. Lo mismo no es cierto para JSX, que superficialmente se asemeja a HTML, pero lo cambia de varias maneras sutiles y molestas.

Así como un documento HTML puede contener un elemento de estilo, que afectará a ese documento, un componente de Svelte puede contener un elemento de estilo cuyo contenido afectará a ese componente. Los selectores aquí no coincidirán con elementos en otros componentes, lo que significa que no necesitas evitar manualmente conflictos dando a todo un nombre de clase complicado y esperando lo mejor.

Aquí solo estamos usando un selector P. Puedes, por supuesto, usar Tailwind y mucha gente lo hace, pero los problemas que Tailwind resuelve no son tan aplicables cuando tienes estilos de alcance nativo. Y CSS es posiblemente más a prueba de futuro. Al igual que en JavaScript y TypeScript tu editor te dirá si tienes una variable no utilizada y tu minificador la eliminará de tu compilación de producción, Svelte eliminará estilos no utilizados.

Podemos, por supuesto, usar JavaScript. Podemos usar valores directamente en nuestro marcado o referenciar valores que están definidos en la etiqueta de script del componente. Lo más probable es que quieras mantener tu UI actualizada cuando los valores de esas variables cambien. Para eso, necesitamos que sean reactivos. Este es el mayor cambio de Svelte 4 a Svelte 5. Svelte 4 haría automáticamente que las variables fueran reactivas si pensaba que era necesario. Este era un proceso sobre el cual no tenías control directo. En Svelte 5, anotamos explícitamente el estado con algo llamado rune. Una rune es una instrucción para el compilador que, en el caso de esta rune de estado dólar, le dice que convierta el valor en algo llamado señal. La forma en que interactúas con el valor no cambia. Sigue siendo solo un número en lugar de una función u objeto. Pero el compilador sabe que cada vez que lee ese valor, como en este atributo, o escribe en él, como en este controlador de eventos, necesita desenvolver la señal. Podemos simplificar este código reemplazándolo con una vinculación. Esto hace lo mismo que el código existente, pero es una mejor articulación de la intención de tu aplicación. Svelte tiene muchas de estas características que simplifican tareas comunes.

Por ejemplo, si quieres darle un poco de dinamismo a tu UI, puedes agregar transiciones, que usan una API de animaciones web para controlar lo que sucede cuando los elementos entran o salen del DOM. Importaremos la transición fly de Svelte y una función de easing de Svelte easing y agregaremos esa transición a este elemento span. Ahora, cuando agregamos esta transición, los elementos se desvanecen suavemente dentro y fuera. Y dentro, y fuera, y dentro, y fuera, y dentro, y fuera. La reactividad en Svelte se aplica profundamente a objetos y arreglos y es de grano fino. En este ejemplo, puedo agregar un to do simplemente llamando a to dos.push. Si lo hago, o si cambio el estado de hecho de un to do individual, el número de to dos restantes se recalcula, lo que puedes ver porque lo hemos envuelto en una función que llama a nuestra función de alerta modificada. Pero si editamos el texto del to do, no pasa nada. Porque remaining no se ve afectado por el contenido de texto de estos to dos.

Contrasta esto con React, por ejemplo, donde el valor predeterminado es recalcular agresivamente todo el tiempo. Una de las principales limitaciones de Svelte 4 era que la reactividad solo ocurría dentro de los componentes. Si querías tener algún estado global compartido o alguna lógica reactiva reutilizable, entonces tenías que escribir código de una manera completamente diferente. En Svelte 5, eso ya no es el caso. Puedes usar runes en módulos Svelte.js y Svelte.ts así como en componentes.

Esencialmente, hemos agregado la reactividad como una construcción a nivel de lenguaje a JavaScript y TypeScript. Ahora, ciertamente no somos el primer framework en tener reactividad de grano fino con señales. Muchos frameworks expondrán una función para crear señales, que podría tomar la forma de una clase con una propiedad de valor reactivo o un par de funciones para leer y escribir valores. Así que, podrías pensar que Svelte está haciendo lo mismo que todos los demás. Pero en realidad estamos haciendo algo bastante diferente.

Por un lado, cuando escribes código, no estás lidiando con una API de framework. Solo estás tratando con valores normales. El compilador convierte tu código en algo como esto. Porque no necesitamos preocuparnos por la ergonomía de la API de señales, bajo el capó, una señal de Svelte es solo un objeto JavaScript simple, que es muy barato de crear y actualizar comparado con los otros métodos. No estamos jugando con cierres y cadenas de prototipos y lo que sea. Como resultado, el rendimiento de Svelte es bastante difícil de superar.

Este es un reciente benchmark de terceros que comparó implementaciones de señales a través de diferentes bibliotecas. Svelte es el segundo más rápido detrás de una biblioteca experimental que ya no se mantiene. Pero va más allá de eso. Dado que deliberadamente no exponemos el mecanismo de creación de señales, en muchos casos, podemos evitar crear una señal por completo. Por ejemplo, durante la renderización del lado del servidor donde nada es reactivo o cuando detectamos que un fragmento de estado se actualiza pero nunca se reasigna directamente. De manera similar, si el compilador detecta que un fragmento de tu marcado no contiene estado reactivo, no necesita rastrear nada. Puede simplemente inicializar el DOM y alejarse. Llamamos a esto reactividad aumentada por el compilador. El código generado por el compilador de Svelte es más pequeño y más eficiente en términos de rendimiento y memoria. Incluso si una implementación de señal más rápida aparece, no será más rápida que no crear una que no necesitabas en primer lugar.

No es magia, pero es bastante mágico. Así que, ocho años es mucho tiempo en JavaScript. Y Svelte ha evolucionado mucho a lo largo de su vida. Nos gusta decir que se ha vuelto más como sí mismo.

De la misma manera que las personas crecen en sí mismas, Svelte ha sobrevivido a su adolescencia incómoda y a sus años universitarios pretenciosos y ahora es un software joven pero maduro al comienzo de su carrera profesional. El proyecto tiene cientos de colaboradores y cientos más de patrocinadores financieros, no menos Vercel, que emplea a tres de nosotros para trabajar en él a tiempo completo.

Y el lanzamiento de Svelte 5 es un buen momento para tomarse un momento y preguntarnos, ¿qué es lo que esperamos lograr con todo este trabajo? Esta pregunta se me hizo evidente recientemente durante una conversación con Simon Halthausen, quien junto conmigo y Dominic Gannoway es uno de los tres miembros del equipo a tiempo completo. Simon dijo, y parafraseo, tenemos una lista interminable de ideas que queremos llevar a cabo después de lanzar Svelte 5. ¿Cómo priorizamos ese trabajo? ¿Cómo añadimos todas estas cosas sin cambiar la naturaleza fundamental de Svelte? ¿Cómo nos aseguramos de que estamos apuntando en la dirección correcta? ¿Cuál es nuestra estrella del norte?

Es una pregunta interesante de intentar responder. La mayoría de nosotros pasamos por la vida muchas veces en piloto automático, sin pensar realmente en qué impacto estamos tratando de tener en el mundo. Particularmente si trabajas en un proyecto de código abierto, sabrás lo que es pasar tus días luchando con problemas y solicitudes de características y rara vez tener tiempo para alejarse. Pero tómate un momento para pensarlo.

Una forma de abordarlo es intentar identificar las cosas en las que crees. Particularmente si esas creencias son contrarias. A principios de este año hice precisamente eso en un post llamado Tenets, en el que intenté codificar algunas de las cosas que nos motivan. Número uno, la web importa. Trabajamos en Svelte porque creemos que la web es una tecnología críticamente importante y que su supervivencia continua no está garantizada. Número dos, optimizar para las vibras. Así es, América, lo escribo con una S. La gente usa Svelte porque les gusta Svelte. Les gusta porque se alinea con sus sensibilidades estéticas. En lugar de esforzarnos por ser el más rápido o el más pequeño o lo que sea, apuntamos explícitamente a ser el framework con las mejores vibras. Número tres, optimizar para la adopción. No estamos tratando de ser el framework más popular. Estamos tratando de ser el mejor framework. A veces eso significa tomar decisiones en las que creemos pero que van en contra de la corriente de las tendencias de desarrollo web, como HTML, el idioma madre. Es un idioma realmente bueno para describir UI. Svelte aumenta HTML de una manera que lo hace un idioma realmente bueno para describir UI interactiva. Número cinco, abrazar el progreso. Hay una tendencia en la comunidad de desarrolladores web hacia una forma dañina de nostalgia pesimista. La idea de que las cosas eran mejores en la era prelapsaria y antes de los empaquetadores, Typescript, el enrutamiento del lado del cliente y otros adornos de la modernidad. Esto es un sinsentido. Como comunidad, nuestra posición predeterminada es de optimismo sobre la tecnología. La plataforma está mejorando, nuestras herramientas están mejorando, nuestros dispositivos están mejorando, y si abrazamos ese hecho podemos hacer cosas mejores.

Número seis, los números mienten. Lighthouse ha roto el cerebro de una generación de desarrolladores web. Hemos reemplazado el buen juicio con la sumisión a métricas que solo estaban destinadas a ser utilizadas como una herramienta de diagnóstico. Prestamos atención a los números, pero al diseñar Svelte, pensamos cualitativamente, no cuantitativamente.

Número siete, mágico, magia de Svelte. Queremos que Svelte se sienta mágico, queremos que te sientas como un mago cuando estás usando Svelte. Históricamente, creo que Svelte fue demasiado lejos en el territorio mágico donde no está 100 por ciento claro por qué las cosas funcionan de cierta manera. Eso es algo que estamos tratando de rectificar con Svelte 5.

Número ocho, soñar en grande. Elegir la herramienta adecuada para el trabajo es un consejo sensato pero aburrido. Nos hace pequeños en nuestras ambiciones. Quiero que soñemos más grande. No quiero sentir que mis herramientas no pueden manejar requisitos en evolución o si quiero incursionar en un nuevo campo necesito aprender una forma completamente nueva de trabajar primero. Incluso si resulta ser inalcanzable, encuentro valioso hacer la pregunta ¿qué se necesitaría para que Svelte Git sea el mejor framework para cualquier aplicación, ya sea contenido puramente estático o una aplicación multijugador en tiempo real, una aplicación de productividad offline primero, o incluso algo construido para un casco de realidad aumentada? Como ingenieros, nos encanta hablar sobre compensaciones hasta el punto en que instintivamente creemos que ser bueno en una cosa te hace malo en otras cosas. Pero eso es una mentalidad de escasez. De la misma manera que los avances en energía solar y almacenamiento de baterías y fusión nuclear están al borde, creo, de remodelar la civilización, los avances en herramientas significan que los desarrolladores web están viviendo en una época de abundancia. Necesitamos remodelar nuestra mentalidad en consecuencia. Recuerda el punto cinco. Somos optimistas.

Número nueve, a nadie le importa. La mayoría de las personas no se preocupan por los frameworks. Solo quieren construir algo genial, y Svelte es para esas personas también. Esto informa nuestro enfoque a la documentación y los tutoriales. Debería ser posible construir lo que quieras solo aprendiendo los conceptos que necesitas en el momento y preocupándote por las otras cosas otro día. Me gusta llamar a esto documentación justo a tiempo.

Número diez, diseño por consenso. Svelte es un proyecto impulsado por la comunidad y liderado por consenso. Muchas de las mejores ideas de Svelte se originaron fuera del equipo central. Es importante que la comunidad tenga un interés en el futuro del proyecto. Estos principios guían nuestras acciones, pero ninguno de ellos califica como una estrella del norte. No nos dicen qué hacer tanto como cómo hacerlo.

Hace unas semanas, cuando los mantenedores de Svelte se reunieron en línea para nuestra reunión mensual, este fue nuestro tema principal de discusión. ¿Hacia qué estamos esforzándonos? ¿Cuál es el cambio que esperamos lograr en el mundo? Surgieron muchas ideas en esa discusión, pero seguimos volviendo a una en particular. El software está roto. Creo que todos saben a qué me refiero con esto. La mayoría de nosotros probablemente hemos tenido la experiencia de eliminar un elemento en DevTools o quitar el atributo deshabilitado de un botón para poder enviar un formulario, o esperar 30 segundos para que un pago se procese antes de ver una página de meditación guru sin estilo y no saber si tuvo éxito, o ayudar a un familiar a realizar alguna tarea básica porque la aplicación que están usando es simplemente demasiado confusa.

Te ofrezco un desafío. Durante el transcurso de una semana, toma nota de cada vez que uses un software y falle de alguna manera básica. Una aplicación que se bloquea o no arranca, una casilla de recordar en este ordenador que no hace nada, un código de error visible que no significa nada y no ofrece ninguna acción correctiva. Cuando Spotify se queda atascado en el limbo entre el modo offline y online, toma nota de ello. Cuando GitHub muestra datos obsoletos o elimina la pieza de la interfaz de usuario con la que estás a punto de interactuar o colapsa conversaciones hasta el punto de inutilidad, toma nota de ello. Cuando la aplicación web móvil de Twitter falla al abrir la pestaña de DM, toma nota de ello. Cuando la aplicación web de Instagram rompe el botón de retroceso, toma nota de ello. Cuando tu teléfono suena pero el cajón de notificaciones solo muestra correos de hace una semana, toma nota de ello. Cuando el comando clic abre un enlace en la pestaña actual en lugar de una nueva, toma nota de ello. Cuando intentas leer un artículo pero tu teléfono se bloquea debido a toda la basura de seguimiento y la tecnología publicitaria mal codificada, toma nota de ello. Cuando estás caminando por una ciudad y ves una pantalla azul de la muerte en un cajero automático o una pantalla de publicidad, toma nota de ello. Estas son todas cosas que experimento todo el tiempo. Y podría seguir por un tiempo, pero entiendes el punto.

Hay una razón por la que este chiste de The IT Crowd resuena. Aquellos de nosotros que trabajamos en tecnología simplemente hemos decidido que esto es aceptable y a medida que el software se come el mundo, tratamos de convencer a todos los demás de que también es aceptable. Pero no lo es.

Como industria, hemos fallado. Merecemos que la inteligencia artificial nos quite nuestros trabajos. Sin embargo, no imagines ni por un momento que la inteligencia artificial nos salvará. Si has prestado atención a la ranura de IA que está inundando las redes sociales o Amazon o Google, entonces ya sabes que estamos enfrentando un tsunami inminente de software basura.

Así que, si cada aspecto de nuestras vidas va a ser mediado por software, deberíamos aspirar a algo mejor. Quiero un software que sea increíble, resiliente, accesible, encantador. Resiliente significa que funciona, es seguro y se degrada de manera elegante frente a redes intermitentes, dispositivos con poca potencia y entradas de usuario inesperadas. Accesible significa que funciona para todos, no solo para personas sin discapacidad con teléfonos caros y planes de datos ilimitados. Encantador significa que espero usarlo porque confío en que me ayudará a completar mi tarea rápidamente y sin tonterías.

Entonces, en términos concretos, ¿qué significaría orientar explícitamente un proyecto alrededor de estos problemas? Algunas cosas son obvias. Actualmente estamos priorizando los límites de error y mejores primitivas de depuración para que sea más fácil hacer que tus aplicaciones sean resilientes. También queremos invertir en herramientas para desarrolladores realmente buenas. Me gusta mucho la idea detrás de la barra de herramientas de desarrollador de Astro y creo que deberíamos copiarla para poder proporcionar mejores diagnósticos de accesibilidad que los que generamos al analizar estáticamente tu código. Este enfoque también nos ayuda a pensar sobre de qué nos consideramos responsables. Pasamos mucho tiempo en el mundo de JavaScript hablando sobre si deberíamos tener nuestro propio Laravel o Rails. ¿Debería SvelteKit tener opiniones sobre bases de datos y desarrollo local primero? ¿Deberíamos tener una biblioteca de componentes oficial? Tal vez.

Parte de esto es aún más especulativo. Dado que la IA es una realidad de nuestro trabajo ahora, nos estamos haciendo preguntas como ¿cómo podemos asegurarnos de que la IA generativa sepa cómo construir componentes Svelte de alta calidad? O mejor que tener una IA tratando de escribir nuestras aplicaciones por nosotros, ¿podríamos algún día usarla para ayudar a llenar los vacíos en QA y pruebas de usuario para que tengamos menos puntos ciegos? No tenemos las respuestas a todas estas preguntas. Pero saber qué preguntas hacer es un paso en la dirección correcta. Esto, para mí, es una misión que vale la pena inscribirse. Amo la web y quiero hacer mi parte para preservarla para las generaciones venideras. Si podemos empujarla en la dirección correcta, aunque sea un poco, habrá valido la pena. La Estrella del Norte cambia con el tiempo porque la tierra es inestable. Hoy es Polaris. Cuando los antiguos egipcios construyeron las pirámides, las orientaron hacia una estrella llamada Thuban, y en siglos venideros, Polaris será usurpada. Así también, nuestras prioridades cambiarán como lo han hecho antes. Pero por ahora, esta es nuestra Estrella del Norte.

Svelte existe para ayudarnos a hacer mejor software. Gracias por escuchar. Una última cosa. Kevin de Svelte Society está en algún lugar de esta sala con una docena de camisetas de Svelte. Si quieres una, ve a buscarlo. Gracias.

Muy bien. Tu primera pregunta viene de Anónimo, y es, ¿cuál es la única cosa que desearías que la gente supiera sobre construir software de código abierto o Svelte que no es obvio desde afuera? ¿Sobre construir software de código abierto en general? Es mucho más difícil de lo que piensas, solo en términos de la cantidad de trabajo que tienes que hacer. Publiqué en Blue Sky el otro día sobre el hecho de que habían pasado ocho años desde el día en que comencé Svelte, y alguien respondió con, espera un minuto, la versión uno salió como una semana después. Y la versión uno es fácil. Es todo el resto de las cosas que toma el tiempo. Tienes que escribir documentación, tutoriales, tienes que construir una comunidad, tienes que hacer mucho, escribir pruebas, todas estas cosas. Y yo, por mi parte, he subestimado repetidamente bastante significativamente cuánto trabajo está involucrado. Lo cual no es para disuadir a nadie de embarcarse en un proyecto de código abierto, pero definitivamente es algo en lo que deberías entrar con los ojos bien abiertos. Definitivamente.

Muy bien. Esta siguiente creo que puede estar relacionada con tu trabajo con Rollup, porque están preguntando sobre Rust. Están diciendo, ¿ves a Rust convirtiéndose en el lenguaje predeterminado para el análisis o las herramientas de construcción en el futuro o crees que esto debería suceder? Claramente está sucediendo. Hay mucho impulso alrededor de esa idea. No soy un Rustation, así que si esto sucede, siento que o me voy a tener que alinear o me voy a quedar fuera de ello. Me gusta el hecho de que tenemos la capacidad de escribir nuestras herramientas en el lenguaje con el que todos estamos familiarizados. Y creo que eso ha sido un verdadero beneficio para toda nuestra comunidad. Y parte de mí está definitivamente un poco triste con el cambio a herramientas de lenguaje nativo, podríamos perder un poco de eso. Pero aquí está esperando que no suceda.

Definitivamente. Bien. Yo también tenía esta pregunta. Me alegra que alguien más la haya hecho. ¿Cuál es tu velocidad de escritura por minuto?

¿Cuál es tu velocidad de escritura por minuto? ¿Y estabas escribiendo esos ejemplos? ¿Eres realmente tan rápido? Bien. Increíble.

Tendré que añadir eso a mi bolsa de trucos.

Esta es de Ben. ¿Puedes elaborar sobre las partes de Svelte que crees que eran demasiado mágicas en el pasado? Entonces, la principal era que las variables se volvían automáticamente reactivas. Mientras que hoy tenemos lo que ahora llamamos reactividad aumentada por el compilador. En Svelte 3 y 4 teníamos reactividad impulsada por el compilador. Lo que significa que decíamos que una variable era reactiva si se declaraba en el nivel superior de un componente y se reasignaba en algún lugar dentro de tu componente. Y luego, si queríamos tener un cálculo o lo que ahora llamamos derives, entonces secuestrábamos una pieza de sintaxis, la sintaxis de etiqueta, dólar etiqueta, y luego cualquier cosa que siguiera se volvería a ejecutar automáticamente cuando cualquiera de las piezas de estado que se referencian dentro de ese bloque cambie. Y esto funciona muy bien para casos simples. Y la gente realmente lo quiere. Pero resulta que si construyes aplicaciones muy grandes, la reactividad impulsada por el compilador simplemente no funciona. Te encuentras con los límites de lo que puedes hacer con el análisis estático. Y eso es exactamente lo que encontramos. Por eso cuando empezamos a pensar en el futuro de Svelte, miramos alrededor, todos los demás habían entrado en el mundo de los signals, y dijimos, sí, tomaremos algo de eso. Y honestamente, es mucho mejor. Diré en mi experiencia, porque he escrito mucho en Svelte y luego aprendiendo Svelte 5, encuentro que Svelte 5 hace que los problemas más simples sean un poco más difíciles, pero los problemas más complejos mucho más simples. Porque me encontré con problemas con la sintaxis de etiqueta. Es muy fácil entrar en un bucle infinito si tienes dependencias extrañas en tu seguimiento allí. Svelte 5 hace eso mucho más explícito.

Esta siguiente pregunta viene de Daniel. ¿Por qué hay tantos frameworks? ¿Estás realmente resolviendo diferentes problemas? Considero una verdadera bendición que estemos en una comunidad lo suficientemente grande como para sostener tantos frameworks diferentes. Todo el asunto de optimizar por vibraciones. Lo que realmente estoy diciendo con eso es que puedes construir cualquier aplicación con cualquiera de estos frameworks. Y realmente es solo una cuestión de gusto. Sabes, no quiero vivir en un mundo donde haya, no sé, solo un tipo de mantequilla de maní o lo que sea. Me gusta el hecho de que tengo opciones. Y eso es lo que es para mí en los frameworks de JavaScript, también. Sí, hay muchos de ellos. Pero todos abordan las cosas desde un ángulo ligeramente diferente y todos nos informamos mutuamente.

Cada framework aporta algo nuevo a la mesa. Y aunque hay mucho solapamiento, al empujar los límites en diferentes direcciones, la marea creciente realmente eleva a todos los barcos. Muchas comunidades no tienen eso. Sé que es un meme. Sé que es cero días desde el último framework de JavaScript o lo que sea. Pero, sinceramente, valóralo. Es una cosa preciosa.

Definitivamente. Y entonces este siguiente dice que la mayoría de los frameworks de front-end ahora tienen signals. Unos pocos ahora están obteniendo compilers. ¿Cuál es el próximo avance que la mayoría de los frameworks implementarán? Y supongo que también de dónde probablemente se inspiraron en Svelte. ¿Qué crees que va a ser lo próximo? Quiero decir, contradiciéndome un poco de mi respuesta anterior, parece que el rendering es un problema resuelto. Como, sabemos cómo tomar algún estado y convertirlo en una pieza de DOM que se actualiza.

Me parece que necesitamos empezar a movernos más allá de eso y empezar a pensar de una manera más holística, ¿qué podemos hacer que toda aplicación necesita? ¿Qué podemos llevar a una base compartida para que no tengamos que reinventar esto todo el tiempo? Como, esta es la razón por la que Vite ha sido un éxito tan masivo. Porque toma las cosas en común entre todas estas diferentes aplicaciones y las pone en un paquete que todos pueden compartir y construir sobre él. Y siento que eso es necesario para otras áreas de, ya sabes, el espacio problemático de construir aplicaciones. Definitivamente. De acuerdo. Seis Uno dice, ¿por qué mencionaste que la web no está garantizada? Las estadísticas son bastante desalentadoras, honestamente. Si miras el tiempo que la gente pasa en sus dispositivos, la gente usa mucho la web en el escritorio. Pero en móviles, es como menos de una cuarta parte, creo. Y está disminuyendo. Y eso es en parte porque la plataforma en sí a veces, sinceramente, es un poco inestable.