DEV Community

Composite
Composite

Posted on • Updated on

SVELTE의 개선해야 할 점

The plain english of this article for non-korean users:

  • The Cons of SVELTE
    • Proprietary(Closed) community
    • No Compiler Extension for customization of SVELTE
    • Hard to hydrate(SSR)
  • But I like SVELTE and I hope to grow up this ecosystem.

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 쓰던가 해야 하는 상황...

끗.

Top comments (6)

Collapse
 
tsmvision profile image
Luke Lee

1년 지난 글이긴 하지만...

"지금은 자바하고, 닷넷의 안좋은 기억만 굳어졌기 때문에." -> 닷넷은 그렇다 치고, 자바는 왜 안좋은 기억만 굳어졌나요?

frontend, backend를 자바나 닷넷으로만 모두 해결하려면, 좀 그렇지만, 백엔드용도 (rest api 등등)로만 사용하기에는 두 플랫폼 다 충분히 좋다고 생각하는데요,

frontend를 react든 svelte든 선호하는 javascript framework로 진행하고,
rest api든 기타 백엔드는 위 두언어중 선호하는 걸로 하는 것도 충분히 괜찮다고 생각하는데요,

뭐 나중에 또 새로운 블링블링 한 거 나오면 다시 옮겨타야하는게 개발자의 숙명이지만, 현재로는 위의 frontend/backend로도 왠만한 일반적인 웹개발은 커버된다고 생각하는데요??

Collapse
 
composite profile image
Composite • Edited

옛날에 닷넷 하다 자바로 전향한 사람들은 닷넷이 어떻게 흘러갔는지 아는 사람이 전무합니다. Blazor 존재 자체조차 모릅니다. 즉, 아예 관심을 끊어버린 거죠.
한 번은 제가 알려준 기회가 있었습니다. 하지만 반응은 냉담했죠. 그저 전자정부와 제이쿼리가 업계 표준이니 그거 써야 한다. 끝. 그냥 대충 내뱉어버린 충격적 답변을 받았습니다.

이분들은 나이도 드셨으니... 아무래도 전향은 힘들 것 같습니다. 차라리 젊은 꿈나무를 키우는 투자가 더 값지겠더군요.

Collapse
 
tsmvision profile image
Luke Lee • Edited

주제랑 직접관련은 없지만, 얘기 드리고 싶은 내용 조금 적어봅니다.

일단 제가 해외거주중이라 본인이 느끼시는 거랑 좀 의견이 다를지도 모르겠습니다.

(1) 현재 한국에서 대세언어는 Java이고, C#/Asp.net은 마이너리티임.

아시다시피, 한국에서 대다수의 프로젝트는 java/spring 기반입니다. 이쪽 전문가들이 굳이 마이너리티 기술인 C#/asp.net/Blazor에 관심을 가질 이유는 없을 것으로 보입니다. (기술적인 이유가 아니라 현실적인 이유로요.. C#/asp.net 6는 정말 좋은 기술입니다.)

(2) 모든 개발자가 ployglot이지도 않고, 그렇기도 힘들고, 그럴 필요도 없다.

대개의 개발자들이 본인 메인 언어 (한국에서 backend면 거의 Java 일 듯.)를 픽한다음, 거기서 깊이를 더하고, 커리어를 쌓아갑니다.

특정 테크 기업은 여러기술/언어를 동시에 한 프로젝트에 사용하기도 하고, 또는 개발자 본인이 성장욕구가 있어서 비주류 기술/언어를 개인시간에 배우기도 하겠지만, 모두가 그런 건 아닙니다.

(3) 현실 프로젝트에선 한 기술 제대로 할 줄 아는 사람이 훨씬 도움이 됨.

현실 프로젝트에서는 사실 한 기술 제대로 할 줄 아는 사람이 여러기술 대충 아는 사람보다 훨씬 도움이 됩니다. (java/spring 하나 빠삭하게 잘하는 사람이 java, python, c#, golang 다 할줄은 알지만 모두 주니어레벨인 사람보다 훨씬 도움이 되죠.)

(4) 해외(미국)에서는 다양한 기술, 언어가 사용되지만, 여전히 자바 일자리는 매우 많습니다.

미국의 경우에 지역마다 선호하는 언어, 기술 스택이 다 조금씩 다르지만, 그래도 자바는 매우 매우 일자리가 많습니다.

c#/asp.net 스택도 일자리가 매우 많습니다. (한국과 다른 점이죠.)

(5) 한국의 현실에 대한 개인적인 의견

기술 발전, 다양성도 중요하지만, 결국은 IT든 뭐든 비즈니스 잖아요(다 먹고살자고 하는 것들...)

얼마나 개발자를 쉽게 구할 수 있냐, 같은 것을 구현 (유지보수 포함)하는데 비용과 시간이 적게 드느냐가 관건이기 때문에, Java가 메인스트림인 한국에서 단기간에 뭐가 갑자기 바뀌지는 않을 것 같네요.

만약 자바만큼 사람구하기도 쉽고, 같은 기능 구현에 비용도 비슷하거나 적게 드는 기술이 있다면(그게 python이든 javascript든 c#이든 간에) 장기적으로는 java를 대체해 나가겠죠.

하지만, 이미 깔린 인프라, 인력풀이 단시간에 드라마틱 하게 바뀌는 건 어려우리라 봅니다.

(6) 쿨한 새로운 언어/프레임워크/기술 사용하는 방법

SI 시장이라면 당연히 보수적이고, 하던 대로 하려는 경향이 강하겠지만 (유튜브 채널 몇몇 보니까 한국 SI시장도 프로젝트에 따라서 frontend/backend 분리하고 react 쓰고 뭐 그런다던데요...), 테크 기업 가시면 새로운 기술 많이들 시도한다고 들었습니다.

결론적으로 한국/해외 테크기업을 가시던지, 아니면 본인이 테크 스타트업을 차리시던지 하시면, legacy stack에 스트레스 안받고 새로운 기술들 마음껏 적용가능 하실 것 같네요.

PS. 개인적으로는 2021년에 jquery랑 java jsp 같은 걸로 신규 프로젝트 한다고 하거나, 유지보수 하라고 하면 전 절대 그런덴 안갈것 같네요. 굶어죽을 상황 아니면...

Thread Thread
 
composite profile image
Composite

SI/SM 은 네이버 입김이 강해서 vue 위주입니다. 하지만 전자정부에 프론트엔드 샘플이 react 라 그쪽으로 기울어지기 시작했습니다.
아 그리고 저는 굶어죽을 상황 맞네요...ㅠㅠ

Thread Thread
 
tsmvision profile image
Luke Lee

네, 기술논쟁이니 뭐니 해봐야 밥그릇 앞에서는 무의미하죠. 파이팅 하세요!!

Collapse
 
darrellgrimm profile image
DarrellGrimm

Though Svelte is a new to the tribe, it eliminates the need to ... It means Svelte offers great performance . thanks for posting it will be so informative . surah taha for marriage