¿Realmente necesitamos TypeScript en 2020?

TypeScript se ha convertido en una de las habilidades esenciales para un desarrollador web moderno. En 2019, ingresó a los 10 idiomas más utilizados en GitHub , su soporte se agregó por completo a la aplicación Crear reacción, y puede encontrar muchas otras pruebas de su creciente popularidad. Al mismo tiempo, lenguajes como Java y C continúan perdiendo terreno .

Cuando hablamos de los beneficios de TypeScript, generalmente nos viene a la mente la siguiente lista:

• TypeScript admite escritura estática
• TypeScript hace que el código sea más fácil de leer y comprender.
• TypeScript ayuda a evitar los muchos errores dolorosos que los desarrolladores suelen hacer, gracias al código de verificación de tipos
• TypeScript alienta a los desarrolladores a seguir las mejores prácticas de OOP
• Como resultado de lo anterior, TypeScript ahorra tiempo a los desarrolladores

Curiosamente, todos los elementos de esta lista se toman por fe sin un ojo crítico. Hoy sugiero que considere estos puntos más de cerca y descubra si realmente nos son tan útiles.

Dado que el objetivo principal de TypeScript es reducir la cantidad de errores, ¿por qué es tan importante? La respuesta es simple: cuantos menos errores, por lo tanto, el tiempo menos costoso que dedicamos a los desarrolladores y evaluadores, obtendremos un producto valioso por menos dinero y comenzará a generar ingresos antes.

Con eso en mente, descubramos cómo TypeScript puede ayudarnos a mejorar nuestra productividad y eficiencia.

Escritura estática: ¿una tableta mágica para errores?

La característica principal de TypeScript es la compatibilidad con la escritura estática. Existe una creencia generalizada entre los desarrolladores de que la tipificación dinámica es la fuente de casi todos los problemas que tienen los desarrolladores de JavaScript.

¿Me pregunto qué gente mala encuentra en la escritura dinámica? ¿Por qué no cae tal aluvión de críticas en otros lenguajes dinámicos, por ejemplo, Python y Ruby? Solo puedo suponer que el problema no está tanto en la escritura dinámica como en la conversión de tipos en JavaScript. De hecho, a veces puede ser muy desagradable sorprender un código como este:


Pero este es un problema, más bien, un pobre conocimiento de JavaScript, y no del lenguaje en sí. Imagina que tienes un poderoso auto deportivo. Pero tus habilidades para conducir son lo suficientemente mediocres. ¿Requerirá que el fabricante del automóvil haga cambios para reducir la velocidad máxima del automóvil o aprenda a conducir de manera avanzada y se convierta en un profesional excepcional? Lo que TypeScript nos ofrece es limitar las posibilidades de escritura dinámica, en lugar de aprender JavaScript correctamente.

Otra pregunta para los oponentes de la escritura dinámica es que si la escritura estática es tan buena, ¿por qué todavía encontramos errores en el código escrito en Java y C #? Sí, podemos detectar estos errores en la etapa de compilación, pero seamos honestos, esto no es suficiente. Debemos seguir los principios SÓLIDOS y otras mejores prácticas para garantizar un código de calidad. Y de nuevo, esto se aplica más al conocimiento y las calificaciones de los programadores que al lenguaje de programación.

¿El código TypeScript es más fácil de leer?

Aquí hay 2 ejemplos de Redux Thunk:

const getUsers = async dispatch => { //... try { const users = await APIService.get('/users') dispatch(successGetUsers(users)) } catch(err) { dispatch(failedGetUsers(err)) } } 

y lo mismo en TypeScript:

 const getUsers = (): ThunkAction<void, {}, {}, AnyAction> => async (dispatch: ThunkDispatch<{}, {}, AnyAction>) => { //... try { const users: User[] = await APIService.get('/users') dispatch(successGetUsers(users)) } catch(err) { dispatch(failedGetUsers(err)) } } 

¿Qué significan todos estos genéricos? ¿Por qué hay 2 objetos vacíos en ellos? ¿Cuánto tiempo deberíamos pasar leyendo la documentación para resolverlo todo? Bueno, eso sigue siendo normal para Redux Thunk, ya que es un middleware muy popular para Redux, tienen un excelente equipo de soporte y documentación. Pero, ¿qué pasa si tenemos que mantener un código que no tiene todo esto?

¿No habrá más errores sutiles?

En el ejemplo anterior, viste cómo TypeScript hace que el código sea más detallado. Como sabe, cuanto más grande y complejo sea el sistema, mayor será la probabilidad de error. Además de los errores que podríamos cometer en el código JavaScript, también debemos tener cuidado de no cometer un error tipográfico en las interfaces, un error en los genéricos, etc. Para ser justos, vale la pena señalar que el compilador lo ayudará a encontrar y corregir rápidamente tales errores, pero sin TypeScript no los habríamos encontrado en absoluto.

Siguiendo las mejores prácticas de OOP

Como sabemos, debemos seguir las mejores prácticas si queremos escribir código de alta calidad, fácilmente escalable y fácil de mantener. Y TypeScript nos puede ayudar con esto. Eso suena genial, veamos un ejemplo de Express:

userRoute.js

 router.get('/users', (req, res) => { //get users from DB res.json(users) }) router.post('/users', (req, res) => { //create user res.json(userCreated) }) 

userRoute.ts

 class UserRouter { public router = express.Router() public address = '/users' constructor() { this.initRoutes() } initRoutes() { this.router.get(this.address, this.getUsers) this.router.post(this.addressm this.createUser) } getUsers(req: express.Request, res: express.Response) { //get users from DB res.json(users) } createUser(req: express.Request, res: express.Response) { //create user res.json(userCreated) } } 

Lo primero que llama la atención es que se está escribiendo más código nuevamente. Usamos clases para escribir en estilo OOP. Luego tendremos que instanciar estas clases. Además, podemos usar interfaces, tipos estáticos y otras construcciones. Y para que todo esto no se convierta en un caos completo, no tenemos más remedio que utilizar las mejores prácticas. Y esto es lo que se llama: "alentar a los desarrolladores a usar las mejores prácticas de OOP" .

Cuando los desarrolladores votaron por lenguajes simples, flexibles y dinámicos como JavaScript y Python, cuando el paradigma de programación funcional mostró sus ventajas y la capacidad de resolver algunos problemas de manera más elegante y eficiente (y en JavaScript podemos usar ambos enfoques), TypeScript nos empuja a escribir código a la antigua usanza al estilo de OOP Java y C #.

Para resumir, vimos que TypeScript realmente no ahorra nuestro tiempo, ni nos protege de una gran cantidad de errores, ni aumenta nuestra productividad. Además, requiere escribir más código, configuración adicional, archivos de definición de tipo y perder tiempo leyendo documentación adicional. Un novato probablemente escribirá, quizás no sea una aplicación ideal, pero que funcione en JavaScript o Ruby, mientras que escribiremos una excelente aplicación TypeScript de acuerdo con todos los principios. Y luego nos contratará para reescribir su startup, donde podemos usar TypeScript para hacer todo bien.

Es divertido ver cómo desaparecen los lenguajes masivos, verbosos y complicados, incapaces de competir con los más dinámicos y simples, y luego estos últimos rechazan todo lo que les ayudó a desarrollarse tan rápidamente y se esfuerzan por volverse más pesados, más verbosos y más complicados.

Lo veo así:

Bien, ya no queremos Java, queremos JavaScript. Pero no nos gusta JavaScript tal como es, así que hagámoslo un poco más parecido a Java. Genial, ahora tenemos todo lo que estaba en Java, y esto no es Java. Vamos!