Vidact, React 함수 컴포넌트를 빌드 때 직접 DOM 갱신 코드로 컴파일

6년 전 실험으로 시작했고, React 함수 컴포넌트와 훅을 직접 DOM 연산으로 컴파일하는 방식을 다시 만들었음. React Compiler 분석 인프라를 써서 상태마다 영향받는 텍스트, 속성, 조건 범위, 목록 항목의 업데이트 함수를 생성함. 브라우저에는 React, 가상 DOM, 리컨실러, 런타임 의존성 추적을 싣지 않음.

이 설명이 랜딩 페이지보다 훨씬 유용함. 이 내용을 사이트에도 읽기 좋게 옮기는 편이 나아 보임.

OctaneJS와 비슷해 보이는데 벤치마크가 있는지 궁금함. React 훅과 Suspense, 액션을 컴파일러 우선 구조로 가져가고 의존성을 자동 추적한다는 점이 닮았음.

실제 프로젝트인지 의문임.

실제지만 아직 실험 단계임. 작은 앱부터 시험해야 하고, 이번 주에 바닐라 JS로 만든 grep.codemod.com을 Vidact로 옮겨 프로덕션에서 써볼 생각임.

LLM으로 랜딩 페이지를 쓰지 않았으면 함. 문서와 사이트를 사람이 다듬었는지가 첫인상에 큰 영향을 줌.

그 지적 이해함. 콘텐츠 작성은 약하고 게을렀는데 개선하겠음.

LLM 생성 글은 문장마다 더 헷갈림. 기술을 볼 때는 어떻게 동작하는지와 무엇을 못 하는지가 먼저 알고 싶음.

Svelte 5 이전처럼 컴파일러가 표현된 변환에 필요한 명령만 내보내는 모델로 보임. 가상 DOM이 없다는 점도 같음.

TanStack과 직접 통합되면 써볼 마음이 생길 듯함. 사용자가 별도 라우팅 API로 갈아타지는 않을 것 같음.

JSX를 정적으로 직접 DOM 변경으로 컴파일하려면 React의 동적 런타임 유연성과 클로저 모델을 크게 제한하거나 의미론을 깨야 한다고 봄. 동적으로 서버에서 받은 필드 목록으로 만드는 폼처럼 런타임에 DOM 구조가 정해지는 경우는 컴파일 시 의존성을 미리 알기 어렵지 않나.

컴파일러가 일부 코드를 블랙박스로 취급하더라도 React 부분집합에서 클라이언트 렌더링 작업을 줄일 수는 있다고 봄. 다만 DOM을 직접 만지는 라이브러리는 React의 우연한 동작 순서에 의존할 수 있음.

React 문법을 입력으로 쓴 이유가 불분명함. 컴파일 시 의존성을 찾는 방식은 런타임 프록시로 추적하는 Vue에 더 가깝고, Vue 템플릿은 JSX보다 파싱하기 쉬워 보임.

React 코드를 쓰면서 복잡성을 피하려는 목적이면 uibuilder도 살펴볼 만함.

Airbnb에도 Viaduct라는 같은 계열 이름의 프로젝트가 있어서 잠깐 혼동했음. 이쪽은 Vidact이고 철자가 다름.