Re: [PHP-ES] Antes y despúes

This is a multi-part message in MIME format.
--------------Nrms2kHjEl2p6bfukGe6G0nK
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


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



--------------Nrms2kHjEl2p6bfukGe6G0nK
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 10/19/25 08:33, Narcis Garcia wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:[email protected]">El
      19/10/25 a les 6:30, Alma Guevara Castro ha escrit:
      <br>
      <blockquote type="cite">
        <br>
        *Fuente: Naiker.codes*
        <br>
        /"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./
        <br>
        /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./
        <br>
        /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!/*/"/
        <br>
        <br>
      </blockquote>
      <br>
      Celebro la viñeta.
      <br>
      <br>
      ¿Qué factores podemos encontrar que han encaminado el desarrollo a
      este problema?
      <br>
      ¿Componentes de terceros, gratuitos pero con ánimo de lucro?
      <br>
      ¿Pereza de escribir código?
      <br>
      ¿Uso de plantillas para el aspecto visual? <br>
      <br>
    </blockquote>
    <p>Hola Narcis, interesantes preguntas.  </p>
    <p>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:
<a class="moz-txt-link-freetext" href="https://survey.stackoverflow.co/2025/technology/#most-popular-technologies">https://survey.stackoverflow.co/2025/technology/#most-popular-technologies</a>
      .  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".</p>
    <p>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.</p>
    <p>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:</p>
    <ul>
      <li>Validar campos de datos del lado del cliente (aunque, por
        seguridad, debamos también hacerlo del lado del servidor). 
         Nadie quiere hacer un <i>submit</i> de un formulario de 100
        campos para, después de unos segundos, enterarse de que había un
        error en el segundo campo.</li>
      <li>Llenar un &lt;select&gt; basado en otro, por ejemplo, llenar
        el de municipio en base a la provincia seleccionada.</li>
      <li>Activar o desactivar campos opcionales según otras opciones en
        el formulario.</li>
    </ul>
    <p>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.</p>
    <p>La cosa creció, paso a paso, a partir de allí.  Veamos algunas de
      las tecnologías listadas más arriba.</p>
    <p>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.</p>
    <p>Al popularizarse muchos de estos 'paquetes' de funciones,
      apareció el NPM que no es un lenguaje de programación sino un
      sitio de web <a class="moz-txt-link-freetext" href="https://www.npmjs.com/">https://www.npmjs.com/</a> 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.</p>
    <p>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.  </p>
    <p>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.  </p>
    <p>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.   </p>
    <p>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.</p>
    <p>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.</p>
    <p>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.   </p>
    <p>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,</p>
    <pre>&lt;input type="number" placeholder="1.0" step="0.01" min="0" max="10" /&gt;</pre>
    <p>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.</p>
    <p><br>
    </p>
    <p>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.</p>
    <p>Saludos</p>
    <p>Satyam</p>
    <p><br>
    </p>
    <p><br>
    </p>
  </body>
</html>

--------------Nrms2kHjEl2p6bfukGe6G0nK--