오늘 한번 리액트 개발자들을 내가 시험하려 들 것이다. 함수 컴포넌트 기준이다. 틀니 달고 클래스 컴포넌트 쓰고 싶지 않다. 장점 자바스크립트를 최대한 사용 너희들, jsx 쓰면서 마크업에다가 Array.prototype.map 같은 거 많이 쓰는 거 안다. 그게 왜인지는 알고서 하는 거라 믿고 있겠다. 어쨌든, 리액트는 스크립트의 기능을 최대한 활용할 수 있다. 그렇기 때문에, 개발자는 코드에 집중이 가능하기 때문에 구조화가 용이하다 하겠다. Vue와 Svelte 와는 견줄만 한 장점이라 하겠다. (Solid.js 무시하지 마라) 타입스크립트와 궁합도가 최강인 기술 내 개인적인 견해로 봤을 때, 주요 프론트엔드 기술에서 타입스크립트 궁합은 현재 끝판왕이라도 해도 손색이 없다고 하겠다. 오죽했으면 타입스크립트 자체적으로도 JSX 프로세싱을 고려한 설계를 했을까 싶을 정도로 말이지. 유연한 컴포넌트 정의 뷰와 스벨트는 1파일당 하나의 컴포넌

1. 닫혀 있는 커뮤니티 스벨트는 내가 생각했던 것보다 상당히 닫혀 있는 커뮤니티인 점에 놀랐다. 이슈가 올라와도 컨트리뷰터의 결정에 따라 이슈가 순식간에 닫힌다. 물론 스벨트도 스벨트 나름대로 기준이 있고, 그 기준에서 벗어나려 하면 스벨트 자체 생명주기에 지장이 생길 수는 있다. 가뜩이나 커뮤니티 규모도 작고 한정적인데, 리액트와 뷰의 부족함을 스벨트로 채우려 하면... 열에 아홉은 그냥 컨트리뷰터에 의해 반려된다고 보면 된다. 2. 컴파일러 확장의 부재 스벨트의 매력은 바로 컴포넌트를 트랜스파일로 하여금 성능과 메모리 관리 효율을 최대한 이끌어낸다에 있다. 이건 리액트와 뷰에서 차별화할 수 있는 부정할 수 없는 사실이다. 하지만 이를 통해 잃은 게 뭐냐, 바로 UMD의 부재다. UMD의 부재는 이미 스벨트 참여자들도 인지는 하고 있지만, 우선순위는 낮다고 한다. 그렇다면, 스벨트가 확장성이 높다고는 하지만 정작 중요한 확장성이 없다. 바로 스벨트를 컴파일러하는