구글 I/O Extended - Google's PRPL Web development Pattern
Google's PRPL Web development Pattern -신정규님-
같이 간 Seungdols님이 정리한 내용을 토대로 작성합니다.
점차 구글에서는 웹으로 접근하는지에 대하여 의문
- 모질라의 접근
- 구글의 접근
- 애플의 접근
- 페이스북의 접근
최근 10년여간에 대한 충돌이 시작
W3C
HTML 표준안 기구
문서를 강조함. 영속성에 초점을 맞춘다.
WHATWG
웹 어플리케이션 10
프레임워크다라고 강조
- HTML import
- Shadow DOM
- Custom Elements
- Templates
- WebGL
- WebAssembly
- WebPayments
두 집단의 HTML5의 정의가 다르다.
Service Worker는 구글 gears를 그대로 가져왔다고 할 수 있다.
그래서 나온 개념이 미래를 위한 PRPL 개발 패턴이 나온 것이다.
웹 페이지를 구성하는 컨셉의 변경
아래 4가지를 이용하여 패턴을 만듬
- Custom Elements
- Imports
- Service Worker
- HTTP/2
Service Worker
요청을 가로채고 처리함
응답들을 적절하게 캐시
오프라인일때 캐시
백그라운드 단에서도 캐시
Push Render Pre-cache Lazy load = PRPL 개발 패턴
Polymer Demo실무적 문제
- AWS cloudfront 가 HTTP/2를 지원 하지 않음
CloudFlare는 지원함 - 사파이 ios가 service worker를 지원 안함
강제 매니페스트로 적용 가능함 - 크롬을 제외한 브라우저들이 HTML import를 지원 안함
- WebcomponentsReady 이벤트가 네이티브 웹 컴포넌트를 지원하는 크롬에서는 작동 안함
해결코드를 추가함. - Shadow DOM은 모바일 환경에서는 완전 느림
조만간 containment 나오면 디자인쪽은 해결 됨 - Webcomponent.js는 비동기로 호출 불가능
- App-Storage의 동작을 예측할 수 없음
분기로 해결 - Django와 사용시 고민해야 함
Django-rest-flatform으로 갈아타자
좀 더 잘 정리된 글은 Seungdols에 가면 보실 수 있습니다.
아직 많이 부족하여 정리가 힘들어 정리없이 바로 올립니다.