7min

We staan aan de vooravond van een nieuwe browseroorlog, om precies te zijn een browserengine-oorlog. De nachtmerrie van alle webontwikkelaars wereldwijd zou weleens uit kunnen komen als grote jongens als Google, Apple, Microsoft en Mozilla op de huidige voet verder gaan. De afgelopen jaren is het internet min of meer gestandaardiseerd door Google’s intensieve werk aan de zogenaamde WebKit-engine, waar veel fabrikanten en ontwikkelaars dankbaar gebruik van hebben gemaakt. Ook heeft Microsoft eindelijk het licht gezien en heeft het zijn browserpuinhoop grotendeels opgeruimd en ervoor gezorgd dat Internet Explorer zich eindelijk meer is gaan conformeren aan de webstandaarden.

Eindelijk hoeven webontwikkelaars niet langer hun websites voor drie verschillende browserengines te ontwikkelen, maar werkt het in de meeste gevallen meteen. Na jaren van hacks op hacks om Internet Explorer 6 en 7 te ondersteunen, lijken alle browserengines eindelijk redelijk in lijn te lopen.

Om de een of andere reden is er recent een nieuwe concurrentiestrijd losgebarsten en gaan huidige samenwerkingen op het gebied van browserengines in rook op, ontstaan er ook nieuwe, maar is de kans dat dat webontwikkelaars uiteindelijk de dupe worden en over een paar jaar weer websites mogen ontwikkelen voor verschillende browserengines veel groter geworden. Hoe kan dat en waarom? Wie heeft daar baat bij?

Wat is een browserengine?

Elke browser, of het nu Internet Explorer, Firefox, Chrome, Opera of Safari is, bevat een zogenaamde browserengine. Deze engine vertaalt de HTML-, CSS- en Javascript-code naar een website en toont het resultaat op je scherm. Elke browserengine doet dit op zijn eigen manier, maar de bedoeling is dat dit gebeurt volgens de webstandaarden. Dit is iets wat op dit moment redelijk goed geregeld is, sinds enkele jaren. Daarvoor was het echt een ramp. Elke webontwikkelaar moest voor elke browserengine aanpassingen doen aan een zijn of haar ontwikkelde website, om het allemaal vlekkeloos te laten werken in de verschillende browsers. Dit kostte uiteindelijk een hele hoop extra werk voor elke website die ontwikkeld werd.

Geschiedenis

Een van de eerste browserengines in de jaren ’90 was Raptor, later werd dit veranderd in NGLayout en daarna werd dit Gecko. De eerste browser die hier gebruik van maakte was Netscape, Netscape was echt een megasucces, echt iedereen gebruikte in die tijd deze browser. Netscape werd uiteindelijk overnomen door America Online (AOL), maar de Gecko-engine werd ondergebracht in de Mozilla Organization. Uiteindelijk ontstond de Firefox-browser in 2003, toen AOL alle ontwikkelaars ontsloeg die nog aan de Gecko-engine werkten.


Na de lancering van de Netscape-browser en het succes dat volgde, realiseerde Microsoft zich dat het de boot had gemist. Microsoft ging de concurrentie aan door in Windows 98 een eigen browser mee te leveren, Internet Explorer. Internet Explorer gebruikte de MSHTML-engine die later werd omgedoopt tot Trident. Microsoft is altijd trouw gebleven aan de eigen Trident-engine, soms ook tegen beter weten in. De laatste jaren heeft Microsoft echter grote stappen gemaakt met deze engine en is de ondersteuning voor CSS3 en HTML5 flink toegenomen.


In de periode dat Netscape en Internet Explorer het levenslicht zagen, verscheen er ook een browser voor Linux-systemen genaamd Konqueror, deze gebruikte weer een andere engine: KHTML. Deze engine is de basis voor veel bestaande browsers, op 25 juni 2001 besloot Apple een eigen versie (fork) te maken van KHTML en deze zelfstandig verder te ontwikkelen. Deze versie kreeg de naam WebKit en Apple gebruikte deze engine voor de Safari-browser in Mac OS X. In 2005 besloot Apple om de WebKit-engine opensource te maken zodat ook andere ontwikkelaars bijdragen konden doen aan de engine. Ook zouden andere partijen een browser kunnen ontwikkelen op basis van WebKit.


De belangrijkste partij die uiteindelijk besloot om een browser te bouwen op basis van WebKit is Google. Dat bedrijf kwam in 2008 met de Chrome-browser, gebaseerd op WebKit. Google is enorm belangrijk geweest voor de WebKit-engine, want hoewel Apple de basis heeft gelegd, is het Google die de afgelopen jaren de engine naar een hoger plan heeft getrokken. Zo werd recent bekend dat het afgelopen jaar 50 procent van de nieuwe code in de WebKit-engine afkomstig is van Google, 25 procent van Apple en 25 procent van de community.

Tot slot is er ook nog de Opera-browser, die jarenlang met een eigen engine heeft gewerkt. De Opera-browser verscheen in 2003 en maakte gebruik van de zelfontwikkelde Presto-engine. Recentelijk maakte Opera bekend de ontwikkeling van Presto te staken en over te stappen op de WebKit-engine.

Wellicht denk je bij jezelf, maar ik heb ook nog andere browsers gehad in de afgelopen 10 jaar. Dat kan kloppen, er zijn nog vele tientallen browsers verschenen. Deze maakten echter grotendeels gebruik van één van de engines die hierboven zijn beschreven.

Toekomst

Zoals je hebt kunnen lezen waren er de afgelopen jaren dus vier belangrijke browserengines; Trident (Internet Explorer), Gecko (Mozilla Firefox), WebKit (Chrome en Safari) en Presto (Opera). Er zijn echter een aantal aankondigingen geweest in de laatste weken en die gaan grote gevolgen hebben voor deze browserengines en de bijbehorende browsers.

Zo heeft Mozilla aangekondigd dat het werkt aan een nieuwe browserengine, genaamd Servo. Servo wordt samen met Samsung ontwikkeld in de vrij nieuwe programmeertaal Rust. Servo wordt omschreven als de browserengine van de volgende generatie. Belangrijkste pijlers lijken daarbij te zijn dat de engine gebruik kan maken van meerdere rekenkernen in processoren en dat de engine beter werkt op alternatieve architecturen, zoals op de ARM-chips in veel mobiele apparaten. Mozilla heeft laten weten dat het niet verwacht dat Servo uiteindelijk Gecko compleet zal vervangen, de toekomst zal het echter leren. In elk geval zullen we Servo terug gaan zien op mobiele apparaten, aangezien daar Samsung’s grootste kracht ligt.


De grootste veranderingen vinden echter plaats met WebKit. Deze browserengine lijkt uiteen te vallen in twee grote stukken. Google heeft besloten een eigen fork van WebKit te maken, genaamd Blink. Google heeft in Chrome een zogenaamde "multi-process architecture" ontwikkeld, deze zorgt ervoor dat er gelijktijdig meerdere los van elkaar functionerende processen een webpagina kunnen renderen. Het zou steeds complexer worden om die goed te laten samenwerken met WebKit en daardoor wordt de innovatie vertraagd, met een eigen engine kan Google dat helemaal stroomlijnen omdat het dan geen rekening hoeft te houden met andere fabrikanten die WebKit op een hele andere manier inzetten. Zoals wellicht Apple’s Safari. Dat Apple geheel toevallig recent de merknaam WebKit heeft vastgelegd zou er wellicht ook wat mee te maken kunnen hebben, maar hierover rept Google met geen woord.

Het gevolg zal echter zijn dat de ontwikkeling van de WebKit-engine nu in twee grote stukken valt. Gezien Google het afgelopen jaar 50 procent heeft bijgedragen aan de WebKit-engine, zal die engine nu een stuk langzamer worden doorontwikkeld. Apple droeg het afgelopen jaar 25 procent bij aan de WebKit-engine en wordt hierdoor nu gedwongen de browserengine actiever door te ontwikkelen. De community die de overige 25 procent heeft bijgedragen zal waarschijnlijk in stukken vallen, het ene deel zal kiezen om te ontwikkelen voor Google’s Blink, het andere zal trouw blijven aan WebKit. Opera, die recent besloot in WebKit te stappen, zal ook niets bijdragen. Zij kiezen ervoor Google te volgen en Blink te gebruiken. Apple zal dus harder moeten gaan trekken aan WebKit om met Safari een goede browser te kunnen blijven bieden.

Slachtoffers

Degenen die uiteindelijk het grootste slachtoffer kunnen worden van deze ontwikkeling, zijn de webontwikkelaars. De browserengines zijn dadelijk stuk voor stuk bijna allemaal projecten van een enkel groot bedrijf. De kracht van WebKit was dat Google niet zomaar zaken kon toevoegen buiten de webstandaarden, omdat Apple daarop tegen was en andersom gold hetzelfde. De bedrijven hadden elkaar min of meer in een houdgreep en alleen de normale webstandaarden waren de tussenweg. Het gevolg was echter dat webontwikkelaars hierdoor meer gingen focussen op WebKit en andere browserfabrikanten genoodzaakt waren ook sneller de nieuwe standaarden te ondersteunen. Doordat deze houdgreep nu weg is, lijkt die noodzaak ook verdwenen.

In de toekomst komen er ongetwijfeld nieuwe standaarden en de kans bestaat dat bedrijven dan hun eigen belangen boven de webstandaarden stellen en er daardoor weer grote verschillen ontstaan tussen de browserengines. Bijvoorbeeld dat de implementatie van een nieuwe standaard net even anders wordt gedaan omdat dat handiger is voor bepaalde diensten van het bedrijf zelf. Hierdoor zullen webpagina’s standaard wel goed werken in de ene browser en weer niet in de andere, of het ziet er in de ene browser goed uit en in de andere staat alles door elkaar. Gebruikers die een website bezoeken verwachten echter dat het met alle browsers goed werkt. Soms zal dit niet op te lossen zijn en soms zullen de webontwikkelaars met kunst- en vliegwerk dit soort zaken moeten oplossen.

Google bevestigt eigenlijk de problemen al min of meer op voorhand. De zoekgigant verwacht dat doordat het zich afsplitst van WebKit de browsers sneller zullen gaan innoveren. Waarschijnlijk zal Google dan dus zelf heel snel gaan innoveren. De ervaring leert ons echter dat andere browsers dan niet direct zullen volgen. Als er dan een goede innovatie komt, is het wachten op ondersteuning van de rest. Maar moeten we dan Google de schuld geven, of de partijen die achterblijven? In elk geval is de tijd voorbij dat een heel groot deel van de internetters gebruik maakt van WebKit, dit gaat de komende maanden in rap tempo veranderen. De invoering van de Blink-engine vindt op het moment van schrijven al over 10 weken plaats.

Op korte termijn hoeven we niet al teveel problemen te verwachten. Alle browsers hebben net de ondersteuning voor HTML5 en CSS3 voor het grootste gedeelte doorgevoerd. De problemen liggen echt in de toekomst bij wat er nog gaat komen. Verder is het afwachten of Apple in staat is om WebKit goed door te ontwikkelen, dat is vooral voor Apple zelf belangrijk, omdat je bijvoorbeeld op de iPhone en iPad geen echt alternatief hebt, althans niet qua engine.