¿Cómo intenta el equipo de TypeScript evitar efectos negativos en el ecosistema de JS?

Rate this content
Bookmark

TypeScript se está convirtiendo en una de las formas dominantes en las que la gente escribe JavaScript. El objetivo de TypeScript es complementar y no reemplazar a JavaScript, por lo que ¿cómo asegura el equipo que el futuro de JS siempre sea JS?

Orta Therox
Orta Therox
33 min
18 Jun, 2021

Video Summary and Transcription

La influencia de TypeScript en el ecosistema de JavaScript y su alineación con los objetivos y principios de JavaScript. El impacto de TypeScript en la industria y su popularidad entre los programadores de JavaScript. El objetivo de TypeScript de innovar en tipos sin introducir nuevos conceptos en JavaScript. Los desafíos de ejecutar TypeScript en el código de otras personas y convertirlo en un lenguaje nativo del navegador. La compatibilidad de TypeScript con JavaScript y su objetivo de ser una capa delgada sobre JavaScript. Los esfuerzos para mejorar el soporte para JS y la documentación de JS, y los puntos problemáticos de la transición a TypeScript. El trabajo de accesibilidad en TypeScript y la ausencia de competidores reales en el mercado.

Available in English

1. Introducción a TypeScript y su Influencia

Short description:

En esta parte, discutiremos la influencia de TypeScript en el ecosistema de JavaScript y cómo el equipo de TypeScript tiene como objetivo alinear TypeScript y JavaScript para crear soluciones innovadoras. También exploraremos el intento de reemplazar JavaScript con TypeScript y obtendremos información sobre los objetivos y principios del equipo de TypeScript. ¡Vamos a sumergirnos!

Muy bien, comencemos a apostar por TypeScript. Así que voy a intentar hablar un poco sobre la influencia de TypeScript en el ecosistema de JavaScript, ya sabes, cómo el equipo de TypeScript trata de limitarse para asegurarse de que, ya sabes, TypeScript y JavaScript sean aliados en el intento de crear cosas geniales en JavaScript. Y luego, ¿cómo sería si hubiera un intento de usurpar JavaScript a través de TypeScript por parte del equipo de Microsoft? Con suerte, con todo esto, todos saldremos un poco más inteligentes y tendremos ideas diferentes sobre cómo todas las piezas encajan. Bien, entonces empecemos. Mi nombre es Ohto the Rocks. He estado trabajando en proyectos de código abierto a gran escala durante mucho tiempo, comenzando con un administrador de dependencias para iOS. Pasando a esta herramienta cultural en muchos lenguajes de programación diferentes que te permite crear reglas de linter en torno a cómo funciona la etiqueta de solicitud de extracción. Y pasé mucho tiempo, recientemente, trabajando en la era de TypeScript, tratando de descubrir cómo construir herramientas complicadas para ello y cómo todas estas piezas encajan. Eso eventualmente me llevó a trabajar a tiempo completo en TypeScript. Y ahora eso significa que tengo mucha perspicacia que creo que sería súper útil y es algo único. Así que voy a intentar hablar sobre cómo todo eso se une. Los objetivos de esta charla son tratar de hacerla un poco diferente a tu charla promedio sobre TypeScript. La mayoría de las charlas sobre TypeScript intentan hablar sobre qué características son útiles o, ya sabes, cómo proporcionar herramientas útiles para el editor, cosas así. Pero esta charla, en realidad, da un paso atrás y trata de pensar en cómo TypeScript afecta a toda la industria. Y tú sabes, lo que el equipo de TypeScript hace para asegurarse de que eso sea completamente copacético. Así que prepárate y lo pasaremos bien. Para empezar, hablaremos un poco sobre el equipo de TypeScript, si no lo sabes. Somos aproximadamente ocho personas que trabajan en el compilador, y alrededor de 20 personas en total. Eso incluye a los gestores de proyectos. Y hay otro equipo completo cuyo trabajo es manejar la integración con Visual Studio, no Visual Studio Code, lo cual es bastante considerable. Y hacen una gran cantidad de seguimiento de errores y se aseguran de que TypeScript tenga la menor cantidad de errores posible. El equipo en sí tiene algunos objetivos a largo plazo y principios. Los dos documentos principales al respecto, son los principios de funcionamiento. Estos tratan de describir, ya sabes, qué representa el proyecto de TypeScript. Entonces, ¿cuál es el objetivo a largo plazo? ¿Cómo nos percibimos en relación a otros lenguajes de programación en comparación con otros lenguajes de programación similares a JavaScript que se transpilan a JavaScript? Estos simplemente dicen, como, ya sabes, así es como nos definimos. Y luego el otro, y potencialmente el más interesante para esta charla, los objetivos de diseño de TypeScript. Hay mucho aquí. Así que lo dividiremos en dos. Así que hay objetivos de diseño para interactuar con JavaScript, ¿verdad? Imponer ningún overhead en tiempo de ejecución en los programas generados es un lenguaje técnico para decir simplemente que, si pones JavaScript en TypeScript, obtienes

2. Influencia y Popularidad de TypeScript

Short description:

TypeScript se alinea con las propuestas actuales y futuras de JavaScript, preservando el comportamiento en tiempo de ejecución y evitando nueva sintaxis. Se enfoca en la inferencia para encontrar errores y hacer que el código sea más mantenible. La popularidad de TypeScript es evidente en su amplio uso entre los programadores de JavaScript. Resuelve problemas reales en bases de código grandes y sirve como una excelente publicidad para Microsoft. El éxito de TypeScript contribuye al crecimiento del ecosistema de desarrollo de Microsoft.

JavaScript de nuevo y no cambiamos las cosas. Y luego el siguiente es alinear con las propuestas actuales y futuras de JavaScript. Así que no crees tu propio lenguaje que se sienta como JavaScript pero haga algo diferente. Y mantente actualizado con los cambios de JavaScript. Hablaremos un poco más sobre eso más adelante. Preservar el comportamiento en tiempo de ejecución de todo el código de JavaScript. También se refiere a la misma idea de JavaScript de entrada y salida. Evitar agregar sintaxis a nivel de expresión, profundizaremos más en esto más adelante. Y utilizar un sistema de tipos estructurales consistentes y completamente borrables. También algo de lo que hablaremos más adelante. Y luego, por otro lado, tienes a JavaScript y luego tienes los tipos. Que son los tipos de TypeScript. Y, ya sabes, TypeScript tiene una forma única de abordar los sistemas de tipos porque no puede crear nueva sintaxis de manera realista, dentro de ciertas limitaciones para ayudar a hacer los patrones de diseño existentes. Así que TypeScript trata de hacer todo lo posible a través de la inferencia. Y su objetivo es encontrar específicamente código que probablemente sea erróneo y proporcionar sistemas para trabajar en ello, en lugar de crear nuevas ideas y nuevos paradigmas en los que las personas puedan escribir código. La idea es, en cambio, hacer que sea más fácil encontrar código incorrecto en lugar de empujar a las personas en una dirección particular.

Además de eso, ya sabes, puedo hablar sobre cómo TypeScript influye en la industria, pero tienes que entender lo grande que es TypeScript para tener una idea de esto. Entonces, ¿qué hace que TypeScript sea grande? Creo que una encuesta reciente que es bastante útil es Stackoverflow. Stackoverflow es un sitio web donde puedes hacer preguntas. Pero una de las cosas interesantes aquí es que no es un ecosistema de desarrolladores específico de JavaScript. Es un sitio que todos los desarrolladores utilizan en casi todos los lenguajes de programación. Entonces, cuando ves los resultados de este tipo de encuestas, sabes que no están directamente orientados a un tipo específico de desarrollador. A la izquierda, puedes ver que TypeScript es el segundo lenguaje más querido en el mundo. Y a la derecha, puedes ver que, básicamente, uno de cada tres programadores de JavaScript también está utilizando TypeScript. Eso es mucho. Hay un montón de programadores de JavaScript, así que debe haber un tercio de un montón de programadores de TypeScript. Y, ya sabes, es posible que te preguntes, bueno, es popular, a la gente le gusta. También hay, como, una pregunta que siempre me hago, que es, ¿cómo se financia TypeScript? ¿Y por qué se creó? Bueno, en parte, porque resuelve problemas reales en la construcción de bases de código grandes en Microsoft y la otra parte es una increíble publicidad para Microsoft. Como, ya sabes, las personas se introducen en los entornos de desarrollo de Microsoft fuera de Windows ahora a través de VS Code y TypeScript, y luego continúan desde allí y piensan, huh, si VS Code funciona bien y TypeScript funciona bien, entonces, tal vez Azure también funcione bien. Oh, el perro ha bajado. Entonces, ya sabes, si quieres más TypeScript

3. Impacto y Entorno de TypeScript

Short description:

TypeScript tiene un impacto significativo en la industria de JavaScript. Su objetivo es innovar en tipos sin introducir nuevos conceptos en el lenguaje JavaScript. El entorno de TypeScript demuestra el objetivo de borrar el sistema de tipos y producir JavaScript real. Si bien TypeScript solía agregar características adicionales a JavaScript, ahora se enfoca en la compatibilidad hacia atrás y fomenta el uso de la sintaxis moderna de JavaScript.

ingenieros de compiladores, comienzan a usar Microsoft Azure. Pero no puedes pensar en TypeScript de forma aislada. Para TypeScript, hay efectivamente dos audiencias. Hay usuarios de TypeScript y usuarios de JavaScript y hay muchos usuarios de JavaScript en el mundo. Siempre trato de pensar en una base de usuarios como un conjunto de personas que se reduce, donde hay muchos usuarios de JavaScript y muy pocos usuarios de TypeScript. Y queremos proporcionar herramientas en todos esos niveles, y eso se logra brindando características de IDE a todos. Entonces, efectivamente, TypeScript es lo suficientemente grande como para tener un impacto en toda la industria de JavaScript cuando se realizan cambios. Y en general, me gusta pensar en una apuesta por TypeScript como una apuesta por JavaScript en la actualidad. Y la razón es que TypeScript tiene un sistema de tipos tan complicado y todo eso se hace para tratar de mapear JavaScript y tratar de no introducir nuevos conceptos en el lenguaje JavaScript. Y pueden tener todas estas características, pero al final del día, TypeScript tiene como objetivo innovar solo en un lugar y eso es en los tipos. No proporcionar nuevas características a nivel de expresión. Para que entiendas a qué me refiero, voy a mostrarte el entorno de desarrollo. Este es el entorno de desarrollo de TypeScript. Es un lugar en línea para mostrar y resaltar código con otras personas. Y puedes ver aquí a la izquierda que hay un código que primero es una definición de tipo y luego es un objeto constante que cumple con esa definición de tipo y a la derecha puedes ver la salida de JavaScript. Entonces, TypeScript elimina la definición de tipo y también el símbolo de dos puntos después de la A en la izquierda. Y eso es básicamente el objetivo final de TypeScript. Tomar el sistema de tipos, borrarlo y luego obtener JavaScript real al final del día. Esto no siempre ha sido estrictamente el caso. Por ejemplo, aquí hay un enum que es una característica de expresión del lenguaje que fue agregada por TypeScript hace siete u ocho años. Y puedes ver que al usar eso he afectado el JavaScript en la izquierda. A la derecha, hay mucho código que se emite para agregar esta característica adicional a JavaScript. Pero eso no es lo que es TypeScript en la actualidad, pero eso es lo que solían ser. A medida que el tiempo avanzaba, TypeScript agregó una característica explícitamente para deshacer ese tipo de daño a JavaScript que se había hecho. Ahora puedes crear estas estructuras de expresión existentes que también pueden ser completamente borrables. Entonces, TypeScript piensa en ello como las características de expresión se eliminan, ya sabes, Spy Space, cosas así. Bueno, no se eliminan. No se eliminan. La compatibilidad hacia atrás infinita de TypeScript efectivamente. Simplemente no son cosas de las que estemos muy orgullosos en el código moderno y ahora hay muchas formas en que las personas están comenzando a replicar esas características utilizando JavaScript moderno.

4. Influencia de TypeScript en el Futuro de JavaScript

Short description:

TypeScript es un contribuyente bienvenido en lugares donde se discute el futuro de JavaScript. Los objetivos de JavaScript y TypeScript están alineados, pero TypeScript no puede decidir el futuro de JavaScript. Cobrar por TypeScript o hacerlo de código cerrado no es factible. Microsoft debe adoptar JavaScript extendido, pero ejecutar TypeScript en el código de otras personas plantea desafíos. Hacer de TypeScript un lenguaje nativo del navegador es difícil sin la propiedad del motor del navegador. La naturaleza de la web y la estandarización de JavaScript hacen que sea poco probable el soporte de TypeScript en los navegadores.

y eso es lo que fomentamos. El aspecto de TC-39 es interesante. TypeScript y TC-39 son los mejores amigos. Si nunca has oído hablar de TypeTC39, es una reunión que se lleva a cabo cada trimestre, y básicamente discuten el futuro de JavaScript. TC-39 es una gran cantidad de voces diferentes, ya sabes, personas que provienen de diferentes ámbitos que intentan comprender dónde se encuentra JavaScript y hacia dónde se dirige, y presentan propuestas, y pasan por diferentes etapas. Y TypeScript está presente y es un contribuyente bienvenido, en todos estos lugares donde se discute el futuro de JavaScript, y somos solo un contribuyente, al mismo nivel de acceso que otras empresas tienen, que son las que crean los navegadores que utilizas. Intentamos dar comentarios sobre si es algo que se puede abordar en un sistema de tipos, o intentamos ayudar a presentar características que creemos serían muy útiles para las personas que utilizan sistemas de tipos. Esto significa que los objetivos de JavaScript y los objetivos de TypeScript están alineados de tal manera que no es TypeScript quien decide el futuro de JavaScript. No es TypeScript quien presenta a los comités de estándares cómo podría ser el futuro de JavaScript. Entonces, si TypeScript es popular, y la historia de Microsoft en cuanto al manejo de código abierto no es exactamente perfectamente limpio. ¿Cómo podría ser entonces una versión malintencionada de TypeScript? Una versión de TypeScript cuyos objetivos sean socavar a JavaScript como algo conceptual. En primer lugar, cuando pensé en esto, ya no se puede cobrar por un compilador. Hay demasiados compiladores realmente buenos. TypeScript compite con Flow o Haggle o ClojureScript o Elm, y todos estos son gratuitos y de código abierto a los que cualquiera puede contribuir, cualquiera puede mejorar, y que mejoran continuamente cada día. De repente, TypeScript cobrar dinero por ello o convertirse en código cerrado no es muy factible. Los co-creadores de TypeScript, Anders Heidelberg, él creó C Sharp y Pascal, creo, dijo en este punto, básicamente nadie va a crear un lenguaje de programación de código cerrado o cobrar por un compilador nunca más. Y eso me parece genial. Prefiero estar en ese ecosistema.

Entonces, en realidad, Microsoft debe adoptar JavaScript extendido extinguido, lo cual podría parecer factible porque los dos primeros ya están hechos. TypeScript está adoptando JavaScript y TypeScript está extendiendo JavaScript con un sistema de tipos personalizado. Debería ser fácil, ¿verdad? Apenas una molestia. Pero el mayor problema aquí es que TypeScript debe ejecutarse en el código de otras personas. Y un argumento en contra de eso es que Microsoft podría intentar hacer de TypeScript un lenguaje nativo del navegador. Y si esto fuera en los días de IE 6, 7, 8, 9, existe una posibilidad razonable de que ese impulso hubiera sido mucho más exitoso. Pero hoy en día, Microsoft no es propietario de un motor de navegador. Comparten Chromium con Google. Podrían intentar presentar a los comités de estándares que tal vez podríamos llegar a un punto en el que TypeScript pudiera ejecutarse en un navegador. Pero cualquier cosa así tendría que ser en el sentido de cómo podemos eliminar partes oficiales de TypeScript de JavaScript en los navegadores para que puedan ejecutar código de TypeScript pero sin realizar la verificación de tipos. Nadie más quiere esa responsabilidad. Eso sería una pesadilla. Uno de los mayores obstáculos en contra de eso es que la web no es como Denno o Node, donde se puede precompilar y pagar el costo de transformar TypeScript a JavaScript. Ya sabes, los navegadores solo envían una versión de JavaScript y nunca han necesitado usar Babel, por ejemplo, por lo que probablemente no vayan a hacer algo como admitir

5. Influencia y Compatibilidad de TypeScript

Short description:

El futuro de TypeScript está alineado con JavaScript y eliminar la compatibilidad hacia atrás arruinaría la reputación de TypeScript. Aunque existe un lenguaje de programación llamado Static TypeScript que tiene como objetivo convertir TypeScript a código C, es un proyecto de investigación y no está alineado con los valores del equipo de TypeScript. El objetivo de TypeScript es ayudar a migrar de TypeScript compilándolo a JavaScript. Babel seguirá admitiendo TypeScript y existen otros sistemas de tipos de JavaScript compatibles con los archivos DTS de TypeScript. La competencia de TypeScript en el espacio de los sistemas de tipos es beneficiosa para el ecosistema de JavaScript.

Algo como TypeScript. ¿Podrían hacer que TypeScript sea diferente de JavaScript, verdad? Entonces, comencemos a eliminar las características que la gente no quiere en JavaScript de TypeScript. Bueno, en primer lugar, hay demandas bastante regulares para esto, ¿verdad? Hay muchas partes de JavaScript que son extrañas e inconsistentes y que a la gente le molesta, pero ni siquiera podemos decir que es un tipo de JavaScript, por lo que hay momentos en los que la gente quiere eso. Es decir, conceptualmente, TypeScript podría eliminarse del lenguaje haciendo que esas cosas causen errores. Pero al final del día, el futuro de TypeScript está alineado con JavaScript y, ya sabes, comenzar a desmantelar JavaScript y eliminar la compatibilidad hacia atrás arruinaría nuestra reputación con TC39, que controla JavaScript. Molestaría mucho a las personas que realmente lo usan porque de repente su código comienza a fallar y, como regla general, TypeScript intenta no romper el código de las personas. Obtendrás errores del compilador a medida que mejoremos la detección de errores, pero retroceder y comenzar a regresar en cosas que han existido durante mucho tiempo no significa que no puedas hacer JavaScript dentro y JavaScript fuera. Y, realísticamente, debido a que es de código abierto, hay muchos colaboradores, alguien probablemente comenzaría un fork y eso parece totalmente razonable. Por lo tanto, no hay mucho incentivo para que el equipo de TypeScript extinga JavaScript tratando de bifurcar el lenguaje y eliminarlo.

Pero eso no quiere decir que esta idea no tenga valor. Hay un lenguaje de programación llamado Static TypeScript que proviene de Microsoft Research. Su objetivo era hacer eso explícitamente. Querían tomar TypeScript y convertirlo a código C. Por lo tanto, no pueden tener muchas de las trucos extraños de tiempo de ejecución involucrados en JavaScript. Entonces, en realidad, te permiten escribir JavaScript real en un navegador web que se compila en el navegador web a código C que se ejecuta en hardware pequeño. Cosas realmente geniales. Trabajo realmente interesante. Y lo hicieron con TypeScript, por lo que obtienen todas las herramientas para TypeScript, pero luego solo necesitan agregar algunos errores y advertencias adicionales para asegurarse de que se ejecute y se convierta en C. Este es un proyecto de investigación. Definitivamente no son los valores del equipo de TypeScript. Pero es una idea interesante de cómo podría verse si TypeScript fuera a hacer eso. Entonces, probablemente eso no suceda. Pero incluso si sucediera, el objetivo de TypeScript literalmente sería ayudarlo a migrar de TypeScript, ¿verdad? Simplemente compilas TypeScript y elimina los tipos y obtienes JavaScript. Entonces, si quisieras migrar de TypeScript, ejecutarías TypeScript en tu base de código en el nivel más alto de JavaScript y luego comenzarías a usar Babel, ¿verdad? Babel nunca dejará de admitir TypeScript en alguna forma en este punto. Y siempre habrá cosas como complementos de Babel o modificaciones de código para ayudarte a pasar de TypeScript a TypeScript o lo que sea. Y finalmente, TypeScript tiene competencia, y eso es realmente genial porque mantiene a muchas personas usando sistemas de tipos en JavaScript. Quiero que todos tengan éxito. Porque, ya sabes, cada vez que interactúas con bibliotecas, preferiría que tenga bases más sólidas al ser estáticamente analizable. E incluso hay nuevos sistemas de tipos de JavaScript que tienen como objetivo tener compatibilidad con los archivos DTS de TypeScript. Entonces, es poco probable que suceda de esa manera. Y, por lo tanto, es poco probable que suceda en absoluto, en mi opinión, pero esa es una de las razones por las que no hay muchos incentivos para que TypeScript haga eso.

6. Influencia de TypeScript en JavaScript

Short description:

TypeScript tiene como objetivo ser una capa delgada sobre JavaScript, brindando valor a nivel de herramientas. Se esfuerza por mejorar la semántica de TypeScript mientras mantiene una estrecha proximidad con JavaScript. Este enfoque facilita que los usuarios de JavaScript adopten y sigan utilizando TypeScript.

Luego está el tipo de TypeScript, como, se está desaislando, como, TypeScript solía tratarse de usar TS Lint, y tendrías, ya sabes, estas diferentes herramientas para el mundo de TypeScript, pero hoy en día tienes, como, Babel y ES Lint, y mucha gente está usando exactamente las mismas herramientas de JavaScript que solían usar pero con TypeScript. Y eso significa que podemos simplemente mantener JavaScript, TypeScript como esta capa delgada sobre Type, sobre JavaScript, y brindando valor a nivel de herramientas, y eso mantiene la diferencia entre ellos bastante insignificante. Y ese es nuestro objetivo. Queremos seguir mejorando la semántica de TypeScript para poder seguir apoyando a los usuarios de JavaScript, porque eso es muy importante para nosotros. ¿Viste cuántas personas hay? Y para todos, ya sabes, TypeScript tiene éxito en mi opinión porque está tan cerca de la semántica de JavaScript. Hay muchos lenguajes excelentes que brindan mucha mejor seguridad, pero se alejan más de lo que es JavaScript, y tienes que entender esa diferencia mucho más. Y creo que cuanto más cerca estén TypeScript y JavaScript, más fácil será adoptarlo y más probable es que las personas sigan usándolo.

7. La Evolución de TypeScript con JavaScript

Short description:

TypeScript lamenta algunos de los cambios que realizó al principio, como agregar características a JavaScript antes de que fueran introducidas. Ahora, TypeScript tiene como objetivo impulsar a JavaScript en una dirección positiva y agregar características de manera oculta. Sin embargo, TypeScript prioriza la estabilidad y el consenso antes de implementar nuevas características del lenguaje. Al trabajar con otros y evitar romper JavaScript, TypeScript se esfuerza por ser un buen ciudadano. Mi nombre era Otter y creo que TypeScript es genial.

Luego, como TypeScript lamenta algunos de los cambios que realizó al principio al agregar características a JavaScript. Por ejemplo, TypeScript agregó clases antes de que se introdujeran en JavaScript, pero afortunadamente adivinó correctamente la sintaxis o la sintaxis se inspiró en gran medida en el trabajo de TypeScript y en tratar de averiguar cómo debería lucir una clase en JavaScript.

Enum es algo que podría regresar al lenguaje a través de TC39. Hay una propuesta para ello, pero se ve un poco diferente. De repente, TypeScript tendrá que admitir enums de estilo antiguo y enums de estilo nuevo. Y los espacios de nombres ya no los necesitamos. Entonces, TypeScript lamenta efectivamente los períodos de tiempo en los que se ha alejado de lo que es JavaScript y quiere ayudar a impulsarlo hacia donde podría estar. Por lo tanto, TypeScript ahora intenta impulsar a JavaScript en una dirección positiva y trata de agregar cosas de manera completamente oculta. Pero al tratar de pensar en ello desde la perspectiva de por qué TypeScript lo hace de esta manera, me gusta pensar en el operador de interrogación. Esta es una propuesta que alguien más hizo y que TypeScript impulsó en las etapas finales. Cuando esa característica se agregó a Babel, eran aproximadamente 120 líneas de código y un complemento que cualquiera podía usar y hacer algo con él. Y eso era fácil y accesible. Cuando se agregó a TypeScript, eran miles de líneas de código y miles de pruebas y, realísticamente, no muchas personas podrían hacerlo. Entonces, para TypeScript, agregar cambios a todo el sistema de tipos y agregar nuevas características del lenguaje es un trabajo difícil y complicado. Y realmente queremos estabilidad antes de ir por nuevas características como esta. Y no es ventajoso para TypeScript intentar hacer estas cosas antes de tiempo, sino ser estable y esperar hasta que todos estén de acuerdo en cómo se verá antes de implementarlo. Porque es mucho más trabajo y si te equivocas, entonces podríamos tener múltiples implementaciones de lo mismo dentro del código y eso es realmente complicado. Entonces, en realidad, esas son las principales razones por las que TypeScript se impone restricciones a sí mismo. Restricciones de diseño para obligarnos a hacerlo de la manera correcta. Preferimos trabajar con otras personas. No hay mucho incentivo para romper JavaScript. Puedes deshacer TypeScript usando TypeScript. Todo en los últimos dos años se ha hecho para desaislar los proyectos de código de TypeScript. Eso es lo que hace el equipo de TypeScript y así es como intentamos ser un buen ciudadano. Mi nombre era Otter. También creo que deberías protestar si hay alguna en tu ciudad. Creo que TypeScript es genial. Si lo estás usando, genial. Si no, tal vez deberías probarlo.

QnA

Soporte de TypeScript para JS y JS Docs

Short description:

Háganos saber todas sus cosas favoritas. Que tengan un buen día. Ciao a todos. Vamos directo al grano porque tenemos muchas preguntas y poco tiempo para preguntas y respuestas. ¿Hay planes para mejorar el soporte de JS y JS Docs? Sí, JS y JS Docs es un esfuerzo individual de Nathan Sanders. Él hace un gran trabajo en el ecosistema de JavaScript dentro de TypeScript. Mi característica favorita de TypeScript es el sitio web revisado que saldrá con la versión 4.0. Facilitará que las personas aprendan TypeScript. En cuanto a ejecutar código TypeScript, es mejor transpilar todo su código primero y luego ejecutarlo. Ts-node es sólido, pero hacer el trabajo de antemano proporciona menos piezas móviles en el sistema. Deno sigue efectivamente este enfoque como un tiempo de ejecución completo.

Háganos saber todas sus cosas favoritas. Que tengan un buen día. Ciao a todos.

Hola, El. Hola. Hola. Así que vamos directo al grano porque veo que tenemos muchas preguntas y no tenemos mucho tiempo para preguntas y respuestas. Comencemos con ¿hay planes para mejorar el soporte de JS y JS Docs? Sí. JS y JS Docs es efectivamente un esfuerzo individual y siempre está trabajando en ello. Creo que ha estado trabajando en eso intermitentemente durante unos cuatro años. Por lo tanto, se mejora continuamente cada vez que tiene tiempo. ¿Tiene este individuo un nombre para que podamos molestarlo cuando esté... Sí, ese es Nathan Sanders. Él hace un gran trabajo en el ecosistema de JavaScript dentro de TypeScript. Ok, entendido. ¿Cuál es tu característica favorita de TypeScript que está actualmente en el plan? Así que mi característica favorita es, de hecho, creo que el sitio web que saldrá con la versión 4.0. Así que el sitio web revisado con todas las cosas nuevas. Es tan largo que escribí tres publicaciones de blog separadas sobre lo que se viene en este cambio de sitio web. Creo que fundamentalmente facilitará mucho que las personas aprendan TypeScript. Genial. Ok, siguiente pregunta porque estamos apurados de tiempo. Muchas preguntas. Esta es de Danilo. He visto a algunas personas ejecutar código TypeScript en tiempo de ejecución con ts-node en lugar de compilarlo antes de implementarlo y ejecutar node directamente. ¿El equipo de TypeScript recomienda una u otra forma? Bueno, quiero decir, tengo una recomendación personal. Creo que el resto del equipo de TypeScript probablemente estaría de acuerdo conmigo en que es mejor transpilar todo su código primero y luego ejecutarlo. Lo veo simplemente como que hay menos piezas móviles en su sistema. Ts-node es sólido, maduro y genial. Pero hacer todo el trabajo de antemano y luego proporcionar algo para trabajar desde es personalmente una excelente manera de hacerlo. Deno hace eso efectivamente.

Puntos problemáticos y Open Source Corporativo

Short description:

Entonces, los principales puntos problemáticos para que las personas comiencen a usar TypeScript son la transición de proyectos solo de JavaScript a aquellos con herramientas más completas, la necesidad de una mejor documentación y el deseo de complementos que permitan el uso de archivos JavaScript con características adicionales. La naturaleza de código abierto corporativo de TypeScript requiere más esfuerzo en términos de soporte y trabajo de accesibilidad, pero también conduce a la construcción de herramientas mejores y más accesibles para todos.

y es una runtime completo construido en torno a eso. Así que es solo una abstracción y no dos. Por lo tanto, de antemano es mi opinión. Muy bien, anotado. De acuerdo. ¿Cuáles son los principales puntos problemáticos y esto es nuevamente de Danilo, por cierto, ¿cuáles son los principales puntos para permitir que más personas en la community usen TypeScript? ¿Cuáles son las cosas que son tal vez un obstáculo para que las personas comiencen a usar TypeScript? Creo que mostré en la charla este tipo de gráfico de la base de usuarios de TypeScript, que es un montón de usuarios de JavaScript a través de VS code y luego se vuelven cada vez más pequeños y más ajustados a medida que usan más y más características de TypeScript. Creo que hay estos puntos de transición que necesitan una mejor documentación. Saltar de un proyecto solo de JavaScript a un proyecto de JavaScript con herramientas más completas, generalmente lo llamamos JS más JS doc. Saltar a través de esas transiciones, creo que podría ser mucho más fácil y eso moverá a las personas hacia una base de código más estricta, más ajustada, como más comprensible por TypeScript y eso te dará mejores herramientas y una mejor seguridad. Y al final del día, esos son algunos de los mayores valores de TypeScript. Así que ayudar en las transiciones entre esos patrones de migración es una de las mayores cosas que creo que podríamos hacer. Sí, tal vez ahí es donde entra en juego la documentación, ¿verdad? Sí. ¿Qué crees que TypeScript debería tomar prestado de otro lenguaje de JavaScript con tipos? No sé si es otro lenguaje de JavaScript con tipos, pero personalmente me gustaría ver complementos para TypeScript que permitan a las personas usar archivos JavaScript que no sean solo JavaScript puro. Piensa en ello como una vista o un hechizo, o incluso un archivo de GraphQL. Todos pueden representarse en el sistema de tipos, pero en realidad no se pueden representar en TypeScript hoy porque TypeScript asume que un archivo es todo JavaScript y vive en JavaScript. Es extremadamente complicado al final del día, y TypeScript está trabajando lentamente en eso, pero eso es lo que realmente me gustaría ver. Creo que eso es parte de las características. Ningún otro lenguaje tiene sistemas de complementos, por lo que no es algo que puedas robar de alguien más, pero creo que es uno de los frutos más fáciles de alcanzar que brindaría a mucha gente muchas herramientas de manera muy fácil. No estamos diciendo robar. Estamos diciendo inspirado por, ¿verdad? Sí, ya sabes, gran honestidad. Muy bien, déjame ver. Hay tantas preguntas que no puedo elegir. Quería hacer una propia. Dado que TypeScript es un proyecto de Microsoft, ¿crees que eso lo hace diferente de otros proyectos de código abierto en términos de community? Es una pregunta interesante, ¿verdad? Eso lleva a, ¿qué es el código abierto corporativo? Microsoft solía lanzar lenguajes de código cerrado. De hecho, Microsoft solía estar muy en contra del código abierto como idea conceptual. Y bastante recientemente, en la última década, cambió completamente esa línea. Ahora mi trabajo se realiza completamente de forma abierta. Creo que trabajar en código abierto corporativo significa que tienes que poner mucho más esfuerzo en el soporte y tienes que hacer mucho más trabajo por adelantado que es algo aburrido. La cantidad de trabajo de accessibility que tengo que hacer es mucho más complicada que trabajos anteriores que he hecho. Y esto es genial, porque, como construir herramientas mejores y más accesibles, las hace disponibles para todos y eleva el nivel. Pero es un intercambio

Accesibilidad, Competidores y Preguntas y Respuestas

Short description:

El trabajo de accesibilidad en TypeScript incluye el soporte de múltiples idiomas, la localización y la mejora de la usabilidad del sitio web. TypeScript no tiene competidores reales en el horizonte. Únete a la sala de preguntas y respuestas en Zoom para hacer más preguntas y tal vez ver un perro. ¡Gracias, Orta!

Esto es días a meses de mi trabajo. Y eso ralentiza las cosas, pero al mismo tiempo permite que más personas tengan acceso. Y eso es totalmente valioso. Estas son las cosas que si estás haciendo código abierto por tu cuenta, a menos que tengas buenas bases para trabajar, es probable que te estés perdiendo muchas cosas que permiten que más personas tengan acceso a estas herramientas. Entonces... Y eso es súper interesante. ¿Puedes dar un ejemplo de algún trabajo de accesibilidad que hayas estado haciendo? Bueno, el más fácil de pensar es, simplemente, el soporte de múltiples idiomas. Si estás aprendiendo un lenguaje de programación, ¿necesito aprender inglés para aprender TypeScript? Sí. ¿Eso es molesto? Sí. Y, ya sabes, ahora tenemos soporte para japonés, chino. Ya hay soporte en el sitio web para portugués y español para que las personas puedan aprender en su propio idioma. Y luego pueden, ya sabes, pueden escribir sus variables en su propio idioma, y algunos de los ejemplos ya lo hacen.

Entonces, la localización es una forma de accesibilidad. Otras formas son, ya sabes, apoyar a las personas sobre JavaScript en el sitio web o asegurarse de que las pestañas se comporten como aplicaciones nativas. Todas estas cosas se unen para sumar tiempo, pero hacen que esté mucho más disponible para todos. Genial. Otra pregunta es, si ves algún competidor real para TypeScript en el horizonte, por Konstantin Botny. Realísticamente, no. Ya sabes, yo usaba Flow antes de pasarme a TypeScript como usuario. Creo que es un sistema de tipos sólido que hace mucho trabajo. Pero tienen metas y objetivos muy diferentes en el equipo de TypeScript, con los que tienen que lidiar con el código de Flow, la base de código de TypeScript. Nosotros tenemos que lidiar con muchos pequeños, más pequeños, bases de código aisladas y hacer todo el tema de la comunidad y las herramientas. Entonces, realísticamente, las metas de TypeScript son proporcionar el lenguaje, pero también proporcionar todas las herramientas para cosas como VS Code y JavaScript, y nadie se acerca en cuanto a VS Code y el tema de JavaScript. Excepto la gente de WebStorm. Están haciendo un trabajo realmente bueno. Pero también pueden apoyarse en TypeScript para trabajar también. Así que lo hacen de vez en cuando. Muy bien. Y lamento no poder responder todas las preguntas. Recomiendo a las personas unirse a Orta en la sala de preguntas y respuestas de Zoom más tarde. Había una cosa más donde se pedía una foto o que un perro entrara al escenario. No sé si estamos hablando de tu perro, de mi perro, del perro de alguien más. Por favor, especifica de qué perro se trata en la sala de preguntas y respuestas y veremos si podemos hacerlo realidad. Como dije, Orta, muchas gracias por tu charla. La gente se unirá a ti en la sala de Zoom para hacer el resto de las preguntas y tal vez ver a tu perro. No lo sé. También quiero decir muchas gracias. De nada. Que tengan un buen día, todos. Las vidas negras importan. Transcrito por https://otter.ai

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Full Stack Components
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
TypeScript and React: Secrets of a Happy Marriage
React Advanced Conference 2022React Advanced Conference 2022
21 min
TypeScript and React: Secrets of a Happy Marriage
Top Content
TypeScript and React are inseparable. What's the secret to their successful union? Quite a lot of surprisingly strange code. Learn why useRef always feels weird, how to wrangle generics in custom hooks, and how union types can transform your components.
Making JavaScript on WebAssembly Fast
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React's Most Useful Types
React Day Berlin 2023React Day Berlin 2023
21 min
React's Most Useful Types
Top Content
We don't think of React as shipping its own types. But React's types are a core part of the framework - overseen by the React team, and co-ordinated with React's major releases.In this live coding talk, we'll look at all the types you've been missing out on. How do you get the props type from a component? How do you know what ref a component takes? Should you use React.FC? And what's the deal with JSX.Element?You'll walk away with a bunch of exciting ideas to take to your React applications, and hopefully a new appreciation for the wonders of React and TypeScript working together.

Workshops on related topic

React, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
Best Practices and Advanced TypeScript Tips for React Developers
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Hussien Khayoon
Kahvi Patel
2 authors
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
Deep TypeScript Tips & Tricks
Node Congress 2024Node Congress 2024
83 min
Deep TypeScript Tips & Tricks
Top Content
Workshop
Josh Goldberg
Josh Goldberg
TypeScript has a powerful type system with all sorts of fancy features for representing wild and wacky JavaScript states. But the syntax to do so isn't always straightforward, and the error messages aren't always precise in telling you what's wrong. Let's dive into how many of TypeScript's more powerful features really work, what kinds of real-world problems they solve, and how to wrestle the type system into submission so you can write truly excellent TypeScript code.
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
Gleb Bahmutov
Gleb Bahmutov
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
0 to Auth in an Hour Using NodeJS SDK
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Asaf Shen
Asaf Shen
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher