Zusammenfassung
SVGOMG: Ein ansprechendes, responsives Frontend für Material Design für SVGO
Was uns gefällt?
SVGOMG wurde von unserem eigenen Jake Archibald entwickelt und ist ein fast perfektes Beispiel für ein vollständig responsives und leistungsfähiges Tool, das mit Webtechnologien geschrieben wurde. Die Anwendung verfügt über ein ansprechendes Material Design-Erscheinungsbild, sorgt dafür, dass die Anwendung schnell geladen wird, offline verfügbar ist und die Umstellung auf Mobilgeräten reibungslos verläuft.
Mögliche Verbesserungen
Die einzige Kleinigkeit, die wir zu bieten haben, ist, dass die anfängliche UX verwirrend ist, weil die Haupt-UI fehlt. Abgesehen davon, gut gemacht!
Fragen und Antworten mit Jake Archibald
Warum das Web?
Faulheit. Totale Faulheit. Ich kenne mich weder mit der Entwicklung nativer Windows-Apps noch mit der Entwicklung nativer Anwendungen für iOS, Android, Windows Phone oder Linux aus. Ich kenne mich auch nicht mit systemeigenen OSX-Apps aus. Das Web kann ich jedoch auch tun. Mit diesen Fähigkeiten konnte ich einmal etwas entwickeln, das auf all diesen Plattformen funktionierte.
Was hat in der Entwicklungsphase wirklich gut funktioniert?
Ich bin sehr zufrieden mit der Leistung. Ich stelle sicher, dass die Seite gerendert wird, bevor JavaScript verfügbar ist. Tatsächlich wird zuerst mit nur 5.000 HTML und einigen Inline-CSS- und SVG-Dateien gerendert. Die Hauptskripts und der CSS-Code werden alle im Hintergrund geladen. Das bedeutet, dass die Website in 1,5 Sekunden geladen wird, selbst bei einer 3G-Verbindung mit leerem Cache.Der Großteil davon ist DNS und SSL.
Der Startbildschirm ist wirklich simpel, sodass das in 5K keine Herausforderung war. Es stört mich wirklich, dass so viele Websites beim ersten Rendering auf JS warten, manche verlangen sogar, dass JS vor dem Rendern weitere Anfragen stellt. Dadurch erhöht sich die 3G-Renderingzeit auf 10 Sekunden. Als mobiler Nutzer weiß ich, dass ich das nicht zulassen würde.
Die Haupt-JS-Datei ist 15 KB groß, enthält aber nicht die Teile, die das SVG parsen und reduzieren, das als zusätzliche Phase im Hintergrund geladen wird. Der Grund dafür ist, dass die Interaktivität sehr schnell reagiert und die Nutzer die zusätzliche Ladezeit nicht bemerken. Wenn es dem Nutzer gelingt, ein SVG auszuwählen, bevor dieses Skript verfügbar ist, scheint das Laden dieses Skripts Teil der Verarbeitungszeit zu sein.
Ich habe auch ServiceWorker verwendet, damit alles offline funktioniert. Offline arbeiten ist eine ziemlich coole Funktion, aber ich nutze es hauptsächlich, um eine bessere Leistung zu erzielen. Die nachfolgenden Besuche von SVGOMG werden nahezu sofort gerendert, unabhängig davon, welche Verbindung der Nutzer hat. Angesichts der Unterschiede bei der mobilen Konnektivität ist das wirklich wertvoll!
Wenn Sie eine API zur Verbesserung Ihrer App haben könnten, welche wäre das?
Ich habe Babel verwendet, um zukünftige JavaScript-Daten zu nutzen. Es wäre toll, wenn ein Teil davon nativ in der Plattform funktionieren würde. Insbesondere sind dies die Funktionen „async/await“, „Pfeilfunktionen“, „Standardargumente“ und „Destrukturierung“.
Ich musste eine Bibliothek verwenden, um die Ausgabe mit gzip zu komprimieren, um die mit gzip komprimierte Größe zu ermitteln. Die Verwendung einer Bibliothek dafür ist etwas ärgerlich, da sich dieser Code bereits im Browser für HTTP-Inhalte befindet. Es gibt einfach keine API dafür. Idealerweise sollte es ein Transformationsstream sein, damit ich die Größe der Ausgabe zählen kann, ohne dass alles im Arbeitsspeicher ist.