레이블이 chromekr인 게시물을 표시합니다. 모든 게시물 표시
레이블이 chromekr인 게시물을 표시합니다. 모든 게시물 표시

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는 완전하고 스크립트와 디버깅이 가능한 네트워크 요청을 제어할 수 있도록 합니다.
  • 만약 오프라인 기능을 가지고 있다면 컨텐츠 표시 전에 실패한 네트워크를 기다리지 않고 보여줄 수 있습니다.

2013년 10월 29일 화요일

Summary: Chrome Barcamp Korea

10월 25일에 있었던 Chrome Barcamp에 참석했었습니다. 다양한 주제로 그룹을 나누어서 바캠프를 진행했는데 저는 Web Animation과 Google Web Designer, HTML5Rocks에 대해 몇 가지 개인적인 질의를 했습니다. 그와 별개로 Performance Optimization을 해보는 시간도 가졌습니다. (Thx to  +Alex Danilo+Paul Kinlan+Ryan Schoen & 긱한 개발자분. 그리고 보니 이름을 못들었다는...) 좋은 자리 마련해주신 +Soonson Kwon님께도 감사드립니다. 다른 분들의 후기도 기다려봅니다. :)


Web Animation


네이티브로 구현된 모듈은 시드니에서 개발 중이며 곧 블링크에 포함될 것이라고 합니다. 아마 내년 상반기에는 크롬에서 만나볼 수 있을 것 같습니다. 물론 현재도 Polyfill을 이용해서 사용해 볼 수 있습니다.

관련 링크



Google Web Designer


얼마 전에 웹 디자이너를 살며시 뜯어 봤을 때 도구를 포함한 내부 환경은 거의 HTML5로 구성이 되어 있었던 것으로 봤었는데 구현 상으로도 몇가지 얘기해볼 만한 사항들이 있었지만 이에 대한 것은 다음에 따로 정리해보도록 하겠습니다.

일단 구글 웹 디자이너 툴은 광고 컨텐츠에 대해 메인 포커싱을 하고 있다고 합니다. 내부적으로 WebGL에 대한 설정 부분이 예약되어 있는 것에 대한 부분은 프로젝트 팀이 달라서 답변을 듣지는 못했습니다. (예약이 되어 있는 만큼 어느 정도 3D 기반의 리치 미디어에 대한 접근도 고려하고 있는 것이 당연하겠죠.)


Performance Optimization


성능 최적화는 전날의 크롬 Developer Day에서도 많이 다루어졌듯이 레이어의 크기나 사이즈 부분이나 이동 시의 적합한 방식에 대하여 얘기했습니다. 그 중 몇가지를 간단하게 정리하기 전에 간략하게 브라우저의 렌더링 과정을 살펴보고 넘어가보도록 하겠습니다.
  • 브라우저 내 문서의 시각적인 각 엘리먼트는 대부분 하나 이상의 레이어라는 단위로 매핑되는 렌더링 트리를 구성하게 됩니다. 그리고 이 렌더링 트리를 브라우저가 렌더링을 하는데는 다음과 같은 몇가지 패스를 거치게 됩니다. 
    • 레이아웃(Layout)
    • 스타일(Style)의 계산
    • 페인팅(Painting)
    • 합성(Composition)
  • 반복되는 렌더링에서 한번의 패스는 반드시 모든 과정을 반복하지는 않으므로 패스 내에서의 동작을 최소화하는 방법이 성능 최적화의 주요 목표가 되겠습니다. 이와 관련된 자세한 내용은 아래의 참고 자료들을 읽어보시기 바랍니다.

실제적인 가이드라인 중 몇 가지를 살펴보면 다음과 같습니다.

  • 이동에 대한 애니메이션의 경우 top, left 대신 transform : translate() 사용
    • 레이어의 transform은 페인팅을 다시 요구하지 않으므로 translate()를 이용하여 동일한 시각적 효과를 얻을 수 있습니다.
    • 예시
      • -webkit-transform: translateX(-1px);
      • -webkit-transform: translateY(38px);
  • 레이어를 차지하는 엘리먼트는 가급적 사이즈와 갯수를 최소화
    • 간단하게 설명드리면 레이어가 크면 GPU 상의 메모리도 크게 차지하고 레이어의 갯수가 많으면 역시 메모리의 할당 숫자도 많아지므로 이를 회피하는 것이 중요합니다.
    • 비슷한 경우로 별로 중요하지 않은 레이어는 크기를 필요 크기보다 줄이고 (가급적 정수 배율로) scale()로 크기를 맞추는 것도 비슷한 효과를 얻을 수 있을 것으로 예상되네요. (게임에서 LOD를 사용하는 것과 마찬가지로 말이죠.)
  • 화면에서 보이지 않는 DOM의 경우 감추거나 제거
    • 위의 사항과 유사하기는 한데 일단 렌더링 트리가 줄어들어 탐색의 범위가 줄고 GPU 메모리 및 렌더링 패스에서 명시적으로 벗어나므로 성능 향상의 효과를 얻을 수 있을 것으로 보입니다. 렌더러에서도 메모리 관리 부담이 줄어드는 부수적인 효과가 있겠습니다.

이러한 렌더링 오버헤드는 개발자 도구에서 "Show Paint Rectangles"를 선택하거나 프로파일링을 통해 확인할 수 있습니다. 자세한 내용은 역시 아래 참고자료를 참조하세요.


참고자료



2013년 10월 25일 금요일

Summary: Chrome Developer Day Korea


10월 24일 선릉역 D.CAMP에서 크롬 개발자들이 다수 참석하여 개발자 데이 행사를 진행했습니다. 요약 대신해서 간략한 후기 남겨봅니다. 오밤 중에 대충 기억으로 적는 것이라 틀린 것도 많을 겁니다. 이해를...:)



What’s new in mobile HTML5


+Alex Danilo가 크롬 안드로이드와 관련된 신규 기능들에 대한 소개 발표였습니다. 안타깝게도  +Eiji Kitamura씨는 참석을 못했네요. :( 이 세션에서 나온 내용들은 간략하게 나열합니다. 참고로 아래 내용 중 현재 지원 가능한 부분과 아닌 부분들은 업데이트가 필요할 듯 합니다. 첫 세션이라 도저히 기억이 안나네요.
  • 크롬 안드로이드에서 chrome://flags 추가되었습니다.
  • viewports에 새롭게 vw, vh, vmin, vmax가 추가되었습니다. 단위는 전체 길이의 1%입니다.
  • position: sticky가 추가되었습니다. 상위 노드에 대해 fixed와 유사하게 동작합니다.
  • Fullsrceeen가 지원됩니다.
  • Semantic Input Type으로 효과적인 사용자 입력을 기대할 수 있습니다.
  • MS에서 제안 중인 Pointer event에 대한 얘기가 있었는데 아직 지원은 안됩니다. (IE11만 지원). Pointer 이벤트는 mouse와 touch의 통합형 이벤트입니다. 당연히도 필요하겠죠.  :)
  • 하드웨어 관련해서 Media Capture 지원됩니다. <input capture accepts=“image/*”> 처럼 기술하면 카메라로 사진 찍고 input으로 넘어갑니다.
  • WebAudio 됩니다. 입력은 지난번 포스팅에 나온 바와 같습니다.
  • Add Homescreen 기능이 추가되었습니다. 원래 애플이 apple- 접두어를 사용했었는데 일단 크롬에서도 apple- 접두어를 당분간 지원한다고 합니다. (이에 대해 정리해둔 글이 있었는데 어디에 올렸는지를 모르겠네요.)
  • 안드로이드 intents를 웹에서 바로 사용가능합니다. URL로 넘길 수 있습니다.
  • 성능 측정 관련해서 Navigation Timing API, Resource Timing API 추가되었습니다.



Polymer


'폴리머'는 현재 규격 작업이 진행 중인 Web Component를 모던 브라우저들에서 지원하기 위한 Polyfill 라이브러리입니다. Web Component가 표방하는 것이 하나의 완전한 웹 문서가 Encapsulation된 형태로 정의되고, 사용되고, 재사용되는 규격을 목표로 하는 만큼 빠르게 표준화가 되었으면 하고, 추가로 발표자인 +Eric Bidelman 이 궁극적으로 보일러플레이트를 소멸시키는 것이 목표라고 계속 얘기를 하더군요. 그랬으면 좋겠습니다. :)

웹 컴포넌트는 다음과 같이 4개의 규격으로 지탱됩니다.
  1. Shadow DOM - DOM 및 DOM, 자바스크립트에 대해 캡슐화를 지원합니다. 이 규격을 바탕으로 컴포넌트의 Content가 외부로부터 보호됩니다.
  2. HTML Template - 해석, 렌더링, 실행되지 않는 순수 템플릿 기능을 지원합니다. 이로부터 새로운 노드를 복제하거나 새로 생성하는 것이 가능하기 때문에 하나의 웹 컴포넌트로 다수의 인스턴스를 만들어 낼 수 있습니다.
  3. Custom Element - 기존의 DOM을 확장하거나 새로운 DOM을 생성합니다. 위에서 Shadow DOM과 HTML Template가 구조를 제공한다면 Custom Element는 타입의 확장과 정의 기능을 제공한다고 이해해도 되겠습니다.
  4. HTML Imports - HTML 문서를 특정한 위치로 적재하는 기능을 수행합니다. 일종의 로더라고 볼 수도 있겠습니다. 이 규격이 Web Component의 재사용성을 담보합니다.
요약하면 'Polymer'는 프레임워크 등에 대한 의존성 문제가 없기 때문에 생산성과 재사용성이 뛰어나고 특히 소프트웨어 공학면에서도 좋은 접근(Good Software Engineering)을 통한 일종의 OOP를 구현하는데 장점이 있습니다.

물론 현재는 폴리필 형태의 라이브러리이기 때문에  완벽한 encapsulation 등에 대한 부분이 실제로 완전히는 감춰지지 않는 이슈가 있을 수 있는 것도 문제이긴 하지만 이 정도로 잘 지원하는 것만 봐도 충분히 활용이 가능할 듯 합니다.

현재 폴리머에서 제공하고 있는 라이브러리도 쓸모가 많기 때문에 겸사겸사 공부해보는 것은 어떨까 싶습니다. 참고로 Yeoman을 사용하여 생산성을 유지하며 개발하는 것은 어떨까요?  Yeoman과 Polymer를 이용한 웹앱 개발를 읽어 보시길...1, 2년 정도면 Web Component 시대가 올 것 같다는 생각을 조심스럽게 해봅니다.



Workflow, DevTools mobile web


그 유명한 +Paul Irish의 발표였습니다. :) 일단 개발자 도구에 관련한 내용은 크롬 개발자도구 레볼루션 2013에서도 다루고 있기 때문에 크게 다른 부분은 없습니다. 정확하게 말하면 그 문서가 지속적으로 업데이트되고 있기 때문이기도 합니다. :)

어쨌던 가볍게 몇가지만 나열해보자면
  • 기존의 텍스트 에디터에서 수정하고 브라우저로 가서 확인하며 왔다갔다 하면서 개발하는 프로세스가 크롬 개발자도구로 완전히 통합되었습니다.
    • Workspace 설정 후 로컬 파일과 폴더 등을 매핑하면
      • 프로젝트 형태로 편집이 가능하고
      • 웹 문서뿐만이 아니라 서버사이드 스크립트 등의 수정이 가능하며
      • 스타일 창에서의 변경 역시 영구적으로 저장됩니다.
    • 즉, 인스펙터에서 수정하고 저장하면 실제 파일과 동기화됩니다.
  • Sass, Less 지원되고 디버깅도 됩니다.
  • 이 부분이 다들 좋아하는 부분 중에 하나인데 크롬에서 안드로이드 디바이스에 원격 디버깅이 지원됩니다. 
    • 간단하게 주소창에 about://inspect 치시면 디버깅이 연결됩니다.
    • 스크린캐스트를 통해 실제 디바이스의 화면을 보면서 PC 사이드에서 조작과 화면 확인, 디버깅이 가능합니다. (이거 무지무지 유용한 기능이죠.)
    • localhost 등으로 개발 중일 경우 역시 개발자 도구의 포트 포워딩을 통해서 l디버깅이 가능합니다.
  • 개발자도구를 이용하여 Layout, Style Recalculation, Paint, Composition의 프로파일을 디버깅하는 기능도 시연되었습니다.
    • continuous painting inspection을 이용하면 flowl 형태로 렌더링 오버헤드를 확인할 수 있다던가 프레임 렌더링 시간을 조사할 수 있고 이를 통해 스타일의 재계산 등을 막거나 개발자 도구의 프로파일링에서 추가적인 최적화 관련 정보 등을 확인할 수 있습니다.
    • 위 기능이 다 안되면 주소창에 about:tracing 를 써도 됩니다. 물론 좀 많이 불편합니다.



Creating HTML5 Games


+John McCutchan의 발표입니다. (Game과 Dart에 대해 두번 발표하더군요.)  HTML5 기반에서 게임을 개발하는데에 대한 일반적인 기능과 방식에 대해서 설명했습니다. 근데 이때 외부에서 전화가 와서 거의 다 놓쳤네요. :(

가능한 스택으로  Canvas, Web Audio, (P)NaCl 등을 예로 들었고 성능 상에 악영향 요소(Performance Traps)에서 '언제나 할당은 GC Pause로 한발 다가가는 것'이라고 얘기하더군요. GC는 언제쯤 어떻게 처리가 될런지 궁금합니다.

NaCl의 경우는 Security Model이 잘 지원되고 네이티브 기능을 확장하고자 할 때 사용할 수 있는 유용한 플러그인 개발 형태고 PPAPI를 통해 거의 모든 웹 요소들에 접근이 가능한 등의 장점을 얘기했습니다. 마지막에 HTML5 Games polymer에 대해서 얘기했는데 흥미로운 접근이었습니다. :)



Chrome Apps


+Pete LePage가 발표했습니다. 크롬 앱에 대해서 쭉 얘기를 해줬는데  오프라인, 하드웨어 제어, 기존 브라우저, 네이티브 기능 통합, 인프라 등의 이슈가 기존에 존재해왔으며 크롬 앱에서는 이러한 문제를 해결함과 동시에 크롬 웹 스토어에서 클라우드 서비스를 통해서  저장소 및 파일 등을 동기화하거나 푸시 메세지, 사용자 인증 및 정보, 앱 업데이트, 결제(1회성 결제 및 인앱 결제), 네이티브 기능 통합이 가능한 것에 대해 각각 설명했습니다.

재밌는 것은 크롬 앱을 통해서 USB나 블루투스 같은 외부 장치 연동이 가능하다는 점입니다. 몰랐는데 이게 되더군요. :)  네이티브 기능 통합의 예로 심장 박동 모니터를 연동해서 웹으로 박동수를 보여주는 데모와 LED 전등의 색상을 연동을 통해 제어하는 것을 보여줬습니다. 그리고 크롬만 되면 무슨 소용인가라는 의문에 대해 Cordova(Phonegap) 기반으로 만들어진 하이브리드 웹앱 패키징이 됩니다. 궁금하시면 http://github.com/MobileChromeApps/chrome-cordova로 방문!



Rendering without lumps


+Jake Archibald 의 아주 다이나믹한 세션이었습니다. :) Wii 컨트롤러로 프리젠테이션을 진행하는 것도 인상적이었지만 발표 노트와 마치 하나가 된듯한 물 흐르는 듯한 진행 기술을 가지고 있더군요. 그것보다 인상적인 것은 'W(hat)T(he)F(rame)P(er)S(econd)?' 였습니다. (진짜일까요? ㅋ)

간략하게 나누자면 웹 브라우저에서 DOM 트리는 CSS와 함께 덧붙여져서 Rendering 트리를 구성하게 됩니다. (이 과정에서 각 엘리먼트는 하나 이상의 레이어와 대응됩니다.) 이때 하나의 렌더링 노드를 그리는데는 크게 레이아웃, 스타일 계산, 페인팅, 결합(Composition)의 4단계를 하나의 패스로 거칠 수 있습니다. 물론 항상 모든 단계를 거치는 것은 아니고 간 단계가 실행되기 위한 선행 조건이 있습니다. 렌더링 성능 개선의 가장 기본이 바로 이 단계를 최대한 생략하기 위한 여러가지 방법들이 되겠습니다.

예를 들어 left 속성을 통해 X축 이동을 하는게 아니라 translate()를 이용하는 것은 같은 시각적 효과를 보여주지만 렌더링 패스는 전혀 다른 결과를 보여줍니다. 이외에도 z-index나 tranlateZ()를 이용해서 레이어를 별도로 관리하게 하는 등의 테크닉들도 시연이 있었습니다.

한가지 더 보자면 개발자 도구를 사용하여 렌더링, 레이어 결합 등이 어디서 발생하는지 확인하고 처리하는 방법도 함께 소개되었습니다. (렌더링 성능 관련해서는 여러 스피커가 언급을 했기 때문에 동일한 방법이 많이 나왔습니다. 불필요한 페인트 회피하기불필요한 페인트 회피하기 : Animated GIF 에디션를 함께 참고하세요.) 자세한 것은 http://speakerdeck.com/jaffathecake/rendering-without-lumps에서 한번 살펴보시길.



Build a fast mobile site with PageSpeed Mobile Insight


+Paul Kinlan 이 모바일 사이트에서 PageSpeed Mobile Insight를 이용한 모바일 웹 최적화에 대한 발표를 진행했습니다. 일단 PageSpeed Mobile Insight가 웹사이트에 대해 검사해주는 것은 다음과 같습니다.
  1. 리다이렉트의 횟수
  2. 비효율적인 압축 및 최소화(minification)
  3. CSS와 자바스크립트의 성능 상의 이슈 지점
  4. 캐시 이용률
CSS가 로딩되지 않거나 아직 해석되지 않은 시점에서 JavaScript가 Computed Style을 쿼리한다던가 하는 경우…즉, CSS, DOM에서 실행이 멈출 수 있다던지 해서 async나 defer를 이용해서 blocking을 막거나 압축을 통한 네트워크 대역폭 절약 등등 많은 내용이 있어 이것도 이후에 다시 정리합니다.

아, 초반에 "시작이 반이다"를 한글로 적어놓아 빵 터지고 '적합한 설계가 나쁜 효율성을 방지한다.'였던가로 적어놓은데서 눈물 한방울. :(



Introduction of DART


+John McCutchan의 2번째 세션, Dart도 흥미로웠습니다. 일단 Compile 형태의 개발 환경을 가지고 있지만 자바스크립트로의 변경도 가능하고 Dartrium이라는 DART VM + Chromium 형태의 브라우저에서의 JS 대비 성능 우위도 보여주더군요. 물론 VM은 Stand-alone으로 돌리거나 Dartrium에서 돌릴 수 밖에 없고 무엇보다 제가 이건 잘 모르므로 일단 넘어갑니다. :)

#

몇 가지 더 있었는데 정리가 어려워서 수정 및 다른 내용들은 차주로 미룹니다. :)