- [00:00:14] Tools are [not] the Problem
- Schepp und Anselm debattieren zu zweit mit kleinen Abschweifungen über den Artikel von Peter Paul Koch, die Gegendarstellung von Sebastian Markbåge bezüglich der Facebook Instant Articles Ankündigung, zu der auch Tim Kadlec im Bezug auf Performance Stellung nimmt.
Wir fragen uns, was der richtige Weg ist, warum es so unterschiedliche Meinungen zu dem Thema gibt und wie der Missstand denn zu beheben wäre.
- [00:37:33] SVG Icon
Systeme Probleme
- Wir nehmen den Artikel Implementing an SVG Icons System von Damon Bauer zum Anlass und sprechen über SVG. Anselm erzählt von Iconfonts, dem Wechsel zu SVG und etlichen kleinen Problemchen, die er beim Einsatz gefunden hat. Schepp pflichtet bei, wir stellen aber auch fest, dass SVG einfach super coole Sachen wie Vererbungen kann, die wir super nützlich finden. Außerdem erwähnten wir die Grunt-Tasks grunt-svgmin und grunt-svg-sprite.
[00:59:44] Verlosung
- Ja, der Schepp hat eine Lizenz von Jetbrains zu viel und möchte sie unter unsere Hörer bringen.
Schreibt dazu einfach eure Erfahrungen, Tipps oder Probleme mit SVG Icons in die Kommentare und dazu, ob ihr PHPStorm oder WebStorm haben möchtet. Die Verlosung findet zur Revision 223 statt…
[01:01:15] Keine Schaunotizen
- Lovefield
- SQL-ähnliche Syntax schreiben schreiben und JavaScript IndexedDB Queries herausbekommen? Das macht Lovefield für euch. Leider nicht ganz schlank als Library.
- Windows 95
- Yeah, Windows 95 läuft nun im Browser!
Kommentare
Christoph Rumpel #
Geschrieben am 26.05.2015 um 08:36
Welche Probleme hattest du mit CSS Styles für SVGs in Chrome Christian?
Lg
Schepp #
Geschrieben am 26.05.2015 um 10:59
Ich hab jetzt nochmal versucht, es nachzustellen. Ergebnis: Ich weiß nicht mehr, was für ein Problem das war. Ob das vielleicht schon repariert wurde?
Christoph Rumpel #
Geschrieben am 26.05.2015 um 13:43
Hey,
ah ok. Es hat mich nur gewundert weil ich das Problem noch nicht hatte und wenn das wirklich Probleme macht wäre ja Sinn hinter SVGs zu hinterfragen.
Separate Bilder mit der richtige Farbe erstellen ist natürlich sehr mühsam.
Aber vielleicht wurde das wirklich schon gelöst. Danke auf jeden Fall fürs Testen.
lg
dpapad #
Geschrieben am 26.05.2015 um 23:21
Halo,
Ich bin einer der Softwareentwickler von Lovefield library. Ab version 2.0.54 Lovefield library Größe ist nur 115kb (es var 300kb bevor 2.0.54), https://github.com/google/lovefield/blob/master/dist/lovefield.min.js.
Danke schön
Sebastian B #
Geschrieben am 27.05.2015 um 09:32
Es mag ja sein das News Seiten manchmal etwas hakelig sind, aber meint ihr nicht ihr diskutiert da über einen Nebenkriegsschauplatz? Das klingt doch von FB Seite alles sehr vorgeschoben um die Nutzer noch mehr an das eigene Ökosystem zu binden (Alternative zu RSS und macht das gezielte anrufen externen Seiten überflüssig) und die Profiltiefe weiter zu schärfen. Zumal Facebook ja nun auch kein Performance-Monster ist.
Der Punkt mit kleineren lokalen Seiten dürfte sicher auch im Zuge der Netzneutralitätsdebatte nochmal interessanter werden.
Anselm Hannemann #
Geschrieben am 10.06.2015 um 16:20
Hm, so wirklich möchte ich es nicht als Nebenkriegsschauplatz abtun. Denn es sind nicht nur ein paar kleine Webeiten. Es sind extrem viele der Top1000 Alexa Seiten, die Probleme machen, was die Größe und Performance angeht. Das sind wiederum Seiten, die die Leute eben lesen wollen – schnell.
Ich will die Ökosystembindung gar nicht anzweifeln, aber das wollte ich zumindest aus der Debatte an dieser Stelle bewusst herauslassen, das das wichtige Thema für mich als Front-End Entwickler eben der andere Schauplatz, echte Performance, ist.
Sebastian B #
Geschrieben am 11.06.2015 um 10:03
Ich möchte das jetzt auch nicht als unwichtig abtun, aber ich kann mir nicht vorstellen dass das viel mehr als ein Nebeneffekt bzw. ein gutes Verkaufsargument war um eine politische Entscheidung zu treffen. Facebook hat einfach unendlich viel davon den User nicht auf externe Systeme auszuleiten, seine Werbung neben fremden Content anzuzeigen, die Inhaltsanbieter damit noch mehr von sich abhängig zu machen und eine noch tiefere Analyse der User zu haben. Auf der anderen Seite steht dann das Engineering-Argument das man mit der Performance von Newsseiten nicht zufrieden war und das lösen wollte, für mich klingt das einfach mehr nach einem Pseudoargument.
Ich verstehe das man sich im Kontext dieses Projektes natürlich lieber damit beschäftigt, aber auch hier glaube ich das der Blick zu sehr in die eigene „Filterblase“ geht. Ich bin mir mehr als unsicher ob es die Mehrzahl der Nutzer wirklich stört wie die heutige Performance der NY Times z.B. ist. Schneller ist sicher immer besser, aber dass das ein wirkliches Nutzerproblem darstellt sehe ich einfach nicht.
Anselm Hannemann #
Geschrieben am 11.06.2015 um 10:20
Wie gesagt, über die Intention seitens Facebook möchte ich ja gar nicht diskutieren. Da soll sich jeder seinen Teil denken und will auch nicht nicht immer der sein, der böses vermutet.
Aber ich weiß durchaus, dass ganz stinknormale Nutzer sehr viel Wert auf Website-Performance legen. Ich weiß aus User-Tests, dass viele Nutzer einfach keinen Bock mehr haben, einen Artikel zu lesen, wenn die Seite zu lange zum laden braucht. Ich weiß, dass meine Mutter z.B. solche Seiten, die zu lange brauchen, einfach schließt und andere Seiten sucht stattdessen. Und ich schließe daraus auch (=ich weiß es natürlich nicht sicher), dass es einen riesen Unterschied macht für den Nutzer eines Smartphones, ob ein Artikel aus Facebook oder Twitter 1 Sekunde braucht zum lesen oder 20 Sekunden.
Dirk Döring #
Geschrieben am 17.06.2015 um 21:37
Der Artikel von Damon Bauer und sein Fazit treffen den Kern der Sache schon ganz gut. SVG sind eine tolle Sache, garkeine Frage. Hat man volle Kontrolle über den Quellcode und kann das SVG unterbringen oder per einsetzen ist der Nutzung wenig entgegen zu setzen. Ob das nun wirklich viel mehr Markup ist, wenn ich statt
<i></i>schreibe halte ich für vernachlässigbar. Zur Performanceeinbuße in diesem Fall kann ich nichts sagen, das hängt sicher von der Anzahl der Icons ab. Im Bedarfsfall hab ich jetzt nicht unbedingt 50 Icons pro Seite, sondern eher 5-10. Da halte ich die Probleme die IconFonts mit sich bringen für gravierender.Was mich an SVG „stört“ ist die Komplexität es ins Markup zu bekommen, wenn ich die gesamte Bandbreite nutzen möchte, es auch stylen zu können. Das sehe ich besonders aus Sicht des Frontend-Entwicklers. Icon-fonts lade ich rein, setze ein Klasse und kann losstylen und habe alle Möglichkeiten, die mir Text auch gibt. Diese Flexibilität der Integration bietet SVG nur als background-image. Und da gehts dann los, Farben muss ich vorher im Sprite separat anlegen. Transform? keine Chance. Es sieht aber madig aus, wenn sich die Farbe des Text bei hover in 0.2s von schwarz zu rot ändern, das Icon aber direkt wechselt. Das Sprite muss dann auch noch erstellt werden (gut dafür gibt es taskrunner) und ein Icon Font erstellt sich auch nicht von alleine…
Das positivste bei SVG ist die Flexibilität, wenn ich es inline einsetzen kann. Dann ist es in jeder Hinsicht einem Icon Font überlegen. Allein schon die Tatsache dass man es animieren kann, es nach mediaqueries in seiner Komplexität wachsen/schrumpfen lassen kann bringt tolle Möglichkeiten mit sich. In meinen Projekten ist es daher bisher so gewesen, dass wir von Fall zu Fall entschieden haben. Wie halt so oft :D
Was mich kürzlich wirklich geängert hat, war die Möglichkeit nicht in den Shadow DOM eingreifen zu können. (also im FF ging es, aber das war dann ja leider der Bug). Ich hätte in den Fall nämlich nur ein SVG gehabt und dieses dann mit per display:none nach Klassen immer schön abändern können. Schade :D
Soweit meine noch wenigen Erfahrungen mit SVG, danke für euren Talk, ist immer wieder toll reinzuhören.
Faulancr (Dirk)
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.