Antes escribí con algo más de detalle sobre la etapa inicial del caso:
El origen del caso fue una decisión tomada en 1999: el gobierno británico no abandonó un sistema de pago de pensiones y prestaciones que el servicio postal había descartado por dudar de su fiabilidad, y decidió usarlo para modernizar el sistema existente de las oficinas postales, que registraba las transacciones en papel.
Este sistema de punto de venta electrónico, llamado Horizon, tuvo muchos problemas desde el principio, y comenzaron a detectarse diferencias entre el efectivo registrado en Horizon y el efectivo realmente disponible; según se cuenta, los subdirectores de correos, desconcertados, empezaron a llamar al centro de atención de Horizon.
El error "Dalmellington" congelaba la pantalla cuando el usuario intentaba confirmar si se había recibido efectivo, y en esa situación, cada vez que se presionaba Enter, registraba la recepción del efectivo sin mostrar ninguna indicación.
El error "Calendar Square" generó transacciones duplicadas debido a un fallo en la base de datos subyacente del sistema...
¿Cuál fue la causa? Hubo varias, pero destacan: 1) falta de personal, 2) fe ciega en la infalibilidad del software y 3) burocracia.
Falta de personal
Según David McDonnell, quien participó en el desarrollo, "había ocho personas en el equipo de desarrollo; dos eran muy capaces, dos eran normales pero se podía trabajar con ellas, y las otras 3 o 4 no tenían la capacidad de producir código profesional, así que no podían hacer bien el trabajo".
En esencia, el problema es que se está forzando la creación de una web tipo app dentro del protocolo HTTP, cuya base es el “documento” web.
La idea era que, si para resolver esto se necesitan funciones a nivel de aplicación, entonces quizá habría que crear un nuevo protocolo y framework pensados para apps.
Así como en un smartphone no se ejecutan programas nativos puros sino una especie de apps aisladas en sandbox, sería una estructura que se ejecute a nivel del navegador.
Claro, antes habría que garantizar apertura y estandarización para que no termine convirtiéndose en algo como ActiveX.
Todo está muy bien, pero si usas esto no podrás controlar WireGuard desde el sistema. Si quieres usarlo por separado del túnel, tendrás que dividirlo en una VM.
Incluso si se trata de una web tipo app, creo que deberíamos aspirar a algo cercano a la conclusión que plantea. Si se usa mucho JavaScript, del lado del cliente se vuelve pesada.
De hecho, no es que no existan frameworks con los que se pueda implementar así. Incluso en Next.js, si minimizas el uso de componentes del cliente y los usas solo cuando hace falta, más o menos se puede lograr. Y, como mencionó otra persona, en el ecosistema de Rails está Hotwire(https://hotwired.dev/), un conjunto de frameworks que soporta webs tipo app para acercarse bastante a la conclusión que menciona el autor (Turbo, Stimulus, etc.).
Como Claude dejó de ofrecer la licencia de la versión más reciente por el acuerdo de adquisición de OpenAI, para usar los modelos Claude 4.x en Windsurf hay que comprar directamente la API a un precio alto; ¿volverá Claude?
A diferencia de Corea, donde la cultura de desarrollo baja desde la dirección ejecutiva -> planificador -> desarrollador, en Occidente no existe ese concepto de planificador como en Corea y sí hay una participación más activa de los desarrolladores en la planificación del producto y similares. Los PM en Occidente, por ejemplo, no coinciden perfectamente con el planificador coreano, del mismo modo que una cover letter y una carta de presentación personal no son conceptos completamente idénticos. Claro, en los juegos, donde el carácter de proyecto creativo es fuerte y la diversión y la jugabilidad son importantes, Occidente también es más horizontal que Asia, aunque igualmente se baja del director al desarrollador.
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.
Antes escribí con algo más de detalle sobre la etapa inicial del caso:
El origen del caso fue una decisión tomada en 1999: el gobierno británico no abandonó un sistema de pago de pensiones y prestaciones que el servicio postal había descartado por dudar de su fiabilidad, y decidió usarlo para modernizar el sistema existente de las oficinas postales, que registraba las transacciones en papel.
Este sistema de punto de venta electrónico, llamado Horizon, tuvo muchos problemas desde el principio, y comenzaron a detectarse diferencias entre el efectivo registrado en Horizon y el efectivo realmente disponible; según se cuenta, los subdirectores de correos, desconcertados, empezaron a llamar al centro de atención de Horizon.
El error "Dalmellington" congelaba la pantalla cuando el usuario intentaba confirmar si se había recibido efectivo, y en esa situación, cada vez que se presionaba Enter, registraba la recepción del efectivo sin mostrar ninguna indicación.
El error "Calendar Square" generó transacciones duplicadas debido a un fallo en la base de datos subyacente del sistema...
¿Cuál fue la causa? Hubo varias, pero destacan: 1) falta de personal, 2) fe ciega en la infalibilidad del software y 3) burocracia.
Según David McDonnell, quien participó en el desarrollo, "había ocho personas en el equipo de desarrollo; dos eran muy capaces, dos eran normales pero se podía trabajar con ellas, y las otras 3 o 4 no tenían la capacidad de producir código profesional, así que no podían hacer bien el trabajo".
https://x.com/KayKiwoongKim/status/1825209040575873330
En esencia, el problema es que se está forzando la creación de una web tipo app dentro del protocolo HTTP, cuya base es el “documento” web.
La idea era que, si para resolver esto se necesitan funciones a nivel de aplicación, entonces quizá habría que crear un nuevo protocolo y framework pensados para apps.
Así como en un smartphone no se ejecutan programas nativos puros sino una especie de apps aisladas en sandbox, sería una estructura que se ejecute a nivel del navegador.
Claro, antes habría que garantizar apertura y estandarización para que no termine convirtiéndose en algo como ActiveX.
Las opiniones sobre "aburrido" están interesantes jaja. Si lo cambiáramos por otra palabra, ¿cuál quedaría bien? ¿Predecible, común?
¿No es una historia completamente distinta de la que estás contando?
No entiendo muy bien a qué se refiere con lo último que dijo sobre que era una plataforma idealizada.
Al final, estamos hablando de la época en que había que descargar un programa nativo y usar ActiveX ahí.
Traducir
boringcomo «aburrido» realmente no transmite bien su significado original.boringnesses una de las filosofías de diseño de Go.¿Otra vez nos van a engañar~?
No es tan fácil de usar cómodamente con solo hacer clic.
Grok 4 ahora es el modelo de IA líder
Reseña de Grok 4 por Simon Willison
Grok busca qué dice Elon Musk en X sobre el conflicto entre Israel y Palestina
Todo está muy bien, pero si usas esto no podrás controlar WireGuard desde el sistema. Si quieres usarlo por separado del túnel, tendrás que dividirlo en una VM.
Incluso si se trata de una web tipo app, creo que deberíamos aspirar a algo cercano a la conclusión que plantea. Si se usa mucho JavaScript, del lado del cliente se vuelve pesada.
De hecho, no es que no existan frameworks con los que se pueda implementar así. Incluso en Next.js, si minimizas el uso de componentes del cliente y los usas solo cuando hace falta, más o menos se puede lograr. Y, como mencionó otra persona, en el ecosistema de Rails está Hotwire(https://hotwired.dev/), un conjunto de frameworks que soporta webs tipo app para acercarse bastante a la conclusión que menciona el autor (Turbo, Stimulus, etc.).
Como Claude dejó de ofrecer la licencia de la versión más reciente por el acuerdo de adquisición de OpenAI, para usar los modelos Claude 4.x en Windsurf hay que comprar directamente la API a un precio alto; ¿volverá Claude?
A diferencia de Corea, donde la cultura de desarrollo baja desde la dirección ejecutiva -> planificador -> desarrollador, en Occidente no existe ese concepto de planificador como en Corea y sí hay una participación más activa de los desarrolladores en la planificación del producto y similares. Los PM en Occidente, por ejemplo, no coinciden perfectamente con el planificador coreano, del mismo modo que una cover letter y una carta de presentación personal no son conceptos completamente idénticos. Claro, en los juegos, donde el carácter de proyecto creativo es fuerte y la diversión y la jugabilidad son importantes, Occidente también es más horizontal que Asia, aunque igualmente se baja del director al desarrollador.
La filosofía de desarrollo que persiguen varía muchísimo.........
Al parecer, ni siquiera la IA es justa.
Da demasiado miedo.
Que un registro malicioso
derrote la memoria y la experiencia, se convierta en evidencia
y pueda llegar a amenazarnos.
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.