2015년 1월 6일 화요일

[튜토리얼/한글화] 서비스워커 소개: 서비스워커는 어떻게 사용하는가(Introduction to Service Worker: How to use Service Worker)

올해 첫 번역 소식이네요. 새해 복 많이 받으세요. :) HTML5Rocks에 +Matt Gaunt의 '서비스워커 소개: 서비스워커는 어떻게 사용하는가(Introduction to Service Worker: How to use Service Worker)' 한글 튜토리얼이 업데이트되었습니다. :)

"현재의 네이티브 앱들의 기능과 유사한 형태의 웹 어플리케이션을 구현할 때 가장 난해한 부분은 어떤 것일까요? 아마 그래픽스, 성능, 네트워크 등 다양한 의견이 나오리라 생각됩니다만, 단언컨데 현재 가장 어려운 부분 중의 하나는 오프라인입니다. 서비스워커는 브라우저 측에서 동작하는 이벤트 기반의 시스템 Worker입니다. 이를 이용하여 오프라인 앱을 위한 리소스 관리, 원격 푸시 등을 직접 관리할 수 있습니다. 네이티브 어플리케이션에서는 일반화되어 있는 개념이기도 하지만 기존의 웹 개발에 익숙한 분들에게는 생소한 접근일 수 있습니다만 반드시 알아두어야 할 기능이라고 할 수 있겠습니다."



TL;DR;


초기부터 웹은 다양한 서버에 저장되어 있는 문서를 연결하기 위해 요청(Request) 및 응답(Response)의 메커니즘을 기반으로 동작하도록 설계되었습니다. 다시 말해 서버와 클라이언트가 네트워크를 통해 리소스를 송수신하도록 처리하고 있으며, 이 때문에 웹 페이지 자체의 성능 외에도 근본적으로 오프라인을 기반으로 하는 실행 환경은 아닌 것입니다.

서비스워커는 1차적으로는 이러한 오프라인의 문제를 해결하기 위한 시작점입니다. 물론 서비스워커가 해결하고자 하는 문제의 범위는 이보다 더 넓습니다. 오프라인은 시작일 뿐이지만 비유하자면 네이티브 어플리케이션의 동작 흐름을 웹으로 가져오기 위한 가장 중요한 기능이라고 할 수 있겠습니다.

이 튜토리얼에서는 서비스워커를 이용하여 브라우저의 캐시 시스템을 생성하고 관리하는 방법과 이를 통해 웹 페이지에서 사용하는 모든 리소스에 대한 오프라인 동작을 수행하는 방법을 알아봅니다.

> 서비스워커란


서비스워커는 웹페이지나 사용자 인터랙션이 필요하지 않은 기능들을 위한 기회를 제공하고, 웹페이지와는 별개로 여러분의 브라우저에 의해 백그라운드에서 실행되는 스크립트 기반의 워커(Worker)입니다.

이 기능은 앞으로 여러가지 연동 기능을 예정하고 있으며 네트워크 요청을 가로채고, 응답을 조작하기 위한 프로그래밍 가능한 캐시를 제어할 수 있는 기능을 현재 크롬에서 제공합니다. 

> 서비스워커의 생명주기


서비스워커는 웹페이지와 완전하게 별개인 생명주기(Life Cycle)를 가지고 있으며, register를 통해 백그라운드에서 서비스워커의 설치 과정을 시작합니다.

설치 과정에서 리소스를 캐싱하고자 할 때 모든 파일이 성공적으로 캐싱되고 나면 서비스워커는 설치 상태가 되지만 만약 어떠한 파일이라도 다운로드나 캐싱에 실패한다면, 설치 과정 역시 실패하고 서비스워커는 활성화되지 않습니다.

설치가 이루어졌을 때 이어서 활성화 단계가 수행되며, 이는 우리가 서비스워커 갱신하기 섹션에서 다룰 기존 캐시의 관리를 위한 시점으로 활용할 수 있습니다.

활성화 단계 후에 서비스워커는 페이지가 등록한 서비스워커는 범주(scope) 내에 닿는 모든 페이지를 제어하게 되며 페이지로부터 네트워크 요청이나 메세지가 생성될 때 발생하는 fetch와 message를 제어하게 됩니다.


단순화한 서비스워커의 생명 주기

> 서비스워커를 사용하기 위한 몇 가지 사항


서비스워커는 지대한 영향을 줄 수 있는 서비스워커 모듈의 신뢰성을 위해 HTTPS 기반으로만 동작합니다. 또한, 현재 시점에서 캐시 시스템은 폴리필을 통해서만 사용할 수 있습니다.

자세한 내용은 튜토리얼을 참조하시기 바랍니다.


번역 링크

2014년 11월 13일 목요일

[튜토리얼/한글화] 브라우저 내장 반응형 이미지(Built-in Browser Support for Responsive Images)

HTML5Rocks에 +Pearl Chen의 '브라우저 내장 반응형 이미지(Built-in Browser Support for Responsive Images)' 한글 튜토리얼이 업데이트되었습니다. :)

"브라우저의 해상도, 지원 환경에 따른 반응형 이미지는 그간 CSS와 JavaScript를 통해 지원되어 왔습니다. 크롬 브라우저 38버전부터 새로운 <picture> 엘리먼트를 통해 이를 CSS나 JavaScript의 도움 없이 구현할 수 있는 방법이 제공됩니다. 이러한 의존성으로부터 화면의 스타일과 이미지 콘텐츠를 분리함으로써 다양한 환경에 반응하는 이미지 리소스를 자연스럽게 HTML 마크업에 포함시킬 수 있게 되었습니다. 이는 콘텐츠에 집중하도록 설계된 HTML의 개념이나 접근성에 있어서도 매우 중요한 한걸음입니다."

p.s. 이미 한달 전에 Live한 글입니다만, WebFundamentals 번역과 더불어 일신 상의 변화로 인해 정말 오랜만에 업데이트 소식을 올립니다. :)


TL;DR;


<picture> 엘리먼트는 이미지 리소스 로딩에 대한 선언적 형태의 접근을 제공합니다. 웹 개발자들은 더 이상 반응형 디자인에서 이미지를 제어하기 위해 CSS나 자바스크립트 핵(Hack)들을 필요로 하지 않을 것입니다.

네이티브 수준에서 최적화된 이미지 리소스의 활용은 로딩이 느린 모바일 상에서 더 중요할 것이며, <img>과 <picture> 엘리먼트에 새로 추가된 srcset와 sizes 속성은 이미지 리소스에 한해 웹 개발자들에게 보다 많은 유연성을 제공합니다.

이 튜토리얼에서는 깔끔한 HTML 마크업을 작성하고 반응형 디자인과 웹 페이지의 로딩 시간 개선을 위해 브라우저가 다음 중의 아무 시나리오 한가지 혹은 복합적인 형태로 검출하는 동작을 수행하는 방법을 알아봅니다.

> 이미지 로딩 기준의 다양화

이제 여러분이 원하는 다양한 인자를 기준으로 이미지가 로딩되도록 할 수 있습니다. 예를 들어 다음과 같은 기준을 기반으로 이미지가 반응형으로 로딩되도록 할 수 있습니다.


  • 아트 디렉션(Art direction) 기반
    • 현재 스크린 오리엔테이션이나 해상도에 최적화된 이미지를 로드할 경우
  • 디바이스 픽셀 비율(Device Pixel Ratio) 기반
    • 화면의 DPI에 최적화된 이미지들을 로드할 경우
  • 뷰포트(Viewport) 기반
    • 뷰포트의 크기에 대해 반응형으로 이미지를 로드할 경우
  • 이미지 포맷(Image format) 기반
    • 브라우저의 지원 포맷에 따른 이미지를 로드할 경우(e.g. WebP)

브라우저 뷰포트 크기에 대해 반응하는 이미지 로딩


> <source> 엘리먼트들과 함께 사용하기

<picture> 엘리먼트가 제대로 동작하기 위해서는 새로운 속성들이 추가된 <source>의 사용이 필수적입니다. 브라우저는 가장 적합한 이미지 리소스를 로딩하기 위해 속성값을 순서에 따라 힌트로 사용합니다. <source>에는 다음과 같은 새로운 속성을 사용할 수 있습니다.

  • srcset (필수)
    • srcset="kitten.png"와 같이 하나의 이미지 파일 경로
    • srcset="kitten.png, kitten@2X.png 2x"와 같은 픽셀 밀도 기술(Pixel density descriptor)들과 함께 콤마(,)로 구분되는 이미지 파일 경로들의 리스트
    • 기술되지 않았을 경우 1x로 가정됩니다.
  • media (선택)
    • CSS @media 셀렉터에서 일반적으로 확인할 수 있는 모든 유효한 미디어쿼리를 받습니다.
      • e.g. media="(max-width: 30em)"
  • sizes (선택)
    • 너비(width) 서술자
      • sizes="100vw"
    • 너비(width)를 갖는 미디어쿼리
      • sizes="(max-width: 30em) 100vw"
    • 리스트의 마지막 아이템에 콤마(,)로 구분되는 width 미디어쿼리의 리스트
      • e.g. sizes="(max-width: 30em) 100vw, (max-width: 50em) 50vw, calc(33vw - 100px)"
  • type (선택)
    • 지원 MIME 타입
      • e.g. type="image/webp" 혹은 type="image/vnd.ms-photo"

> <picture> 엘리먼트를 지원하지 않는 브라우저를 위한 <img> 사용


브라우저가 picture 엘리먼트를 지원하지 않거나 맞는 source 엘리먼트 태그가 없을 경우 <img> 엘리먼트는 <picture> 내에서 대체 방법으로써 사용할 수 있습니다. 즉, 매칭되는 <source>가 없을 때 <img>도 없을 경우 아무런 이미지도 로딩되지 않습니다.
  • <img>이 마지막 아이템으로 기술되어야 최종적인 선택지로 동작한다는 점에 주의

> 픽셀 밀도 서술자(Pixel density descriptor)


1x, 1.5x, 2x 그리고 3x와 같은 픽셀 밀도 서술자(Pixel density descriptor)들을 사용하여 고해상도 디스플레이 지원을 추가합니다. 새로 추가된 srcset 속성은 <img>와 <source> 엘리먼트 모두에 적용됩니다.

> 대체 이미지 파일 포맷들의 로딩


<source>의 type 속성은 모든 브라우저에서 아마 지원하지 않는 대체 이미지 파일 포맷들을 로딩하는데 사용될 수 있습니다. 예를 들어, 브라우저가 WebP 포맷를 지원한다면 다른 브라우저에서는 JPEG로 처리되는데 반해 다음과 같이 WebP 포맷의 이미지를 제공할 수 있습니다.

자세한 내용은 튜토리얼을 참조하시기 바랍니다.


번역 링크

그외 읽어볼만한 글

2014년 7월 20일 일요일

[튜토리얼/한글화] 크롬 버전 35의 개발자도구 요약(DevTools Digest - Chrome 35)

HTML5Rocks에 +Umar Hansa의 '크롬 버전 35의 개발자도구 요약(DevTools Digest - Chrome 35)' 한글 튜토리얼이 업데이트되었습니다. :)

"크롬 개발자도구는 크롬에서 가장 빠르게 업데이트되는 항목 중의 하나입니다. 35 버전에서의 주요 업데이트는 양이 많지는 않지만 에디팅 기능, 네트워크 리소스에 대한 필터링, 이벤트 리스너 및 기타 편집 편의 기능들이 제공됩니다."



TL;DR;


본문의 내용이 길지 않으므로 이번 업데이트에 대한 요약은 전반적으로 추가된 기능에 대해서만 정리합니다.

> 네트워크 패널 필터링


도메인(Domain)과 같은 확실한 필드들을 통해 리소스들을 필터링할 수 있습니다. 또한 타이핑하고 있는 쿼리들에 대해 실시간의 유효한 필터 값들을 제안하는 자동완성 기능 역시 지원됩니다.

> Shadow DOM 컨텐츠 편집


개발자도구는 Element 패널 내에서 정규적인 HTML의 수정이 항상 가능했으며, 이러한 기능들은 이제 Shadow DOM의 엘리먼트 부분까지 확장되었습니다.

> CodeMirror 4.0으로의 업그레이드


자바스크립트 기반의 텍스트 에디터로써 Source 패널의 일부분으로 사용되고 있는 CodeMirror가 버전 4로 업그레이드되었습니다. 키보드 단축키를 포함한 많은 새로운 기능들이 추가되었습니다.

> CSS 속성의 빠른 검색


이제 Style 패널의 새로운 검색 상자에서 속성 이름들이나 룰 셀렉터들을 검색할 수 있습니다. 결과물은 여러분이 타이핑하고 있는 쿼리에 대해 실시간으로 강조처리됩니다.

> 콘솔 메세지에 대한 타임스탬프


로그 메세지들이 빠르고 연쇄적으로 발생하는 경우 메세지가 출력된 정확한 시간을 확인할 수 있는 것은 유용할 것입니다. (개발자도구 실험실 기능)

> 힙 스냅샷에 대한 통계적 메모리 명세


기록된 힙 스냅샷을 볼 때 자바스크립트의 관점에서 어떠한 부분이 대부분의 메모리를 소모하는지를 확인하기 위한 시각적이고 컬러화된 통계 파이 차트를 확인할 수 있습니다. 현재 실험실 기능이므로 “Heap snapshot statistics”의 활성화를 통해 확인할 수 있습니다.

> console.log의 Wrapping version이 아닌 원본 소스 보기


여러분은 아마도 console.log의 래퍼 함수(Wrapper function)을 가지고 있을 때 개발자도구는 원래 위치를 가지고 있습니다.

> 작지만 강력한 추가 기능들


  • Element 패널 내에서 Event Listeners 새로고침 후 이벤트 리스너의 추가/삭제 가능
  • Ctrl + ` 를 이용한 콘솔 입력에 포커스 설정
  • border- 스타일의 자동완성 지원
  • Restore defaults and reload(초기화 및 갱신) 버튼이 Setting 패널에 추가
  • dock to left(왼쪽으로 도킹하기)를 적용 가능(실험실 기능)
  • "Wheel"을 이벤트 리스너의 중단점(breakpoint)으로 추가


자세한 내용은 튜토리얼을 참조하시기 바랍니다.

번역 링크

[튜토리얼/한글화] requestAutocomplete - take my money, not my time

HTML5Rocks에 +Jake Archibald의 'requestAutoComplete - 시간 빼았지 말고 돈이나 가져가시죠(requestAutocomplete - take my money, not my time)' 한글 튜토리얼이 업데이트되었습니다. 이번 번역은 박태근님께서 수고해주셨습니다. 진작 소개를 해드렸어야 하는데 이런저런 일로 바빠서 이제야 소갯글을 올리는군요. 이해해주시길 :)

"웹에서의 폼 입력의 많은 부분이 동일한 데이터를 반복적으로 입력하기를 요구합니다. 특히 쇼핑몰에서의 결제가 그렇습니다. 카드 번호를 입력하고, 배송될 주소를 입력하고 전화번호를 넣고, 다음 이용 시에도 그렇습니다. 이는 사용자 입장에서는 무척 짜증이 나는 일이죠. 물론 일부 사이트는 최근의 입력 데이터를 제공해주기도 하지만 이는 서버 측에서의 구현이 필요할 뿐만이 아니라 보안상의 취약점이 발생할 수 있는 부분이기도 합니다. 
requestAutoComplete()는 기존의 입력 데이터를 서버 혹은 보안상 취약한 형태로 자바스크립트에서 접근 가능한 브라우저의 웹 스토리지 내에 저장하지 않고 브라우저로부터 바로 채워서 전달할 수 있는 편리한 기능입니다. 만약 서버측의 구현 이슈나 보안 이슈가 있었다면 requestAutoComplete()를 이용해서 사용자에 편리한 환경을 제공해보는 것은 어떨까요?"



TL;DR;


모바일 웹에서 최대 97%의 확률로 카트를 다 채워놓고 결제를 포기하는 행위가 일어납니다. 당신이 웹상에서 경험할 수 있었던 행복한 결제 경험에 대해서 생각해보세요. 이것은 큰 문제입니다. 웹의 한계는 웹사이트들이 이미 사용자들이 계정을 가지고 로그인할 수 있는 특정 결제 대행사에 예속되게 하거나 대개 해당 플랫에 맞추어서 코딩하도록 강제되는 단일 플랫폼들, 가령 앱스토어에 종속되도록 하므로 이러한 경험은 고쳐져야만 합니다.

form.requestAutoComplete


이 API는 상세한 결제 정보를 브라우저에서 요청하고, 사용자 환경(여기서는 아마 브라우저)에 저장합니다. 크롬 버전의 requstAutocomplete()은 또한 미국 사용자에 한해서 (현재로써는) 구글 월렛과도 연동됩니다.

form 요소는 단 한가지의 새 메소드, 바로 requestAutocompltete를 가지며 그 기능은 브라우저에게 form을 채우도록 요청하는 것입니다. 브라우저는 사용자에게 허가와 어떤 정보들을 제공할것인지 묻는 대화창을 나타낼 것입니다.

당신이 이것을 원하는 때 언제나 불러올 수 있는 것은 아닙니다. 이 메소드는 특정한 인터랙션 이벤트들, 가령 마우스 업/다운, 클릭, 키보드 & 터치 이벤트들이 일어나는 도중 불러져야 합니다. 이것은 보안을 위해서 의도적으로 만들어진 제한사항입니다.

이제 name 항목을 변경하지 않고도 field에 채워질것으로 예상되는 항목을 정의할 수 있습니다. 그리고 이것이 바로 requestAutocomplete가 form을 사용자 데이터와 연결하기 위해서 사용하는 방법입니다.



규격 상으로, requestAutocomplte가 한 종류의 결제방식에 대해서만 동작하는 것은 아니지만 현재 Chrome에 구현된 것은 그렇게 구현되어 있는 상태입니다. 결제를 예로 들자면 일반적인 흐름은 다음과 같습니다.

requestAutoComplete()를 이용한 결제의 흐름

주의: 현재로써는 requestAutocomplete가 결제 기능에만 초점이 맞추어져 있기 때문에 <form>에 적어도 하나의 신용카드 관련 필드를 포함하는것이 필요하며, SSL로 암호화된 페이지들에 대해서만 동작합니다. 대신 개발 과정에서 크롬은 requestAutocomplete가 실패하는 정확한 이유를 개발자 콘솔에 로그로 나타내어줍니다.

현재 크롬에서 requestAutocomplete는 특정한 몇가지 필드에 대한 포함을 요구하거나 인식 가능한 필드가 별도로 정의되어 있습니다. 자세한 내용은 튜토리얼을 참조하시기 바랍니다.

번역 링크

2014년 5월 22일 목요일

[튜토리얼/한글화] Object.observe()를 통한 데이터바인딩 혁신(Data-binding revolutions with Object.observe())

HTML5Rocks에 +Addy Osmani의 'Object.observe()를 통한 데이터바인딩 혁신(Data-binding revolutions with Object.observe())' 한글 튜토리얼이 업데이트되었습니다. 아직 사이트에 라이브되지는 않았습니다만 곧 라이브가 될 것으로 예상되고 원문과 비교하면서 읽으셔도 이해에 큰 무리는 없을 것으로 판단되어 미리 업데이트합니다. :)

이 튜토리얼은 Chrome 35 버전부터 포함되는 Object.observe()에 대한 기초적인 설명부터 이를 데이터 바인딩으로 확장하는 구현 사례, 성능에 대한 분석을 담고 있습니다.

"데이터 바인딩은 흔히들 얘기하는 데이터(혹은 모델) 레이어와 표현 레이어를 분리하는 편리하고 강력한 개념이자 방법이며 이미 꽤 오랜동안 그리고  대다수의 프레임워크에서 데이터 바인딩을 지원하고 있습니다.
특히 데이터 바인딩에서 양방향 혹은 데이터의 변경을 자동으로 추적하여 뷰를 업데이트하는 방법은 데이터(정확히는 객체나 객체 내의 속성, 프로토타입 등)에 대한 관리 외에 UI까지 신경써야 하는 개발 과정을 크게 단순화시켰습니다만 이를 지원하기 위해 지속적으로 UI와 연결(Binding)된 데이터에 대한 추적을 지원해야 하며 경우에 따라서는 바인딩을 유지하기 위한 별도의 프로그래밍 방법이 필요한 경우도 있었습니다. ECMAScript7에서 추가된 .observe() 메소드는 이러한 데이터를 추적하기 위한 방법을 순수 스크립트 객체까지 확대하였습니다.
데이터의 변경을 추적하거나 기존 프레임워크에서 데이터 바인딩을 유지하기 위한 실행 비용이 부담스러웠다면 이 튜토리얼에서 observe()에 대한 이해를 통해 힌트를 얻어보시기 바랍니다."



TL;DR;


ECMAScript 7에 정의되고 Chrome 36 베타부터 탑재된 Object.observe() 메소드는 데이터 바인딩(data-binding)과 가장 밀접하게 관계된 새로운 자바스크립트 추가 기능입니다. 이는 MVC 라이브러리들에서 사용하는 감시 모델(Observing Model)에 대한 구현 방식을 획기적으로 전환할 기능이기도 합니다.

자바스크립트에서 객체에 대한 데이터 감시(Observation)의 대상은 보통 다음과 같습니다.

  1. 순수한 자바스크립트 객체들에 대한 변경
  2. 속성(Property)들이 추가, 변경되거나 삭제되었을 때
  3. 배열들이 가진 요소(Element)가 합쳐지거나 나누어졌을 때
  4. 객체의 프로토타입에 대한 변경

Object.observe()- 이하 O.o() -는 별도 라이브러리 없이 자바스크립트 객체들의 변경을 비동기적으로 감시하기 위한 방법입니다. 이는 객체들에 대한 일련의 변경 사항들을 변경이 일어난 시간 순서에 따라 전달받을 수 있는 감시자(감시 객체, Observer)를 통해 프레임워크나 라이브러리에 구현되어 있는 객체 감시 방법들에 대한 성능 개선 효과와 동일한 API를 유지하면서도 빠르고 단순한 구현을 제공하며 별도의 프레임워크 없이 양방향 데이터 바인딩을 구현할 수 있습니다.


> 데이터 바인딩의 중요성과 최근까지의 방법들


데이터 바인딩의 가장 큰 장점은 모델-뷰-컨트롤의 분할입니다. 데이터 바인딩은 복잡한 사용자 인터페이스가 데이터 모델들 내에 있는 여러 개의 속성들과 뷰들 내의 여러 엘리먼트들 간의 관계를 연결하여야 하는 곳에 있을 때 특히 유용합니다. 이는 데이터를 DOM으로부터(그리고 DOM으로) 어플리케이션의 내부 혹은 외부와의 동적인 연결을 제어하는 반복적인 코드 작성 시간을 크게 절약합니다.

최근까지 프레임워크 등에서 널리 쓰인 Dirty-checking의 경우 객체의 변경을 추적하기 위한 방법을 제공합니다만 대체적으로 동작 비용이 감시되는 객체들의 전체 숫자에 비례하여 성능과 관련된 문제가 존재하고 서버로부터 받은 데이터를 이들 객체로 변경하는 작업들이 개발자에게 요구됩니다.

O.o()는 브라우저 내의 데이터를 자체적으로 감시하기 위한 방법을 구축함으로써 요즘 널리 사용되고 있는 느린 구현 방식에 의존하지 않고 자바스크립트 프레임워크에 모델 데이터의 변경을 감시할 수 있는 방법을 제공합니다.


> Object.observe()


Object.observe()는 순수(Raw) 데이터 객체들(정규 자바스크립트 객체들)의 지원을 통해 데이터를 감시할 수 있으며 항상 모든 것에 대해 Dirty-check를 할 필요가 없는 방법으로 잠재적으로 많은 장점을 가지고 있습니다.

O.o()의 특징을 요약하면 다음과 같습니다.

  • Specifying changes of interest
    • 관심있는 변경 사항들만 사용자가 지정하여 추적하거나 알림(Notification) 개념을 통해 작업
  • Notifications
    • 단위의 마지막(대체적으로는 현재 실행 중인 이벤트 핸들러의 종료 시)에 변경 사항을 받아 효과적인 처리가 가능합니다.
  • Synthetic change record & Accessor properties
    • 기본적으로 접근자의 경우는 내부적으로 함수일 뿐이므로 감시의 대상이 되지는
    • 특정한 접근자 혹은 연산 속성(Computed Property)의 경우에도 필요하다면Notifier.notify() 등을 이용하여 사용자가 객체 내에서 추적이 필요한 경우를 선택적으로 혹은 직접 지정할 수 있습니다.
  • Single callback observers
    • 복수의 객체들에 대해 동시에 동일한 콜백으로 변경을 추적할 수 있습니다. 이는 특히 다양한 객체에 대한 변경이 동일한 기능으로 연결될 때 효과적입니다.
  • Large-scale changes
    • 개별적인 변경 사항을 추적하는 대신에 여러개의 변경 사항을 묶어서 보다 큰 단위 관점에서의 변경을 추적할 수 있습니다. 
  • Array Observation
    • 일반적인 객체 이외에도 배열의 변경 등에 대한 변경을 추적할 수도 있습니다.



> 성능


Dirty-checking은 여러분이 감시하고 있는 모든 객체의 숫자에 성능이 비례하며 (변경의 검출을 위해) 데이터 사본의 유지를 필요로 하지만 O.o()의 경우 변경의 횟수에 성능이 비례하므로 여러모로 성능 상 더 효율적입니다.

Dirty-checking
Object.observe()



> 프레임워크와 Object.observe()


이미 말씀드린 바와 같이 O.o()는 네이티브로 구현된 기능을 통해 프레임워크와 라이브러리에 그들의 데이터 바인딩 성능을 개선할 수 있는 방법을 제공합니다. 만약 O.o()가 지원 가능한 환경이라면 자바스크립트를 이용한 복잡한 프로세스 대신 높은 성능 개선을 기대할 수 있을 것입니다. Angular나 Ember 등의 주요 프레임워크들 역시 이를 지원하거나 지원하기 위한 로드맵을 진행 중입니다.


보다 자세한 내용은 튜토리얼을 참조하시기 바랍니다.


번역 링크

2014년 5월 10일 토요일

[소식] Chrome/Chromium 36 관련 업데이트 미리보기

오랜만에 포스팅을 하는군요. 최근 Google I/O 때문인지 HTML5Rocks의 신규 튜토리얼 등록도 미뤄지고 있고 해서 딱히 업데이트할 내용이 없다는 것이 핑계라면 핑계입니다만, 마침 크롬/크로미움 36 버전의 업데이트 관련한 소식 중에 신나는 것들이 있어서 공유하고자 합니다. :)

"아직 36버전의 공식 업데이트까지 기간이 남았기 때문에 최종 버전이라고 생각하시면 곤란합니다. ㅎㅎ 대신 중요한 추가 항목들이 생기면 이 포스트에 업데이트하도록 하겠습니다."



Chrome/Chromium 36 버전 중요 업데이트 미리보기


개인적으로 36 버전 업데이트에서 눈에 띄는 몇가지는 관심을 가지고 있는 신규 규격들의 적용입니다. 아래에 언급하고 있지 않은 기능 중에서 WebComponents와 같은 규격들에 대한 업데이트도 지속적으로 업데이트되고 있습니다. 올해는 재밌군요. :)


> CSS transform의 Prefix 제거


기존에 CSS transform을 적용하기 위해서는 -webkit-transform: ...처럼 prefix가 포함된 형태로 기술해야 했지만 36버전부터는 transform: ... 과 같이 prefix가 없는 상태로 기술이 가능해집니다. :)



> WebAnimations 자바스크립트 API 추가


Web Animations는 기존의 선언적인 방식에서 벗어나서 자바스크립트를 기반으로 능동적으로 CSS3 Animation 및 Transition, SVG 애니메이션을 처리할 수 있는 새로운 HTML5 규격입니다.

작년 말 Blink 엔진에서 WebAnimations 규격을 지원하기 위한 네이티브 엔진 교체가 이루어졌었습니다만 이때까지는 WebAnimation에서 정의하고 있는 자바스크립트 API가 빠진 상태로 기존 CSS3 애니메이션이 제대로 동작하는지만 확인할 수 있어 별로 차이를 느끼지 못하셨을 겁니다. (아마 엔진이 변경되었다는 사실조차 모르시는 분들이 많으실 것 같네요.)

이제 36버전부터 웹 애니메이션의 API 중 element.animate()가 사용 가능해집니다. 물론 Chrome for Android에서도 마찬가지입니다.



> CSS Will-change


will-change CSS 속성이 추가되었습니다. will-change 속성은 엘리먼트 내의 컨텐츠나 리스팅된 속성이 변경될 수 있음을 브라우저에 알려주는 일종의 힌트와도 같습니다.

단순히 속성 자체로 페이지 상의 변화가 일어나는 것은 아니지만 다양한 방식의 하드웨어 가속을 통해 렌더링이 이루어지는 환경에서는 브라우저의 렌더링이 보다 효율적으로 동작할 수 있도록 해줄 수 있습니다.

이 규격은 초안(Draft) 상태입니다만 크롬 36버전부터 구현되어 있는 상태입니다.



> ServiceWorker 초기 구현


ServiceWorker는 웹 페이지와는 독립적인 생명주기(life-cycle)를 가진 이벤트 기반 시스템으로 SharedWorker의 일종이지만 근본적으로는 어플리케이션과 별개의 스레드를 운용하며 필요하다면 개발자의 캐싱(Caching) 관리가 가능하게 하거나 네트워크를 통한 사용자 요청에 대하여 응답을 제어할 수 있게 되는 등 오프라인 지원을 위한 다양한 (특히 리소스의 제어에 유용한) 기능을 제공합니다.

현재 ServiceWorker 규격 정의가 W3C에서 현재 진행 중이며 데스크톱 크롬 36과 안드로이드용 크롬 36부터 ServiceWorker의 초기 구현이 포함됩니다. 구현 상태와 규격은 아래 사이트에서 참조하시기 바랍니다.

2014년 4월 25일 금요일

[튜토리얼/한글화] 크롬 개발자도구로 비동기 자바스크립트 디버깅하기(Debugging Asynchronous JavaScript with Chrome DevTools)

HTML5Rocks에 +Pearl Chen의 '크롬 개발자도구로 비동기 자바스크립트 디버깅하기(Debugging Asynchronous JavaScript with Chrome DevTools)' 한글 튜토리얼이 업데이트되었습니다. 이번 번역은 한순보님께서 수고해주셨습니다. :)

"콜백에 의한 비동기 처리는 우리에게 성능이라는 한가지 장점과 사소해보이는 몇가지 단점을 같이 선물하였습니다. UI가 동작 중인 메인스레드에서 실행되는 자바스크립트에서 콜백에 의한 비동기 처리는 발생할 수 있는 성능 상의 문제를 해결하기 위한 최선의 방법이었습니다만 성능의 이점 대신 코드 작성은 좀 더 어려워졌고 선형적으로 디버깅할 수 있는 방법은 크게 복잡해졌습니다.  
코드에서 무엇을 어떻게 처리할 것인지는 여러분의 몫입니다만 불행하게도 디버깅 역시 그러하며 특히나 비동기 처리라면 개발 환경을 넘어선 코드에 대한 깊은 이해를 요구하는 경우가 많으며 최근과 같이 외부에서 작성된 자바스크립트 라이브러리들을 사용하는 환경에는 더욱 더 그렇습니다. 
크롬에서 추가된 비동기 자바스크립트에 대한 호출 스택과 왓치(Watch) 기능은 이러한 영역에서의 괴로움을 크게 줄여줄 것입니다."



TL;DR;


콜백 함수를 통해 비동기로 동작할 수 있는 능력은 자바스크립트를 특별하게 만드는 강력한 기능이지만 자바스크립트는 순차적으로만 실행되지 않으므로 디버깅 과정에서는 우리를 괴롭게 만듭니다.

다행스럽게도 이제 크롬 카나리 개발자 도구(DevTools)에서 비동기 자바스크립트 콜백이 포함된 호출 스택의 모두를 확인할 수 있습니다. 개발자 도구에서 비동기 콜 스택 기능을 활성화하면 다양한 지점에서 각 지점에서의 상태를 자세히 볼 수 있으며 스택을 추적해 가면서 런타임 실행에서 특정 지점의 어떤 변수 값을 분석할 수도 있습니다.


[그림] 크롬 개발자도구의 비동기 호출 스택 추적

현재 개발자 도구에서 호출 스택을 확인할 수 있는 비동기 콜백의 종류는 다음과 같습니다.

  • 타이머: setTimeout()이나 setInterval()의 초기화 지점으로 이동합니다.
  • XHR: xhr.send() 호출 지점으로 이동합니다.
  • 애니메이션 프레임: requestAnimationFrame의 호출 지점으로 이동합니다.
  • 이벤트 리스너: 이벤트와 addEventListner()의 최초 바인딩 지점으로 이동합니다.
    • addEventListner()는 성능 문제로 인해 개발자도구의 추적대상에서 제거되었습니다.
  • MutationObserver: Mutation Observer 이벤트의 지점으로 이동합니다.


아래의 자바스크립트 API는 곧 이 기능을 지원할 예정입니다.

  • Promise: Promise가 해결된(resolved) 위치로 이동합니다.
  • Object.observe: 옵저버(Observer) 콜백을 처음에 바인딩한 지점으로 이동합니다.


자세한 내용은 튜토리얼을 참조하시기 바랍니다.

번역 링크