SVELTE의 개선해야 할 점

1. 닫혀 있는 커뮤니티

스벨트는 내가 생각했던 것보다 상당히 닫혀 있는 커뮤니티인 점에 놀랐다. 이슈가 올라와도 컨트리뷰터의 결정에 따라 이슈가 순식간에 닫힌다.
물론 스벨트도 스벨트 나름대로 기준이 있고, 그 기준에서 벗어나려 하면 스벨트 자체 생명주기에 지장이 생길 수는 있다.
가뜩이나 커뮤니티 규모도 작고 한정적인데, 리액트와 뷰의 부족함을 스벨트로 채우려 하면... 열에 아홉은 그냥 컨트리뷰터에 의해 반려된다고 보면 된다.

2. 컴파일러 확장의 부재

스벨트의 매력은 바로 컴포넌트를 트랜스파일로 하여금 성능과 메모리 관리 효율을 최대한 이끌어낸다에 있다. 이건 리액트와 뷰에서 차별화할 수 있는 부정할 수 없는 사실이다. 하지만 이를 통해 잃은 게 뭐냐, 바로 UMD의 부재다. UMD의 부재는 이미 스벨트 참여자들도 인지는 하고 있지만, 우선순위는 낮다고 한다.
그렇다면, 스벨트가 확장성이 높다고는 하지만 정작 중요한 확장성이 없다.
바로 스벨트를 컴파일러하는 모듈의 확장이 없다는 것이다.
이걸 격하게 느낀 게 바로 use 속성, 즉 액션이다.
스벨트는 컴포넌트의 스크립트적 확장을 위해 액션을 지원하고, 간결하며 강력하다. 심플의 미학을 선호하는 나에게 이 구문은 신선했다... 하지만 그것도 잠시. 멀티 액션을 지원하지 않는다. 아무도 이슈를 제기하지 않았다. 내가 이슈를 제기하려고 했지만 마땅한 대안이 떠오르지 않는다. 왜냐? 스벨트 만진 지 얼마나 됐고, 게다가 내가 내세울 수 있는 게 뭐가 있을까... 다.
그래도 일단 최대한 어필은 해야 하니, 컴포넌트 내 액션 멀티 사용을 이슈에 제안은 해볼 생각이다.
하지만 내 궁극적인 이슈는 바로 컴파일 확장의 부재다. 어쩌면 개인적인 문제일 수도 있겠지만, 사실 리액트와 뷰는 있는데 스벨트에게 가지지 않은 문제점이 있다면 바로 Custom directive가 없다는 것. 이걸 해결하려면 결국 컴파일러를 건드려야 하는 상황이다. 하지만 스벨트 해킹 말고는 답이 없다. 확장을 제공해주지 않기 때문이다. 사용자는 결국 스벨트 자체를 fork 하여 어렵게 해결해야 한다. 프로젝트는 급한데 보증없는 영역에 누가 끼어들려고 할까? 나는 그럴 시간이 없기에 결국 스벨트를 잠시 뒤로했다. 내게 필요한 이슈만이라도 해결할 때까지는.

3. 미약한 SSR

위 문제 때문에 그들이 만든 Sapper 에서 한계가 너무 여실히 드러난다.
기능이 상당히 제한적이고, 게다가 스코프도 너무 애매하다. 단도직입적으로 말하자면? next.js 어설프게 따라하다 만 느낌이다. 그나마 뷰의 nuxt.js 는 대놓고 패러디성에 next.js 갖다 배꼈다는 느낌을 지울 수는 없지만, Vue 공식 프로젝트 답게 Vue 생태계 특성을 잘 살려낸 모방이 창조의 어머니라 불릴 만하기 때문이다. 게다가 오픈소스니 누가 태클을 걸까? 오픈소스가 원래 이렇게 크는건데.
물론 클라이언트 접근은 OnMount 같은 이벤트를 등록하면 된다지만,
정작
내가 Sapper 프로젝트를 시도해봤는데, SSR에 한해서는 결국 next.js로 넘어갔다.
리액트가 좋아서? 아니, next.js가 좋아서다. 짬밥은 무시할 수도 없거나와 Vercel(구 zeit)이 구축해놓은 프론트엔드 생태계 영향을 아무리 해도 무시할 수 없기 때문에. (그건 뷰도 인정한 바, 리액트 따라한 것도 있고, 반대 케이스도 있다.)
일단 이번달에 진행한 스벨트 웨비나에서 Sapper 를 걷어낸다고 공언한 바 있다. (1.0은 영영 못본다). 대신, 새로운 SSR 프로젝트를 개발한다고 한다. 이른바 SVELTE Kit. 통합 패키지로 갈 생각인가 보다. 물론 소스도 오픈되어 있으나, 아직 문서가 없고 지켜볼 단계이지만, 태클을 걸지 않으면 발전이 없을 것 같다는 생각이 안들래야 안들 수가 없는 것 같다. 프로젝트 환경이.

마치며

마칠 것도 없다. 하지만 난 스벨트가 커졌으면 좋겠다. 그들이 제시한 방향성은 나도 공감이 큰 바이며, 스벨트를 포기할 생각은 없다. 단지, 상용 프로젝트에서는 요구되는 구조 상 안맞아 당장 도입이 힘들다는게 내 생각이다.

잠시 Blazor Server 프로젝트로 갈까 했는데, 기성 닷넷 개발자들이 의외로 강력하게 반대했다. 왜냐고? 지금은 자바하고, 닷넷의 안좋은 기억만 굳어졌기 때문에.
닷넷 코어 이후 닷넷은 아예 환골탈태를 했다지만, 이미 무너져버려 근본없는 프레임워크 취급받는 한국의 찬밥 신세를 어떻게 뎁힐 것인가? 마소 코리아가 직접 나서야 할 것 같지만, 이미 나델라는 이런 건 커뮤니티가 나서야 할 일이라 공언한 사항이기 때문에, 아마 한 번 떠난 닷넷을 다시 되돌리기엔 너무 빡셀 것만 같다.

잠시 만져봤는데, 강력한 웹폼의 경량화 모델을 충실히 구현했던 게 마음에 든다. 하지만 문제는 종속성 주입이 더럽게 불편하다. 모델 자체는 스프링보다 더 혁신적이지만, 여전히 프로젝트 자체는 개발자들에게 상당히 불친절하다. 초창기 node.js 웹 서버 프로젝트 따라간 티를 벗어날 생각이 없었던 걸까... 마소는 그거 개선할 생각 없다고 하니 나 참... 할 말이 없다. Autofac 쓰던가 해야 하는 상황...

끗.