이 튜토리얼은 Chrome 35 버전부터 포함되는 Object.observe()에 대한 기초적인 설명부터 이를 데이터 바인딩으로 확장하는 구현 사례, 성능에 대한 분석을 담고 있습니다.
"데이터 바인딩은 흔히들 얘기하는 데이터(혹은 모델) 레이어와 표현 레이어를 분리하는 편리하고 강력한 개념이자 방법이며 이미 꽤 오랜동안 그리고 대다수의 프레임워크에서 데이터 바인딩을 지원하고 있습니다. 특히 데이터 바인딩에서 양방향 혹은 데이터의 변경을 자동으로 추적하여 뷰를 업데이트하는 방법은 데이터(정확히는 객체나 객체 내의 속성, 프로토타입 등)에 대한 관리 외에 UI까지 신경써야 하는 개발 과정을 크게 단순화시켰습니다만 이를 지원하기 위해 지속적으로 UI와 연결(Binding)된 데이터에 대한 추적을 지원해야 하며 경우에 따라서는 바인딩을 유지하기 위한 별도의 프로그래밍 방법이 필요한 경우도 있었습니다. ECMAScript7에서 추가된 .observe() 메소드는 이러한 데이터를 추적하기 위한 방법을 순수 스크립트 객체까지 확대하였습니다.
데이터의 변경을 추적하거나 기존 프레임워크에서 데이터 바인딩을 유지하기 위한 실행 비용이 부담스러웠다면 이 튜토리얼에서 observe()에 대한 이해를 통해 힌트를 얻어보시기 바랍니다."
TL;DR;
ECMAScript 7에 정의되고 Chrome 36 베타부터 탑재된 Object.observe() 메소드는 데이터 바인딩(data-binding)과 가장 밀접하게 관계된 새로운 자바스크립트 추가 기능입니다. 이는 MVC 라이브러리들에서 사용하는 감시 모델(Observing Model)에 대한 구현 방식을 획기적으로 전환할 기능이기도 합니다.
자바스크립트에서 객체에 대한 데이터 감시(Observation)의 대상은 보통 다음과 같습니다.
순수한 자바스크립트 객체들에 대한 변경
속성(Property)들이 추가, 변경되거나 삭제되었을 때
배열들이 가진 요소(Element)가 합쳐지거나 나누어졌을 때
객체의 프로토타입에 대한 변경
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 등의 주요 프레임워크들 역시 이를 지원하거나 지원하기 위한 로드맵을 진행 중입니다.
오랜만에 업데이트를 하게 되는군요. 그간 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 개발이 일반화되던 시절 많은 회사들과 개발자들이 앞다투어 컴포넌트를 제공했습니다. 이는 그 당시의 프레임워크나 플랫폼들이 이를 지원하는 기술적인 기반을 제공했기 때문이기도 합니다. 웹 역시도 이미 오랜동안 그러한 시도들이 있어왔습니다만 이제 좀 더 유려한 방식으로 이를 지원할 수 있게 되었습니다. 여러분이 게시판의 아이템을 확장하기 위해 태그들을 다시 수정하고 이를 검토한 뒤에 실제 프로젝트에 적용하고 테스트하는 과정은 분명히 간소화될 수 있습니다. -언제나 새로운 기술과 방법들은 버그나 문제점을 만들었지만 이는 가치에 비하면 분명 사소한 것들입니다. 게다가 우리가 경험적으로 알고 있다시피 버그와 문제점들은 언제나 개발자의 가장 친한 친구입니다! 아, 그렇다고 화내지 마세요. :)-
이제 여러분은 이미 만들어 놓은 컴포넌트를 사용하여 보다 빠르게 웹 페이지를 개발할 수도 있고 유지보수를 페이지 기반이 아니라 컴포넌트 기반으로 옮겨갈 수도 있습니다. 혹은 잘 만들어 놓은 컴포넌트를 배포하여 수익을 만들어 낼 수도 있겠죠. 이 모든 것들의 뒤에는 퀩 컴포넌트가 있습니다. 아래의 링크들을 읽어보시고 사용해보시고 적용해보세요. :)
Web Components는 웹을 구축하는데 있어 여러분이 알고 있다고 생각하는 모든 것을 바꾸고 있습니다. 처음으로 웹이 우리 자신의 HTML 태그들을 생성하는 것만이 아니라 로직과 CSS를 캡슐화할 수 있는 저수준 API를 가질 예정이었습니다. 더 이상의 전역 스타일시트 수프나 보일러플레이트 코드는 없습니다! 이는 모든 것이 엘리먼트인 멋지고 새로운 세계입니다.
DotJS에서의 발표에서 저는 웹 컴포넌트가 무엇을 제공해야하는지와 최근의 도구들을 이용하여 이를 어떻게 구축할 수 있는지에 대해 자세하게 설명했습니다. 저는 여러분에게 오늘날 모던 브라우저에서 웹 컴포넌트를 사용하여 앱을 개발하기 위해 Yeoman과 Polymer를 이용하여 웹앱 생성을 간소화하는 도구들의 작업흐름, Polyfill 그리고 설탕 한 숟가락(sugar)을 보여드릴 것입니다.
또한 우리는 새로운 폴리머 엘리먼트들을 스캐폴딩하기 위해 Yeoman sub-generator를 활용하였습니다. 예를 들어 foo 엘리먼트를 위한 보일러플래이트를 생성하기 위해 다음과 같이 실행합니다.
yo polymer:element foo
엘리먼트를 자동으로 불러올지 혹은 생성자가 별도로 필요한지와 몇가지 다른 선호사항들에 대한 프롬프트가 표시될 것입니다.
앱을 위한 최종적인 소스는 발표와 GitHub에서 확인할 수 있습니다. 좀 더 구조적이고 읽기 쉽도록 약간 더 리팩토링을 해두었습니다.
앱의 미리보기는 다음과 같습니다.
추가적인 읽을거리들
요약하자면 폴리머는 웹 컴포넌트가 네이티브로 구현되기를 기다리는 동안 이를 모던 웹 브라우저에서 가능하도록 하는 자바스크립트 라이브러리입니다. 현재적인 도구화는 이들을 사용하는 여러분의 작업흐름을 개선할 수 있도록 도와주므로 여러분은 여러분만의 태그를 개발할 때 Yeoman과 Bower에 대한 시도를 즐겨볼 수 있을 것입니다.
