Si, techniquement parlant, l’avenir du web passe par html5, css3 et javascript, il est intéressant de noter une conséquence importante de cette rupture technologique : la remise en cause de l’architecture client-serveur.
la victoire du web
Dans un billet daté d’octobre 2008 intitulé un écosystème internet libre, il était déjà possible de faire le constat que Microsoft et Adobe faisaient fausse route dans la course au web.
Depuis, les indices s’accumulent au sujet des impasses non-standards, propriétaires et fermées dans lesquelles Microsoft et Adobe se sont engagés :
La tendance est claire : l’avenir du web passe par html5. Le web a une fois de plus gagné. Mais ce n’est pas la première victoire du web sur d’autres médias.
- Il y a eu les cdroms multimédia, ils ont été supplantés par le web.
- Il y a eu les applications internet riches : les RIA (comme les applications Flash, Air ou Silverlight), en l’absence d’un éditeur assurant le support des technologies sous-jacentes, ces applications resteront confidentielles, supplantées par le web.
- Il y a les applications mobiles natives (principalement pour les systèmes d’exploitation mobiles Android de Google et iOS d’Apple), elles seront également évincées par le web (lire l’article intitulé mobile web versus mobile apps).
La raison de la supériorité du web est simple : les liens. L’article intitulé why apps are not the future?) illustre parfaitement en quoi les liens constituent l’essence du web, ce qui caractérise son originalité, et implique son unicité.
Les liens hypertexte sont à la base du web, ils sont le ht de http et de html. Les liens créent un réseau de ressources sur le web, une toile de sites web où le tout vaut plus que la somme des parties. Ne pas comprendre cette notion essentielle, c’est ne pas comprendre ce qu’est le web, comment il fonctionne, et d’où il tire sa force et son unicité.
Concevoir une application qui fonctionne dans son coin, dans un univers clos, n’a pas de sens du point de vue d’internet. Tôt ou tard, cela conduit les mondes fermés à créer des passerelles vers le monde libre du web afin de profiter de la puissance induite par la capacité à créer des liens :
- les acteurs du monde des cdroms multimédia ont permis la création de liens vers les sites web,
- même chose pour les applications riches qui offraient la possibilité de créer des ponts vers le web,
- même chose encore pour les applications mobiles natives qui tentent de gommer le fossé entre une application mobile native et une application web.
Pour les cdroms multimédia, un lien vers un site web permettait de donner accès à un contenu plus riche et trop volumineux pour être stocké sur le cdrom, du fait de la limitation à environ 700 Mo de la capacité d’un cdrom. Il permettait aussi de donner accès à un contenu plus récent que celui présent sur le cdrom, révélant ainsi une faiblesse intrinsèque du média : un cdrom devient obsolète dès qu’il est publié du fait de l’impossibilité de mettre à jour le contenu. C’est la raison pour laquelle - en matière de multimédia - les successeurs du cdrom que sont les dvdrom et les blu-ray - malgré une capacité de stockage accrue - n’ont pas eu plus de succès que le cdrom.
Les applications riches s’exécutent généralement au sein d’un plugin du navigateur et ne sont donc pas des applications web à proprement parler. Cependant, comme les applications mobiles natives, elles évoluent généralement dans un contexte fortement lié à internet et au web. Comme elles ne peuvent généralement pas répondre à tous les besoins d’un utilisateur, il est tentant et techniquement facile d’ajouter un lien vers une ressource ou un service proposés par un site web.
Dans le cas des applications riches comme des applications mobiles natives, il est beaucoup plus délicat de créer le lien inverse : depuis un site web, vers une application riche ou une application mobile native. On voit ainsi qu’il est simple et facile de “basculer vers le web”, mais qu’il est beaucoup plus délicat de “sortir du web” pour aller vers un autre support.
En effet, le web repose sur un ensemble de standards libres et ouverts. Il est relativement simple d’évoluer dans le monde du web car il suffit de suivre les standards du web. En revanche, “sortir du web” nécessite des passerelles spécifiques et non standards, donc difficile à mettre en oeuvre à grande échelle pour une société qui n’agirait pas dans le cadre du W3C.
Cependant, même vainqueur, le web évolue aussi et a amorcé une transition depuis un web orienté document vers un web orienté application.
la transition d’un web orienté document vers un web orienté application
Avec l’avènement progressif de html5, css3 et javascript, le web est en train de passer d’une technologie orientée document à une technologie orientée application.
Mais avant de retracer l’histoire du web, survolons celles d’internet et de l’informatique. L’histoire de l’informatique n’est pas si ancienne mais elle est déjà longue de quelques décennies. Cette évolution a traversé différentes époques articulées autour de phases de rupture.
l’époque des mainframes
L’informatique a commencé à se développer au cours des années 1960, à l’époque des mainframes disponibles dans les universités et les grandes entreprises. Les mainframes sont des serveurs relativement puissants et utilisables par plusieurs utilisateurs simultanément par l’intermédiaire de terminaux informatiques. Ces terminaux sont de conception très simple : ils se résument généralement à un clavier et un écran (qui bien souvent ne peut afficher que du texte).
Le mainframe marque la première grande époque de l’architecture client-serveur. L’intelligence se trouve côté serveur, du côté du mainframe. Le client est le terminal informatique, un “bête” périphérique d’entrée/sortie (entrée pour le clavier, sortie pour l’écran). Les utilisateurs partagent les ressources du serveur par l’intermédiaire de leur terminal individuel.
l’avènement de l’informatique individuelle
Symbolisée par le l’IBM PC et surtout par Microsoft, l’informatique individuelle a commencé à se démocratiser au cours des années 1980. Elle est souvent associées aux systèmes d’exploitation MS-DOS et Windows qui sont installés sur un ordinateur personnel suffisamment puissant pour faire fonctionner le système d’exploitation et des applications, sans pour autant nécessiter de ressources distantes d’un mainframe.
Il est dépourvu de terminal informatique car l’utilisateur travaille directement sur l’ordinateur (toujours via un écran, un clavier et une souris). Comme le système d’exploitation est souvent mono-utilisateur (conçu pour être utilisé par une seule personne), cela n’aurait de toute façon pas grand sens de vouloir relier plusieurs terminaux informatiques à un ordinateur personnel.
L’informatique individuelle et l’ordinateur personnel renversent le paradigme des mainframes car ils suppriment le “centre intelligent” qu’étaient les mainframes et décentralisent cette intelligence dans chaque ordinateur personnel.
Les terminaux informatiques “idiots” sont remplacés par des ordinateurs personnels “intelligents” capables d’effectuer des traitements complexes sans recourir aux ressources d’un mainframe, donc sans nécessiter de capacité à fonctionner en réseau (pour communiquer avec le mainframe).
On peut d’ailleurs formuler l’hypothèse que la démocratisation rapide de l’informatique individuelle s’explique par l’absence d’un réseau capable de mettre à disposition de chacun des ressources informatiques distantes et mutualisées.
l’internet et les débuts du web
Les années 1990 ont vu la démocratisation progressive d’internet et les années 2000 ont vu son usage se généraliser. Avec internet, les ordinateurs personnels peuvent s’interconnecter à d’autres ordinateurs : des mainframes, des serveurs, d’autres ordinateurs personnels… C’est la conjugaison des deux paradigmes précédents : une informatique en réseau comme à l’époque des mainframes et une informatique distribuée comme lors du règne des ordinateurs personnels.
On aboutit donc à une informatique distribuée par le réseau, qui est une caractéristique majeure d’internet.
C’est dans ce contexte révolutionnaire que le web est inventé. Dès que les bases techniques sont en place, le web devient rapidement - avec le courrier électronique - une killer application de l’internet.
Les premiers navigateurs web sont rudimentaires et sont seulement capable d’afficher un rendu très simple des premières page web codées en html. C’est le début du web orienté document.
Le modèle d’interaction qui se généralise est celui où des ordinateurs personnels demandent des pages web à des ordinateurs dédiés qu’on commence alors à appeler des serveurs. Par conséquent, certains serveurs se spécialisent en serveurs web et sont destinés à servir (envoyer par le réseau) des pages web (du code html) aux ordinateurs personnels qui le leur ont demandé.
Internet est un réseau de réseaux. Techniquement, chaque ordinateur connecté dispose d’une adresse ip qui lui confère la capacité de communiquer avec tous les autres ordinateurs du réseau internet, quelle que soit sa localisation, et quel que soit le réseau auquel il est rattaché. Chaque noeud du réseau internet, chaque adresse ip, est techniquement équivalent aux autres noeuds : il n’y a pas de noeuds clients, ni de noeuds serveurs. Internet n’a pas de centre ni de hiérarchie, et c’est cette caractéristique qui lui confère sa robustesse.
Cette neutralité technique est bien résumée par Laurent Chemla dans un article qui retrace l’histoire d’internet depuis le contexte socio-culturel lors de sa conception jusqu’aux dangers qui le menace à l’heure actuelle.
TCP/IP est un langage de pair à pair : les notions de client et serveur sont applicatives, sur Internet, pas structurelles. Il n’y a pas de hiérarchie entre les ordinateurs qui sont reliés par le réseau : chacun peut, à tout instant, passer du récepteur au diffuseur sans avoir à obtenir d’autorisation préalable. Sur Internet, la prise de parole est possible partout, pour tous, tout le temps.
Paradoxalement, alors que l’architecture a-centrée d’internet conduisait naturellement à une informatique distribuée par le réseau, l’histoire du web conduit à revenir au modèle d’architecture du mainframe : une architecture client-serveur.
- le serveur web est le “centre intelligent” (l’équivalent du mainframe) qui génère la page web afin de l’envoyer à l’ordinateur personnel,
- le navigateur web de l’ordinateur personnel est le client, le “bête” terminal informatique qui ne s’occupe que du rendu graphique de la page web, de l’affichage.
L’intelligence a donc déserté l’ordinateur personnel (pourtant doté d’une capacité de traitement significative) pour retourner vers le serveur, le véritable “centre intelligent” du binôme.
le web à maturité
Même s’il s’est imposé pendant de longues années, le paradigme du web orienté document a rapidement montré ses limites : les interfaces web constituaient souvent une régression - tant du point de vue ergonomique que du point de vue des fonctionnalités - par rapport aux applications disponibles sur les ordinateurs personnels du paradigme de l’informatique individuelle.
Interfaces trop frustres, interactivité limité, ergonomie perfectible, latences réseau, complexité côté serveur : le paradigme du web n’était pas (encore) arrivé à maturité.
javascript
Les développeurs web ont tenté de dépasser les limitations des débuts du web, d’abord en ajoutant du javascript aux pages web. Le javascript est un type de code un peu particulier qui est envoyé au client par le serveur web en même temps que la page web en html et exécuté au sein du navigateur web du client (et non au sein du serveur web).
Avec un peu de code exécuté au sein du navigateur web, c’est un peu d’intelligence qui revient du côté du client.
ajax
Par la suite, les développeurs web ont fait preuve de beaucoup d’inventivité et ont combiné les technologies javascript et xml pour inventer l’architecture ajax. Cet assemblage de technologies permet au navigateur web de demander des petits bouts d’information au serveur web afin que le navigateur web puisse ne mettre à jour qu’une partie de la page web (sans avoir à redemander au serveur web la totalité de la page mise à jour).
De ce fait, le serveur web n’est plus capable de déterminer facilement la page web réellement affichée dans le navigateur web du client. Seul le navigateur web du client, qui a exécuté une partie des traitements, est en mesure d’effectuer le rendu de la page. C’est encore un peu plus d’intelligence qui revient du côté du client.
Le javascript comme la technologie ajax contribuent à éloigner le web moderne du modèle mainframe, ou du modèle des débuts du web. Le web tend petit à petit vers une réalité qui se rapproche de la vision de l’inventeur du web, Tim Berners-Lee, la vision d’une informatique distribuée par le réseau.
une architecture orientée service
Sur le web, l’architecture orientée document semble décliner et tend dorénavant à être supplantée par une architecture orientée service. En effet, les applications modernes comportent de plus en plus de traitements côté client (en javascript) sur le navigateur web, et l’architecture ajax simplifie d’autant les traitements côté serveur qui tendent à devenir de simples services typés REST.
Alors que dans les architectures web anciennes, l’ensemble des traitements se trouvent côté serveur, les architectures web modernes tendent à répartir les traitements entre le serveur et le client. Cela remet en cause les fondamentaux du modèle MVC et amène certaines personnes à prédire le déclin inéluctables des frameworks MVC (très adapté au web orienté document), au profit du modèle RVP.
- Dans le modèle MVC, le contrôleur reçoit les sollicitations (get ou post) du navigateur, modifie le modèle (les données) si nécessaire et récupère éventuellement de nouvelles données, puis invoque la vue pour générer la page à envoyer au navigateur (code html et css). Le contrôleur, le modèle et la vue font partie de l’application et se trouvent au sein du serveur.
- Dans le modèle RVP (version client side), la vue reçoit les événements de l’arbre DOM de la page html et fait suivre l’appel au présentateur si nécessaire. Le présentateur manipule les ressources du serveur puis met à jour la vue. Enfin, la vue met à jour l’arbre DOM. La vue, le présentateur et les ressources font partie de l’application, mais tandis que les ressources se situent au sein du serveur, la vue et le présentateur se trouvent au sein du navigateur du client (en javascript).
Dès lors, tout est en place pour une nouvelle génération d’applications web exécutées au sein du navigateur web, les applications se chargeant - non plus de récupérer des vues toutes faites sur le serveur - mais dorénavant de récupérer des ressources (au sens ressources du web) sur le serveur et de les manipuler. Ces opérations de manipulation passent par des services web typés REST basés sur les méthodes spécifiées par le protocole http : get, post, put, delete…
L’adoption de services typés REST permet de revenir aux fondamentaux du web : le protocole http est un protocole sans état (dit stateless). Alors que certains frameworks avaient pris le (mauvais) parti de tenter de simuler une connexion http stateful (dite avec état) par des mécanismes complexes de gestion de session client côté serveur (oui oui, vous avez bien lu), les acteurs du web semblent comprendre que la robustesse du web provient de la relative simplicité (voir rusticité) des protocoles sous-jacents.
Les architectures nouvelles s’orientent vers l’adoption des caractéristiques suivantes :
- côté client : une application riche (utilisant html5, css3 et javascript),
- un protocole rustique : une connexion http,
- côté serveur : des services simples (typés REST).
Le cloud computing a un rôle à jouer dans cet écosystème. Loin d’être indispensable, il reste cependant utile comme fournisseur d’API simples en façade de systèmes complexes, pour des usages tels que le stockage de données privées, les traitements exigeant une importante capacité de calcul (de type big data et mapreduce), la mise à disposition de contenus publics (commerciaux ou non), les plateformes de mise en relation…
Certains voient plus loin et imaginent des architectures sans serveur, des architectures totalement distribuées et a-centrées où une application exécutée sur le navigateur d’une personne peut communiquer avec un autre application exécutée sur le navigateur d’une autre personne. Le serveur devient dès lors facultatif, voir inutile, et on aboutit à une véritable architecture pair à pair. Cette véritable rupture est le cauchemar des fournisseurs de services qui deviendraient dès lors inutiles…
l’échec de java sur le web
Java avait déjà tenté d’investir le web lors de sa création. Java a été conçu pour s’exécuter dans une machine virtuelle java qui permettait au code compilé (le bytecode java) de s’exécuter indépendamment du système d’exploitation sous-jacent. L’exécution du code java dans la machine virtuelle java de l’ordinateur client était prévue pour être initiée par la visite d’une page web qui demandait au serveur d’envoyer une applet java au navigateur du client.
L’idée de départ était de diminuer la charge du serveur et la quantité de données transmises via le réseau, en déplaçant une partie des traitements sur l’ordinateur client. Malgré une idée intelligente, les applets java ont souffert de pré-requis techniques trop exigeants et de limitations techniques qui ont fortement limité le déploiement de ces architectures. On ne croise aujourd’hui plus aucune applet java sur le web et java a trouvé un nouveau débouché côté serveur, toujours dans une machine virtuelle java, mais pour un usage pour lequel java n’avait pas été conçu à l’origine.
Paradoxalement, javascript a parcouru le chemin inverse. Sous le nom de LiveScript, ce langage de script côté serveur devait assurer la supériorité du serveur web de Netscape. Renommé javascript pour souligner sa complémentarité avec java, il est intégré au navigateur Netscape Navigator et présenté dans un communiqué de presse de Netscape :
JavaScript is an easy-to-use object scripting language designed for creating live online applications that link together objects and resources on both clients and servers. While Java is used by programmers to create new objects and applets, JavaScript is designed for use by HTML page authors and enterprise application developers to dynamically script the behavior of objects running on either the client or the server. JavaScript is analogous to Visual Basic in that it can be used by people with little or no programming experience to quickly construct complex applications. JavaScript’s design represents the next generation of software designed specifically for the Internet.
Il avait à l’origine été conçu pour fonctionner en complémentarité avec java. Javascript devait constituer le liant, la colle entre le code html de la page et l’applet java. Javascript a été conçu pour permettre le développement d’applications centrées autour du réseau (“designed for creating network-centric applications”) en abrogeant la distinction entre le client et le serveur. Cette vision en avance sur son temps est en train de se concrétiser seulement maintenant… grâce à javascript et à des solutions comme node.js et Meteor.
Le paysage du web se modifie comme jamais. Les architectures traditionnelles n’ont plus le vent en poupe : la pile java JEE est souvent jugée trop complexe pour le web tandis que de nouveaux frameworks full stack apparaissent. Ces nouveaux frameworks révolutionnent l’existant pour proposer une solution technique nouvelle qui s’affranchit du passé : python et django, ruby et ruby on rails, java et play framework. Ces frameworks full stack proposent des solutions plus simples, comportant moins de couches (moins de mécanismes d’encapsulation et d’abstraction) et orientés vers l’agilité et la facilité de déploiement.
Mais tous ces langages, tous ces frameworks présentent le point commun d’être des solutions pour développer des applications côté serveur, dans l’ancien paradigme du web orienté document. Ils proposent certes parfois l’intégration de librairies javascript comme jquery. Mais la gestion de l’interface utilisateur relève souvent plutôt du bricolage, plus ou moins bien réalisé, plus ou moins simple d’usage.
D’autres frameworks comme GWT (et dans une moindre mesure wicket) ont fait le choix de générer eux-même le code javascript à intégrer à la page web envoyée au client. La simplicité apparente de ce type de solution a souvent commencé par séduire avant qu’elles n’apparaissent ensuite que comme des solutions temporaires visant à combler un manque. Aujourd’hui, les frameworks générateurs de code sont moins à la mode car leurs faiblesses sont mieux connues : manque de maîtrise sur le code généré, complexité grandissante de la solution qui superpose les couches techniques, difficulté à diagnostiquer les bugs. C’est ainsi que la pertinence de GWT commence à être remise en question.
javascript est désormais incontournable
Javascript devient le langage de prédilection du web, du fait de sa disponibilité sur tous les navigateurs sans nécessiter de plugin complémentaire. On peut certes fermer les yeux et nier cette réalité, mais javascript n’est plus un petit langage de bricolage, il est devenu un véritable langage complet qu’il convient de maîtriser pour développer des applications web modernes.
Si javascript est à l’honneur coté client, il pourrait également le devenir côté serveur, dans un soucis d’homogénéité de l’architecture et de simplicité de développement du code, qui pourrait dès lors être partagé entre le client et le serveur. C’est le pari que tentent de relever le serveur node.js et de nombreux frameworks javascript qui ambitionnent de permettre des applications web en temps réel :
- frameworks javascript orientés clients :
- frameworks javascript orientés serveur (basés sur node.js) :
- frameworks javascript orientés client et serveur :
Tous ces frameworks javascript gèrent à leur manière les interactions entre le javascript côté client et les services côté serveur. Certains distinguent le code serveur et le code client, souvent le code serveur est lui aussi en javascript, les plus novateurs abolissent la frontière entre le code client et le code serveur et conçoivent le client et le serveur comme un ensemble indissociable et où le code est réparti par le framework entre le client et le serveur.
Le point commun de tous ces frameworks reste l’usage intensif de html5 et css3 pour gérer la présentation et les interactions avec l’utilisateur dans le navigateur du client.
html5
Le retour en grâce du web est en grande partie dû au dynamisme de html5 qui - bien qu’étant un standard non encore finalisé - est d’ores et déjà utilisable. Il est déjà capable de concurrencer Flash au point que la société Adobe elle-même a avoué que 80 % des fonctionnalités de Flash sont réalisables avec html5 (lire l’article intitulé web technologies can do 80% of what flash can, Adobe says.
Cette bataille a commencé sur les smartphones, où la voracité énergétique de Flash a entraîné de sérieux doutes sur la pertinence d’intégrer Flash aux systèmes d’exploitation mobiles. Apple et son système iOS fermé a donné le ton dès la commercialisation de son premier iPhone en 2007 en ne mettant pas à disposition la technologie Flash sur l’iPhone. L’avenir lui a donné raison et on voit aujourd’hui que les applications natives et html ont conquis les smartphones sans que Flash ne soit plus réellement utile. Google et sa plateforme mobile Android ont suivi le mouvement et Flash n’est plus disponible pour Android depuis l’été 2012.
Evidemment, les voix des défenseurs de Flash ou de JEE vont continuer à s’élever pour défendre les technologies qu’ils maîtrisent, et c’est bien compréhensible : après avoir passé plusieurs mois ou plusieurs années à acquérir une expertise dans un domaine, après avoir consacré du temps et de l’argent pour suivre des formations, passer des certifications et des diplômes, il est difficile pour eux de voir leur technologie de prédilection remise en question. A travers la remise en cause de cette technologie, c’est leur propre expertise qui est remise en cause.
Mais les développeurs expérimentés familiers d’une plateforme ou d’une technologie ne devraient pas avoir peur du succès des autres plateformes et des autres technologies, ils devraient au contraire s’y aventurer en confiance. En effet, le meilleur de leurs compétences sont applicables aux autres environnements techniques comme l’affirme cet article qui traite des développeurs web :
So, experienced developer-friends who are already intimately familiar with one platform: fear not; the best of your skills are transferrable.
Ces développeurs expérimentés ont donc tout à gagner à appréhender au plus tôt les technologies de demain afin d’anticiper les évolutions technologiques.
application mobile native ou application web ?
On peut certes se demander qui des applications mobiles natives ou des applications web prendra le dessus, mais il ne faut pas perdre de vue que l’essentiel n’est pas là. La rupture majeure à prendre en compte est la fin d’un modèle où le serveur central est érigé en maître absolu de l’application. Le pouvoir passe maintenant aux applications exécutées dans le terminal de l’utilisateur (application native) ou dans le navigateur (application web).
Mais force est de reconnaître que html5 présente de sérieux atouts faces aux applications natives. L’article intitulé mobile web versus mobile apps) établi un comparatif entre les applications web et les applications natives, au large désavantage des applications natives :
- portabilité naturelle de l’application web sur tout type de terminaux disposant d’un navigateur web,
- disponibilité de l’application web chez tous les possesseurs d’un navigateur web, indépendamment du type de terminal,
- l’application web tire parti de la puissance des liens hypertexte,
- découvrabilité de l’application web via internet et les moteurs de recherche (sans nécessité d’exécuter une recherche sur un appstore particulier),
- inutile d’installer une application web, se connecter au site web est suffisant,
- inutile de mettre à jour l’application web, se connecter au site web est suffisant,
- indépendance vis-à-vis des appstores et de leurs règles de censure,
- pas de coût à l’entrée (comme c’est le cas avec les appstores),
- pas de partage des revenus (comme c’est le cas avec les appstores),
Ces raisons incitent à prédire un brillant avenir au html5 sur les smartphones.
Si les applications web viennent marcher sur les plates-bandes des applications mobiles natives des smartphones, elles devraient également s’étendre à d’autres terminaux, mobiles ou non. En effet, la surface de déploiement du trinôme html5 + css3 + javascript est en train de s’étendre de manière significative avec le support natif de ces technologies par des systèmes d’exploitation majeurs et des applications populaires :
- la dernière version d’Ubuntu propose d’accéder aux applications web (comme gmail) de la même manière qu’aux applications natives,
- l’environnement de bureau Gnome Shell est extensible par le biais d’extension écrites en javascript,
- l’environnement de bureau KDE propose de développer des plasmoids (des extensions) en javascript,
- Windows 8 propose de développer des interfaces en utilisant les technologies html5, css3 et javascript,
- l’interface d’iTunes est basée sur html5.
Souhaitant pousser le concept aux extrêmes, certains systèmes d’exploitation proposent même html5 comme technologie de base pour développer des applications. Tout le système d’exploitation est alors architecturé autour du web. C’est le cas de HP webOS développé par Palm, puis racheté par HP qui l’a ensuite arrêté avec la fermeture de sa ligne de produit tablettes, pour le libérer ensuite sous le nom de Open webOS.
Firefox OS
Mozilla, ardent défenseur du web depuis ses débuts, propose l’approche la plus novatrice en ce domaine en développement un système d’exploitation complet visant à placer le web au coeur même du système d’exploitation : Firefox OS.
Firefox OS est un système d’exploitation littéralement basé sur les technologies du web que sont html3, css3 et javascript : l’interface graphique avec laquelle interagit l’utilisateur est un site web, chaque écran se trouve être une véritable page web. Firefox OS constitue une alternative crédible aux systèmes d’exploitation Android de Google et iOS d’Apple en proposant une alternative libre qui permet :
- aux utilisateurs technophiles de maîtriser le code exécuté sur leur terminal (en installant et administrant eux-même Firefox OS sur leur terminal),
- aux opérateurs télécom de rétablir le lien avec leurs abonnés en procédant à une désintermédiation (comme Orange qui annonce se recentrer sur son métier d’opérateur de réseau).
Un support d’une présentation par Mozilla vous donnera un aperçu de Firefox OS.
conclusion
En conclusion, nous sommes à l’aube d’une nouvelle ère de l’informatique, d’internet et du web : nouvelles technologies, nouvelles architectures, nouveau paradigme.
Il y a ceux qui s’aventure avec enthousiasme dans ce nouvel univers, et ceux qui ont peur de javascript.
Au sujet de l’adaptabilité des espèces et de leur longévité, Darwin avait un point de vue intéressant :
Ce n’est pas la plus forte des espèces qui survit, ni la plus intelligente. C’est celle qui est la plus adaptable au changement.
Mais comme la peur (de javascript) ne supprime pas le danger (de l’immobilisme), à chacun de choisir s’il préfère considérer le trinôme html5 + css3 + javascript comme une opportunité ou comme une menace. S’adapter au changement et en tirer parti, ou préférer l’immobilisme et espérer survivre, voilà le dilemme qui secoue le web actuellement.