Svelte

State of JS 2023 설문 결과에는 매우 흥미로운 데이터가 있습니다. 바로 자바스크립트의 주요 라이브러리들을 리텐션(retention)에 따라 급(tier)을 나눈 건데요. 즉, 퍼센트가 높을수록 해당 라이브러리에 대한 경험이 좋아서 계속해서 쓰길 원하는 응답자가 많다는 뜻입니다 🤗

영광의 S티어는 Vite, Vitest, Playwrite, pnpm, MSW, esbuild, SWC, Testing Library, Astro가 차지했는데요. 아마 큰 이견이 없이 대부분의 자바스립트 개발자들에게 사랑받고 있는 라이브러리일 것입니다. 올해는 Svelte와 Storybook이 A티어로 밀려날 정도로… 요즘 라이브러리 간에 경쟁이 치열하고, 개발자들의 기대치가 참 높아졌구나라는 생각이 들었습니다.

B티어에는 비교적 연식이 쫌 된 굴직한 라이브러리가 주로 포진해 있습니다. 대표적으로 React와 Vue를 들 수 있죠. 그럼에도 불구하고 이 두 라이브러리를 사용한다는 응답자는 작년보다 오히려 증가하였습니다. 아무래도 많이 쓰이는 만큼 불만도 많고 이탈도 많은 게 아닐까요? 시장 점유율이 워낙 높아서 좋든 싫든 프론트엔드 개발자로 먹고 살려면 써야하는 라이브러리가 된 느낌입니다 😂

마지막으로 C티어에는 다양한 이유로 인기가 예전같지 않은 라이브러리들이 꽤 보이는데요. 최근에 빌드 도구의 세대 교체가 활발히 일어나면서 Webpack과 Parcel은 점점 설 자리를 잃어가고 있는 것 같습니다. Angular의 하락세는 수년간 지속되어 와서 이제는 그닥 놀랍지도 않네요.

개인적으로 제일 눈에 띄는 부분은 Gatsby의 몰락입니다. C티어 내에서도 최하위권이죠. Gatsby는 몇 년전만 해도 Next.js와 어깨를 나란히 하던 React 기반 정적 사이트 생성기(Static Site Generator)입니다. 잘 나가던 라이브러리도 순식간에 나락갈 수 있다는 것을 잘 보여주는 예라고 할 수 있겠네요 😓

어떤 프론트엔드 프레임워크를 활용할지 고민되시나요?

커리어리에서 주요 프론트엔드 프레임워크 정보와 생생한 리뷰를 바탕으로 비교 후 결정하세요!

리뷰는 각 라이브러리 게시물의 댓글에서 보실 수 있어요.

사용해봤던 라이브러리라면 다른 유저분들을 위해 리뷰를 남겨주세요. 리뷰를 작성해주시는 분들께는 감사의 마음을 담아 스타벅스 기프티콘을 보내드릴게요.
각자의 개발 경험을 나누고, 때론 도움을 얻을 수 있는 공유의 장이 되기를 바라요 💡

1. React (📌상세 정보 및 리뷰 보러 가기 : https://careerly.co.kr/comments/92538)

   1. 개요 : 사용자 인터페이스를 만들기 위한 자바스크립트 라이브러리 (웹 프레임워크)

   2. github star : 214k

   3. 라이센스 : MIT License

   4. 공식 문서 링크 : https://react.dev/

2. Svelte (📌상세 정보 및 리뷰 보러 가기 : https://careerly.co.kr/comments/92539)

   1. 개요 : 개요 : 웹 애플리케이션을 구축하는 새로운 방법. 선언적인 컴포넌트를 가져와서 효율적인 JavaScript로 변환하여 DOM을 정교하게 업데이트하는 컴파일러. 따로 프레임워크를 로딩하지 않기에 기존 프론트엔드 기술보다 빠른 웹 어플리케이션을 만들 수 있음.

   2. github star : 73.1k

   3. 라이센스 : MIT License

   4. 공식 문서 링크 : https://svelte.dev/docs/introduction

3. Vue (📌상세 정보 및 리뷰 보러 가기 : https://careerly.co.kr/comments/92540)

   1. 개요 : 웹 페이지 화면을 개발하기 위한 JavaScript 프레임워크. 가벼운 크기와 직관적인 문법으로 SPA 개발에 적합.

   2. github star : 206k

   3. 라이센스 : MIT License

   4. 공식 문서 링크 : https://vuejs.org/guide/introduction.html

4. SolidJS (📌상세 정보 및 리뷰 보러 가기 : https://careerly.co.kr/comments/92541)

   1. 개요 : 사용자 인터페이스를 구축하기 위한 선언적, 효율적이고 유연한 JavaScript 라이브러리. 컴포넌트 내부에 선언한 함수가 한번만 실행되며 로직, 상태 업데이트를 리엑트보다 쉽고 직관적으로 인지할 수 있음.

   2. github star : 29.2k

   3. 라이센스 : MIT License

   4. 공식 문서 링크 : https://www.solidjs.com/docs

React vs Svelte vs Vue vs SolidJS 비교 데이터 (npm trends)

• https://npmtrends.com/react-vs-solid-js-vs-svelte-vs-vue

📭라이브러리 추가 / 정보 추가 / 기능 제안 등 피드백 남기기 > https://tally.so/r/3y4zy0

어제 Vite 5가 출시되었습니다. 한 달 전에 ViteConf 2023에서 발표된 것처럼 Rollup 4가 사용되며, CJS Node API가 폐기(deprecated)되었습니다. 자세한 내용은 아래 공식 블로그를 참고 바랍니다.

📣 공지 글: https://vitejs.dev/blog/announcing-vite5

자바스크립트 생태계에서 Vite의 성장세가 심상치 않은 것 같습니다. 바로 지지난 주에 Remix가 v2.2.0부터 Vite를 지원한다고 발표했는데요. Remix가 왜 이제서야 Vite를 사용하는지에 대한 이유를 밝히면서, 그 동안 자기들이 Vite보다 부족했던 부분을 솔직하게 털어놓았습니다. 관련 내용은 아래 공식 블로그를 읽어보시면 좋을 것 같습니다.

📝 관련 글: https://remix.run/blog/remix-heart-vite

Remix의 Vite 생태계 합류로 SvelteKit, Nuxt, Astro, Solid Start, Qwik City, RedwoodJS 등등 Next.js 제외한 왠만한 메타프레임워크는 이제 모두 Vite 위에서 돌아간다고 해도 과언이 아닌 것 같습니다. Bun, Deno와 같은 런타임, Storybook, Playwright, Nx와 같은 개발 도구는 말할 것도 없고요.

State of JS 2022의 빌드 도구 부분 설문 결과에서 Webpack 사용률이 89%에서 85%로 소폭 떨어진 반면에 Vite 사용률은 30%에서 49%로 대폭 상승했었는데요. 벌써부터 내년 State of JS의 설문 결과가 궁금해지네요. Vite 공부를 생각하고 계셨다면 미루셨다면 지금이 적기일지도 모르겠습니다.

개발자 경험을 중요시하는 트렌드에 따라서 최근에 나오는 자바스크립트 프레임워크는 대부분 프로젝트를 편리하게 구성할 수 있도록 명령줄 도구(CLI)를 제공하고 있습니다.

그런데 각 프레임워크의 문서를 확인해보면 프로젝트를 생성하는 방법이 조금씩 다르다는 것을 알 수 있는데요.

예를 들어, React 기반 SPA(Single Page Application)을 생성할 때 많이 사용되는 Create React App의 문서를 보면, `npx` 명령어나 `npm init` 명령어를 사용하고 있습니다.

```sh

$ npx create-react-app my-app

```

```sh

$ npm init react-app my-app

```

다른 예로, React의 대표적인 메타 프레임워크인 Next.js 문서를 보면 `npx` 명령어를 사용하고 있습니다.

```sh

$ npx create-next-app@latest

```

Svelte나 Vue.js 쪽은 어떨까요? Svelte 문서와 Vue.js 문서를 보면 `npm create` 명령어를 사용하고 있습니다.

```sh

$ npm create svelte@latest myapp

```

```sh

$ npm create vue@latest

```

하나의 명령어로 통일하면 좋을텐데 왜 이렇게 헛갈리게 다른 명령어를 사용해서 프로젝트를 생성하라고 하는지 궁금하지 않으세요?

이번 포스팅에서는 자바스크립트 프로젝트 생성할 때 자주 보게되는 `npm init`, `npm create`, `npx`, 이 세 가지 명령어에 대해 샅샅이 파헤쳐 보겠습니다!

📝 포스팅: https://www.daleseo.com/js-npm-init/

자바스크립트를 공부하고 계시다면 아래 게시물도 함께 읽어보시기를 추천드립니다.

📕 자바스크립트 개발자를 위한 package.json 파일 정리: https://careerly.co.kr/comments/90359

📗 패키지 잠금 파일 (package-lock.json, yarn.lock): https://careerly.co.kr/comments/93535

📘 자바스크립트 개발자를 위한 필수 npm 커맨드 정리 (+npx): https://careerly.co.kr/comments/93003

📙 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/92202

📓 자바스크립트 패키지 매니저: npm vs. Yarn: https://careerly.co.kr/comments/94203

URL이 바뀔 때 마다 새로운 페이지를 서버로 요청하지 않는 SPA(Single Page Application)에서는 보통 클라이언트 단에서 라우팅(routing)을 하는데요. 그래서 React, Svelte, Vue.js와 같은 대부분의 프론트엔드 프레임워크을 사용할 때는 이러한 클라이언트 단 라우팅을 지원하는 라이브러리와 함께 쓰는 경우가 많습니다.

그런데 이러한 라우팅 라이브러리는 대부분은 내부적으로 자바스크립트의 History API를 사용하고 있다는 것을 알고 계셨나요? 이번 글에서는 클라이언트 단 라우팅을 이해하는데 핵심적인 자바스크립트의 History API에 대해서 알아보고 간단한 실습도 진행해보겠습니다.

📝 포스팅: https://www.daleseo.com/js-history-api/

🧑‍💻 실습 코드: https://codepen.io/daleseo/pen/JjwPBwv

실제 애플리케이션을 개발하실 때는 이미 많은 프로젝트에서 검증이 된 유명한 라우팅 라이브러리를 사용하실테니 이렇게 직접 라우팅을 구현할 일은 없으실 것입니다. 하지만 라우팅 라이브러리가 내부적으로 어떻게 동작하시는지 이해하신다면 버그가 생겼을 때 디버깅이 용이해지고 나중에 다른 프론트엔드의 라우팅 라이브러리를 배울 때도 큰 도움이 될 것입니다.

앞으로 프론트엔드에서 어떤 기술이 중요해질까?

React? Vue? Svelte? 아니면 Next 또는 Nuxt 같은 프레임워크?

위 기술들도 분명 중요한 기술들임에는 틀림없지만 나는 그보다 Web Component가 더 중요해질거같다는 생각이 든다.

https://developer.mozilla.org/en-US/docs/Web/API/Web_components

물론 회사 상황에따라 다르다.

서비스 코드가 일괄적으로 하나의 기술로만 구현되어있다면 해당 기술을 사용해 공통 컴포넌트를 만들어놓으면 될 것이다.

하지만 서비스 코드가 프로젝트마다 다른 기술로 개발되어있다면?

(이런 일이 흔하지 않을거라고 생각할 수 있지만, 내 주변에 의외로 이런 일이 많이 발생하고 있다. 솔직히 우리 회사처럼 다양한 기술들을 사용하진 않았더라도 React와 Vue를 같이 사용하는 회사들은 많다. 심지어 많이 사용하지 않는 기술.. Svelte가 될 수도 있고.. 우리회사는 WoowahanJS가 있고.. 과거에 많이 사용했던 JSP도 있고.. 이런 기술들을 사용한 곳도 많이 있을 것이다.)

그러면 각 기술별 공통 컴포넌트를 만드는건 엄청나게 귀찮고 어려운 작업이 될 것이다.

똑같은 기능을하는 컴포넌트를 각 기술마다 따로 만들어야되기 때문이다.

이러한 문제를 해결해주는 것이 Web Component이다.

위 기술은 표준화된 기술로 대부분의 브라우저에서 지원하고 있다.

그리고 공식적으로 재사용 가능한 컴포넌트를 만들기위한 기술이라고 명시되어있다.

그렇기 때문에 위 기술로 공통 컴포넌트, 디자인 시스템을 만들어놓으면 해당 서비스에서 어떤 기술을 사용하던 기술에 구애받지않고 개발을 할 수 있다.

또한 기능을 캡슐화하고 slot 이란 장치를 이용해서 기존 코드를 건드리지않고 특정 기능을 부여할 수 있기까지하다.

마치 데코레이터처럼.

지금 회사에서 실제로 JSP, WoowahanJS, React, Vue3로 되어있는 서비스를 위 Web Component 기술을 사용하여 개발하고 있는데 만족도가 굉장히 높다. (이런 프로젝트가 있을 수 있어?라고 생각할 수도 있지만 실제로 있을 수 있다.)

Web Component 기술로 공통 컴포넌트(또는 디자인시스템)를 Headless UI 방식으로 개발해놓으면 그 컴포넌트를 모든 기술에서 가져다 사용할 수 있다.

즉, 프레임워크 자유도가 확 올라가는 것이다.

사실 개발자라면 다들 새로운 기술, 보다 더 좋은 기술에 대한 욕심이 조금이라도 있을 것이다.

하지만 현실의 벽에 부딪혀 실행에 못 옮기는 분들이 많을 것이다.

개발 일정도 준수해야되고.. 괜히 신기술을 사용했다가 다른 프론트엔드 개발자의 러닝커브만 높이게되고..

하지만 이 벽을 깨고싶다면, 이 벽을 깨서 기술 선택의 자유도를 높이고 싶다면, Web Component를 사용해보는 것도 좋은 방법이 될 것이다.

물론 이걸하려면 Web Component와 Litjs를 따로 좀 학습해야되지만.. (litjs는 Web Component를 보다 더 쉽게 개발하게 해주는 프레임워크이다. 사실 이런 프레임워크들은 따로 많이 있지만(Stenciljs 등) Litjs를 제일 많이 사용하는거같아 선택했다.)

그리고 무엇보다도 Headless UI 원칙을 준수해 개발해야돼서 머리가 꽤 아프지만.. 좋은 선택지임에는 틀림없다고 생각한다.