Re: Antes y despúes

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