2014년 1월 11일 토요일

[업데이트/Summit] 크롬 개발자 서밋: 플랫폼 부문 요약(Chrome Dev Summit: Platform Summary)

Chrome Dev Summit의 플랫폼 부분에 대한 +Seth Ladd의 요약이 업데이트 되었습니다. 요즘 확장을 선언한 Dart로 시작하여 Chrome Apps, PNaCl에 대한 요약입니다. 공통적으로 표준적인 웹 기술은 아닙니다만 반대로 말하면 현재 웹의 보완재에 해당하는 기술이 어떤 것들이 있는지 살펴볼 수도 있겠군요. :)


"HTML5는 순수한 표준 규격으로써의 기술을 일컫기도 하지만 HTML5과 관련된 기술을 통칭하는 개념으로 사용되기도 합니다. 표준된 규격도 중요하지만 상호보완재의 역할은 규격을 기반으로 한 기술의 범위를 넓혀주기도 합니다."




다트(Dart)


다트는 자바스크립트로 컴파일되며 때로는 직접 작성한 자바스크립트보다도 더 빠른 코드를 생성하기도 합니다. 다트의 공동 설립자 캐스퍼 런드(Kasper Lund)가 dart2js 컴파일러가 빠르고 문법적으로 옳은 자바스크립트를 생성하기 위해 지역 및 전역 최적화를 어떻게 수행하는지에 대해 설명합니다. 트리 흔들기(Tree shaking), 형식 추론(Type inference) 그리고 최소화(minification)을 이용하여 다트는 여러분의 웹 앱을 최적화할 수 있도록 도울 것입니다.




크롬 앱스(Chrome Apps)


크롬 앱스는 개발 단순성, 웹의 보안성 및 구글 드라이브 같은 심리스(Seamless)한 구글 서비스들 통해 강력함과 네이티브 앱의 사용자 경험을 제공합니다. 크롬 앱스는 맥, 윈도우즈, 리눅스 그리고 크롬OS뿐만이 아니라 iOS 그리고 안드로이드까지 즉시 사용할 수 있도록 합니다.




포터블 네이티브 클라이언트(PNaCl)


Portable Native Client는 이식성, 네이티브 어플리케이션의 보안서 있는 실행 모델을 크롬에서 가능하게 하는 기술입니다. Native Client 프로젝트에 대한 이러한 확장은 네이티브 코드의 성능과 저수준 제어를 웹의 보안성과 이식성에 대한 희생없이 모던 웹브라우저에서 가능하도록 합니다.

PNaCl은 개발자가 그들의 네이티브 어플리케이션을 플랫폼 독립적인 형태로 생산할 수 있으며 이를 어떠한 설치과정도 없이 웹 브라우저에서 실행할 수 있도록 합니다. 크롬은 네이티브에 근접하는 성능을 달성하기 위해 PNaCl 어플리케이션을 실행 시간에 기계어로 번역합니다. 다른 브라우저에서 PNaCl 어플리케이션은 Emscripten과 pepper.js를 사용하여 최소의 성능으로 기능을 유지할 수 있습니다.


2014년 1월 9일 목요일

[업데이트/Summit] 크롬 개발자 서밋: 성능 부문 요약(Chrome Dev Summit: Performance Summary)

오늘은 +Paul Lewis가 Chrome  Dev Summit의 성능과 관련된 세션들의 요약을 업데이트했네요. 개인적으로도 관심이 많은 영역입니다만 도구화, 렌더링, 네트워크, 모바일에 대한 최적화가 한곳에 있으니 다들 읽어보시면 좋을 듯 합니다. 이전과 마찬가지로 자세한 내용은 전문을 참고하시기 바랍니다.


"성능은 언제나 이슈지요. 그래서 성능 역시 기능입니다."


#perfmatters: 퍼포먼스 닌자를 위한 도구화 기술들


개발도구에 대해 방향을 앎에 있어 요점은 성능의 그랜드 마스터가 되는 것입니다.
+Colt McAnlis는 성능과 관련하여 네트워크, 연산, 렌더링에 대한 3개의 기둥을 다루었습니다.

슬라이드


  • 이제 여러분은 데스크탑에서 알고 사랑해온 크롬 개발자도구를 사용하여 안드로이드 크롬(Chrome on Android)를 프로파일링할 수 있게 되었습니다.
  • 성능 개선은 데이터를 수집하여 검토한 것을 기록하고 액션을 취하는 작업의 반복적인 루프입니다.
  • 페이지에 대해 중대한 렌더링 경로 상의 애셋(Asset)의 우선순위를 결정하세요.
  • 페인팅을 피하세요. 이는 엄청나게 비싼 비용을 소모합니다.
  • 앱 내에서 메모리 변동(Churn)과 임계시간의 코드 실행을 피하세요.

#perfmatters: 네트워크 성능 최적화


네트워크와 지연시간은 일반적으로 사이트의 전체 페이지 로딩 시간의 70%를 차지합니다. 이는 정말 큰 비율입니다만 또한 사용자를 위한 아주 큰 장점으로 뛰어넘는 개선을 만들 수 있다는 것을 의미하기도 합니다. 이 발표에서 +Ilya Grigorik은 절대적인 최소 시간으로 네트워크 부하를 유지하도록 도와주는 환경을 만들도록 해주는 작은 변화뿐만이 아니라 로딩 타임을 개선할 수 있는 크롬에서의 최근 변경들에 대해 다뤘습니다. 


    • Chrome M27은 새롭게 개선된 리소스 스케쥴러를 가지고 있습니다.
    • Chrome M28은 SPDY 사이트들을(조차도) 더 빠르게 만들었습니다.
    • Chrome의 단순한 캐쉬(Simple cache)는 재정비를 받았습니다.
    • SPDY / HTTP/2.0는 전송 속도의 엄청난 개선을 제공합니다. (일단 3가지만 나열하자면) nginx, 아파치 그리고 Jetty에서 사용 가능한 우아한 SPDY 모듈이 있습니다.
    • QUIC은 UDP의 최상위에 구축된 새롭고 실험적인 프로토콜입니다. 아직 초기지만 사용자가 (성능과의 전쟁에서) 승리할 수 있도록 해줍니다.


    #perfmatters: 60fps 레이아웃 및 렌더링


    여러분의 프로젝트에서 60fps에 닿는다는 것은 사용자와의 약속과  프로젝트의 성공에 중대하게 즉각적으로 연관되어 있습니다. 이번 발표에서 +Nat Duca와 +Tom Wiltzius는 크롬의 렌더링 파이프라인에 대해 설명하고 프레임을 떨어뜨리는 몇가지 일반적인 경우와 그를 회피하기 위한 방법을 다룹니다.

    슬라이드


    • 프레임은 16ms입니다. 이는 자바스크립트, 스타일 계산, 페인팅, 합성(Compositing)을 포함하는 과정입니다.
    • 페인팅은 매우 비싼 비용을 소모합니다. 페인팅의 폭풍은 불필요하게 비싼 페인트 동작을 반복합니다.
    • 레이어는 페인팅된 엘리먼트들을 캐싱하는데 사용됩니다.
    • 입력 핸들러들(터치, 마우스휠 리스너들)은 반응성을 죽일 수도 있습니다. 가능하다면 이를 피하세요. 그럴 수 없는 곳에서는 이를 최소화해야 합니다.


    #perfmatters: 즉각적인 모바일 웹앱


    중대한 렌더링 경로(Critical Rendering Path, 이하 CRP)는 페이지 페인팅을 시작할 수 있기 전까지 브라우저가 필요로 하는 어떠한 것(JavaScript, HTML, CSS, 이미지 등)과도 연관될 수 있습니다. CRP에서 애셋의 전달 우선순위를 결정하는 것은 셀룰러 네트워크 상의 스마트폰같이 네트워크가 제한적인 디바이스의 사용자들을 위한 필수적이고 까다로운  것입니다. +Bryan McQuade가 구글의 팀이 어떻게 PageSpeed Insights 웹사이트를 위해 애셋들을 선정과 우선순위의 결정 과정을 진행하는지에 대해 설명하고, 20초의 로딩 시간을 단 1초로 바꿀 수 있었는지에 대해 이야기합니다!

    슬라이드


    • 렌더링을 블록하는 자바스크립트와 CSS를 제거하세요
    • 보여야하는 컨텐츠의 우선순위를 결정하세요.
    • 스크립트는 비동기적으로 로딩하세요.
    • 초기 뷰를 서버 사이드 HTML으로 렌더링하고 이후에 JavaScript로 강화하세요.
    • 렌더링을 블록하는 CSS를 최소화하세요. 초기 뷰포트를 디스플레이하는데 필요한 스타일만 전달하고 그 뒤에 나머지를 전달하세요.
    • 렌더링을 블록하는 CSS 내에서 인라인된 커다란 Data URI들은 렌더링 성능에 치명적입니다. 이미지 URL들이 논-블로킹인 곳에서도 리소스를 블록합니다.

    2014년 1월 8일 수요일

    [업데이트/Summit] 크롬 개발자 서밋: Polymer, 선언적/캡슐화/재사용가능한 컴포넌트(Chrome Dev Summit: Polymer declarative, encapsulated, reusable components)

    작년 Chrome Dev Summit에 대한 +Paul Kinlan모바일 부문 서밋 요약 포스팅에 이어서 바로 +Eric Bidelman이 Web Component에 대한 Polyfill 라이브러리인 폴리머(Polymer)에 대한 발표 요약을 포스팅했습니다. 자세한 내용은 아래를 참조하시기 바랍니다.



    전문


    Polymer는 웹 컴포넌트의 놀라운 미래로 가는 하나의 관문입니다. 우리는 사용자 엘리먼트(Custom element)를 쉽게 만들고 구축할 수 있기를 바래왔습니다. 작년동안 팀은 혁신적인 규격에 대한 Polyfill 세트를 위해 열심히 일했습니다. 우리는 그 최상위에 웹 컴포넌트를 더 쉽게 구축하기 위한 편리하고 간편한 라이브러리(sugaring library)를 만들었으며 마지막으로 여러분의 앱에서 재사용할 수 있는 UI와 유틸리티 엘리먼트들의 세트를 공들여 만들고 있습니다. 2013 Chrome Dev Summit에서 저는 Polymer의 각 부분들과 "모든 것이 엘리먼트"라는 마법주문 뒤에 감춰진 철학에 대해 깊이 파고 들어가 보았습니다.



    "모든 것이 엘리먼트입니다(Everything is an element)"

    - <select>에서 사용자 엘리먼트까지



    90년대의 웹 페이지 구축은 제한적이었지만 강력했습니다. 단지 곧 없어질 몇가지 엘리먼트를 가지고 있었을 뿐입니다. 강력한 부분이요? ...모든 것이 선언적이었습니다. 이는 자바스크립트의 덩어리 없이도 페이지를 생성하고 폼 컨트롤을 추가하고 "앱"을 생성하는데 놀라울 정도로 간편했습니다.

    겸손하기 그지없는 <select> 엘리먼트를 보세요. 여기에는 엘리먼트 내에 구축된 엄청나게 많은 기능이 있으며 다음과 같이 그를 정의하는 것으로 간편하게 사용할 수 있습니다.
    • HTML 속성들을 통한 사용자화(Customizable)
    • 속성을 통해 설정 가능한 기본 UI를 사용한 자식들(예. <option>)의 렌더링
    • <form> 같은 다른 컨텍스트 내에서의 활용성
    • DOM API: 속성들과 메소드들
    • 흥미있는 것이 발생했을 때의 이벤트 전달

    웹 컴포넌트는 이러한 웹 개발의 전성기로 되돌아가기 위한 도구를 제공합니다. <select>를 연상시키지만 2014의 사례를 위해 디자인된  새로운 엘리먼트를 생성할 수 있는 것입니다. 예를 들어 AJAX가 오늘날 발명되었다면 아마도 다음과 같은 HTML 태그가 될 것입니다. (예제)
    <polymer-ajax url="http://gdata.youtube.com/feeds/api/videos/" 
                   params='{"alt":"json"}'></polymer-ajax>

    혹은 다음과 같이 queryMatches 속성으로의 데이터 바인딩을 제공하는 반응형 엘리먼트들이 될 수도 있습니다.
    <polymer-media-query query="max-width:640px" queryMatches="{{isPhone}}"></…
    이는 Polymer에서 우리가 취하고 있는 정확한 접근 방법입니다. 단일한 덩어리로 된 자바스크립트 기반의 웹앱을 구축하는 대신 재사용가능한 엘리먼트를 생성해봅시다. 시간이 흐르고나면 전체 앱을 작은 엘리먼트들로 구성하도록 성장할 것입니다. 그리고 전체 앱은 다음과 같이 하나의 엘리먼트가 될 수도 있습니다.
    <my-app></my-app>


    Polymer의 특제양념을 이용한 웹 컴포넌트 구축



    폴리머는 웹 컴포넌트 기반의 어플리케이션을 구축하기 위한 엄청나게 많은 편리성들을 다음과 같이 가지고 있습니다.
    • 선언적인 엘리먼트 등록: <polymer-element> 
    • 선언적인 상속: <polymer-element extends="..."> 
    • 선언적인 양방향 데이터 바인딩: <input id="input" value="{{foo}}"> 
    • 선언적인 이벤트 핸들러: <button on-click="{{handleClick}}"> 
    • 배포 속성: xFoo.bar = 5 <-> <x-foo bar="5"> 
    • 속성 관찰: barChanged: function() {...} 
    • 기본적으로 내장된 PointerEvents / PointerGestures
    이 이야기의 교훈은 Polymer 엘리먼트의 작성은 전부 선언적이라는 것입니다.
    코드는 적게 작성하면서 더 나아진다는 것이죠. ;)


    웹 컴포넌트: 웹 개발의 미래



    슬라이드: http://html5-demos.appspot.com/static/cds2013/index.html#26

    만약 웹 컴포넌트 뒤의 표준을 내밀지 않았다면 제가 태만한 탓입니다. 결국 Polymer는 이러한 혁신적인 기초 API들에 기반하고 있습니다.

    지금은 웹 개발의 매우 흥미진진 시기인 듯 합니다. 웹 플랫폼에 추가되는 다른 새로운 기능과는 달리, Web Components를 구성하는 API들은 눈부시거나 사용자를 대상으로 하고 있지 않습니다. 이들은 순수하게 개발자 생산성을 위한 것입니다. 4가지 API 각각이 그 자체로 유용하지만 함께 사용하면 마법과도 같은 일이 벌어집니다!

    • Shadow DOM
      • 스타일과 DOM의 캡슐화
    • Custom Elements
      • 새로운 엘리먼트의 정의
      • 엘리먼트에 속성과 메소드를 이용해 API를 정의할 수 있습니다.
    • HTML Imports
      • CSS, JS 그리고 HTML의 패키지를 위한 배포 모델
    • Templates
      • 이후의 템플릿 처리를 위해 비활성화된 마크업 덩어리를 정의하기 위한 제대로된 DOM 템플릿 기능

    API에 대해 더 자세하게 알고 싶으시다면,  ebidel.github.com/webcomponents를 확인해보시기 바랍니다.

    2014년 1월 7일 화요일

    [업데이트/Summit] 크롬 개발자 서밋: 모바일 부문 요약(Chrome Dev Summit: Mobile Summary)

    2013년 열렸던 Chrome Dev Summit의 세션 소개 요약을 포스팅한 적이 있었는데 이 중 모바일 부문에 대한 요약을 +Paul Kinlan이 업데이트했네요. 자세한 내용은 아래를 참조하시기 바랍니다.





    몇 주 전 개최되었던 Chrome Dev Summit이 여기 이벤트에 대한 리포트들이 처음으로 발간되었습니다. 모바일과 크로스 디바이스 개발에 대한 매우 인상적인 글들이 있어 이로부터 시작하고자 합니다.


    모바일 웹 앱을 위한 최고의 UX 패턴들 by +Paul Kinlan 


    최상위 1000개 사이트에 대해 모바일 친화 여부에 대한 분석 후에 우리는 다음과 같은 몇가지 문제 영역을 발견했습니다. 53%는 여전히 데스크탑만으로 체험을 제공하고 있으며 82%의 사이트는 모바일 디바이스와의 상호작용에 대한 이슈들을 가지고 있고 64%의 사이트들은 사용자들이 읽는데 문제가되는 텍스트를 가지고 있습니다.

    모바일 웹 사용자 경험을 극적으로 개선 방법을 다음과 같이 빠르게 훑어봅니다.

    • 항상 뷰포트(Viewport)를 정의할 것
    • 뷰포트 내에 컨텐츠를 맞출 것
    • 읽기 좋은 수준으로 폰트 사이즈를 유지할 것
    • 웹 폰트의 사용을 제한할 것
    • 탭(Tab) 대상들에 대해 크기와 공백을 적절하게 만들 것
    • 입력(Input) 엘리먼트들에 대해 시멘틱 타입을 사용할 것

    PageSpeed Insights는 여러분의 사이트가 얼마나 모바일 친화적인지를 검토하는 UX 분석 기능을 얼마전 런칭했습니다. 이는 사이트의 모바일 UX를 통해 일반적인 문제를 발견하는데 도움을 줄 것입니다. 사용해보시기 바랍니다!


    슬라이드: 모바일 웹 앱을 위한 최고의 UX 패턴들




    멀티디바이스 접근성 by +Alice Boxhall


    사용자들은 접근성에 대한 넓은 범위의 각기 다른 요구사항을 가지는 아주 많은 디바이스를 통해 여러분의 사이트와 서비스에 접근할 것입니다. 올바른 시멘틱 엘리먼트들과 올바른 ARIA 역할들의 사용에 의해 브라우저과 보조적인 기술들이 여러분의 페이지를 이해하는데 많은 개선을 할 수 있도록 도와줄 수 있습니다.


    슬라이드: 멀티디바이스 접근성(Multi-device Accessibility)



    접근성 이슈들을 참조하고 이해하기 위한 주요 방법

    • 키보드만의 사용자 경험을 가지도록 할 것
    • 올바른 엘리먼트의 선택과 ARIA를 통해 인터페이스의 시멘틱을 표출할 것
    • 테스트를 위해 데스크탑은 ChromeVox를 안드로이드에서 TalkBack를 사용할 것
    • 접근성 개발자도구(Accessibility Developer Tools Chrome extension)을 사용할 것
    • 용이한 사이트 접근성을 확대하도록 더 다양한 사용자를 온라인으로 유지할 것


    크롬 웹뷰를 사용한 모바일 앱 구축 by +Matt Gaunt 


    우리 모두는 개발자들이 웹뷰를 사용한 구축 시 제한된 HTML5 기능, 디버깅 도구의 부재, 빌드 도구의 부재와 같은 문제들을 예전에 가지고 있었음을 알고 있습니다. 안드로이드 4.4(KitKat)의 Chromium powered WebView의 소개를 통해 이제 개발자들이 웹뷰를 사용하여 훌륭한 네이티브 앱을 개발하기 위한 거대한 범주의 새로운 도구들을 가지게 되었음을 알리고자 합니다.

    웹뷰는 크롬에서 사용하는 것과 동일한 도구로 완전한 리모트 디버깅을 지원합니다. 또한 Grunt를 사용한 믿을 수 있는 웹 개발 워크플로우를 가지게 되었으며 이를 Gradle을 통해 여러분의 네이티브 도구 스택에 통합할 수 있습니다. 통합된 세계들에 더 깊게 들어가, 여러분의 네이티브 코드를 자바스크립트로 테스트하기 위해 크롬 개발자도구를 사용할 수 있는 현명한 기법들을 살펴봅니다.


    효율적인 웹뷰 개발 방법들

    • 새로운 기능들이 아니라 워크플로우 속도 향상에 대해 지금 사용가능한 도구들이 중요
    • 네이티브 UI의 에뮬레이션 대신 웹 컨텐츠로 보이게 하는 것들을 확실하게 제거할 것
    • 필요할 때만 기능의 네이티브 구현을 사용할 것.
      • 예> 큰 파일에 대한 XHR 대신 다운로드매니저 사용


    크로스디바이스를 위한 워크플로우 최적화 by +Matt Gaunt 


    우리가 데스크탑, 모바일, 태블릿, 웨어러블 그리고 다른 형태의 디바이스에 대한 개발을 해야한다면 어떻게 덜 스트레스를 받도록 워크플로우를 최적화할 수 있을까요? 여기 LiveReload, Grunt, Yeoman 그리고 새롭게 베일을 벗은 Mini Mobile Device Lab을 통해 빠르게 반복적인 작업을 처리할 수 있는 튼튼한 멀티디바이스 접근방법이 있습니다. 만약 테스트하고자 하는 실제 디바이스가 없다면 클라우드를통해 이를 가능하게 하는 몇몇 서비스 제공자들이 있습니다.

    • 우리가 공급해야할 많은 디바이스들은 증가하기만 할 것임
    • Grunt와 Yeoman을 적절하게 이용한 워크플로우 가지기
    • Mini Mobile Device Lab를 이용한 크로스 브라우저 및 크로스 디바이스 테스트의 간소화
    • SaucelabsBrowserstack 그리고 Device Anywhere와 같은 클라우드 기반 에뮬레이터와 서드파티 에뮬레이터 Genymotion
    • 모바일 테스팅은 WiFi를 통한 테스트보다 더 많은 것들을 의미하므로 더 느린 네트워크 성능을 시뮬레이션하기 위한 프록시를 사용할 것


    네트워크 연결성: 선택적 접근 by +Jake Archibald 


    이 토크로부터 우리는 Jake는 프리젠테이션할 때 신발을 신지 않고 Business Kinlan은 곧 발매될 새로운 책을 가지고 있으며 오프라인이 되는 것은 브라우저 벤더들에게 심각하게 받아들여지고 있고 여러분은 곧 오프라인 시에도 잘 동작하는 훌륭한 체험을 구축할 수 있도록 도와줄 도구들을 손에 쥐게 될 것이라는 많은 사실들을 배울 수 있습니다. :)

    ServiceWorker는 우리에게 눈을 뗄 수 없는 첫번째 체험의 구축을 위해 필요한 유연성을 쉽고 AppCache로부터 기인한 고통을 느낄 필요가 없이 제공해줍니다. Polyfill을 사용한 API를  실험해 볼 수도 있습니다.


    슬라이드: 네트워크 연결성: 선택적 접근



    ServiceWorker로 바뀌는 것들

    • 차세대 점진적 향상(Progressive enhancement)으로써 네트워크를 잠재적 향상 버전처럼 다룰 수 있니다.
    • ServiceWorker는 완전하고 스크립트와 디버깅이 가능한 네트워크 요청을 제어할 수 있도록 합니다.
    • 만약 오프라인 기능을 가지고 있다면 컨텐츠 표시 전에 실패한 네트워크를 기다리지 않고 보여줄 수 있습니다.

    2014년 1월 6일 월요일

    [튜토리얼/한글화 소식] JavaScript Promise 외 튜토리얼 4종 라이브 소식

    안녕하세요. 연말 연휴로 밀렸던 HTML5Rocks 한글화 업데이트가 오늘 전부 라이브되었습니다. 평상 시에는 개별적인 튜토리얼 단위로만 포스팅을 했지만 조금 밀려있는 관계로 금번 업데이트 소식을 모은 포스팅을 추가하여 전달해드립니다. 각 제목을 클릭하시면 개별 튜토리얼에 대한 포스트로 이동합니다. :)


    1. 자바스크립트 Promise: 또 다른 시작


    자바스크립트의 비동기 동작으로 인해 콜백이 콜백을 부르고 다시 콜백이 콜백을 부른 과정이 중첩되다보면 내가 콜백인지 콜백이 나인지 헷갈릴 정도의 Callback Hell에 빠지게 됩니다. Promise는 이러한 비동기 동작을 손쉽게 처리할 수 있도록 고안된 비동기 프로그래밍 모델입니다.

    이번 튜토리얼은 거의 작정하고 만든 듯이 완벽 해설서에 가깝습니다. Polyfill을 이용해서 당장 적용해보실 수도 있으니 비동기 콜백에 지치거나 그 지옥 한가운데에 있으시다면 잠시 코딩을 멈추시고 일단 읽어보시길 바랍니다.

    "콜백 지옥(Callback Hell)은 멀리 있지 않습니다. 몇가지의 이벤트를 순차적으로 사용하기 위한 시나리오만 있으면 됩니다. 그러나 겹겹이 이어지는 콜백 함수가 포함된 코드는 주말이 지나고 새로운 모습으로 여러분에게 다가올 것입니다."



    2. 객체 풀 기반의 정적 메모리 자바스크립트


    아시다시피 자바스크립트에서는 자바와 마찬가지로 개발자가 직접 메모리를 관리할 필요가 없습니다. 이 둘은 전혀 다른 언어 스펙을 가지고 있지만 메모리 관리에 대해서는 가비지 콜렉션(Garbage Collection, 이하 GC)을 사용하기 때문입니다. 이번 튜토리얼은 이러한 GC의 동작을 회피하기 위해 정적으로 메모리 공간을 할당하고 이를 지속적으로 재사용하는 모델을 자바스크립트를 기반으로 설명합니다.

    번역은 김훈민님께서 수고해주셨습니다.  :)

    "GC는 개발자가 메모리를 직접 관리하는 대신 경험적으로 효율적이라 판단되는 형태로 메모리를 자동으로 수거하고 관리합니다. 그러나 메모리의 할당/해제는 아주 오래된 성능 병목지점의 하나이기 때문에 직접적으로 관리하지 못하는 모델에서는 순간적인 지연으로 인한 멈칫거리는 현상이 발생하고는 합니다. 정적 메모리 모델이 모든 것에 대한 해답은 되지 못하지만 GC에서 매뉴얼적인 메모리 관리 모델이 제공되지 않는 경우 유일한 해결 방법이기도 합니다."



    3. CSS 페인트 타임과 페이지 렌더 가중치


    이전에 포스팅한 렌더링 관련 튜토리얼들은 웹킷 혹은 크롬의 렌더링 모델이 취하는 구조나 그로 인한 렌더링 성능의 형태 및 최적화에 대해 논의한 글이었습니다. 그리고 이 튜토리얼은 조금 다른 관점에서의 렌더링 성능과 관련하여 가중치와 그 측정 방법에 대해 논의하고 있습니다. 특히, CSS의 속성들의 조합이 그 각각의 페인트 시간의 합보다 더 많은-심지어 훨씬 더 많은- 시간을 소모할 수 있다는 것은 특별히 더 염두에 두어야 할 내용 중의 하나입니다. :)

    "GPU 기반으로 가속되는 그래픽스의 성능 향상은 웹에서도 많은 효과를 가능하도록 만들었습니다. 그러나 그래픽스 시스템이 가지는 특성으로 인해 이러한 효과들이 조합되는 경우 중 어떠한 것들은 우리가 기대하는 바와는 달리 더 많은 렌더링 시간을 차지하여 예상치 못한 성능 상의 영향을 주기도 합니다."



    4. 안티앨리어싱 101


     다른 그래픽스와 마찬가지로 안티앨리어싱은 다양한 방식으로 처리될 수 있습니다. 또한 폰트의 안티앨리어싱 처리는 기본사항이라고 생각해도 무방합니다. 이 튜토리얼에서는 현재 크롬에서 사용하고 있는 '그레이스케일 안티앨리어싱(Grayscale Antialiasing)과 서브픽셀 안티앨리어싱(Antialiasing)'에 대해 차이점을 설명하고 어떠한 기준으로 각 방식이 사용되는지에 대해 설명합니다.

    "안티앨리어싱은 그래픽스에서 2가지 이상의 색상들이 충돌하는 픽셀과 그 주변들에 대해 어떠한 색상으로 채울 것인지를 결정하는 처리 과정을 말합니다. 특히 폰트의 렌더링에서 윤곽선의 처리는 미려한 출력을 위해 아주 오랜동안 사용된 기법이기도 합니다."


    5. Shadow DOM 301: 고급 개념과 DOM API


    웹 컴포넌트 관련 튜토리얼마다 말씀드리는 내용입니다만 DOM에 대한 캡슐화(Encapsulation)와 같은 매우 강력한 기능을 제공하는 Shadow DOM 역시 이전의 Custom Element나 HTML Imports처럼 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다. 이 튜토리얼은 여러개의 Shadow root 사용하는 방법과 호스트의 Shadow tree를 얻고, 자바스크립트을 통한 Shadow DOM의 구축 및 삽입지점을 통한 동작에 대해 논의합니다. 그리고 Shadow DOM을 쉽게 이해할 수 있도록 만들어진 도구인 Shadow DOM Visualizer와 이벤트 모델의 동작 방식을 소개합니다.

    "Shadow DOM이 컴포넌트를 구성하는 DOM을 감추는 역할(encapsulation)을 하고 HTML Template가 DOM의 복제 및 재 사용성을 제공하며 Custom Element는 웹 문서에서 사용할 엘리먼트를 모듈에서 직접 등록할 수 있도록 하는 기능을 제공하여 컴포넌트의 명시적인 alias를 선언하는 역할을 한다면 HTML Imports는 웹 문서 내에 외부 리소스를 포함(Import)하기 위한 기능을 제공합니다."

    [튜토리얼/한글화] Shadow DOM 301: 고급 개념과 DOM API (Shadow DOM 301: Advanced Concepts & DOM APIs)

    HTML5Rocks의 Shadow DOM 관련 튜토리얼 중 마지막 글인 +Eric Bidelman의 '섀도 DOM 301: 고급 개념과 DOM API (Shadow DOM 301: Advanced Concepts & DOM APIs)' 튜토리얼의 한국어 번역이 업데이트되었습니다.

    웹 컴포넌트 관련 튜토리얼마다 말씀드리는 내용입니다만 Shadow DOM 역시 이전의 Custom ElementHTML Imports처럼 웹 컴포넌트를 지탱하는 4가지 규격 중의 하나입니다. Shadow DOM은 DOM에 대한 캡슐화(Encapsulation)와 같은 매우 강력한 기능을 제공합니다. 이 튜토리얼은 여러개의 Shadow root 사용하는 방법과 호스트의 Shadow tree를 얻고, 자바스크립트을 통한 Shadow DOM의 구축 및 삽입지점을 통한 동작에 대해 논의합니다. 그리고 Shadow DOM을 쉽게 이해할 수 있도록 만들어진 도구인 Shadow DOM Visualizer와 이벤트 모델의 동작 방식을 소개합니다.

    "Shadow DOM이 컴포넌트를 구성하는 DOM을 감추는 역할(encapsulation)을 하고 HTML Template가 DOM의 복제 및 재 사용성을 제공하며 Custom Element는 웹 문서에서 사용할 엘리먼트를 모듈에서 직접 등록할 수 있도록 하는 기능을 제공하여 컴포넌트의 명시적인 alias를 선언하는 역할을 한다면 HTML Imports는 웹 문서 내에 외부 리소스를 포함(Import)하기 위한 기능을 제공합니다."


    TL;DR;


    Shadow DOM은 DOM에 대한 캡슐화(Encapsulation)와 같은 매우 강력한 기능을 제공합니다. 이 튜토리얼은 Shadow DOM 101과 Shadow DOM 201에서 다뤘던 개념들을 기초로 하여 고급 개념과 활용 방법에 대해 논의합니다.

    Shadow DOM을 호스팅하는 엘리먼트도 한번에 하나 이상의 Shadow Root를 호스팅할 수 있습니다. 호스트에 추가된 섀도 트리들은 그들이 추가된 순서대로 스택에 쌓이며 가장 최근에 추가된 것부터 시작합니다. 따라서 만약 여러개의 <shadow> 삽입지점들이 섀도 트리 내에 존재한다면 첫번째만이 인식되며 나머지는 무시되고 렌더링됩니다.

    또한 만약 자바스크립트에서 DOM을 구축하는 것을 선호한다면, HTMLContentElement과 HTMLShadowElement는 그를 위한 인터페이스를 가지고 있으며 Shadow DOM 내의 <content>내로 탐색은 원칙적으로 불가능하나 .getDistributedNodes() API나 .getDestinationInsertionPoints()를 통해 액세스할 수 있습니다.

    삽입지점(Insertion Point)은 DOM이 실제로 이동하는 것이 아니라 삽입지점이 가르키고 있는 위치에 대해 마치 DOM이 존재하는 것처럼 렌더링하고 동작하는 것을 뜻합니다. 이러한 이유로 여러분의 DOM 트리는 여전히 원래 상태대로 유지되고 있지만 실제 렌더링 결과는 DOM이 그리로 이동하거나 복사된 것처럼 동작합니다.

    이벤트는 Shadow Root의 상위 경계가 제공하는 캡슐화(Encapsulation)을 유지하기 위해 Shadow DOM으로 이동한 내부 엘리먼트들로 대상을 재설정되며 abort, error, select, change,load, reset, resize, scroll, selectstart와 같은 이벤트들은 Shadow Boundary 간의 전달이 일어나지 않습니다.


    +Eric Bidelman의 Shadow DOM Visualizer 소개 영상



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

    번역 링크


    참고 글

    2014년 1월 1일 수요일

    [튜토리얼/한글화] 안티앨리어싱 101 (Antialiasing 101)

    어느새 새해의 첫날이 시작되었네요. 먼저 새해 복 많이 받으세요. :-)

    HTML5Rocks에 +Paul Lewis의 '안티앨리어싱 101(Antialiasing 101)' 한글 튜토리얼이 업데이트되었습니다.

     다른 그래픽스와 마찬가지로 안티앨리어싱은 다양한 방식으로 처리될 수 있습니다. 또한 폰트에 대한 안티앨리어싱은 기본사항이나 마찬가지입니다. 이 튜토리얼에서는 현재 크롬에서 사용하고 있는 '그레이스케일 안티앨리어싱(Grayscale Antialiasing)과 서브픽셀 안티앨리어싱(Antialiasing)'에 대해 차이점을 설명하고 어떠한 기준으로 각 방식이 사용되는지에 대해 설명합니다.

    "안티앨리어싱은 그래픽스에서 2가지 이상의 색상들이 충돌하는 픽셀과 그 주변들에 대해 어떠한 색상으로 채울 것인지를 결정하는 처리 과정을 말합니다. 특히 폰트의 렌더링에서 윤곽선의 처리는 미려한 출력을 위해 아주 오랜동안 사용된 기법이기도 합니다."



    TL;DR;


    안티앨리어싱은 스크린 상에서 깔끔한 텍스트와 부드러운 벡터 형태를 가지게 된 근본적인 이유인데도 불구하고 웹 그래픽스에서 알려지지 못한 영웅과도 같습니다. 실제로 안티앨리어싱의 접근 방법들 중 다음 방법들은 최근의 브라우저에서 텍스트를 렌더링할 때 가장 분명하게 사용되고 있습니다.


    • 그레이스케일 안티앨리어싱(Grayscale Antialiasing)
      • 픽셀들의 처리에 있어 RGB 요소를 모두 균등한 비율의 값으로 처리합니다.
    • 서브픽셀 안티앨리어싱(Subpixel Anitialiasing) 
      • 픽셀 별로 RGB의 각 요소를 각각의 연산에 따라 다른 비율로 처리합니다.
      • 그레이스케일보다 깔끔하지만 처리 비용은 더 높습니다.

    보다 자세한 내용과 각 안티앨리어싱 알고리즘이 선택되는 기준에 대해서는 본문을 참조하시기 바랍니다.


    번역 링크