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

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

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

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

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.

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.

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.

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