No hay tantos tipos de navegadores que use la gente, pero sí hay demasiados frameworks. ¿No sería mejor que las empresas que gestionan los navegadores hicieran un framework óptimo y lo mantuvieran junto con ellos? ¿Hasta cuándo vamos a repetir este círculo vicioso?
Coincido con el diagnóstico del fenómeno, pero no con la conclusión.
La causa superficial del fenómeno, como también se menciona en el artículo, es que aumentó la demanda de una "web tipo app",
y tanto ahora como antes la web no era realmente adecuada para crear "algo parecido a una app", aunque si uno hace malabares, sí puede "lograr algo similar".
En realidad, la web desde su origen fue una plataforma creada para compartir una especie de "documentos", como los papers.
Eso se puede ver incluso solo observando los componentes básicos de HTML.
Luego aparecieron tecnologías capaces de generar contenido dinámico, como cgi, y del lado del navegador también se integraron lenguajes de scripting, lo que permitió darle dinamismo al resultado, y así comenzó el alejamiento de la "web como documento".
El problema es que, desde ese primer momento de ruptura hasta hoy, la base de la web sigue siendo un sistema fundamentado en "documentos".
Claro, han surgido muchas tecnologías nuevas que se apartan de esa orientación de "documento", como web socket, webrtc y wasm, pero incluso hoy la mayoría de los sitios web siguen desarrollándose sobre la plataforma tradicional basada en "documentos".
Seguimos teniendo que apilar etiquetas div para dibujar la pantalla.
Hasta ahí llega el análisis del fenómeno, y entonces uno se pregunta cuál sería la respuesta.
Si imaginamos las funciones de una plataforma ideal de próxima generación sin pensar para nada en su viabilidad, sería algo así:
(No digo que todos los sitios deban ser así, sino solo los sitios con carácter de aplicación).
Para empezar, el navegador se convertiría en una especie de lanzador de apps.
Una vez descargada, debería poder ejecutarse también sin conexión.
Y la app se implementaría dejando atrás el actual html/css/js y usando otros lenguajes.
En ese proceso, parece que el navegador podría ofrecer una especie de framework, como Android.
La forma de comunicación con el servidor también podría salir del esquema tradicional de solicitudes web y probar otro paradigma.
En el caso de comunicaciones que requieran tiempo real, se podría incluso usar la comunicación tcp tal cual,
y también se podría crear y usar una comunicación rpc nueva, más simple, que no utilice el protocolo http.
Hace un mes, para aprender qué era la programación con IA usando CURSOR, empecé a desarrollar un framework de desarrollo.
Durante unas 3 semanas, repetí el ciclo de ver cómo el código fuente, que había sido validado con éxito por un Agente de IA, se arruinaba, e intenté por todos los medios controlar al Agente de IA, pero fracasé.
Entonces me di cuenta de que, antes de desarrollar el framework, lo prioritario era desarrollar el código fuente para controlar al Agente de IA.
Al final, exactamente un mes después de haber empezado para entender qué era la IA, logré completar el desarrollo de un software 100% implementable y 100% operable por IA con control perfecto sobre el Agente de IA (más precisamente, sin necesidad de un LLM externo ni de un Agente de IA).
Ahora llevo 14 días avanzando en el proceso de crear y hacer cumplir reglas operativas mientras sigo entrenando esa META IA para una mayor sofisticación; al mismo tiempo, estoy migrando, mejorando y estandarizando en paralelo tres sistemas MES que antes habían sido creados de forma incompleta por personas, y ya estoy entrando en la etapa final.
Y ahora también me estoy preparando para otra evolución.
La visión central de la tecnología MCP-B puede entenderse así.
"A través del medio confiable que representa una extensión de Chrome (Extension), se aprovechará la información del usuario que el navegador ya gestiona de forma segura (cookies, sesiones, autenticación, etc.) para invocar y controlar con comandos en lenguaje natural, desde una ventana de chat de IA, las 'herramientas (Tools)' que los desarrolladores hayan definido previamente en la página web."
Sin embargo, yo siento que "no parece tener margen para escalar", y creo que las razones son las siguientes.
Resistencia de los usuarios: este es el mayor obstáculo. Los usuarios tienen un rechazo instintivo y preocupaciones de seguridad respecto a instalar extensiones que acceden a la información de su navegador. Si la comodidad que ofrece esta tecnología no es lo bastante abrumadora como para superar esas preocupaciones, los usuarios dudarán en instalarla.
Carga para los desarrolladores web: además de crear las API existentes, los desarrolladores de sitios web tendrían la carga adicional de definir y administrar por separado las 'herramientas (Tools)' para MCP-B. Si los beneficios obtenidos por una adopción amplia de esta tecnología no son grandes, los desarrolladores no querrán hacer ese doble esfuerzo.
Responsabilidad por problemas de seguridad: si ocurriera un incidente de seguridad a través de esta tecnología, podría volverse poco claro si la responsabilidad recae en el desarrollador del sitio web, en el desarrollador de la extensión o en el proveedor del modelo de IA. Esta complejidad hace que las empresas sean reacias a adoptar la tecnología.
Ausencia de una plataforma centralizada: por ahora no existe un directorio o plataforma estandarizada que informe "qué sitio web ofrece qué herramientas". Antes de visitar un sitio web, a los usuarios les resulta difícil saber qué funciones de IA podrán usar.
En conclusión,
aunque la idea de MCP-B en sí es técnicamente muy interesante e innovadora, parece que no logra dar una respuesta clara a la pregunta fundamental de "¿por qué habría que usar precisamente este método?" tanto para usuarios como para desarrolladores. En comparación con el enfoque tradicional basado en API, los beneficios obtenidos no están claros, mientras que las desventajas, como las preocupaciones de seguridad y la complejidad del desarrollo, sí lo están.
Por lo tanto, por ahora parece que esta tecnología podría usarse de forma experimental entre algunos entusiastas o desarrolladores con objetivos específicos, pero da la impresión de que enfrenta muchas dificultades para expandirse al ecosistema web en general.
Estoy de acuerdo con la preocupación de fondo de este artículo, pero también hay partes que me hacen levantar un poco la ceja.
Por ejemplo, el sitio web promocional de cierto servicio que opera nuestra empresa mantiene justamente la misma simplicidad que este artículo elogia. Por suerte, la mayoría de los elementos de ese sitio son bastante estáticos. El código del frontend, como HTML y CSS, está escrito a mano por personas sin ningún framework, y de JS solo tiene jQuery y Google Analytics. Los avisos y el tablero, entre otras cosas, están implementados con AJAX usando jQuery, pero no me parece que eso sea algo irracional ni excesivamente complejo. De hecho, siento que está dentro del nivel que yo mismo podía implementar con jQuery cuando empecé a aprender desarrollo web básico hace mucho tiempo. Hasta donde sé, ese sitio existe desde la época de Internet Explorer, así que no lo hice yo directamente, pero me parece que no está nada mal.
Pero aun así tiene control de versiones con Git y un pipeline de CI/CD, y además están separados el servidor de staging y el servidor de producción. Cuando se fusiona un Pull Request en la rama Main, el pipeline despliega automáticamente en el servidor de staging los artefactos generados por el bundler, y después, cuando la persona responsable revisa el servidor de staging y aprueba finalmente el despliegue, eso se publica otra vez en el servidor de producción. Antes simplemente se sobrescribían directamente los archivos originales en el servidor de producción por FTP, pero después de que ese trabajo pasó a nuestro equipo lo cambiamos a este esquema.
¿De verdad esto es una complejidad irracional? Antes, modificar la etiqueta de título de ese sitio web era tan simple como entrar directamente al archivo HTML del servidor de producción con AcroEdit compatible con conexión por FTP (sí, las personas que originalmente escribieron a mano el HTML de ese sitio seguían usando eso) y cambiar una sola línea, guardar, y con eso terminaba todo el trabajo. Así que probablemente ellas sí podrían sentirlo de esa manera.
Sin embargo, yo creo que agregar este nivel de complejidad era perfectamente razonable. No todas las tareas equivalen a cambiar una sola etiqueta de título. Y me parece que sí son ventajas suficientes cosas como poder borrar sin miedo código viejo que antes quedaba pegado por todos lados solo comentado, porque siempre puede restaurarse; poder rastrear cambios y hacer rollback de forma transparente; o poder agregar, si hace falta, optimizaciones más básicas mediante el bundler. Incluso añadir un servidor de staging para previsualizar antes de desplegar en el entorno real podría verse como otra forma de complejidad, pero yo sí creo que era necesario.
Yo también tengo muchas quejas sobre cómo la estructura interna del código de varios sitios web se ha vuelto excesivamente compleja y pesada. Hoy en día la app de Outlook en Windows está basada en una web app, y últimamente se ha puesto todavía más pesada. Ya llega al punto de trabarse o incluso mostrar "La página no responde" solo por escribir el cuerpo de un correo en pantalla o seleccionar todo el contenido. Me pregunté por qué pasaba eso, abrí las herramientas de desarrollador en Outlook web y me llevé una sorpresa. Una vez borré la caché y recargué, seguían apareciendo solicitudes incluso después de 1 minuto. Al revisarlo en el navegador, vi que solo lo relacionado con el sitio de MS Office tenía almacenados varios gigabytes de datos.
Sin embargo, en este artículo se mezclan varias cosas: con algunas partes coincido, pero con otras no tanto. Según entiendo, en temas como HTML semántico o accesibilidad, el pasado era incluso peor. Además, eso de que mejorar la experiencia del desarrollador empeora la experiencia del usuario no me genera ninguna identificación, aunque quizá sea porque yo no soy desarrollador frontend web. Incluso eso de que todo el poder y el control se concentraron en los desarrolladores me suena absurdo. ¿Acaso el poder en una empresa no lo tiene la dirección? ¿O es que en Occidente la estructura de las empresas es algo distinta de la de Corea?
Como siempre, estoy totalmente de acuerdo en que el equilibrio y la moderación, así como la simplicidad y la practicidad, son valores importantes y deben priorizarse en la toma de decisiones. Pero este artículo sostiene que "tratar todos los sitios web como si fueran productos de software" es casi enteramente responsabilidad de los desarrolladores, y creo que esa parte más bien termina difuminando la preocupación de fondo. Y también pienso que las partes que parecen idealizar aquellos "buenos viejos tiempos" en los que no había procesos establecidos deberían ser objeto de crítica.
Estoy de acuerdo con la idea principal de este artículo. Últimamente se está abusando demasiado de JS, así que hay muchos casos en los que un sitio se traba incluso usando un i9-9900k. Puede que sea una especificación algo ambigua para gaming o trabajo, pero la realidad es que abundan las computadoras de oficina con especificaciones peores que esa.
Por eso me gustan Astro y Hotwired, frameworks con la filosofía de usar JS solo cuando de verdad hace falta, como en las partes interactivas o en una navegación de página interactiva. También me gusta SSR, es decir, renderizar del lado del servidor. En cambio, detesto mucho CSR (incluyendo cuando solo se renderizan del lado del servidor las meta tags y el resto se maneja con CSR). Porque lo veo como trasladarle al cliente trabajo que debería hacer el servidor. Personalmente, creo que el enfoque tradicional de SPA que usa CSR debería usarse cuando el frontend se ejecuta localmente en una app como Electron. Claro, si el frontend se carga desde el servidor, entonces sí debería usarse SSR.
Creo que, por la estructura de los LLM, será imposible garantizar por completo la seguridad. Pienso que es inevitable que los LLM sean inestables, y que lo importante será cómo otorgarles autoridad sobre acciones físicas, como en agentes o en conducción autónoma.
No hay tantos tipos de navegadores que use la gente, pero sí hay demasiados frameworks. ¿No sería mejor que las empresas que gestionan los navegadores hicieran un framework óptimo y lo mantuvieran junto con ellos? ¿Hasta cuándo vamos a repetir este círculo vicioso?
Tengo curiosidad por saber por qué se cayó.
Resulta que la forma definitiva de una IA aduladora era una IA que adula al jefe...
Coincido con el diagnóstico del fenómeno, pero no con la conclusión.
La causa superficial del fenómeno, como también se menciona en el artículo, es que aumentó la demanda de una "web tipo app",
y tanto ahora como antes la web no era realmente adecuada para crear "algo parecido a una app", aunque si uno hace malabares, sí puede "lograr algo similar".
En realidad, la web desde su origen fue una plataforma creada para compartir una especie de "documentos", como los papers.
Eso se puede ver incluso solo observando los componentes básicos de HTML.
Luego aparecieron tecnologías capaces de generar contenido dinámico, como
cgi, y del lado del navegador también se integraron lenguajes de scripting, lo que permitió darle dinamismo al resultado, y así comenzó el alejamiento de la "web como documento".El problema es que, desde ese primer momento de ruptura hasta hoy, la base de la web sigue siendo un sistema fundamentado en "documentos".
Claro, han surgido muchas tecnologías nuevas que se apartan de esa orientación de "documento", como web socket, webrtc y wasm, pero incluso hoy la mayoría de los sitios web siguen desarrollándose sobre la plataforma tradicional basada en "documentos".
Seguimos teniendo que apilar etiquetas
divpara dibujar la pantalla.Hasta ahí llega el análisis del fenómeno, y entonces uno se pregunta cuál sería la respuesta.
Si imaginamos las funciones de una plataforma ideal de próxima generación sin pensar para nada en su viabilidad, sería algo así:
(No digo que todos los sitios deban ser así, sino solo los sitios con carácter de aplicación).
Para empezar, el navegador se convertiría en una especie de lanzador de apps.
Una vez descargada, debería poder ejecutarse también sin conexión.
Y la app se implementaría dejando atrás el actual html/css/js y usando otros lenguajes.
En ese proceso, parece que el navegador podría ofrecer una especie de framework, como Android.
La forma de comunicación con el servidor también podría salir del esquema tradicional de solicitudes web y probar otro paradigma.
En el caso de comunicaciones que requieran tiempo real, se podría incluso usar la comunicación
tcptal cual,y también se podría crear y usar una comunicación
rpcnueva, más simple, que no utilice el protocolohttp.Oh, vaya, parece que el futuro de Windsurf tampoco pinta tan prometedor.
Hace un mes, para aprender qué era la programación con IA usando CURSOR, empecé a desarrollar un framework de desarrollo.
Durante unas 3 semanas, repetí el ciclo de ver cómo el código fuente, que había sido validado con éxito por un Agente de IA, se arruinaba, e intenté por todos los medios controlar al Agente de IA, pero fracasé.
Entonces me di cuenta de que, antes de desarrollar el framework, lo prioritario era desarrollar el código fuente para controlar al Agente de IA.
Al final, exactamente un mes después de haber empezado para entender qué era la IA, logré completar el desarrollo de un software 100% implementable y 100% operable por IA con control perfecto sobre el Agente de IA (más precisamente, sin necesidad de un LLM externo ni de un Agente de IA).
Ahora llevo 14 días avanzando en el proceso de crear y hacer cumplir reglas operativas mientras sigo entrenando esa META IA para una mayor sofisticación; al mismo tiempo, estoy migrando, mejorando y estandarizando en paralelo tres sistemas MES que antes habían sido creados de forma incompleta por personas, y ya estoy entrando en la etapa final.
Y ahora también me estoy preparando para otra evolución.
La visión central de la tecnología MCP-B puede entenderse así.
"A través del medio confiable que representa una extensión de Chrome (Extension), se aprovechará la información del usuario que el navegador ya gestiona de forma segura (cookies, sesiones, autenticación, etc.) para invocar y controlar con comandos en lenguaje natural, desde una ventana de chat de IA, las 'herramientas (Tools)' que los desarrolladores hayan definido previamente en la página web."
Sin embargo, yo siento que "no parece tener margen para escalar", y creo que las razones son las siguientes.
En conclusión,
aunque la idea de MCP-B en sí es técnicamente muy interesante e innovadora, parece que no logra dar una respuesta clara a la pregunta fundamental de "¿por qué habría que usar precisamente este método?" tanto para usuarios como para desarrolladores. En comparación con el enfoque tradicional basado en API, los beneficios obtenidos no están claros, mientras que las desventajas, como las preocupaciones de seguridad y la complejidad del desarrollo, sí lo están.
Por lo tanto, por ahora parece que esta tecnología podría usarse de forma experimental entre algunos entusiastas o desarrolladores con objetivos específicos, pero da la impresión de que enfrenta muchas dificultades para expandirse al ecosistema web en general.
Estoy de acuerdo con la preocupación de fondo de este artículo, pero también hay partes que me hacen levantar un poco la ceja.
Por ejemplo, el sitio web promocional de cierto servicio que opera nuestra empresa mantiene justamente la misma simplicidad que este artículo elogia. Por suerte, la mayoría de los elementos de ese sitio son bastante estáticos. El código del frontend, como HTML y CSS, está escrito a mano por personas sin ningún framework, y de JS solo tiene jQuery y Google Analytics. Los avisos y el tablero, entre otras cosas, están implementados con AJAX usando jQuery, pero no me parece que eso sea algo irracional ni excesivamente complejo. De hecho, siento que está dentro del nivel que yo mismo podía implementar con jQuery cuando empecé a aprender desarrollo web básico hace mucho tiempo. Hasta donde sé, ese sitio existe desde la época de Internet Explorer, así que no lo hice yo directamente, pero me parece que no está nada mal.
Pero aun así tiene control de versiones con Git y un pipeline de CI/CD, y además están separados el servidor de staging y el servidor de producción. Cuando se fusiona un Pull Request en la rama Main, el pipeline despliega automáticamente en el servidor de staging los artefactos generados por el bundler, y después, cuando la persona responsable revisa el servidor de staging y aprueba finalmente el despliegue, eso se publica otra vez en el servidor de producción. Antes simplemente se sobrescribían directamente los archivos originales en el servidor de producción por FTP, pero después de que ese trabajo pasó a nuestro equipo lo cambiamos a este esquema.
¿De verdad esto es una complejidad irracional? Antes, modificar la etiqueta de título de ese sitio web era tan simple como entrar directamente al archivo HTML del servidor de producción con AcroEdit compatible con conexión por FTP (sí, las personas que originalmente escribieron a mano el HTML de ese sitio seguían usando eso) y cambiar una sola línea, guardar, y con eso terminaba todo el trabajo. Así que probablemente ellas sí podrían sentirlo de esa manera.
Sin embargo, yo creo que agregar este nivel de complejidad era perfectamente razonable. No todas las tareas equivalen a cambiar una sola etiqueta de título. Y me parece que sí son ventajas suficientes cosas como poder borrar sin miedo código viejo que antes quedaba pegado por todos lados solo comentado, porque siempre puede restaurarse; poder rastrear cambios y hacer rollback de forma transparente; o poder agregar, si hace falta, optimizaciones más básicas mediante el bundler. Incluso añadir un servidor de staging para previsualizar antes de desplegar en el entorno real podría verse como otra forma de complejidad, pero yo sí creo que era necesario.
Yo también tengo muchas quejas sobre cómo la estructura interna del código de varios sitios web se ha vuelto excesivamente compleja y pesada. Hoy en día la app de Outlook en Windows está basada en una web app, y últimamente se ha puesto todavía más pesada. Ya llega al punto de trabarse o incluso mostrar "La página no responde" solo por escribir el cuerpo de un correo en pantalla o seleccionar todo el contenido. Me pregunté por qué pasaba eso, abrí las herramientas de desarrollador en Outlook web y me llevé una sorpresa. Una vez borré la caché y recargué, seguían apareciendo solicitudes incluso después de 1 minuto. Al revisarlo en el navegador, vi que solo lo relacionado con el sitio de MS Office tenía almacenados varios gigabytes de datos.
Sin embargo, en este artículo se mezclan varias cosas: con algunas partes coincido, pero con otras no tanto. Según entiendo, en temas como HTML semántico o accesibilidad, el pasado era incluso peor. Además, eso de que mejorar la experiencia del desarrollador empeora la experiencia del usuario no me genera ninguna identificación, aunque quizá sea porque yo no soy desarrollador frontend web. Incluso eso de que todo el poder y el control se concentraron en los desarrolladores me suena absurdo. ¿Acaso el poder en una empresa no lo tiene la dirección? ¿O es que en Occidente la estructura de las empresas es algo distinta de la de Corea?
Como siempre, estoy totalmente de acuerdo en que el equilibrio y la moderación, así como la simplicidad y la practicidad, son valores importantes y deben priorizarse en la toma de decisiones. Pero este artículo sostiene que "tratar todos los sitios web como si fueran productos de software" es casi enteramente responsabilidad de los desarrolladores, y creo que esa parte más bien termina difuminando la preocupación de fondo. Y también pienso que las partes que parecen idealizar aquellos "buenos viejos tiempos" en los que no había procesos establecidos deberían ser objeto de crítica.
Haciéndose el muy aburrido…
En Corea todo termina siendo JavaLandia, así que se les hace raro, jaja
Creo que la tecnología de otro país != los datos de otro país.
Por ahora, no me lo creo hasta que lo liberen gratis. Grok cuesta incluso 30 dólares, así que me da miedo suscribirme...
jajajaja el estudiante de posgrado quedó todo sacado de onda por el golpe inesperado..
Usa Rails, sé feliz
Apoyo el intento, pero...
Ojalá no hagan cosas como crear una nueva organización y tirar por la borda la 1.0.
¿Se trata de la vida en la empresa (coreana)? Jajaja
Ojalá también salga en YCD~
Estoy de acuerdo con la idea principal de este artículo. Últimamente se está abusando demasiado de JS, así que hay muchos casos en los que un sitio se traba incluso usando un i9-9900k. Puede que sea una especificación algo ambigua para gaming o trabajo, pero la realidad es que abundan las computadoras de oficina con especificaciones peores que esa.
Por eso me gustan Astro y Hotwired, frameworks con la filosofía de usar JS solo cuando de verdad hace falta, como en las partes interactivas o en una navegación de página interactiva. También me gusta SSR, es decir, renderizar del lado del servidor. En cambio, detesto mucho CSR (incluyendo cuando solo se renderizan del lado del servidor las meta tags y el resto se maneja con CSR). Porque lo veo como trasladarle al cliente trabajo que debería hacer el servidor. Personalmente, creo que el enfoque tradicional de SPA que usa CSR debería usarse cuando el frontend se ejecuta localmente en una app como Electron. Claro, si el frontend se carga desde el servidor, entonces sí debería usarse SSR.
Pedir ayuda también es una habilidad.
Creo que, por la estructura de los LLM, será imposible garantizar por completo la seguridad. Pienso que es inevitable que los LLM sean inestables, y que lo importante será cómo otorgarles autoridad sobre acciones físicas, como en agentes o en conducción autónoma.