paint-brush
La différence entre les applications Web et les sites Webpar@webhistory
3,787 lectures
3,787 lectures

La différence entre les applications Web et les sites Web

par History of the Web6m2023/01/15
Read on Terminal Reader

Trop long; Pour lire

En 1999, la conversation autour du web portait sur sa puissance en tant que nouveau média. Mais il y avait peu d'applications informatiques. Koranteng Ofosu-Amaah d'IBM a tracé une ligne cruciale dans le sable. Dans un article de blog, il a écrit sur les applications vs W3C DOM.
featured image - La différence entre les applications Web et les sites Web
 History of the Web HackerNoon profile picture
0-item

Un site Web est-il la même chose qu'une application Web ? Cette question est plus ancienne que vous ne le pensez


En 2013, le blog de développement web CSS Tricks a mené un sondage avec une seule question : « Est-il utile de faire la distinction entre les « applications Web » et les « sites Web » ? Dix-sept mille personnes ont répondu. 72 % ont répondu Oui. Ce sont des choses différentes avec des préoccupations différentes. Les 28% restants ont répondu Non. Tout n'est que le web.


Cette question, diffusée de différentes manières, est devenue un refrain commun. Toutes les quelques années, il réintègre l'air du temps du développement Web. Au centre, cependant, se pose la même question : le web est-il divisé ? Existe-t-il un site Web destiné aux applications de type bureau et un autre destiné au contenu. Un web qui sert, et un autre qui crée.


En pratique, il n'offre guère plus qu'une expérience de pensée, bien qu'utile. Il peut encadrer un moment de pratique du développement web. Il est tout aussi utile de retracer la conversation jusqu'à l'une des premières fois où la conversation a surgi, jusqu'à l'histoire de DHTML et d'une société appelée Oddpost.


En 1999, la petite startup Halfbrain a lancé BrainMatter. BrainMatter était un tableur. Il imitait la fonctionnalité d'Excel, et les utilisateurs pouvaient trier les données, faire glisser et déposer des lignes et des colonnes, et même utiliser des fonctions et des macros de base. Ce qui a fait la particularité de BrainMatter, c'est qu'il existait entièrement sur le Web. N'importe quel utilisateur peut démarrer BrainMatter directement dans son navigateur depuis n'importe où dans le monde. Bien qu'à l'époque, le site ne fonctionnait que sur le navigateur leader du marché Internet Explorer, un choix conscient de l'équipe de développement en raison du type de technologie que Microsoft avait mis à disposition.


Néanmoins, BrainMatter était impressionnant ; cela a fonctionné bien mieux que quiconque ne l'aurait cru possible. En 1999, la conversation autour du Web s'est concentrée sur sa puissance en tant que nouveau média - l'ère du « contenu est roi ». Les publications dominaient le paysage des internautes, mais il y avait peu d'applications informatiques. Halfbrain a défié cette perception, tirant parti d'un lot de technologies évolutives regroupées sous l'égide de Dynamic HTML, ou DHTML.


Plutôt qu'une pratique ou un principe de programmation unifié, DHTML était un ensemble lâche de techniques qui combinent JavaScript, CSS et quelques technologies Microsoft propriétaires (c'est pourquoi il ne fonctionnait que dans un navigateur Microsoft) pour rendre possibles des sites Web capables d'actualiser des données interactives sans la nécessité d'un rechargement de page. Cela permet aux utilisateurs d'interagir directement avec une page, de remplir des formulaires pour ajouter des données, de faire glisser des éléments - et généralement de faire le type de choses que les gens avaient l'habitude de faire uniquement sur leur bureau - directement sur le Web. À l'époque de Google Docs et des applications Web Electron, cela peut sembler courant. En 1999, il était tout neuf.


Peu de temps après la sortie de BrainMatter, Halfbrain a été racheté par AlphaBlox, qui a utilisé la même technologie et les mêmes techniques pour créer un logiciel de présentation sur le Web ; PowerPoint dans un site Web. Peu de temps après, AlphaBlox a été racheté par IBM.


À ce moment-là, le marché des navigateurs avait une nouvelle étoile montante, Firefox de Mozilla. Firefox a rendu DHTML possible d'une manière que l'ancien concurrent de Microsoft et son prédécesseur, Netscape, n'avaient jamais eu. Mais non sans difficulté. L'un des ingénieurs d'IBM, Koranteng Ofosu-Amaah, a ensuite compilé des notes sur cette même complexité dans un article de blog, Applications vs W3C Dom . Dans ce document, Ofosu-Amaah trace une ligne cruciale dans le sable. D'une part, les applications Web, rendues possibles grâce à une série de hacks, de solutions de contournement intelligentes et de technologies propriétaires disponibles dans un navigateur ou un autre. L'un et l'autre sont des sites Web de contenu, rendus possibles par les technologies standardisées du Web. Applications pilotées par DOM et sites web pilotés par des normes. Applications Web et sites Web.

Halfbrain alun publiera plus tard Oddpost, illustré ici, en utilisant les mêmes techniques appliquées à DHTML

Dans l'une de ses notes, il le précise : La compatibilité des navigateurs est un gros obstacle pour les applications DOM du W3C . Ofosu-Amaah a reconnu que certains sites nécessitaient des fonctionnalités et des technologies qui n'étaient pas universellement accessibles, et ont ainsi totalement exclu certains utilisateurs de l'expérience (les personnes utilisant des navigateurs plus anciens, par exemple). Et dans l'état du développement Web vers l'an 2000, c'était en grande partie vrai. La question des applications Web par rapport aux sites Web à l'époque était largement axée sur ce fait, qu'il était presque impossible d'offrir la même expérience interactive et dynamique sur tous les navigateurs et appareils.


Le nombre d'ingénieurs Web en activité en 1999 était relativement faible. Ingénieurs connaissant bien DHTML, encore plus petit que cela. Parmi ce groupe restreint se trouvaient deux ingénieurs de Halfbrain, Ethan Diamond et Iain Lamb. En 2002, ils étaient prêts à passer de Halfbrain à leur prochaine application Web alimentée par DHTML. Cette fois par mail. Il s'appelait Oddpost.


Oddpost a fait ses débuts en juin 2002. Sa page d'accueil se lit simplement "Voici ! Oddpost. E-mail incomparable. Les dernières nouvelles et blogs. Tout en un seul endroit. La fonction principale d'Oddpost était le courrier électronique. Il a modélisé les applications de messagerie de bureau populaires de l'époque, comme Microsoft Outlook et Eudora. Mais il avait également un lecteur de flux intégré pour agréger le contenu des sites d'actualités et des blogs.

Comme BrainMatter, cependant, Oddpost fonctionnait entièrement sur le Web, en utilisant des technologies Web natives. Il était accessible à partir de n'importe quel ordinateur doté d'un navigateur moderne (mais encore une fois, juste Internet Explorer), ce qui était la plupart des ordinateurs. À 30 $ / an, c'était dans un territoire à prix raisonnable avant que le concept de courrier électronique gratuit ne devienne la norme.


En termes d'interfaces de messagerie, ce n'était pas trop révolutionnaire. Fenêtre à trois volets. Messages organisés par date, enfilés par expéditeur. Son interface était simple, avec seulement les fonctionnalités les plus essentielles. C'était voulu. Oddpost était impressionnant car il se sentait vif et dynamique même si, pour l'utilisateur moyen, ce n'était rien de plus qu'une URL Web.


Telle était la puissance de DHTML. Lors du lancement d'Oddpost, d'autres applications Web similaires ont été lancées et conçues dans diverses poches du Web. Cela a réorienté la conversation sur la possibilité et la promesse du Web, et les gens ont commencé à discuter de sites Web qui étaient plus que des sites Web. Des sites Web qui étaient, comme le dit Ofosu-Amaah, de véritables applications Web.


En 2002, Ethan Diamond a accordé une interview au blog populaire de Joshua Kaufman , Unraveled . Oddpost, comme BrainMatter avant lui, ne fonctionnerait pas du tout à l'intérieur de Mozilla. Kaufman a poussé Diamond sur ce point, remettant en cause la décision de verrouiller un groupe d'utilisateurs potentiellement important. La réponse de Diamond a mis en évidence la distinction entre l'application et le site Web.

« Oddpost n'est pas une page Web, c'est une application logicielle [nous soulignons]. Les pages Web, qu'elles soient consacrées à des soirées pyjamas mixtes totalement sans pyjama ou à la Déclaration des droits de l'homme, présentent des informations, et il existe une conviction bien répandue que l'information devrait être accessible à tous… Les applications logicielles, en revanche, sont des outils, et il est absurde de leur appliquer la norme d'accès à l'information du Web. De plus, les applications logicielles, avec toute l'incroyable sophistication que cette étiquette implique, nécessitent des coûts et des efforts considérables pour se développer sur une plate-forme unique. Pour les applications web comme Oddpost, les normes W3C atténuent, mais ne nient absolument pas cette vérité. C'est un point que nous devons souvent souligner, mais jamais à quiconque ayant ne serait-ce qu'un minimum d'expérience dans les applications Web multi-navigateurs.

Dans sa réponse, il a évoqué un argument familier. Bien que les applications Web soient possibles sur le Web, a expliqué Diamond, les applications Web n'étaient pas nécessairement disponibles pour tous les utilisateurs du Web.


Cette interview a déclenché une autre série de conversations, plusieurs années après le lancement de BrainMatter. Une réponse, de Joyce Park de Dojo Toolkit, l'a dit clairement . "D'après mon expérience, il faut peu de temps marginal pour que quelque chose fonctionne dans Mozilla ainsi que dans IE... Et bien que le nombre total d'utilisateurs non-IE soit faible, le pourcentage d'utilisateurs précoces des technologies Web au sein de ce groupe est super super élevé … donc on pourrait penser que le plan d'affaires pour quelque chose comme Oddpost devrait en tenir compte.


Et cela est souvent au centre du débat. L'effort marginal de prise en charge de plusieurs navigateurs est-il une condition préalable plutôt qu'une option ? L'ouverture du Web est-elle quelque chose de si intrinsèque, de si fondamental, qu'elle ne peut être ignorée. Ou sommes-nous maudits d'avoir une version du Web qui vit à la pointe de l'exclusion de certains dans le but de proposer des expériences que personne ne pensait possibles. Ces questions restent sans réponse, mais une chose est sûre. Ils seront certainement redemandés.


Sources


Première publication ici .