Google werkt aan 'experimentele' iOS-browser zonder WebKit-ondersteuning

Google-ontwikkelaars werken aan een 'experimentele' browser voor iOS die niet gebruikmaakt van WebKit. Zonder die WebKit-ondersteuning mogen browsermakers hun app niet aanbieden in de App Store, een regel die in diverse markten onder druk staat.

De content_shell-app zou zijn bedoeld om graphics en input latencies te kunnen meten en traces te kunnen leveren voor analyses. De makers benadrukken dat de opensourceapp niet bedoeld is om een shippable browser te maken en dat deze puur voor experimentele doeleinden bedoeld is. Een Google-woordvoerder bevestigt tegen The Register dat het bedrijf niet van plan is om de app uit te brengen en dat het blijft voldoen aan Apples regels.

Hoewel Google zegt de app niet uit te gaan brengen, is het opvallend dat het bedrijf nu aan een niet-WebKit-iOS-browser werkt. Op iOS is het gebruik van WebKit en JavaScriptCore voor een browser verplicht, waardoor iOS-browsers niet veel kunnen afwijken van Safari. Dit beleid staat echter onder druk in verschillende landen, waaronder het Verenigd Koninkrijk en de Verenigde Staten, en in de Europese Unie, merkt The Register op.

Mogelijk bereidt Google zich met de 'experimentele' app dan ook voor op een toekomst waarin WebKit niet meer verplicht is op iOS. De experimentele browser is nog in ontwikkeling en gebruikt Blink, de rendering-engine die al in onder meer de Windows-, Android- en macOS-versies van Chrome wordt gebruikt.

Reacties (128)

[flame suit on]
Safari is de nieuwe Internet Explorer.
Het kost steeds meer moeite om om alle beperkingen heen te werken.
Safari daarom ook op Chromium gaan baseren.
En daar "democratische" besluiten nemen over doorontwikkeling van *de* web/HTML standaard.

Eh... Chrome is juist het nieuwe internet explorer. Ze verzinnen iets nieuws, maken er support voor, en een halve brakke polyfill voor de rest (firefox/safari) en pushen het zo de standaard in.

Die polyfill is traag en kut voor andere browsers, en opeens is het de schuld van firefox/safari dat ze achterlopen. Nee. Dat is niet hoe het zou moeten werken. Iedereen die klaagde over firefox/safari kwa snelheid doet dat altijd over sites die van google zijn (youtube/gmail/google maps).

Het is gelukkig minder erg nu er native support is in andere browsers voor shadow dom, maar het is een tijdtje heel erg geweest om youtube te bezoeken in firefox. Was dat de schuld van mozilla? Nee. Google zorg er indirect voor dat hun site kut werkt in firefox door dingen te gebruiken / forceren in hun browser die nog geen standaard zijn.

Mja, de standaarden voor het web voorzien gewoon in het ontwikkelen van nieuwe features, en Google houd zich in principe daar keurig aan. Ik heb het verder wel eens met datt de positie van Chrome aardig dominant is, en dat, dat problematisch is gezien de controle over grote web platformen van de fabrikant.

Bedenk wel echter dat ooit Safari de meest vooruitstrevende browser is en Apple ook de nodige veranderingen heeft geïntroduceerd in het web. Zo komt HTML canvas voort uit de widgets die OS X (destijds) had en komen tot zo ver ik kan zien ook CSS animaties daarvandaan.

De technieken voor website worden continu uitgebouwd, persoonlijk ben ik daar positief over, we hoeven namelijk nu niet meer tabellen te gebruiken voor layout (wat toegankelijkheid problemen introduceert) en hebben we ook (betere) alternatieven voor floats.

Er is al jaren niks meer vooruitstreven aan Safari. Ze zijn al jaren aan het bijbenen wat andere browsers doen. En nee, Google houd zich niet "keurig" aan de normale werkwijzen, het is al meermaals gebeurd dat de standaard A zegt, Google B implementeerd, en de standaard zich vervolgens moet aanpassen omdat Google het hele web ermee heeft ontwricht.

Dat Safari inmiddels achterloopt ben ik met je eens. Kan je trouwens een voorbeeld noemen van waar Chrome een standaard niet (goed) implementeert?

Google heeft een tijdje een afwijkende versie van IntersectionObserver geimplementeerd die zich op boundary cases anders gedraagde dan de spec zei.

Verder hebben ze ieders hand geforceerd en een tijdje lang een heleboel sites gemold middels hun 'interventie' om event handlers voor het scroll event standaard in de modus passive:true te registreren, waardoor deze niet cancelbaar zijn en bijna iedereen die iets met touch gestures deed als de wiedeweerga hun spul aan moest passen.

... wat overigens ook inhield dat je een compleet 2e implementatie er apart naast moest gaan draaien en user agent sniffing moest gaan toepassen, want de workaround die Google gaf om met het touch-action attribuut te gaan werken, was destijds niet ondersteund op ... jawel: Safari.


Feitelijk zijn Google en Apple beiden slechte actoren op het web:
Google dramkloot z'n zinnetje door. En Apple laat ontwikkelaars graag tegen een betonnen muur opwandelen omdat ze liever iedereen richting native apps blijven jagen (en lekker 30% commissie vangen).
Dan gedraagt Mozilla zich nog voorbeeldig. Zij hebben dan weer andere problemen, en zijn middels allerlei idiote aanpassingen aan Firefox om deze meer op Chrome te laten lijken, goed op weg hun eigen core userbase om zeep te helpen.

[Reactie gewijzigd door R4gnax op 6 februari 2023 14:53]

Bedankt voor de voorbeelden. als ik de tweede bekijk, en dat even langs de specificatie houd (https://dom.spec.whatwg.o...ntlisteneroptions-passive) lijkt Chrome dit gewoon goed te doen op basis van je beschrijving:

The default passive value, given an event type type and an EventTarget eventTarget, is determined as follows:

Return true if all of the following are true:

type is one of "touchstart", "touchmove", "wheel", or "mousewheel". [TOUCH-EVENTS] [UIEVENTS]

eventTarget is a Window object, or is a node whose node document is eventTarget, or is a node whose node document’s document element is eventTarget, or is a node whose node document’s body element is eventTarget. [HTML]

MDN zegt overigens iets anders (https://developer.mozilla...ntTarget/addEventListener).

De specificatie is later retro-actief aangepast toen Google hun intervention al doorgedrukt had en iedereen geforceerd had om deze dan maar as-is over te nemen.

In die zin is het het perfecte voorbeeld van Google's machtsmisbruik van hun marktdominante positie. Zij zeggen: "Wij hebben al zo gesprongen; dus spring." en de rest van de wereld heeft te luisteren.

[Reactie gewijzigd door R4gnax op 6 februari 2023 15:04]

Ah je hebt gelijk: https://github.com/WICG/interventions/issues/35, maar dat zal niet gebeurd zijn zonder akkoord van andere W3 lederen (waar Mozilla en Apple bijhoren).

[Reactie gewijzigd door Ed Vertijsment op 6 februari 2023 15:16]

Eerder overgave dan akkoord

Mja, de standaarden voor het web voorzien gewoon in het ontwikkelen van nieuwe features, en Google houd zich in principe daar keurig aan.

Welke nieuwe features zijn er de laatste pakweg tien jaar nog ontwikkeld dan? Als ik daar naar zoek kom ik zaken tegen die vaak al meer dan 20 jaar bestaan en hooguit nu een eigen tag of zo gekregen hebben. Ik ben bang dat, buiten webdesigners, niemand het zal opvallen dat er nu een placeholder-attribute aan html is toegevoegd, aangezien daar eerder ook al methodes voor waren.

Alleen al met CSS is er te veel om op te noemen: CSS grid, container queries, custom properties, nieuwe kleuren palletten naast RGB en hex, shadow dom, web components... etc.

Placeholder attributen? HTML daar veranderd niet heel veel meer aan tegenwoordig. Maar CSS en JavaScript daar worden met elke nieuwe browser release grote en kleine features aan toegevoegd.

HTML daar veranderd niet heel veel meer aan tegenwoordig.

Mwa. Er zijn nog genoeg zaken die ook ergens een effect op HTML hebben hoor. Kijk bijv. naar lazy loaded images en async decoded images. Beiden hebben aansturing via HTML attributen.

Ja dat is zeker waar.

[...]

Welke nieuwe features zijn er de laatste pakweg tien jaar nog ontwikkeld dan? Als ik daar naar zoek kom ik zaken tegen die vaak al meer dan 20 jaar bestaan en hooguit nu een eigen tag of zo gekregen hebben. Ik ben bang dat, buiten webdesigners, niemand het zal opvallen dat er nu een placeholder-attribute aan html is toegevoegd, aangezien daar eerder ook al methodes voor waren.

Nou begin een hier: https://www.w3.org/TR/?status=FPWD&version=ed

Maar laten we eens wat noemen:

- Service Workers API: https://www.w3.org/standards/history/service-workers
- CSS grid: https://www.w3.org/TR/2011/WD-css3-grid-layout-20110407/
- ES2015 (en opvolgers): https://262.ecma-international.org/6.0/

Er is de laatste 10 jaar gigantisch veel gebeurd op het gebied van wegtechnieken.

Servers Workers API weblock gaat over javascript communicatie met de server, niet iets waar je als gebruiker qua interface iets van gaat zien.

Css grid, dus ook geen html, gaat over een functie voor een grid in css. Het laatste voorstel is trouwens alweer drie jaar oud. Met alle respect maar wie zit hier op te wachten? Dit is details bijschaven.

En ECMA is een prachtig instrument, absoluut, maar wat kan javascript nu, wat het eerder niet kon, door het bijschaven van ECMAScript?

Servers Workers API weblock gaat over javascript communicatie met de server, niet iets waar je als gebruiker qua interface iets van gaat zien.

Hierdoor werken "progressive web app", ook wel offline websites, super handig als je even geen internet hebt. Maar inderdaad, dat kon ook al met web manifest welke uit 2013 komt (https://www.w3.org/TR/2013/WD-appmanifest-20131217/) daarvoor was dit eigenlijk niet goed mogelijk dus deze is wat concreter.

Je vroeg trouwens om de afgelopen 10 jaar, vandaar dat ik ook oude voorbeelden noem. Als je de afgelopen 3 jaar wilt weten kan je, je ens verdiepen in bijvoorbeeld WebGPU.

Je hebt gelijkt met je stelling dat de gebruiker hier niet veel van merkt, maar dat geld ook een muziekluisteraar die veranderingen in de techniek gebruikt in de (professionele) muziekindustrie vaak niet echt meekrijgt. Dit zijn ontwikkelingen die vooral de technieken voor web professionals beter maken.

Je kunt niet eerst vragen welke nieuwe features er dan nog ontwikkeld zijn binnen "de standaarden voor het web" en vervolgens als je antwoord krijgt, stellen dat allerlei vernieuwingen en toevoegingen binnen CSS en JS niet meetellen.

Het web en het bouwen van websites, dat gaat breder dan alleen HTML markup. En hiermee ben je aan het morren aan de doelposten.

[Reactie gewijzigd door R4gnax op 6 februari 2023 15:50]

Laat ik het dan zó zeggen: Ik ben teleurgesteld dat na al die jaren html nog steeds totaal afhankelijk is van javascript en css.

In 2000 werd gezegd: Het kost nou eenmaal tijd voordat alle deelnemers van W3 het eens is zijn. Intussen werden allerlei problemen en vragen vanuit de gebruikers steeds meer ingevuld met css, flash en javascript.

Maar de meeste functionaliteit werkt nog steeds alleen met behulp van css en javascript.

Het is verre van ideaal om allerlei scripttalen door elkaar te gebruiken. Ik begrijp dat het toen, historisch, zo gelopen is maar dat het 20, 25 jaar later nog steeds van die houtje-touwtje oplossingen zijn, is niet iets om trots op te zijn.

CSS is geen script taal; maar een declaratieve taal om in opmaak te voorzien.
Daarnaast: de specificaties voor de verschillende modules binnen CSS en DOM (wat jij eigenlijk bedoelt zijn de DOM APIs; die een binding naar de JS script taal hebben - niet JS zelf) worden ook gewoon door W3 en verschillende gelieerde organen beheerd.

https://caniuse.com/?comp...refox+109&compareCats=all

Er zijn verbazingwekkend veel kleine dingen die (nog) niet worden ondersteund door alle browsers. Sterker nog. Er lijkt geen één browser te zijn die alles wel ondersteund.

Dat is waar ik mede op doel. Op papier is het allemaal heel aardig geregeld, met het w3 als soort van poortwachter en centraal ontwikkel- en overlegplatform, maar te veel partijen hebben tegenstrijdige belangen en boeit het blijkbaar niet. Hoe dan ook kosten zelfs kleine ‘stappen’ jaren van overleg en dan nog worden ze vaak niet unaniem geïmplementeerd, waardoor je ze zelfs na jaren nog steeds niet veilig kunt toepassen.

Zo was het 20, 25 geleden ook al. Ik schaam me bijna plaatsvervangend een beetje voor de industrie waar ik ook deel van uitmaak.

Mijn dank, ik had het niet beter kunnen verwoorden.

Ik snap dat Chrome een 2e IE aan het worden is maar IE werd gesterkt door MS Frontpage, een HTML editor dat MS eigen code ontwikkelde. Heeft Google ook zoiets of moet het zich toch nog een beetje aan standaarden houden?

De eventuele editor heeft daar niks mee te maken.
Vroeger was IE (doordat het standaard in Windows zat) de browser met het grote marktaandeel, waardoor Microsoft zich niet meer aan de standaarden hoefde te houden omdat IE door zijn marktaandeel feitelijk de de facto standaard geworden was.

Helaas heeft Google het nu met Chrome voor elkaar gekregen een dergelijk groot marktaandeel te behalen, waardoor zij nu simpelweg de standaards kunnen afdwingen, en browsers met andere engines (Firefox/Mozilla, Safari/Webkit) maar moeten volgen wat Goolge allemaal verzint (om voornamelijk zelf financieel beter van te worden) vanwege het risico anders problemen met websites te krijgen, waardoor ze nóg meer marktaandeel verliezen en Google nóg groter wordt.

Firefox is ook een beetje stuck between a rock and a hard place. Ze hebben veel terechte kritiek op Google, maar ze krijgen miljarden van Google. Een half miljard per jaar geloof ik. Volgens mij is dat meteen 95% van hun inkomen.

• Chrome is "het nieuwe IE", omdat het de andere browsers dwingt om mee te gaan met nieuwe technologische ontwikkelingen.
• Safarie is "het nieuwe IE", omdat het achterloopt op de andere browsers en door het "verplichte" gebruik de ontwikkeling remt.

Beide beweringen zijn waar. Het is alleen naar welk era je kijkt van IE.
MS heeft op een gegeven moment de ontwikkeling van IE verhoogt tot de overstap naar Edge. Apple blijft wat dat betreft achter.

Google Chrome is de nieuwe Internet Explorer.

Misschien zelfs nog erger dan IE gezien de veel grotere en meer agressieve monopolie.

Ik zie zelf ook liever dat iOS andere engines toestaat, in feite is iedere iOS browser "Safari met een andere schil eromheen", en ook qua wat andere browsers mogen tegenover Safari op iOS kan een stuk beter.

Maar aan de andere kant zie ik dan Google meteen hun kans grijpen, je hoort de laatste jaren ook al veel mensen zeggen "download Chrome gewoon" of ze noemen hun browser Chrome, ook als het geen Chrome is omdat bepaalde mensen denken dat browser = Chrome, en de rest bestaat niet.

Google zal dan Chrome pushen en dat "duwtje" komt bovenop de mensen die Safari voor Chrome inruilen.

Dus nog meer monopolie van een browser die al extreem ongezonde monopolie heeft op de browser markt, ik zou zelfs zeggen dat Chrome op dat front nog veel erger is dan IE.

Chromium is helaas niet democratisch, maar voornamelijk een feestje van Google.

Juist doordat steeds meer browsers Chromium als engine zijn gaan gebruiken, is dat de nieuwe Internet Explorer aan het worden. Steeds vaker is de "standaard" simpelweg wat Google besluit te implementeren - of dat nou goed is voor de gebruiker of niet. We zien zelfs een terugkomst van "Deze website werkt alleen met browser X" meldingen!

Het probleem met Safari is dat de browser praktisch dood is en dat ze gestopt zijn met ontwikkelen. Maar overstappen naar de Chromium-engine zorgt op lange termijn alleen maar voor nóg meer problemen.

"Deze website werkt alleen met browser X" is ook een gevolg van wat je als ontwikkelaar wil steken in de ontwikkeling.

Ik gebruik bijvoorbeeld graag de https://developer.mozilla...PI/File_System_Access_API omdat je dan webapps(tools) kunt maken die op meerdere platformen draaien en volledig in de client(browser) draait. Safari ondersteunt die wel maar Firefox niet. Aangezien het aandeel Firefox in de browser markt heel klein is zal ik echt geen effort steken in Firefox behave een melding met 'this browser is not supported'.

Dat is precies het probleem, ja. Ontwikkelaars gaan er vanuit dat Chrome de enige browser is, en geven vaak zelfs een waarschuwing zonder te kijken naar de daadwerkelijk ondersteunde features. Vaak werkt de website zonder enig probleem als je de User Agent spooft.

In plaats van zo'n waarschuwing kan je ook testen of de browser ondersteuning heeft voor de feature, en zo niet een polyfill aanbieden, of dat deel van de website uitschakelen.

Overigens is juist de File Access API een interessant punt. Deze is oorspronkelijk bedacht door Google, maar bevat een een aantal gevaarlijke tekortkomingen. Er is een poging gedaan om er een standaard van te maken, maar Google was niet bereid om de feedback mee te nemen en heeft de standaardisatie inmiddels opgegeven. Ondertussen is er een tweede API gekomen, maar Chrome gebruikt non-standaard functienamen.

Google implementeert wel vaker features zonder goed na te denken wat de effecten daarvan zijn op de rest van de wereld. Juist daarom is het belangrijk om een gezond ecosysteem te hebben waarin verschillende partijen samen kunnen werken aan nieuwe standaarden. Een quasi-monopolie van welke browser dan ook is onwenselijk.

Ik gebruik bijvoorbeeld graag de https://developer.mozilla...PI/File_System_Access_API omdat je dan webapps(tools) kunt maken die op meerdere platformen draaien en volledig in de client(browser) draait.

Mozilla heeft principiële bezwaren tegen de File System Access API omdat deze in de huidige vorm zeer eenvoudig misbruikt kan worden om argeloze gebruikers toestemming te laten geven om well-known folders zoals My Documents en My Pictures te encrypten met web-based ransomware, bijvoorbeeld.
Daarnaast is het triviaal mogelijk om een disk volledig vol te pompen met dummy data.
De huidige API voorziet niet in enige vorm van write-quota bescherming en door lokaal in geheugen een file aan te maken en vervolgens de write offset heel ver naar achter te duwen en dan weg te schrijven kun je zeer snel gigabytes aan data naar disk forceren. Dat gaat niet werken als je een filesystem gebruikt wat sparse data ondersteunt; maar niet alle filesystems doen dat. Daarnaast is dit een implementatie-detail wat ook niet in de huidige spec proposal vastgenageld wordt. User agents die in zo'n geval zelf naive NUL-writes gaan doen en er een dense file van maken? Mag vziw gewoon...

En dat zijn zo maar een paar 'probleempjes' met dat niet-doordachtte gedrocht.

[Reactie gewijzigd door R4gnax op 6 februari 2023 16:07]

Je kan toch prima een Service Worker inzetten om zo een app in de client te draaien, daar heb je toch geen toegang tot het file system voor nodig?

In sommige gevallen zou dat kunnen, maar denk meer in de richting van vscode.dev of 16 Gib aan data files parsen en statistieken genereren/visualiseren.

Ja, dan is het file system wel handig

[Reactie gewijzigd door Ed Vertijsment op 6 februari 2023 14:43]

Keer op keer komt deze vergelijking bovendrijven maar die gaat op een aantal punten mank:

• Chromium is open-source, Internet Explorer was dat niet. Er zijn genoeg voorbeelden te vinden van functies die Google in haar browser implementeert die niet worden overgenomen door derden waardoor dat soort functies geen tractie krijgen. Meest aansprekende voorbeeld is FLoC. De hele reden dat dit kan is omdat het project open-source is en anderen kunnen besluiten om patches wel/niet over te nemen.
• IE was beperkt tot één platform. Ditzelfde manko zien we ook bij WebKit. Wil je je site op WebKit-gebaseerde browsers testen dan ben je afhankelijk van een Apple-apparaat. Heb je dat niet dan moet je gaan prutsen met diensten als BrowserStack of rommelen met VM's wat verre van optimaal is. Met Chromium en afgeleide browsers heb je dat probleem niet omdat je dat op vrijwel ieder denkbaar platform kunt draaien.

Chromium is in theorie open source, maar het heeft vrij weinig gemeen met de rest van de open-source wereld.

De ontwikkeling gebeurt voornamelijk achter gesloten deuren, en keuzes worden voornamelijk gemaakt vanuit het commerciële oogpunt van Google en interne bedrijfspolitiek. Mensen buiten Google hebben er bijna niks over te zeggen, en code bijdragen is bijzonder lastig. In de praktijk komt het er op neer dat ze af en toe een bak met code over de schutting heen gooien. Dit is compleet anders dan de werkwijze van reguliere open source software.

Daarnaast is Chromium wellicht open source, maar dat zegt weinig over de toekomst. Chrome is namelijk gewoon closed-source, en Google doet er alles aan om mensen Chrome te laten gebruiken in plaats van Chromium. Android is in theorie ook open source, maar in de praktijk is er steeds meer verplaatst naar closed-source apps en is een Google-vrije build praktisch onmogelijk. Er is geen enkele garantie dat dit niet in de toekomst met Chromium gaat gebeuren.

Zodra een browser praktisch een monopolie heeft, kunnen ze doen wat ze willen. Chrome en Safari zijn de enige browsers met een noemenswaardig marktaandeel. Leuk dat dingen als Edge en Opera bestaan, maar praktisch niemand gebruikt ze, en de ontwikkelaars nemen klakkeloos alle keuzes van Google over. De monopolie van Chrome is een bedreiging voor het internet, en in tegenstelling tot Internet Explorer zal het een heel stuk lastiger zijn om er vanaf te komen.

Overigens is Chromium ook een WebKit-browser - dus WebKit testen is vrij eenvoudig.

De ontwikkeling gebeurt voornamelijk achter gesloten deuren, en keuzes worden voornamelijk gemaakt vanuit het commerciële oogpunt van Google en interne bedrijfspolitiek. Mensen buiten Google hebben er bijna niks over te zeggen, en code bijdragen is bijzonder lastig. In de praktijk komt het er op neer dat ze af en toe een bak met code over de schutting heen gooien. Dit is compleet anders dan de werkwijze van reguliere open source software.

Jij maakt er wel een karikatuur van. Dit zijn grote en complexe codebases waar heel veel mensen aan werken. Om dat beheersbaar te houden en in goede banen te leiden heb je strikte regels en procedures nodig. Dit vormt een hoge drempel wanneer je iets wil bijdragen maar dat is dus niet zonder reden. De werkwijze van Chromium is helemaal niet zo uniek wanneer je die vergelijkt met de procedures die WebKit en Firefox hanteren om iets bij te kunnen dragen.

Daarnaast is Chromium wellicht open source, maar dat zegt weinig over de toekomst. Chrome is namelijk gewoon closed-source, en Google doet er alles aan om mensen Chrome te laten gebruiken in plaats van Chromium. Android is in theorie ook open source, maar in de praktijk is er steeds meer verplaatst naar closed-source apps en is een Google-vrije build praktisch onmogelijk. Er is geen enkele garantie dat dit niet in de toekomst met Chromium gaat gebeuren.

Google is een bedrijf dus nogal wiedes dat ze willen dat zo veel mogelijk mensen hun diensten en producten gebruiken, dat wil ieder bedrijf. Dat doet verder niets af aan het open source karakter van Chromium of AOSP. Chrome is niet veel meer dan Chromium + een aantal integraties met diensten van Google. En AOSP omvat het besturingssyteem. Waar jij waarschijnlijk op doelt met closed-source apps zijn diensten die zitten verpakt in Google Play Services. Die diensten/apps hebben in principe weinig van doen met het besturingssysteem want het zijn toepassingendie bovenop het besturingssysteem draaien. Dat een Google-vrije build praktisch onmogelijk is slaat nergens op, LineageOS, /e/, GrapheneOS en CalyxOS bewijzen het tegendeel.

Zodra een browser praktisch een monopolie heeft, kunnen ze doen wat ze willen. Chrome en Safari zijn de enige browsers met een noemenswaardig marktaandeel. Leuk dat dingen als Edge en Opera bestaan, maar praktisch niemand gebruikt ze, en de ontwikkelaars nemen klakkeloos alle keuzes van Google over. De monopolie van Chrome is een bedreiging voor het internet, en in tegenstelling tot Internet Explorer zal het een heel stuk lastiger zijn om er vanaf te komen.

FLoC was anders een prima voorbeeld dat zelfs Google zich niet zomaar alles kan permiteren enkel omdat ze een groot marktaandeel hebben. Als Google te ver uit te pas gaat lopen dan loopt het een risico dat de andere partjen, die gebruik maken van Chromium, de boel forken en samen een andere richting inslaan (beetje zoals Google destijds WebKit forkte en met Blink een eigen koers ging varen). Daar heeft geen van allen echt belang bij omdat ze dan niet meer van elkaars werk kunnen profiteren. Het is in ieders belang om samen te blijven werken.

Overigens is Chromium ook een WebKit-browser - dus WebKit testen is vrij eenvoudig.

Blink is een fork van WebKit maar dat is inmiddels bijna tien jaar geleden. In de tussentijd is zoveel aangepast dat je niet meer kunt spreken van een WebKit-browser, laat staan dat je het als drop-in replacement kunt gebruiken (op niet Apple-hardware) om te kijken hoe je site functioneert in browsers die op iOS of iPadOS draaien. Zelfs GNOME Web, dat op WebKit draait, volstaat daarin niet.

Dus?


Er is geen alternatief waarbij de Dames en Heren van Google niet aan tafel zitten.


Dezelfde Dames en Heten die miljarden aan belasting ontwijken om er maar voor te zorgen dat we reclames krijgen voorgeschoteld.

Een simpel voorbeeld is dat deze mensen het vertikken om op video-search het aantal resultaten van hun hun eigen systeem youtube te beperken tot vb 40%.


Als jij met die mensen aan tafel zitten die bewust zagen aan een aantal fundamentele principes van een open-markt beleid, succes er mee. Ik sluit ze bewust uit omdat ze zich bewust dom gedragen en als je ze betrapt liegen ze in je gezicht dat het per ongeluk was.

Er is geen alternatief waarbij de Dames en Heren van Google niet aan tafel zitten.

Die zijn er wel? Zie WebKit en Gecko (Firefox).

Een simpel voorbeeld is dat deze mensen het vertikken om op video-search het aantal resultaten van hun hun eigen systeem youtube te beperken tot vb 40%.

Wat heeft dit met de browserengine te maken? En als de zoekresultaten niet bevallen dan gebruik je toch lekker een andere zoekmachine?

Open source of niet heeft geen invloed op de stelling. Noch dat het schikbaar was op 1 platform. Indertijd was er maar 1 platform, dat dat er nu meer zijn maakt 0 verschil.

• Floc, ggogle's manier om nog slimmer te tracken, weinig verrassed dat browsers van leveranciers die meer privacy willen geven aan hun klanten geen zin hebben om dat te implemneteren
• IE was niet beperkt tot 1 platform, er is een tijd lang een OSX versie geweest van IE, naast Safari.

[Reactie gewijzigd door Yalopa op 6 februari 2023 16:26]

Safari en Firefox zijn enige die een kans maken tegen Google's Chrome, maar het lijkt een verloren strijd te worden. Wanneer Apple straks "andere browsers" moet toestaan, heeft Google een complete monopolie op web.

Alles op chromium zal lekker democratisch worden met een advertentie-gigant aan het roer.

[Reactie gewijzigd door Gamebuster op 6 februari 2023 13:09]

Niet als Google Manifest V3 uit gaat rollen in Chrome, en de ad-block fabrikanten nog geen alternatief hebben gemaakt.
Als ad-blocks niet werken, verwacht ik dat heel snel een hoop mensen naar Firefox over schakelen. Al zijn het maar de wat meer bekwame tweakers die eerst overstappen. Die zullen toch al snel met trots opscheppen dat ze helemaal geen last hebben van ads, en dan willen meer mensen dat weer hebben.

We gaan zien hoe ver ad-blockers gaan werken, maar zo niet, dan zou het weleens een omslagpunt kunnen zijn.

Als ad-blocks niet werken, verwacht ik dat heel snel een hoop mensen naar Firefox over schakelen.

Dat is een grote "als". Waarom werken adblockers niet in Manifest V3? Volgens deze site is de impact beperkt: https://nordvpn.com/blog/manifest-v3-ad-blockers/

En deze: https://blog.adblockplus....ing-ready-for-manifest-v3

Lijkt erop dat het enige impact heeft, maar niet het einde van adblocking. Plugin-makers vinden wel een oplossing.

De NordVPN link is eigenlijk gewoon een advertentie voor hun Threat Protection service.
En ja, natuurlijk dat die blijft werken, het is een VPN.

AdblockPlus geeft toch duidelijk aan dat er verscheidene beperkingen zullen zijn met Manifest V3.
Adblockers zullen inderdaad niet volledig stoppen met werken, echter met beperkingen.

Ik wilde zeggen: we zullen zien wat het brengt, maar ik niet, want ik gebruikt Firefox.

AdblockPlus geeft toch duidelijk aan dat er verscheidene beperkingen zullen zijn met Manifest V3.
Adblockers zullen inderdaad niet volledig stoppen met werken, echter met beperkingen

Alleen al EasyList heeft een kleine 60 000 regels - dan is een limiet van 30 000 regels een halvering van de functionaliteit.

Dan zie ik liever dat het gebaseerd wordt op Quantum browser/Firefox.
Chromium is niet hetzelfde als Google Chrome, maar uiteindelijk houd je dat ecosysteem zo wel in stand.
Zie het als /e/OS, wat op Android gebaseerd wordt. Goed initiatief, maar ... zo blijven we dus wel het ecosysteem van Google indirect ondersteunen. En dat wil je net niet.

Zoals anderen al hebben gereageerd, Safari ook op chromium gaan baseren lijkt me geen goed idee, zo hou je weinig verschillende smaken over. Echter zou het wel goed zijn als Safari updates los zouden worden gekoppeld van OS-updates. Ik denk dat daar een hoop problematiek mee verholpen zou zijn

[flame suit on]
Safari is de nieuwe Internet Explorer.
Het kost steeds meer moeite om om alle beperkingen heen te werken.
Safari daarom ook op Chromium gaan baseren.
En daar "democratische" besluiten nemen over doorontwikkeling van *de* web/HTML standaard.

Je kunt er bijna niet verder naast zitten!

Chrome heeft een marktaandeel van bijna 70%.
Chrome plus de andere Chromium gebaseerde browsers (waaronder MS Edge) hebben een marktaandeel van boven de 80%.

Het niet-democratisch tot stand gekomen Chromium van het miljardenbedrijf Google heeft een bijna-monopolie!

Laat alsjeblieft Safari en Firefox bestaan, zonder dat heeft dataverzamelaar Google weer een monopolie erbij.

Het wordt tijd dat de Amerikaanse overheid Alphabet / Google gaat opsplitsen. En er moet een wet komen dat sites niet voor Chrome geoptimaliseerd mogen worden, want dat betekent namelijk dat de W3C compatibiliteit ver te zoeken is, waardoor de browserervaring in Safari en Firefox minder is.

Dat gebeurd al (en is mijns inziens een probleem). Google Chrome en Safari gebruiken dezelfde rendering engine: Webkit. Alleen Firefox is een browser met een andere rendering engine.

Hoe het zit met de besluitvorming weet ik niet

https://www.chromium.org/...ing-a-web-page-in-chrome/

Google Chrome gebruikt geen WebKit, ze gebruiken net als Edge de Blink engine, die is een afgeleide van WebKit.

Bron: https://en.wikipedia.org/wiki/Blink_(browser_engine)

(dubbel)

[Reactie gewijzigd door Gamebuster op 6 februari 2023 13:09]

Ik zou liever zien dat ze hun browser op gecko of servo baseren, dan blijft het in iedere geval geen monopolie van google.

Tja WebKit houdt diverse technologiën tegen tbv de Apple Appstore (werkende WebGL2, een fatsoenlijke WebXR ondersteuning). Zou mooi zijn met wat concurrentie...

"Wat concurrentie" in deze betekent helaas waarschijnlijk dat Google Chrome een monopolie krijgt op de browsermarkt.

Je kunt toch gewoon Safari gebruiken als je IOS hebt?

Dat veel mensen dan misschien overstappen op Chrome.... Tjah, dan moet Apple maar een betere browser maken.

Dat is wat kort door de bocht.
Google heeft al eerder services zoals YouTube slechter laten draaien op concurrerende browsers om hun eigen browser Chrome beter naar voren te laten komen.
Ik vermoed een belangrijke reden voor Microsoft om hun eigen browser Edge op Chromium te baseren.

Vergeet ook de zakelijke markt niet, Edge is een stuk meer expliciet in het niet delen van je gebruiksdata dan Chrome. Om die reden is voor veel banken, etc. Edge de standaard. Daarnaast is het met Endpoint makkelijker Edge te managen en kan je zakelijke browserprofielen syncen.

Edge heeft bij default de hele reeks aan "stuur al mn data door naar microsoft" aan staan hoor.
Als je privacy en een degelijke browser wil gebruik je Firefox.

Die optie kan je als IT organisatie in Edge centraal uitzetten, bij Chrome is dat echter niet 100% uit te sluiten.

Ook bij Edge is niet uit te sluiten dat er bij een volgende update niet een heleboel data naar Microsoft wordt verstuurd. Je blijft dan bezig. Firefox is dan ook zakelijk een veel eenvoudiger keuze.

Ja want Microsoft staat bekend om het niet ongevraagd doorsturen van gebruikersdata...

Sysadmins inhaleren iets teveel microsoft copium de laatste tijd

Of Safari. Prima privacy, lekker snel en goede integraties. Ik vind Firefox helemaal geen fijne browser. Het zal wel vloeken in de kerk zijn, naast Safari fijn vinden , maar eigenlijk mis ik de Opera met presto van de dagen van weleer. (nee Vivaldi is niet hetzelfde.)

Chrome ook maar dan naar Google!

Elk woordje wat je in de omnibox typt, zelfs zonder enter te drukken wordt naar Google gestuurd.

Ik vermoed een belangrijke reden voor Microsoft om hun eigen browser Edge op Chromium te baseren.

Vergeet ook de zakelijke markt niet

De zakelijke markt lijkt mij geen argument voor Microsoft om hun eigen web engine te dumpen en die van Google te omarmen.

De reden dat Microsoft overgestapt is puur hun kleine marktaandeel. Het kost een stuk meer om volledig je eigen browser te ondersteunen.

Maar met de hoeveelheid werk die Microsoft in Chromium Edge verzet heeft, was het achteraf gezien makkelijker geweest om gewoon Trident/Edge Html verder te ontwikkelen.

En op dezelfde manier zorgt Apple ervoor dat je hun apparaten moet kopen wil je hun klanten kunnen bedienen en weigeren ze features die zelfs in Firefox zitten in te bouwen of stellen ze die jaren uit.

Niemand in het browserspelletje is onschuldig. Als ik zie hoeveel mensen Samsung Internet gebruiken, denk ik niet dat er op Apple veel mensen over zullen stappen zolang hun browser competitief blijft. De meeste mensen weten helemaal niet wat een browser is, ze weten alleen het icoontje te vinden van "internet". Zie bijvoorbeeld de verschillende enquêtes op de wereld waar men aangeeft veel meer Facebook te gebruiken dan "het internet"; dit soort dingen zijn technische details waar de meeste mensen geen rekening mee houden.

Helemaal nu Chrome al controversieel is vanwege hun WebExtensions-keuzes, denk ik dat alternatieven veel meer kans hebben. Laat Google lekker Chromium naar iOS porten, dan kunnen Brave/Vivaldi/Opera/Microsoft meteen een maand of twee later daadwerkelijk populaire browsers maken.

Ja, Google's web developers zijn net zo incompetent als de rest van de webdevwereld als het aankomt op "browsers die niet Chrom[e|ium] zijn" maar Chrome heeft momenteel zo'n groot marktaandeel om een reden. Hun browser is over het algemeen de snelste, zelfs in code die niet specifiek voor Chrome is geoptimaliseerd, en werkt op alle platformen.

Momenteel heeft Chrome op iOS ook al een behoorlijk marktaandeel en dat komt mede doordat lang niet iedereen zin heeft om een Mac met Safari te gebruiken willen ze wachtwoorden en dergelijke syncen.

Apple's WebKit is op veel plekken heel goed en ik denk dat ze zich in de browsermarkt kunnen verankeren als ze cross-platform zouden gaan. WebKit is zuiniger met stroom, rendert relatief snel, en heeft een aardige UI, genoeg om veel mensen en ook ontwikkelaars te bedienen. Met de ontwikkelwijze die Apple nu hanteert, waar ontwikkelaars straal lijken te vergeten dat iOS/Mac-gebruikers wereldwijd een minderheid zijn, zie ik ze jammer genoeg hun huidige marktaandeel snel verliezen.

Ik zie veel tevreden Safari-gebruikers bang zijn dat Google er met competitie voor zal zorgen dat mensen niet meer even veel moeite doen om Safari te ondersteunen, maar misschien moeten die mensen zich een keer afvragen waaróm niemand speciaal voor Safari wil ontwikkelen. Ik kan nú een VM downloaden met een geactiveerde versie van Windows en Internet Explorer 11 op Linux of Mac en daarmee mijn website doortesten maar als ik Safari wil testen, wordt dat een Mac of iPhone kopen of een derde partij betalen om een cloudbrowser te mogen bekijken. Je zou kunnen kijken naar WebKit, dat is cross-platform, maar dat gedraagt zich lang niet hetzelfde als Safari dus is geen alternatief.

Die alternatieve browsers komen eraan, dat staat vast. Het is nu aan Apple om te zorgen dat dat geen probleem is voor hun gebruikers en browserteam. Ja, helaas betekent dat dat Apple misschien VP9 moet gaan ondersteunen of zelfs de langbeloofde Web Push-ondersteuning eindelijk een keer uitbrengen en dat zal tijd en geld kosten, maar concurrentie kost altijd geld.

[Reactie gewijzigd door GertMenkel op 6 februari 2023 15:14]

Je kunt toch gewoon Safari gebruiken als je IOS hebt?

Tot geen enkele website het nog ondersteunt omdat iedereen alleen voor Chromium ontwikkelt. Google heeft op de browsermarkt ontzettend veel macht omdat ze ook de populairste websites bezitten.

Krijgen ze ook nog iOS erbij dan kan Google eigenlijk het W3C wel vaarwel zeggen en zelf de webstandaarden gaan bepalen (iets dat ze momenteel ook al doen, want ze lopen vaak voor op de standaard).

Wat dan weer niet gaat gebeuren omdat ze zichzelf dan in de voet schieten door iPhone gebruikers te negeren.

Die negeren ze niet, die dwingen ze dan even hard om een andere browser te installeren willen ze kunnen browsen.

Wat ze eigenlijk al proberen, zeker met die co-hort flock tracking.

Ik als developer zou daar erg blij mee zijn. Safari werkt echt tegen. Ik ben niet bang voor een IE monopoly scenario (zoals dat voor mijn tijd scheen te zijn) omdat de basis van Chrome nog altijd open source is (en ja, daar heeft Google te veel in de melk te brokkelen), maar je hebt binnen no-time een mooie Chromium fork.

edit: haakjes afgesloten

[Reactie gewijzigd door SilentLucidity op 6 februari 2023 16:09]

De basis van Chromium is open source. Google bepaald welke commits toegevoegd worden. Open Source zegt op zichzelf echt helemaal niets, men gebruikt get alsof het een magisch woordje is.

In de praktijk is Chromium helemaal niet zo 'open'.

De broncode is vrij in te zien en te forken, wat is daar niet open aan? Tuurlijk bepaalt Google zelf wat er wel of niet toegevoegd wordt, het is immers hun eigen code.
Maar uiteindelijk heeft het geen zin, want elke fork is weer gebaseerd op de code van Google, en gebruikt dezelfde engine. En als je dat allemaal aanpast en verbetert moet je alsnog bekendheid zien te krijgen.

Maar dat is toch wat ik zeg? Google bepaalt wat er in Chromium gaat, maar in tegenstelling tot IE zou je dus een fork kunnen maken en dan heb je een al meteen een hele stabiele browser.

Met Safari heb ik de afgelopen twee weken problemen gehad met Smooth scrolling, push notificaties & https://bugs.webkit.org/show_bug.cgi?id=160953 uit 2016.

Ik weet niet of je blij moet zijn met een Google monopolie, Elke fork gebruikt immers de Blink engine.

Tsja Chromium en Blink gaan hand in hand. Maar ik kan wel een degelijke push notificatie API gebruiken.

Als dat de enige reden is (niet dat ik denk dat het blokkeren van andere engines dan Webkit binnen iOS gaat helpen tegen die monopolie).
Het probleem van zo'n monopolie is dat Google uiteindelijk de webstandaarden bepaalt.

Uiteraard is dat niet de enige reden, het is een van de recentelijke voorbeelden. En inderdaad, het wordt als monopolist wel makkelijk om een standaard bij W3 voor te stellen en maar gewoon direct door te voeren (zoals IE in de tijd deed) maar zoals ik al aan probeerde te geven is het voor elke Chromium-based browser mogelijk om andere keuzes te maken. En daarvoor hebben we gelukkig Edge, Firefox, Opera, en andere (Chromium-based) browsers.

Binnen no-time een Chromium fork, maar niet binnen no-time die Chromium fork zo populair als de oorspronkelijke Chromium main branch die met Google's Chrome mee komt.

Dat gezegd hebbende, ik denk niet dat het in stand houden Apple's blokkade de oplossing is. Ik denk ook niet dat het puur af moet hangen van 'competitie'; als Google Chrome een marktleider is, en dat is het op desktop, dan moet het streng(er) gecontroleerd worden of er geen sprake is machtsmisbruik (b.v. sites voortrekken en misschien wel verbieden dat het features gebruikt in diens producten zonder dat die door een standaardisatieproces zijn gegaan)

Een rebase voor Vivaldi, Edge of Brave op die fork zal inderdaad niet gemakkelijk zijn, maar het kan wel. Het is Google ook gelukt. Ieder slim Neefje dat Chrome installeerde bij zijn oom (of buurman, maar dan is het geen neefje). Het is in ieder geval fijn dat specs gewoon werken, we moeten inderdaad wel waken voor het misbruik door zo standaarden to doorforceren zoals Google's Floc(?).

Ik heb met development weinig problemen met Safari.

Het ene probleem (monopolie Chrome) moet echter niet het oplossen van het andere probleem (gesloten platform) tegenhouden. En vergeet niet dat Apple in bepaalde regio's en doelgroepen ook een monopolie heeft die marktwerking tegen kan gaan.

Ja, Google Chrome's hegemonie is slecht (daarom ben ik net weer teruggegaan naar Firefox), maar de oplossing is NIET om dan maar Apple zn platform te laten dichttimmeren en iedereen te verplichten een browser te gebruiken die webstandaarden breekt om toch maar de appstore aantrekkelijker te maken dan webapps. Het is absurd om de mogelijkheid van keuze af te schaffen in de naam van 'ja maar anders komt er een monopolie'.

Als je dat een oplossing vindt kan je ook wereldvrede proberen te verkrijgen door gewoon de mensheid uit te roeien.

Valt mooi mee, Chrome heeft al een redelijke monopoliepositie, maar deze technieken werken dat niet perśe in de hand. Mozilla en andere browsers kunnen deze specificaties gewoon inzien en ondersteunen.

Apple's houding tegenover WebGL enz. heeft weinig te maken met de App Store en eerder met een onbekend juridisch geschil omtrent OpenCL tussen Apple en de Khronos Group (eigenaar van de OpenGL/Vulkan/..-standaarden) wat er voor zorgt dat Apple geen deel uit kan maken van de ontwikkeling van nieuwere standaarden van Khronos.

In feite is juist hierdoor een alternatief ontwikkeld (WebGPU) wat Apple ook ondersteunt en wat niet een of andere 'normale' API is die achteraf aangepast is voor het web, maar een API die onder andere op het aspect 'veiligheid' van meet af aan ontworpen is als web-API.

(en ook meer als Metal/D3D12 een vriendelijkere API is dan Vulkan)

[Reactie gewijzigd door NTAuthority op 6 februari 2023 13:03]

Alleen is WebGL zeker niet het enige probleem hier, ze missen ondersteuning voor verschillende APIs die websites meer als apps laten werken, waaronder dingen zo basic als notificaties (wat wel belooft is, maar nog steeds niet beschikbaar).

Daar ben ik dan juist weer een voorstander van.
Ik vind het hele concept verschrikkelijk dat een website zich als een app gedraagd. Althans. Eentje die op de achtergrond dingen regelt. Ik wil juist absoluut niet dat een website mij reclame/pushberichten kan toesturen via m'n OS.

Er zijn gigantisch veel webdiensten met een prima mobiele site en ook een app. De app voegt in mijn ervaring vrijwel niks toe aan de mobiele site behalve dat het makkelijker is om te tracken voor het bedrijf dat er achter zit.

Nou moet ik eerlijk bekennen dat ik vrijwel geen verstand heb van webtechnologieën als WebGL/WebRTC en weet ik wat er allemaal bestaat, maar ik ben zelf vrij conservatief met de insteek dat een website vooral een website moet zijn en zich niet per se moet willen gedragen als een applicatie die dynamisch zonder tussenkomst van mij als gebruiker of van welk controlemechanisme dan ook.

Misschien dat ik de plank compleet mis sla hoor, maar dit is hoet ik het in m'n hoofd heb zitten.

Push notificaties van tweakers werken wel op een stokoude Android phone bijvoorbeeld maar niet op een peperdure iPhone

En ook op een S23 Ultra, en niet op een iPhone 6S. Prijs is niet van invloed, dus is het irrelevant om te benoemen. Sowieso is prijs niet relevant, want dat is al heel lang geen factor in de software op een smartphone.

Apple's houding tegenover WebGL [heeft eerder te maken met] een onbekend juridisch geschil omtrent OpenCL tussen Apple en de Khronos Group (eigenaar van de OpenGL/Vulkan/..-standaarden) wat er voor zorgt dat Apple geen deel uit kan maken van de ontwikkeling van nieuwere standaarden van Khronos.

Is er meer bekend over dat onbekende juridische geschil? Ik vind het wel interessant/relevant maar kan er niets over vinden.

Ik wil graag leren, want ik heb hier absoluut geen verstand van.

Waar loop ik als gebruiker tegenaan dan? Ik kom eigenlijk nooit op sites die het niet doen (zoals ze het moeten doen zover ik door heb) op m'n telefoon. Ik gebruik alleen Safari. Ik heb in het verleden naar andere browsers als Firefox e.d. gekeken (M'n enige browser op m'n laptop), maar die voegde eigenlijk niets toe voor mij. Alleen extra bloat en gezeur of ik wil inloggen en syncen enzo.

‘Wat concurrentie’ zal er niet komen door de enige serieuze concurrent van Apple/webkit, namelijk Google/Firefox nog machtiger te maken.

Begrijp me goed, ik ben warm voorstander van concurrentie of beter gezegd: Tegenstander van monopolies. Maar het is juist Google die de verreweg grootste macht is op dit gebied en die in haar eentje het w3 kan gaan bepalen als ze hun browser engine op iOS krijgen.

Idealiter komen allerlei partijen samen via het W3-consortium tot mooie standaarden, maar ja, de praktijk is weerbarstig, zullen we maar zeggen.

edit: Ik @aldieaccounts heeft gelijk, ik zit niet goed op te letten qua opschrijven, FF is natuurlijk maar een kleine speler, ik bedoelde Google (Chrome).

[Reactie gewijzigd door laptopleon op 6 februari 2023 14:14]

Google/Firefox ? Je bedoelt Google/Chrome waarschijnlijk.

Firefox heeft wel jarenlang held gekregen van Google om de default zoekmachine te mogen zijn (en misschien nog steeds wel? ) maar Firefox wordt niet gemaakt door google.

Apple Webkit is een doorontwikkeling van KHTML en Blink (de enigine van chrome) is weer een doorontwikkeling van een fork van webkit.

Firefox is juist de enige die op een engine draait die echt anders is: Gecko.

Hij bedoelt Google Chrome / Firefox denk ik.

Beetje raar om dat op 1 hoop te gooien. Firefox 'nog machtiger' maken is voorlopig (tot ze weer boven de 25% marktaandeel komen ofzo) nog een prima idee m.i. ;-)

Firefox heeft bijna zijn gehele marktaandeel aan Chrome verloren. En maar lekker Google als standaard laten staan voor het grote korte termijngeld.

Mozilla heeft weinig keuze, zonder de financiële afhankelijkheid van Google, was Mozilla al lang en breed failliet geweest.

Hoog tijd dat overheden eens kei en keihard gaan optreden tegen de misselijke praktijken van Google.

De reden dat dit monopolie in dit scenario tot stand zou kunnen komen is echter de conesequentie van Apple's monopolie te verwijderen via de controle die zij uitoefenen op de App Store.

Ik ben het met je eens dat monopolies op elk niveau ongewenst zijn, dus ook voor iOS, maar in dit geval zou je kunnen verdedigen dat Apple's Safari webkit toch een positief effect heeft.

iOS heeft een marktaandeel dat te groot is om te negeren. Ontwikkelaars en webdesigners komen er daardoor niet mee weg alleen te testen voor één browser en zodoende de andere browsers te dwingen die te volgen, oftewel de browserwars zoals we in die jarenlang kenden in het verleden toen Internet Explorer dominant was en Netscape de das om deed.

Ja hee. “Experimentele browser” is dus gewoon een webdev tool. Het is dan dus helemaal niet opvallend dat iOS het niet toestaat en deze app het wel doet, want het is dus eigenlijk geen browser, maar een debug tool.

Verder wel eens dat het dan waarschijnlijk wel een pre-cursor is voor webkitloze iOS browsers.

Voor iOS-gebruikers zou het positief zijn als de browsermarkt daar wordt opengebroken.

Voor internetgebruikers in het algemeen is het stiekem positief dat Apple zo vasthoudt aan WebKit. Anders zou Chrome nu op elk platform super dominant zijn en daar is eigenlijk niemand mee geholpen. Google dwingt onder het mom van open source alsnog zijn eigen standaarden en wil door.

Nee dit is juist absoluut niet goed voor de browsermarkt en ook niet voor iOS gebruikers.
Juist om de reden die je in je 2e alinea beschrijft.

De monopolie van Google met Chrome wordt alleen maar groter. Samen met Firefox is Safari (Webkit) de enige die iets tegenover Chromium zit totdat ze de complete browsermarkt overnemen en er geen concurrentie mee is.

Er wordt de laatste jaren door Apple ontzettend hard gewerkt aan Safari om de achterstand die ze hebben opgelopen in te halen en het is echt indrukwekkend hoeveel stappen ze hebben gezet. Dit in combinatie met initiatieven zoals InterOp zorgen ervoor dat Safari zich inmiddels echt wel kan meten met FF en Chrome.

Ja precies, dat bedoel ik ook. Het lijkt met een beperkte blik goed voor iOS-gebruikers, maar uiteindelijk zal iedereen aan vrijheid inboeten. Dat is zo interessant aan de gesloten houding van Apple: zolang dat bedrijf geen meerderheid heeft op een markt is het eigenlijk een zegen, hoe zeer het vaak ook lijkt op iets dat 'aangepakt' zou moeten worden.

Apple gaat waarschijnlijk ook WebKit niet meer verplicht stellen: https://www.macrumors.com...n-webkit-iphone-browsers/

Mocht dat waar zijn, dan hoop ik dat FF op iOS dan net als de Android variant wordt, dan zie ik een reden om op iOS naar FF over te stappen (want nu voegt dat niks toe voor mij)

Ik vind Safari wel fijn hoor, alleen ik vind FF op Android (en PC maar dat terzijde) beter.

Safari is een okay tot prima browser, maar het loopt achter en dat is best te merken.

Waar merk je dat aan dan? Serieus benieuwd.

Ik zelf heb niet enorm veel problemen met Safari, maar het valt mij op dat 3 dingen wel regelmatig terug komen.

- websites die je voorkeur voor een desktop modus negeren, waar op FF en Chrome op Android dit vaker wel dan niet prima werkt, zie ik vaak genoeg met Safari dat een website die voorkeur gewoon negeert, en met sommige websites komt het dan erop neer dat ik mijn Android toestel of PC voor moet gebruiken.

- websites die ineens stoppen met laden, dit is een issue die ik sinds iOS 16 heb, en nu op 16.3 nog steeds last van heb. Het komt meerdere keren per dag dat Safari gewoon een website niet in wil laden, en dat zonder dat Safari zichtbaar crashed. Vaak is de snelste oplossing om een tablad af te sluiten, nieuwe te openen en dan ineens werkt het wel, maar het is irritant.

- websites die anders (slechter) werken op Safari dan in Chrome en FF, dit komt minder vaak voor gelukkig maar ik heb het meerdere keren meegemaakt dat bepaalde websites gewoon anders (vaak slechter) met Safari op iOS omgaan. En dan wil de desktop modus dat weleens oplossen (vreemd genoeg) maar zoals mijn eerste issue al vermeldt, desktop modus werkt niet altijd.

Over het algemeen werkt Safari voor mij prima, alleen komt dat 2de issue ineens sinds iOS 16.3 dagelijks voor, soms wel 10 keer per dag (en settings herstellen en verwijderen heeft het niet opgelost voor mij)

Punt 1 en 3 had ik al last van in iOS 15 overigens.

Sommige websites dan stopt het met typen of vreemde auto correct, alsof een of ander script niet lekker ligt.
Webm’s niet kunnen bekijken.

Traagheid valt nog mee.

Op iOS is het gebruik van WebKit voor een browser verplicht

En dat noemt zich smartphone?

Even voor jou: iOS is het OS voor de smartphones van Apple, iOS noemt zichzelf geen smartphone. En iOS is geen persoon (natuurlijk of AI), dus het noemt zichzelf niks.

Daarnaast mag je (achteraf gezien) blij zijn dat dankzij Apple het marktaandeel van Chrome / Chromium niet op 99% zit.

Ik ben vaak een tegenstander van verplichtingen, maar in dit geval ben ik blij! Dankzij Apple doen de meeste sites het ook goed op andere dan Chromium browsers.

Op iOS is het gebruik van WebKit voor een browser verplicht, waardoor iOS-browsers niet veel kunnen afwijken van Safari.

Dat lees ik wel vaker, maar vind ik zo'n kul. Met welke render engine html op het scherm gezet wordt is maar een klein deel van de gebruikerservaring. En alleen interessant voor techies zoals wij. Voor doorsnee gebruikers is de hele applicatie eromheen wat het onderscheid maakt en daar zijn heel soorten in, ook op iOS. Keuze genoeg in browsers, en sommige wijken juist enorm af van Safari (kan me nog een Opera browser op iPad herinneren met een tile achtige interface, heel apart ding).

iCabMobile is daar een enorm goed voorbeeld van. Een zeer uitgebreide browser met tal van extensies, features, analyseopties en zaken die je in Safari echt niet terug kan vinden. Echt geweldig gedaan. Dat het onder de motorkap webkit gebruikt om te renderen: ja lekker boeiend.

Uiteraard is dat boeiend. Safari ondersteunt bijvoorbeeld geen push notificaties.

Een browser waar je echter wel eventjes € 3,49 voor neerlegt. Dat gaat nergens over. Overigens ben ik wel benieuwd welke extensies dan allemaal aanwezig zijn.

Vooralsnog kan je op iOS bijvoorbeeld extensies als 'Dark Reader', 'Adguard' enkel gebruiken in Safari. Heel apart, want alle browsers immers gebaseerd op Webkit. Klaarblijkelijk heeft Apple de mogelijkheid geblokkeerd om deze in andere browsers als Firefox en Chrome te gebruiken. Waarom?

Ik ben nu bijna twee jaar geleden overgestapt op iOS om wat minder Google in m'n leven toe te laten. Maar de hele ideologie van Apple rondom hun besturingssystemen staat mij gigantisch tegen. Laat ze op z'n minst er eens voor zorgen dat extensies als U-Block origin in hun mobiele Safari browser werken.
Verder iets relatief kleins, op Android al jaren mogelijk, maar op iOS nog altijd niet: Het instellingenscherm openen via het snelmenu (voor Wif-FI, Bluetooth etc.).
Zomaar twee dingen, maar ik zou dit met gemak met meer voorbeelden kunnen uitbreiden.

(CC: @calvinturbo)

[Reactie gewijzigd door JKP op 7 februari 2023 04:43]

Ja, vreselijk. Wereldschokkend bedrag voor een zeer uitgebreide en constant bijgewerkte app. Die dev zou gratis moeten werken, de vuile gier. Wel geinig om dan te klagen over het gebrek aan functies in de gratis apps die je benoemt, maar afijn. Dit klinkt net als “De officiële Reddit client is echt kamehameha-superkut, maar eenmalig €5 voor Apollo Pro is echt belachelijk duur!!1!”.

iCabMobile heeft tal van extensies (Dark Reader heb je niet nodig want heeft zelf out-of-the-box functies daarvoor aan boord), al jaren. Dus dat wordt zeker niet door Apple geblokkeerd. Ofwel de browsers’ varianten van iOS ondersteunen het niet of de ontwikkelaars van de door jou genoemde extensies interesseert simpelweg niets anders dan Safari. (Voor iOS)

op Android al jaren mogelijk, maar op iOS nog altijd niet: Het instellingenscherm openen via het snelmenu (voor Wif-FI, Bluetooth etc.).

Beetje off-topic, maar okee…: geen idee wat een “snelmenu” is, maar WiFi en Bluetooth beheer je op iOS makkelijk en snel door over je batterij-icoontje naar beneden te swipen (Control Center) of een long-press op het icoon van de “Instellingen”-app of via Siri… Als ik je goed begrijp kan dat dus wel. En ook echt al jaren.

[Reactie gewijzigd door WhatsappHack op 7 februari 2023 06:33]

Het gaat hier niet per se om WebKit, maar om het verplichte gebruik van JavaScriptCore.

De ECMAScript specificatie is niet volledig geïmplementeerd in JSC. Dat zorgt er voor dat Progressive WebApps niet fatsoenlijk ondersteund worden in iOS, waardoor men niet om de App Store heen kan.

WebCore is voor de rendering. In Chromium wordt standaard Blink gebruikt, wat een fork is van WebCore.

Dat weet ik allemaal, maar dat is niet waar het hier om gaat. Dit gaat specifiek over WebKit en daardoor geen afwijkende browsers kunnen hebben (zie de letterlijke quote).

Ik geloof overigens dat het op deze manier niet om de web store kunnen wel een opzettelijke strategie is…

WebKit bestaat uit WebCore en JavaScriptCore. That's it.

Het is ook een opzettelijke strategie. Apple heeft meer dan 10 jaar dwarsgelegen over met name ES6. Met precies de reden dat het anders hard in hun inkomsten snijd.

En daar kunnen we lekker over ranten, maar dat heeft verder weinig met de stelling in het artikel te maken dat er geen afwijkende browsers mogelijk zijn (dat was waar ik op reageerde).

Fair enough.
Die stelling van @Hayte is inderdaad niet correct.

Bijna elke partij (Op Firefox na) maakt al decennia gebruik van de WebCore rendering engine, of het nou geforked is met een paar aanpassingen of niet. Dus dat is niet de issue.

Het probleem ligt dus puur in hun beperking van JavaScript.

Wanneer je de Chromium repo bekijkt zie je ook dat ze de V8 engine aan het compilen zijn voor iOS met een paar wijzigingen van Blink om het mogelijk te maken. Zogezegd voor tracing om te kunnen debuggen.

Dus de stelling dat het beklag ligt in dat browsers niet kunnen afwijken van Safari door WebKit is niet correct.

Bedankt voor de mention Ik heb nu 'en JavaScriptCore' toegevoegd aan die zin, als ik het goed begrijp, klopt het zo wel?

Apple gebruikers hoor ik altijd nog veel over 'Apps'. Ik denk dat Apple het heel belangrijk vindt dat zijn gebruikers apps installeren via de store.

Als Android gebruiker vind ik het een beetje ouderwets. Gewoon moderne Web-App gebruiken, onafhankelijk van platform of een bepaalde store.

Kan het zijn dat daarom deze WebKit zo belangrijk is voor Apple?

Dat klopt.
WebKit is namelijk niet het punt, maar hun JavaScript engine. Daarin hebben ze de specificatie maar half geïmplementeerd. Daardoor worden PWAs niet serieus ondersteund op iOS.

Misschien schop ik nu enthousiaste Google Chrome gebruikers tegen het zere been maar ik zelf zelden tot nooit Google Chrome gebruik. Eerlijk gezegd vond ik Safari ook prima werken binnen IOS en MacOS dus of dit dan nu zo'n goed nieuws is, voor mij niet echt. Veelal gebruik ik dan ook de standaard browsers die bij het OS komen zoals bij Windows dan Edge, MacOS dan Safari, Android een standaard Samsung browser en dan binnen IOS ook Safari.