Recommended
Recommended
More Related Content
More from Wonjun Hwang
More from Wonjun Hwang (20)
svelte
- 1. SVELTE
- 2. Agenda 1. history 2. why svelte ? 3. svelteKit 4. svelte 현 상황
- 3. history - Ractive.js 기반 - 2016 release - vercel 합류 - 차별화된 프레임워크 Rich Harris
- 4. why svelte ? write less code No virtual DOM Truly reactive
- 10. SvelteKit Component를 고도로 최적화된 vanilla javascript로 컴파일하는 UI framework
- 12. Build Optimizations 일반적인 번들링 방식
- 13. Build Optimizations native ESM 번들링 방식
- 15. svelte 현 상황 - 컴파일러다보니 CDN을 제공하지 않음. - Edge Function 도입 예정(svelteKit) - 현저히 적은 생태계.. - 아직까진 정적인 사이트가 한계(SPA)
Editor's Notes
- vercel: 버셀
- Rative.js → 신문사 application 개발을 위해 만든 라이브러리(interactive) 실질적으로 개발자들에게 알려진 시기는 2019년 vercel은 next.js만든 회사임.. Rich Harris: Ractive는 2012-13 UI 프레임워크의 일부였으며 그 시대의 산물이었습니다. 강력하고 직관적이었지만 다른 모든 동료와 마찬가지로 런타임에 선언적 구성 요소 코드를 해석하여 작동하므로 패널티가 발생합니다. DOM을 직접 조작하기 위해 손으로 작성한 코드보다 더 큰 JS 번들과 느린 성능의 형태로 프레임워크에 대한 비용을 지불합니다. 2016년이 되자 모든 것이 바뀌었습니다. 데스크톱이 아닌 모바일이 갑자기 트래픽의 대부분을 차지하면서 번들 크기와 성능이 더욱 중요해졌습니다. Babel 및 TypeScript와 같은 프로젝트 덕분에 JS 커뮤니티는 컴파일러와 빌드 단계에 새로 익숙해졌기 때문에 선언적 구성 요소를 이해하는 컴파일러가 이를 고도로 최적화된 명령형 코드로 변환할 수 있는지 궁금하기 시작했습니다. 이 시점에서 저는 UI 프레임워크 디자인에 대해 몇 년 동안 생각했고, 모듈 번들러(Rollup)와 컴파일러(Bublé)를 구축했기 때문에 한 번 해볼 수 있는 좋은 위치에 있다고 느꼈습니다.
- virtual dom을 사용하는 react는 실제 dom을 스냅샷을 떠놓은 뒤, virtual dom에서 스냅샷과 비교를 먼저하고 실제 dom에 반영하는 방식(이 과정에서 오버헤드가 발생할 수 있다고 함) 커뮤니티에서는 아직도 svelte vs react 성능 이슈로 싸우고 있음.. svelte가 react보다는 더 빠를 수 있지만 svelte보다 더 빠른 virtual dom 방식도 존재함..(inferno) virtual dom이라는게 기능이 아니라 단순히 수단이기 떄문에 꼭 필요한건 아님. Svelte는 빌드 타임에 돔을 업데이트하는 효율적인 명령 코드로 변환하기 때문에 컴파일러라고 하는듯
- truly reactive ⇒ 함수나, 조건문에도 반응형 구현이 가능 상태 관리 라이브러리가 필요 없음. ⇒ javascript 자체에 대한 반응성을 제공함. 옵저버 패턴 사용함. 순차실행 x , 토폴로지 방식 $$.dirty : 어떤 객체가 변경되었는지 감지하여 실행
- Svelte 앱을 구축하기 위한 프레임워크 !
- build optimizations: 최적화하여 구축 hook: 상태관리 로직 추상화 achor options: prefetch, reload page options: prerender, hydrate, router
- cold-starting방식으로 개발 서버 구동시 애플리케이션 내의 모든 소스 코드에 대한 크롤링 및 빌드 작업을 마쳐야지만 실제 페이지 제공 가능 (cold-starting → 최초로 실행되어 이전에 캐싱한 데이터가 없는 경우) 기존 번들링 방식은 모든 소스코드의 모듈을 묶어 번들링
- bundling: 모듈화된 소스 코드를 브라우저에서 실행할 수 있는 파일로 묶어주는 작업 vite는 es modules(ESM) 및 네이티브 언어로 작성된 javascript 도구 등을 활용해 해결(원래 vue를 위해 만들어짐 - but 지금은 아님) esbuild를 활용(webpack, parcel같은 번들러보다 훨씬 빠름) - go로 작성됨. dependencies와 source code를 분리하여 빌드함 dependencies(패키지)는 설치후 내용이 바뀌지 않고 소스코드는 빈번이 바뀌기 때문에 미리 esbuild로 트랜스파일링 해놓은 뒤, 소스 코드를 불러오면서 의존성이 있는 패키지만 가져옴.
- esbuild의 성능.. three.js 라이브러리를 10개 카피하여 번들링 테스트를 해봤다고 함.
- edge function은 속도가 빠르지만 정적인 컨텐츠만을 제공할 수 있는 CDN, 동적으로 매 요청마다 랜더링이 가능하지만 속도가 느린 동적 서버 ⇒ 모두 극복 가능 아직은 next.js에서만 사용가능(beta 버전임)
- edge function은 속도가 빠르지만 정적인 컨텐츠만을 제공할 수 있는 CDN, 동적으로 매 요청마다 랜더링이 가능하지만 속도가 느린 동적 서버 ⇒ 모두 극복 가능 아직은 next.js에서만 사용가능(beta 버전임)