SVGOMG

Zrzut ekranu ze Svgomg

Podsumowanie

SVGOMG: atrakcyjny, materiałowy, elastyczny frontend SVGO.

Co nam się podoba?

Stworzona przez naszego Jake'a Archibalda SVGOMG jest niemal doskonałym przykładem w pełni elastycznego i wydajnego narzędzia napisanego przy pomocy technologii internetowych. Ma atrakcyjny wygląd w stylu Material Design, dzięki czemu aplikacja ServiceWorker szybko się wczytuje i jest dostępna offline, a przejścia na urządzeniach mobilnych są płynne.

Możliwe ulepszenia

Jedyną różnicą jest to, że początkowy interfejs użytkownika jest niezrozumiały ze względu na brak głównego interfejsu. Poza tym brawo!

Pytania i odpowiedzi – Jake Archibald

Dlaczego internet?

Lenistwo. Całkowite lenistwo. Nie jestem ekspertem w tworzeniu aplikacji natywnych dla Windows, nie jestem ekspertem od aplikacji natywnych w OSX ani nie jestem ekspertem w tworzeniu aplikacji natywnych na iOS, Androida, Windows Phone czy Linuxa. Mogę natomiast korzystać z internetu, a ten jeden zestaw umiejętności pozwolił mi stworzyć coś raz, które zadziała na wszystkich tych platformach.

Co sprawdziło się szczególnie dobrze w trakcie tworzenia aplikacji?

Jestem bardzo zadowolony z jej wydajności. Zapewniam, że strona renderuje się przed udostępnieniem JavaScriptu. Najpierw renderuje się za pomocą 5 KB kodu HTML z wbudowanymi elementami CSS i SVG. Główne skrypty i kod CSS są wczytywane w tle. Oznacza to, że strona wczytuje się w 1,5 sekundy nawet w sieci 3G, gdy pamięć podręczna jest pusta, a większość z nich to DNS i SSL.

Otwieranie ekranu jest naprawdę proste, więc zrobienie tego w 5K nie było wyzwaniem. Naprawdę denerwuje mnie to, że tak wiele witryn czeka na JS na pierwsze renderowanie, a niektóre nawet wymagają tego, aby przed renderowaniem wysyłać kolejne żądania. Wydłuża to czas renderowania 3G do 10 s, ponieważ użytkownik mobilny nie jest w stanie sobie na to pozwolić.

Główny plik JS ma 15 tys., ale nie obejmuje części, które są analizowane i minimalizowane w pliku SVG, ponieważ są wczytywane jako dodatkowa faza w tle. To świetna sprawa, bo interaktywność rozwija się bardzo szybko, a użytkownik nie zauważa dodatkowego wczytywania. Jeśli użytkownik wybierze obraz SVG, zanim skrypt stanie się dostępny, wczytanie skryptu będzie prawdopodobnie częścią czasu przetwarzania.

Użyłem też ServiceWorker, aby wszystko działało offline. Praca offline to świetna funkcja, ale głównie ze względu na wydajność. Kolejne wizyty w SVGOMG są renderowane niemal natychmiast, niezależnie od połączenia, jakie ma użytkownik. Biorąc pod uwagę różnice w łączności komórkowej, to naprawdę cenne!

Gdybyś miał(a) jakiś interfejs API, który mógłby ulepszyć Twoją aplikację, co by to było?

Użyłem Babel, by w przyszłości wykorzystać JavaScript. Dobrze byłoby mieć część z nich, która działa natywnie na platformie. Chodzi konkretnie o asynchronizację i oczekiwanie, funkcje strzałek, wartości domyślne argumentów i demontaż struktury.

Aby sprawdzić rozmiar danych wyjściowych, musiałem korzystać z biblioteki i skompresować je za pomocą programu gzip. Korzystanie z biblioteki do tego jest dość irytujące, ponieważ kod jest już w przeglądarce dla treści HTTP, ale nie ma do niego interfejsu API. Najlepiej, gdyby był to jakiś rodzaj strumienia przekształcania, który pozwoli mi policzyć rozmiar danych wyjściowych, nie mając wszystkiego w pamięci.