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é).
[^] # 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é).