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
5. React write less code
6. Vue write less code
7. Svelte write less code
8. no virtual DOM
9. Truly reactive
10. SvelteKit Component를 고도로 최적화된 vanilla javascript로 컴파일하는 UI framework
11. SvelteKit Build Optimizations service workers page options hooks anchor options
12. Build Optimizations 일반적인 번들링 방식
13. Build Optimizations native ESM 번들링 방식
14. Build Optimizations
15. svelte 현 상황 - 컴파일러다보니 CDN을 제공하지 않음. - Edge Function 도입 예정(svelteKit) - 현저히 적은 생태계.. - 아직까진 정적인 사이트가 한계(SPA)
16. Thank you 출처 - https://blog.bitsrc.io/react-vs-sveltejs-the-war-between-virtual-and-real-dom-59cbebbab9e9 - https://svelte.dev/

Hinweis der Redaktion

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 버전임)

svelte

Du liest eine Vorschau.

Hier ansehen

svelte

Weitere Verwandte Inhalte

Weitere von Wonjun Hwang (20)

Aktuellste (20)

svelte

Hinweis der Redaktion