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.

Resulta que tenemos que implementar cierta lógica para generar código HTML. Esa lógica podríamos codearla server-side con Python o bien client-side con JavaScript. Personalmente prefiero Python que JavaScript pero en este caso codear server-side con Python implica tener que tocar código de una aplicación Django mientras que en el caso de ir por el camino client-side/JavaScript estaría trabajando en un código completamente nuevo.

Mis compañer@s de equipo no parecían muy convencidos, estimo que porque se sienten mucho más cómodo en Python que yo, pero finalmente me dieron un voto de confianza. ¡¿Quién lo hubiera dicho?! Yo «vendiendo» JavaScript.

Continuará….

Para muchos de mi generación, los que empezamos a programar en la web 1.0 allá por fines de los ’90 comienzos de 2000, Javascript nunca fue «algo serio». En general uno no aspiraba a ser programador JavaScript. Uno podía definirse como programador de un lenguaje en particular: Java, Php, Visual Basic, C++, etc. y en todo caso si era necesario tiraba algunas líneas de JavaScript.

Claramente los tiempos han cambiando y también JavaScript. Y en un punto las cosas se han pasado de rosca, ahora tenemos gente que directamente se define como «programadores de un framework basado en JavaScript» (react developer, angular developer, etc.) y lamento decir que he visto algunos de estos programadores que apenas si dominan JavaScript y no tienen ni idea de la diferencia en JavaScript y ECMAScript. Ojo, no pretendo hacer un juicio de valor sobre esto, tal vez pueda resultar conveniente saber de React sin tener demasiada idea de JavaScript con el fin de manejar un mayor nivel de abstracción y bajar la carga cognitiva.

En fin, hoy en día JavaScript como lenguaje está en un estado, a mi parecer, bastante maduro. Sin embargo creo que el ecosistema JavaScript aún está medio inestable. Todo el tiempo están saliendo nuevas librerías/frameworks/componentes para resolver cuestiones recurrentes. Es así que a la hora de resolver una problemática hay varias opciones de componentes/frameworks. Esto puede parecer positivo pero es también un arma de doble filo. Cuando un programador experimentado se enfrenta a varias opciones es precisamente su experiencia una cuestión central para elegir la opción a utilizar. Pero ocurre que en el mundo JavaScript hay mucho programador sin demasiada experiencia y en esos casos el tener varias opciones puede resultar más riesgoso. Cuando digo «mucho programador sin experiencia», lo digo en términos comparativos con otros lenguajes. Cuando vemos la oferta de bootcamps y cursos de programación para gente que se está iniciando en esta disciplina, vemos que la gran mayoría en la actualidad están relacionados a JavaScript y tecnologías de frontend en general.

Al margen de todo lo anterior, hoy en día tenemos herramientas JavaScript para construir interfaces de usuario web (angular, react, vue), aplicaciones móbiles (react native, flutter), y aplicaciones/servicios server-side (nodejs). Esto hace que empiece a sonar muy atractivo tener JavaScript como lenguaje de cabecera, ya que parece esta por todos lados. Sin embargo no hay que tomar esto a la ligera porque si bien estamos hablando del mismo lenguaje de programación, cada escenario implica un stack de frameworks y herramientas distintos. Personalmente, por mucho tiempo no le di mayor importancia a JavaScript y siempre que me lo cruzaba, veía puntualmente de resolver la cuestión inmediata que tenía entre manos sin profundizar demasiado. Pero ya desde hace un tiempo he comenzado a tomarlo más seriamente, estudiándolo más en profundidad.

Como mencioné hace un tiempo, me he visto en la necesidad de meterme de lleno con Node/JavaScript. Para ello he echado mano de 3 recursos:

• Libros: tengo una lista de libros que me recomendaron, pero por el momento solo he visto dos libros gratuitos de la gente de Syncfusion: Node.Js Succinctly y JavaScript Succinctly.
• Tutoriales de nodeschools
• Sesiones de pair-programming con ingenieros experimentados

Y obviamente mas allá de todo esto: práctica, práctica y más práctica.

Si bien aún me queda mucho por aprender, hay algunas cuestiones que ya tengo claras:

• El lenguaje JavaScript en términos de sintáxis no me gusta
• La experiencia de desarrollo es muy «suave», muy parecida a la experiencia en Ruby e incluso mejor en algunas cuestiones.

Continuará…

Si bien JavaScript tiene unos cuantos años, desde el auge de la web 2.0 su popularidad ha ido constantemente en ascenso. En los últimos años han aparecido diversas herramientas y frameworks que permitieron a JavaScript ir más allá de los navegadores web.

Como efecto colateral, ya no importa si uno se consideraba programador Java, C# o Ruby, hoy por hoy todo el mundo debe tener cierto manejo de JavaScript.

Personalmente nunca me gustó JavaScript pero a pesar de eso no dudo en usarlo cuando creo que es la opción apropiada para una determinada solución. Eso me llevo a trabajar con jQuery y Node.js.

Recuerdo que hace dos o tres años, mientras que en el mundo JavaScript empezaban a surgir diversos frameworks y herramientas, en el mundo de los Sysadmins empezaban a popularizarse herramientas de automatización de infraestructura. Justamente en el aquel momento me encontré en un contexto en el que tuve que elegir trabajar como desarrollador FrontEnd con JavaScript o bien tomar un rol de SysAdmin/DevOp y meterme con las herramientas de automatización. Precisamente fue esta última opción la que elegí. Creo que profesionalmente aquella fue una elección muy acertada pues el manejo de herramientas de automatización me permitió participar en diversos proyectos muy interesante. Pero hace un par de meses me rendí, siendo consciente que ya no es posible escapar de la marea JavaScript me puse a aprender AngularJS y agregué a mi backlog Meteor y React.

 

Este semana estuve participando de un entrenamiento en JavaScript organizado por la gente de OLX con quien vengo trabajando desde hace casi un año.

El entrenamiento fue dictado por Kyle Simpson (@getify) y estaba titulado «Advanced JavaScript». Cómo dijo el propio Kyle durante la apertura, un nombre mejor podría haber sido «JavaScript Foundations», pues justamente el foco estuvo en cuestiones básicas, de «bajo nivel» en cierto punto, que en mi opinión la gran mayoría de la gente que escribe JavaScript desconoce.

El entrenamiento me pareció muy interesante, me enteré de cosas de las que no tenia ni idea. Ojo, también debo admitir que nunca le puse muchas pilas a aprender JavaScript. He escrito código y aprendido lo poco que sé a base de «prueba y error». A pesar de esto soy consciente que cada vez es más necesario para todo programador, manejar cierto nivel de JavaScript.

Una cosa que confirmé en el entrenamiento es que nunca voy a llegar a un nivel avanzado en el uso de JavaScript, pues resulta que el lenguaje tiene tantas particularidades/características que llegar a dominarlas me llevaría un tiempo tal que no estoy dispuesto a invertir.

Le agradezco a David Grandes y Santiago Villa del equipo Mobile de OLX por haberme invitado.