Durante años, ha habido un odio casi religioso, o al menos tribal, hacia JavaScript entre los desarrolladores geniales “en grupo”. JavaScript y PHP ambos. Si eras un programador hotshot, era genial odiarlo en JavaScript.
Lo sé, porque yo era parte de eso. Elegiría JavaScript como todos los demás. ¡Era un blanco tan fácil! Tantos problemas bien conocidos. Se colgó en el DOM, y como resultado tuvo que lidiar con tortuosas incompatibilidades del navegador. ¡Y había tantos malos desarrolladores de JavaScript!
Luego conocí y trabajé con un desarrollador que respetaba e insistió en que, en el fondo de JavaScript, había un núcleo de un buen lenguaje.
- ¿Por qué debería importarme la programación asincrónica (en Javascript / Node.js)?
- ¿Debería permitirse a los usuarios cambiar las URL en mi sitio web, o esto no es importante?
- ¿Cuáles son las API de descanso más útiles?
- ¿Debo leer sobre algoritmos si estoy aprendiendo el desarrollo front-end?
- ¿Qué debo poner en mi currículum voluntario para un trabajo de programación?
Al principio, realmente no me importó. Esto fue a principios de la década de 2000. Estábamos haciendo juegos casuales que tenían un tamaño máximo de descarga de 20Mb. Lua fue nuestro lenguaje de script preferido porque era muy pequeño, rápido, fácil de insertar y elegante. Para incluir un intérprete de JavaScript, estábamos buscando un mínimo de 10Mb de sobrecarga. Así que nos quedamos con Lua.
Y más tarde me doblé en Lua (un lenguaje que tiene un parecido sorprendente con las “partes buenas” de JavaScript) y escribí un juego que dependía mucho de él. Incluso escribí el código del lado del servidor en Lua. [1] De hecho, fue una locura rápida, y Lua era y es un lenguaje muy elegante, flexible y poderoso, pero comencé a ver sus grietas.
Finalmente, tuve la oportunidad de trabajar con JavaScript mientras trabajaba en Amazon. Tenía un juego en el que quería trabajar que se beneficiaría de JavaScript [2], por lo que tenía un motivo alternativo para aprender el idioma. Debido a ese prejuicio de JavaScript en toda la industria, mi ligero interés me consiguió el trabajo, ya que todos los demás dieron un paso atrás al pedir voluntarios.
Así que me sumergí en aprender JavaScript. Leí “JavaScript: The Good Parts” de Crockford. Aprendí sobre linters, Node.js, scripts de compilación, Grunt (y luego Gulp) y la transpilación.
Y dentro de JavaScript, como mi amigo había sugerido años antes, encontré ese lenguaje al que se refiere Crockford. Sí, hay un gran lenguaje dentro de JavaScript.
Pero lo más importante, hay un ecosistema increíble en Node.js. Uno de los puntos recurrentes de Lua era que no tenía un administrador de paquetes o ecosistema robusto. Tiene LuaRocks, pero juro que solo funciona de manera confiable en una plataforma a la vez para cada paquete, y esa plataforma rara vez es Windows (recuerde, soy un desarrollador de juegos, y los desarrolladores de juegos están fuertemente enfocados en Windows). Hay algunas excepciones notables, pero muchos de los paquetes también estaban incompletos o rotos de otras maneras. Esto significaba que poner en marcha un entorno siempre era un desafío, más aún si tenía que ser multiplataforma.
Pero Node.js tiene un gran ecosistema. NPM no es perfecto, pero es mucho mejor de lo que había usado antes. Y cuando un paquete funcionaba en una plataforma, normalmente solo funcionaba en todas partes. (Más recientemente, el administrador de paquetes de hilo hace un trabajo aún mejor que npm, pero estoy divagando).
Y JavaScript, aunque todavía no es tan rápido como LuaJIT, sigue siendo bastante rápido. Mucho más rápido que Ruby o Python. PHP, gracias a una decisión de ingeniería profundamente pobre en Facebook que ha resultado en una gran cantidad de esfuerzos de ingeniería, se ha mejorado en velocidad en varios órdenes de magnitud, pasando del peor desempeño a estar a la par con JavaScript para un rendimiento bruto, pero aún así no tiene un lenguaje excelente escondido en él. He usado PHP. Tiene las partes malas de JavaScript sin las buenas.
Hablando de esas “partes malas”, eso es lo que ayuda a evitar. Si no sabe qué es un linter, es una herramienta que se ejecuta en su código que aplica ciertas convenciones y prácticas de codificación. Uno puede configurarse para evitar que caiga en muchas de las dificultades de JavaScript, de modo que esté escribiendo un código que sea más fácil de mantener y más robusto.
Y rendimiento: si bien LuaJIT es increíblemente rápido, JavaScript es lo suficientemente bueno y, en las últimas versiones de Node, en realidad supera a OpenResty. [3]
Pero el clavo final en el ataúd de Lua, y lo que me puso sólidamente en la corte de JavaScript, no es parte de JavaScript propiamente dicho, sino TypeScript.
Como desarrollador de juegos, venía de lenguajes como C ++ con tipos estáticos. Me sentí liberado por la falta de restricciones de los tipos dinámicos en Lua, pero a medida que los juegos y otros programas se volvieron más complejos, los tipos dinámicos se convirtieron en un obstáculo. Son un ejemplo clásico de deuda técnica: más rápido para comenzar a expensas de pagarlos con intereses a medida que el proyecto se expande.
Así que probé TypeScript, temiendo que tendría las mismas restricciones que C ++, pero dispuesto a intentarlo para evitar que los proyectos se vuelvan inmanejables a medida que crecen. ¿Y sabes qué? TypeScript le ofrece un sistema de tipos casi tan poderoso como el de C ++, pero con toda la flexibilidad de JavaScript justo para preguntar.
Y fue entonces cuando finalmente hizo clic. JavaScript y TypeScript ganan. Y me alejé de muchos años de ser un gran defensor de Lua. [4]
Volviendo a la pregunta original: he tenido debates con Richard Eng. No estamos de acuerdo sobre lo que es importante. Creo que hay muchos JavaScript terribles, en gran parte porque JavaScript es fácil de aprender para un principiante. Pero JavaScript, el lenguaje, siempre fue un intento de ser mejor que otros lenguajes contemporáneos; se basa libremente en Self, un lenguaje prototípico que se basa libremente en Smalltalk, que es el lenguaje por el que Richard defiende. Sin embargo, no veo muchos trabajos de Smalltalk fuera de Europa occidental, por lo que, dependiendo de dónde viva, es probable que no sea una buena opción de trabajo, independientemente de los méritos del idioma. Y, como en el caso de Lua, creo que no se puede descartar el ecosistema, y el ecosistema de Node gana en picas.
En cuanto a si debe aprender el último marco: si está buscando trabajo, vea qué trabajos en su área están contratando y aprenda eso. Es realmente así de simple.
Pero trate de hacer que su empleador use un linter, o use uno usted mismo. Y lea “Las mejores partes”. Hay un gran lenguaje escondido allí. Intenta usarlo en lugar del resto. Como beneficio adicional, aprenda TypeScript. Es el idioma predeterminado / preferido de Angular, y su uso es prácticamente un superpoder.
Buena suerte.
PD: No me preocuparía por Node.js “muriendo” pronto tampoco. JavaScript sigue siendo uno de los diez idiomas principales, [5] y como usted señala, hay muchas posibilidades de trabajo. Los informes de la muerte de Node son muy exagerados, parafraseando a Mark Twain.
Notas al pie
[1] OpenResty® – Sitio oficial
[2] Steel Dragons: un nuevo tipo de juego de mesa
[3] Puntos de referencia del marco TechEmpower
[4] Adiós, Lua · RealMensch
[5] Índice de Popularidad de Lenguaje de Programación PYPL