Re: Antes y despúes

Hola. Antes que nada, que bueno ver a alguien de "aquella vieja guardia" por aca. Complementando tu analisis que me parece excelente, creo que hay que poner no solo el foco en la utilización de cada pieza de tecnología que usamos, sino también un para qué histórico: Históricamente la gran mayoría de los desarrolladores web (Al menos medidos por el número) evoluciona en su trabajo hasta un punto donde considera que "ya sabe" y no sigue evolucionando ni en cuanto a tecnología ni en cuanto a desafíos que buscan. Por eso es tan común la discusión por ejemplo acerca de si son útiles las matemáticas: Una vez me dijeron en un foro "Yo para centrar un div no necesito matemáticas y con eso gano un montón de dinero al año". Tu "depende para que" debe necesariamente incluir que quizás el 80% de los programadores sigan el hype tecnológico no por necesidad real, que implica un análisis puntual de las cosas que vas a hacer sino porque no se quieren "quedar a fuera del mercado". Todo ese mecanismo sociocultural termina en un código caro, con muchos recursos innecesarios, generalmente mal usados y muy difícil de mantener. Muchas veces con código que si fue escrito muy rápido (Lo cual es una obvia ventaja) porque utiliza en general soluciones ya standard para problemas de moda ... Que así queda! (Y que no resiste el avance de las bibliotecas que lo formaron, cualquiera de los presentes que halla tenido que actualizar un sitio hecho con Laravel o Angular de mas de cinco o seis años de hecho puede avalar lo que digo) La verdad toma muchos años de práctica formar a alguien que en serio pueda pasar verdaderamente rápido de una tecnología en otra y usarlas como corresponde. Ojala ahora estemos usando para eso la IA. Slds. Pablo. On Sun, Oct 19, 2025 at 1:14 PM Satyam <satyam@satyam.com.ar> wrote: > > On 10/19/25 08:33, Narcis Garcia wrote: > > El 19/10/25 a les 6:30, Alma Guevara Castro ha escrit: > > > *Fuente: Naiker.codes* > /"Cada día tengo más claro que hemos complicado demasiado algo que antes > era sencillo. Programar una página web en PHP (sí, el de toda la vida) > sigue siendo, a día de hoy, una de las formas más rápidas, estables y > eficaces de levantar un proyecto funcional./ > /No hace falta un stack de 10 tecnologías ni un curso intensivo de > dependencias para mostrar datos en pantalla o conectar con una base de > datos. Pero parece que ahora todo tiene que pasar por React, Node, Webpack, > NPM, Typescript, Redux, Vite ... con el respeto que se merecen./ > /Y en muchos casos, no aporta valor real al usuario, solo complica el > desarrollo, la curva de aprendizaje y el mantenimiento. No se trata de > rechazar la innovación, sino de recordar que la tecnología debe > simplificar, no enredar. A veces lo más eficiente sigue siendo lo más > simple. /*/¡PHP vive!/*/"/ > > > Celebro la viñeta. > > ¿Qué factores podemos encontrar que han encaminado el desarrollo a este > problema? > ¿Componentes de terceros, gratuitos pero con ánimo de lucro? > ¿Pereza de escribir código? > ¿Uso de plantillas para el aspecto visual? > > Hola Narcis, interesantes preguntas. > > Creo que, como todo en la vida, la respuesta suele ser "depende". Es > obvio que PHP sigue siendo una alternativa muy válida, en las encuestas de > Stack Overflow muestran que todavía casi un 19% de quienes completaron la > encuesta usa PHP: > > https://survey.stackoverflow.co/2025/technology/#most-popular-technologies > . La encuesta muestra muchos lenguajes, muchos de ellos no necesariamente > relacionados con los desarrollos para WEB así que, excluyendo los que no > son aplicables, PHP no está tan mal ubicado. Pero, como decía, cuál > lenguaje usar "depende". > > JavaScript surgió para ofrecer interactividad del lado del cliente. Sin > JavaScript, Google Maps no existiría ni toda la familia de aplicaciones > on-line de Google: Mail, Docs, Sheets, Slides. > > Tampoco habrían existido utilitarios como JQuery que nos ofrecieron por > primera vez acceder a esas posibilidades de interacción que antes no > teníamos. Por ejemplo: > > - Validar campos de datos del lado del cliente (aunque, por seguridad, > debamos también hacerlo del lado del servidor). Nadie quiere hacer un > *submit* de un formulario de 100 campos para, después de unos > segundos, enterarse de que había un error en el segundo campo. > - Llenar un <select> basado en otro, por ejemplo, llenar el de > municipio en base a la provincia seleccionada. > - Activar o desactivar campos opcionales según otras opciones en el > formulario. > > Todo esto es posible hacerlo del lado del cliente en JavaScript sin que > haya necesidad de enviar todos los datos al servidor y esperar una > respuesta del mismo. > > La cosa creció, paso a paso, a partir de allí. Veamos algunas de las > tecnologías listadas más arriba. > > Era muy habitual programar en PHP en el servidor y JavaScript en el > cliente. NodeJS permitió que el mismo lenguaje se usara en ambos lados. > De pronto no fue necesario tener alguien en el equipo que supiera los > trucos de PHP y otro que supiera los trucos de JavaScript. Surgió también > la posibilidad de que el mismo código se usara en ambos lados. Por > ejemplo, una librería de validación de datos. Ya no era necesario tener > dos funciones en dos lenguajes distintos para validar, digamos, una fecha > esté entre ciertos límites, o que una cantidad sea positiva y menor a, > digamos, 1000. Las mismas funciones de JavaScript se podían usar en el > cliente y en el servidor. > > Al popularizarse muchos de estos 'paquetes' de funciones, apareció el NPM > que no es un lenguaje de programación sino un sitio de web > https://www.npmjs.com/ con una biblioteca de estos programas y > un > utilitario que permite bajar estos utilitarios e instalarlos en la máquina > del desarrollador en un lugar convenido donde NodeJS los pueda encontrar > con facilidad. > > WebPack, el veterano de los empaquetadores, surgió porque no es aceptable > transmitir enormes programas a través de líneas de comunicación de baja > velocidad. Para ello es importante 'minimizarlo'. Si nosotros enviamos > JQuery a nuestros clientes, lo hacemos con la versión minimizada, no el > fuente completo, que ocupa mucho más espacio. WebPack ofrece lo mismo para > nuestros programas. Pero, también ofrece mucho más. > > Por ejemplo, separar la aplicación en lo que llaman "chunks" (pedazos) de > tal manera que, por ejemplo, no se cargue cierta funcionalidad (por > ejemplo, validación de datos) en una página que no la necesita. La > aplicación, en lugar de ser monolítica se separa en "chunks" más pequeños > que se cargan bajo demanda. > > También ofrece "tree-shaking", literalmente "sacudir el árbol" esto es, > analizar el código fuente para ver cuáles funciones de las librerías > cargadas (gracias al NPM) se usan y cuales no. Lo del árbol viene a cuenta > de que las dependencias de unas funciones con otras se pueden diagramar > como un árbol donde a partir del punto de entrada principal de la > aplicación, la raíz del árbol, se desprenden las funciones que se usan y > las que esas funciones usan, formando así un árbol. Si se cargan varios > utilitarios, va a haber funciones que no se usan. Estas funciones quedan > desconectadas del árbol principal y, por ello, al "sacudir el árbol", estas > ramas se caen. > > Obviamente, nada de esto es necesario en un programa que se ejecuta en el > servidor, el intérprete de PHP tiene acceso directo a todos los recursos en > el servidor, pero cuando el código ha de enviarse a través de conexiones de > internet al cliente, que puede no tener un buen ancho de banda, reducir el > tamaño de lo que se transmite importa, y mucho. > > Vite es una versión más moderna del WebPack, mucho más eficiente y con > varias opciones extra. Nuevamente, al igual que NPM, o WebPack, Vite no es > un lenguaje de desarrollo, es un utilitario para facilitar el desarrollo. > Por ejemplo, le ofrece al desarrollador una suerte de mini-servidor de > donde probar la aplicación que está programando y, al detectar un cambio en > cualquier archivo, inmediatamente transmite el cambio al navegador y > efectúa los cambios sin que el desarrollador tenga que refrescar la > pantalla. Esto no se aplica sólo a JavaScript. Si un desarrollador está > trabajando con doble monitor, puede desarrollar en una pantalla y ver la > página de web en el otro. Si cambia un atributo de CSS en el fuente, que > puede ser en puro CSS, SASS, SCSS, LESS o tantos otros, verá el cambio en > el navegador de inmediato, habiéndolo convertido a puro CSS de ser > necesario. > > React/Redux es uno de tantos paquetes de manejo de la interfaz gráfica en > el cliente y los datos que muestra. Está perdiendo adeptos pues hay > actualmente opciones mucho más simples, compactas y, por ello más rápidas. > De la misma manera que tradicionalmente el JQuery nos salvaba de los > peligros de manipular el DOM directamente, React (o Vue, Svelte, HTMX, > Angular, Solid y un largo etc) nos ofrece una forma de codificar la > interfaz de usuario y su relación con los datos (Redux) que facilita un > alto grado de interactividad. > > El conjunto React/Redux es, quizás, lo más cuestionable y si se quiere > prescindible de todo lo mencionado. Cuando se lanzó, cubría una gran > cantidad de agujeros en performance y compatibilidad que tenían los > navegadores. Ya no existe la pelea entre Internet Explorer y NetScape y sus > muchas versiones que hacía temblar al desarrollador ante la posibilidad de > qué se podía hacer y qué no con cada uno. Ahora, la compatibilidad está > casi asegurada y las facilidades propias de los navegadores aumentan día a > día. Quién habría soñado hace unos años escribir, por ejemplo, > > <input type="number" placeholder="1.0" step="0.01" > min="0" max="10" /> > > Finalmente, TypeScript, un lenguaje basado en el JavaScript pero que > agrega la posibilidad de declarar los tipos de los datos (de allí el > prefijo Type) en el nombre. Un grave problema del JavaScript es que > cualquier variable puede aceptar cualquier clase de datos. Esto abre la > posibilidad de que una variable pueda contener un tipo de dato imprevisto, > por ejemplo, un texto en lugar de un número. TypeScript permite declarar > los tipos de las variables y los tipos de los parámetros de las funciones y > el tipo de valor que devuelve. Esto permite detectar errores en el > programa cuando se está desarrollando y no cuando se esté probando o, peor > aún, cuando esté en producción. Esto es particularmente útil en el caso > del uso de paquetes de terceros, cargados, por ejemplo, de NPM donde uno > puede tener la duda de si tal parámetro de una función acepta o no un > string numérico, o cuáles parámetros son opcionales. Editores como el > VsCode interpretan los archivos de tipos que genera el TypeScript para el > Intellisense, que provee ayuda inmediata mientras se escribe el código. > > > Creo que todos coinciden en que la enorme variedad de lenguajes (JSX, > TypeScript) y utilitarios (WebPack, NPM) es abrumadora para el > desarrollador, pero tienen su razón de ser y, dependiendo del tipo de > aplicación, la envergadura del equipo de programación y la amplitud del > mercado a que está destinada, muchas de estas herramientas, o sus > descendientes, están justificadas, como también lo está el PHP en muchas > otras. > > Saludos > > Satyam > > > >