La diferencia entre aplicaciones web y sitios web

¿Es lo mismo un sitio web que una aplicación web? Esa pregunta es más antigua de lo que crees.

En 2013, el blog de desarrollo web CSS Tricks realizó una encuesta con una sola pregunta: “¿Es útil distinguir entre “aplicaciones web” y “sitios web”? Diecisiete mil personas respondieron. 72% respondió Sí. Son cosas diferentes con preocupaciones diferentes. El 28% restante respondió No. Todo es solo la web.

Esa pregunta, circulada de diferentes maneras, se ha convertido en un estribillo común. Cada pocos años vuelve a entrar en el espíritu de la época del desarrollo web. En el centro, sin embargo, yace la misma pregunta: ¿ está dividida la red? ¿Hay una web destinada a aplicaciones de escritorio y otra destinada a contenido? Una web que sirve, y otra que crea.

En la práctica, ofrece poco más que un experimento mental, aunque útil. Puede enmarcar un momento de práctica de desarrollo web. Igualmente útil es rastrear la conversación hasta uno de los primeros momentos en que surgió la conversación, hasta la historia de DHTML y una empresa llamada Oddpost.

En 1999, la pequeña startup Halfbrain lanzó BrainMatter. BrainMatter era una aplicación de hoja de cálculo. Imitaba la funcionalidad de Excel, y los usuarios podían ordenar datos, arrastrar y soltar filas y columnas, e incluso usar funciones y macros básicas. Lo que hizo que BrainMatter se destacara fue que existía completamente en la web. Cualquier usuario puede iniciar BrainMatter directamente en su navegador desde cualquier parte del mundo. Aunque, en ese momento, el sitio solo funcionaba en el navegador líder en el mercado Internet Explorer, una elección consciente del equipo de desarrollo debido al tipo de tecnología que Microsoft había puesto a disposición.

Sin embargo, BrainMatter fue impresionante; funcionó mucho mejor de lo que nadie había pensado que fuera posible. En 1999, la conversación en torno a la web se centró en su poder como nuevo medio: la era del "contenido es el rey". Las publicaciones dominaban el panorama de los internautas, pero había pocas aplicaciones informáticas. Halfbrain desafió esa percepción, aprovechando un lote de tecnologías en evolución agrupadas bajo el paraguas de HTML dinámico o DHTML.

En lugar de alguna práctica o principio de programación unificado, DHTML era una colección suelta de técnicas que combinaban JavaScript, CSS y algunas tecnologías propietarias de Microsoft (razón por la cual solo funcionaba en un navegador de Microsoft) para crear posibles sitios web que podían actualizar datos interactivos sin la necesidad de recargar una página. Esto permitió a los usuarios interactuar directamente con una página, completar formularios para agregar datos, arrastrar cosas y, en general, hacer el tipo de cosas que la gente solía hacer solo en sus escritorios, directamente en la web. En la época de Google Docs y las aplicaciones electrónicas basadas en la web, eso podría parecer un lugar común. En 1999, era nuevo.

No mucho después del lanzamiento de BrainMatter, AlphaBlox compró Halfbrain, que usó la misma tecnología y técnicas para crear software de presentación en la web; PowerPoint en un sitio web. Poco después, IBM adquirió AlphaBlox.

Para entonces, el mercado de los navegadores tenía una nueva estrella en ascenso, Firefox de Mozilla. Firefox hizo posible DHTML de una manera que el competidor anterior de Microsoft y su predecesor, Netscape, nunca habían hecho. Pero no sin dificultad. Uno de los ingenieros de IBM, Koranteng Ofosu-Amaah, luego compiló notas sobre esa misma complejidad en una publicación de blog, Applications vs W3C Dom . En él, Ofosu-Amaah dibuja una línea crucial en la arena. Por un lado, están las aplicaciones web, posibles gracias a una serie de trucos, soluciones inteligentes y tecnologías propietarias disponibles en un navegador u otro. Uno de los otros son sitios web de contenido, posibles gracias a las tecnologías estandarizadas de la web. Aplicaciones basadas en DOM y sitios web basados en estándares. Aplicaciones web y sitios web.

En una de sus notas, lo hace explícito: la compatibilidad del navegador es un gran obstáculo para las aplicaciones W3C DOM . Ofosu-Amaah reconoció que algunos sitios requerían funciones y tecnologías que no eran universalmente accesibles y, por lo tanto, bloquearon completamente la experiencia de algunos usuarios (personas que usaban navegadores más antiguos, por ejemplo). Y en el estado del desarrollo web alrededor del año 2000, esto era en gran medida cierto. La cuestión de las aplicaciones web frente a los sitios web en ese momento se centró en gran medida en este hecho, que era casi imposible brindar la misma experiencia interactiva y dinámica en todos los navegadores y dispositivos.

La cantidad de ingenieros web en activo en 1999 era relativamente pequeña. Ingenieros bien versados en DHTML, incluso más pequeños que eso. Entre este selecto grupo se encontraban dos ingenieros Halfbrain, Ethan Diamond e Iain Lamb. En 2002, estaban listos para pasar de Halfbrain a su próxima aplicación web basada en DHTML. Esta vez por correo electrónico. Se llamaba Oddpost.

Oddpost debutó en junio de 2002. Su página de inicio decía simplemente “¡Mira! Oddpost. Correo electrónico incomparable. Las últimas noticias y blogs. Todo en un lugar." La función principal de Oddpost era el correo electrónico. Modeló las populares aplicaciones de correo electrónico de escritorio de la época, como Microsoft Outlook y Eudora. Pero también tenía un lector de feeds incorporado para agregar contenido de sitios de noticias y blogs.

Sin embargo, al igual que BrainMatter, Oddpost se ejecutó completamente en la web, utilizando tecnologías web nativas. Se podía acceder desde cualquier computadora que tuviera un navegador moderno (aunque nuevamente, solo Internet Explorer), que era la mayoría de las computadoras. A $ 30 / año, estaba en un territorio de precio razonable antes de que el concepto de correo electrónico gratuito fuera la norma.

En términos de interfaces de correo electrónico, no fue demasiado innovador. Ventana de tres paneles. Mensajes organizados por fecha, hilos por remitente. Su interfaz era simple, con solo las características más esenciales. Eso fue por diseño. Oddpost fue impresionante porque se sintió rápido y dinámico a pesar de que, para el usuario promedio, no era más que una URL web.

Tal era el poder de DHTML. Cuando se lanzó Oddpost, se lanzaron otras aplicaciones web similares concebidas en varios bolsillos de la web. Reorientó la conversación sobre la posibilidad y la promesa de la web, y la gente empezó a hablar de sitios web que eran más que sitios web. Sitios web que eran, como dijo Ofosu-Amaah, aplicaciones web.

En 2002, Ethan Diamond concedió una entrevista al popular blog de Joshua Kaufman , Unraveled . Oddpost, al igual que BrainMatter antes, no funcionaría en absoluto dentro de Mozilla. Kaufman presionó a Diamond en este punto, cuestionando la decisión de bloquear a un grupo potencialmente grande de usuarios. La respuesta de Diamond puso de manifiesto la distinción entre la aplicación y el sitio web.

“Oddpost no es una página web, es una aplicación de software [énfasis añadido]. Las páginas web, ya sea dedicadas a fiestas de pijamas mixtas sin pijamas o a La Declaración de los Derechos del Hombre, presentan información, y existe una creencia buena y generalizada de que la información debe estar disponible para todos... Las aplicaciones de software, por otro lado, son herramientas, y es absurdo aplicarles el estándar de libertad de información de la web. Además, las aplicaciones de software, con toda la increíble sofisticación que implica esa etiqueta, requieren un costo y un esfuerzo tremendos para desarrollarse para una sola plataforma. Para aplicaciones web como Oddpost, los estándares W3C mitigan, pero no niegan en absoluto esta verdad. Este es un punto que a menudo tenemos que hacer, pero nunca a nadie con un mínimo de experiencia en aplicaciones web entre navegadores”.

En su respuesta, evocó un argumento familiar. Aunque las aplicaciones web eran posibles en la web, argumentó Diamond, las aplicaciones web no estaban necesariamente disponibles para todos los usuarios de la web.

Esa entrevista provocó otra ronda de conversación, varios años después del lanzamiento de BrainMatter. Una respuesta, de Joyce Park de Dojo Toolkit, lo dijo claramente . “Según mi experiencia, se necesita poco tiempo marginal para hacer que algo funcione en Mozilla así como en IE… Y aunque el número total de usuarios que no son de IE es pequeño, el porcentaje de los primeros en adoptar tecnologías basadas en la web dentro de ese grupo es muy, muy alto. … por lo que uno pensaría que el plan de negocios para algo como Oddpost debería tener eso en cuenta”.

Y eso suele estar en el centro del debate. ¿Es el esfuerzo marginal de compatibilidad entre navegadores un requisito previo en lugar de una opción? ¿Es la apertura de la web algo tan intrínseco, tan fundamental, que no se puede ignorar? ¿O estamos condenados a tener una versión de la web que vive a la vanguardia con la exclusión de algunos en un intento de brindar experiencias que nadie pensó que eran posibles? Estas preguntas siguen sin respuesta, pero una cosa es segura. Definitivamente se les preguntará de nuevo.

Fuentes

• Phil Wainewright. "Recuperando el significado de Office". ZDnet. 9 de septiembre de 2005. https://www.zdnet.com/article/reclaiming-the-meaning-of-office/
• Adán Rifkin. "Webplicaciones". Relájate, todo está profundamente entrelazado. 12 de diciembre de 2004. https://ifindkarma.typepad.com/relax/2004/12/weblications.html
• Phil Wainewright. "Ahora IBM compra Alphablox". Débilmente acoplado. 7 de julio de 2004. http://www.looselycoupled.com/blog/lc00aa00045.html
• Koranteng Ofosu-Amaah. "Aplicaciones frente a W3C DOM". Koranteng. 7 de julio de 2003. https://home.koranteng.com/writings/applications-vs-w3c-dom.html

Publicado por primera vez aquí .