Svelte

컴포넌트 기반 UI 개발의 패러다임을 주도한 React가 등장한지도 어느 덧 10년이 넘었네요. 이제 Vue.js, Svelte, Angular 등 어떤 프론트엔드 프레임워크를 사용하든 현대 웹 개발에서 컴포넌트 기반으로 UI 개발하는 것은 거의 당연한 얘기가 되었죠. 그리고 마침내 웹 컴포넌트(Web Components)를 통해서 별다른 프론트엔드 프레임워크가 없어도 UI 컴포넌트를 만들 수 있는 길이 활짝 열렸습니다.

웹 컴포넌트는 웹사이트나 애플리케이션에서 UI를 모듈화하고 재사용할 수도록 해주는 웹 표준 기술입니다. React와 같은 프론트엔드 프레임워크에서 오랫동안 경험해왔던 UI 컴포넌트를 떠올리시면 이해가 쉬우실 것 같습니다.

React 컴포넌트는 React에서만 쓸 수 있고, Vue.js 컴포넌트는 Vue.js에서만 쓸 수 있는 근본적인 한계가 있습니다. 하지만 웹 컴포넌트는 이와 같은 구애를 받지 않고 어떤 프론트엔드 프레임워크와도 함께 쓸 수 있습니다. 왜냐하면 웹 컴포넌트는 브라우저에서 네이티브(native)하게 작동하기 때문입니다.

이러한 웹 컴포넌트의 띄어난 호환성과 이식성, 재사용성 및 생산성 덕분에 최근에는 디자인 시스템(Design System)을 구현하는 최고의 기술로 주목받고 있습니다.

모든 기술이 그러하든 웹 컴포넌트가 장점만 있는 것은 아닙니다. 대표적인 단점으로 API가 직관적이지 않다고 평가받고 있고, 배우기 쉬운 기존 프런트엔드 프레임워크 대비 진입 장벽이 높은 편입니다. 그래서 실제 프로젝트에서는 이러한 단점을 보완한기 위해서 웹 컴포넌트를 직접 작성하기 보다는 Lit나 Stencil과 같은 라이브러리를 많이 사용합니다.

웹 컴포넌트은 크게 다음 세 가지 핵심 기술로 이루어집니다.

• Custom Elements: 사용자 정의 HTML 요소(element) 또는 태그(tag)를 정의할 수 있습니다.

• Shadow DOM: DOM 트리의 일부를 캡슐화하여 스타일과 마크업이 외부와 충돌하지 않도록 해줍니다.

• HTML Templates: 화면에 나타나지 않는 HTML 조각(fragment)을 정의해놓고 재사용할 수 있습니다.

이 웹 표준 기술들은 현재 주요 브라우저에서 모두 지원되고 있습니다.

이번 포스팅에서는 각각의 기반 기술을 하나씩 살펴보면 웹 컴포넌트의 기본 개념을 잡아보도록 하겠습니다.

📝 포스팅: https://www.daleseo.com/web-components/

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)입니다. 잘 나가던 라이브러리도 순식간에 나락갈 수 있다는 것을 잘 보여주는 예라고 할 수 있겠네요 😓

개발자 경험을 중요시하는 트렌드에 따라서 최근에 나오는 자바스크립트 프레임워크는 대부분 프로젝트를 편리하게 구성할 수 있도록 명령줄 도구(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 원칙을 준수해 개발해야돼서 머리가 꽤 아프지만.. 좋은 선택지임에는 틀림없다고 생각한다.

jQuery는 더 이상 새로운 버전이 안 나올 줄 알았는데 4.0 베타 버전이 출시되었네요. 곧 출시된 버전 4.0에서는 IE 10까지 지원이 종료되고, 추후 출시될 버전 5.0에서는 IE 11까지 지원의 종료하면서 jQuery 마저도 IE 지원을 완전히 종료한다고 선언하였습니다. jQuery를 썼던 큰 이유는 IE와 타 브라우저 호환성 문제였는데 jQuery의 이러한 변화는 시사하는 바가 큰 것 같습니다.

📝 관련 포스트: https://blog.jquery.com/2024/02/06/jquery-4-0-0-beta

2006년에 출시되었던 jQuery는 한 때는 자바스크립트 개발이 곧 jQuery 개발이라고 여겨질 정도로 정도로 상당히 오랫동안 자바스크립트 생태계를 주름잡던 라이브러리입니다. 하지만 최근에는 React, Angular, Vue.js, Svelte와 같은 모던 자바스크립트 라이브러리에 밀려 주로 레거시(legacy) 코드에서나 미처 못해 쓰는 라이브러리로 전략하고 말았는데요.

jQuery 새로운 버전을 출시하더라도 얼마나 많은 프로젝트에서 업그레이드를 할 지는 의문입니다. 이미 컴포넌트 기반의 웹 프로그래밍이 대세가 된 상황에서 jQuery가 이번 업그레이드를 통해 과연 과거의 영광을 얼마나 되찾을 수 있을지 궁금해지네요.