Jeena Paradies: Blink - neue Rendering Engine von Google

Hallo,

Google geht den umgekehrten Weg von Opera und weg von WebKit und hin zu ihrer eigenen Rendering Engine Blink: http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html

Dies ist ein guter Tag für das offene Web :-)

/Jeena

  1. Hi there,

    Google geht den umgekehrten Weg von Opera und weg von WebKit und hin zu ihrer eigenen Rendering Engine Blink: http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html

    Naja, aber hier liest man auch: [...] based on WebKit...;)

  2. Hi,

    Blink ist wie gesagt "nur" ein Fork von WebKit. Opera will in Zukunft auch auf Blink setzen.
    Mein letzter Versuch Chromium zu kompilieren endete damit, dass sich der Linker nach Verschlingen von RAM und Swap verabschiedet hat. Vielleicht versuch ich's in Kürze nochmal!
    Brandan Eich hat zeitnah zu Google bekannt gegeben, dass Mozilla in Zusammenarbeit mit Samsung an einer neuen Browser-Engine namens Servo arbeitet. Die verwenden dafür auch gleich mal ihre eigene neue Programmiersprache.

    Ich bin gespannt, was da auf uns zukommt.

    Martin

  3. Hallo,

    Google geht den umgekehrten Weg von Opera und weg von WebKit...

    Dies ist ein guter Tag für das offene Web :-)

    Wie kann es ein guter Tag fürs (offene) Web sein, wenn Google irgendetwas macht? In Google we trust?

    Viele Grüße
    Siri

    1. Hi,

      Google geht den umgekehrten Weg von Opera und weg von WebKit...

      im Gegenteil, hin zu Webkit, wie zwei der Vorredner schon betont haben.

      Dies ist ein guter Tag für das offene Web :-)
      Wie kann es ein guter Tag fürs (offene) Web sein, wenn Google irgendetwas macht? In Google we trust?

      Und vor allem: Warum stürzen sich jetzt "alle" (erst Opera, jetzt Google) ausgerechnet auf die Engine, die am meisten Ärger macht?
      What's wrong with Gecko? What's wrong with Presto? - Okay, Presto ist nicht Open-Source, streichen wir das.

      Ciao,
       Martin

      --
      Heutzutage gilt ein Mann schon dann als Gentleman, wenn er wenigstens die Zigarette aus dem Mund nimmt, bevor er eine Frau küsst.
        (Barbra Streisand, US-Schauspielerin)
      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      1. What's wrong with Gecko?

        Also auf eine Engine zu setzen, die dadurch ein fast Monopol erhält, halte ich für falsch.

        Es würde dann ja Firefox, Chrome, Chromium und Opera die gleiche Engine nutzen

        Auch wenn IE und Safari grosse Marktanteile haben, halte ich das eher für kontraproduktiv. Konkurrenz belebt das Geschäft und da ich den FF seit Version 7 nicht mehr mag (zu langsam für mich), bin ich eh gegen Gecko ;)

        PS: Nächste Woche bekommst du deine Obst-Lieferung, genaueres gleich per Mail ;)

        1. Hallo,

          What's wrong with Gecko?
          Also auf eine Engine zu setzen, die dadurch ein fast Monopol erhält, halte ich für falsch.

          ja, sehe ich auch so.

          Es würde dann ja Firefox, Chrome, Chromium und Opera die gleiche Engine nutzen

          So hatte ich es nicht gemeint; ich würde mir schon wünschen, dass Opera an Presto festhält. Und ich bin nicht begeistert von der Idee, dass jetzt ausgerechnet um Webkit so ein Hype gemacht wird - es sei denn, die Engine wird relativ zügig so weit in Ordnung gebracht, dass man als Webautor nicht mehr so viele Verrenkungen machen muss.

          Auch wenn IE und Safari grosse Marktanteile haben, halte ich das eher für kontraproduktiv. Konkurrenz belebt das Geschäft

          Stimmt. Gut, wenn Chrome zukünftig Blink anstatt Webkit nutzen will, was aber im Endeffekt nur eine Variante von Webkit wird, ändert das nicht viel. Wenn Opera seine eigene inzwischen sehr ausgereifte Engine zugunsten von Webkit aufgibt, ist das erstens ein evolutionärer Rückschritt, und zweitens am Ende eher weniger Konkurrenz.

          und da ich den FF seit Version 7 nicht mehr mag (zu langsam für mich), bin ich eh gegen Gecko ;)

          Ich mag ihn schon seit Version 2 nicht mehr. Am besten gefiel er mir, als er noch eine 0 als Major Version führte. Da war er wirklich noch schlank, universell und relativ flott. Und man *wusste*. dass es sich um ein noch nicht ausgereiftes Produkt handelt. Heute weiß man das auch, aber Mozilla versucht uns immer darüber hinwegzutäuschen. Gecko als Browser-Engine ist IMO inzwischen wirklich gut geworden - aber der Browser, den man drumherum gebaut hat, geht an Krücken.

          PS: Nächste Woche bekommst du deine Obst-Lieferung, genaueres gleich per Mail ;)

          Danke, ist gut. Ich hatte mich schon a bisserl g'wundert. Lag vielleicht am kalten Frühjahr, da braucht's halt etwas länger, bis die reif sind. ;-)

          Ciao,
           Martin

          --
          Die junge Ehefrau weint sich bei ihrer Mutter aus:
          Er hat gesagt, ich soll mich zum Teufel scheren! - Und da kommst du ausgerechnet zu mir?!
          Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
  4. Moin,

    "Auf Herstellerpräfixe wird Blink verzichten, denn es habe sich gezeigt, dass dieses Vorgehen dem Web schadet" (Quelle)

    *freu*

    Grüße Marco

    --
    Ich spreche Spaghetticode - fließend.
    1. @@misterunknown:

      nuqneH

      "Auf Herstellerpräfixe wird Blink verzichten, denn es habe sich gezeigt, dass dieses Vorgehen dem Web schadet" (Quelle)

      Ich sehe keinen Grund zur Freude.

      „Stattdessen will Google neue Funktionen von Anfang an ohne Präfix unterstützen, ohne diese aber in der Standardeinstellung zu aktivieren. Wer sie nutzen will, kann sie mit dem Schalter "enable experimental web platform features", der unter about:flags in Chrome zu finden ist, aktivieren.“

      WTF?? Das heißt, als Webentwickler baut man „Best viewed with“-Hinweise für Nutzer ein und fordert sie auf, ihre Browsereinstellungen zu ändern, um die Webseiten optimal zu sehen zu bekommen?

      Was dem Web wirklich schadet, sind vorschnelle präfixfreie Implementationen von Features, bevor die Spec dazu stabil ist. Bei Gradienten oder Flexbox ist deutlich zu sehen, dass sich die Spec durchaus nach dem ersten Ansatz noch ändern kann. Was, wenn Browser diese Features von vornherein präfixfrei implementiert hätten?

      Qapla'

      --
      „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
      1. Moin,

        „Stattdessen will Google neue Funktionen von Anfang an ohne Präfix unterstützen, ohne diese aber in der Standardeinstellung zu aktivieren. Wer sie nutzen will, kann sie mit dem Schalter "enable experimental web platform features", der unter about:flags in Chrome zu finden ist, aktivieren.“

        Ich finde den Link grade nicht wieder. Dort wurde zitiert, dass Blink das flag für Funktionen die von mind. 2 weiteren Browsern unterstützt werden und/oder vom W3C als "fertig" (der genau Terminus ist mir grade entfallen) deklariert werden aktiviert.

        Gruß
        Ole

        1. @@Ole:

          nuqneH

          Ich finde den Link grade nicht wieder. Dort wurde zitiert, dass Blink das flag für Funktionen die von mind. 2 weiteren Browsern unterstützt werden

          Nicht zielführend.

          Mehrere Browser unterstützten -<prefix>-linear-gradient(left, black, white) und -<prefix>-linear-gradient(30deg, black, white). Dennoch hat sich die Spec geändert, die präfixfreie Syntax ist linear-gradient(to right, black, white) und linear-gradient(60deg, black, white). Jawohl, 60, nicht 30; Startpunkt und Richtung der Winkel wurden geändert.

          Hätten die Browser linear-gradient(left, black, white) ohne Präfix implementiert, käme man jetzt in Teufels Küche.

          und/oder vom W3C als "fertig" (der genau Terminus ist mir grade entfallen) deklariert werden aktiviert.

          Recommendation.

          Und die lassen auf sich warten. Das hieße, man kann Features auf Ewigkeit nicht nutzen, obwohl sie implementiert sind.

          Qapla'

          --
          „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
          1. Moin,

            Und die lassen auf sich warten. Das hieße, man kann Features auf Ewigkeit nicht nutzen, obwohl sie implementiert sind.

            Prefixe halten aber auch davon ab Sachen zu nutzen, die zwar implementiert sind, aber überall anders. Mich jedenfalls.
            Ich verstehe nicht, warum man in Zeiten des Internets trotzdem eine gefühlte Ewigkeit braucht um sich auf einen Standard zu einigen, der dann implementiert werden kann - völlig ohne Prefixe. Seit ich mich mit HTML5 und CSS 3 beschäftige, stört mich, dass ich viele Sachen nur in bestimmten Browsern nutzen kann. Klar, eine Website muss nicht in jedem Browser gleich aussehen; gewaltige Unterschiede nerven trotzdem.

            Grüße Marco

            --
            Ich spreche Spaghetticode - fließend.
            1. [latex]Mae  govannen![/latex]

              Und die lassen auf sich warten. Das hieße, man kann Features auf Ewigkeit nicht nutzen, obwohl sie implementiert sind.

              Prefixe halten aber auch davon ab Sachen zu nutzen, die zwar implementiert sind, aber überall anders.

              Genau das ist aber doch den Sinn von Prefixen. Man kann dann die für den jeweils entsprechenden Browser passende, gegebenenfalls unterschiedliche Syntax notieren, für den Nutzer sieht es trotzdem (mehr oder weniger) gleich aus. Insofern verstehe ich

              Mich jedenfalls.

              nicht.

              ♫ FIIIIISCH!! ♪
              Kai

              --
              var jQuery = $(hit);
              Wir sind die Schlumpf. Widerschlumpf ist schlumpflos. Wir werden Sie einschlumpfen.
              SelfHTML-Forum-Stylesheet
            2. Hallo!

              Ich verstehe nicht, warum man in Zeiten des Internets trotzdem eine gefühlte Ewigkeit braucht um sich auf einen Standard zu einigen, der dann implementiert werden kann

              Ich verstehe das durchaus. Nicht umsonst ist das Hixies Motto »Things that are impossible just take longer«. HTML5 ist so eine Sache, die eigentlich unmöglich ist, aber bereits fast 9 Jahre andauert.

              Technische Spezifikationen zu entwickeln und sie in Software zu implementieren ist eine verdammt schwierige, aufwändige und zeitraubende Sache. Bis man eine Sprache gefunden hat, die die Probleme sinnvoll ausdrücken kann, vergehen mehrere Spezifikations- und Prototyping-Zyklen. Was HTML und CSS angeht, ist die Verfahrensweise: »Try again. Fail again. Fail better.« Das Problem hat man erst am Ende halbwegs erfasst.

              So gesehen finde ich, dass die Entwicklung der Webstandards eigentlich recht schnell vorangeht. Schaut man sich einmal die Aktivität in der HTML- und der CSS-Arbeitsgruppe an oder verfolgt man die Änderungen an den jeweiligen Dokumenten, so sieht man, dass es ziemlich schnell vorangeht und es wöchentlich wichtige Entscheidungen getroffen werden.

              Beim lange währenden CSS-Flexbox-Standard z.B. ist die gegenwärtige Lösung den vorherigen Entwürfen (die allesamt mit Präfixen in Stable-Versionen implementiert sind) merklich überlegen. Das ganze fing vor langer Zeit in XUL an und wurde seitdem signifikant weiterentwickelt.

              Grüße,
              Mathias

  5. Google und Opera wollen damit wohl in erster Linie den Webkit-Bremsblock Apple los werden ohne dessen Einverständnis bei Webkit wohl nicht viel läuft (so habe ich das zumindest verstanden).

    Außerdem wird es wohl dringend Zeit bei Webkit gewaltig aufzuräumen. So hatte sich ein jQuery-Entwickler mal so geäußert, dass eine nicht unbeachtlicher Teil von jQuery nur dazu da ist diesen Webkit-Müll zu umschiffen.

    Da Google für Chrome eh nur Teile von Webkit nutzt und Opera einen "Neustart" hinlegt ist es eigentlich nur konsequent die Kompetenzen zu bündeln, immerhin ist/war Presto eine wirklich gute Engine die sich in Sachen Performance und Können nicht hinter Webkit verstecken muss(te).

    Ich bin gespannt.

    Gruß
    Ole

    1. Hallo,

      Google und Opera wollen damit wohl in erster Linie den Webkit-Bremsblock Apple los werden ohne dessen Einverständnis bei Webkit wohl nicht viel läuft (so habe ich das zumindest verstanden).

      Außerdem wird es wohl dringend Zeit bei Webkit gewaltig aufzuräumen. So hatte sich ein jQuery-Entwickler mal so geäußert, dass eine nicht unbeachtlicher Teil von jQuery nur dazu da ist diesen Webkit-Müll zu umschiffen.

      Das kann man so nicht sagen. Das was Google zu schaffen macht, ist die Architektur von WebKit. Apple und Google sind mit WebKit2 und Chrome’s Multiprozess-Architektur, JavaScriptCore und V8 schon unterschiedliche Wege gegangen. Das alles zu warten und abzustimmen ist Google ein Dorn im Auge.

      Was jQuery zu schaffen macht ist, sind alles Bugs, die Apple und Google auch problemlos im aktuellen Code der HTML-/CSS-/JavaScript-Implementierung hätten beheben können. Daran haben sie keine Architekturfragen gehindert.

      Im Übrigen beziehen sich die jQuery-Workarounds nicht alle auf den aktuellsten WebKit, WebKit hat nur eine Breite Installationsbasis, wie auch IE.

      Grüße,
      Mathias