EDICIóN GENERAL

Programadores antiguos vs programadores de hoy

La complejidad, tamaño, necesidades de escalabilidad, la cambiabilidad del entorno (SO, Libs, Drivers, Hardware)... no tienen nada que ver con las que había antes. LAs App de antaño son juguetes en entornos ultraestables en comparación con las actuales que han de ofrecer una resiliencia infinitamente mayor.

#3 Estoy en completo desacuerdo. Cualquier aplicación medianamente compleja hoy en día se hará con un Framework (o como algunos se denominan ahora "MicroFrameworks") , sea este público o inhouse, pero un Framework al fin y al cabo (de hecho serán muchas veces varios si hay microservicios).

El problema, aunque prefiero verlo como la causa, es que las aplicaciones de hoy son monstruosamente grandes, han de ser altamente escalables y lo más mantenibles que se puedan hacer, todo estoy limitados por el tamaño de los equipos que no puede irse de madre.

Otro debate que sí me parece más interesante y realista es el de buen Framework vs mal Framework, que si creo que limita lo optimizada que pueda estar la aplicación.

El objetivo de un framework es ofrecerte un entorno en el que los problemas que tiene el 90% de las aplicaciones ya estén resueltos y dónde puedas conectar las partes que resuelven los casos de tu negocio.

Un buen framework te ofrecerá formas de limitar su aparición a la capa más externa de tu proyecto (ej: capa HTTP, Manejo del DOM, Routing...) un mal framework te obligará a hacer las cosas de una manera e infectará tu aplicación hasta lo más profundo.

Un buen framework te ofrecerá modularidad y posibilidad de no incluir el código que no necesites (ej: Tree Shaking).

Un buen framework te ofrecerá una IoC atractiva porque tiene unas interfaces solidas y bien definidas, además de un buen sistema de inyección de dependencias permitiendo que tu codigo esté libre de detalles de implementación (lenguaje, frameworks y libs es lo que son, detalles de implementación).

Un buen framework se encargará de adaptarse a los cambios de esas capas de infrastructura (HTTP, Window API, APIs del lenguaje, libs de sistema) minimizando el impacto que pueda tener en tu aplicación. Esto hace precisamente que, si no es un proyecto de chinchinabo, puedas centrarte en lo que te hace viable: tu capa de negocio sin necesidad de decicar tanta cantidad de esfuerzo a todas esas capas externas y comunes a todas tus aplicaciones (seguridad incluida).

También podríamos hablar de como se usan en muchas ocasiones los Frameworks, que algunas personas no terminan de entender que NO son librerías.

#6 Pero el problema ahí es de análisis y diseño de la solución, no el framework en sí, el problema es de quien decide que ese framework y ese lenguaje son los correctos para dar solución a determinado problema. Es como si yo diseño un sistema de seguridad en aviones con Visual Basic, el problema no es el lenguaje, es la elección.

Si no se entiende que el lenguaje, el framework y en general toda la infrastructura es un detalle de implementación y que ha de ser elegido pensando en el producto a implementar... ningun framework o lenguaje serán buenos. Es como usar Java para un SO, mientras Java puede ser una buena elección para implementar Servicios SOAP, nunca lo será para implementar un SO, pero el problema no será Java, será de quien lo eligió para implementar esa solución.

De todas formas siempre hay excepciones y creo VS Code, no parece siquiera Electron, me sorprendé muy gratamente siempre que lo uso.

menéame