Directorio de artículos
El trasfondo de la aparición de TypeScript
Puntos débiles de JavaScript
La aparición de cualquier nueva tecnología es para resolver un cierto punto de dolor de la tecnología original .
¿Es JavaScript un buen lenguaje de programación?
Puede que no todos tengan la misma opinión, pero desde muchas perspectivas, JavaScript es un muy buen lenguaje de programación ;
Además, se puede decir que este lenguaje no será reemplazado por mucho tiempo y será ampliamente utilizado en más campos;
La famosa ley de Atwood :
Jeff Atwood, uno de los fundadores de Stack Overflow, propuso la famosa Ley de Atwood en 2007.
Cualquier aplicación que pueda implementarse en JavaScript eventualmente se implementará en JavaScript.
De hecho, hemos visto que esta frase se va cumpliendo paso a paso :
Siempre hemos usado JavaScript para el desarrollo web;
Para el desarrollo móvil, el desarrollo multiplataforma se puede lograr con la ayuda de marcos como ReactNative, Weex y Uniapp, y la tecnología multiplataforma también usa JavaScript;
El desarrollo de pequeños programas también es inseparable de JavaScript;
Podemos desarrollar aplicaciones de escritorio con la ayuda de Electron;
El desarrollo del lado del servidor se puede realizar mediante JavaScript con la ayuda del entorno Node.
Y con el rápido desarrollo del campo front-end en los últimos años, JavaScript ha sido rápidamente popularizado y amado por la mayoría de los desarrolladores.Con la ayuda del poder de JavaScript, cada vez más personas usan JavaScript para desarrollar .
¿Un buen JavaScript no tiene inconvenientes?
De hecho, debido a varios factores históricos, el propio lenguaje JavaScript tiene muchas deficiencias;
Por ejemplo, ES5 y el uso anterior de la palabra clave var sobre el alcance;
Por ejemplo, el tipo de matriz diseñado originalmente por JavaScript no es un espacio de memoria contiguo;
Por ejemplo, hasta hoy JavaScript no ha agregado el mecanismo de detección de tipos;
JavaScript está mejorando lentamente
Es innegable que JavaScript está mejorando cada vez más, tanto desde el diseño de bajo nivel como desde el nivel de la aplicación.
La introducción de ES6, 7, 8, etc., ha hecho que el lenguaje sea cada vez más moderno, seguro y conveniente.
Pero sepa que hoy en día, JavaScript todavía no ha progresado en la verificación de tipos (por qué la verificación de tipos es tan importante, hablaré de eso más adelante).
tipo de problema
Antes que nada, debes saber que tenemos un consenso en el desarrollo de la programación: cuanto antes aparezcan los errores, mejor
Si puede encontrar errores al escribir código, no los encuentre cuando se compila el código (la ventaja de IDE es ayudarnos a encontrar errores durante el proceso de escritura de código).
Si puede encontrar errores durante la compilación del código, no los encuentre cuando se ejecuta el código (la verificación de tipos puede ayudarnos a hacer esto muy bien).
Si puede encontrar errores durante el desarrollo, no los encuentre durante las pruebas, y si puede encontrar errores durante las pruebas, no los encuentre después del lanzamiento.
Ahora lo que queremos explorar es cómo encontrar errores en el código durante la compilación del código :
¿Puede JavaScript hacerlo? No, veamos los siguientes problemas de código que pueden ocurrir con frecuencia.
// 当前foo函数, 在被其他地方调用时, 没有对参数做任何的校验
// 1> 没有对类型进行校验(字符串或数字都可以传入)
// 2> 没有对是否传入参数进行校验
function foo(message) {
if (message) {
console.log(message.length);
}
}
foo("Hello World");
foo("你好啊TS");
foo() // 错误的调用代码会报错(IDE不会报错), 报错后续代码不会执行
Aquí hay un error muy común que cometemos :
La gran razón de este error es que JavaScript no impone ninguna restricción sobre los parámetros que pasamos , y este error solo se puede encontrar durante el tiempo de ejecución;
Y cuando ocurre este error, afectará la continuación de la ejecución del código posterior, es decir, todo el proyecto colapsará profundamente debido a un pequeño error ;
Podrías estar pensando: ¿cómo pude haber cometido un error de tan bajo nivel?
Cuando escribimos demostraciones simples como la nuestra arriba, los errores como este son fáciles de evitar, y cuando lo hacen, son fáciles de verificar;
Pero, ¿y cuando desarrollamos un gran proyecto? ¿Puedes garantizar que no tendrás ese problema? Y si estamos llamando a la biblioteca de clases de otra persona, ¿cómo sabemos qué tipo de parámetros nos permiten pasar otros? En otras palabras, si encapsula una función para que la usen otros, ¿cómo sabrán los demás qué parámetros necesita pasar su función?
Sin embargo, si podemos agregar muchas restricciones a JavaScript, podemos evitar este tipo de problemas en el desarrollo :
Por ejemplo, el mensaje en la función que acabamos de pasar es un tipo que debe pasarse.Si la persona que llama no lo pasa , se informará un error durante la compilación ;
Por ejemplo, requerimos que sea de tipo String, y si se pasan otros tipos, se informará directamente de un error;
Entonces puede saber que muchos errores se encuentran durante la compilación, en lugar de esperar a ser descubiertos y modificados en tiempo de ejecución;
Ya nos hemos dado cuenta brevemente de algunos de los problemas causados por la ausencia de verificación de tipo. Dado que JavaScript no consideró las restricciones de tipo desde el comienzo de su diseño, ha causado que los desarrolladores front-end carezcan de pensamiento de tipo :
Los desarrolladores front-end generalmente no se preocupan por el tipo de variables o parámetros.Si se debe determinar el tipo, a menudo necesitamos usar varios juicios para verificar;
Las personas que van al front-end desde otras direcciones siempre se preocuparán de que su código no sea lo suficientemente seguro y robusto porque no hay una restricción de tipo;
Por lo tanto, a menudo decimos que JavaScript no es adecuado para desarrollar proyectos a gran escala, porque una vez que el proyecto es enorme, esta restricción de tipo suelto traerá muchos riesgos de seguridad y no existe un buen tipo de contrato entre varias personas que lo desarrollan .
Por ejemplo, cuando implementamos una biblioteca de clases principal, si no hay restricciones de tipo, debemos realizar varias verificaciones en los parámetros que otros pasan para garantizar la solidez de nuestro código;
Por ejemplo, cuando llamamos a la función de otra persona, la otra parte no comenta sobre la función. Solo podemos mirar la lógica interna para comprender qué parámetros necesita pasar esta función y qué tipo de valor de retorno se requiere;
Para compensar las deficiencias de las restricciones de tipo de JavaScript y aumentar las restricciones de tipo, muchas empresas han lanzado sus propias soluciones :
En 2014, Facebook lanzó el flujo para verificar el tipo de JavaScript;
En el mismo año, Microsoft también lanzó TypeScript 1.0;
Ambos trabajan para proporcionar verificación de tipos para JavaScript;
Y ahora, no hay duda de que TypeScript ha ganado por completo :
En Vue2.x, el flujo se usa para la verificación de tipos;
Vue3.x ha cambiado a TypeScript en todos los ámbitos, y el 98,3 % se ha refactorizado usando TypeScript;
Angular usó TypeScript para la refactorización de proyectos en una etapa muy temprana y necesita usar TypeScript para el desarrollo;
E incluso algunos de los propios productos de Facebook utilizan TypeScript;
Aprender TypeScript no solo puede agregar restricciones de tipo a nuestro código, sino también cultivar a nuestros programadores front-end con el pensamiento de tipos .