Aprender Javascript en 2016

03 Ene 2017

Son tiempos difíciles para el desarrollador frontend. Cada día vemos aparecer nuevas herramientas, sistemas y paradigmas que desplazan a los anteriores volviéndolos obsoletos. Vivimos en una época de continuo cambio, de continua renovación. En muchas ocasiones, no hemos tenido tiempo aún de analizar una nueva tecnología cuando inmediatamente surge otra que reclama la atención de toda la comunidad obligándonos a considerarla.

El siguiente artículo, publicado originalmente por Jose Aguinaga, ilustra perfectamente las dificultades con la que se enfrentan los nuevos programadores; no nuevos en el sentido de que se asomen por vez primera al mundo del desarrollo, sino de aquellos que, o bien han estado ausentes durante un tiempo, o bien llegan desde otras ramas diferentes como ese subconjunto al que llamamos backend.

La conclusión final es simple y directa: son tiempos difíciles. Basta con que hayamos estados trabajando durante más de un año en un mismo proyecto para que, a su conclusión, nos enfrentemos con una realidad muy diferente a la que nos acogimos cuando lo empezamos… Incluso, y aunque el texto nos mienta en sus primeras líneas, mientras estemos leyendo el texto, el imparable ecosistema frontend estará sacando a la luz nuevas formas de hacer las cosas.

Un detalle final antes de pasar al artículo: el texto no está escrito en clave de humor y aún así, no podremos evitar soltar una risota cómplice mientras compartimos la desesperación de su protagonista. Es la otra cara de esta realidad que nos toca vivir: en el fondo, aunque participemos de ella, todos somos perfectamente conscientes de la locura sinsentido en que se ha convertido el desarrollo moderno.

Disclaimer

El siguiente artículo es una traducción directa del original “How it feels to learn JavaScript in 2016”, por Jose Aguinaga, publicado inicialmente en Hackernoon el 3 de octubre de 2016. El texto original puede encontrarse aquí.

Aprender Javascript en 2016

Durante la escritura de este artículo no se ha desarrollado ningún nuevo framework Javascript.

El texto que sigue ha sido inspirado por el artículo “It’s the future”, de Circle CI. Puedes leer el original aquí. Este fragmento es solo una opinión y, como cualquiera de los frameworks Javascript que tenemos ahí fuera, no debe tomarse demasiado en serio.

En algún lugar de cualquier ciudad moderna…

¡Buenas! Tengo un nuevo proyecto web en mente pero, para ser honestos, hace algunos años que no toco nada de código. He oído que la cosa ha cambiado un poco… Tú eres el desarrollador web más al día que hay por aquí, ¿no?

– El término actual es ingeniero frontend, pero sí, yo soy el chico correcto. Desarrollo para la web actual: gráficas, reproductores de música, drones que juegan al fútbol, ​​lo que quieras. Acabo de volver del JsConf y del ReactConf, por lo que conozco las últimas tecnologías para crear aplicaciones web.

Genial. Necesito crear una página que muestre los últimos registros de mis usuarios, por lo que solo tendría que coger los datos de un servicio REST y pintarlos en algún tipo de tabla con sus filtros y mecanismos para ordenar campos. Querría también que la tabla se actualice automáticamente si algún dato cambia en el servidor. Estaba pensando que quizá podría utilizar jQuery para traerme los datos y pintarlos, ¿qué te parece?

– Oh dios mio, no… nadie usa jQuery en 2016. Deberías echarle un ojo a React.

Ah, perfecto. ¿Qué es React?

– Es una biblioteca super puntera desarrollada por algunos chicos de Facebook. La gracia está en que permite manejar cualquier cambio en las vistas de una manera sencilla y eficiente.

Suena muy bien. ¿Puedo entonces usar React para pintar los datos que me llegan desde el servidor?

– Por supuesto, pero primero necesitas añadir al proyecto tanto la biblioteca de React como la de React DOM.

Un segundo, ¿por qué dos bibliotecas?

– Porque una es la biblioteca base mientras que la segunda, es una especializada en manipular el DOM usando JSX.

¿JSX? ¿Qué es JSX?

– JSX es solo una extensión de la sintaxis Javascript muy parecida a XML. Es como una manera alternativa de describir el DOM, mucho mejor que HTML.

¿Qué problema hay con HTML?

– Estamos en 2016. Nadie trabaja ya directamente con HTML.

De acuerdo… De cualquier modo, ¿si añado esas dos bibliotecas ya puedo utilizar React?

– No del todo. Necesitarías también añadir Babel para poder utilizar React.

¿Otra biblioteca? ¿Qué es Babel?

– Oh, Babel es un ‘transpiler’ que nos permite fijar una versión de Javascript mientras que programamos en cualquier versión del lenguaje más reciente. Realmente, no TIENES que incluir Babel para usar ReactJS, pero si no lo haces, te verás obligado a utilizar solo ES5… Y siendo prácticos, es 2016 y deberías programar en ES2016+, como hace el resto de la comunidad.

¿ES5? ¿ES2016+? Creo que me he perdido aquí… ¿Qué son ES5 y ES2016+?

– ES5 viene de ECMAScript 5. Es la edición sobre la que todos trabajamos porque es la que implementan la mayoría de navegadores actuales.

¿ECMAScript?

– Sí, ya sabes… El estándar Javascript se fijó en 1999 después de su lanzamiento inicial allá por 1995 cuando se llamaba Livescript y solo funcionaba en el navegador Netscape. Fueron tiempos complicados… Afortunadamente, desde entonces, las cosas se han ido regulando y hoy contamos con unas 7 ediciones de esta implementación.

7 ediciones… ¿Y ES5 y ES2016+ son…?

– La quinta y séptima edición respectivamente.

Un segundo, ¿y que pasó con la sexta?

– ¿Te refieres a ES6? Sí, me explico: cada edición es una revisión expandida de la anterior, por lo que si usas ES2016+, realmente estás usando todas las funcionalidades de las versiones previas.

Ah, vale… ¿Y por qué usamos entonces ES2016+ en lugar de ES6?

– Bueno; tu PODRÍAS usar ES6, pero estarías desaprovechando todas las mejoras de ES2016+ como son el async y el await. Eso quiere decir que si nos quedamos con ES6, nos podríamos utilizar las co rutinas para bloquear llamadas asíncronas y modificar un flujo de control.

No tengo ni la más remota idea de qué significa eso último. Todos estos nombres son muy confusos. Mira, solo necesito leer algunos datos desde el servidor. Yo solía incluir jQuery desde un CDN y obtener esos datos mediante peticiones AJAX. ¿No puedo limitarme a eso?

– Es 2016 hombre… nadie utiliza jQuery. Eso siempre acaba con una maraña de código tipo espagueti. Todo el mundo sabe eso.

Es verdad… Así que mi alternativa es cargar 3 bibliotecas para coger esos datos y mostrarlos en una tabla HTML, ¿no?

– Bueno; tu incluyes esas tres bibliotecas, pero las empaquetas después con un gestor de módulos para terminar cargando un único fichero.

Ah, ya veo. ¿Y qué es un gestor de módulos?

– La definición depende del entorno, pero en web, habitualmente nos referimos a cualquier cosa que soporte módulos AMD o CommonJS.

Biiiien. ¿Y AMD y CommonJS son…?

– Definiciones. Hay varias formas de describir cómo varias bibliotecas Javascript y sus clases deberían interactuar. Ya sabes… ¿exportar e importar? Puedes escribir múltiples ficheros Javascript siguiendo la API AMD o CommonJS para luego, utilizando algo como Browserify, empaquetarlo todo junto.

OK, eso tiene sentido… creo. ¿Qué es Browserify?

– Es una herramienta que nos permite empaquetar las dependencias descritas en CommonJS en ficheros que puede cargar un navegador. Esto lo hacemos porque la mayoría publican estas dependencias en el registro npm.

¿Registro npm?

– Es un repositorio público gigantesco donde la gente inteligente sube sus códigos y dependencias en forma de módulos.

¿Cómo un CDN?

– No exactamente. Es más como una base de datos centralizada donde cualquiera puede publicar y descargar bibliotecas. Se puede utilizar de forma local durante un desarrollo y subir luego los módulos a un CDN si eso te gusta más.

Ah, ¡como Bower!

– Sí… pero estamos en 2016. Bower está bien muerto.

Vaya… entonces ahora necesito descargar las bibliotecas desde npm.

– Sí. Por ejemplo, si quieres usar React, te descargas el módulo React y lo importas en tú código. Haces lo mismo con casi cualquier biblioteca Javascript popular.

Oh, ¡como Angular!

– Angular es de… ¿2015?. Pero sí… Seguramente Angular esté allí, junto a VueJS, RxJS y otras bibliotecas punteras de 2016. ¿Quieres que te hable de ellas?

Estoy aprendiendo demasiadas cosas de golpe, vamos a centrarnos en React… En resumen, si quiero usar React, tengo que coger su módulo desde el npm y empaquetarlo luego todo con Browserify, ¿no?

– Sí.

Parece un proceso algo complicado… tenemos que coger primero las dependencias y juntarlas después todas en un único fichero.

– Sí, es complicado… por eso hay que utilizar un gestor de tareas como Grunt, Gulp o Broccoli para automarizar el proceso. Puede que te vaya bien con Mimosa…

¿Grunt? ¿Gulp? ¿Broccoli? ¿Mimosa? ¿De qué diablos estamos hablando ahora?

– Gestores de tareas. Aunque la verdad es que ya no están de moda… Los usábamos en 2015… Luego nos pasamos a Makefiles, pero ahora agrupamos todo con WebPack.

¿Makefiles? Yo pensaba que eso era de C o C++…

– Sí, pero aparentemente nos encanta complicarnos la vida en la web. Más o menos, una vez al año, volvemos a una tecnología básica de toda la vida… De hecho, si esperamos un poco, en uno o dos años estaremos todos programando web en ensamblador.

Qué cosas… Por cierto, ¿has mencionado antes algo llamado WebPack?

– Es otro gestor de módulos para el navegador que también puede funcionar como un lanzador de tareas. Es como una versión mejorada de Browserify.

Ah, perfecto. ¿En qué lo mejora?

– Bueno… quizá no sea necesariamente mejor. Solo resulta más estricto a la hora de definir cómo se empaquetan las dependencias. WebPack permite utilizar diferentes gestores de módulos no limitándose únicamente a los de tipo CommonJS. Por ejemplo, soporta los módulos nativos de ES6.

La verdad es que estoy algo perdido con todo eso de CommonJS y ES6…

– Todo el mundo lo está, pero no tienes que preocuparte demasiado porque ahora estamos empezando a usar SystemJS.

La Virgen… otra cosa más. De acuerdo, ¿qué es ese SystemJS?

– A diferencia de Browserify y WebPack 1.x, SystemJS es un cargador de módulos dinámico que permite unir varios módulos en varios ficheros diferentes en lugar de hacerlo en uno único.

Pero, tenía entendido que era mejor tenerlo todo en un único fichero grande…

– Sí, pero eso era antes. Ahora, con HTTP/2 a la vuelta de la esquina, es mejor hacer varias peticiones pequeñas HTTP que una sola de mayor tamaño.

Genial; ¿no podríamos entonces simplemente añadir nuestras tres bibliotecas para React sin utilizar nada más?

– La verdad es que no. Verás, se podría añadir cada una desde un CDN por ejemplo, pero aún así, todavía necesitas incluir Babel.

Ah, cierto. ¿Y cuál sería entonces el problema?

– Pues que de hacerlo así, tendrías que incluir el núcleo completo de Babel, y eso no es eficiente para un entorno de producción. En producción, necesitas realizar una serie de pre tareas para preparar tu proyecto que hacen del ritual de invocar a Satán algo similar a hervir unos huevos en un cazo: tienes que minificar las dependencias, re formatearlas, crear reglas en línea para el CSS crítico, delegar la carga de los scripts, además de…

Vale, vale, lo pillo… Así que no queremos incluir las bibliotecas directamente desde un CDN. ¿Cómo lo harías tú entonces?

– Yo utilizaría un ‘transpiler’ a partir de Typescript usando una combinación de Webpack + SystemJS + Babel.

¿Typescript? ¡Pensaba que estábamos programando en Javascript!

– Typescript es Javascript, o mejor dicho, un meta conjunto de Javascript, más específicamente de la versión ES6. Ya sabes, la sexta versión que mencionamos hace un rato…

¡Pero pensaba que ES2016+ era ya un meta conjunto de ES6! ¿POR QUÉ necesitamos ahora esa cosa del Typescript?

– Ah, porque nos permite utilizar Javascript como si fuera un lenguaje tipado, reduciendo los errores en tiempo de ejecución. Es 2016, y todos deberíamos añadir algunos tipos a nuestro código…

Y Typescript, obviamente, hace eso…

– Sí, igual que Flow, aunque éste solo comprueba el tipado mientras que Typescript es un meta lenguaje de Javascript que necesita ser compilado.

Diablos… ¿y Flow es?

– Es un validador de tipos estáticos desarrollado por algunos chicos de Facebook. Lo han programado en OCaml… ¡la programación funcional es increíble!

¿OCaml? ¿Programación funcional?

– Es la moda más puntera a día de hoy. Ya sabes: programación funcional, funciones de orden superior, currying, funciones puras…

Ni idea de qué me estás hablando…

– Bueno, nadie la tiene al principio. Mira, solo tienes que saber que la programación funcional es superior a la POO, y es el paradigma a utilizar ahora en 2016.

Pero, yo aprendí POO en la Universidad… ¡pensaba que era la metodología más eficiente!

– Sí, pero solo hasta que Java fue adquirida por Oracle… Quiero decir que la POO estuvo bien hace tiempo, y todavía se puede encontrar en algún proyecto a día de hoy… pero actualmente, todo el mundo coincide en que modificar estados es similar a ir por ahí pateando bebés, por lo que ahora la comunidad se ha mudado a la programación funcional y a sus objetos inmutables. Los chicos de Haskell lo han estado proclamando a los cuatro vientos desde hace años, y ni hablemos de los de Elm… afortunadamente, ahora tenemos bibliotecas como Ramda que nos permiten utilizar la programación funcional en Javascript plano.

¿Estás dejando caer nombre tras nombre solo para volverme loco? ¿Qué demonios es Ramnda?

– No, Ramda. Como Lambda. Ya sabes, la biblioteca de David Chambers…

¿Qué David?

– David Chambers. Un tío fantástico y uno de los responsables de Ramda. Deberías echarle un vistazo también al trabajo de Erik Meijer si estás interesado en todo esto de la programación funcional.

¿Y Erik Meijer es…?

– Otro experto en programación funcional. Un máquina en el tema. Tiene un montón de presentaciones donde aparece con esas horribles camisetas estampadas atacando al mundo Agile… También deberías conocer el trabajo de gente como Tj, Jash Kenas, Sindre Sorhus, Paul Irish o Addy Osmani.

Vale, tenemos que parar esto. Todo suena muy bien, y estará correcto, pero creo que es exageradamente complicado e innecesario para mi idea inicial. Solo necesito coger datos desde el servidor y mostrarlos. Estoy seguro de que no necesito conocer a toda esta buena gente y aprenderlo todo para montar una tabla con datos dinámicos. Vamos a volver a React… ¿cómo puedo traerme los datos desde el servidor con React?

– Bien… actualmente React no sirve para traerse datos, solo para pintarlos.

Maldición… Bueno, ¿entonces qué necesitamos para traernos los datos?

– Lo habitual es utilizar Fetch para eso.

¿Así que necesitar algo llamado Fetch para coger los datos? Quienquiera que esté poniéndole nombres a estas cosas necesitaría un buen diccionario de sinónimos…

– Bueno, Fetch es el nombre de una implementación nativa para realizar peticiones XMLHttpRequests.

Ah, como AJAX.

– AJAX es solo el uso de XMLHttpRequest… pero sí. Fetch nos permite hacer AJAX basado en promesas. Eso elimina el problema de la pirámide de callbacks del infierno.

¿La pirámide del infierno?

– Sí… cada vez que realizas una petición asíncrona al servidor, tienes que esperar la respuesta, lo cual requiere de añadir alguna función dentro de otra. Eso, al final, termina generando lo que llamamos ‘Pirámide del Infierno’.

Ah, sí… me suena. ¿Y esa promesa resuelve el asunto?

– Exactamente. Manipulando las callbacks a través de promesas, podemos escribir un código mucho más asequible y sencillo. También nos permite crear mocks, testearlos e, incluso, realizar varias peticiones simultáneas y esperar a que todas ellas hayan cargado.

¿Y eso se puede hacer con Fetch?

– Sí, pero solo si tus usuarios utilizan un navegador moderno; de otro modo, necesitas incluir un pollyfill de Fetch, o usar Request, Bluebird o Axios.

Por el amor de Dios, ¿cuántas bibliotecas necesito conocer? ¿Cuántas hay?

– Es Javascript… Debe haber como miles de bibliotecas que hacen exactamente lo mismo. De hecho, lo que tenemos que conocer son solo los nombres de las mejores. Pero vamos… sí: son muuuuuuchas, e incluso a veces, añadimos en ellas alguna imagen de Guy Fieri…

¿Acabas de mencionar a Guy Fieri? ¿El restaurador, autor, presentador, comediante y celebrity? Pasemos del tema… ¿Qué hacen estas Bluebird, Request o Axios?

– Son bibliotecas para realizar peticiones XMLHttpRequest basadas en promesas.

¿El método AJAX de jQuery no devolvía promesas también?

– No usamos ninguna palabra que empiece por ‘J’ en 2016. Limítate a Fetch y su polyfill cuando el usuario no lo soporte. O Bluebird, Request o Axios en su lugar. Luego, solo tienes que gestionar la promesa con await dentro de una función asíncrona y ¡boom!, tienes control total del flujo.

Es la tercera vez que mencionas eso de ‘await’, pero no tengo ni idea de qué es.

await nos permite bloquear una petición asíncrona. Eso mejora el control sobre cuándo recibimos los datos y aumenta la legibilidad general del código. Es realmente increíble, solo tenemos que asegurarnos de añadir las reglas ‘stage-3’ a Babel, o usar algún plugin de ‘syntax-async-functions’ y ‘transform-async-to-generator’.

Esto es una locura.

– No, la locura es tener que precompilar el código Typescript para luego pasarle Babel y así, poder usar await.

¿Ein? ¿Pero es que eso no está incluido en Typescript?

– Lo estará en la próxima versión, pero actualmente solo funciona con ES6, por lo que si queremos usar await en el navegador, primero tenemos que compilar el código Typescript en ES6 y luego pasarlo a ES5 con Babel.

La verdad es que llegados a este punto no sé qué decir…

– Bueno; es fácil. Se programa todo en Typescript. Todos los módulos que utilizan Fetch, se compilan a ES6; luego, se utiliza Babel con las reglas ‘stage-3’ para convertirlos en ES5 y los cargamos con SystemJS. Si nuestros usuarios no tienen Fetch, entonces tenemos que utilizar el polyfill, Bluebird, Request o Axios. Por último, todas las promesas las manejamos con await.

Tenemos un concepto diferente de lo que significa ‘fácil’. Entonces, después de todo ese ritual, ¿podemos finalmente traernos los datos del servidor y mostrarlos con React?

– ¿Va tu aplicación a manejar cambios de estado?

Eh… creo que no. Solo necesito pintar los datos.

– Oh, gracias a Dios. De lo contrario, tendría que explicarte Flux y sus implementaciones como Flummox, Alt, Fluxible… Aunque, para ser honestos, deberías utilizar Redux.

Creo que voy a pasar de todos esos nombres… Te repito que solo necesito pintar los datos.

– Perfecto; si solo quieres eso realmente no necesitas React. Irías sobrado con un motor de plantillas.

¿Me estás tomando el pelo? ¿Esto te parece divertido? ¿Así es como tratas a la gente que quieres?

– Solo te he explicado qué deberías utilizar…

Para for favor; ahora mismo.

– Quiero decir… incluso aunque uses un sistema de plantillas, yo seguiría con la combinación Typescript + SystemJS + Babel si fuera tú.

Solo necesito mostrar datos en una página, no realizar el fatality original de Sub Zero. Solo dime qué sistema de plantillas necesito y lo retomamos desde ahí.

– Hay muchos… ¿cuál te resulta familiar?

Ummm… no recuerdo los nombres. Hace tiempo que no uso esas herramientas.

– ¿jTemplates? ¿jQote? ¿PURE?

No me suenan… ¿Algún otro?

– ¿Transparency? ¿JSRender? ¿MarkupJS? ¿KnockoutJS? Ese último es de tipo ‘two-way binding’.

¿Otro?

– ¿PlatesJS? ¿jQuery-tmpl? ¿Handlebars? Algunos todavía usan este…

Quizá… ¿Hay alguno más similar a ese último?

– ¿Mustache? ¿Underscore? Creo que hasta Lodash tiene uno… pero son todos herramientas del 2014 o así.

Mmmm… me quiere sonar algo, pero quizá sea más reciente…

– ¿Jade? ¿DustJS?

No.

– ¿DotJS? ¿EJS?

No.

– ¿Nunjucks? ¿ECT?

No.

– No sé… nadie a día de hoy usaría CoffeeScript… ¿Jade?

No… ya habías mencionado antes Jade.

– Quería decir Pug… no, Jade… la cuestión es que Jade ahora se llama Pug.

Pues no… no me acuerdo. ¿Cuál usarías tú?

– Pues, seguramente… usaría el sistema de plantillas nativo de ES6.

Y, por supuesto, necesitamos entonces ES6.

– ¡Correcto!

Entonces, dependiendo del navegador que esté usando, también necesitaré Babel…

– Exacto.

Y, si quiero incluirlo sin tener que añadir la biblioteca completa, necesito cargarlo como un módulo desde el npm.

– Eso es.

Y eso nos lleva a necesitar de Browserify, Webpack o -incluso mejor- SystemJS.

– Ahí lo tienes.

Y, a no ser que estemos usando WebPack, necesitaremos automatizarlo todo con un gestor de tareas.

– Lo has pillado.

Pero, como ahora se lleva eso de la programación funcional y los lenguajes tipados, necesitamos pre compilar primero Typescript o añadir ese Flow.

– Justo.

Y luego, enviar el resultado a Babel para poder disponer de ‘await’.

– Estás ‘on-fire’.

De este modo, podemos utilizar Fetch, promesas, control de flujo, y toda esa magia…

– No te olvides de incluir el polyfill de Fetch en caso de que no lo soportemos. Safari todavía no lo maneja.

¿Sabes qué? Creo que lo tengo todo… Una idea general del mundo web, y todo Javascript de paso.

– Eso está genial. En unos años, sin embargo, estaremos todos programando en Elm o WebAssembly.

Me vuelvo al backend. Simplemente, no puedo con todos estos cambios, y versiones, y ediciones, y compiladores, y ‘transpilers’. La comunidad Javascript se ha vuelto completamente loca si piensa que alguien puede manejar todo esto.

– Te entiendo. Deberías echarle un ojo a la comunidad de Python entonces…

¿Por qué?
– ¿No has oído nada sobre Python 3?

Bonus

El texto anterior, ya de por sí magnífico, ha removido de forma innegable las arenas de la comunidad. Al artículo original no le faltaron un gran número de comentarios y foros externos donde aún hoy se continúa discutiendo sus implicaciones.

A modo de corolario, quería traer el comentario realizado por uno de los pesos pesados en el mundo del desarrollo actual (citado por cierto en el mismo texto) como es Addy Osmani:

Addy Osmani, destacado miembro de la comunidad Javascript; ingeniero Google y miembro del Chrome Team.

Entiendo perfectamente tu frustración 🙂

Animo a todos aquellos que quieran estar al día con el ecosistema Javascript a que sigan estos tres simples consejos: primero, hazlo; luego, hazlo bien; entonces, hazlo mejor.

Primero, hazlo

Coge aire y conciénciate de que eres totalmente nuevo en este mundillo. Es perfectamente razonable no utilizarlo todo. De hecho, es mejor así. Piensa en un simple prototipo que sirva para cumplir tu propósito: no hay nada malo en utilizar como base HMTL/CSS/JS.

Por lo general, no solemos tener en cuenta que cualquier tema nuevo requiere de un tiempo de aprendizaje y experimentación para dominarlo. Los principiantes no deben agobiarse por utilizar la biblioteca más puntera o el patrón reactivo de la semana. A mí, me tomó varias semanas el comprender correctamente Babel y React. Bastante más el hacerme con IsomorphicJS, Webpack y todas esas bibliotecas que hay alrededor. Preocúpate de empezar por lo más sencillo.

Entonces, hazlo bien

Itera: mejora todo aquello que ya hayas conseguido. ¿Ves algún problema que aún tienes que resolver? Tal vez puedas apoyarte en alguna biblioteca o módulo para ello. No hay ninguna razón para plantearse el reescribir un proyecto en otro lenguaje o framework sin tener la certeza de que eso te permitirá continuar con las necesidades que te has fijado. Todo aquello que añadas al proyecto tiene que aportar algún valor. Si en lugar de eso, estás complicando las cosas, o haciéndolo el trabajo más difícil a tu equipo, no vale la pena continuar por ahí.

Finalmente, hazlo mejor

Domina tus herramientas. Una vez que te encuentres cómodo navegando por las aguas de herramientas y bibliotecas, sabrás cómo añadir valor a tu flujo de trabajo. Encontrarás que incluir todas esas cosillas aprendidas, ‘tiene sentido’. Yo, por ejemplo, me encuentro ahora utilizando a fondo unas 9 o 10 herramientas diferentes en mi proyecto… pero he aprendido lo suficiente de ellas como para evitar caer aquellos aspectos de cada una que me exijan tiempo resolverlas. Yo nunca sugeriría a un principiante usar la mayoría de cosas que aparecen en el artículo. Serían una receta segura para pasarlo realmente mal. En lugar de eso, de nuevo, recurre a lo más básico. Ve poco a poco familiarizándote con el ecosistema; busca aquello que gradualmente añada valor y te haga más efectivo.

También es importante recalcar que todos, incluidos aquellos programadores que escriben las herramientas mencionadas aquí, pasan por los mismos estadios de frustración y fatiga durante el aprendizaje y puesta a punto de esto que llamamos Javascript moderno. Me gustaría animar a los programadores a recordar que todos estamos en el mismo barco, y que nuestras herramientas están aquí para ayudarnos. Si no lo están haciendo, entonces tenemos que deshacernos de ellas 🙂

Sobre la traducción

Por lo general, siempre he defendido el uso de términos castellanos para todo aquello que tiene que ver con la programación: considero que nuestro idioma dispone de un vocabulario lo suficientemente vasto como para no estar recurriendo continuamente a los palabros anglosajones.

Sin embargo, durante la traducción de este artículo, me he permitido respetar algunos de los términos originales, bien sea porque no tienen una traducción directa al español, o bien porque ésta, al ser muy forzada, desdibuja la idea original del autor. Es por lo anterior que podemos encontrar palabras como transpilers, polyfill y similares.

Más:

{11} Comentarios.

  1. Charly

    Toda la razón. 10/10.

  2. Angel

    Muchas gracias por el esfuerzo de traducir este interesante artículo

  3. Carlos Salas

    Muchas gracias por el esfuerzo, la verdad actualmente me siento así, estube aprendiendo Javascript con Node.JS para querer montar una pequeña página mientras aprendía, al inicio iba todo bien creando modulos, pero conforme querías realizar algo más completo, te encontrabas con un sin número de librerías y frameworks que adoptar. Que al final termine desplazandoe a seguir aprendiendo Backend haciendo uso de jQuery para manejar el DoM y el Ajax ya que no soy muy de front-end pero personalmente me gusta dejar un acabado bonito y presentable en un producto final. Quizá después aprenda Angular-2 o Vue.js cuando me sienta completamente seguro y confiado en mis capacidades de BackEnd y así mejorar un poco en FrontEnd. Ojala algún día la comunidad se ponga de acuerdo en facilitar este mundillo, porque se está volviendo un verdadero caos.

  4. Alcides

    Simplemente de fábula. ¡Excelente artículo!

  5. Om

    Muy buena lectura, gracias por traducirla y compartirla

  6. Repli

    Me has obligado a realizar ciertas búsquedas.
    Mientras tanto, me atengo al original javascript, ampliamente soportado, y que, con algunas dificultades, me permite realizar todo lo que quiero. Si no me subí al carro de jQuery en su día, hoy menos aún.

  7. Orlando

    Excelente artículo.
    Hice backend cuando se llamaba “webmaster” y lo dejé un tiempo. Ahora volví con front-end y son miles de cosas que aparecen y todo el mundo habla pestes de jquery por ser “viejo” y mencionan todos los términos que salen en el artículo y me perdia cuando tenía que aplicar uno u otro.

    Voy a imprimir esto porque está genial!!!

  8. felipetiza

    “– Bien… actualmente React no sirve para traerse datos, solo para pintarlos.”

    5 minutos explicándole de todo menos lo imprescindible. He llegado a esta línea y no sabes como me he reido xD

  9. HF

    jejejeje :\

  10. Juan Suarez

    Felicidades gracias, excelente articulo. Y muy bien con la opion del experto. Gracias por compartir. 🙂

  11. Jonathan

    Genial! Excelente articulo estoy empezando con JavaScript y me parece de locos,vengo del back-end,pero me ha aclarado mi duda que deberia de aprender primero y cosas así,aparte que me he partido a risas ,por que estoy en la misma situacion que el que tenia la duda jajajaajjajaja

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *