Blink statt WebKit: Google wechselt Browser-Engine

Chrome-Anbieter Google hat in der Nacht auf heute angekündigt, dass man demnächst aufhören wird, die Rendering-Engine WebKit bei seinem Browser einzusetzen. Stattdessen will man auf eine abgespaltete Technologie namens Blink setzen. mehr... Google, Browser, Chrome, Chromium Bildquelle: Google Google, Browser, Chrome, Chromium Google, Browser, Chrome, Chromium Google

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Mich würde interessieren, was sich für Webdesigner ändert bzw. was diese an Webseiten ändern müssten (Thema CSS und webkit Definitionen).
 
@Rebirth: Ich denke am Anfang nicht, später muss man es vielleicht umbenennen.
 
@Rebirth: Vorerst noch nicht viel. Die meisten Webkit hacks waren nur kleinigkeiten bei Listen. Ich habe Zwei mal einen Webkithack betätigen müssen, beim ersten mal wurden Inputfields in eine Liste gepackt und das letzte war versetzt. In Zukunft werden aber wohl viele Leute mit Blink herumfahren und man wird Trident, Gecko und 2 verschiedene Blink Implementationen auf Windows haben. Auf Mac gibt es dann Webkit, 2x Blink und Gecko und auf Linux kommen wieder eigenheiten dazu.
 
@Rebirth: mittlerweile deutlich weniger als zu Zeiten des IE8. Für uns Webentwickler hat sich in den letzten 3-4 Jahren viel vereinfacht.
 
@TurboV6: Aber auch etwas komplizierter gemacht was den Browsersupport für die älteren Browser betrifft solange man da mit drauf optimieren muss.
 
@Stoik: meine Auftraggeber sehens ein, dass ich nur noch die neueste Generation unterstütze + eine Version älter. Der Trick: exorbitanter Aufschlag / Stunde, wenn ich einen Steinzeitbrowser unterstützen soll. Liegt aber auch daran, dass ich mich auf modernere Seiten / RIAs spezialisiert hab. Viele können sich das nich erlauben.
 
@TurboV6: Jap, mit Aufschlag ist mit die beste Möglichkeit auch wenn da manche Kunden die Augen verdrehen..
 
@Rebirth: Bei Blink soll es keine neuen Herstellerpräfix "-chrome" geben und neue Funktionen sollen von Anfang an ohne Vendor Prefixes auskommen.
 
@klink: Juhu, lasst uns Verwirrung stiften...
 
@Knerd: Du redest von genau was? Prefixe sind eigentlich nur während Umstellungen vorhanden. Es ist der Sinn ohne Prefixe zu arbeiten.
 
@TurboV6: Es ist aber nicht der Sinn, nicht standadisierte Funktionenn ohne Prefix zu verwenden.
 
@Knerd: Es ist viel eher nicht der Sinn den Standard nicht einzuhalten.
 
Don't blink! Blink and you will die...
 
@Slurp: Doktor wer? ;-)
 
@OPKosh: The first question, the oldest question in the universe, that must never be answered..... :D
 
@Slurp: "Silence will fall when the question is asked!" AND! "Demons run when a good man goes to war!" ;-)
 
@Slurp: Do not click it!
 
Hm, verstehe ich ehrlich gesagt nicht so ganz. Das bedeutet doch im Grunde nur, daß die Engines zwar jetzt noch relativ gleich sind aber ab jetzt wieder auseinanderlaufen. Man hat wieder mehr unterschiedliche Implementierungen und damit fast zwangsläufig unterschiedliche Verhaltensweisen. Klar Google muss sich nicht mehr so viel abstimmen und kann wahrscheinlich schneller und mehr auf eigene Faust entwickeln, aber für die Webdesigner wird dafür wieder komplizierter. Vor allem im Business-Umfeld hat man es bis heute noch nicht mal richtig geschafft sich vom "Alles muss IE kompatibel sein" Vorgehen zu lösen.
 
@Givarus: Da stimme ich dir zu. Ich finde die Browserhersteller sollten sich mit einem starken ICE auf einem Gleis fortbewegen statt mit eigenen Zügen auf mehreren Gleisen zu fahren. Damit hätten Webdesigner weniger Fehler bzw. Anpassungen und somit würden auch die "normalen" Surfer keine unterschiedlichen Optiken haben.
 
@Rebirth: Im Optimal Fall könnt es 2000 verschiedene Engines geben und der Webentwickler sollten sich nicht weiter dadrüber gedanken machen müssen welche Engine grade benutzt wird. Solange sich alle an die Vorgaben halten würde wäre das auch so. Ob die eine Engine jetzt intern 1+1 anders berechnet als die andere wäre dabei total egal solang am ende immer 2 raus kommt.
 
@MysticEmpires: Das Stimmt im Prinzip schon. Wenn es nicht bestimmte komplexe Anforderungen gäbe die anders sind, müsste man auch keine eigene Engine haben. Daher kann man das leider nicht auf 1+1=2 runterbrechen, denn die "Wahrheit" bei HTML-Interpretation ist wie der Name schon andeutet "Interpretation"! Um bei Deinem Beispiel zu bleiben - mit 100 Engines ist die Wahrscheinlichkeit extrem groß, daß die eine 1+1= 2,00012 ausgibt und die nächste 1+1 = 2,00032.
 
@Givarus: Du hast "Interpreter" falsch verstanden. Das ist keinen "Interpretation" wie der Name evtl. vermuten läßt sondern beschreibt einfach nur das der Code zur Laufzeit erst übersetzt wird. Und für diese Übersetzung gibt es Regel und da hat auch bei 2000 Engines bei 1+1 ne 2 rauzukommen und nichts anders. Was da intern angeht hat nicht zu interessieren.
 
@MysticEmpires: Mir ist schon klar, daß das so zu funktionieren hat in der Theorie! In der Praxis sieht es anders aus. Gib 2000 Programmieren ein Klassen-Interface das sie zu implementieren haben. Du wirst immer in Details unterschiedliche Ergebnisse bekommen und sei es nur weil einige Implementiereungen nicht ausreichend getestet wurden oder die Methoden des Interfaces anders gedeutet werden. Beim Interface für eine Klasse klappt das Ganze vielleicht noch, bei einer Browser-Engine die aus abermillionen Zeilen Code besteht bezweifel ich das ehrlichgesagt!
 
@Givarus: Daher habe ich oben ja auch geschrieben " Im Optimal Fall" :)
 
@Rebirth: Wenn alle Engines die Standards einheitlich umsetzen würden, wäre es egal welche Engine eingesetzt wird. Autos fahren auch alle mit eigenen Motoren und trotzdem laufen alle mit demselben Benzin.
 
@Givarus: Ich denke da eher an deinen letzten Satz. Allen Minusklickern zum Trotz, aber es gab durchaus ein paar Gründe dafür warum Trident lange Zeit ein "Eigenleben" hatte und gewisse Sachen konnte, die in der Form noch keine andere Engine konnte. (z.B. VML, XMLHttpRequest u.ä.) Sicher, die Zeiten haben sich geändert am, recht langsamen, W3C u.ä. kommt man heute wohl nicht mehr vorbei, aber welche "Web Anwendungen" haben die Webkit Nutzer Apple, Opera und auch z.B. Nokia denn so? Ich könnte mir durchaus das ähnliche Überlegungen bei Google vielleicht auch eine Rolle gespielt haben.
 
Vorausgesetzt, die Webentwickler würden für Standards anstatt für WebKit entwickeln (z.B. die Jungs und Mädels bei Google), wäre die Entscheidung für das Web egal.
 
@Kirill: Naja, ist leider utopisch... Ich finde es ehrlich gesagt eine Sauerei, dass das W3C browserspezifische Tags erlaubt...
 
@Knerd: damit vermeiden sie halt druck....das w3c ist halt einfach zu langsam
 
@0711: Ist ja richtig, nur sollten sich die Entwickler nicht immer an den spezifischen Tags orientieren. Es gab auch schon vor Jahren Möglichkeiten Ecken rund zu machen.
 
Ach so, wer wissen will was das konkret bedeutet: dieses Team http://trac.webkit.org/wiki/WebKit%20Team wird sich wohl spalten und getrennte Wege gehen. Hier kann jeder sehen, welche Firma wie viel zu Webkit beiträgt. Schon interessant.
 
@Givarus: Also gibts dann eine Apple- und eine Google-Engine, wenn ich die Liste so überfliege...
 
@dodnet: Primär ja, es scheinen aber auch einige Samsung und Intel Mitarbeiter daran beteiligt zu sein. Würde mich interessieren, auf welche Seite die sich stellen :D
 
@Rebirth: Nokia hat auch ein paar dabei. Die Frage ist wohl die interessanteste.
 
@Givarus: Bei den Committern, also bei denen, die den Code liefern, ist vor allem Google vertreten. Da fragt man sich, warum Apple als Webkit-Entwickler gilt.
 
@TiKu: Weil Google quasi erst mit Beginn der Chrome-Entwicklung 2008 dazugestoßen ist und Webkit an sich zuerst zum Großteil von Apple getrieben wurde?
 
@TiKu: Liegt wohl daran dass Apple damals KHTML geforkt hat und daraus dann WEbkit wurde
 
Hm. Als Web-Entwickler sehe ich wieder nur Probleme auf mich zukommen. Das gute an WebKit war meiner Meinung nach, dass der Test-Aufwand gesunken ist, da man nur noch den IE und einen WebKit Browser nutzen musste. Das wird sich dann jetzt wohl wieder ändern :|
 
@PranKe01: Und Gecko ;) Wobei sich Chrome und Safari auch unterscheiden ;)
 
@Knerd: Zum Gecko kommt bald noch Servo wenn Mozilla die Engine wechselt...
 
@PranKe01: Genau, Firefox nutzt ja keiner (?) :P
 
@lutschboy: Ach, dann bin ich doch der letzte Nutzer *hmpf*
 
@PranKe01: "da man nur noch den IE und einen WebKit Browser nutzen musste" Was für ein Quark. Auch die Webkit-Browser haben sich unterschieden.
 
@PranKe01: Auch Web Entwickler können sich vernünftige Testumgebungen aufbauen die zum Teil automatisierbar sind. Und durch den IE10 sind die Unterschiede auch nicht mehr so extrem krass zwischen den Browsern. So dramatisch finde ich das gar nicht mal wenn Google jetzt an einem eigenen WebKit Fork rumschraubt.
 
An den Verfasser. Da fehlt ein "hat" in Absatz 4.... Deshalb hat man sich entschieden, sollte das heißen oder?
Will nicht klugscheißen, sondern lediglich drauf hinweisen :-)
 
@DarK-LighT: Danke für den Hinweis. Schneller geht die Berichtigung allerdings, wenn Du den "Hinweis einsenden" Link unter der jeweiligen News nutzen würdest. :)
 
Ach und Mozilla baut mit Samsung zusammen auch ne neue experimentelle Web-Engine: http://tinyurl.com/bwcm58t Also vor Monokultur im Web brauchen wir uns derzeit also nicht wirklich zu fürchten ;-)
 
@Givarus: In gewisser weise sind die ganzen Browser-Engines vielleicht ganz gut, da geht vielleicht das Preis-Dumping in der Branche etwas zurück.
 
Dass Opera jetzt gleich mitgeht ist vermutlich mehr als konsequent. In Sachen Web macht vermutlich einfach mehr Sinn sich an Google anzuheften als an Apple.
 
@kubatsch007: Das stimmt schon. Aber wichtiger ist, dass die alle sich an das W3C hängen und wir nicht wieder in Zeiten zurückfallen wo jeder Browser-Hersteller sein eigenes HTLM definierte! Google ist zwar ein mächtiger Webplayer - aber Google ist nicht das ganze Web! Doch ich glaube aus dem Netscape/IE Zeitalter haben alle gelernt und selbst MS ist ja heute W3C konform. Deswegen bin ich guter Hoffnung!
 
@kubatsch007: für iOS müssen die dann aber wieder auf Webkit gehen, da dort ja keine andere Engine erlaubt ist. vermutlich wird es aber wenig Unterschiede geben - da beide Engines ja Open Source sind können und werden die Devs ja auch Quelltexte vom anderen aufgreifen. Webkit wird schlanker werden und blink bekommt Features dazu - wenn man auf diese Features verzichtet bei der iOS-Version müsste die Engine ja einfach austauschbar sein - die erfinden das Rad ja nicht neu, es ist und bleibt ja wohl khtml und kjs.
 
@otzepo: Unter IOS ist es sogar noch schlimmer... andere apps haben zwar webkit aber nur ne lite version die langsamer ist als vom safari (leider)
 
@kubatsch007: warum ist das konsequent und ergibt mehr sinn, wenn sie sich an google statt apple hängen??
 
Also ganz ehrlich, der erste Satz des Artikels ist vom Ausdruck her "ganz weit unten" und dämlich geschrieben. Niveau und hoher redaktioneller Anspruch sehen anders aus. Und der Satz scheint nichtmal abgeschrieben zu sein, denn so schreibt keiner! ;)
 
Was würde eigentlich passieren wenn Apple morgen ankündigt sie setzten nun auch auf Blink?
 
@Givarus: wieso sollte apple das tun und das was sollte dann passieren?
 
@Mezo: Dann hat Webkit Probleme ;)
 
@Mezo: keine Ahnung, aber dann könnten sie auch einfach Webkit in Blink umbenennen - nur so ein blöder Gedanke ;-)
 
Sehr gut, so kommt es doch nicht zur Webkit-Monokultur.
 
Fragt sich auf was QtWebKit in der Zukunft basieren wird.
 
Der letzte Satz ist toll - Opera läuft hinterher *g
 
Viel lustiger ist das man jetzt alternative JS Engines killen will und V8 ganz aus dem Quellbaum löschen will.
Kommentar abgeben Netiquette beachten!

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles