Frameworks de Desarrollo – Día 60

Alfin ya casi al día con mis articulos de opinion, hoy hablare resumidamente de los frameworks de desarrollo, va a ser generalizando y quiza luego hago articulos por separado de cada uno de los que uso o conozco o quiero conocer.

Cuando yo era niño, yo decia que queria aprender a hacer todo desde 0, basicamente programacion desde ensamblador. Luego me di cuenta que no es tan sencillo, mi Papá trataba de explicarme sin exito, que se tiene que reutilizar en algun punto los constructos o las bases que ya existen en el conocimiento colectivo de la humanidad. Si bien yo lo pensaba como la construccion de un edificio, desde diseña, se cava, se construye, se refina y se entrega. Mi logica tenia fallas ¿Es que acaso Los ingenieros civiles? construyen su maquinaria, pican la piedra y la vuelven cemento, generan su propio acero/hierro, generan su propia pintura, etc. No, no lo hacen.

Esto realmente lo entendi muchos años despues, en mi busqueda por hacer todo desde 0, lo mas lejos que llegue fue a crear mi propio muy rudimentario procesador con compuertas logicas en un protoboard. Bueno como 4 protoboards conectados entre ellos. Y a duras penas podia recibir ciertas interrupciones y hacer algunos calculos.

Espero mi historia personal de un buen inicio a la lectura. Los frameworks son precisamente todo ese conocimiento colectivo, para crear un flujo de trabajo (workflow) con ciertos fines, sobre una tecnologia y una plataforma.

Los frameworks permiten usa lenguajes de programacion, funciones preconstruidas, que funcionan sobre diferentes sistemas operativos y hardware.

Nos dan asistencia y sugerencias para trabajar de una forma especifica, pero no fuerzan a seguir una estructura mas alla de su configuracion inicial.

Esto es algo que se puede apreciar, si bien Javascript tiene cualquier cantidad de frameworks extendibles, cada uno tiene un paradigma que se debe seguir, pero se puede dentro del paradigma construir lo que queremos incluso cosas que vaya encontra del mismo.

En contraste otro caso es el de C/C++, que no tienen un ente regulador, mas bien tiene una gran recopilacion de funciones que se distribuyen en el mismo compilador. Pero no te dice ninguna restriccion mas alla de la que el lenguaje y el compilador entienden.

En el caso de un framework su limite es el paradigma y el contexto para que el framework haga lo que debe hacer, y en C su limite es el lenguaje mismo. En ensamblador el procesador y su juego de instrucciones son la limitante.

Todo este contexto es para entender que cada framework tiene sus usos y casos de exito para lo que fueron diseñados, incluyendo frameworks rivales, por ejemplo Angular, React, Vue , buscan resolver el mismo problema, cada uno a su estilo. Todos crean nuevos problemas, que hacen querer volver a Jquery o Javascript Vanilla


Hottake: Se que un purista no considera React un framework, pero para que funcione en un ambiente profesional, se tiene que complementar con un grupo de librerias de soporte, que todas juntas aparte de un dolor de cabeza, dan las mismas capacidades que los ‘frameworks’ por diccionario, asi que para este articulo es un framework)

¿Entonces como escogemos un buen framework y cual es mejor?

Bien hay algunas capacidades que son importantes, todos los frameworks y sus lenguajes les van a indicar, su flexibilidad, su comunidad, su familiaridad a cierto tipo de programacion, su presencia en el mercado. Pero si tienen que elegir un framework, busquen Estabilidad, Retrocompatibilidad, y Soporte.

Con eso yo personalmente descartaria Angular y React para un proyecto nuevo, cuando salieron eran lo mas popular, lo mas hot, pero cada par de años, agregan nuevas soluciones incompatibles con sus viejas soluciones. Al menos tienen un buen soporte ya que son hechos por compañias grandes.

En mi lista anterior eso nos dejaria con VueJS, pero hay nuevos frameworks como Svelte y viejos como Ember que podrian considerarse, buscando estabilidad y retrocompatibildad.

Hottake: Tambien se que Svelte introdujo Runes, pero no son tan incompatibles como otras tecnologias.

Lo ideal, tomen un framework para un proyecto, centrence en ellas, lleguen a esa etapa del ciclo de vida de ‘mantenimiento’ y no actualicen por lo mas nuevo a menos que su vida dependa de ello.

✓ Nuevo proyecto, momento de actualizar.

✓ Rehacer el viejo proyecto en la nueva tecnologia tambien.

𐄂 Mezclar version nueva y vieja a la vez