Se considera Millennials a aquellos nacidos entre comienzos de los 80 y mediados de los 90. Los millennials y pre-millennials que se dedicaron a la programación trabajaron en una web distinta. Muchos vivimos en la web 1.0.

No había programadores de front. Yo creo que no había una «división» tan marcada de programadores. Recuedo los «duelos» Java vs. Net, pero al margen de eso creo que había «programadores web» y «programadores a secas».

No había estándares web, cada navegador se comportaba distinto al interpretar el código js/css/html.

Tal vez como consecuencia de lo anterior, había «engendros» (como Applets y ActiveX) que corrían dentro del navegador pero que estaban programados server-side y no es que uno escribiera código Java que luego era traducido a js/css/html, sino que los navegadores tenían complementos que les permitían ejecutar binarios (jar, dlls, etc). Pero igualmente era raro, porque estos complementos tampoco corrían en todos los navegadores. Yo hablo de esto en pasado pero sin duda hay soluciones de este tipo que aún hoy están en funcionamiento.

Tampoco había la variedad de navegadores que tenemos hoy en día.

Y finalmente, nadie tomaba JavaScript muy seriamente, nadie se dedicaba a JavaScript. Un programador que hacía web trabajaba con Php, Asp, Perl, Java o incluso C++ (haciendo los denominados CGIs) y si por alguna razón necesitaba utilizar JavaScript lo googleable en el momento que lo necesitaba. Como el soporte de JavaScript ofrecido por los navegadores no era estándar, tampoco se podía hacer demasiado en JavaScript (técnicamente se podía pero era muy costoso y terminaba siendo insano).

Creo que muchos de esta generación intentamos por un tiempo escaparle a JavaScript. De hecho algunos aún siguen intentando escapar. Más aún, algunos vendors insistieron mucho tiempo en proveer soluciones para que el programador no tenga que tocar JavaScript. Soluciones como las provistas por Microsoft con las primeras versiones de ASP.NET iban aún más allá, posibilitaban al programador trabajar exclusivamente con C# sin tener que meterse con las tecnologías web y dejar en manos de la plataforma la generación del código (js/css/html) que finalmente se ejecutaba en el navegador. Menciono a Microsoft porque ahí está el grueso de mi experiencia, pero otros vendors siguieron estrategias análogas. Y menciono explícitamente «las primeras versiones de ASP.NET» porque creo que en un punto el propio Microsoft tomó conciencia de las limitaciones de ese enfoque y cambió el rumbo. Ya desde hace años Microsoft viene apostando al desarrollo client-side dándole un gran impulso a TypeScript.

Personalmente me rendí a JavaScript hace varios años pero los proyectos en los que estuve involucrado me mantuvieron lejos del navegador. Profundicé mi conocimiento de JavaScript a partir de algunas cosillas que hice con Node y alguna otra cosilla que hice principalmente con Angular.

Como ya mencioné en algún post anterior, hoy por hoy estoy metiéndome muy de lleno en el mundo de desarrollo JavaScript client-side y es por ello que en los próximos días/meses iré compartiendo recursos de lo que vaya aprendiendo. En general estarán enfocados desde la perspectiva pre-millennials ya que esa es mi procedencia.

Creo que hay mucho material de JavaScript/Frontend dando vueltas por la web pero mi sensación es que la gran mayoría es material introductorio y enfocado en programadores que están dando sus primeros pasos en la profesión. Al mismo tiempo la mayoría del material que veo es para el escenario de creación de aplicaciones desde cero, lo cual tiene mucho sentido pero hay también una parte de la población que tenemos que lidiar con aplicaciones existentes y para esos escenarios creo que no abunda el material. Esta percepción motiva en gran medida mi intención de compartir lo que vaya descubriendo.

Continuará…

Nuestra aplicación Django de 2014 tiene un componente de código JavaScript (client-side) construido a la vieja usanza, con pruebas y modularizado, pero a la viaja usanza. Las pruebas estan escritas en Jasmine/Karma y la modularización está hecha en base «namespaces«. El bundle productivo es generado por Django.

A partir de ciertas necesidades de evolución funcional y de mejorar la experiencia de usuario decidimos llevar la parte visual de nuestro componente a React. Alguien podría preguntarse porqué React y no algún otro como Vue o Angular. La elección está basada en dos cuestiones. En primer lugar no queremos hacer una SPA, sino simplemente reemplazar componente dentro de un sitio existente. Este es uno de los escenarios explícitamente atacados por React a punto tal que ya en el tutorial inicial nos muestra como hacerlo. El otro tema es que en breve tendremos que rehacer nuestra aplicación mobile para lo cual apuntamos a React Native así que encarar este componente con React nos resultó una conveniente primera aproximación al mundo React.

A la pasada, aprovechamos y, decidimos actualizar el stack del proyecto. En primer lugar decidimos quedarnos en JavaScript (en lugar de pasar TypeScript) al mismo tiempo elegimos NPM + WebPack + Babel. También pasamos de Jasmine a Jest para los tests.

Uuuufffff. Durísimo. Si bien yo ya estaba familiarizado con lenguaje JavaScript (sintáxis, características del lenguaje, etc) estaba bastante ajeno a las cuestiones de tooling (frameworks, gestor de paquetes, bundlers, transpilers, linters, etc, etc) y meterme con estas cuestiones me ha resultado bastante desgastante. Al mismo tiempo si bien había hecho algún proyectito menor con JavaScript «moderno», en esos casos había comenzado desde cero utilizando un stack preconfigurado donde ya de entrada tenemos todo el tooling cableado. Pero en este caso teníamos una base de código existente y tuvimos que ir haciendo nosotros mismos la elección y cableado de todo el tooling. La parte positiva de esto es que nos permitió entender ciertas cuestiones con un nivel de detalle tal que al usar el stack prearmado uno ni se entera.

La cantidad de opciones existente y el vértigo de evolución de las herramientas JavaScript creo que no tiene igual en otros lenguajes. Esto lleva a que las posibilidades combinación de herramientas sea realmente muy grande y a la hora de tener que buscar información de un stack específico, todo sea más trabajoso. Esto queda muy en evidencia cuando lo comparamos con otros lenguajes donde las opciones son mucho más acotadas. Personalmente vengo muy acostumbrado del mundo .Net/C# donde en general hay una forma de hacer las cosas, si bien en ocasiones existen alternativas la comunidad ha decantado claramente hacía ciertas opciones que se han convertido en un estándar de facto. En el medio de toda esta movida fui a dar con la página stateofjs.com que realizada una encuesta y provee un interesante informe sobre la evolución del uso de las herramientas en el mundo JavaScript que confirma en cierto modo mi sensación de vértigo.

En fin, el proyecto ya está encaminado y en siguientes post iré compartiendo como hemos resulto distintas cuestiones particulares.