WebKit-motorn ligger långt efter konkurrenterna
Arvet från Internet Explorer 6 är fortfarande en mardröm för webbutvecklare. Microsofts webbläsare från förr gjorde livet surt för dem, och det är bara lite hyperboliskt att säga att den nästan förstörde hela Internet. Det var verkligen så illa, mina herrar.
Idag finner utvecklare som vill använda “cutting edge” webb-API:er sig att tillgripa samma typ av webbläsarspecifika lösningar, men den här gången kommer webbläsaren som drar saker från Äpple.
Safari släpar betydligt efter sina kamrater när det gäller att stödja webbfunktioner. Huruvida det är tillräckligt bakvänt för att betraktas som “den nya IE” kan diskuteras och kan säga mer om den skugga IE fortfarande kastar på webben. Men Safari – eller mer specifikt WebKit-motorn som driver den – ligger långt efter konkurrenterna. Enligt Web Platform Test Panel stöder Chrome-baserade webbläsare 94 % av testpaketet, Firefox får 91 %, men Safari får bara 71 %.
På stationära datorer spelar detta inte så stor roll eftersom användare alltid kan växla mellan webbläsare. På iOS-enheter är det dock inte möjligt. Enligt Apples App Store-regler “måste applikationer som surfar på webben använda lämpligt WebKit-ramverk och WebKit Javascript.” Alla iPhone-användare är Safari/WebKit-användare, oavsett om de använder Safari eller Chrome.
Apple har monopol på webbläsare på iOS, något Microsoft aldrig kunde uppnå med IE. På Windows kunde du åtminstone installera Firefox. Om du gör det på iOS kan det stå Firefox, men du använder fortfarande WebKit. Verkligheten är att om du har en iOS-enhet använder du Safari och du är bunden av dess begränsningar.
En annan sak som webbutvecklare tycker är överväldigande är Apples långsamma utvecklingscykel. Apple uppdaterar Safari ungefär var sjätte månad i bästa fall. Blinkbaserade webbläsare uppdateras var sjätte vecka (snart var fjärde), Firefox var fjärde vecka och Brave var tredje. Det betyder att Apple inte bara är långsam med att lägga till nya funktioner, utan dess utvecklingscykel gör att även enkla buggfixar måste vänta länge innan de når användarnas enheter. Safari-lösningar är inga snabba lösningar. Om din webbplats påverkas av en Safari-bugg kan du vänta upp till ett år innan problemet är löst.
En fråga som dyker upp när man tittar på data från Tester av webbplattformar Om Safaris brister är att även när WebKit har implementerat en funktion är den ofta inte komplett. Ta fallet med progressiva webbappar (PWA). Progressiva webbappar är ett paraplybegrepp för webbplatser som vill bete sig som inbyggda mobilappar. Några av API:erna som används för att bygga PWA inkluderar möjligheten att köra helskärm (inget webbläsargränssnitt), skicka meddelanden och varningar, offlinefunktioner och starta från en startskärmsikon. Förmodligen de två mest kända exemplen på PWA är Twitter och Uber.
Apple har implementerat mycket av det som utvecklare behöver för att bygga PWA, men det finns begränsningar. Apple har inte lagt till stöd för att skicka aviseringar och ikoner på hemskärmen. I huvudsak har Apple inte implementerat några av kärnfunktionerna som gör att webbplatser kan bete sig på samma sätt som appar.
Detta har länge varit kärnan i argumentet att Apple medvetet förlamar WebKit för att skydda sin App Store-verksamhet. Med andra ord, om Apple implementerar dessa saker kommer utvecklare att börja skapa bättre webbappar, ingen kommer att köpa inbyggda appar och Apple kommer att förlora sin andel på 30 % av iOS App Store.
Detta kan vara vettigt för webbutvecklare, som är djupt passionerade när det gäller att bygga webbapplikationer, men det är inte mycket meningsfullt utanför det sammanhanget. Apple är ett av de rikaste företagen i världen, och det bryr sig förmodligen inte så mycket vad webbutvecklare ska göra med alla dessa coola nya API:er som det inte stöder. Apple skyddar verkligen sina intressen, men det verkar åtminstone just nu ha mer att göra med Apples satsning på att positionera sig som ett beskyddare av användarnas integritet än oro över webbappar.
Sparar Safari webben?
Safaris försvarare, och Apple själv, hävdar att företaget inte implementerar alla dessa nya API:er eftersom att låta utvecklare få tillgång till dina USB-portar, Bluetooth, batteristatus och närhetssensor skulle tillåta annonsörer att skapa “fingeravtryck.” fingeravtryck” av enheten som ytterligare urholkar integriteten, för att inte tala om påverkan på batteritiden.
Jag äger inte en iOS-enhet, men ärligt talat, Apples inställning till detta får mig nästan att önska mig en.
Jag borde nog erkänna vid det här laget att jag hatar den moderna webben. Det stör mig inte så mycket eftersom att ha en mobil enhet och att ha integritet utesluter varandra. Jag gillar inte sekretess, men jag tycker att den moderna webbplatsupplevelsen är så opålitlig, långsam och allmänt användarovänlig att jag hellre skulle göra något annat.
Jag ogillar upplevelserna som aktiveras av JavaScript-baserade webb-API:er så mycket att jag har valt att surfa med JavaScript inaktiverat. Detta ger webben tillbaka en vacker, ren enkelhet som förmodligen skulle göra Apple glad. Webbplatser som laddas utan JavaScript jag läser – webbplatser som inte stör mig. Ja jag är seriös. Om Invidious kan ladda YouTube-innehåll utan JavaScript, varför kan YouTube inte? Jag vet inte och jag bryr mig inte. Jag skrev ett manus för att se till att jag alltid blir omdirigerad till Invidious (PeerTube är ett bättre alternativ) men jag avviker.
Min poäng är att jag vill stödja Apple i detta, men tyvärr tycker jag att argumentet att Apple håller tillbaka Safari för att skydda användarnas integritet är svagt. Även om jag inte tror att Apple bryr sig så mycket om att webbutvecklare skadar sina App Store-vinster, så tror jag inte heller att företaget är tillräckligt stort för att ignorera webben helt och hållet och inte drabbas av konsekvenserna. Det vill säga, Apple kan tro att de agerar för att skydda användarnas integritet, men det kommer inte att fungera.
Det faktum att dessa API:er inte har implementerats har inte hindrat dem från att användas i alla andra webbläsare. Det kommer att ta ett tag, men vi vet redan hur den här historien slutar. Det slutar som det slutade för Internet Explorer: Microsoft förlorade. Alla andra gick vidare och så småningom var Microsoft företaget med produkten som ingen ville ha. Om Apple går den vägen kommer det inte bara att förlora Apple, utan även webben. För Apples försvarare har rätt i en sak: Om Apple inte tar sig an Googles gigantiska Blink, ser det inte ut som om någon annan kommer att göra det.
Hur ser det där monstret ut? Webbutvecklaren Tim Perry påpekade nyligen att alla webbläsare en gång erbjöd sina egna plugin-API:er. Men, som Perry skriver, “Chrome dominerade effektivt utvecklarens mindshare, gav mer kraftfulla och lättanvända tilläggs-API:er som blev mycket mer populära, och både Firefox och Safari … tog bort sina egna API:er och accepterade Chromes, oavsiktligt tillåter Google att ensidigt sätta standarden för webbtillägg.” Detta är vad som händer när det inte finns någon att motsätta sig marknadsledaren.
Nu händer samma sak med utvecklingsverktyg och API:er. “Chrome följer samma väg idag”, skriver Perry, “erbjuder webbutvecklare kraftfullare verktyg och en bättre utvecklingsupplevelse (bättre utvecklingsverktyg, färre buggar) än Safari. Om inget förändras kommer resultatet troligen att bli liknande. Det här är dåligt. “
Hur kunde Apple hjälpa webben?
Vad webben behöver är att någon sätter käppar i hjulet för Google och Blink och ser till att de API:er som skapas är bra för webbanvändare. Inte bara för Google-användare. Inte bara för Apple-användare. Inte bara för webbutvecklare. De är bra för alla.
Mycket av modern webbfunktionsutveckling sker tyst och med mycket lite diskussion. Blink-utvecklare föreslår funktioner genom att skicka in dem i Chrome bakom en utvecklarflagga. Vid den tidpunkten finns det redan en fungerande implementering och diskussion är svår, för att inte säga omöjlig.
Jag antyder inte att Apple har orena motiv, men det verkar som att dess syn på Safari kanske, åtminstone tillfälligt, skulle kunna vara användbar för webbstandardprocessen…om Apple kunde ändra sin inställning till Safari.
Det är förmodligen en chimär. Men som den mångårige webbförespråkaren (och mångårig Opera-evangelist) Bruce Lawson nyligen skrev: “Om Apple tillät Safari att verkligen konkurrera, skulle det vara bättre för webbutvecklare, företag, konsumenter och Internets hälsa.” Webb”.
Om Apple var mindre ogenomskinliga och snabbare i sin utvecklingsprocess skulle det kunna vara mer involverat i debatten om nya API:er. Om företaget verkligen är bekymrat över integritetskonsekvenserna av API:er bör det säga det. Stå upp mot Google och erbjuda ett verkligt alternativ till Chrome. Det skulle inte vara lätt, men det kanske är det enda hoppet vi har.
källa: The Register
Projekt
Vi använder våra egna och tredje parts cookies för att förbättra våra tjänster, sammanställa statistisk information och analysera dina surfvanor. Detta gör att vi kan anpassa innehållet vi erbjuder och visa dig reklam relaterade till dina preferenser. Genom att klicka på “Acceptera alla” accepterar du lagringen av cookies på din enhet för att förbättra navigeringen på webbplatsen, analysera trafik och hjälpa till med våra marknadsföringsaktiviteter. Du kan också välja ‘Endast systemcookies’ för att endast acceptera de cookies som behövs för att webbplatsen ska fungera, eller så kan du välja de cookies du vill aktivera genom att klicka på ‘Inställningar’
Godkänn alla systemcookies endast inställningar
Alltid aktiv
Strikt nödvändiga cookies
Dessa cookies är nödvändiga för att webbplatsen ska fungera och kan inte inaktiveras i våra system. De ställs vanligtvis bara in som svar på dina handlingar när du begär tjänster, som att ställa in dina integritetsinställningar, logga in eller fylla i formulär. Du kan ställa in din webbläsare för att blockera eller varna dig för dessa cookies, men vissa delar av webbplatsen kommer inte att fungera. Dessa cookies lagrar ingen personligt identifierbar information.
