Servo : le futur des moteurs de rendu web par Mozilla
Basé sur Rust et axé sur le parallélisme

Le , par Arsene Newman, Expert éminent sénior
Durant le récent FOSDEM 2014, Mozilla a laissé filtrer des détails sur son futur moteur de rendu web, fruit d'une collaboration avec Samsung. Baptisé Servo, il a été longuement présenté par Josh Matthews, ingénieur au sein de la fondation. Servo diffère sensiblement des précédents et actuels moteurs de rendu sur plusieurs points.

Premier constat, son développement a été axé sur la mobilité, le parallélisme et une exécution sur des processeurs multi-cœurs, alors que les moteurs utilisés actuellement sont basés sur une architecture datant des années 2000, époque où des processeurs multi-cœurs n'étaient pas encore à l'ordre du jour. De plus, Servo sera adapté pour s’exécuter sous Android et sur des appareils basés sur des processeurs ARM. Ainsi, les développeurs espèrent améliorer grandement les performances à la fois d’exécution et d'autonomie, car un processeur mono-coeur surchargé consommerait plus d'électricité que plusieurs processeurs moins chargés.

Autres points marquants, il est écrit avec le fameux langage Rust, lui-même issu de la fondation, son utilisation permet d’éliminer les failles de sécurité et les bugs rencontrés actuellement sous le moteur Gecko qui est développé en C++. En outre, Matthews a évoqué la possibilité d’exécuter du code en langage C, réputé pour ses performances, grâce à l'intégration de la sandbox NaCL de Google. A terme, son utilisation pourrait donner une surcouche de protection.

Pour finir, Mattews a invité la communauté à participer activement à ce projet, en détaillant d’ailleurs certaines tâches qui restent à faire pour permettre de finaliser le développement de Servo comme : l’implémentation de certaines APIs relatives au DOM, l'implémentation de certaines fonctionnalités CSS ainsi que le portage du moteur sous Windows.

Source : Présentation de Josh Mattews

Et vous ?

Qu’en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 26/02/2014 à 11:22
Citation Envoyé par Arsene Newman  Voir le message
En outre, Matthews a évoqué la possibilité d’exécuter du code en langage C, réputé pour ses performances, grâce à l'intégration de la sandbox NaCL de Google.

Formidable ! Si NaCl vient à se généraliser, alors peut-être éviterons-nous un futur 100% javascript. Entre Canvas et NaCl nous aurions tout ce qu'il faut pour faire des applis web totalement libérées de html et javascript.

EDIT : ceci n'est pas contre JS, je me réjouis simplement de pouvoir à nouveau choisir le langage que nous voulons et sans sacrifier les perfs.
Avatar de Traroth2 Traroth2 - Expert éminent sénior https://www.developpez.com
le 26/02/2014 à 13:25
@DonQuiche : si tu penses que Javascript est un mauvais langage, je ne peux que te conseiller de revenir y jeter un coup d'oeil. Il est possible que tu ais encore des conceptions héritées du début des années 2000, qui sont totalement dépassées aujourd'hui. De nos jours, Javascript est un des langages les plus puissants disponibles.
Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 26/02/2014 à 13:36
Citation Envoyé par Traroth2  Voir le message
@DonQuiche : si tu penses que Javascript est un mauvais langage

Je pense simplement qu'il n'est pas adapté pour tout, qu'il serait nuisible qu'il devienne une lingua franca indépassable, et que nous devrions tous pouvoir choisir.
Je suis convaincu que dans quelques décennies nous regarderons cette période où JS était le seul choix possible comme la préhistoire des applis web.
Et NaCl est le meilleur choix disponible pour en sortir.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 26/02/2014 à 15:17
Citation Envoyé par DonQuiche  Voir le message
Formidable ! Si NaCl vient à se généraliser, alors peut-être éviterons-nous un futur 100% javascript. Entre Canvas et NaCl nous aurions tout ce qu'il faut pour faire des applis web totalement libérées de html et javascript.

Attention, Servo ne prévoit absolument rien à propos de NaCl. Il ont juste dit que ca pouvait éventuelement être envisagé. La position générale chez Mozilla n'étant pas du tout en faveur de NaCl, il y a peu de chance que ça arrive, et même si c'était la Cas Servo a des millions de problèmes plus urgent a régler que celui là.

Citation Envoyé par DonQuiche  Voir le message
@DonQuiche : si tu penses que Javascript est un mauvais langage, je ne peux que te conseiller de revenir y jeter un coup d'oeil. Il est possible que tu ais encore des conceptions héritées du début des années 2000, qui sont totalement dépassées aujourd'hui. De nos jours, Javascript est un des langages les plus puissants disponibles.

La notion de puissance étant terriblement vague, elle ne veut juste rien dire. La tendance générale que je constate est que plus on me présente un langage comme puissant, moins il est efficace, car les concepts avancés ont le plus souvent un cout.
Je ne nie pas que JavaScript a des avantage, mais il a aussi de nombreuses tares qui font que ce n'est certainement pas le meilleur langage a tout faire qui puisse exister.

Citation Envoyé par DonQuiche  Voir le message
Et NaCl est le meilleur choix disponible pour en sortir.

Je suis totalement d'accord sur ton constat, mais absolument pas d'accord sur ta conclusion :NaCl est pour moi la pire solution si l'on souhaite conserver l'universalité du web, vu qu'il rend les sites dépendant de l'architecture du matériel.
pNaCl et asm.js sont des solutions plus valides dans mais chacune d'elles a aussi des lacunes (pas de normalisation pour la première et héritage javascript pour la seconde).

De toute façon Servo est encore bien loin de se soucier de ce genre de problème : leur soucis en ce moment c'est d'implémenter la gestion des tables et de s'améliorer sur le test acid 2. et de toute façon, il ne prétend pas y répondre.
Le principal but de Servo, c'est surtout de voir comment faire un rendu en utilisant au mieux les capacité de parallélisation des processeur modernes.
Avatar de Traroth2 Traroth2 - Expert éminent sénior https://www.developpez.com
le 26/02/2014 à 15:26
Citation Envoyé par DonQuiche  Voir le message
Je pense simplement qu'il n'est pas adapté pour tout, qu'il serait nuisible qu'il devienne une lingua franca indépassable, et que nous devrions tous pouvoir choisir.
Je suis convaincu que dans quelques décennies nous regarderons cette période où JS était le seul choix possible comme la préhistoire des applis web.
Et NaCl est le meilleur choix disponible pour en sortir.

Dans ce cas, nous sommes bien d'accord.
Avatar de Traroth2 Traroth2 - Expert éminent sénior https://www.developpez.com
le 26/02/2014 à 15:35
Citation Envoyé par Uther  Voir le message

La notion de puissance étant terriblement vague, elle ne veut juste rien dire. La tendance générale que je constate est que plus on me présente un langage comme puissant, moins il est efficace, car les concepts avancés ont le plus souvent un cout.
Je ne nie pas que JavaScript a des avantage, mais il a aussi de nombreuses tares qui font que ce n'est certainement pas le meilleur langage a tout faire qui puisse exister.

Dans ce cas, disons plutôt "productif". Et je n'ai jamais dit que Javascript est un "langage à tout faire". Je ne le pense pas, d'ailleurs. Même s'il est possible de presque tout faire avec la plupart des langages, il y a des choix de langage qui sont meilleurs que d'autres pour un problème donné. Et je ne pense pas que ça changera prochainement. La notion de langage à tout faire me parait donc à peu près aussi floue que celle de langage puissant...

En réalité, tout langage est basé sur des abstractions. Et des abstractions permettant de faire simplement des choses complexes, voila pour moi la définition de la puissance.

Le fait que Javascript a conservé de ses débuts une réputation exécrable de langage mal repompé sur Java et ne fournissant que peu de fonctionnalités et peu d'outils. Cette réputation n'est plus du tout méritée. Les closures, l'orienté objet par prototypes et les timers sont des fonctionnalités qui offrent des possibilités dont on ne peut malheureusement que rêver en Java pour l'instant. Les outils de développement sont plutôt bons, même si on pourrait encore faire des progrès dans ce domaine. Et les frameworks commencent à poser les mêmes problèmes d'embarras du choix qu'avec Java.
Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 26/02/2014 à 15:47
Citation Envoyé par Uther  Voir le message
Attention, Servo ne prévoit absolument rien à propos de NaCl. Il ont juste dit que ca pouvait éventuelement être envisagé. La position générale chez Mozilla n'étant pas du tout en faveur de NaCl, il y a peu de chance que ça arrive, et même si c'était la Cas Servo a des millions de problèmes plus urgent a régler que celui là.

Ertf, tu me vois vraiment désolé de l'apprendre.

Citation Envoyé par Uther  Voir le message
Je suis totalement d'accord sur ton constat, mais absolument pas d'accord sur ta conclusion :NaCl est pour moi la pire solution si l'on souhaite conserver l'universalité du web, vu qu'il rend les sites dépendant de l'architecture du matériel.
pNaCl et asm.js sont des solutions plus valides dans mais chacune d'elles a aussi des lacunes (pas de normalisation pour la première et héritage javascript pour la seconde).

Initialement je penchais plutôt vers asm.js. Malheureusement il reste plus lourd à compiler (il faut reparser, identifier correctement asm.js, etc) et, surtout, à transporter puisqu'il produit des pages très lourdes (plusieurs dizaines de fois le poids d'un binaire natif).

Cela dit je ne comprends pas ton affirmation selon laquelle NaCl rendrait les sites dépendant de l'architecture : tout comme les instructions de asm.js le bytecode de NaCl (qui est celui de LLVM) a justement été conçu pour être indépendant d'une plateforme en particulier et pour être traduit vers n'importe quel CPU. Et si les deux solutions nous enferment dans un modèle CPU classique c'est aussi le cas de javascript ou des autres langages impératifs qui ne peuvent pas être parallélisés automatiquement pour une architecture hétérogène par exemple.

Je ne dis pas que NaCl est la panacée, non, loin de là. Simplement je ne lui vois que des avantages par rapport à asm.js et je pense que c'est le mieux qui ait été proposé.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 26/02/2014 à 21:39
Citation Envoyé par DonQuiche
Initialement je penchais plutôt vers asm.js. Malheureusement il reste plus lourd à compiler (il faut reparser, identifier correctement asm.js, etc) et, surtout, à transporter puisqu'il produit des pages très lourdes (plusieurs dizaines de fois le poids d'un binaire natif).

Je n'ai pas personnellement testé asm.js, mais de ce que j'ai lu, le code asm.js généré se compresse plutôt bien et que par conséquent le surpoids du code généré est très fortement réduit si l'on a activé la compression des pages. As tu pris en compte ce point?

Citation Envoyé par DonQuiche
Cela dit je ne comprends pas ton affirmation selon laquelle NaCl rendrait les sites dépendant de l'architecture : tout comme les instructions de asm.js le bytecode de NaCl (qui est celui de LLVM) a justement été conçu pour être indépendant d'une plateforme en particulier et pour être traduit vers n'importe quel CPU. Et si les deux solutions nous enferment dans un modèle CPU classique c'est aussi le cas de javascript ou des autres langages impératifs qui ne peuvent pas être parallélisés automatiquement pour une architecture hétérogène par exemple.

Tu confonds NaCl et pNaCl.
NaCl se base sur la compilation de code natif comme son nom(Native Client) l'indique. Il est donc bien dépendant de l'architecture, contrairement à pNaCl qui se base en effet sur la représentation intermédiaire de LLVM et permet donc théoriquement de s'adapter aux architectures supportées en backend par LLVM. pNaCl peut sembler en effet plus propre que asm.js, sur le papier, cependant il n'est pas standardisé et même les développeur de LLVM trouvent qu'il a trop de point spécifiques a certaines architectures et beaucoup de points volontairement non définis pour être un bon bytecode multiplateforme.

Mais ce qui semble le plus poser de soucis, c'est surtout la PepperAPI qui vient en compagnon indispensable de pNaCl et NaCl. C'est un nouveau système très semblable aux ActiveX (sauf qu'ils sont sous le contrôle de Google, au lieu de Microsoft) et qui se retrouve en plus à dupliquer de manière non standardisée beaucoup de chose déjà présentes ou en cours d'intégration aux standards du web.
Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 27/02/2014 à 9:16
Citation Envoyé par Uther  Voir le message
Je n'ai pas personnellement testé asm.js, mais de ce que j'ai lu, le code asm.js généré se compresse plutôt bien et que par conséquent le surpoids du code généré est très fortement réduit si l'on a activé la compression des pages. As tu pris en compte ce point?

Je n'ai pas testé personnellement mais apparemment la compression ne résolvait pas totalement le problème. Or on est encore dans un Internet où chaque ko compte. Et pourtant la France n'est pas la plus mal lotie, loin de là. Et puis tu images parser des sources de 50Mo ? On va le sentir passer.

Tu confonds NaCl et pNaCl.

Autant pour moi, considère que tout ce que j'avais écrit jusqu'ici valait pour pNaCl.

Ce qui semble le plus poser de soucis, c'est surtout la PepperAPI qui vient en compagnon indispensable de pNaCl et NaCl. C'est un nouveau système très semblable aux ActiveX (sauf qu'ils sont sous le contrôle de Google, au lieu de Microsoft) et qui se retrouve en plus à dupliquer de manière non standardisée beaucoup de chose déjà présentes ou en cours d'intégration aux standards du web.

C'est juste, merci d'avoir attiré mon attention là-dessus.

Cela dit, concernant l'API il n'y a que trois solutions :
* Conserver les API JS telles quelle et introduire un marshalling à chaque appel d'une fonction de l'API par un code asm.js.
* Exposer des versions typées des API existantes (et donc introduire un système de types).
* Créer une nouvelle API de zéro (et donc introduire un système de types).

Laquelle est la meilleure ? J'aurais dit la seconde plus un peu de la troisième. Et si d'un côté je n'ai pas envie que Google contrôle quoi que ce soit, de l'autre je ne fais absolument pas confiance aux standards, qui ne sont pas une vision neutre ou dénuée d'intérêts particuliers ou d'influences dominantes, et promeuvent des choix aussi néfastes que l'autoplay (qui n'a aucune raison d'être) ou l’accès du stockage local aux sites tierce-parties. Un de mes gros reproches à Mozilla c'est qu'ils ne protègent pas assez l’utilisateur lambda de ce genre de nuisances promues par les standards.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 03/03/2014 à 13:54
Il n'y a rien a faire de plus que ce qui existe déjà : les API Web telles que spécifiées par le W3C sont déjà statiquement typées.
Même si JavaScript, le seul langage qui les utilise actuellement est dynamiquement, elles pourraient tout à fait être utilisées telles qu'elles et sans couche intermédiaire par des langages statiquement typés.
Offres d'emploi IT
Expert décisionnel business intelligence H/F
Safran - Ile de France - Évry (91090)
Architecte et intégrateur scade/simulink H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Ingénieur H/F
Safran - Ile de France - Moissy-Cramayel (77550)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil