Letzte Woche war ich bei der EdgeConf, einer Konferenz, die von vielen der führenden Leuten der Webindustrie besucht wird. Ich habe Panel-Talks und Breakout-Sessions gehalten mit einem Fokus auf Technologien, die gerade neu in Browsern Einzug halten, also gab es eine Menge lebhafter Diskussionen über Service-Worker, Web-Components, Shadow DOM, Web-Manifests und mehr.

Die über 100 EdgeConf-Besucher waren wirklich die einflussreichsten Persönlichkeiten der Web-Community. Die durchschnittliche Twitter-Follower-Anzahl in jedem beliebigen Raum lag vermutlich in den Tausenden, und alle großen Browser-Anbieter waren präsent – Google, Mozilla, Microsoft, Opera. Also hatten wir viel Spaß dabei, sie mit Fragen dazu zu löchern, wann sie diese oder jene API veröffentlichen werden.

Es gab allerdings eine Firma, die nicht anwesend war, und sie hatte die Rolle des sprichwörtlichen rosa Elefanten im Raum, über den niemand sprechen wollte. Ich hörte, wie jemand sie ausweichend als „eine Firma aus Kalifornien“ oder „die Firma mit dem Obst“ bezeichnete. Ihr leuchtendes Logo leuchtete auf fast jedem Laptop im Raum, und dennoch schien es so, als würde niemand wagen, ihren Namen auszusprechen. Natürlich rede ich hier von Apple.

Ich denke, dass es unter Webentwicklern ein allgemeines Gefühl gibt, dass Safari den anderen Browsern hinterherhinkt, aber wenn man zu einer Konferenz wie der EdgeConf geht, fällt es wirklich auf, wie groß der Abstand ist. Keine der oben genannten APIs ist in Safari implementiert, und Apple hat kein öffentliches Interesse an ihnen bekundet. (Korrektur: Okay, haben sie doch.) Wenn man auf caniuse.com nachschaut, hört die Liste gar nicht mehr auf.

CC BY 2.0)

Auch wenn Apple neuere APIs implementiert, machen sie es oft halbherzig. Ein Beispiel, das mir am Herzen liegt, ist IndexedDB, das vor mehr als fünf Jahren eingereicht wurde und schon seit 2012 für IE, Firefox und Chrome verfügbar ist. Apple dagegen hat es erst Mitte 2014 veröffentlicht, und als sie es taten, brachten sie eine rätselhaft inkompetente Implementierung heraus, die so schlecht war, dass sie weltweit als unbrauchbar verspottet wurde. (Local Forage, PouchDB und YDN-DB, die größten IndexedDB-Wrapper ignorieren alle Safaris Version und machen ein Fallback auf WebSQL.)

Jetzt, ein Jahr später, hat Apple zwei riesengroße Bugs in IndexedDB repariert (unter vielen), und sie haben öffentlich vermeldet, dass sie nicht viel Nutzen darin sehen, weiter daran zu arbeiten, weil sie „keine große Verwendung“ beobachten. Na klar, kein Mensch wird IndexedDB benutzen, wenn der Browser-Support überhaupt nicht funktioniert. (Microsoft, ich meine auch euch!)

„In den letzten Jahren kann man Apples Strategie fürs Web mit gutem Willen als ‚wohlwollende Missachtung‘ beschreiben. “

Es ist schwer herauszufinden, warum Apple so vorgeht. Sie schicken nie jemanden zu Web-Konferenzen, ihr Surfin‘-Safari-Blog ist nur noch ein Schatten seiner selbst, und bis zum nächsten WWDC weiß keiner, was die nächste Version von Safari enthalten wird. Auf eine Art ist Apple wie Santa Claus, der einmal im Jahr zu uns runterkommt, um uns ein paar sehnlichst erwartete Geschenke zu bringen, ohne Vorwarnung, welche unserer Wünsche er dieses Jahr erfüllt. Und offen gesagt sind die Geschenke in der letzten Zeit immer kleiner geworden.

In den letzten Jahren kann man Apples Strategie fürs Web mit gutem Willen als „wohlwollende Missachtung“ beschreiben. Obwohl die Performance mit JSCore und dem neuen WK WebView erheblich verbessert wurde, sind die aufkommenden Features im Web – Offline-Storage, Push-Notifications und installierbare Webapps – in Safari bemerkenswert abwesend. Es ist verführerisch, das als bewusstes Vorgehen von Apple zu interpretieren, um jedwede Bedrohung für sein App-Store-Businessmodell zu sabotieren, aber ein Zusammenhang erscheint unwahrscheinlich, weil dieser Teil des Business weitestgehend kostendeckend arbeitet. Eine andere Möglichkeit ist, dass sie nur auf die Forderungen von iOS-Entwicklern reagieren, die größtenteils auf 1) mehr native Apps und 2) schnell, schnell, schnell hinauslaufen. Aber da Apple sehr gut darin ist, einen Deckel über ihre internen Prozesse zu halten, sind das alles Spekulationen.

Die Tragödie hierbei ist, dass Apple nicht immer so ein Web-Skeptiker war. Noch 2010, als Steve Jobs bekanntermaßen Flash abservierte und HTML5 zur neuen Zukunft erklärte, war Apple ein leidenschaftlicher Web-Anhänger. Viele der frühen Features, die Web-Apps dazu verhalfen, es mit nativen Apps aufzunehmen – ApplicationCache, WebSQL, Touchgesten, Touchicons – wurden von WebKit-Entwicklern begeistert übernommen – und viele stammen sogar von Apple.

Zur gleichen Zeit, als WebSQL zugunsten von IndexedDB missbilligt wurde, findet man auf Mailinglisten Diskussionen, in denen Apple-Mitarbeiter WebSQL energisch als ein Muss für performante Webapplikationen verteidigen. Wenn ich die Debatten lese, spüre ich darin eine Menge Bitterkeit von Apple, nachdem IndexedDB sich durchgesetzt hat. Die Ironie dabei liegt darin, dass Apple uns fast die Werkzeuge dafür gegeben hat, um ihre eigene proprietäre Plattform zu unterlaufen, aber indem wir WebSQL ablehnten, gaben wir ihnen die Chance, ihre Strategie zu überdenken und die Bremsen vor jedem neuen Fortschritt bei Web-APIs zu ziehen.

„Apple ist wirklich der einzige Sänger in diesem Frisörsalon-Quartett, der alle schiefen Töne trifft.“

Ich finde, dass das eine ähnliche Geschichte ist wie mit Application-Cache, das vermutlich demnächst zugunsten von Service-Worker ausrangiert wird. Es bekam umfassenden Browser-Support zu einer Zeit, als Apple noch am Web interessiert war, aber unglücklicherweise stellte es sich als eine überstürzte, halbgare Lösung für das Problem heraus. Ich habe die Sorge, dass Service-Worker das gleiche Schicksal ereilt wie IndexedDB, wenn Apple weiterhin hinter der Meute zurückbleibt.

An diesem Punkt müssen wir in der Web-Community uns damit abfinden, dass Safari der neue IE geworden ist. Microsoft ist heute reumütig, Google treibt das Web so weit voran, wie es geht, und Mozilla ist immer noch Mozilla. Apple ist wirklich der einzige Sänger in diesem Frisörsalon-Quartett, der alle schiefen Töne trifft, und es ist Zeit, offen darüber zu reden, anstatt drumherum zu reden, als ob wir jemandes Gefühle verletzen könnten. Apple ist die wertvollste Firma in der Welt; sie können ein paar Schläge einstecken.

Was können wir also tun, wenn einer der größten Browser-Anbieter im 2010er-Modell steckengeblieben ist und darüber hinaus ein völliges Monopol auf dem iOS besitzt (ja, weil „Chrome für iOS“ ist nicht wirklich Chrome), was die Dreistigkeit der 90er-Ära von Microsoft noch übertrifft? Ich sehe drei große Bewältigungsansätze.

1. Bleib bei dem, was 2010 funktioniert hat, und verwende Polyfills für den Safari-Support. Das ist eine Strategie, die ich in meiner Eröffnungsrede für das Frontend-Data-Panel beleuchtet habe, und in der ich gezeigt habe, dass man mit der Verwendung von AppCache und PouchDB (welches beim Safari auf WebSQL zurückfällt) fast die gleichen Features erhalten kann wie mit Service Worker. Dieser Ansatz sollte an die große Mehrzahl der Webentwickler gehen, die dazu neigen, bei neuen Technologien die Schlummertaste zu drücken, bis sie cross-browser-verfügbar sind. Auf der anderen Seite ist das auch ein guter, Weg um Apple zu schmeicheln und ihnen keinen Anlass dazu zu geben, ihr Spiel weiterzutreiben.
2. Verwende Technologien wie Service Worker, die nicht im Safari laufen, und begreife sie als schrittweise Steigerung. Alex Russell hat das bei seinem „Installable Webapps“-Breakout gut getroffen, indem er sagte, dass, wenn wir eine große Menge an freien Webapps schaffen, die Service Worker verwenden und die ganz wunderbar auf Android aber *meh* nicht auf iOS laufen, es im Interesse von Apple liegen wird, dem ein Ende zu machen und die API zu unterstützen. Obwohl das das beste Resultat für die gesamte Web-Community wäre, wird es unglücklicherweise schwer, Entwickler davon zu überzeugen, Code zu schreiben, der nur die Hälfte ihres Publikums erreicht.
3. Wirke bei WebKit mit. Der Kern von Safari ist im Grunde immer noch ein Open-Source-Projekt, also gibt es keinen praktischen Grund, warum irgendjemand mit C++-Kenntnissen nicht seine Ärmel hochkrempeln und die neuen APIs selbst implementieren sollte. (Die Absurdität, kostenlose für die reichste Firma der Welt zu arbeiten entgeht mir nicht, aber wir reden hier über einen Notstand.) Das Hauptproblem, das ich bei diesem Ansatz sehe, ist, dass WebKit nicht Safari ist, und Apple könnte sich jederzeit dazu entscheiden, WebKit-Features nicht für ihren Flaghsip-Browser zu übernehmen. Um den Bogen zurück zu IndexedDB zu schlagen – vor dem Blink-Fork war es von Google voll implementiert, und mehrere Jahre lang hätte Apple nur ein kleines Stück an ihrem Build-Script schrauben müssen, um die Google-Implementierung einzufügen, aber statt dessen entschieden sie sich dafür, ein paar Jahre herumzuschwafeln und es dann mit ihrer eigenen kaputten Version zu ersetzen. Es gibt keine Garantie, dass sie das gleiche nicht mit anderen Beiträgen von Außen tun.

In der Zusammenfassung weiß ich also nicht, welches die beste Lösung ist. Ich habe mich mit vielen der WebKit-Entwickler auf Twitter verknüpft, und ich habe mir die Arbeit gemacht, reproduzierbare Test-Anwendungen zu schreiben und ihre Beta-Software auszuprobieren, also kann ich sie früh warnen. (Ja, ich bleche mehr als 200 US-Dollar pro Jahr an Apple für das Privileg, dass ich für sie ihre eigene Software teste.) Und offen gesagt bin ich langsam verbittert darüber, weil die meisten der Bugs, die ich ihnen berichtet habe, immer noch vor sich hin dümpeln, mit kaum mehr Resonanz als einen Link auf ihren internen Radar-Tracker.

Ich schätze die Arbeit, die sich viele der WebKit-Entwickler gemacht haben (Brady Eidson war besonders geduldig und hilfsbereit), aber an diesem Punkt scheint mir die besten Strategie gegenüber Apple eher die Peitsche als das Zuckerbrot zu sein. Also bin ich dazu geneigt, zu Alex Russels Lösung aus Punkt zwei zurückzugreifen, und damit zu beginnen, die Adaption von neuen Web-Technologien anzupreisen – scheiß auf den Safari-Support.

Wenn wir damit beginnen können, ein lebhaftes Ökosystem von Web-Applikationen zu schaffen, bei denen Apple nicht eingeladen ist, dann werden sie vielleicht dazu gezwungen sein, es wie Microsoft zu machen und ihren eigenen reumütigen Gang nach Canossa anzutreten. Ansonsten müssen wir uns damit zufriedengeben im Web von 2010 zu leben, in dem Safari den IE ersetzt, als ein bläuliches Icon, das Webentwickler das Fürchten lernt.

Nolan Lawson ist Entwickler, der in New York lebt und für Squarespace arbeitet. Dieser Beitrag, der übrigens nicht unbedingt die Meinung seines Arbeitgebers widerspiegelt, erschien zuerst auf seinem Blog nolanlawson.com. Übersetzung: Anja Braun.