요약
SVGOMG: SVGO를 위한 아름답고 물질적이며 반응형 프런트엔드입니다.
좋아하는 점
Google의 Jake Archibald이 빌드한 SVGOMG는 웹 기술로 작성된 완전히 반응형이며 기능이 뛰어난 도구의 거의 완벽한 예입니다. 멋진 Material Design 디자인을 사용하며 ServiceWorker를 통해 앱이 빠르게 로드되고 오프라인에서도 사용할 수 있으며 모바일에서 전환이 원활합니다.
가능한 개선사항
유일하게 지적할 수 있는 점은 기본 UI가 누락되어 초기 UX가 혼란스럽다는 점입니다. 그 점을 제외하고는 잘하셨습니다.
제이크 아치볼드와의 Q &A
웹을 사용해야 하는 이유
게으름 게으름이 극에 달했습니다. 저는 Windows 네이티브 앱 개발 전문가가 아니며, OSX 네이티브 앱 전문가도 아니고, iOS, Android, Windows Phone 또는 Linux용 네이티브 앱을 만드는 전문가도 아닙니다. 하지만 웹은 할 수 있습니다. 이 하나의 기술 세트를 사용하면 모든 플랫폼에서 작동하는 앱을 한 번 빌드할 수 있습니다.
개발 중에 어떤 부분이 효과가 있었나요?
성능이 정말 만족스럽습니다. JS를 사용할 수 있기 전에 페이지가 렌더링되도록 합니다. 실제로는 인라인 CSS 및 SVG가 포함된 5, 000바이트의 HTML로 첫 번째 렌더링을 시작합니다. 기본 스크립트와 CSS는 모두 백그라운드에서 로드됩니다. 즉, 캐시가 비어 있는 3G에서도 사이트가 1.5초 후에 로드되는 것처럼 보이며, 이 중 대부분은 DNS 및 SSL입니다.
시작 화면은 매우 간단하므로 5K로 제작하는 데 어려움이 없었습니다. 많은 사이트에서 첫 번째 렌더링을 위해 JS를 기다리는 것이 정말로 불편합니다. 일부 사이트에서는 렌더링 전에 JS가 추가 요청을 해야 합니다. 이렇게 하면 3G 렌더링 시간이 10초에 가까워집니다. 모바일 사용자로서 저는 이를 참을 수 없을 것입니다.
기본 JS는 15KB이지만 SVG를 파싱하고 축소하는 부분은 포함되지 않으며, 이 부분은 백그라운드에서 추가 단계로 로드됩니다. 상호작용이 매우 빠르게 이루어지고 사용자가 추가 로드를 인식하지 못하기 때문에 매우 좋습니다. 사용자가 스크립트를 사용할 수 있기 전에 SVG를 선택하는 경우 스크립트 로드가 처리 시간의 일부로 표시됩니다.
또한 ServiceWorker를 사용하여 전체가 오프라인에서 작동하도록 했습니다. 오프라인 작업은 꽤 멋진 기능이지만 저는 주로 성능을 위해 사용합니다. SVGOMG를 다시 방문하면 사용자가 어떤 연결을 사용하든 거의 즉시 렌더링됩니다. 모바일 연결의 다양성을 고려할 때 이는 매우 중요한 사항입니다.
앱을 개선할 수 있는 API가 있다면 어떤 API를 선택하시겠어요?
향후 JavaScript 항목을 사용할 수 있도록 Babel을 사용했습니다. 이러한 기능 중 일부가 플랫폼에서 기본적으로 작동하면 좋을 것입니다. 특히 async/await, 화살표 함수, 인수 기본값, 디스트럭처링을 사용합니다.
라이브러리를 사용하여 출력을 gzip하여 gzip 크기를 알아야 했습니다. HTTP 관련 코드가 이미 브라우저에 있으므로 라이브러리를 사용하는 것은 다소 불편합니다. 단지 API가 없을 뿐입니다. 전체를 메모리에 저장하지 않고도 출력 크기를 계산할 수 있도록 일종의 변환 스트림이면 이상적입니다.