Door Yannick Spinner

Redacteur

Ladybird-browser sprint naar alfa: 'Eerste versie is puur voor techmasochisten'

03-11-2025 • 06:00

105

Ladybird

Vanaf de zomer van 2026 moet het browserlandschap er een volledig nieuwe speler bijkrijgen met de alfarelease van een van de grond af aan opgebouwde nieuwe browserengine. Het opensourceproject Ladybird zou daarmee tegenwicht kunnen bieden aan de dominantie van de grootste drie: Googles Chromium, het aanzienlijk kleinere Apples WebKit en het nog kleinere Mozilla's Gecko. Vrijwel alle mainstreambrowsers zijn gebaseerd op deze drie. Maar voordat het zover is voor Ladybird, moet er nog een hoop gebeuren. Tweakers sprak met maker en bedenker Andreas Kling over de status van het Ladybird-project, de mijlpaal voor toelating in het iOS-ecosysteem en de laatste grote hordes voor de eerste publieke release van de opensourcebrowserengine.

LadybirdLadybirdLadybird

Apple-test

In de zomer van 2024 vertelde Kling voor het eerst aan Tweakers over zijn browserengineproject Ladybird, en sindsdien is er een hoop gebeurd. Onlangs haalde het project bijvoorbeeld een Apple-grens om op iOS toegelaten te kunnen worden. "Apple vindt iets een legitieme alternatieve browserengine als het onder meer een score van 90 procent haalt in de compatibiliteitstest voor webplatforms. Eerst konden we deze test helemaal niet draaien − dan crashte de engine − maar 1,8 miljoen tests later is het ons gelukt om aan een van die vereisten te voldoen."

Waarom Ladybird?

Kling wil met Ladybird een onafhankelijke browserengine maken, 'zonder miljarden te spenderen'. Voor hem is het project een manier om te bewijzen dat het kan. "Denk aan de four-minute mile: het doorbreken van het stigma dat mensen geen mijl in minder dan vier minuten konden rennen. Toen dat eenmaal ontkracht was, werd die psychologische barrière doorbroken." Hij hoopt dat meer ontwikkelaars dan hetzelfde proberen.

Toch benadrukt de initiatiefnemer dat de engine niet nadrukkelijk als een alternatief voor de grote drie bedoeld is. Het doel is om een onafhankelijke, goedkopere, opensourcebrowserengine te maken die 'de gebruiker op de eerste plaats zet'.

Volgens Kling was het uitgangspunt van de ontwikkeling echter niet om dit arbitraire getal te bereiken, maar om Ladybird geschikt te maken voor wat de ontwikkelaars dagelijks nodig hebben. "Mensen nemen het voor lief, maar de eerste keer dat we via Discord met elkaar konden praten was voor ons een enorme overwinning. Discord is een grote, zeer gecompliceerde webapp, dus dat is niet vanzelfsprekend. Hetzelfde geldt voor Uber Eats; we hebben een week samen gezeten om die app te laten werken. En als je dan voor het eerst een poppetje over een kaart ziet bewegen en iemand daadwerkelijk je eten komt brengen, dan geeft dat ontzettend veel voldoening."

Iedereen doet wat hij wil

Het team van Kling werkt dus vanuit eigen interesse, om dagelijks gebruikte apps als YouTube, GitHub, Gmail, Maps en Discord, en systemen als de PlayStation-controller werkend te krijgen in de browserengine. Dit is volgens de Zweed ook de insteek van zijn organisatie. "We hebben een simpele hiërarchie: iedereen doet wat hij wil. Het enige wat ik van de werknemers verwacht is dat ze iets doen dat het project vooruit helpt."

Volgens Kling is dat de enige manier waarop hij kan concurreren met de grote bedrijven: "Ik kan niet concurreren op salaris. Maar wat ik mijn werknemers wel kan bieden, is enorme vrijheid en de kans om bij de underdog te horen." Een jaar geleden had Ladybird een team van zes fulltimewerknemers; dat zijn er inmiddels acht. Ook werken er volgens Kling zo'n 250 vrijwilligers via GitHub aan het project.

Werknemers worden betaald door middel van no-strings-attacheddonaties van bedrijven en individuen aan de stichting Ladybird Browser Initiative. Die organisatie startte in de zomer van 2024 met een donatie van een miljoen dollar van GitHub-medeoprichter en -ceo Chris Wanstrath. Intussen zijn daar meerdere tonnen van andere bedrijven bijgekomen. "De donaties van individuen via bijvoorbeeld Donorbox zijn daarnaast maandelijks goed voor zo'n 3000 dollar, wat alleen al onze techkosten dekt. Verder moeten reserves ons ten minste 18 maanden lang door kunnen betalen, ook wanneer donaties plotseling zouden stoppen. Dat vind ik een veilige marge."

Windows-versie

Ladybird pcDe werknemers en vrijwilligers van het Ladybird-initiatief werken volgens Kling allemaal aan vakgebieden waarin zij op een hoog niveau kunnen werken. En als er niemand voor een specifiek vakgebied is, dan worden er bestaande bouwstenen gebruikt. "We stellen onszelf telkens de vraag: zijn we een expert op dit gebied? Zo ja, dan doen we het zelf, maar zo nee, dan is het in ieders voordeel om bestaande bouwstenen te nemen. Neem videocodecs of encryptielibrary's als voorbeeld: dat kunnen anderen veel beter, dus gebruiken we daar een openbare library voor. Want verplaats je eens in de schoenen van de gebruiker: zou jij een browser gebruiken voor onlinebankieren als er een huisgemaakt encryptieprotocol gebruikt wordt dat nooit op grote schaal getest is?"

Om diezelfde reden werd Ladybird in de eerste plaats niet voor Windows ontwikkeld; daar wist Kling naar eigen zeggen te weinig vanaf. Intussen durft hij met zekerheid te stellen dat een Windows-versie op den duur gaat lukken. "Onze community heeft een hoop werk verricht om Ladybird voor Windows mogelijk te maken; dat schiet enorm op. Veel van dat werk is al in onze codebase opgenomen. Er zijn genoeg stappen gezet om aan te tonen dat het niet super moeilijk zal worden om de engine uiteindelijk naar Windows te brengen." Desondanks ligt de focus vooralsnog op Linux en macOS.

Hoe maak je een browserengine?

Voor beide besturingssystemen is het proces van een browserengine maken vergelijkbaar. Het uitgangspunt is, zoals vermeld, het werkend krijgen van de belangrijkste apps en systemen. Dat doet het team volgens Kling door alles te reverse-engineeren. "Het web is onder de motorkap een aaneenschakeling van HTML, JavaScript en CSS, die samenwerkt op allerlei interessante manieren. Wij moeten achterhalen hoe."

Hij gaat verder: "Een browser is vergelijkbaar met een emulator en het web met een enorme collectie aan games; je moet kijken hoe een app werkt en je browserengine aanpassen om dit werkend te krijgen."

Ladybird Tweakers-bugfixLadybird Tweakers-bugfix

Ladybird-coo Jelle Raaijmakers wist een bug met de coördinaten voor SVG‑gradientfill te fixen, waardoor er in het Best Buy Guides-menu van de Tweakers Pricewatch geen visuele artefacten meer te zien zijn.

Kling noemt als voorbeeld YouTube. Hoewel het videoplatform nog niet optimaal werkt, geeft dat proces inzicht in hoe het Ladybird-team te werk moet gaan. "YouTube gebruikt een moderne media-api waarmee stukjes video naar de browser gestuurd worden. We hebben die api slechts gedeeltelijk geïmplementeerd, waardoor YouTube nog niet werkt. Maar het blijkt dat als we die gedeeltelijke api-implementatie verwijderen, YouTube via een ander systeem video's in een lagere kwaliteit stuurt. Dat ondersteunt de engine wel." Zo pluizen Kling en zijn team de werking van individuele apps uit om het werkend te krijgen met de browserengine.

Eindsprint

Tot en met de zomer van 2026 is het doel dus duidelijk: het Ladybird Browser Initiative wil alle populaire websites aflopen, zodat de browserengine zoveel mogelijk functionaliteit ondersteunt. Daarvoor hanteert Kling het 80-20-principe; 80 procent van de websites gebruikt 20 procent van de functies, dus daar wil het initiatief zich op richten.

Maar Kling belooft dat het tegen die tijd simpelweg niet uitmaakt wat de status van de engine is; er komt een alfarelease: "Onze voortgang is veelbelovend, maar wat de status ook is, op het beloofde moment publiceren we gewoon wat we hebben. Ik vind dat we de verantwoordelijkheid naar onze donateurs hebben om te laten zien waar we mee bezig zijn. Het is ook een goed moment voor ons om praktische feedback te gaan verzamelen."

Hij steekt echter niet onder stoelen of banken dat de verwachtingen vooral niet te hoog moeten zijn: "Het wordt een piece of shit. De gemiddelde gebruiker gaat de eerste versie verschrikkelijk vinden." Volgens Kling is de alfabuild bedoeld voor 'techmasochisten' en voor mensen die de browserengine puur uit technologische interesse willen testen en proberen, niet voor de gemiddelde gebruiker. Die doelgroep moet volgens de huidige planning ergens in 2028 bediend worden, want dan staat vooralsnog de volledige release van Ladybird gepland.

Ladybird banner

Redactie: Yannick Spinner • Eindredactie: Monique van den Boomen

Reacties (105)

Sorteer op:

Weergave:

"We hebben een simpele hiërarchie: iedereen doet wat hij wil. Het enige wat ik van de werknemers verwacht is dat ze iets doen dat het project vooruit helpt."
(...)
Werknemers worden betaald door middel van no-strings-attacheddonaties van bedrijven en individuen aan de stichting Ladybird Browser Initiative.
Hoe voorkomt men dat dit de Star Citizen onder de browsers wordt? Zachte beloftes zijn makkelijk om uit te stellen. Het is een publiek geheim dat voor Star Citizen financiering van de ontwikkeling het doel is, niet een bruikbare versie 1.0. Dat wordt dus steeds uitgesteld, want financiering komt in gevaar als dat uit zou komen.

Verder zijn er twee bruikbaarheidszaken zaken voor mij belangrijk in browsers:
• Compatibiliteit. Als sites die ik gebruik niet werken dan is het waardeloos.
• Uitbreidbaarheid. Geen onbegrensde uBlock Origin of equivalent is geen deal. Het moderne internet is rioolwater. Er moet veel gebeuren om daar drinkwater van te maken.

Zolang het FLOSS is vertrouw ik erop dat de rest wel goed komt.
Hij gaat verder: "Een browser is vergelijkbaar met een emulator en het web met een enorme collectie aan games; je moet kijken hoe een app werkt en je browserengine aanpassen om dit werkend te krijgen."
Dit is een interessante ontwikkelfilosofie. Mijn eerste gedachte toen ik dit las was "keep calm and follow the standards". Met andere woorden: werk bottom-up en ondersteuning komt vanzelf wel.

Nu ik er wat meer over nadenk, valt er ook wat te zeggen voor top-down. Zo wordt bijvoorbeeld Wine/Proton ontwikkeld. De compatibiliteit daarvan is bijzonder goed, ook voor zaken waar nog nooit iets expliciet voor ontwikkeld is. Een voordeel is dat het zo makkelijker wordt om tot een minimal viable product te komen, wat beter is voor marketing en financiering.

Een browser die voor 99,9% compatibel is met standaarden maar die niet de top 10 populaire websites ondersteunt zal nooit voldoende gebruikers trekken. Ondersteun de 10 populairste websites en er zal veel meer interesse zijn. Het is niet alsof die ontwikkeltijd volledig exclusief voor die 10 sites zal zijn. Ondersteun iets als DASH voor YouTube en het zal daana niet veel extra ontwikkeltijd kosten om het compatibel te maken met andere sites.

[Reactie gewijzigd door The Zep Man op 3 november 2025 07:35]

Mijn eerste gedachte toen ik dit las was "keep calm and follow the standards".
Dat zullen ze ook doen, probleem is echter dat niet alle standaarden even strict of zelfs duidelijk zijn. De SVG standaard (om maar een voorbeeld uit het artikel te nemen) bijvoorbeeld is dat wel. Ergens een klein rekenfoutje zorgt dan voor zulke gekke bugs, maar met SVG heb je wel een houvast en dat kan relatief op zichzelf staand gedaan worden.

Maar er zijn vele W3 standaarden die wel duidelijk functionaliteit beschrijven, maar waar je vervolgens 7 andere standaarden bij nodig hebt om alles in het grote geheel juist werkend te krijgen. Dus die implementeer je en dan zijn de grote web apps inderdaad de beste manier om te kijken wat je nog mist, waar je bijvoorbeeld een hiërarchie fout hebt, welke optionele functionaliteiten missen. Want dat is ook best een dingetje, er is veel "optioneel" op papier, maar in de praktijk niet.

En er is genoeg functionaliteit die veel gebruikt wordt omdat het in alle browsers ondersteund wordt...met een prefix (-webkit-*).
Waar je als browser engine ontwikkelaar nu tegenaan loopt, wat vergelijkbaar is met het maken van een (retro hardware) emulator: bestaande producten (websites, games) zijn mede gebaseerd op flaws, bugs en ongedocumenteerd gedrag van het bestaande platform.

Om dus optimaal compatibel te zijn moet je helaas niet de standaard maar de bestaande implementatie volgen. Frustrerend en onlogisch maar volgens mij ook wel een zeer interessante uitdaging!
Mbt het web zou je twee engines kunnen leveren; de ene is jouw eigen perfecte supersnelle engine die alleen goed werkt met standards-compliant html/css/js, als het detecteert dat er iets niet compliant is valt ie terug op een engine die veel meer workarounds voor dat soort dingen heeft, zoals Chromium.

Maar dan zal ik wel te moeilijk nadenken. Ik ben er vrij zeker van dat ook Chromium en gerelateerde engines een "fast" en "slow" code path hebben voor dit soort situaties.
In o.a. Internet Explorer had je altijd ook zoiets, daar noemden ze dat "quirks mode".
Het grote verschil tussen browser (of het web) en emulators is dat er voor het web wel standaarden bestaan. Er zijn beschrijvingen van hoe het moet werken. Het klopt inderdaad wel dat browser bugs soms door sites omzeild worden, maar het lijkt mij een vreemde manier om een standaard gebaseerde technologie als emulator aan te pakken. Het zal resulteren in een werkende browser, tot er een site komt die niet meer werkt, want hij baseerde zich wel op de standaarden.

Het is logisxher om eerst de standaarden te implementeren en dan de site specifieke fixes aan te pakken, want die zullen voor een kleine nieuwe browser sws nodig zijn. Als snap ik wel dat deze manier van werken voor een klein team sneller resultaten geeft. Ik vrees alleen dat de engine een hoop spaghetti wordt hierdoor. Als er later een nieuwe standaard uitkomt kan het heel goed zijn dat er op 100 plekken in de code dingen aangepast moet worden, juist omdat nu alles ad hoc gefixt wordt ipv Structureel.
Hoe voorkomt men dat dit de Star Citizen onder de browsers wordt? Zachte beloftes zijn makkelijk om uit te stellen. Het is een publiek geheim dat voor Star Citizen financiering van de ontwikkeling het doel is, niet een bruikbare versie 1.0. Dat wordt dus steeds uitgesteld, want financiering komt in gevaar als dat uit zou komen.
Dit heeft het artikel niet gehaald, maar Kling heeft hier wel over gezegd (ik parafraseer): Featurecreep is altijd iets om voor te waken. Het voordeel is dat een browserengine niets nieuws hoeft te kunnen, maar alleen het web weer te geven zoals het is. Zie verder de verwijzing naar de 80-20-regel.
Maar een browserengine heeft natuurlijk ook een browser nodig, nemen ze dan genoegen met een webview-achtige implementatie of zijn ze tegelijkertijd óók een browser aan het bouwen? Een browser kan namelijk wel heel makkelijk flinke feature/scope creep hebben
"Hoe voorkomt men dat dit de Star Citizen onder de browsers wordt? Zachte beloftes zijn makkelijk om uit te stellen."

Ze hebben geen verantwoordelijkheid af te leggen tegenover jou, alleen als vrijwilliger binnen hun eigen team en donateur. Ik snap niet zo goed waar deze houding vandaan komt. Star Citizen is een project van een developer met een track record van gefaalde projecten, ook zijn succesvolle. Freelancer werd bv op het laatst overgenomen zodat het eindelijk uit productie zou komen. Het is flauw om hun falen direct aan een ander developer-team te plakken die resultaten boekt.

[Reactie gewijzigd door Zwarte_os op 3 november 2025 09:18]

Hij gaat verder: "Een browser is vergelijkbaar met een emulator en het web met een enorme collectie aan games; je moet kijken hoe een app werkt en je browserengine aanpassen om dit werkend te krijgen."
Dit is een interessante ontwikkelfilosofie. Mijn eerste gedachte toen ik dit las was "keep calm and follow the standards". Met andere woorden: werk bottom-up en ondersteuning komt vanzelf wel.

Nu ik er wat meer over nadenk, valt er ook wat te zeggen voor top-down. Zo wordt bijvoorbeeld Wine/Proton ontwikkeld. De compatibiliteit daarvan is bijzonder goed, ook voor zaken waar nog nooit iets expliciet voor ontwikkeld is. Een voordeel is dat het zo makkelijker wordt om tot een minimal viable product te komen, wat beter is voor marketing en financiering.

Een browser die voor 99,9% compatibel is met standaarden maar die niet de top 10 populaire websites ondersteunt zal nooit voldoende gebruikers trekken. Ondersteun de 10 populairste websites en er zal veel meer interesse zijn.
Nog interested is dan een half jaar geleden er gezegd werd dat het juist 100% aan de standaarden werd ontwikkelt met het idee "dan zijn wij nooit het probleem" en ze zichzelf prezen als enige dusdanig compatible te zijn daarmee. Dat werd nog mooi verteld in presentaties van hun eigen mensen, op bijv. de NLUUG conferentie, en nog een keer benadrukt toen ik vroeg over het verschil tussen hun en Servo (welke ook erg interessant is, maar enorm onder belicht naast Ladybird. Vorige maand hebben die de eerste alpha versie uitgegeven).

@YannickSpinner is er nog wat gezegd over deze verandering van filosofie? Ik vind het een opvallende verandering, maar wellicht is het een die enkel opvalt als je meer oplet op dit project.
Ik heb zelf een paar jaar terug een proxy ontwikkeld die real-time oude onveilige html, css en javascript om zet naar een moderne veilige variant en op verzoek een service worker met local cache en OpenAPI compatible proxy injecteert met reverse validatie (typisch geeft dit een 80% of hogere offload van het hosting platform en een snellere klant beleving, vandaar).

Zo iets kan deze browser natuurlijk ook doen voordat het door de parser gaat.
Je implementeert alle nieuwste standaarden en maakt Transformers of een Polyfill voor incompatible input.

Zo blijft je engine clean. Je voegt een cache laag toe voor eerder getransformeerde dingen en eventueel een in memory look-up voor de meest voorkomende transformaties als dat snelheid verhoogt. Aan/uit te zetten als balans tussen geheugengebruik, opslaggebruik en snelheid.

[Reactie gewijzigd door djwice op 3 november 2025 10:34]

Verder zijn er twee bruikbaarheidszaken zaken voor mij belangrijk in browsers:
• ...
• Uitbreidbaarheid. Geen onbegrensde uBlock Origin of equivalent is geen deal. Het moderne internet is rioolwater. Er moet veel gebeuren om daar drinkwater van te maken.
In de laatste update video gaat het toevallig over adblocking in Ladybird.
  • Huidige status: Simpele adblock regels ingebakken in de browser (met algehele aan/uit knop). Puur omdat de ontwikkelaars zelf een adblocker wilden tijdens het ontwikkelen.
  • Gewenste toekomst: Add-ons voor adblocking zodat bovenstaande verwijderd kan worden..
Kling wil met Ladybird een onafhankelijke browserengine maken, 'zonder miljarden te spenderen'

Ook werken er volgens Kling zo'n 250 vrijwilligers via GitHub aan het project.
En hoeveel zou het gekost hebben als deze 250 vrijwilligers ook een eerlijke salaris hadden gehad? Want dit bespaard een hoop geld. Niet elke project zal altijd maar vollopen met vrijwilligers. LAMadybird heeft geluk dat het de eerste browser is die dit probeert en dat dus mensen eerder geneigd zijn om te helpen. De volgende keer dat iemand dit probeert (of misschien de keer erna) zullen mensen misschien wel denken dat het onverstandig is nog een browser te maken en mogelijk dus geen vrijwilligers krijgt. Ik denk dus dat als je alle kosten zou optellen dat ze wel schrikken van het bedrag. Dus ja leuk dat je nu geen miljarden uitgeeft maar het is voor mij gevoel dus oneerlijk om te zeggen dat het geen miljarden heeft gekost op deze manier.
Het ligt er maar net aan hoe die vrijwilligers hun tijd inzetten. Wanneer ze vanuit hobbymatige interesse per week een paar (zeg twee, voor het gemak) uurtjes besteden aan dingen testen, levert dat al 500 uur aan gedane arbeid op. Dat hoef je dan als ontwikkelteam van 8 man niet meer te doen. Maar het is wel heel belangrijk om die vrijwilligers erkenning en waardering voor hun inzet en werk te geven.
Ik zeg niet dat vrijwilligers gebruiken verkeerd is. Maar wel dat ik dus het gevoel heb dat de kostenplaatje nu wel een verkeerd beeld kan geven.

Al verwacht ik persoonlijk wel meer als 2 uur per week. Ik verwacht meer richting de 5 of 6 uur gemiddeld. Maar zelfs bij jouw 2 uur per eat 500 uur is. Even van uit gaan een werkweek van 40 uur dan is dat 12 man personeel wat ze eigenlijk niet betalen. Dat is meer dan de betaalde hoeveelheid personeel wat ze hebben. Dus om te zeggen dat het goedkoop kan terwijl je infeite maar de helft aan salaris aan kosten kwijt bent vind ik gewoon niet compleet kloppen. Want ik denk niet dat als Google zou zeggen dat ze 250 vrijwilligers zoeken dat mensen in de rij zullen staan. Dan zal het wel zijn dat iedereen denkt dat Google rijk genoeg is en dus iedereen wel kan betalen.
En hoeveel zou het gekost hebben als deze 250 vrijwilligers ook een eerlijke salaris hadden gehad?
Dan hadden ze waarschijnlijk niet met 250 mensen eraan gewerkt.
Dat logisch. Maar simpel gezegd kan alles goedkoop zijn op deze manier. Als ik genoeg donaties en vrijwilligers heb kan ik een hele stad bouwen zonder dat het mij een euro kost. Sterker nog als ik begin met een vrijwilliger die mij vervangt hoef ik dus maar 1 ding te doen en de rest wordt gedaan. Kan ik dan ook zeggen dat een stad bouwen dus niet zo duur en moeilijk hoeft te zijn? Mijn voorbeeld is natuurlijk overdreven maar dit klinkt in mijn oren wel wat ze doen. Het geeft gewoon geen goed beeld wat de kosten normaal gesproken zouden moeten zijn.
Eigenlijk is dat een rare vraag omdat die heel erg cirkelig is. Als je je vrijwilligers zou moeten betalen, dan zou dat zoveel geld gaan kosten dat het niet mogelijk zou zijn. Dus zou je het niet doen en zouden die vrijwilligers er ook niet zijn en dus het project ook niet.

Ik maak zelf een open source tool waar ik inmiddels al 15 jaar mee bezig ben. In totaal zit daar rustig een paar duizend uur ontwikkelwerk in. Hoeveel zou het gekost hebben als ik (of iemand anders) mezelf had moeten betalen?
De vraag hoeft op zich niet zo krom te zijn. Vrijwilligers hebben deze week x aantal uur gewerk. X : 40 (werkweek) = aantal personeel wat dan betaalt had moeten worden. Dat keer de salaris en je weet wat je deze week bespaart hebt. Reken de kosten van elke week bovenop de totale kosten en je weet wat de project +- had gekost zonder vrijwilligers. Natuurlijk zal het niet compleet correct zijn omdat een vrijwilliger mogelijk minder snel werkt, mogelijk minder kennis heeft, dingen als vakantie dagen / ziekte dagen zitten dan niet in de berekening maar het is ieder geval wel een goede indicatie. Want als die 250 mensen maar 1 uur per week werken (wat ik zeer betwijfel dat het zou weinig is) is dat 6.25 personeel beparing. Dat is bijna evenveel als wat er nu werkt.
Ja, ik zie wat je bedoelt. Door de nadruk te leggen op het feit dat ze weinig geld uitgeven, kan de indruk ontstaan dat je zoiets als dit best goedkoop / makkelijk kan regelen. Maar dat is - gezien de flinke vrijwilligersinbreng - inderdaad niet het hele verhaal.

Ja, er wordt weinig geld uitgegeven, maar nee, niet iedereen kan dit zomaar herhalen of per definitie op andere projecten toepassen
Dit is wel een beetje hoe open source Welt natuurlijk. Home assistant heeft ook slechts een klein aantal mensen in dienst maar de duizenden integraties worden vaak door vrijwilligers geïmplementeerd. Daarom kan open source ook zo krachtig zijn. Verder is een browser zo'n belangrijk stuk software dat enkel door vrijwilligers of een selectie groep grote corporaties geïmplementeerd kan worden. Kijk naar Microsoft dat zelfs niet in staat was om presto te vervangen. En als grote ondernemingen dit implementeren, dan moet het opbrengen en de enige manier om te laten renderen is door gebruikers van privacy te ontdoen. Daarom is het enige alternatief een open source project met honderden ontwikkelaars. Komt verder bij dat Europa geen enkele eigen browser engine in beheer heeft, voor velen zal dit ook een drijfveer zijn om hier aan te weken.

Mozilla ontwikkelt de enige andere open browser, en daar Is je dat je ofwel financiële backing nodig hebt of vele vrijwilligers.

Om nu terug te komen op jouw conclusie: er zijn inderdaad geen miljarden gespendeerd omdat er zo veel vrijwilligers aan meewerken, maar juist daarom is dit een vrije browser. Op geen enkele andere manier kan je nu nog een browser maken die de privacy kan garanderen. Dus ik vind jouw opmerking nogal eenzijdig. Het zelfde met zeer veel open source projecten: er hoeft geen geld te zijn, juist omdat er mensen vrijwillig aan werken. Om verschillende redenen. Zijt blind dat de vrijwilligers hun tijd er insteken want hun doel is een Europese, vrij, privacy veilige opensource browser te maken, en dat kan je alleen maar toejuichen

[Reactie gewijzigd door MrSnowflake op 3 november 2025 08:39]

Het punt lijkt me dan ook dat de kosten van een bedrijf als Mozilla om de Gecko-engine te maken en onderhouden een vertaling is naar 'ongedifferentieerde productiefactoren' (geld).

Iets vrijwillig en voor niets doen is niet hetzelfde als dat er geen ongedifferentieerde productiefactoren mee zijn gemoeid.

Op zijn minst leeft iemand in een ecosysteem, wat al productiefactoren in beslag neemt. Zelfs als die persoon anders niets zou doen, neemt het nog steeds niet weg dat er bijvoorbeeld arbeid mee gemoeid is. Het vertegenwoordigd altijd uiteindelijk een hoeveelheid ongedifferentieerde productiefactoren.

Kortom: Duizenden uren is best een hoop geld. Dat ook alleen maar kan vanwege alle miljoenen uren die alle anderen in al het andere steken.

Het is een mooi project, maar het is een utopie om te denken dat dit niet beter een geleid, georganiseerd, gebudgetteerd, en betaald project kon zijn.
Zegt ook niemand dat dit dé manier is om een project te leiden. Maar dit is wel dé manier om een project te maken dat vrij is van externe invloeden. Met geld komt meestal ook controle, en dat is wat je wil vermijden voor een browser. Het zo'n belangrijk stuk software dat het wel een vrij project moet zijn.
Dat zou je ook kunnen inbouwen, maar verder eens hoor: ik volg het project met interesse.
En hoeveel zou het gekost hebben als deze 250 vrijwilligers ook een eerlijke salaris hadden gehad?
Het is ietwat vreemd om bij dergelijke projecten te spreken over een "eerlijk salaris". Indien je het zo nodig zou willen beschouwen in het kapitalistische frame, dan kopen die mensen juist een browser voor de gemeenschap, waarbij ze betalen in natura.
Het enigste wat ik er mee bedoelde was dat men een normaal salaris zou krijgen. Ik heb bijvoorbeeld een uitkering en werkte daarnaast. Maar door mijn uitkering kon ik niet volledig betaald worden. Ik heb ooit 20 euro promotie gekregen en daarna kon ik 200 euro minder uitkering krijgen. En om nou het bedrijf 200 euro extra te laten betalen zodat ik 20 euro overhoudt is ook dom natuurlijk. Dus ik zat gewoon vast qua salaris. Maar ook geen situaties als iemand is een stagiaire en krijgt elke maand 100 euro fooi maar telt wel als personeel. En ook het omgekeerde natuurlijk. Stel dat het huidige personeel 10% boven de minimale loon zit dat de rest dan ook deze 10% zou krijgen en niet dat hun dus als minimaal gerekend gaan worden. Uiteraard mogen dingen als werkervaring meegerekend worden en dat er dus wel een verschil kan zitten tussen het personeel.
Stel dat die 250 vrijwilliger per persoon ongeveer het werk doen van 10% van een full-time ontwikkelaar. Dat is waarschijnlijk erg hoog ingeschat, maar stel. Dan heb je dus 25 gratis werknemers. Stel dat je daar anders 150k per persoon per jaar voor had moeten betalen (loon + alle andere kosten). Dan hebben we het dus over 3,75 miljoen per jaar. Kan je 260 jaar mee vooruit voordat je een miljard hebt uitgegeven.

Dus het lijkt me juist heel terecht om te stellen dat het geen miljarden heeft gekost. :-)
Mijn reactie was ook niet bedoelt om te zeggen dat ze wel over de miljard zouden gaan. Maar wel dus dat ze een hoop besparing hebben waardoor het goedkoper is. Dat er dus wel meer speelt. Al zeg ik eerlijk dat 3.75 miljoen voor 25 mensen minder is dan dat ik verwachtte (al verwacht ik zelf wel iets meer als 25). Maar het hoeft niet de enigste kosten te zijn. Tegenwoordig is thuiswerken een ding (zoals de vrijwilligers ook doen) maar als ze dus ook een grotere ruimte hadden moeten huren of kopen dan denk ik niet dat 150k per jaar dit ook zou dekken.

Maar ik kan mij ook voorstellen dat Google misschien hun ontwikkelaars niet het minimale betalen wat dit bedrijf misschien wel doet. Daarnaast is Chrome natuurlijk ook door veel mensen in gebruik. Dus veel hackers proberen dit dus te hacken. Google heeft dus veel meer verantwoording om dus lekken snel te dichten in plaats van dat dat alles rustig aan kan. Ik denk als Ladybird dus zo populair zou zijn dat ze waarschijnlijk ook niet genoeg zouden hebben aan 33 (8 + jouw 25) werknemers om te dichten en nieuwe dingen te maken.

Wat ik dus probeerde te zeggen dat er dus wel meer speelt. Dat wij kunnen het goedkoop geen compleet eerlijke vergelijking was. Maar ik had de salaris wel hoger verwacht watvdus een vergissing was.
Ik gok maar wat hoor, qua salaris, maar in het artikel staat dat ze op salaris niet concurreren met bijvoorbeeld google. Uiteraard heb je gelijk dat je de kosten niet zomaar één op één kan vergelijken!
@YannickSpinner Wellicht had Tweakers dan wat vooronderzoek kunnen doen voor wat diepte-vragen:

https://drewdevault.com/2025/09/24/2025-09-24-Cloudflare-and-fascists.html

https://hyperborea.org/reviews/software/ladybird-inclusivity/

Of kijken we lekker weg omdat we het wel een leuk project vinden?

[Reactie gewijzigd door DrPoncho op 3 november 2025 08:23]

Dit heeft niks met tech te maken en heeft geen plaats in een interview over een browserengine. Kling heeft zijn standpunt openbaar gedeeld en mensen die interesse hebben in politiek weten dat ongetwijfeld te vinden.
Dat is wat naief, en op het randje van misleidend. Als de developer zijn eigen politieke kleur duidelijke door laat schijnen in zijn projecten, heeft dat wel degelijk te maken met dat project. Hij heeft zijn standpunt niet alleen "openbaar gedeeld", maar zijn politeke voorkeur heeft direct invloed op wat wel en niet geaccepteerd wordt in het Ladybird project.

En tweakers.net is niet alleen tech. Op tweakers worden enorm veel politiek gerelateerd nieuws geplaatst, je nu plots verschuilen achter "het heeft niets met tech te maken" is raar.
Ik vind de insinuatie van 'wegkijken' ongepast. We maken een journalistieke overweging en daar bied ik je context over. Voor de duidelijkheid, we vragen niet alle interviewgasten over hun politieke voorkeur of een tweet over een politieke spreker; dat is voor Tweakers niet relevant. De context over Kling als persoon is overigens volgens mij gewoon welkom in de comments (daar gaan de mods over, redactie niet)
Is dit beleid van Tweakers? Als jullie een interview met Elon Musk of zo zouden krijgen, zouden jullie hem ook geen politieke vragen stellen?
Dat is een whataboutism, maar ik snap de vergelijking wel ;) Zou je hem over een specifieke tweet met een mening vragen? Of wellicht over de politieke invloed van zijn platform. Doge heeft niks met Tweakers te maken. Grok wel, dus daar zou je over filteren en sturen kunnen vragen. Ik hoop dat de distinctie duidelijk is; politiek is geen nono, maar wel als het niks met tech te maken heeft.
Als je een artikel schrijft over een project, en de persoon die je interviewt is zowel aan de leiding van dat project en brengt binnen de context van dat project zijn politiek naar boven; dan lijkt het mij absoluut wel gepast om daar vragen over te stellen ja.

Het hele incident is inherrent politiek, ookal zegt Kling dat hij geen politiek wil in Ladybird, de keuze die hij daar maakt is gewoon politiek gekleurd op zichzelf. Lijkt me niet meer dan logisch dat dat binnen de scope past om daar dan ook vragen over te stellen.

[Reactie gewijzigd door Loller1 op 3 november 2025 09:50]

Ik zie dit erg vaak op Mastodon ook als no-go gebeuren. Ergens duikt dan een verkeerde uitspraak op van een developer en meteen wordt het hele project afgeschoten. Natuurlijk is het wel van belang als de developer echt totaal niet door de beugel kan en in zijn eentje werkt aan iets wat ik dan niet kan steunen, maar als het 1 van de velen is of alleen de ceo, maar het product is top en werkt goed.. moet ik mezelf dan in de voet blijven schieten? Zo kan je echt niks gebruiken namelijk, want helaas zijn er nogal wat mensen met een discutabele mening in het algemeen. Framework bijv. steunt een Linux distributie gemaakt door iemand die ook niet door de beugel kan. Maar ik zie ze ook vanalles en nog wat steunen, koop ik dan maar geen Framework meer?

[Reactie gewijzigd door vgroenewold op 3 november 2025 11:09]

Zo kan je echt niks gebruiken namelijk, want helaas zijn er nogal wat mensen met een discutabele mening in het algemeen. Framework bijv. steunt een Linux distributie gemaakt door iemand die ook niet door de beugel kan. Maar ik zie ze ook vanalles en nog wat steunen, koop ik dan maar geen Framework meer?
Dat moet iedereen voor zich uitmaken. Maar in dit geval gaat het om Omarchy van David Heinemeier Hanson, die zou ik ook niet indirect willen steunen.

Maar ik koop sowieso geen laptops.
Langs de ene kant snap ik je punt. Langs de andere kant gaat het artikel niet louter over de persoon, maar over de persoon in de rol van projectleider, waarbij het project feitelijk centraal staat. Dan is het wel logischer om het vooral over het project te hebben en niet over diens persoonlijke opvattingen.
Dat is geen whataboutism -> dat zijn namelijk deflecties, dat is dit niet. Dit is vragen naar de scope van jullie beleid.
Leuk he, de nieuwe stop woordjes als whataboutism en bubbel, heel vaak enorme dooddoeners in een discussie.
Bedankt dat je de tijd neemt om te antwoorden. Ik snap ook wel wat je bedoeld en zou het beter vinden (in het geval van een Musk-type) als zeer politieke kwesties bevraagd worden door een reguliere krant/medium. Ik vindt wel de tweede tweet in het artikel van Drew DeVault zowel met tech als politiek te maken heeft. Ik zou graag een vraag zien over het inclusiebeleid van Ladybird, bijvoorbeeld. Als potentieel gebruiker wil ik wel weten of een open-source project een politieke kleur heeft, en zo ja, welke.
Of he of they wordt gebruikt lijkt me bijzonder irrelevant. Deze blogs zijn gewoon Amerikaanse politiek. Ik kan me goed voorstellen dat iemand hier opinies over heeft, maar lijkt me niet de moeite waard om in het artikel te vermelden
Maar het irrelevant noemen is al een politiek standpunt op zichzelf - dat is aannemen dat de lezer ook een "hem" is en/of dat dat de standaard is en dat iedereen die daar niet onder valt eigenlijk niet mee telt.

Ja het is maar een woordje, maar het is een indicatie dat er een stereotype of generalisatie aanwezig is.
Jij denkt ik heb geen zin om dat door te lezen, 't lijkt niet om mij te gaan dus ik roep maar direct wat? Het gaat niet alleen om he/they.
Toen ik het woord "fascist" zag in je gelinkte bron, haakte ik al af. Dat woord wordt te pas en te onpas in het rond geslingerd.
Is het niet verstandig om enigzins te verdiepen in waarom de term gebruikt wordt?
Zoals een post van Kling waarin hij oproept om te stoppen met het oproepen van geweld. Dat dan door Drew wordt geframed als pro-fascisme? Behoorlijk ironisch.

Dan die flauwe manier om de projecten minder professioneel over te laten komen : Is een nieuwe browserengine wel haalbaar? Zit ikke ikke wel te wachten op een nieuwe Arch distro ?(helaas ook een ding hier op Tweakers)

Aan open source projecten wordt in eerste instantie begonnen vanuit de behoefte van de ontwikkelaars zelf. Voor whatever reden.

Die hele blog leest verder als poging tot karaktermoord.

Disclaimer: Ik ken die Drew en Kling verder niet en ben ook niet geinteresseerd op welke partij ze stemmen. Dat is hun zaak.
De term wordt overal voor gebruikt, blijkbaar is iemand nu fascistisch omdat hij genderneutrale termen niet wil gebruiken. Fascisme heeft totaal geen betekenis meer, en dat heeft men zelf voor elkaar gespeeld—the boy who cried wolf. En dan zou het verbazingwekkend moeten zijn dat mensen je gelinkte artikels niet serieus met willen nemen.

Overigens heb ik ze gelezen maar wat een irritante typisch Amerikaanse hysterie: in de eerste zin al beginnen met stellen dat men in Amerika mensen opsluit in “concentratiekampen”, want dat is—als het al geen fantasie zou zijn—blijkbaar relevant volgens de auteur. Heeft werkelijk waar niets met een browserengine of de makers daarvan te maken. Eigenlijk best ziek iemand zo te linken aan concentratiekampen en fascisten. Maar natuurlijk zal ik mij wel niet goed genoeg hebben verdiept in waarom dit soort termen gebruikt worden.
Mogelijk, maar als het te onpas zou zijn dan zou het toch makkelijk weg te wuiven zijn?

Wegkijken of negeren is wat de facisten graag willen dat men doet, laat ze hun gang gaan om zo invloed te verkrijgen. Musk z'n hitlergroet zou het einde van zijn carriëre moeten zijn, zeker omdat hij vervolgens smoesjes en ontkenning deed ipv een stelling nemen tegen facisten en / of excuses aanbieden.
Voordat ik in herhaling val, denk ik dat @i7x hierboven al een keurige uitleg heeft gegeven. Echt fascisme ben ik uiteraard ook tegen, maar het woord wordt tegenwoordig voor bijna alles gebruikt als iemand het niet eens is met de mening van een ander.

Een recent voorbeeld is dat er ook veelvuldig "Fascist Scum" geschreeuwd werd bij de pro-Gaza/Hamas-protesten in Europa. Met andere woorden: als je niet voor Gaza/Hamas was, dan was je een fascist. En zo zijn er nog wel meer voorbeelden, waarin mensen uitgemaakt worden voor fascist terwijl ze gewoon een ander standpunt hebben.
Het mooie van open source is dat het ook zonder de huidige leiders voortgezet kan worden, waardoor het project op zichzelf (m.i.) prima gevolgd kan worden zonder de specifieke leiders te noemen, laat staan te veroordelen. Als het project technisch interessant is, is dat wat mij betreft voldoende reden om erover te berichten, zonder direct vingers te wijzen naar de huidige voormensen.

Don't get me wrong, o.b.v. jouw linkjes krijg ik geen fijn beeld van deze man. Jammer dat het zo gaat in die cirkels (niet alleen Ladybird), en fijn dat je hier (een kant van) de bredere context deelt, daar zijn de comments juist geschikt voor.
Het mooie van open source is dat het ook zonder de huidige leiders voortgezet kan worden, waardoor het project op zichzelf (m.i.) prima gevolgd kan worden zonder de specifieke leiders te noemen, laat staan te veroordelen. Als het project technisch interessant is, is dat wat mij betreft voldoende reden om erover te berichten, zonder direct vingers te wijzen naar de huidige voormensen.
Dat zei ik laatst ook, maar toen werd ik gemind en bekritiseerd, omdat een browserengine een te groot project zou zijn om over te nemen.
Tsja dat zou inderdaad best een uitdaging worden, maar als het closed-source is heb je die kans überhaupt niet. Bovendien hoef je ook niet alle contributors te vervangen natuurlijk, dus ik kan me voorstellen dat zelfs een groot project na zo'n verandering uiteindelijk toch wel op z'n pootjes kan belanden.
Dat zei ik laatst ook, maar toen werd ik gemind en bekritiseerd, omdat een browserengine een te groot project zou zijn om over te nemen.
Ja, je werd echt kei hard gemind en bekritiseerd, hé. :+

Neemt natuurlijk niet weg dat het gewoon onrealistisch is zonder de nodige schaal, net als dat als het Ladybird project op zichzelf nooit een functionele browser zal zijn als ze niet gigantisch veel uitbreiden.
O, ik dacht ik ook gemind was, maar dan herinnerde ik me dat verkeerd. Wel bekritiseerd, gezien de +2 eronder die het onrealistisch noemt.

Maar bedankt voor het opfrissen van mijn geheugen. :)
Bedankt, hier was ik me niet van bewust. Niet bepaald een fijn type inderdaad.

Ook weer heel typisch dat hij schrijft "everyone is welcome and nobody tells anyone what to think or say" https://mastodon.social/@alatiera/115272605624599561

Maar ondertussen dreigt hij met verbannen uit het project als mensen dat daadwerkelijk doen.

Dan blijf ik maar bij Firefox. Die zijn tenminste duidelijk aan de inclusieve kant (zie de situatie Brendan Eich bijvoorbeeld)

[Reactie gewijzigd door Llopigat op 3 november 2025 10:41]

Als Kling zegt
to engage young people with words, not fists.
lijkt mij dat ver van fascisme af te staan. Het is in mijn beleving helemaal niet slecht om met elkaar in debat te gaan in plaats van op de vuist.

Dus ik begrijp je referentie niet, ik vind je referentie zelfs ongenuanceerd en je maakt een ongepaste aantijging naar Tweakers en de auteur van het artikel.

Je referenties passen totaal niet in de context van dit artikel. Ook een besluit om documentatie vanuit een persoonsvorm te schrijven is geen fascisme maar een stijl keuze. De persoon die het wil herschrijven kan dat gewoon als nog doen en die versie zelfstandig publiceren. https://github.com/Ladybi...ybird/blob/master/LICENSE
https://github.com/Ladybi...master/CODE_OF_CONDUCT.md

[Reactie gewijzigd door djwice op 3 november 2025 11:17]

Wat voor vragen had Yannick dan moeten stellen?

En waarom zou Tweakers "wegkijken"? Misschien zijn ze juist enthousiast over zijn politieke opvattingen.
Jezus in wat voor wereld leven we ondertussen?

Tweakers schrijft een artikel over een nieuw stuk software, en vervolgens moet het (ook) gaan over de manier waarop de hoofdontwikkelaar tegen de politiek aankijkt? En over de keuze om wel of niet inclusief te zijn binnen de commentaren op de code?

Persoonlijk denk ik dat er betere arena's te bedenken zijn om fascisme te bestrijden dan in de reacties op het artikel. En ik heb het idee dat de bedenkelijke opmerkingen (of acties) van een ontwikkelaar niet automatisch inhouden dat het stuk software dat hij aan het ontwikkelen is dus bij definitie slecht is. Daarbij: jouw post is een keurige aanvulling op het artikel van Yannick: waar hij kiest voor een benadering van de software, en de politiek buiten beschouwing laat, doen de twee artikelen die jij linkt het omgekeerde... die hebben het over de politiek en laten de software(ontwikkeling) volkomen links (pun intended) liggen.

In mijn wereld(je) is het de software die zijn noodzaak moet bewijzen, en niet de eigenaar of ontwikkelaar. Ik vind Twitter een gedrocht, en vond dat al voordat Musk zich er mee ging bemoeien. Apple maakt best mooi spul waar goed mee te werken is. Ondanks het feit dat Jobs niet aardig was. Idem voor Spotify, ik ben al jaren (behoorlijk vocaal) geen liefhebber. En dat heeft met het product te maken. Niet met de keuzes wat meneer Ek doet met zijn centen (en dat wil ik zeker niet goedpraten).
Het helpt als je zaken leer te scheiden. Dat rotmensen af en toe best goeie dingen maken, en omgekeerd; dat aardigste gasten ook wanproducten kunnen creëren.
Door enige discussie over bijvoorbeeld een genderneutrale term af te kappen of door "niet woke" te zijn is het juist niet apolitiek. Maar veel mensen hebben een "knee-jerk" reactie van "dit is woke politiek!" zodra iemand de aanname dat de lezer van een document een man is aan probeert te vechten.
Door enige discussie over bijvoorbeeld een genderneutrale term af te kappen of door "niet woke" te zijn is het juist niet apolitiek. Maar veel mensen hebben een "knee-jerk" reactie van "dit is woke politiek!" zodra iemand de aanname dat de lezer van een document een man is aan probeert te vechten.
Het is verspeelde tijd en energie om je daar mee bezig te houden. De browser zal daar niet beter van worden.
Heel cool! Nu hopen dat wij het mogen meemaken dat er een serieuze nieuwe speler komt op de mobile phone market naast IOS/Android :)
Het fundament daarvoor bestaat al. AOSP is iets van 99,9% compatibel met Google's Android. Compatibiliteit wordt verder verbeterd door opensource vervangers van Google's software. Het probleem met AOSP is dat het ergens op moet draaien (hardware), wat verschillende uitdagingen oplevert.

Iets als Ladybird heeft die problemen niet of veel minder, omdat het OS waarop het draait een abstractielaag vormt tussen de applicatie en de browser. Die abstractielaag hoeft niet ontwikkeld te worden.
Die is al in veel verdere ontwikkeling en heet Servo. Maar ik gun Ladybird ook een goede kans, want hoe meer spelers hoe beter. :)
Afgelopen week dus Jelle (de COO) gezien samen met een collega en het is echt zo tof om te zien dat ze echt aan het zoeken zijn naar websites die niet werken om die weer werkend te maken. Zo kwam hij erachter dat de shadowroot die Home Assistant gebruikt nog niet lekker werkt, dus ging hij dat terplekke proberen te fixen :D
Ha Joost! Nog steeds bezig met een fix :D dit is inderdaad hoe we werken, bugs in -> betere browser out.

[Reactie gewijzigd door JeRa op 3 november 2025 15:44]

Het is heel goed dat er een totaal nieuwe browser in de maak is, een die niet blind Chromium pakt en daar wat USP tegenaan plakt. Het internet wordt al te lang geregeerd door Google.

Ik ga dit project in de gaten houden!!
Het zou mij weinig verbazen als dit project met name gebruikers bij Firefox weghaalt, en niet zozeer bij Chrome-based alternatieven. En dan schieten we er in het gehaal natuurlijk niet zo heel veel mee op...
Spijtig dat het C++ is en niet Rust bijvoorbeeld. Nuja de uitleg waarom is er ook.

Moest wel eens lachen bij "techmas....". Heb de install toevallig vorige week eens bekeken en voor velen is dit een stap te ver. Enja het is maar wat commando's uitvoeren, maar je zou versteld staan hoeveel mensen daar toch in de problemen komen.

Als ze apt/rpm packages etc hebben dan gaan ze een hele hoop testers bijkrijgen. Ik meng zelf niet graag source + packages. Tenzij het echt niet anders kan. Uiteraard kan je dit ook gewoon in VirtualBox ofzo runnen
Apart idd, ik denk dat we nu op een punt zijn waarbij het gebruik van C++ juist mensen minder enthousiast maakt om mee te doen. Het is een werkende taal met een groot ecosysteem natuurlijk, maar het is niet meer van deze tijd - of, het landschap is zodanig veranderd. Toen de eerste browsers uitkwamen was alles nog single-core bijvoorbeeld.
Dit hebben we met opzet zo gedaan: voor enigszins technisch aangelegde mensen is het geen enkel probleem om een tweetal commands te kopiëren en aan het compileren te slaan. Op dit moment hebben we weinig behoefte aan veel extra testers, maar developers zijn zeer zeker welkom. Zodra we de alpha releasen komen er natuurlijk binaries beschikbaar die iedereen simpel kan draaien.
Benieuwd naar hoe deze gaat evolueren, een beetje meer (echte) competitie op browsergebied kan zeker geen kwaad.

Een gelijkaardig project: https://github.com/qutebrowser/qutebrowser
Iemand met meer kennis dan ik zou eens moeten toelichten in welke mate deze nieuwe engine verschilt van bv. de QtWebEngine gebruikt door qutebrowser.

Even terzijde, maar waarom geen github-link ergens bovenaan in de inleiding van het artikel? Ik wou even het project zelf checken, alvorens verder te lezen. Uiteraard kan ik gewoon de link uit de afbeelding overnemen, maar lijkt mij zo'n bizar overzicht.

[Reactie gewijzigd door Bospaddenstoel op 3 november 2025 09:07]

Zo te lezen gebruikt QtWebEngine Chromium. Ladybird verschilt hierin door een totaal nieuwe web engine te implementeren.
[...] een volledig nieuwe speler [...]
100% nieuw wil ik het niet per sé noemen. Terwijl de graphics backend van de Ladybird engine (LibGfx) begon met een eigen implementatie (vanuit SerenityOS), zijn ze na een tijdje geswitched naar Skia als achterliggende implementatie. Voor wie dat niet weet: Skia is de graphics backend van Blink (de engine van Chrome) en Skia wordt uiteraard ontwikkeld door Google. Skia is een draak van een library en het is zeker niet lightweight.

Nu is de graphics backend juist iets wat veel uitmaakt op meerdere vlakken. Dus de Ladybird engine is in mijn optiek meer een soort van half-Chromium/half eigen implemenatie op die manier.

Ik hoop eigenlijk dat de devs op een gegeven moment weer een eigen (of op zijn minst een non-Google-based tech) implementatie krijgt.

[Reactie gewijzigd door recyclebin op 3 november 2025 09:19]

We gebruiken inderdaad Skia, maar het is "slechts" de graphics backend in zoverre dat het m.n. de 2D compositing voor zijn rekening neemt, en omdat het voor het web is ontwikkeld sluit het goed aan bij wat we nodig hebben. Het is maar een klein deel van de gehele stack die ervoor zorgt dat het web op je beeldscherm getoverd wordt, en ik sluit ook zeker niet uit dat we ooit overstappen op een andere backend.


Om te kunnen reageren moet je ingelogd zijn