Étiquette : webkit

La deuxième guerre des navigateurs est-elle déjà terminée ?

Entre 1997 et 2002, la première guerre des navigateurs a eu lieu, et le résultat fût simple : Microsoft ayant encastré au maximum Internet Explorer dans les différentes versions de son MS-Windows 98 (avec Internet Explorer 4.01), 98Se et 2000 (avec Internet Explorer 5.0), Millenium (avec Internet Explorer 5.5) et XP (avec Internet Explorer 6.0) que les autres navigateurs internet ne pouvaient qu’être lentement vidés de leur sang. Je sais qu’il y a eu des projets comme 98lite pour enlever Internet Explorer, mais cela n’a pas vraiment changé la donne au final.

En 2002, Internet Explorer (sous ses diverses variantes) mangeait à lui seul plus de 90% des parts de marché des navigateurs internet. Ce n’est pas le tout jeune projet Mozilla (à l’époque une suite avec un client courrier et un éditeur de pages web) qui pouvait lutter. La sortie de Mozilla Firefox 1.0 en 2004 força Microsoft à ouvrir un oeil et faire renaître de ses cendres son navigateur internet et mettre près de deux ans à proposer Internet Explorer 7 sorti à peu près en même temps qu’un certain MS-Windows Vista.

Entre 2004 et 2008, Mozilla Firefox a eu les coudées franches pour croître en terme de parts de marché. Aucune concurrence sérieuse n’existait pour ralentir sa croissance. Mais en 2008, Google sort son navigateur, Chrome. Sur un graphique de StatCounter au niveau mondial qui montre les évolutions entre décembre 2008 et janvier 2016, on voit que le pic de Mozilla Firefox, c’est en novembre 2009 (31,82%). En janvier 2016, Mozilla Firefox arrive difficilement à 9,1%. Google Chrome ? 47,82%.

Continuer la lecture de « La deuxième guerre des navigateurs est-elle déjà terminée ? »

Une lame de fond de rationalisation dans le petit monde des navigateurs web ?

L’info est presque passée inaperçue, mais le projet Camino, un navigateur pour Apple MacOS-X et qui prenait comme base le moteur de rendu de Mozilla Firefox a été arrêté fin mai 2013.

J’avais jadis utilisé une des premières versions quasiment finale de ce navigateur, en décembre 2005.

Il prenait le moteur de rendu de Mozilla Firefox de l’époque (donc de Mozilla 2.0.0.x à l’époque) en proposant une interface en Cocoa pour qu’elle soit plus jolie à l’affichage. Avec Camino, c’est un peu de diversité qui disparait, et en cela, c’est un autre exemple de la rationalisation croissante du marché des navigateurs annoncées avec l’abandon du moteur de rendu Presto par Opera pour prendre le moteur « nouvelle génération » de Chromium, Blink. Même si les retours sur la première béta, donc loin d’être finalisée, d’Opera 15 ne sont pas très positifs pour les utilisateurs de longue date du navigateur norvégien.

J’avais déjà évoqué dans un billet en février 2013 le retour à 2002 en terme de variété de navigateurs.

Et il faut être réaliste. Il ne reste plus qu’un trio de moteurs de rendu : Trident (Internet Explorer), Webkit / Blink (Safari, Chrom(ium)e, Opera, Midori, Epiphany, Rekonq, uzbl, iCab, Omniweb), Gecko (Mozilla Firefox).

Il ne faut pas oublier la tripotée de pseudo-navigateurs sous MS Windows comme Avant Browser, Maxthon, Slim Browser, etc… Qui n’apporte aucune réelle diversité, un peu à l’image des MVNOs pour la téléphonie mobile qui ne sont que des loueurs de matériels du quatuor Orange, SFR, Bouygues Telecom, Free Mobile (même si Free Mobile ne supporte aucun MVNOs).

Du côté des développeurs de sites, ce doit être agréable, mais cela risque de développer une nouvelle forme de monoculture, remplaçant celle du « Internet Explorer uniquement » au « Webkit uniquement ». Ce qui au final n’est pas forcément mieux 🙁

Cf le coup de gueule de Daniel Glazmann en ce qui concerne le web mobile, qui date de 2012 et qui est toujours d’actualité…

En vrac’ rapide et libre de fin de semaine.

Etant donné que je ne compte rien publier avant lundi prochain, un petit en vrac’ pour finir la semaine.

Voila, c’était court, mais j’ai pas mal de pain sur la planche avec un projet personnel qui me tient à coeur depuis près de 15 ans… Mais je n’en dirais pas plus pour le moment 😀

Vers une monoculture des moteurs de rendus dans les navigateurs internet ? Welcome back, 2002 !

L’annonce est officielle sur le blog des relations publiques d’Opera, le petit navigateur scandinave : Webkit sera bientôt le moteur de rendu officiel de la gamme des navigateurs proposés.

La raison principale invoquée pour le changement de moteur, c’est que celui-ci est le moteur idéal quand le projet Opera a été lancé, et que les innovations introduites au fil des années par le projet sont maintenant reprises partout, dixit l’article :

The WebKit project now has the kind of standards support that we could only dream of when our work began. Instead of tying up resources duplicating what’s already implemented in WebKit, we can focus on innovation to make a better browser. Opera innovations such as tabbed browsing, Speed Dial and data-saving compression that speeds up page-load, have been widely copied and improved the web for all.

Même si je n’ai pas toujours eu des relations très détendues avec Opera, je me demandais quand Opera passerait à l’opensource. Je pensais bien entendu à l’ouverture de Presto, pas à un passage vers WebKit qui est un moteur de rendu libre, sauf erreur grossière de ma part.

Continuer la lecture de « Vers une monoculture des moteurs de rendus dans les navigateurs internet ? Welcome back, 2002 ! »

Ubumonkey : où comment faire croire qu’un enrobage de webkit donne un nouveau navigateur.

J’ai lu sur le blog de Clapico l’annonce d’un nouveau navigateur, Ubumonkey, codé en RealBasic. Outre le fait que RealBasic soit tout sauf un langage de programmation libre, j’ai eu un doute.

Car je ne connais pas 36 moteurs de rendu fonctionnant aussi bien avec Windows, que MacOS-X et Linux : deux libres (webkit et gecko) et un non-libre (presto)

J’ai donc installé une machine virtuelle contenant une ubuntu 10.10 32 bits, avec les mises à jour, puis j’ai récupéré le paquet .deb qui va bien.

100% à Acid3 ?

Pour éliminer un enrobage de gecko, j’ai lancé le test acid3. Un résultat parfait (100/100) me fait donc éliminer gecko. Reste Presto et Webkit.

Je suis donc allé sur le site de la CNIL, puis en cliquant sur le lien « vos traces », j’ai lancé le test pour identifier le moteur utilisé… Et la réponse me confirme mon soupçon : Safari, en clair le moteur webkit.

Webkit inside !

Donc, je viens à me poser une simple question : peut-on considérer qu’un enrobage d’un moteur de rendu est un nouveau navigateur à part entière ? Surtout que la page officielle du site est muette sur ce point…

Et question subsidiaire : peut-on utiliser un logiciel non-libre comme RealBasic pour écrire un logiciel sous GPL v3 ?

 

 

v8 ou Nitro… Lequel des deux est le plus rapide et le plus respectueux de JavaScript et de ses normes ?

Dans un article récent, je parlais du progrès fait par la pré-beta5 de Mozilla Firefox 4.0, alias Minefield.

J’ai voulu voir où en était les deux autres grands noms des moteurs de rendu du logiciel libre, à savoir Chromium (et son moteur de Javascript v8), et Webkit (et son moteur de Javascript Nitro).

J’ai donc fait compilé les deux via AUR, aussi bien pour chromium-browser-svn et webkitgtk-svn. En sachant que pour le second, je ne l’ai pas installé, histoire d’éviter des conflits avec les logiciels de ma machine.

La compilation du code source de Chromium demande pas mal d’espace… 4,5 Go environ…


[fred@fredo-arch chromium-browser-svn]$ pwd
/home/fred/download/chromium-browser-svn
[fred@fredo-arch chromium-browser-svn]$ du -sh src/
4,5G src/

Webkit est quant à lui, largement moins gourmand : à peine 720 Mo.


[fred@fredo-arch webkitgtk-svn]$ pwd
/home/fred/download/webkitgtk-svn
[fred@fredo-arch webkitgtk-svn]$ du -sh src/
722M src/

Une fois les deux logiciels compilés, j’ai utilisé v8 benchmark, sputnik (pour vérifier le niveau de compatibilité avec les normes définies du langage javascript), et html5test, pour finir, histoire de voir le niveau d’avancement de ce nouveau standard du langage html.

Chromium, qui se définit comme une version 7.0.501 (7ième version, déjà, en l’espace de quoi, deux ans ?), explose largement le score au niveau du Javascript… 4961 points, soit 4,45 fois plus rapide que Mozilla Firefox 4.0b5pre… Autant dire que la Fondation Mozilla a de la marge.

Score de v8 avec Chromium

Coté respect des normes javascript, le score est plutôt bon : 5109/5246, soit un niveau de respect de… 97,38%.

Score de Sputnik avec Chromium

Enfin, en ce qui concerne html5test, Chromium fait mieux que Mozilla Firefox, avec un score de 222 points et 10 points de bonus.

Score de html5test avec Chromium

En ce qui concerne Webkit, j’ai utilisé l’outil GtkLauncher, qui offre une interface basique pour Webkit.

[fred@fredo-arch Programs]$ pwd
/homefred/download/webkitgtk-svn/src/webkit-build/Programs
[fred@fredo-arch Programs]$ ./GtkLauncher &

Le score du moteur de Javascript bien que moindre que celui de v8 reste honorable : 2984 points au benchmark v8, soit 2,67 fois le score de Mozilla Firefox 4.0b5pre. On comprend pourquoi la Fondation Mozilla veut intégrer Nitro dans son code source 😉

Score de v8 avec Webkit

Coté sputnik, le score est vraiment bon : 5069/5246, soit un niveau de respect de 96,62%

Score de Sputnik avec Webkit

Enfin, en ce qui concerne html5, le score est inférieur à celui de Mozilla Firefox et de Chromium, avec seulement 195 points et 12 points de bonus.

Score de html5test avec Webkit

J’allais oublier, le score de Mozilla Firefox 4.0b5pre pour sputnik : 4978/5246, soit un niveau de respect de 94,89%

Score de Sputnik avec Mozilla Firefox 4.0b5pre

Mis à part la vitesse d’exécution, le respect du html5 et des normes javascript sont une marque de fabrique de moteurs de rendu libre. Les moteurs de rendus non-libre ? Je ne saurais dire, je ne les utilise pas 😉

html5test… Où en sont les navigateurs avec cette nouvelle version du test ?

Puisque la course à la vitesse à l’interprétation du JavaScript approche de son apogée (cf les 35% de vitesse en plus annoncé par Google Chrome 5) et que bientôt le Javascript sera interprêté avant même le chargement de la page, passons à un autre test : celui concernant le degré d’implémentation des normes HTML5, même si celles-ci sont encore à l’état de brouillon.

Le test se trouve sur la page http://www.html5test.com/

J’en avais déjà parlé le 24 mai dernier, mais comme une nouvelle version est sortie entre temps, j’en reparle 😉

Le résultat est désormais sur 300 points, et est donc largement plus exaustif. De plus, il y a des points bonus attribués dans certains catégories.

Pour le test, je vais montrer les résultats obtenus par :

Et dans une machine virtuelle – Oracle Virtualbox 3.2.4 car Qemu n’arrivait pas à installer Windows XP ?! – contenant un MS-Windows XP-Sp3 à jour :

Continuer la lecture de « html5test… Où en sont les navigateurs avec cette nouvelle version du test ? »

Chromium, soit. Mais quid de Midori ?

Midori – en dehors de devenir le navigateur de l’environnement Xfce – partage le même coeur de rendu de pages Web, à savoir webkit. En dehors du fait que Chromium n’existe qu’en version 32 bits (pas de version native 64 bits), j’ai voulu voir les différences… Et si Chromium est finalement si intéressant que cela.

Dans ce but, j’ai installé dans une ArchLinux 64 bits dans une machine virtuelle kvm un environnement Xfce 4.6.1 avec la dernière version en date de Midori, la 0.1.7.

En dehors du fait de passer sans aucun problème Acid3, le score obtenu par Midori sur la 4ième version du test de rapidité du moteur V8 de Google Chrome. En effet, le score obtenu est de 871 points.

Chromium, une fois toutes les dépendances 32 bits installées, obtient un score de… 1025 points seulement… 17,68% plus rapide. Le moteur de JS v8 ne serait donc pas rapide que cela ?

D’ailleurs, le test acid3 est passé par Chrome, mais de manière imparfaite. Donc, on peut faire tout un tapage sur Chromium, mais il risque de fermer sa bouche bientôt sur Linux par rapport à Midori…

Maintenant, il est sûr que la puissance de frappe commerciale de Google est largement supérieure à celle de Midori et de ses développeurs…

SquirrelFish extreme, le moteur javascript « dopé à l’EPO » ?

Récemment annoncé sur le blog des développeurs de Webkit, cette nouvelle version du moteur Javascript est encore plus rapide.

Bien qu’officiellement encore limité au 32 bits, je cite « Currently the code is limited to x86 32-bit, but we plan to refactor and add support for more CPU architectures. », « Actuellement le code est limité à du 32 bits en x86, mais nous comptons le refactoriser et ajouter plus d’architectures de microprocesseurs« , les gains sont déjà visibles.

Continuer la lecture de « SquirrelFish extreme, le moteur javascript « dopé à l’EPO » ? »

Lequel est le plus rapide pour Javascript ? Webkit, Opera ou Gecko ?

Pour le savoir, il faut utiliser deux tests complémentaires : le test du site CelticKane et le test « SunSpider« .

Les versions testées sont :

  • une compilation nocturne de Shiretoko pré-alpha2 de ce 13 août matin => Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1a2pre) Gecko/20080813050659 Minefield/3.1a2pre
  • Une préversion d’Opera 9.52, cf ce billet du blog des développeurs d’Opera.
  • Webkit révision 35706, compilée ce matin, pour contourner le bogue 20370 qui rendait impossible la compilation de la version gtk.

Continuer la lecture de « Lequel est le plus rapide pour Javascript ? Webkit, Opera ou Gecko ? »