"현재의 네이티브 앱들의 기능과 유사한 형태의 웹 어플리케이션을 구현할 때 가장 난해한 부분은 어떤 것일까요? 아마 그래픽스, 성능, 네트워크 등 다양한 의견이 나오리라 생각됩니다만, 단언컨데 현재 가장 어려운 부분 중의 하나는 오프라인입니다. 서비스워커는 브라우저 측에서 동작하는 이벤트 기반의 시스템 Worker입니다. 이를 이용하여 오프라인 앱을 위한 리소스 관리, 원격 푸시 등을 직접 관리할 수 있습니다. 네이티브 어플리케이션에서는 일반화되어 있는 개념이기도 하지만 기존의 웹 개발에 익숙한 분들에게는 생소한 접근일 수 있습니다만 반드시 알아두어야 할 기능이라고 할 수 있겠습니다."
TL;DR;
초기부터 웹은 다양한 서버에 저장되어 있는 문서를 연결하기 위해 요청(Request) 및 응답(Response)의 메커니즘을 기반으로 동작하도록 설계되었습니다. 다시 말해 서버와 클라이언트가 네트워크를 통해 리소스를 송수신하도록 처리하고 있으며, 이 때문에 웹 페이지 자체의 성능 외에도 근본적으로 오프라인을 기반으로 하는 실행 환경은 아닌 것입니다.
서비스워커는 1차적으로는 이러한 오프라인의 문제를 해결하기 위한 시작점입니다. 물론 서비스워커가 해결하고자 하는 문제의 범위는 이보다 더 넓습니다. 오프라인은 시작일 뿐이지만 비유하자면 네이티브 어플리케이션의 동작 흐름을 웹으로 가져오기 위한 가장 중요한 기능이라고 할 수 있겠습니다.
이 튜토리얼에서는 서비스워커를 이용하여 브라우저의 캐시 시스템을 생성하고 관리하는 방법과 이를 통해 웹 페이지에서 사용하는 모든 리소스에 대한 오프라인 동작을 수행하는 방법을 알아봅니다.
> 서비스워커란
서비스워커는 웹페이지나 사용자 인터랙션이 필요하지 않은 기능들을 위한 기회를 제공하고, 웹페이지와는 별개로 여러분의 브라우저에 의해 백그라운드에서 실행되는 스크립트 기반의 워커(Worker)입니다.
이 기능은 앞으로 여러가지 연동 기능을 예정하고 있으며 네트워크 요청을 가로채고, 응답을 조작하기 위한 프로그래밍 가능한 캐시를 제어할 수 있는 기능을 현재 크롬에서 제공합니다.
> 서비스워커의 생명주기
서비스워커는 웹페이지와 완전하게 별개인 생명주기(Life Cycle)를 가지고 있으며, register를 통해 백그라운드에서 서비스워커의 설치 과정을 시작합니다.
설치 과정에서 리소스를 캐싱하고자 할 때 모든 파일이 성공적으로 캐싱되고 나면 서비스워커는 설치 상태가 되지만 만약 어떠한 파일이라도 다운로드나 캐싱에 실패한다면, 설치 과정 역시 실패하고 서비스워커는 활성화되지 않습니다.
설치가 이루어졌을 때 이어서 활성화 단계가 수행되며, 이는 우리가 서비스워커 갱신하기 섹션에서 다룰 기존 캐시의 관리를 위한 시점으로 활용할 수 있습니다.
활성화 단계 후에 서비스워커는 페이지가 등록한 서비스워커는 범주(scope) 내에 닿는 모든 페이지를 제어하게 되며 페이지로부터 네트워크 요청이나 메세지가 생성될 때 발생하는 fetch와 message를 제어하게 됩니다.
단순화한 서비스워커의 생명 주기
> 서비스워커를 사용하기 위한 몇 가지 사항
서비스워커는 지대한 영향을 줄 수 있는 서비스워커 모듈의 신뢰성을 위해 HTTPS 기반으로만 동작합니다. 또한, 현재 시점에서 캐시 시스템은 폴리필을 통해서만 사용할 수 있습니다.
"콜백에 의한 비동기 처리는 우리에게 성능이라는 한가지 장점과 사소해보이는 몇가지 단점을 같이 선물하였습니다. UI가 동작 중인 메인스레드에서 실행되는 자바스크립트에서 콜백에 의한 비동기 처리는 발생할 수 있는 성능 상의 문제를 해결하기 위한 최선의 방법이었습니다만 성능의 이점 대신 코드 작성은 좀 더 어려워졌고 선형적으로 디버깅할 수 있는 방법은 크게 복잡해졌습니다.
코드에서 무엇을 어떻게 처리할 것인지는 여러분의 몫입니다만 불행하게도 디버깅 역시 그러하며 특히나 비동기 처리라면 개발 환경을 넘어선 코드에 대한 깊은 이해를 요구하는 경우가 많으며 최근과 같이 외부에서 작성된 자바스크립트 라이브러리들을 사용하는 환경에는 더욱 더 그렇습니다.
크롬에서 추가된 비동기 자바스크립트에 대한 호출 스택과 왓치(Watch) 기능은 이러한 영역에서의 괴로움을 크게 줄여줄 것입니다."
TL;DR;
콜백 함수를 통해 비동기로 동작할 수 있는 능력은 자바스크립트를 특별하게 만드는 강력한 기능이지만 자바스크립트는 순차적으로만 실행되지 않으므로 디버깅 과정에서는 우리를 괴롭게 만듭니다.
다행스럽게도 이제 크롬 카나리 개발자 도구(DevTools)에서 비동기 자바스크립트 콜백이 포함된 호출 스택의 모두를 확인할 수 있습니다. 개발자 도구에서 비동기 콜 스택 기능을 활성화하면 다양한 지점에서 각 지점에서의 상태를 자세히 볼 수 있으며 스택을 추적해 가면서 런타임 실행에서 특정 지점의 어떤 변수 값을 분석할 수도 있습니다.
Build with Chrome은 Chrome 브라우저에 실행되며 LEGO® 벽돌들을 이용하여 구조물을 만들어낼 수 있으며 이를 Google Maps와 연동하여 전세계의 지도 위에 위치시킬 수 있는 인터랙티브 3D 컨텐츠입니다. 이 튜토리얼은 Build with Chrome이 2014년 다시 런칭하며 적용하였던 모바일 및 터치 지원 과정에서 발생한 주요 이슈에 대한 사례연구를 담고 있습니다. (저자인 Hans Eklund가 일하고 있는 North Kingdom은 그동안 '호빗 체험'이나 'RO.ME'과 같은 프로젝트를 만들어온 회사입니다. 포트폴리오도 재밌는 것이 많으니 한번 살펴보시기 바랍니다.)
"Build with Chrome이 2014년에 터치 스크린 및 모바일 디바이스를 지원하도록 적용하는 과정에서 발생한 성능, 터치 그리고 멀티 스크린 대응과 같은 주요 문제들은 다른 인터랙티브 3D 컨텐츠에서도 반복되는 문제입니다. 만약 비슷한 컨텐츠 개발을 계획 중이라면 읽어보시기 바랍니다."
TL;DR;
데스크탑 크롬용으로 개발되었던 Build with Chrome은 다시 릴리즈되는 과정에서 모바일 디바이스들을 지원하는 기능이 새로 추가되었습니다. 이 과정에서의 가장 큰 이슈들은 사용자 경험과 디자인에 대한 해결이었으며 기술적인 도전은 많은 화면 크기, 터치 이벤트 그리고 성능 이슈들을 관리하는 것이었습니다. 터치 디바이스 상에서의 WebGL 쉐이더 사용에 대한 몇가지 도전과제들이 있었지만 이는 기대했던 것보다 꽤나 잘 동작했습니다. 디바이스들은 점점 더 강력해지고 있으며 WebGL 구현들은 빠르게 개선되고 있으므로 가까운 시일 내에 더 많은 디바이스에서 WebGL을 더 많이 사용할 수 있을 것이라고 예상할 수 있습니다.
> 반응형 프론트엔드
터치와 마우스 입력을 사용하는 디바이스 모두를 지원해야 했으나, 작은 터치 스크린 상에서 동일한 UI를 사용하는 것은 공간 제약을 제대로 해결할 수 없었고 사용자의 손가락이 상호작용을 하는 동안 작은 스크린의 많은 부분을 커버하였으므로 픽셀들보다 물리적인 스크린 사이즈에 대해 정말 고려하고 실제 컨텐츠에 전념할 수 있도록 가능한 많은 공간을 확보하는 것이 중요합니다.
Build with Chrome의 경우 터치 디바이스에서 자연스럽게 느끼도록 만들고 정말 터치 입력을 의도한 것처럼 느끼도록 하기 위해 미디어쿼리를 이용하여 2가지의 UI 변경 버전을 개발하였습니다.
마우스와 터치를 지원하는 큰 화면
큰 화면 버전은 마우스를 지원하는 모든 데스크탑 컴퓨터와 큰 화면을 가진 터치 디바이스에 제공되며 터치 지원과 몇가지 제스쳐가 추가된 오리지널 데스크탑 버전과 유사합니다.
터치만 지원하는 작은 화면
이 모바일 디바이스들과 작은 태블릿용 버전은 멀티-터치를 요구하며 화면 상의 공간을 최대화하기 위한 대부분의 작업은 잘 사용하지 않는 UI 요소들을 최소화하거나 멀티 터치 제스쳐로 변경하고 풀스크린 모드를 지원하는 것이었습니다.
> WebGL 성능과 지원
현재의 터치 디바이스들은 꽤 강력한 GPU들을 가지고 있지만 여전히 데스크탑의 상대가 되기는 어려우므로 성능, 특히 동시간에 많은 구조물을 렌더링할 필요가 있는 3D 탐색 모드에 대해 텍스쳐, 구조물 로딩이나 구조물들의 애니메이션 및 렌더링 등 많은 것들이 동시에 처리되어 GPU와 CPU 모두를 크게 요구했으므로 모바일 디바이스에서는 구조물에 꽤 가깝게 줌하도록 하여 동시에 많은 구조물을 렌더링할 필요가 없도록 하는 접근을 취했습니다. 다만, WebGL 기능이 없는 디바이스의 경우 WebGL의 사용없이 빌드와 3D 탐색 기능을 유사하게 동작할 수 있는 충분히 훌륭한 해결방법을 찾지는 못했습니다.
> 화면 방향 관리하기
모바일 디바이스에 적용을 시작할 때 세로 모드(Portrait mode)에서 가로 모드(Landscape mode)에 대해 고려할 필요가 있습니다. Build with Chrome의 경우 컨텐츠의 흐름을 유지하고 편안한 방식의 상호작용을 제공하면서 가로와 세로 방향으로 모두 동작하는 대신 가로 모드만을 지원하기로 하였습니다.
대부분의 컨텐츠 레이아웃은 CSS에 의해 제어되지만 방향과 관련된 것은 자바스크립트에서의 구현을 필요로 하였으며 이를 위해 window.orientation을 사용하는 것은 좋은 크로스-디바이스 솔루션이 아니라는 것을 확인하였으므로 window의 .innerWidth와 .innerHeight의 비교하였습니다.
> 터치 지원 추가하기
웹 컨텐츠에 대한 터치 기능의 추가 지원은 합리적이며 올바른 것입니다. 마우스와 터치를 동시에 지원하기 위한 포인터 이벤트는 W3C에 표준으로 제출되었습니다만 아직 인터넷 익스플로러에서만 구현되어 있습니다. 따라서 터치 이벤트들 또한 다루는 것이 필요할 것입니다. 이 글은 이 이벤트들을 어떻게 사용하는지에 대한 기초들을 다루고 있습니다.
멀티터치 제스쳐
핀치(Pinch)와 회전 제스쳐를 관리하기 위해 두번째 손가락이 화면에 얹어질 때마다 두손가락 사이의 거리와 각도를 저장했습니다.
마우스와 터치의 동시 지원
오늘 날에는 마우스와 터치 입력을 둘 다 지원하는 디바이스가 있으므로 터치 지원의 검출만으로 마우스 입력을 무시하는 대신 동시에 전부를 지원하지 않는다면 몇가지 예상치 못한 동작을 발생할 수 있습니다.
마우스, 터치 그리고 키보드 입력 처리
이벤트 핸들러 내에서의 입력을 변수에 저장하고 requestAnimationFrame의 렌더 루프에서 입력에 반응하도록 하여 렌더링 성능 등의 오버헤드를 최대한 회피하고 마우스 입력 등으로의 확장을 보다 용이하도록 합니다.
또한 각 이벤트 핸들러에서 event.preventDefault()는 브라우저가 스크롤이나 전체 페이지의 스케일을 조정하는 것과 같은 예상치 못한 동작을 발생할 수 있는 터치 이벤트의 지속적인 처리를 막을 수 있습니다.
HTML5Rocks에 +Sam Dutton의 'WebRTC 시작하기(Getting Started With WebRTC)' 튜토리얼의 한글 버전이 업데이트되었습니다. 이번 번역은 이원제(+nuri nam)님께서 수고해주셨습니다. :)
"말그대로 WebRTC는 웹을 위한 실시간 통신 규격입니다. 이는 오디오나 비디오 스트림을 P2P로 송수신하는 것뿐만이 아니라 데이터 전달을 위한 메커니즘을 포함하고 있습니다. 대다수의 서비스들은 클라언트-서버 간의 데이터 통신을 통해 기능을 제공하고 있지만 어떤 경우는 클라이언트 간의 빠른 데이터 교환이 주요 기능 구현 사항이 되기도 합니다. 바로 이러한 경우 WebRTC는 중요한 기반 기능을 제공합니다. 뒤집어 얘기하자면 서버를 중계할 이유가 없으며 클라이언트 간의 데이터를 빠르게 송수신하고자 한다면 WebRTC는 좋은 선택이 될 수 있습니다. WebRTC의 다양한 구현 사례를 보기 전에 이 튜토리얼을 통해 WebRTC가 어떠한 것이고 어떻게 사용하는지를 확인해보시기 바랍니다."
TL;DR;
현재 웹의 주요 도전 과제 중에 남은 하나는 실시간 대화(Real Time Communication, RTC) 가능하게 하는 것입니다. 많은 웹서비스들이 이미 실시간 통신을 사용하고 지만 네이티브 앱이나 플러그인들의 다운로드가 필요했습니다. 이제 HTML5에서 플러그인 없는 실시간 통신을 위한 규격인 WebRTC는 현재 크롬, 오페라, 파이어폭스에서 가능하며 WebKitGTK+ 와 Qt 네이티브 프레임워크에도 통합되어 있습니다.
(getUserMedia라고도 하는) MediaStream - 카메라/마이크 등 데이터 스트림 접근
RTCPeerConnection - 암호화 및 대역폭 관리 및 오디오 또는 비디오 연결
RTCDataChannel - 일반적인 데이터 P2P통신
> MediaStream
MediaStream API는 미디어의 동기화된 스트림들을 말합니다. 예를 들어, 카메라와 마이크의 입력에서 받아온 스트림은 오디오와 비디오 트랙들로 동기화 됩니다. getUserMedia()는 반드시 로컬 파일 시스템이 아닌 서버에서 사용되어야 합니다.
> 시그널링(Signaling)
WebRTC 클라이언트로 사용되는 웹 브라우저들 사이에 스트리밍 데이터를 주고 받기 위해 RTCPeerConnection를 사용하며 통신을 조율하고 조장할 메세지를 주고 받기 위해 시그널링(Signaling)으로 알려진 일련의 과정이 필요합니다. 시그널링(Signaling)은 RTCPeerConnection API에 포함되지 않지만 WebRTC 개발자들은 SIP, XMPP 또는 적절한 쌍방통신 채널 등 자신들에게 편한 방식을 선택할 수 있습니다.
> RTCPeerConnection
RTCPeerConnection은 Peer들 간의 데이터를 안정적이고 효율적으로 통신하게 처리하는 WebRTC 컴포넌트입니다. JavaScript 측면에서 보면 RTCPeerConnection는 WebRTC에서 사용되는 엄청나게 많은 일들을 개발자가 신경쓰지 않을 수 있도록 많은 기능을 백그라운드에서 지원하고 있습니다. 실제로 WebRTC는 서버가 필요하지만 단순합니다.
> RTCDataChannel
오디오와 비디오처럼, WebRTC는 실시간으로 다른 형태의 데이터 통신도 지원합니다. RTCDataChannel API는 피어와 피어간 임의의 데이터 교환을 빠른 반응속도와 높은 처리량으로 가능하게 합니다. 이 API를 이용하여 게임이나 원격 데스크탑 어플리케이션, 실시간 채팅, 파일 전송, 분산 네트워크 등으로의 응용이 가능합니다.
RTCDataChannel API는 RTCPeerConnection의 대부분의 기능들을 활용하여 강력하고 유연한 P2P통신을 가능하게 하는 몇가지 기능을 가지고 있으며 통신은 브라우저간 직접 연결됩니다 , 그래서 RTCDataChannel은 WebSocket보다 매우 빠릅니다. 심지어 방화벽과 NAT의 방해로 '구멍내기'가 실패하여 중계(TURN) 서버와 연결이 되더라도 빠릅니다.
> 보안
실시간 통신 어플리케이션이나 플러그인에서 보안 문제가 발생하는 경우가 몇가지가 있습니다. WebRTC는 이 문제들을 피할 수 있는 몇가지 기능들을 가지고 있습니다:
WebRTC는 DTLS와 SRTP등의 보안 프로토콜을 사용하여 구현되었습니다. 따라서 암호화는 Signlaing 메커니즘을 포함한 모든 WebRTC Components의 필수 조건입니다.
그동안 웹에서 오디오와 비디오의 캡쳐는 재생과는 전혀 다른 범주의 기능처럼 인식되어 왔습니다. HTML5는 다른 많은 기능과 마찬가지로 오디오 및 비디오의 재생뿐만이 아니라 오디오나 비디오 입력 스트림의 처리를 가능하도록 그 기능을 확장하였습니다. 이 튜토리얼은 이 기능들을 다루기 위한 기초적인 설정 방법부터 몇가지 일반적인 구현 사례를 설명합니다.
"오랜 기간동안 웹 환경은 개발자에게 플래시나 실버라이트와 같은 플러그인을 이용하여 오디오와 비디오 캡쳐를 구현하도록 강요해왔습니다. HTML5는 이러한 플러그인 종속성을 없애고 이들 장치에 대한 입력 스트림을 직접 제어할 수 있도록 기능을 제공하고 있습니다. 입력 스트림을 제어한다는 것은 여러분의 웹 앱을 생각보다 더 크게 확장할 수 있습니다. WebRTC의 일반적인 사례처럼 비디오 컨퍼런스 서비스를 구현할 수도 있지만 조금만 더 아이디어를 덧붙인다면 네이티브에서 구현해왔던 얼굴/모션의 검출 등으로 얼마든지 확장할 수 있습니다."
TL;DR;
지난 세월동안 오디오와 비디오 캡쳐는 외부 플러그인들을 사용할 수 밖에 없었습니다. HTML5는 다양한 하드웨어에 대한 접근을 표준 규격으로 정의하고 있으며 오디오와 비디오의 캡쳐 역시 예외는 아닙니다. 이와 관련해서 그동안 다양한 규격들이 W3C에서 시도되어 왔지만 현재 getUserMedia()를 통해 대다수의 작업을 할 수 있도록 정리되었습니다. 이제 여러분은 getUserMedia()를 통해 사용자의 카메라와 마이크를 웹앱에서 접근할 수 있습니다.
> 멀티미디어 디바이스의 접근
사용자의 멀티미디어 디바이스의 입력 스트림을 제어하기 위해서 다음과 같은 기능들이 필요할 것입니다.
미디어에 대한 권한 요청
웹캠과 마이크에 접근하기 위해서는 먼저 어떤 디바이스에 어떠한 방식으로 접근하는지에 대한 권한을 getUserMedia()를 이용하여 요청해야 합니다.
미디어 기능 요구사항 설정
필요하다면 getUserMedia()의 호출 시 접근하고자 하는 미디어 스트림에 대해 필요한 요구사항들(해상도, 비트레이트 등)을 설정할 수 있습니다.
미디어 소스의 검색과 선택
크롬의 경우 버전 30 이후부터는 getUserMedia()에서 입력 스트림으로 사용가능한 소스를 검색할 수 있도록 MediaStreamTrack.getSources() API를 지원합니다.
이 API를 이용하면 현재 디바이스에 지원하고 있는 접근 가능한 입력 스트림 소스에 대한 리스트를 액세스할 수 있으며 이를 통해 적합한 디바이스를 선택할 수 있습니다.
getUserMedia()를 사용할 때 일부 브라우저는 카메라와 마이크에 대한 접근에 대한 사용자 허가를 요청하는 상태바를 표시할 수 있으며 getUserMedia()가 지원되지 않거나 API 호출이 실패하였을때 다른 형태의 미디어로 대체하는 과정이 필요할 수 있습니다.
> 입력 스트림을 통한 몇가지 구현 사례들
디바이스의 입력 스트림에 성공적으로 접근한 뒤에 <video>나 <audio> 태그의 소스로 사용할 수도 있지만 이를 통해 다음과 같이 추가적인 기능을 구현할 수도 있습니다.
사진 찍기
<canvas> API의 ctx.drawImage()를 이용하여 입력 스트림을 정적인 사진 이미지 형태로 활용하여 사진 촬영 기능으로 사용할 수 있습니다.
효과 적용
CSS Filters를 사용해서 <video>에 대한 효과를 적용할 수 있습니다.
비디오 스트림을 WebGL Texture로 이용할 수 있습니다.
크롬의 경우 getUserMedia()의 스트림을 Web Audio API로 연결하여 오디오를 직접 제어할 수 있습니다.
이제 웹앱의 범주를 확장하기 위한 다양한 시도들 중의 하나인 getUserMedia()를 이용하여 다양한 어플리케이션의 개발을 시도해보시기 바랍니다. 자세한 내용은 튜토리얼을 참조하세요.
당연한 얘기지만 모든 최적화는 문제가 되는 지점을 개선하는 작업입니다. 당연한 얘기겠지만 이러한 이유로 성능 병목 지점을 찾는 것이 가장 첫번째 단계입니다. 문제의 원인을 찾으면 여러가지 테크닉 중 어떤 것을 선택해서 해결할 수 있는지에 대한 방법을 결정할 수 있을 것입니다. 이 튜토리얼은 Find Your Way to Oz의 개발 과정에서 성능 문제를 개선하기 위해 병목 지점들을 찾는데 사용된 방법을 다루고 있는 사례 연구이기도 하며 실질적인 가이드라인이기도 합니다.
"가비지 콜렉션이나 로직 오버헤드, 렌더링 오버헤드 혹은 리소스 로딩으로 인한 jank 등 하나의 어플리케이션에서 성능에 영향을 주는 요인은 굉장히 많습니다. 점진적으로 하나씩 개선해나가는 방식도 좋지만 가능하다면 가장 큰 요인 중 가장 쉽게 해결할 수 있는 것들부터 찾아나가거나 다른 기준에 의해 성능을 개선할 수도 있을 것입니다. 만약 이러한 방식을 원하신다면 그 무엇보다도 우선시되어야 할 작업은 최적화가 아닌 진단입니다."
TL;DR;
최근 몇 년 동안 자바스크립트 가상 머신 기술의 놀라운 진보에도 불구하고, 최근 한 연구는 Google 어플리케이션이 그들의 시간 중 50~80%를 V8에서 보내고 있음을 증명하였습니다. CPU 사이클은 하나의 제로-썸 게임입니다. 시스템 리소스를 더 적게 사용하도록 하는 것은 더 높은 성능을 보여주는 방법이며 고성능 실시간 어플리케이션에서 무엇보다 중요합니다.
성능 문제를 해결하는 것은 범죄를 해결하는 것과 유사합니다. 여러분은 조심스럽게 증거를 조사하고 의심되는 원인들을 확인하고 다른 해결책들을 실험하는 것이 필요합니다. 이러한 과정 내내 문제를 실제로 고쳤는지 확인할 수 있도록 반드시 측정된 결과들을 문서화해야 합니다.
이 튜토리얼은 Find Your Way to Oz의 모호한 성능 문제를 찾아내고 자바스크립트를 최적화와 프로파일링한 방법들을 다루고 있습니다. Oz의 경우 가설을 통해 최종적으로 선택된 두 개의 용의자가 있었으며 이를 V8 엔진의 로그와 V8 내부의 최적화에 관련된 추적을 통해 정확한 문제점을 도출하고 자바스크립트 for-in 구문의 수정을 통해 성능을 개선하였습니다.
> 자바스크립트의 로그를 이용한 성능 요인 검출 방법
V8 자바스크립트 엔진은 내장된 로깅 시스템을 가지고 있습니다.
터미널에서 "--no-sandbox --js-flags="--prof --noprof-lazy --log-timer-events" 인자들을 이용하여 크롬을 실행하고 어플리케이션을 구동한 뒤 종료하면 현재 디렉터리 안에 v8.log 파일이 생성됩니다. 이렇게 생성된 로그는 tick processor와 plot-timer-event를 통해 분석할 수 있습니다.
> V8 최적화의 추적
V8의 자바스크립트 성능 관련 팁들에서 언급된 바 있듯이 V8은 높은 성능을 위해 실행 시간에 자바스크립트에 대한 많은 최적화를 수행합니다. 만약 이 과정에서 의심되는 문제가 있다면 터미널에서 "--js-flags="--trace-deopt --trace-opt-verbose" 인자를 통해 크롬을 실행하여 상세 로그를 확인할 수 있습니다.
Node.js가 등장한 이후 이를 이용한 다양한 모듈과 서비스들 쏟아져 나왔습니다. 아마 Ben Alman이 만든 Grunt 역시 그 중의 하나이며 가장 사랑받는 모듈 중의 하나일 것입니다. Grunt는 프론트엔드 웹 개발 및 배포 환경의 많은 부분을 자동화할 수 있도록 강력한 빌드 기능을 제공합니다. 특히 JavaScript를 통해 이러한 부분이 제어될 수 있다는 점 역시 프론트엔드 개발자들에게 Grunt가 사랑받는 이유 중의 하나일 것입니다.
그러나 대부분의 프론트엔드 개발 프로젝트는 강력해진 기능만큼이나 복잡한 개발 및 테스트, 배포 환경을 필요로 하게 되었고 부피가 커진 만큼이나 다루기가 어려워져 가고 있습니다. Grunt도 이 부분에서는 예외가 아닙니다.
이 튜토리얼은 프로젝트가 커질 수록 더 유용해지는 몇가지 Grunt 플러그인들과 Grunt의 빌드 프로세스 자체를 개선할 수 있는 핵심적인 내용을 살펴볼 것 입니다.
"Grunt는 개발자가 커스터마이징할 수 있는 강력한 빌드 환경을 제공합니다. 하지만 복잡하고 거대해진 프로젝트 빌드 환경을 관리하는 것은 프로그래밍과는 또다른 영역의 작업들을 수반합니다. Gruntfile을 얼마나 깔끔하게 관리할 수 있는지, 빌드를 얼마나 신속하게 끝낼 수 있는지, 빌드의 완료나 문제에 따른 알림 처리를 통해 작업에 빠르게 복귀할 수 있는지에 대한 문제는 프로젝트가 커질 수록 더 중요해집니다. 과거의 (물론 현재도) Makefile이 그랬듯이 큰 프로젝트를 관리하는 것은 프로페셔널의 또 다른 모습일 것입니다."
TL;DR;
프로젝트가 커질 수록 깔끔하게 정리되고 빠르고 선택적인 처리, 무언가가 잘못되었을 때 알림을 발생하는 빌드 시스템은 언제나 개발자에게 유용합니다. 이 튜토리얼은 최근 프론트엔드 개발에서 널리 쓰이고 있는 Grunt의 빌드 프로세스 자체를 다음 관점에서 살펴봅니다.
어떻게 Gruntfile을 산뜻하고 깔끔하게 유지할 수 있는가,
어떻게 빌드 시간을 극적으로 개선할 수 있는가,
빌드 시 발생한 이벤트들을 어떻게 전달받을 수 있는가.
> Gruntfile의 체계적인 정리
Gruntfile 체계화하는 것은 지속적인 빌드 설정의 관리와 유지 보수 측면에서 매우 중요합니다. Gruntfile 내에 수많은 Grunt 플러그인이나 수동 태스크들을 깔끔하게 정리할 수 있는 플러그인들은 다음과 같습니다.
Grunt 플러그인의 자동로딩
load-grunt-tasks는 package.json 파일을 분석할 것이며 이 태스크가 어떠한 Grunt 플러그인들에 대한 의존성들을 가지는지에 따라 이들 모두를 자동으로 로딩합니다.
Grunt 설정의 파일 단위 분리
load-grunt-config은 Gruntfile 설정을 작업 단위로 분리하며 load-grunt-tasks 및 그 기능들을 캡슐화해줍니다.
> 빌드 시간의 최소화
웹 앱의 실행 성능은 사업적으로 중요한 의미를 가지지만 빌드 성능은 개발의 반복에 대한 생산성을 담보합니다. 빌드 성능을 개선하기 위한 방법은 다음과 같습니다.
변경 파일들만의 빌드
grunt-newer는 실제 파일 변경 정보를 저장하는 로컬 캐시를 통해 변경된 파일들에 대해서만 태스크를 실행합니다.
다중 태스크의 동시 실행
grunt-concurrent는 CPU 단위의 스레드를 이용하여 동시에 여러개의 태스크를 실행합니다.
서로에 대해 독립적이며 큰 실행 시간을 필요로 하는 다량의 태스크들을 가지고 있을 때 유용합니다.
빌드 시간의 측정
작업 단위별로 실행 요구 시간을 측정하기 위해 time-grunt를 사용할 수 있습니다.
이는 다른 최적화와 마찬가지로 각 작업에 대한 최적화 지점을 찾을 수 있도록 합니다.
> 자동화된 시스템 알림
만약 다음 빌드가 가능하다던지 빌드 중의 오류를 개발자에게 알려주는 것은 자동화된 프로세스만큼이나 개발자에게 유용할 수 있습니다. 이런 기능이 필요하다면 grunt-notify는 Grunt 에러와 경고 전부에 대해 자동화된 알림을 제공하는 방법으로 사용할 수 있습니다.
"WebRTC는 종종 화상 회의와 같은 미디어 통신을 위한 규격처럼 인식되는 경우가 있으나 그렇지 않습니다. 화상회의와 같은 것은 WebRTC의 P2P 통신과 mediaCapture()이 결합된 좋은 사례 중 하나일 뿐이죠. WebRTC는 근본적으로 P2P를 기반으로 하는 데이터 전송 메커니즘입니다. 이는 파일 전송뿐만이 아니라 P2P를 기반으로하는 멀티플레이어 게임에도 유용합니다. RTCDataChannel은 파일 공유, 멀티플레이어 게임, 콘텐츠 전송을 위한 앱을 만드는 새로운 방식이며 이를 사용하여 낮은 지연 시간을 가지는 고성능 네트워크 어플리케이션을 제공할 수 있습니다. RTCDataChannel의 출현은 브라우저에서 데이터의 통신 방식 중 많은 부분들을 바꾸게 될 것입니다."
TL;DR;
커뮤니케이션, 게임, 혹은 파일 전송을 위한 두 브라우저 간의 데이터 전송은 상당히 복잡한 과정일 수 있습니다. 우리에게는 WebSocket, AJAX, 그리고 Server Sent Events가 있지만 근본적으로 서버를 통한 통신 모델로 디자인되었습니다. 데이터를 중계(relay)하기 위해 서버를 설정하고 비용을 내야 하며, 아마도 이를 여러 데이터 센터로 확장할 필요가 있습니다. 이 시나리오는 높은 지연 시간(latency)의 가능성이 있고, 데이터를 비공개로 유지하는 것이 어렵습니다.
한 피어(peer)에서 다른 곳으로 직접 데이터를 전달하기 위해 WebRTC의 RTCDataChannel API를 사용하는 것은 P2P(peer-to-peer) 연결을 가능하게 하여 중개 서버가 없고 '홉(hops)'이 적어 지연 시간을 더 줄일 수 있습니다.
> WebRTC DataChannel의 특성
RTCDataChannel API는 웹소켓을 완전히 모방하여 디자인되었을 뿐만 아니라 문자열, Blob, ArrayBuffer 그리고 ArrayBufferView와 같은 일부지만 유용한 자바스크립트 바이너리 타입을 지원합니다. RTCDataChannel은 다음과 같이 UDP와 유사한 '신뢰성 없는 모드'와 TCP과 유사한 '신뢰성 있는 모드' 둘 중 하나로 동작할 수 있습니다.
신뢰성 있는 방식은 메시지 전송과 메시지가 전달되는 순서를 보장하지만 추가적인 오버헤드가 있으며 신뢰성 없는 방식은 모든 메시지가 상대편에 도달하는지와 어떤 순서로 도달하는지를 보장하지 않는 대신 오버헤드를 제거합니다
시그널링이 일어난 전후에 이미 설정한 피어 연결로부터 dataChannel 오브젝트를 생성하고 옵션을 설정하여 데이터 채널의 신뢰성 등을 설정할 수 있습니다. RTCDataChannel은 연결이 되거나, 끊기거나, 에러가 발생할 때와 다른 피어에서 메시지를 받았을 때 이벤트를 발생하도록 할 수 있습니다.
> 안전성
암호화(Encryption)는 WebRTC 요소의 기본 사항입니다. RTCDataChannel을 사용하면 모든 데이터가 데이터그램 전송 계층 보안 (Datagram Transport Layer Security, DTLS)을 사용하며 WebRTC를 지원하는 모든 브라우저가 DTLS를 내장하고 있으므로 추가적인 구현없이도 안전한 데이터 송수신을 가능하게 합니다.
이 튜토리얼은 WebRTC 데이터 채널을 설정하고 사용하는 기본적인 방법뿐만 아니라 오늘날 웹에서의 일반적인 사용 사례를 다루고 있습니다. 자세한 내용은 튜토리얼은 참조하시기 바랍니다. :)
사용자는 브라우저를 통해 문서를 요청하고 다운로드하고 이를 파싱하거나 렌더링하는 등의 일련의 과정을 거쳐 완성된 페이지를 확인하게 됩니다. 같은 이유로 사용자 입장에서의 로딩 성능이란 이 일련의 과정에 대한 성능이 됩니다. 철저히 클라이언트 입장에서의 감각이죠. 그렇다면 사용자에게 높은 수준의 로딩 성능을 체험할 수 있도록 해주기 위해서는 무엇을 해야할까요? CDN을 통해 최소한의 네트워크 경로를 통해 리소스를 배포하고 웹 페이지의 구조는 최적화되어야 하며 여러가지 기법들이 사용되어야 합니다. 우리는 이를 위한 일반적인 체크리스트들을 많이들 보게되지만 이게 끝일까요?
모든 최적화는 '측정'에서 출발합니다. 측정되지 않는 것은 불행하게도 추측과 실험의 반복(Iteration)을 통해서 접근할 수 밖에 없습니다. 하지만 로딩 성능를 측정하는 방법은 쉽지 않습니다. 자바스크립트를 이용하여 어느 정도의 추적은 할 수 있지만 이 접근은 근본적으로 자바스크립트가 웹 페이지에서 가지는 생명 주기와 같은 이슈들로 인해 우리를 정확한 측정에서 한발 물러서 있도록 합니다. Navigation Timing은 우리가 해왔던 이러한 일들을 브라우저 측면에서 접근합니다. 정확한 시간을 측정하고 그 시간값을 통해 정확한 최적화 지점을 찾을 수 있도록 합니다.
이 튜토리얼은 브라우저의 네비게이션 과정에 대한 시간 흐름을 측정할 수 있는 Navigation Timing을 다루고 있습니다. 이번 번역은 변정훈(Outsider)님께서 수고해주셨습니다. :)
"Navigation Timing 인터페이스는 일련의 브라우징 과정에 대해 브라우저가 직접 측정한 결과값을 제공합니다. 사용자는 언제나 브라우저를 통해 우리의 웹페이지에 접근하므로 이러한 정확한 측정값은 제대로 된 최적화를 위한 첫걸음을 딛을 수 있도록 해줍니다. 사용자 타이밍과 함께 사용한다면 여러분의 웹페이지가 가지는 성능 상의 약점을 쉽게 파악할 수 있는 강력한 도구가 될 것입니다."
TL;DR;
사람들은 빨리 뜨는 웹페이지를 좋아합니다. 하지만 웹페이지의 로딩 속도는 어떻게 측정해야 하며 "페이지 로딩"의 의미는 정확히 무엇일까요?
Navigation Timing은 웹의 성능을 정확하게 측정하는 자바스크립트 API입니다. Navigation Timing API는 페이지 탐색과 로드 이벤트와 관련한 정확한 타이밍을 자세하게 얻을 방법을 제공합니다. 현재 이 API는 인터넷 익스플로러 9, 크롬, 파이어폭스에서 사용할 수 있습니다.
[그림] Navigation Timing에 대한 기본 Mark들
Date 객체를 사용해서 타이밍을 측정하는 방법과는 달리 Navigation Timing API는 페이지 로딩에 전혀 영향을 주지 않고 사용할 수 있습니다. 그러므로 사내 네트워크에서 개발용 컴퓨터를 사용해서 개발자가 직접 테스트하는 대신 실제 사용자가 겪는 "현실"의 페이지 로딩 지연시간을 측정하는 데 유용하게 사용할 수 있습니다.
Navigation Timing은 개발자가 성능을 이해하고 최적화하도록 유용한 도구를 제공하며 더 나은 정보는 페이지 로드 지연을 이해하는 데 유용하고 이로써 더 효율적인 웹사이트와 인프라, 더 빠른 웹 애플리케이션과 웹을 만들 수 있고 좋은 사용자 경험을 제공할 수 있습니다.
이 튜토리얼은 Navigation Timing API를 사용해서 타이밍 데이터를 사용하는 방법을 설명합니다. 보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.
오랜만에 업데이트를 하게 되는군요. 그간 HTML5Rocks의 튜토리얼들을 함께 번역해주신 분들의 노력에 힘입어 Web Component에 관련하여 설명할 수 있는 문서의 뼈대가 만들어졌습니다. 다른 한글화 및 업데이트 소식들도 밀려있는데 잠시 미뤄두고 이에 대한 포스팅을 하고자 합니다.
"다소 거창한 제목을 붙였습니다만;; 컴포넌트가 완전한 에코 시스템하에서 가지는 강력함과 파괴력을 우리는 다른 플랫폼에서서도 익히 봐왔습니다. 같은 관점에서 웹 컴포넌트 역시 프론트엔드 개발에 있어 많은 변화를 예고하고 있는 기술이라고 예상할 수 있지 않을까요?"
웹 컴포넌트?
웹 컴포넌트(Web Component)의 개념 자체가 아주 새롭고 특별한 기술은 아닙니다. 오랜동안 개발을 해오신 분들이 아니더라도 '컴포넌트(Component)'라는 말은 들어보셨으리라 생각합니다. 그러나 웹 컴포넌트가 가지는 의미를 알기 위해 웹에서의 컴포넌트가 왜 필요한지에 대해 잠시 생각해보도록 하겠습니다.
> 골격만큼이나 중요한 다른 것들...
한두번쯤은 게시판을 꾸미기 위해 혹은 만들기 위해 마크업 작업을 해보신 경험이 있을 것입니다. 사실 의미적으로 마크업이 가지는 모습은 매우 명확합니다. '<head>'에는 사용자의 눈에는 보이지 않지만 브라우저가 먼저 처리해야하는 많은 것들이 기술되어 있으며 '<body>'에는 우리가 사용자에게 전달하고자 하는 정보들이 담긴 수많은 마크업과 텍스트들이 존재합니다. 물론 이미지도 말이죠. 단지 이 관점에서 보자면 문서는 그리 복잡하지 않습니다. 예를 들어 W3C의 대한민국 인터넷 관심그룹이 그렇습니다. 문서는 깔끔하게 필요한 태그들만을 가지고 있고 그 자체로도 문서는 완전합니다.
그러나 실제는 어떤가요? 실제 현장까지 가지 않고 개인 홈페이지만 살펴보더라도 스타일에 대한 많은 시도들이 보이고 있습니다. 이들은 화려하고 아름답고 때로는 사용자 경험(UX)를 개선하는 많은 기능들을 제공합니다만 그 뒤에는 너무나도 복잡해져만 가는 마크업들과 스타일, 자바스크립트들이 존재합니다. 많은 요구사항들이 본래의 구조보다 많은 개발들을 요구하고 있죠. -물론 국내는 웹이 대중화되던 초기부터 그랬습니다. 지금은? :)-
GMail을 예로 들어보죠. 저는 GMail을 이용하고 있고 실제로는 애용하고 있습니다. 이 서비스는 쉽게 메일을 읽고 편리하게 기록 속에 남아 있는 다른 사용자들의 메일주소를 몇번의 타이핑만으로 찾을 수 있으며 답장 역시 현재 읽고 있는 페이지에서 가능합니다. 그러나 과연 개발도 그럴까요? 이 서비스를 개발자도구로 열어본다면 아마 그렇지 않다고 생각하게 될 것입니다.
전 오랜동안 네이티브 앱이나 서비스, 플랫폼을 개발해왔습니다. 사실 개발에 촛점을 맞춰보자면 웹 개발을 마지막으로 한 것은 CGI와 ASP가 전성시대를 열던 초기에 있었던 몇번이 제 경험의 대다수라고 해도 과언이 아닙니다. 그리고 현재 시점에서 다시 웹을 살펴보았을 때 정말 많은 것들이 바뀌었고 그에 놀라워함에도 불구하고 개발 방법 자체는 예전에 작업하던 많은 방식들이 그대로 이루어지고 있다는 것에 다시 놀랄 수 밖에 없습니다. (사실 편리해진 것들도 많고, 모든 것을 바꿔야할 필요가 없다는 것은 잘 알고 있습니다.)
여전히 우리는 다른 프로젝트에서 사용했던 리스트 아이템들을 새로운 프로젝트에서도 적용하기 위해 마크업을 복사해서 수정하고 스타일링을 위한 새로운 CSS를 작성하거나 기존 스타일과의 충돌을 제거하고, 자바스크립트를 최대한 모듈화하여 작성하고 있습니다. 그러나 여전히 이는 근본적인 재활용 방법이 아닌 개발자의 역량과 경험에 의존하고 있는 일종의 개선된 Workflow에 가깝습니다. 즉, 언제든지 우리는 태그의 바다(Tag Soup)와 같은 위험 지역에 다시 빠질 수 있는 가능성을 안고 있습니다. 게다가 태그의 바다에 빠진다는 것은 CSS나 자바스크립트의 태풍 속에 노출된다는 것과도 같죠.
> 무엇이 필요할까?
사실 우리는 필요한 것이 무엇인지는 이미 알고 있습니다. 다만 지금까지는 이를 방법론으로, 개발도구로, 경험으로 해결해왔을 뿐이죠. 이제 우리에게 필요한 것은 '자주 사용되는 유용한 것들 혹은 구조 상 분리가 필요한 것들을 개발의 다른 요소들과 충돌하지 않는 형태로 재활용이 가능하도록 만들어 주는 일관적인 방법'입니다. 특히 UI 요소들이 많은 프론트엔드 개발에서는 '리소스 관점에서 분리되어 있는 HTML, CSS, 자바스크립트를 하나로 묶어 주는 것' 또한 중요한 기능 중의 하나가 됩니다. 소프트웨어 개발에서는 이러한 요소들을 '컴포넌트(Component)'라는 개념으로 오랜동안 사용해 왔으며 예를 들자면 백엔드에서는 이미 다양한 형태의 컴포넌트가 각 플랫폼에 적합한 형태로 오랜동안 배포되고 사용되어 왔습니다. 이제 조금 더 나아가서 우리는 컴포넌트를 웹에서 (특히 프론트엔드 개발에서) 사용할 방법이 필요하며 가능하다면 도구적인 지원을 받을 수 있으면 더 좋을 것입니다.
다행스럽게도 W3C에서는 이러한 컴포넌트 기술을 웹에서 적용할 수 있도록 새로운 규격의 집합을 만들었으며 이 규격들을 묶어 '웹 컴포넌트(Web Component)'라고 부르게 되었고 이를 지원하는 도구와 라이브러리들의 작업이 여러 곳에서 매우 빠르게 진행되고 있습니다.
웹 컴포넌트를 지탱하는 규격들
앞에서 말씀드린 바와 같이 웹 컴포넌트는 하나의 규격으로 이루어진 것은 아닙니다. 개별적인 특성을 가진 여러개의 규격으로 이루어져 있죠. 이 포스트는 웹 컴포넌트의 기술적인 내용을 목적으로 하고 있지는 않지만 어떠한 규격들로 이루어져 있는지는 살펴보도록 하겠습니다.
웹 컴포넌트는 다음과 같은 4가지의 규격으로 구성되어 있습니다.
Shadow DOM - 컴포넌트의 DOM, CSS, JS를 감추는 캡슐화(encapsulation)와 외부로부터의 간섭을 제어하는 스코프(Scope)의 분리를 제공
HTML Template - 로딩 시간에는 비활성화되는 마크업을 정의하고 이를 실행 시간에 복제할 수 있는 기능을 제공
Custom Element - 웹 문서에서 사용할 엘리먼트의 동적인 등록을 통해 컴포넌트의 명시적인 alias를 선언
HTML Imports - 웹 문서 내에 외부 리소스를 포함(Import)하기 위한 기능을 제공
각 규격에 대해 간략하게 살펴보기 전에 +Eric Bidelman이 JSCamp에서 발표했던 다음 영상을 확인해보시기 바랍니다. (발표 자료는 여기에서 확인할 수 있습니다.)
JSCamp Talk: Eric Bidelman - WebComponents are the Future
> 캡슐화와 스코프의 제어 - Shadow DOM
지금까지의 웹 개발에서 하나의 페이지는 하나의 문서를 나타내었습니다. 이들은 구조를 나타내는 마크업이나 표현을 위한 스타일, 동작에 대한 자바스크립트들이 복잡하게 얽혀있지만 브라우저는 언제나 이들을 하나의 문서로 통합하여 제어해왔습니다. 하나로 보이는 것은 언제나 중요한 일입니다만, 실제로도 하나로 다루어지기 때문에 우리가 작성하는 모듈이나 마크업들은 언제나 다른 영역과 함께 보이고 관리되며 처리되어 왔습니다.
이러한 문제로 인해 웹 페이지를 개발할 때 몇 가지 UI 요소들은 지속적으로 재활용됨에도 불구하고 개발자가 올바른 DOM 트리를 구축하기 위해 마크업을 재작성하고 UI 요소를 둘러싸는 다른 요소들과의 구조적인 이슈들을 해결하기 위해 추가적인 작업을 필요로 합니다. 이러한 과정에서 발생하는 복잡한 DOM 트리들(좀 더 정확하게는 Tag Soup)은 재사용성과 개발 효율성에 크게 영향을 미치는 부분이기도 합니다.
Shadow DOM은 이러한 하나의 문서에서 특정한 DOM을 통해 복잡한 서브 DOM 트리를 대표할 수 있도록 만들었습니다. 이러한 개념을 우리는 캡슐화와 스코프 관점에서 바라 볼 수 있습니다.
"캡슐화(Encapsulation)은 소프트웨어 공학에서 매우 중요하게 다뤄지던 개념 중의 하나입니다. 캡슐화는 어떠한 모듈이나 기능 단위를 인터페이스만 남기고 외부로부터 완전하게 감추어주는 역할을 하며 Shadow DOM의 대표적인 장점 중의 하나이기도 합니다. 스코프(Scope)는 이러한 캡슐화 과정에서 나타나는 부산물이지만 여러가지의 모듈이 연동하는 소프트웨어에서 각 모듈의 독립적인 동작을 보장하는 매우 중요한 개념입니다. 조금 더 정확하게 얘기하자면 Shadow DOM은 스타일에 대한 캡슐화도 지원하고 있습니다."
우리는 Shadow DOM을 이용하여 컨텐츠와 표현을 분리할 수 있습니다. Shadow DOM은 이를 이용하여 캡슐화된 DOM 트리를 HTML 문서에 활용할 수 있는 가장 기초적인 개념과 원칙을 제공합니다. 표현(Presentation)과 내용(Contents)의 분리는 하나의 웹 문서가 지나치게 복잡해지는 태그의 바다(Tag Soup)를 해결해줄 뿐만이 아니라 보다 근본적인 기능-즉, 개발된 UI 요소의 재사용을 위한 가장 기본적이고도 중요한 기능-을 제공합니다.
또한, Shadow DOM이 컴포넌트를 구성하는 DOM을 감추는 역할(encapsulation)뿐만이 아니라 스타일에 대한 캡슐화를 지원함으로써 여러분은 배포된(혹은 배포한) 웹 컴포넌트에 대해 여러분의 스타일을 유지하거나 반대로 사용자의 페이지의 Look&Feel을 상속받아 위화감 없는 스타일을 구성할 수도 있습니다. 이러한 스타일에 대한 캡슐화는 특히 사이트를 구축하는 UI 요소로써는 매우 중요한 속성이 될 것입니다. 더불어 이러한 캡슐화된 스타일을 어떻게 관리할 것인가도 웹 컴포넌트의 사용자들에게는 중요한 지점이 될 것입니다.
> 런타임에만 활성화되는 복제 가능한 마크업 - HTML Template
템플릿은 뷰를 위한 기반 구조로 사용되는 미리 작성된 형식의 문서나 파일입니다. 즉, 문서가 표현될 형식 마크업를 정의한 뒤 재사용하도록 하여 (마크업의 작성이나 런타임 마크업 생성 모듈과 같은) 추가적인 개발 작업으로부터 개발을 간편하게 만들어줍니다.
템플릿의 개념 역시도 웹 개발에 있어 새로운 것은 아닙니다. 서버 측에서의 템플릿 활용뿐만 아니라 클라이언트에서도 우리가 주로 사용해오던 여러가지 방법들이 이미 존재합니다.
예를 들어, "오프스크린" 상에서 DOM을 생성하고 이를 hidden 속성이나 display:none을 사용하여 뷰로부터 이를 감추는 오프스크린 DOM은 브라우저에서 제공하는 다양한 기능을 활용하여 템플릿을 구현할 수 있지만 문서 내의 다른 DOM에 영향을 주는 등의 부작용을 가지고 있습니다. 반대로 <script>를 오버로딩하고 <script>의 컨텐츠를 문자열로 처리하는 스크립트 오버로딩은 렌더링 이슈 및 비활성화를 해결하고 있으나 .innerHTML의 사용을 필요로 하고 이로 인한 보안 취약성이 존재합니다.
WhatWG HTML Templates 표준규격은 템플릿을 위한 표준적인 DOM 기반의 접근 방법을 기술하는 새로운 엘리먼트인 <template>를 정의하였으며 템플릿 컨텐츠는 사용시까지 비활성화되어 렌더링되지 않고 템플릿 안의 스크립트나 DOM이 다른 곳에 영향을 미치는 부작용이 없습니다. 선언/재활용 역시 마찬가지이며 또한 적용 위치 역시 자유롭기 때문에 많은 부분에서 활용이 가능합니다.
> 새로운 엘리먼트의 동적인 등록 - Custom Element
웹은 문서의 구조적인 형식을 가지고 있지만 HTML 엘리먼트가 미리 정의된 엘리먼트에 대해서만 사용 가능하다는 문제로 앞에서도 얘기한 현재에도 웹앱을 구축하는데 있어서는 많은 이슈를 안고 있습니다. <div>가 끝도 없이 중첩되어 나타나는 <div> Soup가 대표적인 예입니다. 이를 기본적으로 해결해주는 기능은 Shadow DOM이라고 할 수 있습니다만, Custom Element는 사실 Web Components에서 가장 중요한 기본 API입니다.
Custom Element는 HTML의 엘리먼트를 사용자가 문서에서 확장하여 사용할 수 있도록 기능을 제공하고 있습니다. 즉, 모든 웹 개발자들이 새로운 타입의 HTML element를 정의할 수 있도록 하여 본질적으로 최종 개발자들이 Web Components를 쉽게 사용하기 위한 방법들을 제공한다고 볼 수 있습니다.
Custom Element는 새로운 HTML/DOM 엘리먼트뿐만이 아니라 다른 엘리먼트를 확장한 엘리먼트를 만들 수도 있고 하나의 엘리먼트에 사용자 지정 기능을 제공하는 방법을 논리적인 형태로 정의하거나 이미 존재하는 DOM 엘리먼트의 API 기능 자체를 확장하는데 사용할 수도 있습니다. 만약 여러분께서 Shadow DOM을 이용하여 복잡한 내부 구조를 가지는 웹 컴포넌트를 개발한다고 해도 Shadow DOM을 사용하도록 정의하는 Custom Element를 정의한다면 마치 '<itemlist type="card">' 형태로 단순화하여 사용자에게 전달할 수 있다는 뜻이기도 합니다.
> 웹을 위한 #include - HTML Imports
웹에서 각기 다른 형태의 리소스들은 개별적으로 로딩을 위한 메커니즘을 가지고 있고 이를 통해 개별적인 리소스에 대해서는 지속적으로 재사용 가능한 사례를 제공하고 있습니다. 그러나 웹의 기본 리소스인 HTML, CSS, 자바스크립트에 대해서도 그렇다고 생각할 수 있을까요?
<iframe>의 경우 사용이 가능하며 실제적인 방법이지만 무겁고 세부적인 제어에 있어서는 굉장히 큰 노력을 필요로 하면서도 결국 불가능한 부분들이 있습니다. 그외에도 Ajax를 사용하거나 <script> 태그를 응용한 각종 핵(hack)이 존재합니다. 동작을 위한 정말 굉장한 노력을 필요로 하는 웹 컨텐츠(HTML/JS/CSS 등)에 대해 하나의 패키지처럼 관리하며 로딩할 수 있는 메커니즘이 있다면 어떨까요?
HTML Imports는 HTML 문서를 다른 HTML 문서들에 가져오기 위한 방법이며 CSS, JavaScript 등의 어떠한 문서 리소스도 손쉽게 가져올 수 있습니다. 다시 말해서 Shadow DOM이 형태를 정의하고 Custom Element가 엘리먼트를 손쉽게 사용할 있도록 한다면 HTML Imports는 분산되어 있는 웹 컴포넌트 리소스를 불러올 수 있는 기능을 제공합니다. 컴포넌트를 배포의 경우는 말할 필요도 없을 것입니다.
웹 컴포넌트가 왜 중요한가?
여기까지 읽어보셨다면 웹 컴포넌트가 왜 중요한지는 이미 눈치채셨을 것이라고 생각합니다. '재사용성'을 기반으로 한 개발, 배포 및 유지보수의 편의성은 개발자에게는 다른 것들과 바꾸기 힘든 가치일 것입니다. 아마 앞으로는 웹 컴포넌트를 여러분이 쉽게 사용하기 위한 많은 서비스들이 나올 수 있을 것입니다. 배포와 삽입, 사용이 쉬워졌기 때문이죠. 게다가 일부 이슈가 있기는 하지만 현재도 이를 사용할 수 있도록 해주는 폴리필 기술들은 분명 축복이라고 할 수 있습니다.
도구들
웹 컴포넌트가 새로운 기술이라면 이를 지원하기 위한 많은 도구들 역시도 쉽게 찾을 수 있습니다. 최신 브라우저에서도 웹 컴포넌트 지원은 아직 진행 중인 사항이지만 우리는 웹 컴포넌트를 위한 폴리필 라이브러리인 Polymer나 X-Tag를 이용한 Brick을 쉽게 찾을 수 있습니다. Yeoman은 빌드를 위한 Grunt, 의존성 관리를 위한 Bower, 작업 흐름을 관리하기 위한 Yo를 통합하고 있는 도구입니다. 필요하다면 이러한 도구들을 이용하여 폴리필 라이브러리부터 여러분의 개발흐름까지도 손쉽게 개선할 수 있을 것입니다.
앞으로를 예상해봅시다.
예전에 GUI 개발이 일반화되던 시절 많은 회사들과 개발자들이 앞다투어 컴포넌트를 제공했습니다. 이는 그 당시의 프레임워크나 플랫폼들이 이를 지원하는 기술적인 기반을 제공했기 때문이기도 합니다. 웹 역시도 이미 오랜동안 그러한 시도들이 있어왔습니다만 이제 좀 더 유려한 방식으로 이를 지원할 수 있게 되었습니다. 여러분이 게시판의 아이템을 확장하기 위해 태그들을 다시 수정하고 이를 검토한 뒤에 실제 프로젝트에 적용하고 테스트하는 과정은 분명히 간소화될 수 있습니다. -언제나 새로운 기술과 방법들은 버그나 문제점을 만들었지만 이는 가치에 비하면 분명 사소한 것들입니다. 게다가 우리가 경험적으로 알고 있다시피 버그와 문제점들은 언제나 개발자의 가장 친한 친구입니다! 아, 그렇다고 화내지 마세요. :)-
이제 여러분은 이미 만들어 놓은 컴포넌트를 사용하여 보다 빠르게 웹 페이지를 개발할 수도 있고 유지보수를 페이지 기반이 아니라 컴포넌트 기반으로 옮겨갈 수도 있습니다. 혹은 잘 만들어 놓은 컴포넌트를 배포하여 수익을 만들어 낼 수도 있겠죠. 이 모든 것들의 뒤에는 퀩 컴포넌트가 있습니다. 아래의 링크들을 읽어보시고 사용해보시고 적용해보세요. :)
Template는 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다. Template 규격 이전에도 여러가지 형태의 템플릿들이 자바스크립트 라이브러리나 프레임워크를 통해 제공되어 왔습니다만 이번에 템플릿에 대한 표준 규격이 작성됨에 따라 이러한 템플릿 기능을 네이티브 브라우저를 통해 활용할 수 있게 되었습니다.
이 튜토리얼은 템플릿을 어떻게 정의하고 컨텐츠와 연동할 수 있는지 설명합니다. 이로써 HTML5Rocks에 올라온 웹컴포넌트 관련 튜토리얼은 전부 번역되었으므로 아직 읽어보지 않으신 분들은 참조 링크에서 웹 컴포넌트에 관련된 내용을 일독해보시기를 권해드립니다.
"캡슐화된 컴포넌트를 정의하여 문서 내에서 재사용하고 요구사항에 따라 컴포넌트의 내부를 깨뜨리지 않으면서 확장할 수 있습니다. 계속해서 말씀드리지만 웹 컴포넌트는 프론트엔드에 있어 2014년에 빠질 수 없는 가장 중요한 개념 중의 하나가 될 것입니다."
TL;DR;
이 튜토리얼은 Template의 개념과 Template를 선언하고 컨텐츠를 적용하여 DOM을 런타임에 손쉽게 생성할 수 있도록 합니다.
템플릿은 뷰를 위한 기반 구조로 사용되는 미리 작성된 형식의 문서나 파일입니다. 즉, 형식(Format)를 한번 정의한 뒤 재사용하도록 하여 (마크업의 작성이나 런타임 마크업 생성 모듈과 같은) 추가적인 개발 작업으로부터 개발을 간편하게 만들어줍니다.
템플릿의 개념은 웹 개발에 있어 새로운 것은 아닙니다. 서버 측에서의 템플릿 활용뿐만 아니라 클라이언트에서도 우리가 주로 사용해오던 여러가지 방법들이 이미 존재합니다. "오프스크린" 상에서 DOM을 생성하고 이를 hidden 속성이나 display:none을 사용하여 뷰로부터 이를 감추는 오프스크린 DOM은 브라우저에서 제공하는 다양한 기능을 활용하여 템플릿을 구현할 수 있지만 문서 내의 다른 DOM에 영향을 주는 등의 부작용을 가지고 있습니다. 반대로 <script>를 오버로딩하고 <script>의 컨텐츠를 문자열로 처리하는 스크립트 오버로딩은 렌더링 이슈 및 비활성화를 해결하고 있으나 .innerHTML의 사용을 필요로 하고 이로 인한 보안 취약성이 존재합니다.
WhatWG HTML Templates 표준규격은 템플릿을 위한 표준적인 DOM 기반의 접근 방법을 기술하는 새로운 엘리먼트인 <template>를 정의하였으며 템플릿 컨텐츠는 사용시까지 비활성화되어 렌더링되지 않고 템플릿 안의 스크립트나 DOM이 다른 곳에 영향을 미치는 부작용이 없습니다. 선언/재활용 역시 마찬가지이며 또한 적용 위치 역시 자유롭기 때문에 많은 부분에서 활용이 가능합니다.
보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.
번역 링크
HTML's New Template Tag: standardizing client-side templating
"HTML5이 도입되면서 서버에서 클라이언트로 이동한 것은 단지 로직만이 아닙니다. 데이터 저장소 역시 클라이언트로 범위를 확대하였습니다. 이러한 클라이언트 측의 데이터는 브라우저가 관리하는 공간 속에 저장됩니다. 또한 다양한 액세스 방법은 적합한 방식을 개발 중에 선택할 수 있도록 하였습니다. 그러나, 이러한 저장소는 웹 앱 입장에서 보면 브라우저에 의해 컨트롤되고 있으며 이에 의한 다양한 제한점이 존재하기 때문에 이에 대한 숙지가 필요합니다."
TL;DR;
HTML5 이전에 사용자의 데이터를 저장하기 위해 쿠키를 사용하는 것 이외에는 대안이 없었지만 HTML5의 가장 큰 혁신 중 하나는 브라우저 상의 영구적인 저장소를 제공한다는 것입니다.
HTML5의 시대가 오면서 웹 어플리케이션이 점점 더 풍부해짐에 따라 더 많은 개발자가 브라우저 측의 스토리지를 사용하고 있습니다. 그러나 다양한 한계를 비교하는 중요한 연구가 이루어지고 있지 않으므로 개발자가 이를 극복하기 위한 시간이 소요됩니다. 이 튜토리얼은 다양한 브라우저에 대한 스토리지 상의 제한점들과 이를 측정하는 방법에 대해 다루고 있습니다.
이 튜토리얼에서 다루는 대상 스토리지는 다음과 같습니다.
WebStorage
키-값(Key-Value) 기반의 API를 제공하며 일반적으로 가장 많이 사용됩니다. (익히 아시다시피 WebStorage는 반영구적으로 저장 가능한 LocalStorage와 세션이 연결된 동안만 사용할 수 있는 SessionStorage로 나뉘어집니다.)
WebSQL Database
브라우저를 위한 관계형 데이터베이스(RDB)를 제공합니다. 실제 WebSQL은 W3C에서 표준화 진행을 중단한 상태이지만 현재까지는 브라우저에서는 사용이 가능한 상태입니다.
Indexed Database
자바스크립트 객체가 저장가능하고 이를 기반으로 한 인덱스 처리가 가능한 새로운 규격입니다. 점진적으로 이에 대한 지원 및 사용이 확장될 것입니다.
FileSystem API
웹을 위한 파일 시스템입니다. 개발자는 샌드박스 형태로 사용자의 파일 시스템을 사용할 수 있으며 이를 URL 형태로 직접 참조할 수도 있습니다. 현재 크롬과 오페라만 이를 구현하고 있지만 표준화는 순조롭게 진행 중입니다.
Application Cache
단일 페이지 어플리케이션을 위한 강략한 캐쉬 메커니즘을 제공합니다. 그러나 많은 제한점으로 인해 ServiceWorker로 불리는 표준 규격이 이를 대치할 예정입니다. 현재(2014, Jan.)까지 이를 제외하면 진정한 오프라인 웹앱 솔루션은 없다고 해도 과언이 아닙니다.
이전에도 시간을 이용하여 성능을 측정하는 방법은 있었지만 실제로 스크립트의 설정과 시간 관련 API 들의 제한으로 인해 자세하고 정확하게 측정하기는 어려웠습니다. 이를 해결하기 위해 W3C에서는 High Resolution Time Stamp라는 타입을 추가하였고 이제 모던 브라우저에서 이를 사용할 수 있는 User Timing API이 구현되어 있습니다.
이 튜토리얼은 사용자가 페이지의 로딩, DOM Ready, Navigation 시간 등이나 사용자가 지정한 지점 간의 시간을 측정하기 위한 Timing API를 다루고 있습니다. 이번 번역은 한순보님께서 수고해주셨습니다. :)
"Performance API는 개발자가 직접 측정하기 어려운 페이지 로딩 시간 등을 조회할 수 있도록 해주며 개발자가 직접 지정한 지점을 표시(.mark() 함수)하고 이를 측정(.measure() 함수)할 수 있도록 해주는 등의 스크립트 수준에서의 성능 측정 방법을 제공합니다. Performance API를 이용하면 로딩, 렌더링부터 함수 혹은 특정 실행 사이클을 가지는 모듈의 측정 등 다양한 형태로도 활용할 수 있는 가능성이 있습니다. 프로젝트에서 개발자도구만으로 측정할 수 없는 부분이 있다면 Performance API를 개발 작업흐름 내에 포함하는 것도 좋은 방법이 될 것입니다."
TL;DR;
최적화에 있어서 가장 첫번째 단계는 병목 지점을 찾아내기 위한 측정(Measure)입니다. 반대로 이야기하자면 측정이 없다면 단지 경험과 시간을 사용하여 수정하고 테스트하는 반복적인 과정을 피할 수 없습니다. 물론 개발자 도구에서 렌더링이나 리소스에 대한 로딩 타임들을 측정할 수 있지만 이는 우리의 프로젝트에서 일부에 불과합니다.
User Timing API는 이렇게 도구에서 지원하지 않는 코드 상의 측정을 위한 기능들을 다음과 같이 제공합니다.
(Perfomance API는 아래에서 언급하는 내용 이외에도 Navigation에 대한 정보 그리고 Chrome의 경우 여기에 메모리 사용량도 지원하지만 이 튜토리얼에서는 다루지 않습니다.)
고해상도 시간(High Resolution Time)
W3C의 규격에서 High Resolution Time이란 밀리초(msec) 이하의 시간 단위를 말합니다. 이는 보다 정밀한 시간 측정이 가능하므로 아주 짧게 실행되는 코드에 대한 반복적인 실행 없이 시간 측정이 가능한 것을 뜻합니다.
사용자 타이밍 인터페이스(User Timing Interface)
기본적으로 사용자 타이밍 인터페이스는 개발자가 직접 측정하기 어려운 URL 요청, 응답, 페이지 로딩 시간, DOM 로딩, 완료 등에 대한 지점(Mark)를 기본으로 포함합니다.
[그림] performance.timing이 가진 기본 Mark들
User Timing API는 사용자 타이밍 인터페이스의 기본 지점과 사용자가 직접 지점을 설정 및 해제할 수 있으며 이를 기반으로 하는 측정 시간과 데이터 액세스 기능을 제공합니다.
설정 및 해제
.mark()/.clearMarks() : 사용자 지점 설정/해제
.measure()/.clearMeasures() : Mark 간의 시간 측정 설정/해제
데이터 액세스
.getEntriesByType() : 주어진 타입('mark' 혹은 'measure')에 대한 엔트리 반환
.getEntriesByName() : 주어진 이름에 따른 엔트리 반환
이 튜토리얼은 이러한 API의 사용 방법부터 Ajax 호출에 대한 성능 측정 방법에 대해 다루고 있습니다. 보다 자세한 내용은 튜토리얼을 참고하시기 바랍니다.
웹 컴포넌트 관련 튜토리얼마다 말씀드리는 내용입니다만 Shadow DOM 역시 이전의 Custom Element나 HTML Imports처럼 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다. Shadow DOM은 DOM에 대한 캡슐화(Encapsulation)와 같은 매우 강력한 기능을 제공합니다. HTML5Rocks에는 다음과 같이 Shadow DOM에 대한 3개의 튜토리얼이 업데이트되어 있습니다.
Shadow DOM 101 - Shadow DOM의 기초적인 개념 및 구조
Shadow DOM 201: CSS and Styling - Shadow DOM의 CSS 규칙 적용 및 스타일화 방법
이 튜토리얼은 Shadow DOM를 사용할 때 캡슐화된 DOM 내의 스타일과 호스트 문서로부터의 스타일 상속 혹은 상속을 재설정하는 방법 등에 대해 설명합니다.
"Shadow DOM이 컴포넌트를 구성하는 DOM을 감추는 역할(encapsulation)뿐만이 아니라 스타일에 대한 캡슐화를 지원함으로써 여러분은 배포된(혹은 배포한) 웹 컴포넌트에 대해 여러분의 스타일을 유지하거나 반대로 사용자의 페이지의 Look&Feel을 상속받아 위화감 없는 스타일을 구성할 수도 있습니다. 이러한 스타일에 대한 캡슐화는 특히 사이트를 구축하는 UI 요소로써는 매우 중요한 속성이 될 것입니다. 더불어 이러한 캡슐화된 스타일을 어떻게 관리할 것인가도 웹 컴포넌트의 사용자들에게는 중요한 지점이 될 것입니다."
TL;DR;
이 튜토리얼은 Shadow DOM 101에서 다뤘던 개념들을 기초로 하여 Shadow DOM의 외양(Look&Feel)을 다루기 위한 몇가지 방법과 개념에 대해 다룹니다.
Shadow DOM은 DOM 자체에 대한 캡슐화(Encapsulation) 외에도 스타일에 대한 캡슐화를 지원하고 있습니다. 이렇게 스타일에 관련된 Shadow DOM의 핵심 기능 중의 하나는 섀도 경계(shadow boundary)입니다. Shadow DOM이 DOM에 대한 캡슐화만 지원하는 것이 아니라 자유로운 스타일 캡슐화를 제공하여 Shadow DOM 내의 스타일을 외부에서 격리시켜 유지하거나 반대로 외부의 스타일을 그대로 상속받아 위화감 없이 페이지의 Look & Feel을 유지할 수도 있습니다.
특히 :host를 이용하여 호스트가 되는 엘리먼트에 따라서 스타일을 다르게 지정하거나 확장하는 것이 가능하며, ^과 ^^ 연결자를 통해 섀도 경계(Shadow Boundary)를 무효화하는 것처럼 Shadow Tree 내의 스타일에 관여할 수도 있습니다. (^은 Hat, ^^은 Cat이라고 부릅니다.) 이러한 섀도 경계를 가로지르는 스타일링의 경우 Shadow DOM의 사용자가 정의한 스타일을 손쉽게 연결할 수 있도록 CSS Variable을 이용한 스타일 연결을 만들어내거나 .resetStyleInheritance 혹은 .applyAuthorStyles를 이용하여 스타일에 대한 상속 적용 여부를 결정지을 수도 있습니다. 또한 Shadow DOM 내에 배포된 노드들의 경우는 의사 엘리먼트(::content)를 이용하여 유연하게 확장할 수 있습니다.
Polymer는 웹 컴포넌트의 놀라운 미래로 가는 하나의 관문입니다. 우리는 사용자 엘리먼트(Custom element)를 쉽게 만들고 구축할 수 있기를 바래왔습니다. 작년동안 팀은 혁신적인 규격에 대한 Polyfill 세트를 위해 열심히 일했습니다. 우리는 그 최상위에 웹 컴포넌트를 더 쉽게 구축하기 위한 편리하고 간편한 라이브러리(sugaring library)를 만들었으며 마지막으로 여러분의 앱에서 재사용할 수 있는 UI와 유틸리티 엘리먼트들의 세트를 공들여 만들고 있습니다. 2013 Chrome Dev Summit에서 저는 Polymer의 각 부분들과 "모든 것이 엘리먼트"라는 마법주문 뒤에 감춰진 철학에 대해 깊이 파고 들어가 보았습니다.
90년대의 웹 페이지 구축은 제한적이었지만 강력했습니다. 단지 곧 없어질 몇가지 엘리먼트를 가지고 있었을 뿐입니다. 강력한 부분이요? ...모든 것이 선언적이었습니다. 이는 자바스크립트의 덩어리 없이도 페이지를 생성하고 폼 컨트롤을 추가하고 "앱"을 생성하는데 놀라울 정도로 간편했습니다.
겸손하기 그지없는 <select> 엘리먼트를 보세요. 여기에는 엘리먼트 내에 구축된 엄청나게 많은 기능이 있으며 다음과 같이 그를 정의하는 것으로 간편하게 사용할 수 있습니다.
HTML 속성들을 통한 사용자화(Customizable)
속성을 통해 설정 가능한 기본 UI를 사용한 자식들(예. <option>)의 렌더링
<form> 같은 다른 컨텍스트 내에서의 활용성
DOM API: 속성들과 메소드들
흥미있는 것이 발생했을 때의 이벤트 전달
웹 컴포넌트는 이러한 웹 개발의 전성기로 되돌아가기 위한 도구를 제공합니다. <select>를 연상시키지만 2014의 사례를 위해 디자인된 새로운 엘리먼트를 생성할 수 있는 것입니다. 예를 들어 AJAX가 오늘날 발명되었다면 아마도 다음과 같은 HTML 태그가 될 것입니다. (예제)
이는 Polymer에서 우리가 취하고 있는 정확한 접근 방법입니다. 단일한 덩어리로 된 자바스크립트 기반의 웹앱을 구축하는 대신 재사용가능한 엘리먼트를 생성해봅시다. 시간이 흐르고나면 전체 앱을 작은 엘리먼트들로 구성하도록 성장할 것입니다. 그리고 전체 앱은 다음과 같이 하나의 엘리먼트가 될 수도 있습니다.
만약 웹 컴포넌트 뒤의 표준을 내밀지 않았다면 제가 태만한 탓입니다. 결국 Polymer는 이러한 혁신적인 기초 API들에 기반하고 있습니다.
지금은 웹 개발의 매우 흥미진진 시기인 듯 합니다. 웹 플랫폼에 추가되는 다른 새로운 기능과는 달리, Web Components를 구성하는 API들은 눈부시거나 사용자를 대상으로 하고 있지 않습니다. 이들은 순수하게 개발자 생산성을 위한 것입니다. 4가지 API 각각이 그 자체로 유용하지만 함께 사용하면 마법과도 같은 일이 벌어집니다!
최상위 1000개 사이트에 대해 모바일 친화 여부에 대한 분석 후에 우리는 다음과 같은 몇가지 문제 영역을 발견했습니다. 53%는 여전히 데스크탑만으로 체험을 제공하고 있으며 82%의 사이트는 모바일 디바이스와의 상호작용에 대한 이슈들을 가지고 있고 64%의 사이트들은 사용자들이 읽는데 문제가되는 텍스트를 가지고 있습니다.
사용자들은 접근성에 대한 넓은 범위의 각기 다른 요구사항을 가지는 아주 많은 디바이스를 통해 여러분의 사이트와 서비스에 접근할 것입니다. 올바른 시멘틱 엘리먼트들과 올바른 ARIA 역할들의 사용에 의해 브라우저과 보조적인 기술들이 여러분의 페이지를 이해하는데 많은 개선을 할 수 있도록 도와줄 수 있습니다.
우리 모두는 개발자들이 웹뷰를 사용한 구축 시 제한된 HTML5 기능, 디버깅 도구의 부재, 빌드 도구의 부재와 같은 문제들을 예전에 가지고 있었음을 알고 있습니다. 안드로이드 4.4(KitKat)의 Chromium powered WebView의 소개를 통해 이제 개발자들이 웹뷰를 사용하여 훌륭한 네이티브 앱을 개발하기 위한 거대한 범주의 새로운 도구들을 가지게 되었음을 알리고자 합니다.
웹뷰는 크롬에서 사용하는 것과 동일한 도구로 완전한 리모트 디버깅을 지원합니다. 또한 Grunt를 사용한 믿을 수 있는 웹 개발 워크플로우를 가지게 되었으며 이를 Gradle을 통해 여러분의 네이티브 도구 스택에 통합할 수 있습니다. 통합된 세계들에 더 깊게 들어가, 여러분의 네이티브 코드를 자바스크립트로 테스트하기 위해 크롬 개발자도구를 사용할 수 있는 현명한 기법들을 살펴봅니다.
우리가 데스크탑, 모바일, 태블릿, 웨어러블 그리고 다른 형태의 디바이스에 대한 개발을 해야한다면 어떻게 덜 스트레스를 받도록 워크플로우를 최적화할 수 있을까요? 여기 LiveReload, Grunt, Yeoman 그리고 새롭게 베일을 벗은 Mini Mobile Device Lab을 통해 빠르게 반복적인 작업을 처리할 수 있는 튼튼한 멀티디바이스 접근방법이 있습니다. 만약 테스트하고자 하는 실제 디바이스가 없다면 클라우드를통해 이를 가능하게 하는 몇몇 서비스 제공자들이 있습니다.
이 토크로부터 우리는 Jake는 프리젠테이션할 때 신발을 신지 않고 Business Kinlan은 곧 발매될 새로운 책을 가지고 있으며 오프라인이 되는 것은 브라우저 벤더들에게 심각하게 받아들여지고 있고 여러분은 곧 오프라인 시에도 잘 동작하는 훌륭한 체험을 구축할 수 있도록 도와줄 도구들을 손에 쥐게 될 것이라는 많은 사실들을 배울 수 있습니다. :)
