Las tecnologías modernas suelen fomentar la creatividad y las ganas de programar, a mí en lo particular me ha pasado, y considero que ha muchos otros más, con los frameworks modernos de javaScript.
Cada vez que Angular actualiza tus datos con el doble data binding, o cuando React actualiza tus componentes sólo con cambiar un dato del state, la creatividad se activa, las ideas de productos llegan y el conjunto de las tecnologías que usarás empieza a formarse en tu mente.
A esto responde que una de las dudas más populares que recibimos en CódigoFacilito es, qué framework debo usar o comentarios con ideas de apps que se harán con Angular, con React o incluso con Vue; la realidad es que, lo más probable es que no necesites ninguno.
El precio de tu stack
En la industria a la que pertenecemos, existen una infinidad de herramientas y alternativas, cada una de ellas con sus pros y sus contras, con sus fortalezas y sus casos de uso. Esto se traduce en que, para los productos más refinados y complejos, es conveniente tener una colección de herramientas extensa, cada una trabajando en aquello donde se fortalece.
No es un secreto que las grandes empresas y los productos más importantes, usan múltiples tecnologías para lograr su cometido, en Google por ejemplo, usan JAVA, Python, javaScript, Go, Git, Angular, Polymer, etc. También podríamos hacer mención del stack extenso en Facebook, en Airbnb, en Snapchat, o en cualquier empresa que puede darse el lujo de pagarlo.
Un stack de tecnologías tiene un costo, entre más reducidas sean las opciones, es más económico, entre más agregues a él, es más caro. La mayoría de los productos nuevos no pueden darse el lujo de pagar un stack extenso, esto quiere decir en muchas ocaciones, no se puede dar el lujo de pagar por React, Angular o el framework de tu preferencia.
Cómo afecta mi stack a los costos de desarrollo
Un stack diverso requiere de un equipo diverso, o de una inversión en dinero y tiempo para prepararte a ti y al equipo con el que cuentes.
Un producto con muchos recursos puede pagar un equipo de expertos en React, uno en Node, uno en Postgres, básicamente, uno por cada tecnología que forma parte de su stack. Uno con menos recursos, quizás pueda darse el lujo de contratar un experto por tecnología, en el caso de los equipos más pequeños, con menos recursos, no existen suficientes personas para cubrir de manera apropiada, cada uno de las tecnologías que forman parte del stack.
Los frameworks de javaScript ofrecen muchísimas ventajas, en muchos escenarios, particularmente si tu aplicación tiene alta interacción con datos o con el usuario, seguramente un framework hará su trabajo, sin embargo, es una tecnología más, no es magia, hay que dedicarle tiempo a escribir el código, probarlo, integrarlo con los otros componentes, etc.
De hecho, aunque es sabido que en beneficio del mantenimiento a futuro y la detección de bugs, es mejor fragmentar los sistemas en piezas menores con responsabilidades específicas, también esto tiene un impacto sobre el tiempo de desarrollo, que eventualmente se traduce en un impacto sobre el costo del mismo.
Cuando fragmentas un sistema, sigues escribiendo la misma funcionalidad que si desarrollas lo que conocemos como un monolito (una solución no fragmentada e integrada en una sola pieza), y adicionalmente, tienes que escribir la integración entre los componentes, probar que estén apropiadamente integrados y definir qué pasaría si uno deja de funcionar o deja de coordinarse. Todo lo anterior, claro está, implica trabajo.
En la mayoría de los casos, cuando te comprometes con un framework de javaScript, separas la funcionalidad del frontend con la del backend, haciendo que el backend únicamente sirva datos y el frontend los use para comunicarse con el usuario. Esto significa que, por lo menos, estás separando la funcionalidad en dos grandes bloques, con los compromisos que eso implica: comunicarlos, balancearlos, probarlos, etc.
El producto es más importante que las tecnologías
¿Suena obvio? No para muchos...
Can you imagine what kind of education you'd get from someone invoking "true computer scientist" and "true paradigms" in the same sentence? pic.twitter.com/YO5FwcOyOt
— DHH (@dhh) 7 de agosto de 2017
Este es una frase de Karen Panetta del IEEE, que independientemente de ser una crítica a Ruby, contiene una frase muy peculiar al final del "If you want to just get the job done, It's okay", traducido quiere decir "Para quienes sólo quieren dejar el trabajo listo, está bien" a lo que muchos usuarios en twitter respondieron con frases que aludían al hecho de que ellos sólo quieren tener el trabajo hecho, todas las veces.
Este es el mensaje inverso a un stack complejo y emocionante, uno simple que cumpla con el trabajo que te permita finalizar el proyecto.
Bootcamp Ciencia de Datos
12 semanas de formación intensiva en los conocimientos, fundamentos, y herramientas que necesitas para ser científico de datos
