La forma en que escribimos JavaScript en 2030 será completamente diferente a como lo hacíamos en 2020. Aquí está el por qué: la lenta muerte de IE11 y el despliegue de los módulos ES convergerán hacia una nueva generación de herramientas de JavaScript. Estas herramientas son más rápidas, más seguras en cuanto a tipos y políglotas, lo que conduce a una mejor experiencia tanto para el desarrollador como para el usuario. ¡El cambio está en marcha!
This talk has been presented at JSNation Live 2021, check out the latest edition of this JavaScript Conference.
FAQ
Sean divide la historia de JavaScript en tres edades: la Primera Edad de 1997 a 2007, la Segunda Edad desde 2009 hasta 2019 y la Tercera Edad que comienza desde 2020 hacia adelante.
En 2008, la reunión de Oslo fue un evento crucial donde prominentes figuras de JavaScript se reunieron para resolver disputas entre ECMAScript 3.1 y ECMAScript 4, estableciendo un camino hacia ECMAScript 5.
En 2009, herramientas como Node.js, MPM y la sintaxis de módulos que se convirtió en dominante en Node.js y navegadores surgieron, marcando un año significativo para la innovación en JavaScript.
Un módulo ES se refiere a la importación y la sintaxis de exportación en JavaScript, permitiendo un manejo más eficiente y estructurado del código. Sean destaca su importancia en la Tercera Edad de JavaScript, especialmente con la transición desde CommonJS.
La muerte de IE11 es significativa porque elimina la necesidad de soportar un navegador que no es compatible con muchos estándares modernos de JavaScript, facilitando el uso de tecnologías más nuevas como los módulos ES sin transpiladores.
En la Tercera Edad de JavaScript, muchas herramientas están siendo escritas en lenguajes como TypeScript, Rust y Go en lugar de solo JavaScript, buscando optimizar la velocidad y eficiencia.
Sean especula que JavaScript no desaparecerá completamente sino que coexistirá con tecnologías como WebAssembly, que pueden manejar casos de uso específicos más eficientemente.
Esta charla presenta la Tercera Edad de JavaScript, cubriendo la evolución y el futuro del lenguaje. Explora la adopción de módulos ES y el declive de IE11, así como el cambiante panorama de las herramientas de JavaScript y el concepto de herramientas políglotas. La charla también toca el futuro potencial de JavaScript con WebAssembly y enfatiza la importancia de la composabilidad del código y la recepción de feedback en el desarrollo de software.
Estoy aquí para presentar la Tercera Edad de JavaScript, que es una tesis de una década. JavaScript se puede dividir en diferentes edades, y quiero categorizar y especular sobre los temas futuros. Hoy, cubriremos la Primera Edad, la Segunda Edad y los componentes de la Tercera Edad: módulos ES, la muerte de IE11, herramientas políglotas, colapso de capas de herramientas y, potencialmente, lo que viene después de la Tercera Edad.
Hola a todos. Mi nombre es Sean, también conocido como swicksontheinternet, y estoy aquí para presentar esta idea, esta tesis de una década que tengo, que se llama la Tercera Edad de JavaScript.
¿Cuál es la historia hasta ahora? Puedes dividir los periodos de JavaScript en dos o tres edades diferentes. La Primera Edad fue de 1997 a 2007. Había mucho que estaba sucediendo en 2008. Había una crisis mundial en curso. Así que podrías empezar a recoger cosas de nuevo en 2009, continuando hasta 2019. 2020 fue otra mezcla aleatoria de eventos, pero había todavía muchas noticias. Ahora estamos bien entrados en los años 2020. Quiero hablar de eso. Quiero intentar categorizar las cosas de una manera ordenada. Obviamente, la historia nunca es tan ordenada como la presentan los historiadores. Pero podemos hablar de diferentes temas y especular sobre qué temas están por venir. Así que el índice aproximado de lo que vamos a cubrir hoy, vamos a cubrir la Primera Edad, la Segunda Edad y luego los dos componentes de la Tercera Edad de los que realmente me gustaría hablar. Que son los módulos ES y la muerte de IE11, así como las herramientas políglotas y el colapso de las capas de herramientas. Y luego la muerte de JavaScript. Potencialmente lo que viene después de la Tercera Edad de JavaScript. Porque la historia no termina ahí. Pero tal vez se transforma en una historia diferente. Así que la Primera Edad de JavaScript, 1997 a 2007. Para aquellos que quieren saber más sobre los orígenes de JavaScript, deberían escucharlo directamente de la boca del caballo de Ben e Ike. Dio esta gran charla en .conf sobre una breve historia de JavaScript. Y la verdadera revelación aquí es que JavaScript se basó en una mentira. Netscape en realidad lo atrajo para construir JavaScript diciéndole que podría construir Scheme en el navegador. Y cuando llegó, le dijeron, no, tienes que construir un clon similar a Java que no es Java en absoluto. Es un período muy interesante en la historia de JavaScript, que es un período muy formativo también. Hubo este período caliente de formalización. Marqué el inicio de JavaScript en 1987. Retrocedió unos años antes de eso. Y hubo un largo período de silencio donde hubo una guerra civil donde realmente no
2. Comunidad JavaScript y la Reunión de Oslo
Short description:
La comunidad abordó JavaScript construyendo dialectos compilados a JS o modificando el propio JavaScript. En 2008, un año crucial, la reunión de Oslo resolvió la disputa entre ECMAScript 3.1 y ECMAScript 4, lo que llevó a la hoja de ruta hacia la armonía con ECMAScript 5. Para más detalles, consulte el manuscrito de JavaScript, los primeros 20 años, de Brendan y Alan Worsbach.
acordar la dirección de ECMAScript 3.1 o ECMAScript 4. Esencialmente, la forma en que la comunidad comenzó a lidiar con esto fue tener dos pistas. Una era que comenzaron a construir dialectos compilados a JS de JavaScript, por lo que había algunas bifurcaciones directas como ActionScript, Qt, JScript o WMLscript. Estos no son compatibles con JavaScript en absoluto. O podrías quedarte dentro de los límites de JavaScript y simplemente modificarlo mucho. Así que puedes tener jQuery, Dojo y Mootools. Obviamente, jQuery terminó ganando al final. Pero creo que 2008 fue aún un año crucial, a pesar de que no fue una zona gris en términos de la forma en que veo mi cronología del tiempo. Realmente me gusta esta idea de la reunión de Oslo donde todos los que eran prominentes en JavaScript en ese momento se reunieron en Noruega y resolvieron esta disputa o este cisma entre ECMAScript 3.1 y ECMAScript 4. Y tuvieron algún tipo de hoja de ruta hacia la armonía, que es ECMAScript 5. Así que dijeron, en lugar de este enfoque evolutivo de 3.1 o un enfoque revolucionario de 4, tomemos lo mejor de cada mundo y lleguemos a algún tipo de concesión para que los navegadores puedan empezar a avanzar de nuevo. Si quieres más detalles sobre esto, deberías consultar el manuscrito de JavaScript, los primeros 20 años, que es una especie de libro / charla que fue presentado para las actas de ECM sobre Lenguajes de Programación que se suponía que iba a suceder el año pasado. Y tiene 200 páginas, así que nadie lo ha leído. Solo lo he ojeado un poco, pero esta es la historia de JavaScript de los autores autorizados, Brendan, quien hizo JavaScript, y Alan Worsbach, quien fue el editor de ES5 y ES6.
3. La Segunda Edad de JavaScript
Short description:
La segunda edad de JavaScript trata sobre la comunidad y el ecosistema. En 2009, se introdujeron ECMAScript 5 y la sintaxis de módulo dominante en Node.js y el navegador. Surgieron diferentes secciones de la comunidad, incluyendo tiempo de ejecución y la aparición de herramientas de construcción. Salieron innovaciones significativas como Closure Compiler, CoffeeScript, Grunt, Webpack, Typescript, Galp, Tracer, Rollout, Babel y versiones más nuevas de Bundlers. También surgieron marcos como Angular, Backbone, Meteor, ReactiveView e Its Vault. Esta historia abarca más de 10 años de tiempos de ejecución, herramientas de construcción, marcos y un cambio a la izquierda en las herramientas de JavaScript.
OK. Luego hablaremos sobre la segunda edad de JavaScript. Entonces, si la primera edad de JavaScript fue sobre la formación del lenguaje, la segunda edad de JavaScript trata sobre la comunidad, el ecosistema. En 2009, todas estas cosas sucedieron en el mismo año. Llegamos a ECMAScript 5, la especificación de Harmony, pero luego también tuvimos esta extraña sintaxis JS común que fue propuesta. Eso se convirtió en la sintaxis de módulo dominante eventual en Node.js y en el navegador. Node.js se lanzó en 2009, y también MPM se lanzó en 2009. Todas estas cosas que damos por sentado hoy fueron inventadas en el mismo año.
Hay diferentes secciones de la comunidad. Así que voy a desglosar algunas de ellas. La primera fue el tiempo de ejecución. Puedes seguir la evolución gradual de poder ejecutar JS en todas partes. Puedes ejecutar JS en un navegador. Chrome también comenzó en 2009, lo cual es increíble pensar que es así Electron, puedes ejecutarlo en el escritorio, puedes ejecutarlo en teléfonos, y luego puedes tener tiempos de ejecución especializados solo para Android. Y eso es algo realmente interesante, de ingeniería de bajo nivel que está sucediendo. Obviamente, probablemente hay otros tiempos de ejecución que ni siquiera conozco, así que déjame saber en los comentarios si hay alguno que creas que debería tocar.
La segunda parte del ecosistema que quiero tocar es la aparición de herramientas de construcción, la forma de ayudarte a compilar, construir y agrupar tu JavaScript. Entonces, Closure Compiler y CoffeeScript también surgieron en 2009, así como también. Un año muy, muy significativo para la innovación. Había Grunt, Webpack, y Typescript alrededor del mismo tiempo en 2012-ish, 2011. Galp y Tracer salieron en 2014, y Rollout y Babel reemplazaron a Tracer, así como las versiones más nuevas de Bundlers, Rollout, Parcel, y Bazel salieron en los tres años siguientes.
También salieron marcos. Entonces, antes de Angular y Backbone, teníamos un montón de otros. Pero llamémoslo el inicio de la segunda edad de JavaScript con Angular y Backbone. Meteor salió e intentó ser full stack, con su propia capa de UI llamada Blaze. ReactiveView salió en 2013 y 2014. Its Vault salió en 2017, pero fue esencialmente reinventado en 2019. Entonces, esa es la historia. Son más de 10 años de tiempos de ejecución y herramientas de construcción y marcos. Y hay una tendencia más que me gusta destacar, que es esta idea de un cambio a la izquierda
4. La Tercera Edad de JavaScript
Short description:
He realizado dos charlas separadas sobre esto. Una sobre Svelte y el gran ascensor espacial, hablando sobre la evolución hacia los marcos de trabajo solo de compilador, así como el crecimiento de un metalenguaje, la importancia de la experiencia del desarrollador y las herramientas de desarrollo para los marcos de trabajo. Ahora llegamos a la tercera edad donde básicamente hacemos un RF en JavaScript antiguo. Las dos suposiciones aquí que están desapareciendo es que commonJS es el objetivo de construcción para todas nuestras herramientas, lo que introduce mucha hinchazón. Vamos a pasar a los módulos ES. Va a ser asistido por la lenta muerte de IE 11. La segunda cosa de la que hablamos es la herramienta de JavaScript. Ahora escribimos la mayoría de ella en TypeScript, pero también cada vez más en Rust y Go. Así como la colapsación de las capas de los diferentes trabajos de la herramienta. Primero hablaremos sobre los módulos ES y la muerte de IE 11. Todavía hay algunas sutilezas, pero en general, el ecosistema se está moviendo. Hay limitaciones de las que la gente debería estar consciente, pero también hay soluciones como usar un desagrupador solo para desarrollo. El único obstáculo con esto es IE11, el elefante en la habitación.
en JavaScript tooling. He realizado dos charlas separadas sobre esto. Una sobre Svelte y el gran ascensor espacial, hablando sobre la evolución hacia los marcos de trabajo solo de compilador, así como el crecimiento de un metalenguaje, la importancia de la experiencia del desarrollador y las herramientas de desarrollo para los marcos de trabajo. Esto fue presentado en la masterclass de React. Ahora llegamos a la tercera edad donde básicamente hacemos un RF en JavaScript antiguo. Algún amable lector hizo una bonita imagen de esto. Nunca jugué a este juego, pero he oído que es muy divertido. Esencialmente, las dos suposiciones aquí que están desapareciendo es que commonJS es el objetivo de construcción para todas nuestras herramientas, lo que introduce mucha hinchazón. Vamos a pasar a los módulos ES. Va a ser asistido por la lenta muerte de IE 11. Te daré actualizaciones sobre esas tendencias.
La segunda cosa de la que hablamos es la herramienta de JavaScript. Ahora escribimos la mayoría de ella en TypeScript, pero también cada vez más en Rust y Go. Así como la colapsación de las capas de los diferentes trabajos de la herramienta. Primero hablaremos sobre los módulos ES y la muerte de IE 11. Para aquellos que no lo saben, lo que es un módulo ES es realmente solo la importación y la sintaxis de exportación que podrías estar viendo en mucho de tu código que podrías no saber que está siendo compilado por Webpack. Webpack está actuando como una especie de intérprete en entornos que en realidad no tienen el lenguaje nativo de importación y exportación del módulo ES. Pero ahora, tanto los navegadores como Node.js tienen esencialmente esta capacidad sin marcar. Todavía hay algunas sutilezas como usar MJS, el script de Michael Jackson, si quieres especificar que estás trabajando en módulos, y hay algunos problemas que resolver allí, pero en general, el ecosistema se está moviendo. Si quieres leer un buen resumen sobre esto, deberías consultar los documentos de MDN sobre los módulos ES, y creo que el equipo de V8 tiene un buen documento sobre los módulos ES según ellos también. Así que, hay algunas sutilezas aquí y hay más desarrollo por hacer, pero está avanzando y se ve muy bien.
Así que hay limitaciones de las que la gente debería estar consciente. Por ejemplo, realmente no puedes simplemente construir módulos ES y enviarlos en producción de cualquier tamaño significativo. Incluso el equipo de V8 recomienda que hay un cuello de botella en la tubería de carga cuando estás cargando 300 módulos. Y así, si empiezas a construir cualquier tipo de aplicación significativa, probablemente no querrás hacer esto, pero probablemente esté bien para un sitio web. Así que todavía puedes usar un desagrupador solo para desarrollo como Snowpack o Vite o WMR. Y creo que también es una muy buena solución. Así que eso es eso es algo que ves refrescando muchas de las herramientas en JavaScript ahora hoy. Que no tienes que agrupar para el desarrollo, por lo que tus ciclos de actualización de desarrollo pueden ser mucho más rápidos. Puede ser una actualización en tiempo constante en lugar de tener que reconstruir los proyectos enteros cada vez que guardas. El único obstáculo con esto, por supuesto, es IE11, el elefante
5. Adopción de Módulos ES y la Muerte de IE11
Short description:
Existe soporte generalizado para la especificación nativa de los módulos ES, pero no para IE11. El gobierno de los EE.UU. podría abandonar IE11 este año, lo que sería un catalizador para la adopción. Muchas empresas y ecosistemas, como Vue y Angular, ya han acordado abandonar el soporte de IE11. El nuevo modo de compatibilidad de IE11 de Microsoft Edge también ayuda a la adopción. La adopción de módulos ES está aumentando tanto en los navegadores como en Node.js, impulsada por Sindra y un esfuerzo coordinado. El momento de los módulos ES es ahora.
en la sala. Existe soporte generalizado para la especificación nativa de los módulos ES, pero no para IE11. Parte de la adopción de IE11 es muy contingente a la muerte de IE11. Entonces, en la esquina superior izquierda, esta es una captura de pantalla de analytics.gov.us. Y el número clave a observar es el porcentaje de visitas desde Internet Explorer. El servicio digital de los EE.UU. ha identificado el 2% como el nivel crítico de referencia donde apoyan a los navegadores. Solía ser 3.6% en noviembre 2020 cuando comencé a escribir sobre esta tesis. Ahora ha caído al 2%. Entonces, ha caído constantemente y probablemente estamos en el momento, y creo que el gobierno de los EE.UU. podría abandonar IE11 este año. Y creo que eso es un gran problema porque es un catalizador que si el gobierno de los EE.UU. ha abandonado IE11, podemos abandonarlo ahora en el trabajo. Obviamente, muchas otras personas en el ecosistema han seguido adelante y han acordado con esa decisión. Entonces, el ecosistema de Vue ha acordado abandonar el soporte de IE11. Angular ha acordado abandonar el soporte de IE11, así como un montón de otras empresas como Skillshare, Twitter, GoDaddy, WordPress, Drupal, Daily Por supuesto, Microsoft misma. También ayuda mucho este ajuste en Edge, el nuevo Microsoft Edge, donde tienen este modo de compatibilidad con IE11. Entonces, incluso si tu aplicación necesita funcionar en IE11, no tienes que visitar IE11, no tienes que usar IE11 la mayor parte del tiempo. Y creo que eso es un gran catalizador para la adopción a medida que esto se implementa en algunas de las empresas más grandes que requieren todas estas aplicaciones de IE11 y no tienen el presupuesto para reescribir todas esas cosas solo para actualizar los navegadores. Entonces, la adopción está ocurriendo lentamente para los módulos ES, tanto en el navegador. Entonces, aquí hay una captura de pantalla de algunas estadísticas de la adopción del navegador de los módulos ES. Se triplicó en 2020 y creo que también lo hará muy bien en 2021. Así como en Node.js porque está impulsado principalmente por Sindra. Va a pasar todas sus bibliotecas a módulos ES. Si quieres usar sus cosas, tienes que usar módulos ES dentro de Node. Creo que está sucediendo de manera coordinada porque todos sienten que el momento es ahora. Ha sido un largo, largo tiempo desde que se planteó la primera idea de estandarización cuando se tomó esta foto con Addy Osmani. Está llegando. Es realmente
6. Cambio en las Herramientas y Herramientas Políglotas
Short description:
La siguiente parte de la tercera era de JavaScript se centra en el cambio en las herramientas. Las herramientas de JavaScript ahora se están optimizando para rutas calientes y velocidad, en lugar de facilidad de contribución. Muchos desarrolladores han cambiado a TypeScript, que ha tenido una fuerte adopción en el ecosistema de React. Otros lenguajes como Rust también se están explorando para una mayor optimización. La idea de las herramientas políglotas está ganando terreno, donde la funcionalidad principal está escrita en un lenguaje compilado para un mejor rendimiento.
llegando. Bien. La siguiente parte de la tercera era de JavaScript es el cambio en las herramientas. Brandon Dale lo predijo en 2018 diciendo que en menos de cinco años, la mayoría de las herramientas de JavaScript más populares no estarán escritas en JavaScript. Creo que esto ha sucedido en su mayoría, pero de diferentes maneras Las dos suposiciones que se están despejando ahora es que las herramientas de JavaScript deberían ser escritas para desarrolladores de JS por desarrolladores de JS para que puedan contribuir. La realidad es que no lo hacen. Por lo tanto, deberíamos optimizar para rutas calientes y velocidad en lugar de facilitar la contribución por personas que en realidad no terminan contribuyendo. Y la otra suposición es la de la filosofía Unix, cada herramienta debería hacer una cosa bien. Así que, hablemos de eso en orden. Entonces, lo primero es si deberíamos escribir solo en JavaScript. La respuesta fácil es, bueno, la mayoría de las personas simplemente han optado por escribir en TypeScript. Así que aquí hay un ejemplo de cuánto del ecosistema de React ha cambiado a TypeScript. Lo he estado monitoreando. Así que, React Router, Next.js, Yarn, Storybook, Apollo, Gatsby, todos han cambiado a TypeScript. Estos son los resultados de las encuestas del estado de JavaScript, y la adopción de TypeScript ha sido extremadamente fuerte. Se puede decir que TypeScript ha ganado en este punto. Pero TypeScript es por diseño muy similar a JavaScript. Entonces, ¿qué pasa con los otros lenguajes que queremos optimizar aún más? Aquí está el benchmark de ES Build. Es un competidor de webpack. Y es aproximadamente 100 veces más rápido que la alternativa más rápida, según su propio benchmark. Así que, tómalo con un grano de sal. Pero es algo más rápido, seguro. Y eso básicamente proviene de tener un lenguaje compilado en su núcleo. Esa es una observación muy interesante. Porque también se ve eso en Rust. Ves que se está adoptando en Denno, en Relay, y en Volta. Todos estos tienen porcentajes significativos de Rust en su base de código. Y creo que lo que está sucediendo es esta idea de que deberíamos explorar las herramientas políglotas. Solíamos tener este concepto de herramientas puras, donde escribirías la API externa en JavaScript, y tú escribirías el núcleo en JavaScript también. Pero no tiene sentido escribir el núcleo en JavaScript,
7. Optimización y Complejidad en las Herramientas de JavaScript
Short description:
No importa cuánta optimización puedas hacer, probablemente puedas hacerlo mejor compilándolo en binarios. Estamos cambiando nuestro concepto de lo que significa exactamente una herramienta, una herramienta para un trabajo. La definición de cuál es el trabajo cambia con el tiempo. Cuando miras todas estas herramientas a las que estamos tan acostumbrados a juntar, ¿por qué son todas herramientas diferentes? ¿Y por qué tienen diferentes plugins? Eso es un poco de lo que sucede. Nuestra primera reacción a esto fue en realidad muy simple. Simplemente escondimos todo bajo la alfombra. Eso sigue sucediendo. Estamos escondiendo la complejidad bajo más alfombras. Estamos empezando a construir sobre React como un límite estable en lugar de reinventar los marcos de trabajo todo el tiempo.
porque es un camino caliente. Se ejecuta una y otra vez. No importa cuánta optimization puedas hacer, probablemente puedas hacerlo mejor compilándolo en binarios. O también puedes hacer un chequeo de tipos más fuerte para que sea un núcleo más estable. Entonces, sea lo que sea, puedes cambiar tu herramienta principal a un lenguaje de sistemas y beneficiarte de la optimization allí. Pero aún dejas tu API externa en un lenguaje de script como JavaScript. Este es el patrón hacia el que nos estamos moviendo para muchas de nuestras herramientas principales. Vamos a tener Go, Rust, o TypeScript si tenemos que, y un exterior en JavaScript. Esto suena como una herejía para ti. Creo que es porque estamos cambiando nuestro concepto de lo que significa exactamente una herramienta, una herramienta para un trabajo. Entonces, este es un blog post realmente bueno que encontré de Benedict Evans sobre plataformas y agrupación. Cuando salieron los procesadores de texto, en realidad tenían diferentes funcionalidades y diferentes plugins para contar palabras, notas al pie y gráficos. Estos eran todos productos separados de diferentes empresas que tenías que salir y comprar por $50 a $100 cada uno. ¿Puedes imaginar comprar un procesador de texto hoy y no tener un contador de palabras y no tener notas al pie? No. Así que, hoy simplemente viene todo agrupado. ¿Cuántos plugins y cuántas, ya sabes, diferentes pequeñas herramientas quieres en un contador de palabras? Creo que la definición de cuál es el trabajo cambia con el tiempo y eso es lo que estamos viendo suceder en JavaScript hoy. Entonces, cuando miras todas estas herramientas a las que estamos tan acostumbrados a juntar, ¿por qué son todas herramientas diferentes? ¿Y por qué tienen diferentes plugins como por qué tengo ESLint Babel prettier type script en lugar de simplemente tener un conjunto de herramientas del ecosystem que funcionan bien juntas y tienen un único paso EST y toda esa optimization que puede suceder si tienes una visión holística de cuál es el trabajo de agrupar JavaScript. Entonces, eso es un poco de lo que sucede. Entonces, nuestra primera reacción a esto fue en realidad muy simple. Esto es algo que cubrí en una charla anterior llamada creando crear React app. Que es que simplemente escondimos todo bajo la alfombra. Diríamos, bueno, configurar Webpack es demasiado difícil para hacer una aplicación de React, así que vamos a esconder todo bajo una única dependencia y simplemente instalarías crear React app. Eso es una mejora mágica en la experiencia del desarrollador. Pero simplemente escondimos esa complejidad bajo la alfombra. En el momento en que necesitamos desviarnos de ella, tenías que expulsar y ahora te quedas con toda esa complejidad de nuevo y toda esa configuración. Creo que eso sigue sucediendo. Esta es mi otra tesis llamada distribuciones de React. Seguimos haciendo eso. Estamos escondiendo la complejidad bajo más alfombras. Crear React app, NextJS y Gatsby hacen eso para el enrutamiento. Y Blitz.js y Redwood.js hacen eso incluyendo otros componentes personalizados y estado y marcos de trabajo de datos. Pero estamos empezando a construir sobre React como un límite estable en lugar de reinventar los marcos de trabajo todo el tiempo.
8. Colapso de Herramientas y la Tercera Edad de JavaScript
Short description:
Este es otro post de blog que tengo. Si miras la presentación de inversores de Rome, puedes ver el mismo gráfico exacto de, por qué todas estas diferentes herramientas, combinémoslas en una herramienta. Y puedes ver esto en la demostración también, que intenta colapsar eso en la capa de node.js, lo cual creo que es un enfoque súper interesante. Estos dos, creo que no es coincidencia que estos dos ahora estén financiados por capital de riesgo.
Para el colapso de tooling. Creo que esta propuesta es realmente genial. Este es otro post de blog que tengo. Si miras la presentación de inversores de Rome, puedes ver el mismo gráfico exacto de, por qué todas estas diferentes herramientas, combinémoslas en una herramienta. Y puedes ver esto en la demostración también, que intenta colapsar eso en la capa de node.js, lo cual creo que es un enfoque súper interesante. Estos dos, creo que no es coincidencia que estos dos ahora estén financiados por capital de riesgo. Y creo que eso es otra interesante innovation también. En la primera y segunda edad de JavaScript, fue muy independiente, movimiento de voluntariado de código abierto. Pero ahora en la tercera edad de JavaScript, creo que hay cierta sensación de que necesitamos un modelo de negocio sostenible para que se construya un gran código abierto. Y creo que el dinero está allí para ello. Entonces, si quieres iniciar un proyecto de herramientas de desarrollador de la tercera edad de JS, habla conmigo. Puedo ponerte en contacto con todos. Y estaría interesado en financiarte yo mismo.
9. La Muerte de JavaScript y el Futuro
Short description:
Finalmente, hablaremos sobre la muerte de JavaScript y qué sucede después de la tercera edad. Según la charla de broma de Gary Bernhardt, el futuro de JavaScript puede involucrar a WebAssembly. Aunque WebAssembly no reemplazará completamente a JavaScript, tiene sus usos, especialmente para aplicaciones grandes como Figma. En conclusión, esta breve charla proporciona una perspectiva sobre el pasado, presente y futuro de JavaScript. Si estás interesado en aprender más sobre cómo detectar tendencias y hacer apuestas tecnológicas, consulta mi libro en LearnInPublic.org. Gracias por estar aquí y disfruta el resto de la conferencia.
Bien. Finalmente, hablaremos un poco sobre la muerte de JavaScript, porque qué sucede después de la tercera edad de JavaScript. Y creo que la mejor fuente sobre esto es en realidad una charla de broma de Gary Bernhardt sobre el nacimiento y la muerte de Javascript. Que es una excelente exploración de qué sucede cuando Javascript obtiene lo que sucede después de Javascript, esencialmente. Creo que eso es algo de lo que Brendan Knight comenzó a hablar también. Tuve esta conversación con él sobre lo que podría ser la máquina virtual universal. Y él dice que es probablemente WebAssembly. En lugar de decir siempre mejor JavaScript, ha comenzado a decir siempre mejor JavaScript y WebAssembly. Y estás empezando a ver eso en algunas de las herramientas que lanzamos. Pero WebAssembly tampoco es polvo mágico de hadas. No creo que vaya a hacer desaparecer completamente a JavaScript para siempre, pero es muy apropiado para algunos casos de uso, y creo que vale la pena explorarlo para aplicaciones grandes como Figma. Entonces, esa es la tesis general, ¿verdad? Esta es una charla muy corta. Pero espero que te haya dado una perspectiva de dónde hemos estado, por lo que estamos pasando ahora y, con suerte, dónde terminaremos. Así que me encantan tus comentarios y preguntas, estaré en el chat de esta conferencia. Si quieres aprender más sobre cómo detectar tendencias y también apuestas en tecnologías para tu carrera, puedes consultar mi libro en LearnInPublic.org. Muchas gracias por tenerme y disfruta el resto de la conferencia.
Entonces, el primero es hablar. Standups nos encuentra en la conferencia con el 36%. Puedes practicar esto simplemente aplicando a una conferencia como esta, como JNation, React, conferencia, así que sí, puedes aplicar a la conferencia. Esa es una buena manera de mejorar esa habilidad. El autocuidado y la priorización, también muy importantes. Escribir blogs documentación, diseños y docs, esa es una de las habilidades que quiero mejorar. Y la negociación es la última con el 12%. Parece que hay muchos buenos negociadores viendo esta conferencia, así que eso es realmente bueno. Entonces, sí, el número uno es hablar. Ahora veamos algunas de las preguntas. Una es de Brian Hawk. ¿Cómo dominas la escritura de blogs técnicos? Me resulta difícil equilibrar el nivel alto versus el técnico. ¿Qué defines como la publicación de un blog técnico? Sean? Hola.
10. Dominando JavaScript y la Composabilidad del Código
Short description:
No creo que nunca lo domines. Solo hazlo mucho e intenta ser mejor de lo que eras ayer. Y después de algunos años de hacerlo, serás realmente bueno. Otra pregunta de Stark Odinson. ¿Mantener tu código más pequeño en términos de tamaño de archivo puede disminuir los tiempos de carga. ¿Cómo equilibras entre mantener tu código corto y mantenerlo legible? Veo. Me encanta esta pregunta. Así que creo que la respuesta del equipo central de React sobre la composabilidad realmente resuena conmigo aquí. Entonces, ¿cuál es realmente la conclusión de la muerte de JavaScript por Comoser? Ah, no hay ninguna. Es solo una observación. Me veo a mí mismo como un periodista de JavaScript. Y el objetivo de un periodista es escribir el primer borrador de la historia. En el sentido de que cuando miremos nuestras carreras de desarrollo web, 20, 30 años más adelante, cuando estemos jubilados y estemos hartos de programar más, ¿qué vamos a decir sobre los años 2020? Ya sabes, este período de 10 años de 2020 a 2030. Ya podemos ver algunas pistas de lo que está pasando. Y creo que mi papel aquí es simplemente señalar, creo que hay algunas tendencias que son muy interesantes. Y estas son cosas en las que yo invertiría personalmente.
Esa es una pregunta interesante. No creo que nunca lo domines. Solo hazlo mucho e intenta ser mejor de lo que eras ayer. Y después de algunos años de hacerlo, serás realmente bueno. ¿Por qué estás tratando de ser perfecto o dominarlo? Solo hazlo mejor de lo que eras antes. Esa es una gran respuesta. Practicando todo lo que te vuelves mejor y mejoras. Otra pregunta de Stark Odinson. ¿Mantener tu code más pequeño en términos de tamaño de archivo puede disminuir los tiempos de carga. ¿Cómo equilibras entre mantener tu code corto y mantenerlo legible? Veo. Me encanta esta pregunta. Así que creo que la respuesta del equipo central de React sobre la composabilidad realmente resuena conmigo aquí. Deberías ser capaz de descomponer tu code en bloques lógicos de code. Si es demasiado largo, tienes demasiado en tu cabeza. Deberías ser capaz de extraer cosas en funciones reutilizables. No necesitas reutilizarlas. Puedes simplemente sacar trozos de code y separarlos para que puedas extraerlos en una sola función. No tienes que romper esa abstracción bien hasta que necesites mirar en el detalle de la implementación. Entonces, la composabilidad del code es mi respuesta para mantener el code corto y legible. Sí. Esa es una buena respuesta. Composabilidad. Ahora lo sabes.
Entonces, ¿cuál es realmente la conclusión de la muerte de JavaScript por Comoser? Ah, no hay ninguna. Es solo una observación. Me veo a mí mismo como un periodista de JavaScript. Y el objetivo de un periodista es escribir el primer borrador de la historia. En el sentido de que cuando miremos nuestras carreras de desarrollo web, 20, 30 años más adelante, cuando estemos jubilados y estemos hartos de programar más, ¿qué vamos a decir sobre los años 2020? Ya sabes, este período de 10 años de 2020 a 2030. Ya podemos ver algunas hints de lo que está pasando. Y creo que mi papel aquí es simplemente señalar, creo que hay algunas tendencias que son muy interesantes. Y estas son cosas en las que yo invertiría personalmente.
QnA
Compartiendo Ideas y Recibiendo Retroalimentación
Short description:
Así que simplemente las compartiría. Y si estás de acuerdo, entonces eso es genial. Si no estás de acuerdo, házmelo saber y podemos tener una conversación al respecto. Leah pregunta, gracias. Muy interesante. ¿Dónde obtienes retroalimentación en la etapa inicial de un plugin? ¿Dónde obtienes? Oh, está bien. Sabes, Twitter es una gran fuente de mis comentarios. Daniel Berg pregunta ¿cómo puedes mejorar la explicación de ideas técnicas complicadas durante las reuniones diarias o las revisiones de código? Oh, vaya. Eso es interesante. Realmente no sé si he descubierto eso. Puru pregunta, ¿cómo equilibras DX y UIs como herramientas proporcionando un gran DX pero por defecto la falta de optimización en producción que Gatsby y Next pueden proporcionar? Pero Next y Gatsby son por defecto más lentos que Byte, y por lo tanto, todo el DX se diluye debido a la falta de velocidad.
invertiría personalmente. Así que simplemente las compartiría. Y si estás de acuerdo, entonces eso es genial. Si no estás de acuerdo, házmelo saber y podemos tener una conversación al respecto. No estoy tratando de imponerte alguna conclusión. Vale. Gracias. Leah pregunta, gracias. Muy interesante. ¿Dónde obtienes retroalimentación en la etapa inicial de un plugin? ¿Dónde obtienes? Oh, está bien. Sabes, Twitter es una gran fuente de mis comentarios. Sabes, prototipo muchas ideas de blogs en Twitter. Y si veo alguna tracción, entonces desarrollo un tweet en una publicación de blog completa. Pero a veces muchas personas tienen preguntas sobre dónde empezar si no tienes seguidores, y esto se llama el problema de arranque en frío. Diría que puedes unirte a grupos de responsabilidad de blogs. Así que junto con mi libro, tengo una community donde nos apoyamos mutuamente en nuestro aprendizaje público y nuestros esfuerzos de escritura. Así que puedes unirte a una community, ya sea una community de pago, o una community gratuita, solo entre tus amigos, para compartir comentarios. Otra cosa que animo a la gente es a tener este ensayo llamado recoger lo que dejan, lo que significa que si quieres que otras personas se preocupen por lo que escribes, entonces asegúrate de que estás escribiendo sobre algo que les importa. Y una forma de garantizar que les importa es simplemente mirar algo que acaban de lanzar. Como digamos que el equipo central de React ayer acaba de lanzar su hoja de ruta para React suspense. Si quieres escribir algo, probablemente lo leerán, y probablemente te darán retroalimentación sobre ello. Así que esa es una forma de responder rápidamente a algo que alguien más escribió, y tienes una probabilidad mucho mayor de recibir comentarios que si solo publicas, sabes, como algún documento aleatorio que nadie realmente estaba buscando o pidiendo. Gracias. Esa es una respuesta realmente genial. Y Daniel Berg pregunta ¿cómo puedes mejorar la explicación de ideas técnicas complicadas durante las reuniones diarias o las revisiones de code?
Explicando Ideas Complejas y el Método de Amazon
Short description:
Realmente no sé si he descubierto eso. Creo que el lugar de una reunión diaria o una reunión diaria no es el lugar adecuado para explicar ideas complicadas. Me gusta mucho el método de Amazon de tener una página o seis páginas para escribir la narrativa completa de un concepto, y antes de lo que trabajé en Amazon, llamaríamos a esto como una reunión de revisión de negocios, nos sentaríamos y tendríamos como 10 minutos de solo leer ese escrito y documento, así que básicamente intenta escribirlo en lugar de simplemente inventarlo al momento, ya sabes, porque cuando lo escribes, cuando escribes las cosas, realmente puedes organizar tus pensamientos.
Oh, vaya. Eso es interesante. Realmente no sé si he descubierto eso. Creo que el lugar de una reunión diaria o una reunión diaria no es el lugar adecuado para explicar ideas complicadas. Me gusta mucho el método de Amazon de tener una página o seis páginas para escribir la narrativa completa de un concepto, y antes de lo que trabajé en Amazon, llamaríamos a esto como una reunión de revisión de negocios, nos sentaríamos y tendríamos como 10 minutos de solo leer ese escrito y documento, así que básicamente intenta escribirlo en lugar de simplemente inventarlo al momento, ya sabes, porque cuando lo escribes, cuando escribes las cosas, realmente puedes organizar tus pensamientos. Gracias. Puru pregunta, ¿cómo equilibras DX y las interfaces de usuario como herramientas proporcionando un gran DX pero por defecto la falta de optimización en producción que Gatsby y Next pueden proporcionar? Pero Next y Gatsby por defecto son más lentos que Byte, y por lo tanto, todo el DX se diluye debido a la falta de velocidad. ¿Cómo equilibrarías eso? Esta es una pregunta más compleja que la publicación. Eventualmente Gatsby y Next se moverán encima de las herramientas de construcción de próxima generación como las herramientas de JavaScript de tercera edad como Vite. Así que eventualmente llegarán allí. Estamos en la fase de transición de herramientas debido a esta nueva era de JavaScript. Entonces sí, la forma en que lo veo es que creamos un mejor DX para crear un mejor UX. Y estas herramientas siempre están cambiando y siempre hay diferentes equipos tratando de mejorarlas. Gracias. Y la última pregunta será de Pedro Flores, quien pregunta, ¿sientes que una vez obtendremos suficiente tracción para eventualmente reemplazar a JavaScript? Sí. Entonces, la última parte de la charla fue sobre esta pregunta. Creo que la respuesta es básicamente no. JavaScript siempre tendrá un lugar, pero WebAssembly reemplazará algunos de los trabajos que estamos usando JavaScript para hacer. Y principalmente, primero, se va a utilizar para portar código escrito en otros lenguajes. Pero eventualmente, también vamos a encontrar formas de optimizar los caminos del código que estamos ejecutando en JavaScript. Pero en última instancia, la capa alrededor de lo que podemos hacer para los usuarios e interactuar con el DOM probablemente seguirá siendo propiedad de JavaScript. Entonces, eventualmente, probablemente tendrás que aprender un lenguaje JS y luego compilar a lenguaje JS para hacer tu trabajo. Y sí, creo que ese es el estado natural de las cosas. No creo que Wes y Will maten a JavaScript. WHITNEY ESPICHER-LONG, JR.: Gracias, Sean, por esta gran charla y por todas estas grandes respuestas. Ahora tienes que elegir tus preguntas favoritas para dar el libro. SEAN GONNIG-MOORE, JR.: Sin presiones. WHITNEY ESPICHER-LONG, JR.: Muchas gracias. SEAN GONNIG-MOORE, JR.: Quiero dar un agradecimiento a Brian Huff, creo, la primera pregunta para romper el hielo. WHITNEY ESPICHER-LONG, JR.: La primera pregunta. SEAN GONNIG-MOORE, JR.: Y hacer una muy buena pregunta. Quiero responderla con más detalle, pero no tenemos tiempo. WHITNEY ESPICHER-LONG, JR.: Bueno, Brian, tienes un libro. Yay. SEAN GONNIG-MOORE, JR.: Sí, entonces creo... WHITNEY ESPICHER-LONG, JR.: Muchas gracias. SEAN GONNIG-MOORE, JR.: Nos pondremos en contacto y te enviaré el libro. Muchas gracias por responder todas las preguntas realmente buenas. WHITNEY ESPICHER-LONG, JR.: Gracias, Sean.
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
WebAssembly enables optimizing JavaScript performance for different environments by deploying the JavaScript engine as a portable WebAssembly module. By making JavaScript on WebAssembly fast, instances can be created for each request, reducing latency and security risks. Initialization and runtime phases can be improved with tools like Wiser and snapshotting, resulting in faster startup times. Optimizing JavaScript performance in WebAssembly can be achieved through techniques like ahead-of-time compilation and inline caching. WebAssembly usage is growing outside the web, offering benefits like isolation and portability. Build sizes and snapshotting in WebAssembly depend on the application, and more information can be found on the Mozilla Hacks website and Bike Reliance site.
In the last 10 years, Webpack has shaped the way we develop web applications by introducing code splitting, co-locating style sheets and assets with JavaScript modules, and enabling bundling for server-side processing. Webpack's flexibility and large plugin system have also contributed to innovation in the ecosystem. The initial configuration for Webpack can be overwhelming, but it is necessary due to the complexity of modern web applications. In larger scale applications, there are performance problems in Webpack due to issues with garbage collection, leveraging multiple CPUs, and architectural limitations. Fixing problems in Webpack has trade-offs, but a rewrite could optimize architecture and fix performance issues.
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
Durante este masterclass, los participantes revisarán los patrones esenciales de JavaScript que todo desarrollador debe conocer. A través de ejercicios prácticos, ejemplos del mundo real y discusiones interactivas, los asistentes profundizarán su comprensión de las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables. Al final del masterclass, los participantes ganarán confianza en su capacidad para escribir código JavaScript de alta calidad que perdure en el tiempo. Puntos Cubiertos: 1. Introducción a los Patrones de JavaScript2. Patrones Fundamentales3. Patrones de Creación de Objetos4. Patrones de Comportamiento5. Patrones Arquitectónicos6. Ejercicios Prácticos y Estudios de Caso Cómo Ayudará a los Desarrolladores: - Obtener una comprensión profunda de los patrones de JavaScript y sus aplicaciones en escenarios del mundo real- Aprender las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables- Mejorar las habilidades de resolución de problemas y la legibilidad del código- Mejorar la colaboración y comunicación dentro de los equipos de desarrollo- Acelerar el crecimiento profesional y las oportunidades de avance en la industria del software
Sumérgete en el mundo de la IA con nuestro masterclass interactivo diseñado específicamente para desarrolladores web. "Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web" ofrece una oportunidad única para cerrar la brecha entre la IA y el desarrollo web. A pesar de la prominencia de Python en el desarrollo de IA, el vasto potencial de JavaScript sigue siendo en gran medida inexplorado. Este masterclass tiene como objetivo cambiar eso.A lo largo de esta sesión práctica, los participantes aprenderán cómo aprovechar LangChain, una herramienta diseñada para hacer que los modelos de lenguaje grandes sean más accesibles y útiles, para construir agentes de IA dinámicos directamente dentro de entornos JavaScript. Este enfoque abre nuevas posibilidades para mejorar las aplicaciones web con funciones inteligentes, desde el soporte al cliente automatizado hasta la generación de contenido y más.Comenzaremos con los conceptos básicos de LangChain y los modelos de IA, asegurando una base sólida incluso para aquellos nuevos en IA. A partir de ahí, nos sumergiremos en ejercicios prácticos que demuestran cómo integrar estas tecnologías en proyectos reales de JavaScript. Los participantes trabajarán en ejemplos, enfrentando y superando los desafíos de hacer que la IA funcione sin problemas en la web.Este masterclass es más que una experiencia de aprendizaje; es una oportunidad de estar a la vanguardia de un campo emergente. Al final, los asistentes no solo habrán adquirido habilidades valiosas, sino que también habrán creado funciones mejoradas con IA que podrán llevar a sus proyectos o lugares de trabajo.Ya seas un desarrollador web experimentado curioso acerca de la IA o estés buscando expandir tus habilidades en áreas nuevas y emocionantes, "Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web" es tu puerta de entrada al futuro del desarrollo web. Únete a nosotros para desbloquear el potencial de la IA en tus proyectos web, haciéndolos más inteligentes, interactivos y atractivos para los usuarios.
Uso de CodeMirror para construir un editor de JavaScript con Linting y AutoCompletado
Top Content
WorkshopFree
2 authors
Usar una biblioteca puede parecer fácil a primera vista, pero ¿cómo eliges la biblioteca correcta? ¿Cómo actualizas una existente? ¿Y cómo te abres camino a través de la documentación para encontrar lo que quieres? En esta masterclass, discutiremos todos estos puntos finos mientras pasamos por un ejemplo general de construcción de un editor de código usando CodeMirror en React. Todo mientras compartimos algunas de las sutilezas que nuestro equipo aprendió sobre el uso de esta biblioteca y algunos problemas que encontramos.
Este masterclass te enseñará los conceptos básicos de cómo escribir pruebas de extremo a extremo utilizando Cypress Test Runner. Cubriremos la escritura de pruebas, abarcando todas las características de la aplicación, estructurando las pruebas, interceptando solicitudes de red y configurando los datos del backend. Cualquier persona que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir el masterclass.
¡Prepárate para potenciar tus habilidades de desarrollo web con los Componentes del Servidor React! En esta inmersiva masterclass de 3 horas, desbloquearemos el potencial completo de esta tecnología revolucionaria y exploraremos cómo está transformando la forma en que los desarrolladores construyen aplicaciones web rápidas y eficientes. Únete a nosotros mientras nos adentramos en el emocionante mundo de los Componentes del Servidor React, que combinan sin problemas el renderizado del lado del servidor con la interactividad del lado del cliente para un rendimiento y una experiencia de usuario inigualables. Obtendrás experiencia práctica a través de ejercicios prácticos, ejemplos del mundo real y orientación experta sobre cómo aprovechar el poder de los Componentes del Servidor en tus propios proyectos. A lo largo de la masterclass, cubriremos temas esenciales, incluyendo:- Entender las diferencias entre los Componentes del Servidor y del Cliente- Implementar Componentes del Servidor para optimizar la obtención de datos y reducir el tamaño del paquete JavaScript- Integrar Componentes del Servidor y del Cliente para una experiencia de usuario fluida- Estrategias para pasar datos efectivamente entre componentes y gestionar el estado- Consejos y mejores prácticas para maximizar los beneficios de rendimiento de los Componentes del Servidor React
La autenticación sin contraseña puede parecer compleja, pero es fácil de agregar a cualquier aplicación utilizando la herramienta adecuada. Mejoraremos una aplicación JS de pila completa (backend de Node.JS + frontend de React) para autenticar usuarios con OAuth (inicio de sesión social) y contraseñas de un solo uso (correo electrónico), incluyendo:- Autenticación de usuario - Administrar interacciones de usuario, devolver JWT de sesión / actualización- Gestión y validación de sesiones - Almacenar la sesión para solicitudes de cliente posteriores, validar / actualizar sesiones Al final del masterclass, también tocaremos otro enfoque para la autenticación de código utilizando Flujos Descope en el frontend (flujos de arrastrar y soltar), manteniendo solo la validación de sesión en el backend. Con esto, también mostraremos lo fácil que es habilitar la biometría y otros métodos de autenticación sin contraseña. Tabla de contenidos- Una breve introducción a los conceptos básicos de autenticación- Codificación- Por qué importa la autenticación sin contraseña Requisitos previos- IDE de tu elección- Node 18 o superior
Comments