Microsoft overweegt Webkit-renderengine voor IE

Tijdens een bijeenkomst voor ontwikkelaars heeft Steve Ballmer laten weten dat het idee om Webkit als renderengine voor Internet Explorer in te zetten, 'interessant' is. Volgens de Microsoft-topman gaat zijn bedrijf er 'mogelijk naar kijken'.

Ballmer ging op het onderwerp in toen een student zich openlijk afvroeg waarom Microsoft zoveel geld en moeite in een eigen rendering engine steekt, terwijl er solide opensource-alternatieven bestaan waarmee snel op nieuwe en veranderende webstandaarden kan worden ingespeeld. Ballmer noemde de vraag 'brutaal maar goed', en zei: "Opensource is interessant. Apple heeft Webkit verkozen en mogelijk gaan wij er ook naar kijken, maar we zullen wel uitbreidingen voor IE8 blijven bouwen." Ballmer gaf verder toe dat de moeizame ontwikkeling van Vista voor vertraging zorgde bij de overgang van IE6 naar IE7, maar hij wilde niet dieper op die zaak ingaan.

De uitlatingen van de ceo over Webkit zijn opvallend, omdat Microsoft altijd zijn eigen renderengines voor IE heeft gebouwd. Bij de ontwikkeling van IE8 moest Microsoft echter zijn uiterste best doen om de belofte in te lossen dat de 'eigenwijze' browser standards compliant zou worden. De opensource-renderengine Webkit wordt ondertussen gebruikt door Apple in zijn browser Safari en door Google in Chrome. Nokia heeft op basis van Webkit een mobiele browser voor het Symbian-platform gebouwd.

Mocht Microsoft de stap naar Webkit daadwerkelijk maken, dan krijgt het een renderengine in handen die niet alleen snel is, maar zich ook aan de gangbare webstandaarden houdt. Webkit kan Microsoft bovendien de kans geven om de verouderde Pocket IE-browser voor het Windows Mobile-platform nieuw leven in te blazen. Ten slotte zou de softwaregigant ook de vlotte javascript-engine Squirrelfish Extreme kunnen integreren, waardoor de browser beter overweg kan met webapplicaties.

Voor webontwikkelaars zou de komst van Webkit ook goed nieuws zijn, omdat er minder tijd nodig zou zijn om websites en -applicaties geschikt te maken voor meerdere browsers. Firefox en Opera zouden verder als enige twee grote browsers nog een eigen renderengine gebruiken .

Door Dimitri Reijerman

Redacteur

07-11-2008 • 15:38

75

Reacties (75)

75
71
15
8
0
6
Wijzig sortering
We vergeten vaak dat Microsoft haar eigen belangen heeft, vooral als het gaat om standaarden. nog steeds is IE verre weg de meest gebruikte browser ter wereld en zo willen ze ook houden. Door een open-source engine te kiezen betekent dat MS haar filosophy en andere belangen verwerpt. Opeens zijn ze "net als alle anderen" en de race is fair. Zelfs MS durf dit niet aan te gaan.

Op dit moment is gewoon niet verstandig voor MS over te stappen en haar voordeel los te laten. Qua innovatie en creativiteit staat MS niet vooraan de lijst. Ze weten in welk positie ze staan en zullen dit ook zo lang mogelijk verdedigen.
Dat zegt balmer ook: eigen uitbreidingen zullen blijven. Het al oude embrace and extend.

Maar MS is groot genoeg om op 2 paarden (trident + webkit) te wedden.
Anoniem: 132507 7 november 2008 16:00
Hoewel iedereen hier behoorlijk positief reageert en ik ook moet toegeven dat een Webkit-renderengine in IE mij veel tijd en frustratie zou besparen, sta ik er toch niet zó positief tegenover. De diversiteit in renderengines en browsers moet gewoon blijven bestaan. Dat is veiliger én zorgt voor gezonde concurrentie.

Okee, Trident is behoorlijk slecht, maar ik hoop dat ze hun renderengine gewoon verbeteren, zodat IE op die manier een waardige concurrent wordt voor Firefox, Safari, Chrome, Safari, Konqueror, ...

Ik wil er ook niet aan denken wat er gebeurt met al die IE-only sites als ze overstappen op Webkit, maarja, dat is hun probleem :9
concurrentie? zodat innovatie blijft bestaan?

gelukkig is het opensource, en als pietje een bepaalde functie wil inbouwen, en steekt er genoeg moeite in en het wordt goedgekeurd, dan komt dat er gewoon in.

Mooi he opensource, innoverend én standaardcompliant :Y)
Anoniem: 100904 7 november 2008 16:09
Ik geloof er helemaal niets van dat Ballmer dit serieus overweegt. Dit doet me een beetje denken aan de expert-chats met het IE-team waar als iemand een suggestie doet je altijd hetzelfde antwoord krijgt:
Thanks for the feedback. We'll consider this for a future IE release.
Microsoft heeft er totaal geen belang bij om over te stappen naar een andere rendering engine. "Don't break the Web" is het motto van Microsoft, laat staan dat ze met zulke rigoureuze veranderingen komen. (Honderd)duizenden sites die compleet niet meer werken. /edit: Onder deze sites valt dan ook het bij bedrijven veel gebruikte Web Access van Office Outlook. Nee, hoe meer je er over nadenkt, hoe onrealistischer dit wordt.

Bovendien zou dit ook een bom leggen onder hun eigen gesloten Silverlight platform door nou een engine te implementeren die wel goed overweg kan met Javascript, Canvas en DOM. Los van het feit dat dit gewoon een 'motie van wantrouwen' is naar de hele IE afdeling.

De kans dat dit gaat gebeuren schat ik haast uitgesloten. Ik gok er op dat Ballmer redelijk verrast was door deze vraag en een beetje onhandig antwoord heeft gegeven, want dit is een compleet onrealistisch scenario (al zou het wel zeer wenselijk zijn...).

/edit: in het uiterst onwaarschijnlijke scenario dat het toch zal gebeuren, zal dit zeker geen invloed meer hebben op IE8, tenzij ze dat met minstens een jaar willen uitstellen. Je bouwt niet zomaar een compleet niet renderengine in je browser in.

[Reactie gewijzigd door Anoniem: 100904 op 22 juli 2024 15:58]

Ik verwacht ook niet dat Microsoft IE's renderengine zal gaan vervangen. Ze hebben er al één en die krijgt voor IE8 nou net heel veel aandacht bij Microsoft. En als die fatsoenlijk aan de standaarden conformeert is het wat mij betreft ook best. :)
Ze hebben het beloofd en de beta van IE8 zag er geloof ik goed uit wat dat betreft, dus dat kan weleens mee gaan vallen allemaal.

Laten ze maar wat doen aan de renderengine van Outlook 2007. Da's Word 2007. Als je dacht dat Trident een slechte renderengine is voor HTML: you ain't seen nothing yet.
Ik geloof er ook weinig van, naast jou argumenten zou het compleet onmogelijk zijn dat microsoft LGPL'd code in hun OS zet die notabene van linux/kde en apple afkomstig is, daarnaast is de browser een tool voor microsoft om via incompatibiliteit mensen/bedrijven te dwingen windows te gebruiken, die controle zouden ze compleet verliezen dan = geen tactisch voordeel.
WebKit is available under a BSD-style license

http://developer.apple.com/opensource/internet/webkit.html

Zou niet de eerste keer zijn dat Microsoft BSD code gebruikt.
Ik zie dat WebKit gedeeltelijk onder de LGPL en gedeeltelijk onder een BSD license is gebouwd.

Weet iemand welk gedeelte onder de LGPL valt? Dat is dan namelijk waarschijnlijk het gedeelte wat MS niet gaat gebruiken ;)

(MS heeft eerder o.a. de TCP/IP stack die onder de BSD licentie valt in Windows gebouwd. Principiële problemen zullen ze wel niet hebben tegen permissive-opensource)
Weet iemand welk gedeelte onder de LGPL valt? Dat is dan namelijk waarschijnlijk het gedeelte wat MS niet gaat gebruiken ;)
Waarom zouden ze niet? Als ik dit goed lees mag men software met het LGPL-licentie, als die niet verandert wordt, commercieel gebruiken.
Klopt, maar wijzigingen aan software die onder de LGPL valt moet onder dezelfde licentie vrijgegeven worden, en dat is precies iets wat MS niet zo leuk vindt.
Namens alle webdevelopers: JA! DOE DAT! ALSJEBLIEFT! WE SMEKEN JULLIE! DUMP TRIDENT! :)
Ze zijn alleen te laat om het in IE8 te gieten... hoewel, Google kwam ook "opeens" op de proppen met iets goed, dus MS kan dat ook.
Echt in eens of was Google al tijden bezich met zo iets (ze zeggen zelf namelijk ook dat het ol in Android zat en dat ze daarom eigenlijk automatisch voor webkit kozen) een nieuwe browser uit de grond stampen gaat niet zo maar. De javascript VM bijvoorbeeld door een clubje in Denenmarken gemaakt een clubje dat Google toevallig niet al te lang daarvoor gekocht had. Hun tab bladen en dat soort dingen die net even anders werken dan de standaard oplossingen van dit moment zijn ook niet even in een weekje geschreven en getest. Het heeft maanden of zelfs jaren geduurt om een nieuwe browser te bouwen.

in IE8 zal er zeker geen webkit komen simpel weg omdat IE8 al uitkomt voor dat een opdrach van Balmer helemaal de lader is af gerolt tot aan de mensen die ook echt aan de ontwikkeling van IE8 werken.
Voor een volgende versie IE9 zou het best wel eens kunnen dat Microsoft hun engine aan de kant zetten en met Webkit gaan werken, niet omdat hun engine nu zo slecht is maar wel omdat er zo ontzettend veel vraag is naar een standaard complient engine... maar de kans is groot dat als IE8 standaard complient is dat microsoft gewoon hun engine blijven gebruiken al is het alleen maar omdat het dingen doet als anti-aliasing en microsoft dat natuurlijk niet beschikbaar wil maken voor webkit.

Het probleem met de webkit engine is dat verbeteringen en aanpassingen terug gegeven moeten worden aan de gemeenschap en dat is iets wat men bij microsoft niet graag doet omdat juist hun technologische voorsprong het geen is waar het bedrijfsmodel op draait. Als ze een browser maken die uit eindelijk precies het zelfde doet als alle andere browsers dan is er dus geen enkele rede meer om voor IE te kiezen want gebruikers gemak is tot noch toe niet echt een van Microsofts sterke punten geweest als je kijkt naar tabed browsing en meer van dat soort dingen geen van alle komen ze bij MS vandaan.
Balmer kan wel leuke uitspraken doen over er naar kijken en zo en mischien ook wel denken geld te besparen maar toch denk ik niet dat het in de nabije toekomst gaat gebeuren dat Microsoft zo'n groot risico gaat lopen als het uit handen geven van de ontwikkeling van hun HTML rendering engine.
De render engine van Mozzila was niet de voornaamste keuze waarom mensen overstappen op FF. De inovatie zit hem dan ook vaak in de snelheid en de functie's. Enkel de render engine is niet voldoenden.

Heel eerlijk zou het geen slechte keus voor MS zijn en vermoedelijk ook goedkoper, zeker op lange termijn. De opmaaktalen en javascript (ecma-script) zijn standaarden die uiteindelijk buiten Microsoft worden ontwikkeld.

Anderzijds dient er toch nog steeds enkele spelers op de markt te zijn die alternatieve bieden, want naast standaarden moet een render engine voornamenlijk snel zijn. De render engine van IE faalt echter op beide vlakken.
Anderzijds dient er toch nog steeds enkele spelers op de markt te zijn die alternatieve bieden, .
En in de vorm van Opera en Firefox zijn die er dus
in IE8 zal er zeker geen webkit komen simpel weg omdat IE8 al uitkomt voor dat een opdrach van Balmer helemaal de lader is af gerolt tot aan de mensen die ook echt aan de ontwikkeling van IE8 werken.
Lijkt me zomaar dat Balmer niet helemaal in zn eentje zo'n dergelijke beslissing neemt zonder dat iemand er vanaf weet. Bovendien denk ik, gezien de reactie van Balmer, dat het idee al enige tijd binnen MS aanwezig is. Ze zullen er denk ik al wel eens eerder over gedacht hebben, anders zou Balmer niet zo'n reactie geven.
Daar heb je gelijk in, zeker bij Balmer, als dat idee er niet was had hij zeker een hoop andere argumenten klaar om de render engine van IE te verdedigen en die van webkit de grond in te boren.
Ik weet het niet... Op de PDC van afgelopen week hebben ze net een presentatie gehouden over het feit dat IE8 en Office dezelfde renderer gebruiken, waarom dat ding presenteren als je het overboord gaat gooien?

Aan de andere kan biedt het integreren van WebKit wel grote voordelen, Windows 7 moet volgens Microsoft ons gaan overtuigen dat ze in Redmond hebben geleerd van hun fouten. Het imago van heel Windows moet door die release op de schop gaan, en het imago van IE kan ook wel een boost gebruiken. WebKit kan juist voor die broodnodige boost zorgen (zeker gezien het gewoon bloedsnel rendered, en dat is iets dat het imago bij het grote publiek verbeterd. In tegenstelling tot het voldoen aan standaarden wat alleen bij developers geliefd zou zijn :) ).

Als je dan ook ziet hoe snel de ontwikkelingen in Gecko en WebKit gaan, dan zal Microsoft of alle zeilen bij moeten gaan zetten om de achterstand goed te maken, of ze pakken de strategie 'if you can't beat them, join them'.

Ik ben benieuwd... persoonlijk zou ik het geweldig vinden :)
Het probleem met de webkit engine is dat verbeteringen en aanpassingen terug gegeven moeten worden aan de gemeenschap en dat is iets wat men bij microsoft niet graag doet omdat juist hun technologische voorsprong het geen is waar het bedrijfsmodel op draait.

Is ook niet echt juist, ze lopen technologisch zelden voor - het is de lockin aan hun software waar hun businessmodel op draait. Zorgt in dit geval voor hetzelfde resultaat, natuurlijk, maar het is wel heel wat anders...
Names alle webdevelopers malware/spyware makers: JA! DOE DAT! ALSJEBLIEFT! WE SMEKEN JULLIE! DUMP TRIDENT!

Ben ik de enige die een probleem ziet? Als er dan een bug gevonden word in de renderer dan zijn ook gelijk alle grote browsers er kwetsbaar voor.

[Reactie gewijzigd door DRaakje op 22 juli 2024 15:58]

Dat was tot voor kort net zo goed het geval, maar dan alleen met IE/Trident, gezien het marktaandeel. Niks nieuws dus. En nu zijn er ook veel meer bedrijven die dan gelijk aan het fixen slaan.
Er zitten nu ook aardig wat bugs in IE, door opensource is de kans dat iemand het probleem oppakt en oplost een stuk groter - als we even kijken naar de reputatie van MS en IE.

Daarnaast, "alle grote browsers"? Safari en dan IE9. Firefox heeft zijn eigen engine en ook Opera heeft een eigen. Vind het dus nog al meevallen.

Van mij mag MS het doen; alles beter dan die verschrikkelijke IE/Trident.
Chrome ook naast IE9en Safari. Dus ja bijna allemaal, op Firefox na en Opera met zijn kleine aandeeltje.
Als je de aandelen van FireFox en Opera klein noemt dan heb je geen verstand van zaken. Chrome doet het met ongeveer 3%, waar FireFox en Opera ruim een kwart van de markt in handen hebben (en gelukkig nog steeds meer martkaandeel verkrijgen).
Je haalt de woorden uit me mond, scheelt een hoop <!--'jes.
Doe het! Kom op MS, doe de developers een plezier :)
Én gebruikers en dus ook hun eigen business.
De business draait nog steeds op IE6, dus tegen 2016 zou die dan op IE9 met webkit draaien.

Komisch overigens dat opgestelde standaarden meer als standaard worden geaccepteerd door developers dan hetgeen het marktaandeel van producten in de business als standaard oplevert.

De gebruikers zal het niet zo veel kunnen schelen hóe het werkt, áls het maar werkt. Alleen moet je dan wel de gebruikers meenemen als belangrijkste ontwikkelcriteria en niet "de standaarden".
Komisch overigens dat opgestelde standaarden meer als standaard worden geaccepteerd door developers dan hetgeen het marktaandeel van producten in de business als standaard oplevert.
Wat is daar komisch aan? Die opgestelde open standaarden zitten niet vol met zaken die bedoeld zijn om het concurrenten moeilijk te maken. Bij proprietaire 'standaarden' is dat veelal wel zo.
De gebruikers zal het niet zo veel kunnen schelen hóe het werkt, áls het maar werkt. Alleen moet je dan wel de gebruikers meenemen als belangrijkste ontwikkelcriteria en niet "de standaarden".
Wat werkt? De pixel-perfecte visuele rendering, de toegankelijkheid in tekstbrowsers, de ondersteuning van proprietaire zaken als ActiveX? De open standaarden zijn juist opgesteld met de gebruikers in gedachten. Bedrijven hebben namelijk de neiging om hun eigen belangen boven die van hun gebruikers te plaatsen. De toepassing van open standaarden geeft de gebruiker de mogelijkheid om op ieder moment over te stappen op de browser die het beste bij haar wensen aansluit.
Dit zal een hoop ontwikkel werk gaan schelen in de toekomst voor de web ontwikkelaars. Hierdoor worden webapplicaties weer goedkoper omdat er minder 'hacks' ingebouwd moeten worden. Een prettig gevolg hiervan is weer dat je dan nog beter goede applicaties bouwen.

* Marientjuh denkt dat google zijn strategie begint te werken... Niet een browser bouwen om groot te worden maar om de rest te laten zien dat standaarden juist een positieve invloed hebben op het internet.
Heb je al eens een pagina van google door de W3C validation gehaald?
62 Errors, 8 warnings.
Dingen als marginheight gebruiken kan nog, omdat niet css browsers het moeten kunnen lezen. Maar geen doctype declaration, Geen mime type, geen quotes gebruiken,...
De meeste errors zijn door geen quotes, en geen '& amp;' gebruiken in URL's.

[Reactie gewijzigd door Anoniem: 217577 op 22 juli 2024 15:58]

Hoeveel bandwidth denk je dat het google kost om een doctype declaration op hun hoofdpagina te zetten? En wat levert het op?
Het levert een beter gerenderde pagina op omdat de webrowsers nu terugvallen op de quirks mode, met alle onvoorspelbare gevolgen van dien. Heel knap van Google nog dat ze een quirks gerenderde pagina in alle browsers nog leesbaar hebben weten te maken.
Waarschijnlijk heeft het niet hele grote gevolgen, omdat de homepage van Google niet echt een ingewikkelde pagina is.
Och, ze pretenderen in ieder geval niet aan een bepaalde richtlijn te voldoen. De overgrote meerderheid van pagina's op het web die dat wel doen (as in: wel een doctype hebben) valideren ook niet...
Geldt dit ook voor de JavaScript engine?
Ik blijf het stom vinden dat IE de enige browser is die bij document.getElementById niet naar het id attribuut kijkt maar naar het name attribuut.
Ik blijf heel veel aan IE stom vinden. Trident is echt compleet achterhaald.
Wanneer er alleen een ID element is, geeft document.getElementById het goede object. Sterker nog, in IE is het mogelijk ID.Method te gebruiken, best handig.
crisp Senior Developer @WinL7 november 2008 23:32
best handig
Juist niet handig want het is global namespace vervuiling en daarmee een bron van veel (potentiele) bugs...
En ik blijf het stom vinden dat sommige mensen (nou ja, sommige) zomaar wat in het rond blaten zonder (schijnbaar) enige kennis van de materie te hebben...
Want IE kijkt wel degelijk naar het id-attribuut wanneer je getElementById(...) gebruikt!

Wat ik nog stommer vind; is dat een heleboel "programmeurs" deze functie in de vorm document.getElementById(...).value (o.i.d.) gebruikt, en dus niet eerst controleert of er wel daadwerkelijk een object teruggegeven/gevonden is (wat in deze vorm direct tot een Javascript-fout zal leiden wanneer dit niet het geval is)!?!
Waarom zou je die check doen? Als bezoekers dezelfde pagina krijgen als die jij hebt gemaakt, kan dit haast niet fout gaan.

Als het wel fout gaat komt het dus doordat iemand zelf de pagina aan heeft gepast (met bijvoorbeeld een GreaseMonkey-script) en het element niet bestaat.
Moet je met dat soort dingen dan rekening gaan houden?
Interessant maar geloof nooit dat MS hier echt veel vaart van zal maken aangezien het natuurlijk ook direct impact heeft op de prestaties van Frontpage en de webfunctionaliteiten van andere Office pakketten die allemaal nog massaal IE (-only) compatible code genereren... :S
Ten slotte zou de softwaregigant ook de vlotte javascript-engine Sproutcore kunnen integreren, waardoor de browser beter overweg kan met webapplicaties.
Hier worden een aantal dingen door elkaar gehaald volgens mij.

Sproutcore is geen onderdeel van WebKit, sproutcore is een javascript/ajax framework voor het bouwen van webapps en heeft verder niet zo veel met WebKit te maken.

De supersnelle Javascript engine van WebKit heet SquirrelFish Extreme.

Op dit item kan niet meer gereageerd worden.