Safari ist der neue Internet Explorer: Warum Apple inzwischen allen Browser-Anbietern hinterherhinkt [Kommentar]
Diese Gefühl, dass Safari den anderen Browsern hinterherhinkt
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.
Apple ist wie Santa Claus
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!)
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. “
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.
Apple und Safari können ein paar Schläge einstecken
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.
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.„Apple ist wirklich der einzige Sänger in diesem Frisörsalon-Quartett, der alle schiefen Töne trifft.“
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.
Drei Ansätze für das Apple-Dilemma
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.
- 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.
- 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.
- 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.
Über den Autor
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.
Finde es schade, dass ihr es nicht mehr hinbekommt guten Content zu produzieren. Die einzig lesenswerten Artikel sind nicht von euch, sondern lediglich übersetzt.
Zum Thema: Solange Chrome und Firefox es nicht hinbekommen die Entwicklertools auf das Niveau von Safari zu hieven werde ich bei Safari bleiben.
> Zum Thema: Solange Chrome und Firefox es nicht hinbekommen die Entwicklertools auf das Niveau von Safari zu hieven werde ich bei Safari bleiben.
Jeder ist für sein eigenes Elend selbst verantwortlich, so sagt man. ;)
WTF? Solange es Firefox nicht hinbekommt, die Entwicklertools auf das Niveau von Safari zu hieven? Das kann nur jemand schreiben, der Firefox schon ziemlich lange nicht mehr benutzt hat. Da bietet Firefox aber wesentlich mehr für Entwickler als Safari.
Unsinn. Ich muss leider zwischendurch mit den Safari Devtools arbeiten. Viel Spaß weiterhin damit ;) Nicht ansatzweise mit den FF Devtools zu vergleichen.
Ich habe nie verstanden, warum man Safari nutzen sollte. Das war für mich schon immer (neben dem IE, aber nicht mal der IE verlangte da soviel ab) der Browser für den das optimieren von Webseiten am langwierigsten war. Safari war auch immer gefühlt langsamer und nicht so gut zu bedienen wie andere Browser. Und das bereits 2011-2012…
„Ich habe Panel-Talks und Breakout-Sessions gehalten mit einem Fokus auf Technologien…“
Zwei neue Begriffe für https://t3n.de/news/schlimmsten-buzzwords-buero-office-phrasen-619550/ ;)
wow t3n ihr übersetzt echt einfach englische blog artikel für euren content? Warum nicht einfach dann zu einer linkliste verkümmern und auf den original content verlinken, statt hier weiter verwerten zu wollen. Klar spricht ihr damit euch nicht englisch sprachige nutzer an, aber ein fader beigeschmack bleibt hängen, und eure Kundschaft sollte des englischen mächtig sein.
Ein enttäuschter Entwickler sagt seine Meinung. Scheinbar gibt es davon noch mehr, wie viele ist aber nicht bekannt – da nur vermutet. Andererseits weiß aber auch jeder Apple-User, dass Apple schon von Anfang an nicht seine Programme dermaßen mit Funktionen überfrachtet. Wenn also APIs fehlen dann heißt das noch lange nicht, dass Apple sie nicht implementieren könnte. Sie fragen immer nach der Sinnhaftigkeit – siehe flash. Letztlich muss auch gesehen werden, dass iOS-Safari und OSX-Safari ziemlich synchron laufen sollten – zumindest in den Features und im Handling.
Was die Kommentare hier um Chrome sollen kann ich als Alternative nicht nachvollziehen. Google als Datensammler freiwillig noch mehr Futter geben verbietet sich doch wohl von alleine. Aber für viele ist das ja normal: Google Docs, Google Mail, Facebook, Android – alles um Längen besser. Der Preis dafür wird wohlweislich schön geredet.
Installiere mal das Programm „Cookie“ und lass es bei normalem Gebrauch 5 Tage im Hintergrund laufen. Und dann lass dir mal alle Tracking Cookies, Datenbanken usw. zeigen, die sich bei dir auf dem Rechner tummeln. Egal welchen Browser du verwendest. Letztlich zeigt das dir aber, wie man hier im Hintergrund ausspioniert wird (auch wenn nicht alle Cookies negativ sind).
„Safari war auch immer gefühlt langsamer und nicht so gut zu bedienen wie andere Browser.“ OK, dann versuche mal nur ein Foto von einer Webseite in dein Schreibprogramm zu hieven. Bei Firefox klickst du dir einen Wolf – bei Safari ziehst du das Foto einfach von der Webseite in dein Schreibprogramm. Ansonsten fühlt man nur das was man fühlen will.
Und wieso sollte das bitte nur bei Safari so funktionieren? Das halte ich jetzt aber für ein Gerücht. Ich hab das nach dieser Aussage auch direkt mal mit einem Bild von dieser Webseite versucht – Firefox, Safari und Chrome verhalten sich absolut identisch.
Ach und andere Browser sammeln keine Daten oder was? Die bieten ihre Software kostenlos nur aus reiner nächsten Liebe an? Ist klar …
Achso, ja, aber der Größe „x“ eines Unternehmens, ist man angehalten, dieses komplett zu boykottieren, egal wie überlegen die Produkte sind. Unter diesem Gesichtspunkt hast du natürlich Recht.
Dir aber schon klar, dass nicht hinter jedem Browser ein profitorientiertes Unternehmen steht? Hinter Firefox beispielsweise steht eine Non-Profit-Stiftung. Insofern ja, sieh es meinetwegen als Nächstenliebe oder nenn es meinetwegen auch anders, aber es ist definitiv wichtig, dass man da unterscheidet. Nicht jeder Browserhersteller hat dieselben Gründe für das eigene Handeln.
Ein spontaner und individueller Grund warum ich auf MacOS den Safari Browser vor Google Chrome vorziehe: Das bessere Energie-Management ist mir unterwegs wichtiger, wenn ich gerade nicht an der Steckdose hänge.
Der einzige Grund, warum ich 2013 zurück zu Safari gewechselt bin: Chrome brachte mein neue Retina MBP in unregelmäßigen Abständen zum Einfrieren. Und der Apple Genius konnte mir als Lösungsvorschlag nur sagen, doch eben nicht mehr Chrome zu benutzen (»bekanntes Problem«).
Ich verstehe die Diskussion um den Content nicht. Lieber ein guter übersetzter Artikel (hier ein Danke an Anja Braun), als ein schlechter eigener Artikel von denen es inzwischen leider zu viele hier bei t3n gibt. Noch schöner wäre natürlich eine eigene Auseinandersetzung mit dem Artikel gewesen.
Auch mir macht es keinen Spass immer auf den Safari Rücksicht zu nehmen, aber im Zweifel gibt es Polyfills und wenn nicht sollte man einfach schauen das die Applicationen irgendwie laufen. Letztlich leben wir nicht mehr in Zeiten wo es den IE6 gibt und der „normale“ Internetnutzer keine anderen Browser kennt. Wenn eine Applikation nicht so gut läuft, schaut mensch halt erst einmal ob ein alternativer Browser oder ein Devicewechsel nicht den gewünschten Erfolg bringt. Safari wird schon irgendwann zu Vernunft kommen, zumal sie nicht unbedingt ganz oben mitspielen ( http://gs.statcounter.com/#browser-ww-monthly-201406-201506-bar ). Und so lange der Support nicht dem des Opera Mini gleicht, sehe ich noch Hoffnung :)
Der Artikel trifft es doch genau auf den Kopf. Gerade sind wir die Sorgen um die alten IE´s mehr oder weniger los, da geht die Pisse mit Apple weiter. Den Laden kann man doch komplett in der Pfeife rauchen. Es mangelt nicht am Geld, bewegt euren Arsch endlich.