Podsumowanie
SVGOMG: piękny, materiałowy, responsywny interfejs dla SVGO.
Co nam się podoba?
Nasz pracownik Jake Archibald stworzył narzędzie SVGOMG, które jest niemal idealnym przykładem w pełni elastycznego i wszechstronnego narzędzia napisanego przy użyciu technologii internetowych. Aplikacja ma piękny interfejs w stylu Material Design, Service Worker sprawia, że wczytuje się szybko i jest dostępna offline, a przejścia są płynne na urządzeniach mobilnych.
Możliwe ulepszenia
Jedyną rzeczą, która nas naprawdę drażni, jest to, że początkowe UX jest mylące ze względu na brak głównego interfejsu. Poza tym wszystko w porządku.
Pytania i odpowiedzi z Jakem Archibaldem
Dlaczego internet?
Lenistwo. Total laziness. Nie jestem ekspertem w kwestii tworzenia natywnych aplikacji na Windowsa, nie jestem ekspertem w kwestii tworzenia natywnych aplikacji na OSX, ani nie jestem ekspertem w kwestii tworzenia natywnych aplikacji na iOS, Androida, Windows Phone czy Linuxa. Mogę jednak zająć się stronami internetowymi, a dzięki temu jeden zestaw umiejętności pozwoli mi stworzyć coś, co będzie działać na wszystkich tych platformach.
Co działało naprawdę dobrze podczas tworzenia?
Jestem bardzo zadowolony z wyników. Upewnij się, że strona jest renderowana, zanim będzie dostępna biblioteka JavaScript. W fakcie, do pierwszego wyrenderowania wystarczy tylko 5 kB kodu HTML z niewielką ilością wbudowanego kodu CSS i SVG. Główne skrypty i CSS są wczytywane w tle. Oznacza to, że strona wczytuje się w 1,5 s nawet w sieci 3G z pustą pamięcią podręczną, a większość tego czasu zajmuje DNS i SSL.
Ekran początkowy jest bardzo prosty, więc zrobienie tego w rozdzielczości 5 k nie było wyzwaniem. Bardzo mnie denerwuje, że tak wiele witryn czeka na JavaScript, aby po raz pierwszy je wyrenderować. Niektóre z nich wymagają nawet, aby JavaScript wysyłał kolejne żądania przed renderowaniem. W przypadku sieci 3G czas renderowania wydłużyłby się do 10 s. Jako użytkownik urządzeń mobilnych wiem, że nikt nie chciałby czekać tak długo.
Główny kod JS ma 15 KB, ale nie zawiera części, które analizują i skompresowują plik SVG, który jest wczytywany jako dodatkowa faza w tle. To świetne, ponieważ interaktywność pojawia się bardzo szybko i użytkownik nie zauważa dodatkowego wczytywania. Jeśli użytkownik zdąży wybrać plik SVG, zanim skrypt będzie dostępny, wczytywanie tego skryptu będzie częścią czasu przetwarzania.
Użyłem też ServiceWorker, aby wszystko działało offline. Praca offline to fajna funkcja, ale głównie korzystam z niej ze względu na wydajność. Kolejne wizyty na stronie SVGOMG są renderowane niemal natychmiast, niezależnie od połączenia użytkownika. Biorąc pod uwagę różnice w połączeniach mobilnych, jest to bardzo cenna funkcja.
Który interfejs API mógłby poprawić Twoją aplikację?
Użyłem Babel, aby móc korzystać z JavaScriptu w przyszłości. Byłoby świetnie, gdyby niektóre z tych funkcji działały natywnie na platformie. Chodzi o funkcje async/await, funkcje strzałki, wartości domyślne argumentów i destrukturyzację.
Musiałem użyć biblioteki, aby skompresować dane wyjściowe, i w ten sposób dowiedzieć się, jaki jest ich rozmiar po skompresowaniu. Korzystanie z biblioteki jest trochę uciążliwe, ponieważ kod jest już w przeglądarce do obsługi HTTP, ale nie ma do niego interfejsu API. Najlepiej, aby był to jakiś rodzaj przekształcania strumienia, aby można było obliczyć rozmiar danych wyjściowych bez przechowywania ich wszystkich w pamięci.