IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

Servo : le futur des moteurs de rendu web par Mozilla

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Étudiant
    Inscrit en
    Août 2011
    Messages
    283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Août 2011
    Messages : 283
    Points : 18 071
    Points
    18 071
    Par défaut Servo : le futur des moteurs de rendu web par Mozilla
    Servo : le futur des moteurs de rendu web par Mozilla
    basé sur Rust et axé sur le parallélisme

    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 ?

  2. #2
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    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.

  3. #3
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    @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.

  4. #4
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    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.

  5. #5
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    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.

  6. #6
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    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.

  7. #7
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    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.

  8. #8
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    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é.

  9. #9
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    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.

  10. #10
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    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.

  11. #11
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    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.

Discussions similaires

  1. [Qt WebEngine] Un nouveau moteur de rendu web pour Qt
    Par arnolddumas dans le forum Moteurs Web
    Réponses: 6
    Dernier message: 25/09/2013, 01h39
  2. Effacer une page web des moteurs de recherche
    Par starwars dans le forum Référencement
    Réponses: 3
    Dernier message: 03/03/2013, 12h09
  3. Comment enregistrer des graphiques pour le web?
    Par pepe2006 dans le forum Access
    Réponses: 1
    Dernier message: 11/10/2005, 21h08
  4. Tomcat 5.5 ( gestion des privilèges d'une web app )
    Par mick72 dans le forum Tomcat et TomEE
    Réponses: 1
    Dernier message: 03/09/2005, 07h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo