<div id="readability-page-1" class="page"><div><p>최근에 SvelteKit으로 아주 작은 서비스를 하나 만들었다. 이에 간단한 소감을 남겨본다.</p>
<p>일단 Svelte 에서 즐거웠던 점은 다음과 같다:</p>
<ol>
<li>React 에서의 여러 번잡스럽던 boilerplate 코드들이 한층 간결해졌다. 예를 들어, React에서 <code>useState</code> 를 통해 변수와 변수 업데이트 함수를 만들고, 이를 DOM에 할당하던 코드를, Svelte 에서는 그냥 <code>let</code> 로 변수를 선언하고, 바로 DOM에 할당하며, 이를 업데이트 하기 위해서는 <code>=</code> 으로 변수에 값 할당하듯이 하면 된다. 즉, 그냥 코드를 짜면 된다. 상태 변수라고 <code>useState</code> 등으로 특별 취급을 하지 않아도 된다.</li>
<li>우리가 익히 아는 그 HTML을 쓰는 점이 좋다. 더 이상 <code>className</code> 으로 쓸 필요가 없다.</li>
<li><code>svelte/store</code> 는 마치 Recoil 을 네이티브로 지원하는 기분이다.</li>
<li><code>&lt;slot name="" /&gt;</code> 은 React 의 <code>children</code> 보다 훨씬 유연하고 좋다.</li>
<li>폰트, 아이콘 적용하는데 React 버전을 찾을 필요 없다.</li>
</ol>
<p>반면 조금 의아하거나 뜨악했던 점은 다음과 같다:</p>
<ol>
<li><code>createEventDispatcher</code> 로 부모의 함수를 자식에서 실행하는 것은 편하긴 했는데, 프론트앤드 앱 코드 규모가 커졌을 때, 과연 스파게티가 되지 않을 수 있는가 하는 의심이 든다. 심지어 함수 이름을 그냥 문자열 파라미터로 넘겨버리는데, 이건 좀.</li>
<li>애니메이션 관련 스타일들을 왜 네이티브로 지원하는지 좀 뜬금없다.</li>
<li><code>{#if}</code> 나 <code>{#each}</code> 문법은 솔직히 좀 번잡스럽고 구리다. 코드 가독성에도 썩 좋지 않다.</li>
<li>Svelte 는 파일이 곧 컴포넌트인데, 난 VSCode 의 공식 Svelte 플러그인에서 컴포넌트가 사용된 위치를 검색하는(find usages by reference) 기능을 아직도 모르겠다. 프로젝트 전체에서 <code>import XX from '$lib/component/XX.svelte</code> 로 텍스트 검색을 수행해서 사용 위치를 찾는데, 솔직히 이런 방식으로는 큰 프로젝트에 사용할 수 없다. 분명 다른 방법이 있는데 내가 모르는거겠지.</li>
<li>SCSS 등을 이용해서 CSS 프로그래밍에 능한 사람들은 상관 없을텐데, 나처럼 오랜기간 stitches, emotion, styled-component 같은 CSS-in-JS 라이브러리들의 테마 기능에 의존하던 사람들에게는 스타일링 적용하는게 다소 막막하게 느껴질 수 있다. 근데 이건 Svelte 의 문제는 아니지. Tailwind CSS를 사용하면 전혀 문제없다.</li>
</ol>
<p>SvelteKit에서 장점으로 느껴졌던 점은 다음과 같다:</p>
<ol>
<li>SvelteKit 은 Next.js 의 13 버전과 매우 유사하다. 특히, 13버전에서 새로 추가된 <code>app</code> 디렉토리와 상당히 유사하다. Svelte, SvelteKit 개발자 Rich Harris가 Vercel 에 입사했기 때문에, 서로 같은 철학 하에 개발된 것이 아닌가 싶기도. 여튼 Next.js 에 익숙하다면, SvelteKit 은 매우 쉽게 시작할 수 있다.</li>
<li>SvelteKit 에서는 <code>XX.server.ts</code> 와 같이 파일 이름 뒤에 <code>.server</code>를 붙여주면 서버에서만 실행하는 코드가 된다. 매우 직관적이면서 폴더 구조에 제한되지 않는 좋은 방법이다. 예를 들어, Firebase 인증을 사용하면, 브라우저에서 실행되는 Firebase 코드의 초기화와 서버에서 실행되는 Firebase Admin 코드의 초기화가 다르다. 이 때, <code>$lib/firebase</code> 폴더 안에서 <code>auth.ts</code>, <code>auth.server.ts</code> 로 파일을 각각 생성하면, 정말 직관적이다.</li>
<li>SvelteKit 에서 예약 파일들(<code>+page.svelte</code> 처럼 이미 프레임워크에서 사용하는 파일 이름들) 이름 앞에 <code>+</code>를 붙이는건 매우 깜찍하고 익숙치 않지만, 좋은 방법인거 같다. Next.js 의 경우 아무런 표시 없이 그냥 <code>page.tsx</code> 와 같이 쓰는데, 이럴 경우, 내가 만든 파일인지 예약 파일인지 햇갈리기도 하고, 폴더 구조에서 정렬이 안되는 문제도 있다. 일괄적으로 <code>+</code>를 붙이게 되면, 폴더 내에서 정렬도 될테고 여러모로 이득이 있어보인다.</li>
<li>SvelteKit 에서 API Endpoint 를 만들 때 <code>export const POST = ()...</code> 와 같이 HTTP Method 명칭을 함수 이름으로 쓰는 것도 깜찍하다. Next.js 에서도 이렇게 해주면 좋겠다.</li>
<li>환경변수 관리가 아주 멋지다.</li>
<li>TypeScript 지원도 지금까지 본 것 중 가장 멋지다.</li>
<li><code>load</code> 함수 사용을 보니 Next.js 13 <code>app</code> 폴더의 데이터 패칭 구조가 어디서 참고한 건지 알겠다. 상당히 직관적이고 편리하다. 특히 Redirection 을 throw 처리하는건 아주 멋지다. Next.js 를 쓸 때, 개인적으로 별도 Error 클래스를 만들어서 처리하고 있었는데..</li>
</ol>
<p>SvelteKit 은 전반적으로 아주 마음에 든다. 단점이 없다. 특히 몇몇 것들은 "왜 Next.js 는 이렇게 안했지?" 싶은 것들이 있다.</p>
<p>Svelte/SvelteKit의 경험은 아주 즐거웠다. 마치 Java 를 하다가 Go 를 만났을 때의 그런 기분이다. 다만, 그 때와 마찬가지로 "이걸로 여러명의 개발자가 뒤엉켜 만드는 큰 규모의 프론트앤드 앱 프로젝트를 할 수 있을까?"라는 의구심은 좀 든다. "Reactive" 라는 개념 아래 제한없이 수많은 변수들에 접근할 수 있는데, 이게 과연 스파게티가 되지 않을 수 있나 라는 의심이 강하게 든다. VSCode 의 Svelte 플러그인은 지금도 상당히 훌륭하지만, find usages by reference 기능을 다른 언어보다도 한층 더 강화해야 수월한 개발을 지원할 수 있을 것 같은 느낌이 든다.</p></div></div>

byron1st.log

안휘

최근에 SvelteKit으로 아주 작은 서비스를 하나 만들었다. 이에 간단한 소감을 남겨본다.
일단 Svelte 에서 즐거웠던 점은 다음과 같다:
React 에서의 여러 번잡스럽던 boilerplate 코드들이 한층 간결해졌다. 예를 들어, React에서 useState 를 통해 변수와 변수 업데이트 함수를 만들고, 이를 DOM에 할당하던 코드를, Svelte 에서는 그냥 let 로 변수를 선언하고, 바로 DOM에 할당하며, 이를 업데이트 하기 위해서는 = 으로 변수에 값 할당하듯이 하면 된다. 즉, 그냥 코드를 짜면 된다. 상태 변수라고 useState 등으로 특별 취급을 하지 않아도 된다.
우리가 익히 아는 그 HTML을 쓰는 점이 좋다. 더 이상 className 으로 쓸 필요가 없다.
svelte/store 는 마치 Recoil 을 네이티브로 지원하는 기분이다.
<slot name="" /> 은 React 의 children 보다 훨씬 유연하고 좋다.
폰트, 아이콘 적용하는데 React 버전을 찾을 필요 없다.
반면 조금 의아하거나 뜨악했던 점은 다음과 같다:
createEventDispatcher 로 부모의 함수를 자식에서 실행하는 것은 편하긴 했는데, 프론트앤드 앱 코드 규모가 커졌을 때, 과연 스파게티가 되지 않을 수 있는가 하는 의심이 든다. 심지어 함수 이름을 그냥 문자열 파라미터로 넘겨버리는데, 이건 좀.
애니메이션 관련 스타일들을 왜 네이티브로 지원하는지 좀 뜬금없다.
{#if} 나 {#each} 문법은 솔직히 좀 번잡스럽고 구리다. 코드 가독성에도 썩 좋지 않다.
Svelte 는 파일이 곧 컴포넌트인데, 난 VSCode 의 공식 Svelte 플러그인에서 컴포넌트가 사용된 위치를 검색하는(find usages by reference) 기능을 아직도 모르겠다. 프로젝트 전체에서 import XX from '$lib/component/XX.svelte 로 텍스트 검색을 수행해서 사용 위치를 찾는데, 솔직히 이런 방식으로는 큰 프로젝트에 사용할 수 없다. 분명 다른 방법이 있는데 내가 모르는거겠지.
SCSS 등을 이용해서 CSS 프로그래밍에 능한 사람들은 상관 없을텐데, 나처럼 오랜기간 stitches, emotion, styled-component 같은 CSS-in-JS 라이브러리들의 테마 기능에 의존하던 사람들에게는 스타일링 적용하는게 다소 막막하게 느껴질 수 있다. 근데 이건 Svelte 의 문제는 아니지. Tailwind CSS를 사용하면 전혀 문제없다.
SvelteKit에서 장점으로 느껴졌던 점은 다음과 같다:
SvelteKit 은 Next.js 의 13 버전과 매우 유사하다. 특히, 13버전에서 새로 추가된 app 디렉토리와 상당히 유사하다. Svelte, SvelteKit 개발자 Rich Harris가 Vercel 에 입사했기 때문에, 서로 같은 철학 하에 개발된 것이 아닌가 싶기도. 여튼 Next.js 에 익숙하다면, SvelteKit 은 매우 쉽게 시작할 수 있다.
SvelteKit 에서는 XX.server.ts 와 같이 파일 이름 뒤에 .server를 붙여주면 서버에서만 실행하는 코드가 된다. 매우 직관적이면서 폴더 구조에 제한되지 않는 좋은 방법이다. 예를 들어, Firebase 인증을 사용하면, 브라우저에서 실행되는 Firebase 코드의 초기화와 서버에서 실행되는 Firebase Admin 코드의 초기화가 다르다. 이 때, $lib/firebase 폴더 안에서 auth.ts, auth.server.ts 로 파일을 각각 생성하면, 정말 직관적이다.
SvelteKit 에서 예약 파일들(+page.svelte 처럼 이미 프레임워크에서 사용하는 파일 이름들) 이름 앞에 +를 붙이는건 매우 깜찍하고 익숙치 않지만, 좋은 방법인거 같다. Next.js 의 경우 아무런 표시 없이 그냥 page.tsx 와 같이 쓰는데, 이럴 경우, 내가 만든 파일인지 예약 파일인지 햇갈리기도 하고, 폴더 구조에서 정렬이 안되는 문제도 있다. 일괄적으로 +를 붙이게 되면, 폴더 내에서 정렬도 될테고 여러모로 이득이 있어보인다.
SvelteKit 에서 API Endpoint 를 만들 때 export const POST = ()... 와 같이 HTTP Method 명칭을 함수 이름으로 쓰는 것도 깜찍하다. Next.js 에서도 이렇게 해주면 좋겠다.
환경변수 관리가 아주 멋지다.
TypeScript 지원도 지금까지 본 것 중 가장 멋지다.
load 함수 사용을 보니 Next.js 13 app 폴더의 데이터 패칭 구조가 어디서 참고한 건지 알겠다. 상당히 직관적이고 편리하다. 특히 Redirection 을 throw 처리하는건 아주 멋지다. Next.js 를 쓸 때, 개인적으로 별도 Error 클래스를 만들어서 처리하고 있었는데..
SvelteKit 은 전반적으로 아주 마음에 든다. 단점이 없다. 특히 몇몇 것들은 "왜 Next.js 는 이렇게 안했지?" 싶은 것들이 있다.
Svelte/SvelteKit의 경험은 아주 즐거웠다. 마치 Java 를 하다가 Go 를 만났을 때의 그런 기분이다. 다만, 그 때와 마찬가지로 "이걸로 여러명의 개발자가 뒤엉켜 만드는 큰 규모의 프론트앤드 앱 프로젝트를 할 수 있을까?"라는 의구심은 좀 든다. "Reactive" 라는 개념 아래 제한없이 수많은 변수들에 접근할 수 있는데, 이게 과연 스파게티가 되지 않을 수 있나 라는 의심이 강하게 든다. VSCode 의 Svelte 플러그인은 지금도 상당히 훌륭하지만, find usages by reference 기능을 다른 언어보다도 한층 더 강화해야 수월한 개발을 지원할 수 있을 것 같은 느낌이 든다.

React 개발자의 Svelte 간단 소감

댓글