Bizarre, Mozilla n'hésite pas à intégrer WebM et Opus, qui ont comme norme… un bon gros code source.
Comme dans le commentaire du dessous, tu confonds motocyclette et poids lourds. Un moteur de rendu est un agrégat de technologies. Le code d'un moteur de rendu est plus complexe, de par sa taille et les technologies qu'il implémente, que le code d'un codec audio et video. Même si un codec, c'est tout de même complexe, ce n'est "que" l'application de formules mathématiques (j'exagère mais bon). Un moteur de rendu, il n'y a pas une spécification, mais des spécifications : les spéc CSS n'expliquent pas comment obtenir un résultat (ou très vaguement), mais ce que doit être le résultat. Du coup il y a plusieurs manières d'implémenter un moteur de rendu CSS.
C'est pour cela qu'un moteur de rendu HTML/CSS ne peut pas servir de norme ou d'implémentation de référence.
je suppose que tu critique bien fort toutes les bibliothèques du genre libogg, libpng, etc. En effet, elle deviennent très rapidement en situation de presque-monopole.
Tu compares des motocyclettes avec des poids lourds de 30 tonnes. Tu compares des projets de quelques (dizaine de?) milliers de lignes de code, avec des projets qui en font plusieurs millions.
D'autre part, OGG, png et compagnie, sont spécifiées. Il y a une spéc, indépendante de l'implémentation, qui permet à quiconque de réaliser une implémentation. De plus, ces spécifications ne bougent pas toutes les quinzaines de jours (ça se compte plutôt en années). Alors, à part réécrire une implémentation pour le plaisir tous les 3 mois, il n'y a pas forcément d'intérêt à forker.
Et dans mon post, je parle du cas où il n'y a plus de spec au niveau HTML &co. Ce qui risque d'arriver car les spec HTML/CSS et autre technos sont en constantes évolutions, à tel point qu'il y a plein de trucs pas spécifiés dans webkit.
Il permet à tous de créer son propre moteur de recherche rapidement : il suffit de forker webkit et zou.
Moteur de recherche ? c'est quoi le rapport avec un moteur de rendu HTML comme webkit ?
Et forker webkit ? si c'est juste avoir 1 patch ou deux, ok. Mais forker pour faire des développements lourds, cela nécessite alors des gros moyens. La complexité d'un moteur de rendu HTML/CSS n'est en rien comparable avec celle d'une lib ogg ou jpeg.
Dans ce cas il me semble que mutualiser les efforts me semble aller dans le sens du progrès, puisque ça libère du temps pour faire autre chose : de nouvelles fonctionnalités, des tests plus poussés, se concentrer sur l'interface,
Oui et non. Si on veut standardiser, il faut deux implémentations (requises par le W3C), sur des bases de code différentes, si on veut pouvoir lever les problèmes d'une spécification. Cela est lié, encore une fois, à la complexité d'un moteur de rendu. Plusieurs implémentations valident le fait que cela est implémentable justement. Le fait que ce soit implémenté dans un projet ne permet pas de valider une spéc. Cela est déjà arrivé qu'un truc pouvait être implémenté dans un moteur et pas dans un autre, ou plus difficilement, à cause de l'architecture utilisée.
Sans être connaisseur, il me semble que le respect des normes HTML/CSS, etc. est surtout le fait des développeurs, qui utilise des trucs pas finalisé.
oui, mais ils ne devraient pas.
Il faudrait donc se poser la question pourquoi ces gens-là ne veulent pas se conformer aux normes ?
par incompétence. un vrai développeur web a conscience, selon moi, des conséquences de ne pas respecter les normes. Et donc, il ne doit pas utiliser des trucs expérimentaux, car il sait, quand il est compétent, que ce sont des trucs pas terminés, proprios, et donc qui ne fonctionnera pas dans les autres navigateurs. Pire, si c'est une feature qui devient standard, par exemple une propriété CSS, le prefixe -webkit-* (ou -moz-*) saute dans les versions suivantes du navigateur, et du coup la fonctionnalité utilisée sur le site n'existe plus. Bref, un site soit-disant "optimisé pour webkit" devient… non optimisé pour webkit. Un comble quoi.
D'une part pour les standards, pour la compétition avec d'autres moteurs. Faut pas oublier que le matos évolue. Webkit est déjà "obsolète" pour le matos actuel. Ex : pas de rendu threadé d'une même page donc n'utilise pas à fond les processeurs multicoeurs. Et pour que cela puisse être fait dans webkit, il faut réécrire au moins tout le layout engine. Et réimplementer toutes les features sous-spécifiées. Et donc s'attendre à des comportements différents sur ces trucs sous-spécifiés. Bref, voir mon post plus haut.
D'autre part, une monoculture webkit ne va rien arranger du tout dans ton travail. Il y a des dizaines de navigateurs différents qui utilisent… une version différente de webkit ! Rien que Chrome et Safari n'ont pas le même webkit. C'est la même base de code, certes, mais qui n'a pas le même "age", qui n'est pas patché pareil (coucou les extensions css proprio!), qui n'est pas compilé avec les mêmes composants (pile réseau, backend graphique…), et même pas avec le même moteur JS qui ne sont même pas au même niveau pour l’implémentation d'EcmaScript.
Bref, des dizaines de webkit dans la nature. Même si un jour Webkit est sur 99% des machines (tient, ça me rappelle une époque ça), tu continuera donc à faire des polyfills, des hacks css et des trucs tordus pour que ton appli qui marchait super bien dans Safari, fonctionne aussi super bien sur le dernier navigateur à la mode qui utilise webkit mais avec des patchs qui ne sont pas encore dans le dépôt webkit.
Mais pire que ça, si webkit est sur 99% des machines, tu te retrouveras avec les mêmes défauts, surtout au niveau du rendu ou CSS (qui sont les deux choses les plus compliqués à hacker/corriger). Tu ne pourras même pas avoir le bonheur de développer avec un navigateur alternatif qui n'a pas ce problème. Parce que faut pas te leurrer, un bug, même si y des milliers de contributeurs, il ne sera pas corrigé si l'architecture du moteur de rendu ne le permet pas (sans une réécriture massive du code). C'est déjà arrivé, que ce soit dans Gecko ou dans Webkit. L'un a des défauts que n'a pas l'autre et vice versa.
En clair, développer pour un unique moteur de rendu, c'est peut être se faciliter la vie sur certaines choses, mais c'est aussi subir pour d'autres choses. Et si un jour il n'y a plus d'alternatives, tu subiras encore plus, et peut-être même que ça pourrait devenir bloquant sur certains projet. Par ex, tu ne pourras même pas proposer à ton client, pour son appli intranet "installez tel navigateur, c'est ce qui correspond le mieux à vos besoins".
Le développeur web doit arrêter de faire de la merde, comme utiliser les extensions propriétaires (webkit-* et moz* etc).
Mais les navigateurs devraient aussi arrêter de fournir des trucs pas standards ou expérimentales dans les releases stables… M'enfin, d'un point de vue marketing, pour Google ou Apple, ça n'a pas de sens.
Et arrêtez avec ces histoires de fork. Forker un projet aussi gros que webkit, implique avoir une armée de développeurs pour suivre la concurrence sur les trucs "standards de facto" pour ne pas être distancé, et pour également développer les spécificités. Et sachant qu'un moteur de layout, c'est complexe, et cela nécessite des très bons développeurs qui ne courent malheureusement pas les rues… Bref, forker webkit nécessite d'être une supère grosse boite.
C'est un problème parce que si webkit, donc son implémentation devient un "standard de facto", alors il n'y aura plus de raison pour que Google ou Apple poussent leurs "innovations" à la standardisation. Ils ont déjà prouvé par le passé que la standardisation, ils s'en foutaient un peu. Je pense par exemple aux API Audio, aux transformations et animations CSS et j'en passe : ils ont développé le truc, ils l'ont inclus dans une release officielle, et seulement après ils ont envoyés leurs gars au W3C avec un brouillon de spec. Et fallait voir les brouillons. Le truc écrit sur un coin de nappe. Sous-spécifiés à mort. À l'époque, ça ressemblait à du gros foutage de gueule.
Bref, le risque à terme, c'est beaucoup moins de standardisation au W3C.
Du coup, comment vont faire ceux qui veulent développer un nouveau moteur, en utilisant par exemple des nouveaux algorithmes et donc qui exclu de réutiliser Webkit ? Comment vont-ils savoir comment implémenter telle ou telle fonctionnalité ?
Par exemple, Mozilla développe en parallèle un tout nouveau moteur de rendu, Servo. Sa particularité et de repartir from scratch, afin d'avoir un coeur totalement multi-threadé : les différentes parties d'une page seront générées par de multiple thread au niveau graphique. Ce qu'aucun moteur de rendu HTML aujourd'hui n'arrive à faire. Gecko y arrive un peu ( Off Main Thread Animations , Off Main Thread Compositing etc ). Chez webkit, ils s'y cassent les dents.
Alors donc, une boite qui veut faire un nouveau moteur de rendu utilisant des techniques innovantes, comment fait-elle pour implémenter les trucs qui ne sont "spécifiés" que dans le code source de webkit (ou dans la doc pour dev web, mais une telle doc n'est jamais suffisante pour implémenter un truc à l'identique) ?
En regardant le code source ? Ça peut être une piste, mais c'est une grosse blague ! Grosse blague parce que déjà un truc aussi complexe qu'un moteur comme webkit, ça a plein de bugs. Et webkit est probablement celui qui en a le plus, n'en déplaise à tout ces partisans. Autrement dit, dans l'implémentation d'un truc qui n'a pas de spécification, comme séparer le bon grain de l'ivraie ? qu'est ce qui est bug, qu'est ce qui ne l'est pas ? L'affichage de la balise X dans un certain cas de figure a tel résultat bizarre : c'est normal ? c'est voulu ? c'est un bug ? ou c'est une limitation de l'implémentation ?
D'autre part, un code source ça peut être très complexe, et il n'est pas toujours facile, dans l'implémentation d'un algorithme, d'en déduire le fonctionnement de cet algorithme, pourquoi comment etc… Alors qu'il serait plus simple, pour faire une nouvelle implémentation, de lire une spec : on sait tout de suite que pour implémenter ceci, cela, il faut que ça respecte telle ou telle règle, que ça produise tel résultat etc. Ce que je veux dire, c'est que souvent, pour implémenter une spec simple, il faille faire du code monstrueux. Un exemple : la spec CSS est simple à comprendre, mais l'implémentation est monstrueusement compliquée (et c'est la raison aussi pour laquelle certaines propriétés CSS mettent des années à se standardiser : les développeurs de navigateurs peinent à trouver des solutions d'implémentations satisfaisantes, en terme de perf etc.. ça sert à rien de standardiser un truc qu'on ne peut implémenter, même si ça pourrait intéresser des milliers de dev web).
Qui dit monoculture, dit moins de standardisation, dit moins de chance d'avoir des alternatives.
Et cette monoculture pourrait d'ailleurs bien se retourner contre webkit, si rien n'est spécifié officiellement : "webkit 2" refait from scratch, qui aurait un rendu identique avec "webkit 1", aurait du mal à voir le jour. Comme les autres quoi.
(rappel: dans un projet long terme comme Mozilla/Webkit, les équipes changent, les développeurs partent, le code reste, mais bien souvent sous-documenté).
c'est beaucoup plus simple à maîtriser (mais ça on l'a déjà dit)
Mq (gestion de pile de patchs) est super puissant et très simple, contrairement à git stash (que je n'arrive toujours pas à aimer…)
J'utilise git et hg au quotidien (depuis 2011 pour git et 2008 pour hg). Et bien que j'utilise de plus en plus Git, j'utilise encore Hg surtout quand j'ai besoin de gérer des piles de patch (qui peuvent être nécessaire en fonction de la manière dont le projet est géré).
dans mercurial la branche n'est qu'une méta donnée d'un commit. Pour qu'une branche existe il faut au moins un commit. Dans git une branche est un pointeur vers un commit. Pas besoin de commit dans la branche pour qu'elle existe, plus simple pour créer plusieurs branches depuis un même état.
En fait, tu as la même chose que Git dans Mercurial : les "branches" de Git s'appellent les "bookmarks" dans Hg. Dans Hg, on a donc presque le fonctionnement de Git. Le seul souci c'est que les bookmarks sont assez récents (2-3 ans je crois), et ils ne sont pas toujours pris en compte par certaines commandes…
Comme dit la réponse précédente, il faut un noyau linux adapté. Mozilla ne travaille pour le moment que sur un nombre limité de téléphones. Comme tu le vois, flasher un Nexus S ou un Galaxy SII, c'est possible.
les webapp sont apparues sur les mobiles il y a quand même quelques années. Ce n'est pas parce que cela a fait un flop il y a 5 ans (au moins) que cela va devenir une innovation.
Compare ce qu'on pouvait faire avec les technologies web entre il y a 5 ans et aujourd'hui. Rien que sur le desktop… Il y a un gouffre. HTML5, JS, api JS etc ont énormément évolué, permettent de développer un éventails beaucoup plus large de type d'applications. Donc oui, il y a quand même plus de chance que ça fonctionne aujourd'hui qu'il y a 5 ans.
Promouvoir le web : en quoi est-ce un intérêt ?
par le coté ouvert du web. ouverture de la technologie (royalty free), accessibilité de la technologie (aux débutants, la courbe d'apprentissage du web est probablement l'une des plus douces en programmation), ouverture au niveau principe (le web appartient à tout le monde, chacun peut devenir acteur etc…)..
Le web est un formidable outil de partage de la connaissance, de communication. Développer ses technologies et le rendre accessible au plus grand nombre, y compris sur le mobile évite qu'il ne soit "déprécié" en faveur des "silos" enfermant les utilisateurs, promu par des géants comme Apple.
Et pour l'instant, en quoi Firefox OS innove-t-il ? Je n'ai pas regardé la présentation en détail…
Bah regarde là déjà, et lis les autres commentaires de ce journal, il y a déjà des éléments de réponses.
mais d'après https://wiki.mozilla.org/WebAPI/ cela n'est réservé qu'aux applis "certifiées" (donc celles fournies avec le téléphone). Possible que ce soit étendue aux applis privilégiées (vérifiées par les gens du marketplace).
D'une manière générale, voir cette page pour connaitre toutes les nouvelles API
si, l’intérêt, c'est de proposer une autre solution. Inciter à l'innovation. Promouvoir le web. Quand tous les mobiles pourront exécuter des applis FirefoxOS, Mozilla aura atteint son objectif.
Surtout quand d'autres sociétés proposeront un Firefox OS avec une toute autre interface de bureau, des applis mobiles innovantes etc…
Par HTML5, j'entend aussi JS, WebAPI, CSS, WebSocket, WebRTC etc… C'est un abus de language certes, mais ça m'évite de lister toutes les technologies à chaque fois que je veux parler d'une appli développée en HTML5.
Plusieurs annees d'historique sur les autres systemes nous a montre que tres peu d'applis sont capables de faire la transition entre telephone et tablette sans grosse mise a jour
Oui mais il y a plusieurs années, on n'avait pas autant de possibilité qu'aujourd'hui, en terme CSS, JS et HTML pour faire une appli qui s'adaptent sur divers écrans. Media queries, responsive design etc.. ça te parle ?
La realite c'est qu'une grosse partie des applis ne font rien de tout ca et qu'avoir tel support necessite un gros temps de dev de toute facon.
Oui elles ne le font pas parce que le cahier des charges ne prevoyait peut être pas ce genre de possibilité. Maintenant, les "gros temps de dev", ça se réduit avec
1) des personnes compétentes (et dieu sait le nombre d'incompétents qu'il y a dans le milieu)
2) l'utilisation de framework, polyfill etc..
3) l'utilisation de standards au maximum
Mais oui, je reconnais que faire une appli web qui passe partout, c'est du boulot. D'où l'importance des standards ouverts (Mozilla ne se contente pas de faire dans son coin sa propre API comme Tizen ou autre) etc..
Maintenant, il faut voir si le surcout engendré par le support des différences entre plateforme HTML5, est plus important que celui de refaire from scratch la même appli en Objective C, une autre en Java etc.. J'en doute fort.
qu'ils ont un homophobe comme CTO
Je ne vois pas ce que ça vient faire dans cette histoire. Des pro-gays et des homophobes, tu en a dans toutes les boites, dans toutes les couches de la société. Si ça se trouve, tous les midi tu déjeunes avec des collègues homophobes sans que tu le saches…
Au final, « tout le monde » s'est mis à l'Objective C pour faire ses applications…
Alors déjà, bon nombre d'applis Objective C ne sont qu'un browser déguisé (surtout pour les version Iphone de sites).
Ensuite il faudrait voir ce que propose la plateforme IOS pour les applis HTML5 (ce sont des vrais questions, je ne connais pas la plateforme IOS).
Peut-on par exemple les installer en local, sur le téléphone, évitant d'avoir accés au réseau pour les faire tourner ? Avec Firefox OS en tout cas, c'est possible (sans parler des fonctions offline en html ).
Est ce que les développeurs ont accès dans le contexte HTML5, à une multitude d'API permettant d'accéder aux fonctionnalités du téléphone (appels, sms, contacts, et j'en passe). Avec Firefox OS en tout cas, c'est possible et ça sera même des API standardisées (avec bien sûr des mécanismes de sécurité).
Si les développeurs IOS préfèrent faire en Objective C, c'est probablement parce que la solution HTML5 dans IOS est trop limitée, et ne peut faire tourner que des applis web "normales".
Firefox OS ne propose pas seulement du HTML5 et api JS d'aujourd'hui, mais aussi ce qu'on pourra faire demain dans tout bon navigateur qui respectent les standards.
En revanche, si je prends un tél. avec X OS, j'aurais toutes les applis pour X OS + toutes les applis pour Firefox OS. Quel intérêt de prendre Firefox OS, alors ?
Déjà il faudra que le X OS propose un navigateur qui implémentent les nouveaux standards proposés au W3C (et discutés conjointement avec Apple, Google etc..). Ensuite il faudra que X OS permettent l'installation d'appli HTML5. C'est à dire permettre d'installer des applis HTML pas seulement au travers de son storemachintruc, mais aussi au travers de n'importe quel site web. Et pour le moment, la politique d'Apple en la matière n'est pas vraiment cela. L'ouverture, ils ne connaissent pas. L'utilisateur ne peut passer que par storemachintruc, et le développeur doit respecter des contraintes pour pouvoir entrer sur le store (pas le droit de proposer un navigateur par exemple). Le play store d'android est moins contraignant, mais probablement pas aussi ouvert que Mozilla.
Mais le principal intérêt sera d'avoir le choix. Que ce soit pour un industriel (proposer un téléphone non android/ios) ou pour un utilisateur. "Promouvoir le choix et l'ouverture", c'est le slogan de Mozilla. Ce n'est pas "gagner toutes les parts du marché et écraser les concurrences".
il y a des smartphones qui sont moins chère et plus puissants
hé bien tant mieux. Les utilisateurs de ces pays émergeants pourront acheter des téléphones encore moins cher (sous Firefox OS) avec à peu près les mêmes fonctionnalités :-p
Les smartphones qui seront vendu par Telefonica/Geeksphone, ce seront des appareils qui sont actuellement vendus (sous d'autres marques, avec de l'android) dans les pays "riches" aux alentours de 100-150 euros (nu, sans abonnements).
Mais pas que. Les applis pour Firefox OS sont 100% HTML5. Et c'est là le gros avantage par rapport à UbuntuOS : pas besoin de recompiler, de redévelopper son appli pour un nième mobile, de réapprendre un nième toolkit/environnement de développement. L'appli bien faite fonctionnera non seulement sur Firefox OS, mais aussi dans tout les autres navigateurs et appareils, qu'ils soient mobiles ou desktop (modulo l'utilisation de certaines API comme la téléphonie bien entendu).
Bref, ce n'est pas qu'un proof of concept. Ça fonctionne parfaitement (pour l'avoir utiliser pendant une semaine sur un téléphone prototype bas de gamme).
La concurrence ? Firefox OS vise pour le moment le low/middle-cost, donc pas les téléphones à 500 euros (iphone, galaxy etc), donc un cran en dessous des androids. Sachant que Firefox OS est plus réactif sur ces téléphones low-cost qu'Android ;-)
mais rappellons que le lancement de FirefoxOS, anciennement Boot2Gecko, date de bientot 3 ans).
Pas du tout le projet a démarré durant l'été 2011.
Pas que Firefox, mais tout les autres navigateurs. Ils utilisent l'API FileSystem, qui n'est implémenté que dans Chrome (soit 30% des internautes). Pour rappel, cette API est encore un brouillon au W3C, et qu'elle ne fait pas du tout l'unanimité dans le working group. Certains la jugent trop complexe, d'autres qu'elle est limite coté sécurité etc… Chez Mozilla, ils testent d'autres solutions (implémentées pour Firefox OS notamment).
Coté sécurité justement, certains recommandent de ne pas utiliser Mega pour y stocker des fichiers sensibles :
Non, tu es serieux avec tes 25k ? C'est absolument enorme comme taille !
énorme par rapport à quoi ? Tu dis "énorme" sans point de comparaison :-/
Déjà un noeud dom, c'est pas juste un nom et quelques valeurs d'attributs. Lis la spec. Il y a plein d'informations sur un noeud DOM. Et il y a parmi ces noeuds des noeuds textes. Si tu met 3Ko de text dans un noeud DOMText, impossible qu'il fasse 2ko, tu en conviendras. Bref, en fonction de la quantité d'information que contient un noeud DOM, il peut faire 1ko comme 50ko. Mon chiffre 25ko est une moyenne.
De plus, comme je l'ai dis, c'est un calcul biaisé. J'ai fait 50Mo / 2000 noeud DOM. Or sur les 50Mo, il y a les images de la pages, le code JS "bytecodé" / "JITé", les rêgles CSS, les informations graphiques et la représentation graphique en mémoire d'un noeud DOM etc.. Bref, j'ai pas fait le tri et donc la vrai taille d'un noeud DOM en mémoire est largement inférieure à 25ko, si ça peut te rassurer.
Le probleme n'est pas Firefox ou Chrome, mais le standard lui meme qui pousse a la consomation de ressource
Oui, c'est probable que les technos Web soient plus gourmandes en ressources, parce que c'est beaucoup plus complexe à afficher qu'avec un toolkit graphique (CSS étant en grande partie responsable de cette complexité). Maintenant, un arbre ça reste un arbre, que ce soit un arbre de noeuds DOM qu'un arbre de widgets QT/GTK, la différence étant que l'organisation des noeuds "widget" est à priori moins flexible que l'organisation de noeuds DOM.
Et ? Comme je disais, ça ne veut rien dire. 3 onglets ouverts sur quoi ? Si c'est juste des about:blank, ok, là c'est pas normal. Si ce sont des sites chargés en texte et/ou images, c'est normal. Un site comme twitter par exemple, la page sur une timeline, c'est déjà 880Ko de contenu téléchargés (html/js/images…). Une fois la page rendue et exécutée : elle contient plus de 2000 noeud DOM générés. Et la page au total prend 50Mo en mémoire (about:memory). à 25ko par noeud DOM, c'est pas cher. Et encore mon calcul est biaisé. Sur les 50Mo, je n'ai pas soustrais l'occupation en mémoire que prennent les 500ko d'images une fois décompressées. Les 25Ko comprennent également une part de JS, de CSS, de layout etc…, pas juste l'objet C++ correspondant à un noeud dom (oui désolé, je n'ai pas fait de calculs pour séparer tout ça)
Sans compte que tu as peut-être des extensions qui bouffent elles-aussi de la mémoire. Et puis il y a aussi tout le système de cache de page en mémoire pour permettre des back rapides (ce qui prend beaucoup de mémoire, et peut d'ailleurs se régler), etc, etc….
J'ai ouvert un Firefox avec extensions désactivées, et avec 5 onglets de sites divers et variés (doc php, linuxfr, site de news, twitter etc…). J'ai ouvert les mêmes onglets dans Chromimum (sans extension). Résultat : j'ai la même occupation mémoire qui est de 150Mo.
(sous linux, 64bits)
c'est quoi tes critères ?
Mes critères, ce sont tous les benchs qui sont publiés de temps en temps par Mozilla et des contributeurs (par rapport aux versions précédentes, pas forcément par rapport à la concurrence). Désolé, j'ai pas le temps de vous faire une liste de liens. Tu as ça aussi https://metrics.mozilla.com/, http://arewefastyet.com et plein d'autres…
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Opera passe à Webkit. Évalué à 0.
où ai-je dit ça ??
[^] # Re: Analyse de glazou
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Opera passe à Webkit. Évalué à 6.
spéc qui peut ne plus exister si webkit devenait l'unique moteur de rendu.
[^] # Re: Analyse de glazou
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Opera passe à Webkit. Évalué à 1.
Comme dans le commentaire du dessous, tu confonds motocyclette et poids lourds. Un moteur de rendu est un agrégat de technologies. Le code d'un moteur de rendu est plus complexe, de par sa taille et les technologies qu'il implémente, que le code d'un codec audio et video. Même si un codec, c'est tout de même complexe, ce n'est "que" l'application de formules mathématiques (j'exagère mais bon). Un moteur de rendu, il n'y a pas une spécification, mais des spécifications : les spéc CSS n'expliquent pas comment obtenir un résultat (ou très vaguement), mais ce que doit être le résultat. Du coup il y a plusieurs manières d'implémenter un moteur de rendu CSS.
C'est pour cela qu'un moteur de rendu HTML/CSS ne peut pas servir de norme ou d'implémentation de référence.
[^] # Re: Analyse de glazou
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Opera passe à Webkit. Évalué à 2.
Tu compares des motocyclettes avec des poids lourds de 30 tonnes. Tu compares des projets de quelques (dizaine de?) milliers de lignes de code, avec des projets qui en font plusieurs millions.
D'autre part, OGG, png et compagnie, sont spécifiées. Il y a une spéc, indépendante de l'implémentation, qui permet à quiconque de réaliser une implémentation. De plus, ces spécifications ne bougent pas toutes les quinzaines de jours (ça se compte plutôt en années). Alors, à part réécrire une implémentation pour le plaisir tous les 3 mois, il n'y a pas forcément d'intérêt à forker.
Et dans mon post, je parle du cas où il n'y a plus de spec au niveau HTML &co. Ce qui risque d'arriver car les spec HTML/CSS et autre technos sont en constantes évolutions, à tel point qu'il y a plein de trucs pas spécifiés dans webkit.
Moteur de recherche ? c'est quoi le rapport avec un moteur de rendu HTML comme webkit ?
Et forker webkit ? si c'est juste avoir 1 patch ou deux, ok. Mais forker pour faire des développements lourds, cela nécessite alors des gros moyens. La complexité d'un moteur de rendu HTML/CSS n'est en rien comparable avec celle d'une lib ogg ou jpeg.
Oui et non. Si on veut standardiser, il faut deux implémentations (requises par le W3C), sur des bases de code différentes, si on veut pouvoir lever les problèmes d'une spécification. Cela est lié, encore une fois, à la complexité d'un moteur de rendu. Plusieurs implémentations valident le fait que cela est implémentable justement. Le fait que ce soit implémenté dans un projet ne permet pas de valider une spéc. Cela est déjà arrivé qu'un truc pouvait être implémenté dans un moteur et pas dans un autre, ou plus difficilement, à cause de l'architecture utilisée.
oui, mais ils ne devraient pas.
par incompétence. un vrai développeur web a conscience, selon moi, des conséquences de ne pas respecter les normes. Et donc, il ne doit pas utiliser des trucs expérimentaux, car il sait, quand il est compétent, que ce sont des trucs pas terminés, proprios, et donc qui ne fonctionnera pas dans les autres navigateurs. Pire, si c'est une feature qui devient standard, par exemple une propriété CSS, le prefixe -webkit-* (ou -moz-*) saute dans les versions suivantes du navigateur, et du coup la fonctionnalité utilisée sur le site n'existe plus. Bref, un site soit-disant "optimisé pour webkit" devient… non optimisé pour webkit. Un comble quoi.
[^] # Re: Le raisonnement fallacieux envers Webkit
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Opera passe à Webkit. Évalué à 2.
Non, ce n'est absolument pas une bonne chose.
D'une part pour les standards, pour la compétition avec d'autres moteurs. Faut pas oublier que le matos évolue. Webkit est déjà "obsolète" pour le matos actuel. Ex : pas de rendu threadé d'une même page donc n'utilise pas à fond les processeurs multicoeurs. Et pour que cela puisse être fait dans webkit, il faut réécrire au moins tout le layout engine. Et réimplementer toutes les features sous-spécifiées. Et donc s'attendre à des comportements différents sur ces trucs sous-spécifiés. Bref, voir mon post plus haut.
D'autre part, une monoculture webkit ne va rien arranger du tout dans ton travail. Il y a des dizaines de navigateurs différents qui utilisent… une version différente de webkit ! Rien que Chrome et Safari n'ont pas le même webkit. C'est la même base de code, certes, mais qui n'a pas le même "age", qui n'est pas patché pareil (coucou les extensions css proprio!), qui n'est pas compilé avec les mêmes composants (pile réseau, backend graphique…), et même pas avec le même moteur JS qui ne sont même pas au même niveau pour l’implémentation d'EcmaScript.
Bref, des dizaines de webkit dans la nature. Même si un jour Webkit est sur 99% des machines (tient, ça me rappelle une époque ça), tu continuera donc à faire des polyfills, des hacks css et des trucs tordus pour que ton appli qui marchait super bien dans Safari, fonctionne aussi super bien sur le dernier navigateur à la mode qui utilise webkit mais avec des patchs qui ne sont pas encore dans le dépôt webkit.
Mais pire que ça, si webkit est sur 99% des machines, tu te retrouveras avec les mêmes défauts, surtout au niveau du rendu ou CSS (qui sont les deux choses les plus compliqués à hacker/corriger). Tu ne pourras même pas avoir le bonheur de développer avec un navigateur alternatif qui n'a pas ce problème. Parce que faut pas te leurrer, un bug, même si y des milliers de contributeurs, il ne sera pas corrigé si l'architecture du moteur de rendu ne le permet pas (sans une réécriture massive du code). C'est déjà arrivé, que ce soit dans Gecko ou dans Webkit. L'un a des défauts que n'a pas l'autre et vice versa.
En clair, développer pour un unique moteur de rendu, c'est peut être se faciliter la vie sur certaines choses, mais c'est aussi subir pour d'autres choses. Et si un jour il n'y a plus d'alternatives, tu subiras encore plus, et peut-être même que ça pourrait devenir bloquant sur certains projet. Par ex, tu ne pourras même pas proposer à ton client, pour son appli intranet "installez tel navigateur, c'est ce qui correspond le mieux à vos besoins".
Le développeur web doit arrêter de faire de la merde, comme utiliser les extensions propriétaires (webkit-* et moz* etc).
Mais les navigateurs devraient aussi arrêter de fournir des trucs pas standards ou expérimentales dans les releases stables… M'enfin, d'un point de vue marketing, pour Google ou Apple, ça n'a pas de sens.
Et arrêtez avec ces histoires de fork. Forker un projet aussi gros que webkit, implique avoir une armée de développeurs pour suivre la concurrence sur les trucs "standards de facto" pour ne pas être distancé, et pour également développer les spécificités. Et sachant qu'un moteur de layout, c'est complexe, et cela nécessite des très bons développeurs qui ne courent malheureusement pas les rues… Bref, forker webkit nécessite d'être une supère grosse boite.
[^] # Re: Analyse de glazou
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Opera passe à Webkit. Évalué à 10.
C'est un problème parce que si webkit, donc son implémentation devient un "standard de facto", alors il n'y aura plus de raison pour que Google ou Apple poussent leurs "innovations" à la standardisation. Ils ont déjà prouvé par le passé que la standardisation, ils s'en foutaient un peu. Je pense par exemple aux API Audio, aux transformations et animations CSS et j'en passe : ils ont développé le truc, ils l'ont inclus dans une release officielle, et seulement après ils ont envoyés leurs gars au W3C avec un brouillon de spec. Et fallait voir les brouillons. Le truc écrit sur un coin de nappe. Sous-spécifiés à mort. À l'époque, ça ressemblait à du gros foutage de gueule.
Bref, le risque à terme, c'est beaucoup moins de standardisation au W3C.
Du coup, comment vont faire ceux qui veulent développer un nouveau moteur, en utilisant par exemple des nouveaux algorithmes et donc qui exclu de réutiliser Webkit ? Comment vont-ils savoir comment implémenter telle ou telle fonctionnalité ?
Par exemple, Mozilla développe en parallèle un tout nouveau moteur de rendu, Servo. Sa particularité et de repartir from scratch, afin d'avoir un coeur totalement multi-threadé : les différentes parties d'une page seront générées par de multiple thread au niveau graphique. Ce qu'aucun moteur de rendu HTML aujourd'hui n'arrive à faire. Gecko y arrive un peu ( Off Main Thread Animations , Off Main Thread Compositing etc ). Chez webkit, ils s'y cassent les dents.
Alors donc, une boite qui veut faire un nouveau moteur de rendu utilisant des techniques innovantes, comment fait-elle pour implémenter les trucs qui ne sont "spécifiés" que dans le code source de webkit (ou dans la doc pour dev web, mais une telle doc n'est jamais suffisante pour implémenter un truc à l'identique) ?
En regardant le code source ? Ça peut être une piste, mais c'est une grosse blague ! Grosse blague parce que déjà un truc aussi complexe qu'un moteur comme webkit, ça a plein de bugs. Et webkit est probablement celui qui en a le plus, n'en déplaise à tout ces partisans. Autrement dit, dans l'implémentation d'un truc qui n'a pas de spécification, comme séparer le bon grain de l'ivraie ? qu'est ce qui est bug, qu'est ce qui ne l'est pas ? L'affichage de la balise X dans un certain cas de figure a tel résultat bizarre : c'est normal ? c'est voulu ? c'est un bug ? ou c'est une limitation de l'implémentation ?
D'autre part, un code source ça peut être très complexe, et il n'est pas toujours facile, dans l'implémentation d'un algorithme, d'en déduire le fonctionnement de cet algorithme, pourquoi comment etc… Alors qu'il serait plus simple, pour faire une nouvelle implémentation, de lire une spec : on sait tout de suite que pour implémenter ceci, cela, il faut que ça respecte telle ou telle règle, que ça produise tel résultat etc. Ce que je veux dire, c'est que souvent, pour implémenter une spec simple, il faille faire du code monstrueux. Un exemple : la spec CSS est simple à comprendre, mais l'implémentation est monstrueusement compliquée (et c'est la raison aussi pour laquelle certaines propriétés CSS mettent des années à se standardiser : les développeurs de navigateurs peinent à trouver des solutions d'implémentations satisfaisantes, en terme de perf etc.. ça sert à rien de standardiser un truc qu'on ne peut implémenter, même si ça pourrait intéresser des milliers de dev web).
Bref, une implémentation, un code source, ne peut définir un standard, comme l'indique un gars ici.
Qui dit monoculture, dit moins de standardisation, dit moins de chance d'avoir des alternatives.
Et cette monoculture pourrait d'ailleurs bien se retourner contre webkit, si rien n'est spécifié officiellement : "webkit 2" refait from scratch, qui aurait un rendu identique avec "webkit 1", aurait du mal à voir le jour. Comme les autres quoi.
(rappel: dans un projet long terme comme Mozilla/Webkit, les équipes changent, les développeurs partent, le code reste, mais bien souvent sous-documenté).
[^] # Re: Je profite de ce troll
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Microsoft passe à git. Évalué à 5.
Mercurial, ça roxxe du poney parce que:
J'utilise git et hg au quotidien (depuis 2011 pour git et 2008 pour hg). Et bien que j'utilise de plus en plus Git, j'utilise encore Hg surtout quand j'ai besoin de gérer des piles de patch (qui peuvent être nécessaire en fonction de la manière dont le projet est géré).
[^] # Re: Je profite de ce troll
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Microsoft passe à git. Évalué à 4.
En fait, tu as la même chose que Git dans Mercurial : les "branches" de Git s'appellent les "bookmarks" dans Hg. Dans Hg, on a donc presque le fonctionnement de Git. Le seul souci c'est que les bookmarks sont assez récents (2-3 ans je crois), et ils ne sont pas toujours pris en compte par certaines commandes…
[^] # Re: Installable sur d'autres smarphones ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 2.
Comme dit la réponse précédente, il faut un noyau linux adapté. Mozilla ne travaille pour le moment que sur un nombre limité de téléphones. Comme tu le vois, flasher un Nexus S ou un Galaxy SII, c'est possible.
Et il y a d'autres hackers qui sont en train de porter Firefox OS sur d'autres téléphones.
Et pour ceux qui sont intéressé pour un portage, voici une petite doc
[^] # Re: Pertinence de l'investissement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 2.
sur les technologies web.
Compare ce qu'on pouvait faire avec les technologies web entre il y a 5 ans et aujourd'hui. Rien que sur le desktop… Il y a un gouffre. HTML5, JS, api JS etc ont énormément évolué, permettent de développer un éventails beaucoup plus large de type d'applications. Donc oui, il y a quand même plus de chance que ça fonctionne aujourd'hui qu'il y a 5 ans.
par le coté ouvert du web. ouverture de la technologie (royalty free), accessibilité de la technologie (aux débutants, la courbe d'apprentissage du web est probablement l'une des plus douces en programmation), ouverture au niveau principe (le web appartient à tout le monde, chacun peut devenir acteur etc…)..
Le web est un formidable outil de partage de la connaissance, de communication. Développer ses technologies et le rendre accessible au plus grand nombre, y compris sur le mobile évite qu'il ne soit "déprécié" en faveur des "silos" enfermant les utilisateurs, promu par des géants comme Apple.
Bah regarde là déjà, et lis les autres commentaires de ce journal, il y a déjà des éléments de réponses.
Comme autre réponse, je te renvoi au manifeste de Mozilla
[^] # Re: Accès sockets
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 2.
Pour le dev, peut être, pour l'utilisateur, certainement pas. Tu voudrais donc que n'importe quelle appli web puisse accéder à ton FS, /dev et cie ?
brrr…
non, à de la sécurité.
Question de point de vue je présume…
[^] # Re: Accès sockets
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 3.
Oui c'est possible : https://bugzilla.mozilla.org/show_bug.cgi?id=733573
mais d'après https://wiki.mozilla.org/WebAPI/ cela n'est réservé qu'aux applis "certifiées" (donc celles fournies avec le téléphone). Possible que ce soit étendue aux applis privilégiées (vérifiées par les gens du marketplace).
D'une manière générale, voir cette page pour connaitre toutes les nouvelles API
[^] # Re: Firefao, l'enfer du jeu
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 0.
Les problèmes de rendu 3D, ce n'est pas la faute à Firefox OS, mais au téléphone. Gecko reposant sur WebGL (donc openGL) pour tout ce qui est 3D.
Et puis tous les jeux ne sont pas en 3D…
[^] # Re: Pertinence de l'investissement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 2.
si, l’intérêt, c'est de proposer une autre solution. Inciter à l'innovation. Promouvoir le web. Quand tous les mobiles pourront exécuter des applis FirefoxOS, Mozilla aura atteint son objectif.
Surtout quand d'autres sociétés proposeront un Firefox OS avec une toute autre interface de bureau, des applis mobiles innovantes etc…
[^] # Re: Pertinence de l'investissement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 2.
oui, ces APIs n'ont rien d'un standard, mais elles sont ou vont être proposées au W3C. L'objectif de Mozilla c'est de standardiser tout ça.
Tu noteras que le langage HTML5 aussi n'est pas encore un standard : ce n'est encore qu'une "candidate recommandation".
[^] # Re: Pertinence de l'investissement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 3.
Par HTML5, j'entend aussi JS, WebAPI, CSS, WebSocket, WebRTC etc… C'est un abus de language certes, mais ça m'évite de lister toutes les technologies à chaque fois que je veux parler d'une appli développée en HTML5.
[^] # Re: Pertinence de l'investissement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 4.
Oui mais il y a plusieurs années, on n'avait pas autant de possibilité qu'aujourd'hui, en terme CSS, JS et HTML pour faire une appli qui s'adaptent sur divers écrans. Media queries, responsive design etc.. ça te parle ?
Oui elles ne le font pas parce que le cahier des charges ne prevoyait peut être pas ce genre de possibilité. Maintenant, les "gros temps de dev", ça se réduit avec
1) des personnes compétentes (et dieu sait le nombre d'incompétents qu'il y a dans le milieu)
2) l'utilisation de framework, polyfill etc..
3) l'utilisation de standards au maximum
Mais oui, je reconnais que faire une appli web qui passe partout, c'est du boulot. D'où l'importance des standards ouverts (Mozilla ne se contente pas de faire dans son coin sa propre API comme Tizen ou autre) etc..
Maintenant, il faut voir si le surcout engendré par le support des différences entre plateforme HTML5, est plus important que celui de refaire from scratch la même appli en Objective C, une autre en Java etc.. J'en doute fort.
Je ne vois pas ce que ça vient faire dans cette histoire. Des pro-gays et des homophobes, tu en a dans toutes les boites, dans toutes les couches de la société. Si ça se trouve, tous les midi tu déjeunes avec des collègues homophobes sans que tu le saches…
[^] # Re: Pertinence de l'investissement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 2.
Oui, mais mes arguments ne se réduisent pas à ce paragraphe.
[^] # Re: Pertinence de l'investissement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 4. Dernière modification le 23 janvier 2013 à 14:39.
Alors déjà, bon nombre d'applis Objective C ne sont qu'un browser déguisé (surtout pour les version Iphone de sites).
Ensuite il faudrait voir ce que propose la plateforme IOS pour les applis HTML5 (ce sont des vrais questions, je ne connais pas la plateforme IOS).
Si les développeurs IOS préfèrent faire en Objective C, c'est probablement parce que la solution HTML5 dans IOS est trop limitée, et ne peut faire tourner que des applis web "normales".
Firefox OS ne propose pas seulement du HTML5 et api JS d'aujourd'hui, mais aussi ce qu'on pourra faire demain dans tout bon navigateur qui respectent les standards.
Déjà il faudra que le X OS propose un navigateur qui implémentent les nouveaux standards proposés au W3C (et discutés conjointement avec Apple, Google etc..). Ensuite il faudra que X OS permettent l'installation d'appli HTML5. C'est à dire permettre d'installer des applis HTML pas seulement au travers de son storemachintruc, mais aussi au travers de n'importe quel site web. Et pour le moment, la politique d'Apple en la matière n'est pas vraiment cela. L'ouverture, ils ne connaissent pas. L'utilisateur ne peut passer que par storemachintruc, et le développeur doit respecter des contraintes pour pouvoir entrer sur le store (pas le droit de proposer un navigateur par exemple). Le play store d'android est moins contraignant, mais probablement pas aussi ouvert que Mozilla.
Mais le principal intérêt sera d'avoir le choix. Que ce soit pour un industriel (proposer un téléphone non android/ios) ou pour un utilisateur. "Promouvoir le choix et l'ouverture", c'est le slogan de Mozilla. Ce n'est pas "gagner toutes les parts du marché et écraser les concurrences".
[^] # Re: Pertinence de l'investissement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 4.
Oui. Les développeurs de chez Mozilla le font tous les jours :-)
(mais désolé, je n'ai plus les références des modèles utilisés en tête)
[^] # Re: Pertinence de l'investissement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 3.
hé bien tant mieux. Les utilisateurs de ces pays émergeants pourront acheter des téléphones encore moins cher (sous Firefox OS) avec à peu près les mêmes fonctionnalités :-p
Les smartphones qui seront vendu par Telefonica/Geeksphone, ce seront des appareils qui sont actuellement vendus (sous d'autres marques, avec de l'android) dans les pays "riches" aux alentours de 100-150 euros (nu, sans abonnements).
[^] # Re: Pertinence de l'investissement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Du nouveau chez Geeksphone et FirefoxOS. Évalué à 10.
Promouvoir un OS 100% libre pour téléphone mobile, sans "app store" obligatoire : tout le monde peut diffuser sur son site son appli firefox OS, voir même monter son propre "marketplace" sachant que Mozilla en propose un par défaut et dont les sources sont libres et disponibles bien sûr.
Mais pas que. Les applis pour Firefox OS sont 100% HTML5. Et c'est là le gros avantage par rapport à UbuntuOS : pas besoin de recompiler, de redévelopper son appli pour un nième mobile, de réapprendre un nième toolkit/environnement de développement. L'appli bien faite fonctionnera non seulement sur Firefox OS, mais aussi dans tout les autres navigateurs et appareils, qu'ils soient mobiles ou desktop (modulo l'utilisation de certaines API comme la téléphonie bien entendu).
Bref, ce n'est pas qu'un proof of concept. Ça fonctionne parfaitement (pour l'avoir utiliser pendant une semaine sur un téléphone prototype bas de gamme).
La concurrence ? Firefox OS vise pour le moment le low/middle-cost, donc pas les téléphones à 500 euros (iphone, galaxy etc), donc un cran en dessous des androids. Sachant que Firefox OS est plus réactif sur ces téléphones low-cost qu'Android ;-)
Pas du tout le projet a démarré durant l'été 2011.
[^] # Re: Ce que je remarque...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mega reprend le flambeau.. Évalué à 5.
Pas que Firefox, mais tout les autres navigateurs. Ils utilisent l'API FileSystem, qui n'est implémenté que dans Chrome (soit 30% des internautes). Pour rappel, cette API est encore un brouillon au W3C, et qu'elle ne fait pas du tout l'unanimité dans le working group. Certains la jugent trop complexe, d'autres qu'elle est limite coté sécurité etc… Chez Mozilla, ils testent d'autres solutions (implémentées pour Firefox OS notamment).
Coté sécurité justement, certains recommandent de ne pas utiliser Mega pour y stocker des fichiers sensibles :
[^] # Re: sans intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu phone OS. Évalué à 3.
énorme par rapport à quoi ? Tu dis "énorme" sans point de comparaison :-/
Déjà un noeud dom, c'est pas juste un nom et quelques valeurs d'attributs. Lis la spec. Il y a plein d'informations sur un noeud DOM. Et il y a parmi ces noeuds des noeuds textes. Si tu met 3Ko de text dans un noeud DOMText, impossible qu'il fasse 2ko, tu en conviendras. Bref, en fonction de la quantité d'information que contient un noeud DOM, il peut faire 1ko comme 50ko. Mon chiffre 25ko est une moyenne.
De plus, comme je l'ai dis, c'est un calcul biaisé. J'ai fait 50Mo / 2000 noeud DOM. Or sur les 50Mo, il y a les images de la pages, le code JS "bytecodé" / "JITé", les rêgles CSS, les informations graphiques et la représentation graphique en mémoire d'un noeud DOM etc.. Bref, j'ai pas fait le tri et donc la vrai taille d'un noeud DOM en mémoire est largement inférieure à 25ko, si ça peut te rassurer.
Oui, c'est probable que les technos Web soient plus gourmandes en ressources, parce que c'est beaucoup plus complexe à afficher qu'avec un toolkit graphique (CSS étant en grande partie responsable de cette complexité). Maintenant, un arbre ça reste un arbre, que ce soit un arbre de noeuds DOM qu'un arbre de widgets QT/GTK, la différence étant que l'organisation des noeuds "widget" est à priori moins flexible que l'organisation de noeuds DOM.
[^] # Re: sans intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ubuntu phone OS. Évalué à 6. Dernière modification le 08 janvier 2013 à 19:01.
Et ? Comme je disais, ça ne veut rien dire. 3 onglets ouverts sur quoi ? Si c'est juste des about:blank, ok, là c'est pas normal. Si ce sont des sites chargés en texte et/ou images, c'est normal. Un site comme twitter par exemple, la page sur une timeline, c'est déjà 880Ko de contenu téléchargés (html/js/images…). Une fois la page rendue et exécutée : elle contient plus de 2000 noeud DOM générés. Et la page au total prend 50Mo en mémoire (about:memory). à 25ko par noeud DOM, c'est pas cher. Et encore mon calcul est biaisé. Sur les 50Mo, je n'ai pas soustrais l'occupation en mémoire que prennent les 500ko d'images une fois décompressées. Les 25Ko comprennent également une part de JS, de CSS, de layout etc…, pas juste l'objet C++ correspondant à un noeud dom (oui désolé, je n'ai pas fait de calculs pour séparer tout ça)
Sans compte que tu as peut-être des extensions qui bouffent elles-aussi de la mémoire. Et puis il y a aussi tout le système de cache de page en mémoire pour permettre des back rapides (ce qui prend beaucoup de mémoire, et peut d'ailleurs se régler), etc, etc….
J'ai ouvert un Firefox avec extensions désactivées, et avec 5 onglets de sites divers et variés (doc php, linuxfr, site de news, twitter etc…). J'ai ouvert les mêmes onglets dans Chromimum (sans extension). Résultat : j'ai la même occupation mémoire qui est de 150Mo.
(sous linux, 64bits)
Mes critères, ce sont tous les benchs qui sont publiés de temps en temps par Mozilla et des contributeurs (par rapport aux versions précédentes, pas forcément par rapport à la concurrence). Désolé, j'ai pas le temps de vous faire une liste de liens. Tu as ça aussi https://metrics.mozilla.com/, http://arewefastyet.com et plein d'autres…