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 ? »

Webkit-gtk : Acid3 est presque passé ? :)

Je me suis basé sur la révision 31787 de WebKit-Gtk pour rédiger cet article. Après avoir lancé une compilation en activant le support du SVG – avec un ./configure --enable-svg-experimental – puis une fois la compilation terminée avec le programme de test GtkLauncher.

Si au premier passage, le test n’est pas passé, au second lancement, celui-ci se lance, donnant un résultat presque parfait, n’affichant qu’une erreur : « Linktest failed ».

Webkit r31387 sous Ubuntu Hardy Heron AMD64.

Au moins, cela laisse de l’espoir pour le futur d’Epiphany, dont la version 2.24.x (en clair, celle qui sortira avec Gnome 2.24 en septembre prochain) d’utiliser WebKit sans gros problème de rendu.

Acid3 : WebKit et Opera vainqueur « ex-aequo » ?

En l’espace de quelques heures, les équipes d’Opera et de Safari ont annoncé passé officiellement la totalité du test Acid3.

Webkit l’annonce en grande pompe :

With r31342 WebKit has become the first publicly available rendering engine to achieve 100/100 on Acid3. The final test, test 79, was a brutal torture test of SVG text rendering. Details of the bugs we fixed will follow. Indeed, we found a critical bug in the test itself that would have forced a violation of the SVG 1.1 standard to pass, so until a few hours ago it was not possible to get a valid 100/100. Acid3 test editor Ian Hickson has the details.[…]

Ce qui donne traduit :

Avec la révision 31342, Webkit a été le premier moteur de rendu disponible à atteindre les 100/100 sur Acid3. Le test final, le 79, était une torture brutale du rendu d’un texte en SVG. Le détail des bogues corrigés suivra. En effet, nous avons vu un bogue critique dans le test lui-même qui aurait forcé une transgression de la norme SVG 1.1 pour son passage, donc jusqu’il y a quelques heures il était impossible d’atteindre les 100/100. Le créateur du test Acid3, Ian Hickson a les détails.[…]

Pour être complet, des ajouts ont été faits pour rendre le passage « plus valide », et un autre annonçant qu’avec la révision 31356, la versions Windows est disponible.

Opera de son coté, a fait l’annonce aussi. Mais avec une subtilité intéressante ; l’annonce du passage est intéressante à lire :

Today we reached a 100% pass rate for the first time! There are some remaining issues yet to be fixed, but we hope to have those sorted out shortly.

We will release a technical preview version on labs.opera.com within the next week or so. For now, the screenshot above shows the Acid3 test as rendered in our latest WinGogi Desktop build. WinGogi is the Windows version of our reference builds used for the internal testing of Opera’s platform independent Core.

Ce qui donne traduit :

Aujourd’hui, nous avons atteint le score de 100% pour la première fois. Il reste quelques problèmes à corriger, mais nous espérons faire cela rapidement.

Nous publierons une version technique d’aperçu (Note du traducteur : une version alpha, donc) sur labs.opera.com d’ici la semaine prochaine environ. Pour le moment, la capture d’écran montre le test Acid3 affichée dans la dernière compilation de WinGogi Desktop. WinGogi est la versions Windows de nos compilations de référence utilisée pour les tests internes sur la plateforme Opera.

Donc, les deux déclarent passer le test Acid3, et un seul mot : félicitations. Cependant, dans un cas, on peut vérifier les dires avec une compilation téléchargeable, et sur l’autre, uniquement un communiqué.

Etant comme un certain apôtre, je ne crois que ce que je vois… Seul l’avenir nous dira quel sera le premier moteur STABILISÉ et donc rendu grand public qui passera Acid3. Je maintiens mon pronostic pour Safari et donc Webkit. Mais je peux aussi me tromper… Seul l’avenir nous le dira !

Webkit : des résultats acid3 variables ?!

Certaines remarques sur le score passé par WebKit (la version de développement du moteur de rendu du navigateur d’Apple, à savoir Safari, logiciel libre) m’ont fait me poser des questions.

Un score de 95% (étant donné qu’il y a 100 « sous »-tests dans le test) pour une nocturne récente de la version MacOS du moteur, des versions très récentes (révision 31108 pour Windows et 31107 pour linux) donne des scores inférieurs quoique proche.

La seule différence entre les deux révisions datées d’hier ? Un bug de compilation sous Windows.

Révision 31108 sous Windows : 94%

94% avec Webkit pour Windows

Révision 31107 sous Linux : 90%

90% avec Webkit pour Linux

4 tests passés sous la versions Windows bloquent avec la version linux. Etrange, étant donné que c’est le MÊME code source utilisé pour le moteur sur les 3 plateformes. Et pourtant, je ne fais que suivre les infos proposées pour la compilation du code. L’utilisation d’autres options faisant planter la compilation avant son terme ! 🙁

J’avoue y perdre le peu de latin que j’ai jamais acquis. Des idées ?!

En tout cas, le score s’approcherait du mythique 100%, du moins si on en croit ce billet du blog des développeurs de Webkit…

Petit point sur Acid3 – Webkit… Le champion toute catégories ? ;)

Ce billet complète le précédent. J’ai pu compiler sans trop de problème la révision 30885 du moteur Webkit, et les résultats sont explosifs… 87/100 !!!

Webkit sous Acid3...

Pour compiler le moteur Webkit, je me suis basé sur cette page : http://trac.webkit.org/projects/webkit/wiki/BuildingGtk. Le code source étant récupérable sur cette page : http://nightly.webkit.org/

A noter que le support du svg soit désactivé… En effet, voici ce que donne le bilan de la commande ./autogen.sh :

Build configuration:
Enable debugging (slow) : no
Code coverage support : no
HTTP backend : curl
Optimized memory allocator : yes
Features:
HTML5 cross-document messaging : yes
HTML5 client-side storage support : yes
HTML5 video element support : no
Icon database support : no
SVG support : no
SVG animation support : no
SVG filters support : no
SVG fonts support : no
SVG foreign object support : no
SVG as image support : no
SVG use element support : no
XPATH support : yes
XSLT support : yes
GTK+ configuration:
GDK target : x11
Hildon UI extensions : no

Quoiqu’il en soit, il semble être certains que la future version stable de Webkit passera lui aussi le test acid3… Du moins, c’est bien parti pour 😉