출처 : https://www.youtube.com/watch?v=vdiYtiKD8eI
유투브 추천알고리즘이 재미있는 자료를 소개해주어 읽어봤습니다.
state of js 2023(https://stateofjs.com) 레포트를 기반으로 만들어 진 것 같은데,
개인적으로 의미있는 결과들이 보여 정리해보고자 합니다.
Vite(S) vs Next.js(S)
Vite는 사실상 프론트엔드의 스프링과 같은 포지션을 잡고 있습니다.
프레임워크 별 설정 자동화 및 단순화 기능을 지원합니다.
Vite와 Rollup.js 플러그인 사용방법만 알면 모든 프론트엔드 프레임워크를 쉽게 설정할 수 있습니다.
Next.js는 현재 프론트엔드 프레임워크 3대장 체제에서 1대장 체제로 서열정리에 성공한 리액트 프레임워크로
Vercel 자체적인 툴체인을 기반으로 웹팩 , 바벨 기반 설정 기능을 제공합니다.
vite와 호환되진 않지만 리액트 만을 쓴다면 next.js를 쓰는게 베스트죠.
현재 Vercel의 프레임워크들이 turboback 기반으로 마이그레이션 해도
많은 프로젝트들이 Vite를 계속 쓰게될 지, turbopack으로 옮겨갈 지 지켜봐야 할 것 같습니다.
이 경우 api는 vite 플러그인 보다 webpack 플러그인과 유사해질 가능성이 큽니다.
(터보팩이 브라우저 네이티브 esmodule보다 웹팩과 같이 단일 번들 위주로 방향성을 잡고 있기 때문입니다.)
Svelte (S) vs Vue (B)
Vue는 B에 위치하고, Svelte는 S랭크에 위치해 있습니다.
이 둘의 가장 큰 차이는, Svelte는 컴파일 타임에 모든 것을 처리하려 하고, (no Vdom)
Vue는 런타임과 컴파일 타임의 동작을 둘 다 이용하려 한다는 것입니다. (Vdom + template compile)
저는 Vue가 템플릿 컴파일을 선택하면서 Svelte처럼 성능 + 적은 코드 기반 DX 두마리 토끼를 잡는데 성공하지도 못하였고
런타임 동작을 선택하면서 리액트와 같이 순수 자바스크립트 + 타입스크립트임을 이용한
확장성 및 자율성을 얻는데도 실패했다고 생각합니다.
reactivity transform과 같은 코어 기능의 stable한 릴리즈에도 한 세월 걸리는걸 보면, 생태계의 추진력을 잃은것 같습니다.
Nuxt3가 힘을 못쓰는 것도 그렇고, 생태계가 더 이상 성장하지 않는다고 느껴집니다.
(Docusaurus와 Vitepress 플러그인 생태계를 비교하며 정말 뼈저리게 느꼈습니다.)
이제 탬플릿 컴파일 기반 프레임워크의 대장은 Svelte, 런타임 코드 기반 프레임워크의 대장은 React로 좁혀진 것 같습니다.
근 3개월간 Vue3를 쭉 사용해온 입장에서, Vue의 몰락은 안타깝습니다.
Playwright(S) vs Cypress(A)
후발주자가 선발주자를 앞질렀습니다.
Playwright는 사용해 본 적이 없습니다만,
요새 js 툴체인은 vscode와 vscode 디버거와의 손쉬운 통합이 가장 큰 메리트 중 하나라고 생각하는데요,
Playwright 자체가 무료에다 ms 라이브러리다 보니, vscode에 손쉽게 붙이기 편하다는 장점이 있는 것 같습니다.
그리고 속도에도 큰 장점이 있다고 하는데,
cypress가 진짜 느리다는건 의심의 여지가 없이 모두가 동의하리라 생각합니다.
https://emewjin.github.io/playwright-vs-cypress/
Typescript(S)
타입스크립트가 S 티어에 위치합니다.
부분적으로 적용하는것도 쉽고
js 코드와 떼어내서 적용할 수도 있고,
점진적 적용 방법이 상당히 많은데,
이걸 안쓴다는건 이젠 납득하기 어려운 지경에 이르지 않았나 생각합니다.
Storybook(A)
이 도구는 약간 계륵같이 느껴지기도 합니다.
스토리북 팀이 버전 7의 stable을 준비하느라 버전 6의 개선이 별로 안이루어져
vite 기반으로 설정하기도 어려우며,
react 말고 다른 프레임워크와 사용하면 생각보다 많이 불편합니다.
의외로 마땅한 대체제가 없는 상황에서도 S가 아니라 A에 있다는게 약간은 납득이 되죠
그리고 생각보다 디자인 시스템 컴포넌트화 라는 작업이,
개발자들이 UI와 디자인 에셋(토큰), CSS 정책에 대한 깊은 이해가 없으면
그냥 퍼블리싱 받아서 그때그떄 작업하는 것보다 생산성이 굉장히 떨어지는 결과가 나타날 수 있습니다.
기능 하나 붙이거나 디자인 하나 추가될 때마다, 컴포넌트의 추가, 변경이 필요하고 비용이 비싸다면,
오히려 개발 프로세스에 병목지점이 추가되는 셈입니다.
하지만 위에 언급한 조건들이 충족된다면, 컴포넌트 라이브러리 유지관리를 위해선 이만한 도구가 없긴 합니다.
좋은 프론트엔드 팀의 조건 중 하나가 해당 도구를 잘 쓰는 것이라고 생각합니다.
이 외에도 babel vs esbuild, rollup vs webpack과 같은 요소들이 있지만,
위의 프레임워크 대전 내부에 이미 녹아있는 문제라 따로 언급하진 않겠습니다.
React vs Vue vs Svelte에 대한 의견을 내보자면
워낙에 리액트의 멘탈 모델이 쉽고 간단해서
아래의 두 조건이 갖추어지는 순간 Svelte고 뭐고 간에 앞으로 계속 React만 써도 될 것 같습니다.
- react-compiler의 지원이 추가
- 이 덕택에 불필요한 리액트 훅의 갯수가 감소
- React 코드 수가 감소하고, 성능이 자동으로 최적화됨
Vue3와 React 경험을 비교해보면,
탬플릿보다 JSX를 쓰는게,
컴포넌트가 단지 마크업이 아닌 CSS(디자인), 마크업(구조), JS(기능)의 협력이라는 것이 더 잘 느껴져 좋았습니다.
또한 Vue3의 경우도 headlessUI나 Vuetify3와 같은 라이브러리는, 성능 최적화와 쉬운 구현을 위해
템플릿이 아니라 렌더 함수를 사용합니다.
이럴꺼면 리액트를 쓰는거랑 별 차이가 없는 것 같더라구요.
또한 prop을 훅처럼 선언해서 사용한다는게 손에 익지 않으면 불편했던 점이 좀 아쉬웠습니다.
스벨트와 같은 대다수의 템플릿 컴파일 기반 프레임워크를 사용하더라도 위와 같은 예시는 동일할 것 같네요.
'FrontEnd' 카테고리의 다른 글
| 멀티쓰레드 Javascript 2편 : Atomics 객체와 원자성, 직렬화 (0) | 2023.01.24 |
|---|---|
| 멀티쓰레드 Javascript 1편 : SharedArrayBuffer (0) | 2023.01.23 |
| Rollup.js 알아보기 1편 : Rollup.js 튜토리얼 (0) | 2023.01.21 |
| Content security policy[콘텐츠 보안 정책]에 대해 알아보기 (0) | 2023.01.21 |
| Vue3과 서버사이드 렌더링(SSR) (0) | 2023.01.19 |
