Si l’on en croit Windows Central, Microsoft travaillerait sur un nouveau navigateur. Portant le nom de code Anaheim, il aurait pour principale caractéristiques de laisser tomber le moteur EdgeHTML au profit de Chromium et de son moteur Blink.
De la même manière qu’Opera en son temps, Microsoft abandonnerait tout développement sur son moteur pour se caler sur le socle le plus utilisé par le marché, isolant d’ailleurs encore un peu plus Mozilla et son Gecko. On ne sait pas cependant quelle proportion de cette nouvelle base serait utilisée : le moteur Blink uniquement ou davantage de composants.
Bien que l’information doive évidemment être confirmée, cette décision aurait du sens. Les investissements de Microsoft ont été nombreux, mais Edge n’ayant jamais été équipé d’autant de fonctionnalités que ses concurrents, il a été boudé par une grande partie du public, sa part de marché ayant même tendance à baisser avec le temps.
En outre, le passage à Chromium résoudrait plusieurs problèmes à la fois, notamment liés au Windows Store. Toute fonction de navigation doit en effet y utiliser le moteur d’Edge. Microsoft cherchant à simplifier la vie des développeurs afin que sa boutique soit plus vivante, l’épine enlevée serait conséquente.
Évidemment, quand on cherche des signes, on en trouve. On peut par exemple faire remarquer que si Edge est disponible sur Android et iOS, c’est en exploitant à chaque fois le moteur natif de chaque plateforme. Il n’y a certes pas le choix chez Apple, mais EdgeHTML aurait très bien pu faire l’objet d’un portage Android, comme Mozilla l’a fait pour Firefox.
En outre, les commits récents de Microsoft dans le code de Chromium pour son portage ARM64 montrent une implication de l’éditeur (Google ayant accepté toutes les modifications). Le père de Windows connait donc manifestement bien le code de Chromium.
Pour Windows Central, l’information ne semble faire aucun doute. Il ne resterait plus que quelques inconnues, comme le nom du navigateur (pas sûr qu’Edge soit gardé) et la période d’arrivée.
Nos confrères estiment que l’attente ne devrait pas être longue : le « nouvel Edge » ferait son apparition pendant le cycle de développement actuel de la version 19H1, nom de code de la prochaine évolution majeure de Windows 10, attendue pour le printemps prochain.
Commentaires (60)
#1
He ben, à cette allure on va revenir à la même situation que quand IE régnait en maître :(
#2
Portant le nom de code Anaheim
ça fait un peu nom d’actrice X
#3
Et par contre ils se servent toujours de Word pour afficher les emails HTML dans Outlook
" />
" />
" />
#4
#5
#6
Avec une “légère” différence quand même
" />
#7
[…] comme le nom du navigateur (pas sûr qu’Edge soit gardé)
Molybdène ? Juste en-dessous du chrome, et c’est l’élément 42
https://fr.wikipedia.org/wiki/Molybd%C3%A8ne
#8
QU’on était jeune à l’époque, c’est ça ? 
" />
#9
Pour ceux qui en doutaient, là on en est sur :
" />
Le nouvel IE sera bien chrome
#10
Cela serait une grosse perte pour Internet, c’est indéniable que Mozilla ne va résister à la pression et que le web n’aura à terme qu’un seul moteur de rendu.
Avec le projet GeckoView (qui permet de se passer de Webview sur Android) Microsoft aurait pu essayer de soutenir Mozilla qui les concurrence moins que Google et maintenir une certaine diversité dans les moteurs de rendu.
MS abandonne un peu trop facilement pour une entreprise de cette taille (ils avaient aussi abandonné les amélioration en arrivant sur IE6).
#11
#12
Voir le commentaire de KP2 juste au-dessus ;)
#13
C’est ça que j’aime avec PCI : à la lecture du message de @ndjpoye j’étais plutôt d’accord avec lui et PAF ! ta réponse - argumentée - m’a fait changer d’avis, c’est cool, du coup merci ! :)
#14
Merci pour l’explication !
Mais du coup, pourquoi Mozilla ne participe pas à cet effort commun ? Quelles sont ses raisons de continuer à développer son moteur de rendu dans son coin ?
#15
Bah oui c’est un truc commun et qui évolue très vite, ce n’est pas du tout la situation d’un monopole d’IE propriétaire, codé donc unilatéralement, avec un vieux système de versions majeures tous les siècles
#16
#17
#18
#19
Je serais moins tranché que toi, Google a un grand pouvoir de décision, Chromium n’étant pas une fondation.
Il faudrait reformuler la question, es-ce que être force de proposition dans les améliorations du web est essentiel pour MS ?
Je ne le pense pas et je me dis que MS va contribuer mais en suivant le sens de la marche. Google proposera des technos qui seront taillées au couteau pour leurs besoins sans chercher à être universel pour d’autres qu’eux, les corrections se faisant après.
#20
Le problème avec “la domination” de Chrome c’est que l’on a vu apparaître pleins de CSS non standards chrome- (ou même l’objet chrome à la place browser).
Au final c’était les mêmes défauts pour lesquels ont a vomit sur IE (à juste titre).
Ce sur quoi il faut se battre c’est éviter ces écarts.
Je suis néanmoins bien partagé entre avoir une saine concurrence avec 3 implémentations de moteurs (permet d’avoir des débats seins sur l’implémentation de telle ou telle spec) et le cout (effort) de maintenir ces moteurs (et de devoir gérer les écarts). Mais bon comme dit plus haut, à voir avec la gouvernance (#forks)
#21
#22
Microsoft veut surtout vendre ses outils web (Office 360, etc.) à tout le monde (et non pas seulement aux utilisateurs de Edge).
Un web fragmenté ne lui convient pas, et abattre du travail que être ou compatible avec le moteur de rendu le plus répandu ou faire évoluer son moteur pour qu’il soit équivalent au plus répandu, n’est pas du tout intéressant pour MS.
MS n’a aucune raison de fragmenter le web quand il n’arrive plus à garder les utilisateurs sur son navigateur.
Par contre, il pourra toujours rajouter des fonctionnalités en plus dans son navigateur (Intégration Windows/Skype/Outlook directement dans le navigateur)
#23
#24
#25
#26
Quand la spec dit browser et que l’implémentation s’appelle chrome ce n’est pas un écart avec le standards établi par la communauté ?
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_in…
#27
Je ne sais pas ce que tu prends mais ça rend parano.
Blink c’est quoi sinon un fork de webkit qui est un fork de khtml ?
fonctionnalités web spécifiques pour leurs applications gratuitesComme ?
Et donc si un fabricant veut implémenter telle ou telle API dans Blink, Google peut décider de refuser si cela va à l’encontre de son propre interêt commercial. Et cela s’est déjà vu. Comme ?
#28
#29
C’est encore au stade du draft et ça a été créé pour unifier le développement d’extensions web qui ont longtemps été absolument incompatibles. Pour l’instant on voit encore nettement les spécificités de chacun des navigateurs mais on peut espérer que ça converge avec le temps.
#30
#31
#32
#33
Leur intérêt avec IE6 était qu’ils pouvaient vendre des fonctionnalités pro dessus donc le monétiser.
Aujourd’hui Edge à part être un élément de fierté technologique interne peut être ne leur sert à rien.
Ils ont raison de l’abandonner et de passer sur des briques libres.
#34
C’est marrant ce manque de recul par rapport au libre. Comme si, parce que le code est libre, les rapports de force disparaissaient. Si seulement…
#35
#36
#37
#38
#39
#40
#41
Je pense que les dévs sont fans de la marionnette de Rocard au Bébète Show
" />
#42
#43
Il est pas du sud surement 
" />
#44
#45
#46
Ça va alléger le Web tt ça
Tous les scripts/bibliothèques/font utilisées sur les sites avec du code spécifique à chaque navigateur.
Et s’il pouvait sortir une version installable sur n’importe quel version de Windows ça serait bien
Car c’est ce qui a tué edge uniquement disponible sur w10
#47
L’analyse de https://twitter.com/SwiftOnSecurity/status/1069776335336292352?s=19 me semble la bonne :
Forker Chromium/Blink pour remplacer Edge serait complètement idiot.
Par contre, forker Electron pour pouvoir le concurrencer et l’améliorer, là ça aurait du sens. Il n’y aurait pas moins de concurrence au final, mais plus !
#48
N’importe quoi rien à voir entre les deux
On parle d’un changement de moteur de rendu.
Pas d’un Framework qui permet de faire des webapp
#49
Alors, peut-être que tu sais pas ce que c’est qu’Electron ?
Electron, c’est une manière de packager des webapps directement avec le moteur de rendu, ici Blink/Chrome. Oui, y’a des bibliothèques JS dedans en plus (NodeJS par exemple), mais ça reste Chrome+webapp.
Donc si MS peut forker Chrome pour faire un autre Electron, plus performant, et même, pourquoi pas, de manière à ce qu’il n’y ait besoin que d’une seule instance pour toutes les apps (VSCode+Slack+Spotify+etc.) ça permettrait de faire un bon de performances.
Tu t’es jamais posé la question de pourquoi toutes ces applications Electron faisaient presque le même poids que Chrome ?
#50
Le gros frein pour le Web aujourd’hui c’est IE11 et pas Edge qui est correct…
le problème pour MS est que c’est IE11 et son moteur qui leur rapporte le plus et qu’ils sont vraiment obligés de maintenir sur le long terme…
Edge doit leur coûter un max pour rester compétitif.
En fait MS est en train d’adopter progressivement la stratégie de Google : vendre des service et miser sur les Logiciels Libres pour minimiser les coûts de maintenance de leurs produits.
#51
Ce n’est pas vraiment pour Mozilla que j’ai peur, mais plus pour les standards et le rôle premier du W3C. Quand on voit comment Google a forcé l’implémentation des Web Components ou des Progressive Web App ces derniers temps, c’est à vomir. Sans même parler de la qualité de l’implémentation…
Apple implémente d’abords les API pour son propre usage, et c’est pour ça que Google est parti parce que… il fait pareil ! Et Microsoft l’a toujours fait ! On va se retrouver avec un Web contrôlé par des entreprises dégueulasses. Apple est un peu plus sage mais ça reste un business avant tout.
Longue vie à Firefox !
#52
#53
Exactement. Tout pousse à soutenir cette hypothèse.
Mais ils auraient besoin de le forker quand même, parce que la communauté ne voudra pas d’un Electron différent. Et Electron est toujours basé sur Chromium/Blink.
Donc ils pourraient faire une version différente pour l’intégrer à Windows directement, en parallèle de l’Electron qui permet d’avoir pleins d’apps séparées :)
#54
#55
Tu voulais sans doute dire AMP et pas PWA.
Les PWA sont une bonne chose on sort les applis des stores proprio pour les remettre dans les mains des utilisateurs.
#56
Ah, j’avais oublié AMP. Non je parle bien des PWA. Google fait le forcing avant que ce soit un standard et une recommendation un temps soit peu réfléchie. A ce propos je ne trouve pas l’implementation très heureuse entre le manifest qui répète ce qu’on a déjà dans le HEAD, une gestion du cache fait sur un nom plutôt que sur des délais qui laisse des résidus à vie si tu ne les nettoie pas par code, la fonction import synchrone qui sort de derrière les fagots, la barre d’installation qui apparaît, qui n’apparaît plus, qui apparaît si on fait une requête. Ca pue le brouillon à des kilomètres.
#57
#58
Non. Tu n’as pas compris ce qu’était une PWA. Tu confonds avec une application Electron. Une PWA n’est pas un exe qui embarque une version castrée d’un navigateur, c’est “simplement” un site web sur lequel tu es venu surajouter des mécanismes de gestion des caches ce qui te permet de gérer le comportement lorsque le site se retrouve offline.
Google earth ayant toujours été une application locale je me réjouis de la voir être disponible sur le web (et sur plus de plateforme). Pour l’instant l’application n’est dispo que sur chrome car ils avaient besoin de vitesse et d’une maitrise du threading. A l’époque seul le NativeClient le permettait. Mais depuis ils ont entrepris la migration vers WebAssembly. Wait And See.
Make no mistake, we were (and still are) thrilled to give people a new way to experience Google Earth — all within the browser. However we initially made a trade off by going with Native Client, as Chrome was the only browser using Native Client at the time.
Le w3c ne va jamais assez vite. Je ne sais pas si je verrais svg2 de mon vivant. Les devs de Inkscape non plus. Quand en plus ils veulent retirer LA feature qui fait svg2 (gradient mesh) on se demande parfois quelle est la légitimité de certains (sous)comités de w3c.
#59
#60
Encore non.
Beaucoup de sites web gagneraient à être convertis en PWA. Et beaucoup d’applications gagneraient à être converties en PWA.
Par exemple l’application de la croix-rouge n’est qu’une copie de leur site web, est-ce pour autant qu’elle n’a aucun intérêt ?
Quelle est sa plus-value par rapport au site web ? L’aspect offline et c’est tout. Cela vaut-il le coup de faire une application pour ça ? Non.
L’application est sortie début 2011 sur iphone et 18 mois plus tard sur Android. Je ne crois pas qu’elle soit jamais sortie sur windows phone
Si on ne fait pas d’appli, est-ce que le site seul suffit ? Comment y accéder si le site est injoignable (catastrophe naturelle, accident de randonnée) ?
Non la solution c’est la PWA. Tu rajoutes un manifest, tu listes les pages pertinentes pour un aspect offline et voilà.
Rien à installer.
Pas de dépendance à un store.
L’utilisateur se connecte normalement et s’il décide d’ “installer” l’application alors les pages ne sont simplement plus enregistrées dans le cache global du navigateur mais dans un cache/répertoire dédié qui constitue l’application (et le navigateur se charge de récupérer en background toutes les pages pertinentes).