Bonjour,
dans une conférence datée de novembre 2013, Benjamin Bayart dit "écrire un navigateur web, c'est indémerdable" (réf. Internet et ses enjeux : Le Monde Change sur un site de streaming bien connu).
Je me demande bien pourquoi.
Déjà, je sais que ce ne sont pas les atours du navigateur qui posent problème: en 10 lignes, on donne un fenêtrage simple à un "moteur de rendu" (https://duckduckgo.com/?q=python+webkit+browser).
Je comprends donc qu'il s'agit du "moteur de rendu" (http://fr.wikipedia.org/wiki/Moteur_de_rendu_HTML).
Mais du coup je ne comprends pas : ce que reçoivent les navigateurs, c'est du code html. Or du code html bien formé devrait être facile à interpréter non ?
Bref, c'est là que je ne comprends plus.
Si vous voulez répondre, vous avez carrément le droit d'être un peu technique.
Ciao
# tout est dit
Posté par NeoX . Évalué à 7.
pour faire "simple", tu as plein de normal à interpreter dans ton moteur de rendu :
- http 0.9,1.0, 1.1 pour la communication
- html strict, xhtml
- css2, css3
- javascript X ou Y
je te laisse imaginer le nombre de combinaisons possibles
ensuite y a les drafts des RFC implementées ou pas
et un probleme similaire du coté des serveurs,
- quel version du protocole
coté developpeur :
- je fais du html, du html strict ? du xhtml .
- du javascript ?
[^] # Re: tout est dit
Posté par totof2000 . Évalué à 5.
Il y a aussi des cas ou la norme ne spécifie pas clairement ce que doit faire le navigateur pour rendre telle ou telle balise, et ces interprétations peuvent poser problème.
# bien formé
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 6.
Salut,
Du code bien formé, à peu près, oui. Quoique quand on lit les normes, c'est quand même vachement complexe.
Mais surtout, tu en connais beaucoup, du code web 100% valide ?
Il y a tellement de variantes différentes, tellement d'erreurs possibles, tellement de cas à gérer… ça en devient très difficile.
Ajoutons à ça les histoires d'extensions, les protections diverses et variés à mettre en place, ça commence à faire beaucoup…
# gestion de la diversité
Posté par Adrien . Évalué à 4.
Un navigateur web est soumis à pas mal de contraintes :
– savoir interpreter correcte des normes… qui évoluent sans cesse (HTML5?).
– savoir interpreter correctement des sites qui ne respectent pas les normes, parce que c'est le plus courant
– pouvoir lire le java, flash et autre cochonnerie facilement
– savoir répondre à plein d'utilisations différentes : entre celui qui veut voir un simple site web, celui qui veut youtube, celui qui veut faire de la VoIP… avec les performances qui vont bien. un gmail qui rame comme pas possible c'est pas top
– le tout de manière sécurisée, sans mettre en danger ta machine.
Avec ça on a déjà un navigateur web basique. On pourrait lui ajouter des modules pour bloquer la publicité, bloquer les cookies, passer en HTTPS, télécharger la vidéo flash à la con de la page, etc.
Bref, faire un navigateur web, c'est pas simple, en partie à cause des informaticiens (cf les normes), en partie à cause des multiples usages qu'il permet.
# Des exemples des choses compliquées
Posté par mrlem (site web personnel) . Évalué à 9. Dernière modification le 19 février 2014 à 13:04.
On pourrait trouver beaucoup à dire, mais déjà :
# Je vous réponds à tous ...
Posté par Sylvain . Évalué à 0.
J'aurais bien fais une réponse personnalisée, mais vous avez dit tous à peu près la même chose en même temps (le temps d'aller manger).
Le côté ultra-tolérant, on s'en rend compte en modifiant le fichier de données d'un programme, qui du coup plante ou refuse de se charger.
Du coup, c'est du côté des normes que je porte mon regard (critique): par exemple quand j'ai vu la déclaration du doctype html5 où il n'est même pas précisé de quelle version il s'agit j'ai fait un bond. Pourtant il me semble bien que les entreprises du web sont présentes dans ces consortium alors quoi, ils se disent "tiens bouge pas, on va mettre un doctype incompréhensible qui va poser des problèmes à nos navigateurs" et les autres "ouais ! ! ouais ! ! " (je m'arrête là, j'aurais beaucoup à dire sur le html5).
Et donc voici le jeu auquel on est obligé de jouer : quand on fait du html etc. on doit faire attention à produire du code lisible par tous les navigateurs (en jouant des bugs, en jouant avec des balises pirates, etc.) ; quand on est codeur de navigateur, on doit faire attention à tout accepter. Et quand quand on est au consortium, on se tourne la nouille et on joue aux dés…
Bonne journée et merci de vos réponses.
[^] # Re: Je vous réponds à tous ...
Posté par GG (site web personnel) . Évalué à 4.
Écoute, une grosse entreprise avec plein de développeurs comme Microsoft n'arrive pas à faire un navigateur correct ni sécurisé.
Même avec l'arrivée de gros concurrents (Chrome, Safari, Firefox), cette entreprise est encore en retard, et la sécurité laisse à désirer. Son navigateur IE est même le plus souvent le point d'entrée pou les intrusions et les prises de contrôles à distance (suffit de lire les news, il est en est question régulièrement).
Donc si c'était si facile, ça se saurait.
Heureusement que les bon navigateurs se basent sur des moteurs déjà bien foutu: Webkit, Khtml.
A+
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Je vous réponds à tous ...
Posté par fabien . Évalué à 3.
Oui bon ça c'est une chose, mais prenons simplement le javascript.
Tu dois coder un compilateur Just in time qui accéde aux objets internes utilisés pour representer ta page (a travers le DOM : Document Object Model) tout en ayant la possibilité d'envoyer et recevoire des requetes (pour l'ajax). ton compilo doit suivre les évolutions de la norme javascript (ECMA-262) et être un tant soit peut… performant!
Rien que ça, ça dechire.
[^] # Re: Je vous réponds à tous ...
Posté par Obsidian . Évalué à 2.
Faire un logiciel « tolérant » est loin d'être la partie la plus difficile, même si ça peut être délicat dans certains cas. Ça devrait même être un principe général à partir du moment où le logiciel interagit avec l'extérieur, que ce soit avec l'utilisateur ou avec le réseau. On ne peut pas partir du principe que les données reçues seront forcément les bonnes dans tous les contextes ni même qu'elles arriveront forcément. Donc, il faut avoir des procédures pré-déterminées dans ces cas-là.
Le problème du navigateur est que c'est le logiciel probablement le plus utilisé sur les ordinateurs de bureau et qu'il est en train de devenir pratiquement aussi complexe que le système d'exploitation lui-même. Outre la liste des normes exposée par Shift juste au-dessous, il faut voir que chacune de ces normes est en soi un monument. Par exemple, si on se restreint au simple W3C, on obtient déjà ceci : http://www.w3.org/TR/
Rien que là-dedans, si on ne s'intéresse qu'aux CSS, on a ceci : http://www.w3.org/TR/2011/PR-CSS2-20110412/ soit un PDF de 487 pages. Et encore, ça, c'est humainement assimilable par une seule personne. Je les avais imprimées et reliées dans mon ancienne compagnie, et j'ai toujours l'ouvrage sous le coude aujourd'hui.
Une fois que tu as fini tout cela — et si tant est que tu ne t'intéresses toujours qu'au rendu du document — alors il faudra aussi tenir compte du fait qu'il est dynamique : il faudra le regénérer lorsque tu redimensionneras ta fenêtre ou que tu l'enverras vers un autre média (imprimante), mais également en fonction des événements reçus pendant et après la génération du document, par exemple le survol d'un élément qui doit déclencher les classes :hover qui, selon la façon dont elles sont écrites, peuvent influer sur le document entier. Et bien sûr, par tout ce qui est généré par le Javascript, ce qui inclut la définition et la mise en place d'un DOM ne serait-ce que pour disposer d'un langage permettant d'indiquer à quelle partie du document on souhaite toucher.
Bref : ce n'est pas forcément difficile en soi ni d'emblée, mais c'est extrêmement long à développer en entier et surtout, il est très difficile de garder l'ensemble cohérent au cours du temps, et de garantir ses performances par dessus le marché.
# Euh... tu déconnes ?
Posté par Infernal Quack (site web personnel) . Évalué à 10.
Un navigateur, il n'a pas beaucoup plus complexe comme logiciel "grand public" en terme de choses à gérer (si on exclut les gros jeux vidéos).
Déjà au niveau des normes et standards à supporter ou qu'il est fortement conseillé de supporter au moins dans des versions light (et leur différentes versions) :
- HTTP : 1.0, 1.1, bientôt 2.0
- SPDY
- HTML : 1.0, 2.0, 3.2, 4.0, 4.0.1 et 5 qui est une espèce de rolling-release.
- XHTML : 1.0, 1.1, bientôt 2.0
- SSL
- TLS
- CSS : 1.0, 2.0, 2.1 et 3.0 encore en cours de spécification.
- XSL
- XML
- XPath
- XQuery
- JSON
- MathML
- SVG
- Image : GIF, JPEG, PNG, ANG, MNG,…
- Audio : MP3, OGG, WAVE, AAC,…
- Video : H.264, WEBM,…
- Javascript
- WebGL
- Canvas
- DOM
- File
- Ftp
- Les encodages : ISO-8859-15, UTF-8,…
- RSS
- Atom
- Cookie
- Local storage
- XBEL
- …
Et ces normes sont très loin d'être simples (contrairement à ce que croient les anciens développeurs COBOL passés chef de projet ou DSI). Il suffit d'aller se taper les spécifications de chacun d'eux pour comprendre.
Qui plus est, certains formats n'ont pas prévu de gestions d'erreurs (HTML avant la version 5) dont les navigateurs doivent pallier à toutes les conneries sur lesquelles ils peuvent tomber afin que la page s'affiche tout de même. En html5, le "comment gérer les erreurs" a le mérite de faire partie de la norme.
Là où quand un traitement de texte ouvrant un fichier corrompu affiche le plus souvent un message d'erreur indiquant "Je peux pas l'ouvrir", un navigateur doit afficher quelque chose. Je pense que cette gestion d'erreurs doit représenter une partie énorme du code.
Les navigateurs ont aussi des algorithmes divers et variés pour pallier les autres conneries des développeurs comme ne pas spécifier d'encodage. C'est loin d'être trivial car ça marche à coup de statistiques de présence de certains caractères et de détections de mots. Et il y a aussi les modes dégradés qui s'activent quand le code HTML est détecté comme mal fait : sans DOCTYPE,… (Mode Quirks).
Et des onglets ! Un navigateur sans onglets c'est devenu has been ;)
A cela s'ajoute la gestion d'add-ons et de plugins avec des bacs à sables pour sécuriser tout ça et de plus en plus souvent des outils de développeurs intégrés (Parcourir le DOM, les CSS appliqués à chaque élément, un profileur mémoire, un débogueur JS,…). Et certains navigateurs ont intégrés des lecteurs PDF. On a aussi le spell-checker intégré.
Perso, je suis admiratif des équipes qui travaille dans le développement des navigateurs et de leurs moteurs (de rendu ou JS). Déjà que de mon coté j'arrive pas à assimiler toutes les technos qui arrivent :)
Et puis une des preuves du boulot effectué par exemple dans l'amélioration des performances et l'arrivée (réelle, car il y avait si je ne me trompe des essais avortés dans le passé) de Javascript coté serveur via NodeJS. C'est devenu suffisamment robuste pour servir des applications webs. Un truc démentiel il y a peu.
Bref, j'arrête là mais voit un navigateur comme une œuvre d'art informatique !
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Euh... tu déconnes ?
Posté par ckiller . Évalué à 3.
ca, c'est pour l'aspect "parsage" des flux d'entrées, après, il faut encore composer l'image, gérer les animations. gérer l'arrivée asynchrone des données, avoir des stratégies de caches tout en gérant la sécurité.
bref, un sacré merdier.
[^] # Re: Euh... tu déconnes ?
Posté par mrlem (site web personnel) . Évalué à 2.
J'avais travaillé en Server-Side JavaScript (SSJS pour les intimes) il y a pas mal de temps. C'était pas mal, mais on était en effet très loin de la sophistication de NodeJS… et c'est la montée en puissance du Java côté serveur qui avait mis à mort cette techno.
[^] # Re: Euh... tu déconnes ?
Posté par freem . Évalué à 1.
Hum… le seul problème des onglets que j'arrive à voir, c'est de les isoler pour pas qu'un bug de l'objet contenu par l'un d'eux fasse planter l'application entière, ou pire, ne puisse corrompre les autres.
Maintenant… si les applications ont besoin de gérer les onglets elles-mêmes, c'est pour une et une seule raison: les gestionnaires de fenêtre flottantes ne font pas leur boulot de façon assez évoluée. Cette fonctionnalité de séparation des processus/thread/affichages (en gros, que dans un même programme on ait de multiples instances de ce programme même qui ne puissent pas communiquer ni avoir d'effets de bord avec/sur les autres) ne devrait pas être dans le navigateur. Bien entendu, je pense la même chose au sujet des éditeurs de texte, notamment.
Gérer les priorité des processus, c'est le job du kernel. Gérer les fenêtres, celui du gestionnaire de fenêtre ( ou comment enfoncer une porte ouverte… ) et donc absolument pas celui du navigateur.
Je crois que le jour où les développeurs de nombreux outils ( wm inclues ) auront compris ça, ils en chieront nettement moins à développer les applis end-user.
Bon, je parle, mais je code pas non plus dans le bon sens, j'admets. Le problème de la séparation des rôles n'est pas simple non plus, par exemple, rien que définir qu'est-ce qui dans une application est de la gestion de fenêtre, et qu'est-ce qui est de l'ordre des contrôles ( et donc, lié au toolkit ) n'est pas simple. Dans les 2 cas, le terme fenêtre est utilisé de façon à peu près semblable, mais pas complètement.
Toujours est-il que je trouve ça assez débile de faire des onglets multiples sur un navigateur, qui est du coup à instance unique ( généralement ) histoire que quand ça plante, ben que ça fasse pas semblant ( le pire, c'est que j'ai été heureux à l'époque ou je suis passé à FF d'avoir des onglets… ).
Pour le reste, je suis globalement d'accord avec toi.
[^] # Re: Euh... tu déconnes ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Les onglets augmentent en général le nombre de connexions vers un domaine donné. Et ensuite ça donne des soucis comme Inter-locks / HTTP's per-server connection limitation.
[^] # Re: Euh... tu déconnes ?
Posté par freem . Évalué à 1.
Intéressant.
Il s'agit d'un bug que je n'ai jamais rencontré, peut-être parce que j'utilise opera ( en revanche j'en ai d'autres, dont un exclusif à linuxfr. Faudra que je report, un de ces 4… allez, je vais me motiver et le faire de suite. ).
Au final, si je comprend bien, le souci vient du fait que certains browser aient un nombre de connexion limité par serveur, je suppose dans le but d'économiser de la BP tout en téléchargeant plus d'un élément par page ( et donc onglet ), mais la bride entre en conflit direct avec le fait d'utiliser des onglets multiples.
Je me demande si ces situations ( sont-elles résolues? le message que tu cites date de 2011, il y a 3 ans donc. ) se seraient également produites dans le cas de plusieurs instances de la même application lancée sur la même machine?
Pour ma part, je flaire l'application (le browser) qui cherche à deviner ce que l'utilisateur veut, et foire lamentablement. Comme souvent quand une application se mêle d'interpréter les intentions d'un humain.
[^] # Re: Euh... tu déconnes ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Non la situation n'a pas évolué et l'entrée est toujours ouverte (et elle concerne plusieurs navigateurs dont les principaux).
# Navigateur "Internet"
Posté par Xaapyks . Évalué à 3.
Je crois qu'il y a certaines conférences de Benjamin que tu as oublié de regarder… ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.