La ‘nueva’ selva del desarrollador web…
Hace unos dias un amigo y compañero de trabajo me mando estos dos links:
https://circleci.com/blog/its-the-future/
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.d7baby1h2
Son dos parodias de dialogos ficticios entre dos desarrolladores hablando de que
tecnología usar para realizar un desarrollo o aplicativo Web. Se hacen largas, pero te dan una idea de como esta la industria del desarrollo web.
Me siento bastante identificado, porque ultimamente han surgido multitud de tecnologías de desarrollo web, algunas son muy buenas ideas, algunas rompen con la forma actual de hacer las cosas, pero otras son ‘raras’, reinventan la rueda o se pasan de rosca.
La mayoria son inestables, de forma que de una versión a otra, suelen cambiar tanto que la compatibilidad hacia atras brilla por su ausencia. Y no se aclaran en decidir que es una clase, un modelo, una ijection, un include o lo que sea…
Algunas vienen esponsorizadas por grandes empresas: la API de los programadores de Facebook, la que usa Google en la intimdad, la preferida de Tweeter, etc.
Muchas de ellas se basan en frameworks o tecnologías que ya existian añadiendo una capa intermedia con la idea de hacer el interfaz más amigable, pero que suelen resultar en un más de lo mismo…pero con una capa en medio.
Otras tantas suponen meter un include de varias decenas (o más) de kbs para acabar usando una funcioncita o dos…matar mosquitos a cañonazos?
La tendencia actual, al parecer es volver a las consolas, el interfaz de comandos, ahora lo que ‘mola’ es instalar cosas a golpe de instrucción desde un prompt, hasta tal punto que he visto como algunos se han instalado en su Windows o Apple un SW que emula una consola de Unix, que permite instalar paquetes ‘Unix-style’ y desde esta ventanita en modo texto sobre un flamante escrtorio gráfico de última generación, lanza comandos al estilo ‘hacker’ para instalar ‘packages’, ‘dependencies’, etc. Raro?
Y lo que me parece más duro, algunas implican usar un dialecto de Javascript que debe ser interpretado o compilado en Javascript ‘de toda la vida’, en cada ejecución o prueba… buf!
Sea como sea, me pierdo entre tanta novedad, nombrecitos, siglas, acrónimos, versiones y dependencias, npms, nodes.js, angular 2.0, RESTful APIs, moment.js, Cygwins, Typescript, JSX y tal.
Bueno, la cosa es adaptarse, y esperar cual de estos nuevos paradigmas se estabiliza, se hace ‘potable’ y se convierte en referencia. Mientras tanto, cada vez que me toca comenzar un nuevo proyecto, tiemblo de pensar que lo que hice anteriormente dificilmente va a ser reutilizable si me cambian la tecnología o la versión…:-(
Professor Associat del DLSI
Que razón tienes Jaume. Yo ya no me levanto pensado si comer galletas o cereales. Solo pienso utilizo PHP, le pongo un poco de Java y luego me tomo un zumo javascript o me pido un chuletón de node.js con una ración de python y un postre de C# con virutas Angular.
Un sin vivir. Pero es lo que tenemos y esperate que todavía no se han metido a fondo con la IoT.
Saludos y gracias por el artículo.
A mi esto de las librerías, más que una ayuda, me parece un cáncer. Resulta que cuando te aprendes todo el JavaScript, te aparece una nueva librería y te tienes que volver a aprender la forma que tiene la librería de acceder a su API, para acabar haciendo lo que ya sabes hacer más que de sobra utilizando simple JavaScript. Y esto no sólo lo tienes que hacer una vez, sino muchas, pues cada vez aparecen más y más ‘soluciones’. Me parece que en vez de ganar tiempo, se pierde. Ni decir cuando te vienen con un ’embolado’ de aplicación hecha con una librería de estas, y tienes que aprender chino para descifrar lo que hace el código, cuando si estuviese escrito en JavaScript normal, verías el error en segundos. Y para terminar, en vez de poder crear una aplicación independiente que una vez hecha funcionará durante años, ahora tienes que estar preocupándote de añadir la ultima actualización de las librerías que añadiste, esperando eso si, que un día esa librería ‘no cierre el kiosko’ y te quedes con un montón de código inútil.
El HTML5 se creó para facilitar la vida a los programadores que hemos estado peleando durante años para que nuestros códigos fuesen compatibles. Ahora aparecen las librerías a enlodazar de nuevo el territorio, no nos ha dado tiempo ni de respirar y ya aparecen ‘los solucionadores’ que lo complican todo sobremanera.
Entiendo que una librería de estas está bien para alguien que no tiene mucha idea de JavaScript y puede hacer de manera sencilla cosas que requerirían bastante código y dominar el lenguaje. Pero que estas librerías las utilicen pretendidas empresas de software, es muy cutre. Una empresa debe tener sus propias librerías y las deben haber creado ellos, lo demás huele a aficionado.