Mozilla komt in juni met alfaversie van browser met nieuwe engine

Mozilla-ontwikkelaar Paul Rouget heeft laten weten dat er in juni een alfaversie verschijnt van Browser.html. Dat is een nieuwe browser, die gebaseerd is op de Servo-browserengine, waar Mozilla en Samsung al enkele jaren samen aan werken.

Voordat de alfaversie in deze zomer kan worden uitgebracht, moeten er nog flink wat bugs aangepakt worden. Rouget wil zorgen dat in ieder geval GitHub, DuckDuckGo, Hacker News en Reddit goed werken met de release. Er zijn nog diverse issues met het weergeven van deze websites in de Servo-engine die moeten worden opgelost.

Browser.html is een experimentele browser van Mozilla waarvan de interface zelf uit html bestaat. De browser wordt gemaakt bovenop de nieuwe Servo-engine, die van de grond af aan wordt opgebouwd. Servo moet de vervanger worden van Gecko, de browserengine waar Firefox op is gebaseerd, die uit 1997 stamt.

De nieuwe engine wordt geschreven in de programmeertaal Rust, een taal die Mozilla zelf ontwikkeld heeft met het oog op veiligheid. Servo wordt geoptimaliseerd voor moderne hardware en moet zowel op ARM- als x86-chips werken.

Google-ontwikkelaar Jake Archibald demonstreerde onlangs de performance van de render engine, die dankzij gpu-versnelling veel sneller is dan de nieuwste versies van Chrome, Safari en Firefox.

Reacties (76)

De demo op zich vind ik er impressive uitzien als je het zo naast de andere browsers ziet, en in theorie klinkt het als een goed concept om weer eens even met 'een schone lei' te beginnen. De vraag is of dit specifieke aspect van de browser (renderen van dynamische content) kenmerkend is voor de browser-ervaring in zijn geheel. Ik begrijp dat GPU-versnelling sterk meespeelt in de browser-ervaring, maar welke niet-dynamische elementen kunnen er bij het renderen van een pagina daadwerkelijk door de GPU versneld worden?

Voor zover ik het begrijp wordt de GPU met name ingezet voor animatiewerk, en voor een deel van het renderen van pagina's. Dat is een belangrijk deel van de uiteindelijke ervaring, maar zeker niet het enige dat van belang is. Andere belangrijke factoren zijn bijvoorbeeld hoe snel de browser de resources inlaadt, hoe snel html en css geparsed worden, tot in hoeverre javascript geoptimaliseerd wordt bij uitvoer en welke technieken / standaarden er ondersteund worden. Verder zijn natuurlijk stabiliteit en veiligheid belangrijk, en zo nog meer zaken. Oftewel: er valt nog niet te zeggen hoe goed deze browser wordt ten opzichte van de huidige. Daarvoor hebben we op z'n minst hands-on-ervaringen met de alfa-versie nodig.

Het feit dat de browser nieuw is opgebouwd, met het oog op recente hardware, klinkt op zich veelbelovend, samen met de demo in het artikel. Voor mijn gevoel doen de huidige browsers hun werk ook zeker niet onaardig tegenwoordig, zeker in vergelijking met IE6/7 bijvoorbeeld, maar als het beter kan dan is dat welkom. We zullen zien wat hier uit komt.

Ik denk dat we aan de vooravond staan van enorme wijzigingen in t webplatform:
1. De introductie van web assembly gaat zorgen voor veel kortere laadtijden voor equivalente websites, en gaat 1st class support voor andere PLs dan JavaScript mogelijk maken (op dit moment moeten Coffeescript, Dart ClojureScript etc naar Javascript compilen). Gister was er nog nieuws dat alle grote browser engines nu experimentele support hebben voor WASM.
2. Na Servo's uiteindelijke release (wat ik pas na 2016 zie gebeuren) zullen alle huidige browsers nogal sloom aanvoelen dus zullen Google et al ook niet stil blijven zitten. Met name renderen wordt sterk geparallelliseerd in Servo, maar de engine is ook een stuk minder vatbaar voor security leaks door het gebruik van Rust als programmeertaal ipv iets als C++.

Btw:
Bovenop dat snelle renderen wordt de GPU ingezet in de demo in het artikel, dus hoewel het indrukwekkend eruit ziet is het een beetje appels met peren vergelijken.

Als GPU meewerkt, is het interessant welke taal ze gebruiken. Meeste browser vallen al een stuk terug op de gpu, maar een browser opbouwen met dat in het achterhoofd zou veel dubbel programmeren onnodig maken.

OpenGL wordt door vrijwel alle hardware ondersteunt, bij de een wat beter dan de ander.
Je ziet dat elk OS een eigen interpretatie gebruikt, Windows valt terug op DirectX, Apple heeft Metal, Android Renderscript, maar Nvidia heeft cuda als extra en AMD heeft Mantle/Vulkan, en allemaal proberen ze dat beetje extra toe te voegen.

Wat ook interessant is, is om te weten of het als standalone kan werken. Een soort Chrome zonder google.

Vulkan?

Op dit moment wordt er gebruik gemaakt van OpenGL, maar Vulkan staat ook op de todo lijst.

https://github.com/servo/webrender/wiki#future-work

Het lijkt me uitgesloten dat een Open Source en Open Standaard club als Mozilla een proprietary en vendor afhankelijke standaard als Cuda zal gebruiken. Als ze GPU computing willen inzetten zullen ze voor OpenCL kiezen.

[Reactie gewijzigd door Maurits van Baerle op 15 maart 2016 23:36]

Het feit dat de browser nieuw is opgebouwd, met het oog op recente hardware, klinkt op zich veelbelovend, samen met de demo in het artikel. Voor mijn gevoel doen de huidige browsers hun werk ook zeker niet onaardig tegenwoordig, zeker in vergelijking met IE6/7 bijvoorbeeld, maar als het beter kan dan is dat welkom. We zullen zien wat hier uit komt.

Het is meer dan veelbelovend: het is revolutionair en zeer gedurfd. Het maken van een nieuwe browser engine staat in complexiteit ongeveer gelijk aan een nieuw besturingssysteem.

De laatste keer dat een bedrijf zich hieraan heeft gewaagd is Opera met Presto bijna 15 jaar geleden. Microsoft durfde het niet aan met Edge en Apple was blij dat ze op KHTML konden voortbouwen met Webkit.

De voordelen zijn evident: gebruik maken van een moderne programmeertaal en vooral profiteren van parallelle uitvoering door de moderne multicore CPU's.

Het parallel uitvoeren van een webpagina en de GPU gebruiken voor het renderen is niet bepaald revolutionair. Dat zijn IE9 features.

Nee, maar dat beweer ik ook helemaal niet.

Wat dan wel? Het maken van een nieuwe engine? Edge heeft een nieuwe engine.

Voortgebouwd op Trident, geen nieuwe engine dus. Alle engines die nu draaien hebben hun oorsprong in de jaren 90.

edit:
Naar mijn weten is het parallelle karakter van Edge vrij beperkt. Vooral Chakra (JavaScript) dat verschillende tabjes in parallelle threads stopt. Bij Servo vinden verschillende componenten: HTML parsing, layout, etc echt parallel plaats.

Als dat voor Edge ook zo is, hoor ik het graag, maar ik had er in ieder geval nog nooit van gehoord.

[Reactie gewijzigd door snirpsnirp op 17 maart 2016 08:11]

Trident is met IE9 intern opgesplits in 2 delen. 1 voor "het oude internet" en 1 wat alle HTML5 features support en de nieuwe engine. Deze Engine is met IE9 van de grond af aan opgebouwd (enkel gebaseert op de oude Trident, en een paar stukken code hergebruikt gezien de engine niet voor alles anders tegen het OS hoeft aan te praten.

MS heeft met IE9 de trident engine compleet verbouwd. En al de oude meuk van Trident is met de overgang naar Edge gedropt. De engine in Edge heeft zijn oorsprong niet in de jaren 90, maar bij IE9. Daar zit geen stukje HTML4 of IE6 legacy meer in.

Overigens ook bij Edge wordt html/css en zelfs DNS requests parralel uitgevoerd, dat deed IE9 al.

Het fijne is wel dat bij deze nieuwe browser die zich nog mag gaan bewijzen, de ontwikkelaars jaren lange ervaring hebben. Ik ben blij dat Mozilla een poging doet voor een nieuwe frisse stap

En, minstens zo interessant: waarom zou precies dezelfde techniek niet in Firefox kunnen werken?

Het hele probleem met producten en het moeten onderhouden/ontwikkelen van een product is natuurlijk dat je wilt dat andere mensen en partijen met je samen werken om zo een groter publiek te kunnen bereiken. Denk hierbij aan technieken voor plug-ins, extensions, maar ook API's en SDKs. Het gevolg is dat hoe meer partijen er afhankelijk zijn van plan het functioneren van een SDK of API op een bepaalde manier, hoe lastiger het is om de onderliggende implementatie te wijziginen of om te gooien zonder hiermee problemen te veroorzaken voor je partners/klanten.

In dit geval gaat het dus om een nieuwe engine, bestaande extensies kunnen hiermee dus waarschijnkijk direct de deur uit, tenzij er een soort compatibility module komt voor legacy plug ins. En dan nu de hamvraag: als Firefox morgen met een update komt voor de engine, maar al je plug ins daarmee onklaar gemaakt worden omdat ze gebruik maken van functionaliteit die niet in de nieuwe engine zit, zou je dan blij zijn met deze update? Ik vermoed dat voor veel mensen het antwoord "nee" zal zijn.

Ik zeg niet dat het niet kan (Google heeft immers ook een transitie gemaakt Van Webkit naar Blink, maar dit kon omdat Blink een fork van Webkit is), maar het is wel verdomd lastig om iedereen te geven wat ze verwachten van je product, en tegelijk te innoveren.

Gaan ze dan toch misschien Gecko vervangen door Servo? Dit was toch eerst niet de bedoeling, maar twee browsers langs elkaar ontwikkelen is toch ook erg vreemd.

Servo is als experiment begonnen om te kijken of parallellisatie de browser sneller maakt en of de gebruiker een gevoel van meer snelheid krijgt. Huidige engines maken hier geen gebruik van omdat de roots van alle in de jaren 90 ligt en parallellisatie onbedenkelijk was. Het vraagt om een grote verbouwing om het in te bouwen. Je noemt namelijk het bouwen van de render three, style three, style calculation, painting, etc allemaal parallelliseren.

Browser.html is begonnen als experiment om te kijken of het mogelijk is om een gehele browser ui in html te schrijven. Al snel kwamen deze dus samen.

Gecko deelt al code met Servo en er zou ergens dit jaar ook een proefversie van Firefox OS met Servo gemaakt worden.
Mozilla is ook bezig XUL uit te faseren en te gaan vervangen voor of native of html5. Het kan best zijn dat servo gecko gaat vervangen en browser.html laat blijken of een UI in html5 de gewenste resultaten oplevert.

Daarnaast is servo in rust geschreven, wat het parallelliseren een stuk makkelijker maakt. Met C++ gaat dit een stuk lastiger.

http://bholley.net/blog/2...-multi-threaded-code.html

Ik vraag me af hoe de CSS 3 animaties hierop draaien als de browser draait op een rpi, ongeacht welke, CSS 3 animaties zijn langzaam.

[Reactie gewijzigd door Brantje op 15 maart 2016 22:21]

CSS3 animaties zijn juist NIET langzaam, afgezet tegen andere vormen van animatie op het web.

Dat is de ervaring van veel mensen omdat ze voor JS animaties leunen op JQuery. Dat is een prima JS library maar alles behalve licht of snel, zeker voor animaties. Wanneer je JS engines gaat gebruiken die speciaal zijn ontwikkelt voor vloeiende animaties, blijkt dat die vaak even snel tot significant sneller zijn dan CSS3 animaties. Tevens biedt JS natuurlijk veel meer flexibiliteit.
Zie voor wat testen bijv. https://css-tricks.com/my...animations-vs-javascript/

Belangrijker dan of je Javascript of CSS3 voor animaties gebruikt is op je ze goed gebruikt. Als je reflows veroorzaakt en/of geen of op een niet handige manier hardware acceleratie triggered dan gaan je animaties er minder soepel of zelfs schokkerig uit zien. Het over elkaar animeren van wel en niet hardware accelerated elementen zal bijvoorbeeld ook niet soepel gaan.

Daarnaast zijn er typen animatie die je simpelweg nog niet (of niet in alle browsers) via CSS3 kan. (zoals combinaties van rotatie en verplaatsing, gradient fades of geanimeerde uitsnedes van afbeeldigen).

Dit soort punten kwamen we vaak tegen bij de ontwikkeling van de Fabulous by Douglas online (desktop / iPad) magazine. Hier hadden we 10 issues van gemaakt en toen hadden we een redelijk inzicht in wat wel en niet soepel animeerde op desktop browsers en iOS.

De site die je vermeld meld terecht dat er nog wel wat flexibiliteit mist in CSS3 (los animeren van allerlei translatie/rotatie eigenschappen die je niet via losse properties kan animeren).
Ik vind echter wel dat een deel van de punten die hij meld (zeldzame?) rendering issues zijn die in de toekomst weer opgelost zullen worden.

Overigens zet ik Javascript componenten (vooral die moeten animeren) zonder enig framework op, want al die abstractie verbergt wat er gebeurt. Vroeger vondt ik het mooie aan 680x0 assembler op de Amiga al dat je zo duidelijk zag hoe alles werkte en waarom. Als je dichter op de werking van iets zit, zie je de pijnpunten en kan je je code/animaties beter en sneller maken... Zeggen dat CSS3 of Javascript of een of ander animatie framework voor het beste resultaat zorgt is eigenlijk helemaal niet zo veel zeggend.

[Reactie gewijzigd door spellcoder op 16 maart 2016 11:50]

Zie voor wat testen bijv. https://css-tricks.com/my...animations-vs-javascript/

Lekker biased dan: de auteur van dat artikel is de ontwikkelaar van één van de grootste commerciele JS animation frameworks, welke nog steeds actief verkocht wordt.

CSS animaties zijn wel degelijk vloeiender (en gebruiken minder resources) dan JS animaties, zolang de eigenschappen die je animeert, compositing-only zijn.

Paul Lewis' [url=https://aerotwist.com/blog/flip-your-animations/]FLIP (First Last Invert Play) methode[/i] is een heel mooi voorbeeld van hoe je daarmee om zou gaan.

[Reactie gewijzigd door R4gnax op 16 maart 2016 00:25]

De auteur van dat artikel heeft een punt in ieder geval dat het iets ingewikkelder ligt:

- het hangt heel erg af van de aard van de test
- het hangt af van de browser en het device

Toch toont hij absoluut niet aan dat JS vaak sneller is, slechts in een specifiek geval. Ook toont hij niet aan dat CSS3 animaties langzaam zijn, wat mijn reactie was op de stelling dat dat wel zo is.

Kortom: it's complicated, it depends.

Als je snelheid zoekt, dan valt alles in het niet tov velocity js. Is dan ook aanzienlijk sneller dan jquery+css.

CSS3 animaties draaien AFAIK op de gpu indien mogelijk. Op een rpi zal dit dus problematisch zijn als hij geen goede support daarvoor heeft.

Aangezien het voornaamste voordeel van deze engine voornamelijk de gpu support lijkt te zijn verwacht ik ook geen turbospeed op rasberries...

[Reactie gewijzigd door Ed Vertijsment op 15 maart 2016 21:16]

Bij deze demo niet, maar die toont maar 1 aspect van de nieuwe engine. Het tweede grote voordeel is dat, mede dankzij Rust, de engine veel meer multithreaded is. Dat zal ook (of zelfs vooral) op een RPi een significante verbetering geven omdat die toch sinds een paar jaar quad-core zijn...

Deze nieuwe engine kan de markt positie van Mozilla compleet veranderen - ze zullen weer de snelste zijn en vooral op low-cost mobieltjes met 4 of 8 langzame cortex a53 cores ga je dat merken

"Google-ontwikkelaar Jake Archibald demonstreerde onlangs de performance van de render engine, die dankzij gpu-versnelling veel sneller is dan de nieuwste versies van Chrome, Safari en Firefox."

Dus: Mozilla maakt een render-engine, en Google demonstreert de snelheid ervan?

Is er toch nog liefde tussen Mozilla en Google?

Jazeker, Google medewerkers die aan "het web" werken zijn behoorlijk objectief. Ze werken goed samen met andere browser bouwers en leveren ook ongeneerd kritiek op hun eigen browser.

Google heeft een groot belang bij een goed werkend en snel ladend internet. Dat beteken crux gezegd dat ze meer advertenties kunnen tonen en betere profielen kunnen opbouwen met gebruikers tracken in dezelfde tijd.

Met Samsung? Het is toch wel volledig GPL?

Firefox is ook geen GPL maar Mozilla Public License, net als dit.

Ik denk dat het adagium 'nieuw is beter' alleen al uit marketing oogpunt beter bekt dan refactoring van (al bewezen) code. Het is een feit dat nieuwe code meer bugs bevat dan oude code die al gestabiliseerd is. Het zal niet de eerste keer zijn dat nieuw != beter is. We wachten af. En eigenlijk zou je willen weten wat de motieven waren om van de oude engine naar een nieuwe te willen overstappen...

In tegenstelling tot mechanische dingen slijt software niet . En sommige programmeerconcepten staan al 10-tallen jaren als een huis. Je moet dus betere argumenten hebben om met iets nieuws te willen beginnen. Waar het (wellicht terecht) optimisme 'nieuw is beter' in diverse reacties hierboven is gebaseerd is me onduidelijk.

Nieuw is zeker niet altijd beter, maar verbeteringen als complete multithreading-support kan je niet of nauwelijks in bestaande software bouwen.
Dan kan je beter opnieuw beginnen.

Dat is eigenlijk kiezen tussen 2 kwaden. Als je met omvangrijke software te maken hebt, is de keuze 'thread-aware maken' of nieuw-beginnen-en-direct-thread-safe programmeren op voorhand bijna niet goed in te schatten. Thread-issues debuggen is altijd complex. Met opnieuw te beginnen is de code mogelijk minder complex te debuggen.

Maar refactoren van bestaande naar thread-safe code is zeker wel ook mogelijk. Zeker als je bottom-up werkt (low-level functies/interfaces/primitieven eerst, daarna adoptie door de hogere lagen). Waar je meer last van hebt is de mind-set van de programmeurs van de oude code (niet thread-safe mindset, soms) en de kennis van de programmeurs die de nieuwe code schrijven van de oude code (als je een compatibel nieuw product moet maken).

In theorie zou waar kunnen zijn dat het schrijven van nieuwe code mogelijk beter direct op multi-threading ge-ent kan zijn. Edoch: als je van single-threaded naar multi-threaded overstapt is de laatste per definitie complexer. Thread/race condities zijn bijzonder lastig te debuggen (en fouten worden (juist) ook in nieuwe code gemaakt).

Zeker, maar het fundament van software kan zo oud en complex (over tijd) zijn dat je beter van een schone lei kan beginnen om alle fouten ed eruit te halen.
Het grote nadeel is dat dit veel werk is en inderdaad grote kans op fouten.
Maar je kan nu eenmaal niet blijven door bouwen op een oud fundament.

Ik denk dat je dat toch tientallen jaren volhoudt. Neem bijv. Windows, daar zitten nog steeds basiszaken uit lang geleden in. Idem Java. En zo zijn er best meer te noemen. Een goed fundament gaat echt (heel) lang mee. Te oud, te complex zijn allemaal signalen dat onderhoud er een ratjetoe van gemaakt heeft. Al is het soms leuk om toe te geven aan de drang om nieuw te maken (uiteraard in een andere programmeertaal, goed voor je eigen vaardigheden ).

Nu wil ik JAVA en Windows niet bepaald voorbeelden noemen van een goed fundament.........

Marktaandeel Windows is 80% of meer. Ondanks de gekkigheden in Windows, zul je wel rekening moeten houden met dit platform. En java op de backend is nog steeds een verdedigbare keuze.

Marktaandeel op de desktop Best wel groot verschil.
Dat ze veel gebruikt worden betekend niet dat de boel goed in elkaar zit.
Gelukkig heb ik persoonlijk bar weinig met Windows te maken en dat wil ik zo houden.

Nee Server.. Weliswaar op basis van wat ik op mijn werk (ERP backend) zie. Wereldwijd zal Linux in de webserver markt een fors aandeel hebben, waardoor daar de verhoudingen anders zullen liggen. Maar de aandelen AIX/Solaris/HPUX zijn sowieso klein t.o.v. Linux/Windows.

En ik denk dat je meer met Windows te maken hebt als je denkt. Er is genoeg infrastructuur (bank, overheidsinstellingen, backend etc etc) waar Windows op draait. En soms denk ik - helaas -... Ik werk zelf (doorgaans) liever op *NIX smaken, maar met Windows is (doorgaans) prima te leven.

Onder servers reken ik alle servers, dus ook de webservers.
Daar heeft Microsoft geen 80% , sterker nog ze zijn nog niet eens de grootste speler. Wat je ziet is uiteraard wel afhankelijk van waar je werkt.

Persoonlijk (werk, eigen bedrijf en privé) heb ik nauwelijks met Windows te maken en dat wil ik zo houden. Te veel gedoe voor een brak platform dat veel te veel onderhoud nodig heeft om te blijven werken.

Jammer genoeg heb ik nooit echt de behoeft om draaiende vierkantjes en rondjes te bekijken....op 60fps.

En al helemaal niet als dan de ventilatoren van mijn videokaart aanslaan...

Interessante vraag natuurlijk wat hardwareversnelling doet met het stroomverbruik van een systeem (met name voor mobiel gebruik interessant). Het volgend artikel https://helgeklein.com/bl...ration-browser-cpu-usage/ gaat onder meer daar dieper op in. Conclusie is dat hardwareversnelling niet altijd leidt tot meer efficiëntie.

[Reactie gewijzigd door resma op 15 maart 2016 22:18]

Mwa, moderne GPU's zijn zó snel dat je hier geen last van gaat hebben. Ook de iGPU van Intel.

De reacties kunnen lastig nog kortzichtiger worden dan deze.

Sneller renderen van moeilijke dingen die ook nog eens gecode zijn met css (radius, gradients, positionering) is voor alles en iedereen goed. Ook als je er een stuk minder op het scherm hebt.

Naar mijn mening test je hier een auto op een weg die hij nooit gaat rijden. Kom maar met een test waar ik het nut van zie. Dit is puur theorie.

Je ziet het nut niet omdat je niet probeert verder te denken:
- Op goedkope low-end apparatuur betekent dit dat ook daar websites snel en vloeiend kunnen laden.
- Technieken als deze maken het mogelijk dat websites complexer en dynamischer kunnen worden (= meer ontwikkelvrijheid).

Je kunt computers sneller maken door de hardware te versnellen of de load te verlagen. Of: beide.

Ik zie het nut niet omdat dit soort laboratorium tests in de praktijk vaak anders uit vallen.
Pak gewoon een low end telefoon en een camera en ga zware websites laden.
Zo test tweakers ook en lijkt mij ook de beste test.
Mijn telefoon browser kan super snel super zware dingen laden, bij elke website crast deze omdat geheugen vol zit....

Dat is echt iets anders. Het gaat erom dat de mast nu driemaal zo kort bezet wordt door jouw telefoon als de snelheid drie keer zo hoog is. Daardoor kunnen er drie keer zoveel telefoons tegelijk op de mast zonder snelheidsverlies.

Dus we moeten maar stoppen met ontwikkelen?

Lolbroek, het versnelt alles in de layout..

Hoeveel merk je daar van als je een normale website laad?

+ dat er langzaamaan steeds meer dingen grafisch mogelijk worden. Dus bijvoorbeeld ook games.

Stilstand is achteruitgang. Of wil jij animaties lekker met flash uitgerendered hebben?

Laat dat dan zien... dan hebben mensen ook gelijk iets van wow wat nuttig.

Iedereen die iets meer geïnteresseerd is in het web weet dat. Zoek eens op webgl example, of webassembly. Daarbij maak je zelf al gebruik van veel features zonder dat je het door hebt.

dat scrollen etc niet vertraagd, dus veel.

Héél erg benieuwd hiernaar! Ik draag Firefox al behoorlijk lang een warm hart toe, maar vond het (zeker op OSX) echt achteruit gaan de laatste tijd.

Hopen dat dit de performance weer een flinke boost geeft

Het maken van een render-engine is verschrikkelijk veel werk vanwege de enorme grootte van de HTML / CSS specificaties. Daarom heeft zelfs een bedrijf als Microsoft voor Edge geen nieuwe engine gemaakt maar slechts de oude IE engine ge-refactored.

Rust is een opvallende keuze, maar volgens mij konden ze met C++ hetzelfde resultaat bereiken als ze wilden. Door een compleet nieuwe taal te gebruiken zal het aantal ontwikkelaars afnemen. Nu dient men nog te bewijzen dat Rust inderdaad een veiliger browser oplevert.

De stap die Mozilla nu lijkt te maken (parallel processing en fatsoenlijke GPU acceleratie) heeft MS al met IE9 gemaakt.

En betrekking tot de HTML/CSS standaarden, dat is met IE9 al losgesplitst van het "oude" systeem. Met Edge zijn alle niet vernieuwde HTML(5) onderdelen gedropt, het mag dan officieel een fork wezen, de engine zelf heeft niets meer gemeen met zijn voorganger.

MS heeft een wat andere aanpak gebruikt, maar Edge was de eerste moderne browser. Mozilla lijkt nu de tweede te worden.

De Edge engine heeft heel veel gemeen met de oude want dezelfde bugs duiken daar ook op.

Wat mij betreft hoef je niet je render engine opnieuw te schrijven om 'modern' te zijn. Ik heb liever dat de huidige code goed werkt en getest is tegen memory management fouten.

[Reactie gewijzigd door ArtGod op 17 maart 2016 10:26]

Welke oude? Die in IE9-11? Want daar is het html5 render gedeelte van de engine dezelfde als die in Edge. Niet alles is verbouwd van IE11 - Edge.

Herschrijven moest gebeuren, Mozilla doet het nu ook, Google ontkomt er straks ook niet aan. De engines moeten van hun legacy meuk af willen ze optimaal gebruik maken van de huidige hardware.

Ik hoop dat deze engine mijn grootste probleem met de 2 huidige grote browsers oplost: dat het 10 gig per tab eet, wat werkelijk nergens op slaat. Maar ik heb er niet heel veel vertrouwen in

10gig per tab? Wat voer jij je browser voor voedsel?

bij wijze van he

Ik verwacht het tegendeel. Ontwikkelaars kunnen straks nog complexere websites maken die vloeiend draaien, dus ik verwacht dat ze dat zullen doen ook. Ik betwijfel of het de browser zelf is die verkwistend met geheugen omgaat. Hoeveel geheugen heeft jouw browser nodig voor bijvoorbeedl anybrowser.org?