Show HN: Nue – React 버튼보다 가벼운 앱

 (nuejs.org)
2P by GN⁺ | ★ favorite | 댓글 2개
  • Nue는 HTML, CSS, JavaScript만으로도 전체 앱을 React/ShadCN 버튼보다 작게 만들 수 있다며, 현대 웹 개발의 무거운 기본값에 문제를 제기함
  • 같은 앱에 Rust 계산 엔진과 Event Sourcing을 붙여 150,000개 레코드에서 즉시 검색과 작업을 수행하는 데모를 제공함
  • JavaScript 엔진은 최대 호출 스택 예외로 멈췄지만, Rust/WASM 버전은 같은 규모의 데이터를 즉시 처리하는 사례로 제시됨
  • React 관용구 대신 모델 우선 접근, 테스트 가능한 함수, 정적 타입, 최소 의존성을 앞세워 앱 구조를 단순화하려 함
  • 디자인·UX 엔지니어에게는 40,000줄 이상 디자인 시스템과 React 훅, 유틸리티 클래스보다 현대 CSS로 직접 제어하는 방식을 강조함

React 버튼보다 가벼운 앱 데모

  • Nue 데모는 HTML, CSS, JavaScript를 웹 표준에 가깝게 활용했을 때 앱이 얼마나 작아질 수 있는지 보여줌
  • 전체 앱의 크기가 React/ShadCN 버튼 하나보다 작다는 점을 전면에 내세움
  • 대규모 버전은 같은 앱에 Rust 계산 엔진과 Event Sourcing을 추가함
    • 150,000개 레코드에서 즉시 검색과 기타 작업을 수행하는 구성을 목표로 함
    • JavaScript 버전 엔진은 최대 호출 스택 예외로 중단됨
    • Rust/WASM 데모에서는 150,000개 레코드에 대한 즉시 작업을 확인할 수 있음

Nue가 겨냥하는 개발 방식

  • Rust, Go, JavaScript 엔지니어에게는 React 관용구보다 전통적인 소프트웨어 패턴과 분리된 모델 계층을 활용하는 방향을 강조함
    • Nue는 모델 우선 접근을 중심에 둠
    • 단순하고 테스트 가능한 함수, 정적 타입, 적은 의존성을 지향함
  • 디자인 엔지니어에게는 React 패턴과 40,000줄 이상 디자인 시스템 대신 현대 CSS로 더 단순한 시스템을 만들 수 있다고 봄
    • 예시로 @layers, CSS 변수, calc()를 언급함
    • 타이포그래피와 여백을 직접 제어하는 방식을 중시함
  • UX 엔지니어에게는 React 훅과 유틸리티 클래스의 장벽을 줄이고 사용자 경험을 직접 다루는 흐름을 제안함
  • Nue는 웹 표준 중심의 웹 프레임워크이며 현재 활발히 개발 중임
  • 단일 버튼이 전체 애플리케이션보다 무거운 상황을 현대 웹 개발의 숨은 복잡성 사례로 보고, 더 깨끗하고 견고한 아키텍처로 도구와 프레임워크를 다시 만들려 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 여러 방식으로 Nue에 화내는 반응을 보면, React에 크게 의존하면서 더 큰 문제를 놓치는 사람들처럼 보임
    문제는 거대한 프레임워크들이 웹을 끔찍하게 느린 덩어리로 만들었다는 것임
    DevOps/SRE로 이런 서비스를 매일 다루는데, 첫 로드가 10초 미만인 걸 찾기가 거의 불가능함
    호스트와 5ms 이내로 피어링된 10G 연결에서도 단순 홈 대시보드나 노트 페이지가 10초 넘게 걸리고, 그중 95%가 JavaScript라면 현재 웹앱이 빠른 브라우저 엔진과 낮아진 기대치에 기대는 거대한 비대화에 도달했다는 뜻임
    Nue가 이를 혁명적으로 바꿀 거라 기대하진 않지만, 적어도 응원할 수는 있음

    • 비대화는 React 같은 거대 프레임워크에서 오는 게 아님
      구체적으로 pnpm create vite -t react-ts로 만든 기본 React 프로젝트는 압축 기준 약 60KB이고, pnpm create vite -t vue-ts로 만든 Vue 프로젝트는 약 25KB임
      React/Vue로 만든 중간 규모 프로젝트도 이미지 제외 압축 200~300KB 정도였고, 실제 2G 제한 상황에서도 쓸 수 있었음
      단순 대시보드가 10초 넘게 걸리는 쓰레기는 어떤 프레임워크로도 만들 수 있고, 프레임워크 없이도 가능함
      오히려 jQuery식으로 제3자 의존성을 통째로 가져오면 실제로 쓰는 1KB를 위해 200KB를 내려받는 식으로 더 나빠질 수도 있음
      기사 비교도 멍청한데, React의 전체 뷰는 “React 버튼 하나”보다 훨씬 커지는 구조가 아니라 초기 비용 + 한계 비용 구조임
    • React 사이트 대부분이 비대해진 건 마음에 들지 않고, 몇 년간 주 프레임워크로 쓰다가 이제는 고객이 명시적으로 요청할 때 말고는 거의 안 쓰지만, “거대 프레임워크가 웹을 느리게 만들었다”는 말은 정확하지 않다고 봄
      웹 비대화의 대부분은 개발자가 최적화, 지연 로딩, 캐시, 의존성 최소화에 시간을 안 쓰는 데서 오고, 또 모든 사이트가 수익을 쥐어짜려고 붙이는 수백 개의 추적 스크립트에서 옴
      몇 년 전 추적기가 50개 붙은 사이트를 보고 충격받았는데, 이제는 수백 개여도 놀라지 않음
      개발자가 신경 쓰면 React 사이트도 매우 빠를 수 있고, React가 추가하는 비대함은 대개 핵심이 아님
      OP 글은 버튼을 78KB라고 설명하지만, 버튼 하나를 위해 React 전체를 로드하기 때문임
      페이지에 버튼이 수백 개 있다고 78KB를 수백 번 가져오는 건 아니므로 복잡한 React 사이트가 그렇게 비효율적인 것도 아님
      DevOps 엔지니어라면 그 느림 중 프레임워크와 실제 앱 코드가 각각 얼마나 차지하는지 통계가 있는지 궁금함
    • 말하려는 바는 알겠지만 조금 과장 아닌가 싶음
      직장에는 위젯 20개 이상이 각자 요청을 보내고 압축 JavaScript 2MB 이상을 전송하는 Vue 3 SPA 대시보드가 있는데, 모든 캐시를 꺼도 2초 안에 전체 로드됨
      “상호작용 가능”이 아니라 전체 로드 기준임
      웹이 더 가벼워질 수 있다는 데는 동의하지만, “첫 로드 10초 미만을 찾기 거의 불가능”은 과장처럼 들리고, 프레임워크 유무 때문이 아닐 수도 있음
      참고로 이 웹앱은 최고 중 최고 팀이 만든 것도 아님
    • “Nue에 화내는 사람들”이라기보다, 증거나 정당화 없이 너무 광범위한 주장을 하는 사람들이 보임
      SRE 도움을 요청받는 건 뭔가 잘못됐을 때뿐이니, 잘 돌아가는 걸 못 봤다고 놀랄 일은 아님
      느린 프로젝트에서 일해 본 사람은 결국 관리진 책임이라는 걸 알고, 코드베이스가 너무 커져서 아무도 고칠 수 없다고 느끼게 되는 것도 관리진 책임
      더 일찍 불렀다면 더 나은 걸 설계했을 거라고 생각할 수도 있지만, 그것도 결국 관리진 책임
      만약 모두가 거대 프레임워크를 버리고 소프트웨어가 완벽하고 안정적으로 된다면, SRE는 정확히 무슨 일을 하게 되는지도 생각해볼 만함
      기술을 다르게 바라보면 지금 가진 역량 앞에 큰 기회가 있다고 봄
    • 진짜 질문은 우리가 정말 프레임워크가 필요한가임
      순수 JavaScript도 꽤 잘 동작하고, JavaScript가 아예 없으면 더 나을 때도 있음
      최근 SAP 프로젝트에서 SAP 앞에 Java 계층이 있고 그 위에 거대한 Angular 앱이 있었는데, 애플리케이션 목적이 물리적 상품의 B2B 판매 관리였고 재고 여부가 매우 중요해서 거의 모든 화면이 SAP 계층에 전체 요청을 보냈음
      두꺼운 “리치 클라이언트”가 필요한 이유가 불명확했고, PHP가 훨씬 더 잘 맞았을 가능성이 큼
      과장 광고를 빼고 보면 대형 조직은 프레임워크를 균일한 코딩 관행과 개발자 교체 용이성을 확보하는 수단으로 쓰는 듯하지만, 그 목적을 달성하는 더 나은 방법은 분명 있을 것임

  • React를 대체하겠다는 건 이쪽임: https://nuejs.org/docs/view.html
    초기 Angular 2.0과 비슷한 방향의 타입 없는 뷰 계층이고, 모델 파일은 그냥 JavaScript임
    즉 어디에도 타입이 없는데, Vue.js 쪽을 겨냥한다면 괜찮을 수도 있음
    다만 지금 React 사용자는 대부분 TypeScript를 쓰고, 뷰 계층의 일급 타입 지원이 아주 유용하니 마케팅 방향을 그쪽으로 조금 바꾸는 게 나을지도 모름

    • 작성자임: 맞음, Nue의 뷰 계층은 타입이 없음
      의도적인 설계임
      React 생태계는 개발자들이 CSS에까지 TypeScript를 붙이게 만들고 있는데, 그건 과함
      Nue는 반대로 표현 계층은 깨끗하고 의미론적으로 유지하고, 웹 표준이 많은 일을 하며, Rust나 Go 같은 정적 타입은 정말 중요한 비즈니스 로직에서 빛나게 하려는 접근임
    • Vue는 TypeScript로 작성됐고, 템플릿 계층까지 일급 지원을 제공함
    • 대부분이 TypeScript를 쓰는 이유는 React 앱이 비즈니스 로직과 뒤엉킨 코드 20만 줄 규모로 커져서, 없으면 관리가 불가능해졌기 때문임
      다른 방향으로 간다면 필요성이 줄어듦
    • 내가 아는 Vue 개발자 대부분도 같은 이유로 TypeScript를 씀
    • Vue에서 TypeScript 지원과 사용량은 매우 큼
      Vue 자체가 TS로 작성됐고, 큰 라이브러리 대부분도 TS로 작성됨
      /r/vuejs와 개인 경험 기준으로도 새 앱 대부분이 그렇다고 봄

  • 훌륭하긴 한데, 나는 Svelte와 SvelteKit에 투자했음
    장난감 예제가 아니라 폼과 화면이 수십 개 있는 꽤 큰 앱을 만든 뒤 React를 다시 돌아봤고, React는 훅을 이해하면 그렇게 어렵지 않고 내 용도에서는 가볍기도 하며, 이제는 지루한 기술이라 오히려 좋다는 걸 알게 됨
    생태계도 거대해서 React Query 같은 라이브러리를 대체하기 어렵다는 것도 한 예임
    그래서 앞으로 몇 년은 React를 계속 쓸 생각이고, 특히 React 컴파일러가 이미 Facebook과 Instagram 내부에서 쓰이고 공개 베타로 나왔기 때문임
    React Native도 React 컴파일러를 지원하고, 이 지원은 사라지기보다 더 좋아질 것으로 봄
    React 컴파일러가 나오면 Svelte의 runes나 컴파일되는 성격이 남길 여지가 크지 않음
    runes 이후 Svelte는 JavaScript를 쓰는 게 아니라 JavaScript처럼 보이는 표기법을 쓰는 느낌이라 별로고, React 컴파일러 이후에는 복잡한 상황에서 훅 지옥도 많이 필요 없어짐

    • TanStack Query는 예전 React Query이고 Svelte와 완전히 호환됨: https://tanstack.com/query/latest
      React는 10년, Svelte는 최근 3년간 써왔는데, Svelte는 확실히 더 새로운 세대의 프레임워크이고 내게는 React보다 훨씬 잘 맞음
      다만 생태계 주변으로 거친 부분이 있다는 데는 동의함
    • Svelte는 확실히 훨씬 덜 장황하고 코드가 적게 필요함
      성능도 훨씬 좋지만 많은 용도에서는 중요하지 않을 수 있음
      단점은 Svelte가 사실상 언어라서, 제대로 작동시키려면 컴파일러와 전용 개발 도구가 필요하다는 것임
      이걸 유지하고 발전시키려면 상당한 노력이 듦
      Svelte를 좋아해서 몇 년 동안 거의 매일 써왔지만, 팀이 비전을 달성하고 장기적으로 유지하려면 더 많은 자원이 필요함
      Apple Music 같은 곳에서 Apple 같은 대기업이 Svelte를 도입하면서도 투자하지 않는 건 놀라움
      https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c321...
    • Svelte로 옮겨 보니 React보다 2~3배 덜 복잡하게 느껴짐
    • 클래스 컴포넌트 시절에 React를 배웠는데, 최근 다시 보니 함수형 컴포넌트와 훅이 완전히 난해하게 느껴졌음
      왜 이 방향으로 갔는지 아는 사람 있는지 궁금함

  • Nue는 현대 웹 개발의 비대함을 잘라내려고 만들고 있는 웹 프레임워크임
    Vite/ShadCN/Tailwind 버튼 하나가 완전한 SPA보다 40% 더 무겁다면, 이제는 다르게 할 때임
    바닥부터 다시 만들고 있고, 웹 표준 우선이며 비대함을 없애려 함
    더 단순하고 제정신인 작업 흐름을 원하는 프론트엔드 아키텍트, 디자인 엔지니어, UX 쪽 사람들을 위한 것임
    아직 진행 중이지만 변화가 오고 있음

    • 이제는 왜 모든 게 SPA여야 하는지조차 모르겠음
      복잡하고 비효율적이라 Photoshop이나 웹용 Ableton Live처럼 상호작용이 매우 많은 애플리케이션에만 써야 할 패러다임이고, 그런 앱은 아주 적어야 함
      프론트엔드 개발자는 아니지만, “15만 개 레코드에 대한 즉시 검색과 작업”이 문제라면 패러다임을 다시 생각하는 게 맞아 보임
    • Nue는 아주 멋진 프로젝트지만, 사람들이 진지하게 받아들이길 원한다면 공격적인 마케팅은 조금 누그러뜨리는 게 좋겠음
      데모를 보니 React 버튼 비교에서 고려하지 않은 WASM 코드가 100KB 정도 있는 것 같음
      그래도 프로젝트 축하하고, 전체 비전이 어떻게 완성될지 정말 궁금함
    • “X의 버튼 하나가 SPA보다 40% 무겁다”는 비교는 공정하지 않다고 봄
      프레임워크를 포함하면 무게가 늘지만, 이런 프레임워크는 단일 컴포넌트용으로 의도된 게 아님
      동등한 조건에서 비교해야 공정한 비교가 가능함
      그렇다면 Nue는 htmx나 현대 웹 표준을 활용하는 다른 프레임워크와 비교해 어떤지 궁금함
    • Vite가 논의와 무슨 관련이 있는지 모르겠음
      Visual Studio 기반 UI가 더 가볍다고 말하는 것과 비슷함
    • 놀라운 마케팅 문구인데, 이게 어떻게 동작하는지에 대한 세부 내용은 하나도 없음

  • 이 마케팅 글 대신 기술적 세부가 있었으면 좋겠음
    예를 들면 변경 추적에 어떤 방식을 쓰는지, Vue식 프록시인지 React식 전체 재계산인지가 궁금함
    또한 15만 개 객체에서 JavaScript가 “스택을 넘친다”는 문구도 이해가 안 됨
    직접 15만 개 객체 리스트를 만들어 보니 프로파일러상 배열과 객체가 14MB 정도를 쓰고, 인덱스 없이 list.find()를 돌려도 스택 오버플로가 나지 않음
    인덱스를 쓰면 아마 매우 빠를 것이고 WASM이나 복잡한 장치가 필요 없을 것임
    JavaScript는 그렇게 느리지 않음
    큰 배열의 숫자 곱셈 같은 수치 계산을 하면 코드가 컴파일되어 꽤 빠르게 실행됨

    • 작성자 데모 코드에서 list.push(...objects) 같은 걸 쓰는데, 그게 원인으로 보임
      스프레드 연산자로 매우 많은 인자, 예를 들어 10만 개 정도를 한 번에 메서드에 넘기면 JavaScript에서는 각 인자가 호출 스택에 올라가므로 스택 오버플로가 나는 것으로 알려져 있음

  • 새 프레임워크 대부분은 당시의 더 성숙한 선택지에 대한 가벼운 대안으로 시작함
    이것만으로는 도입할 이유가 되지 않음
    사용자가 요청하는 비대함을 모두 추가하고 아직 이해하지 못한 모든 예외 상황을 처리한 뒤, 10년 후에 다시 올려 달라
    그때도 React 버튼 하나보다 가볍다면 뉴스 가치가 있을 것임

    • 그렇다면 기존 강자가 되기 전까지는 아무것도 논의할 가치가 없고, 기존 강자보다 낫다고 주장할 수도 없다는 뜻인가?
      기존 플레이어와 비교해 이야기할 수 없다면, 비대해질 만큼 필요한 사용자를 어떻게 끌어모으라는 건지 모르겠음
    • React가 처음 나왔을 때 이 사이트의 반응이 대체로 부정적이었던 걸 보면, React가 가볍다고 여겨진 적은 없었던 것 같음
    • Solid.js는 번들 크기 측면에서 훌륭하게 하고 있음
      계산 방식에 따라 6~9년 정도 개발되어 왔는데도 여전히 아주 날씬함
    • 비슷하게 느낌
      요구사항이 적은 위젯을 웹 컴포넌트로 배포하려고 Svelte를 쓰기 시작했는데, 그 용도로는 훌륭했음

  • 프로젝트를 보면서 든 질문들임
    데모 https://mpa.nuejs.org/app/가 왜 인상적인지 모르겠고, React로도 같은 성능의 웹앱을 만들 수 있다고 봄
    홈에서 코드 예제를 빨리 보고 싶은데 문서를 뒤져야 했고, https://nuejs.org/docs/view.html#clean-html-templating를 보니 Svelte에서 영감을 받은 건지 궁금함
    Nue가 다른 기술, 특히 순수 HTML/JavaScript와 비교해 어떻게 더 빠르고 가벼운지도 알고 싶음
    Nue가 쓸 만한 프레임워크라고 설득하려면 HTML+JS보다 단순하거나 최소한 React보다 단순해야 하고, 마크업과 로직이 HTML 등 이미 아는 것과 가까워 이해하기 쉬워야 하며, 좋은 빌드 시간과 HMR로 개발자 경험이 좋아야 함
    이 부분은 잘한 듯함
    또한 낮은 오버헤드, WASM 기반 여부, 가상 DOM, 서버 아일랜드 같은 기술적 우위와 지표를 보여줘야 함
    esbuild는 이걸 잘했음: https://esbuild.github.io/

    • 메인 페이지의 핵심은 작다는 것, 즉 “React 버튼보다 가볍다”와 많은 레코드를 다룰 수 있다는 것, 즉 “JavaScript와 React가 스택 오버플로로 죽는 지점을 훨씬 넘는다” 아니었나 싶음

  • 이 프로젝트 작성자가 React의 버튼은 React 라이브러리 없이는 동작하지 않으므로 73KB라고 말하려는 거라면 약한 지적임
    그 시점의 앱 번들에서는 React 라이브러리가 다른 부분에서도 재사용되기 때문임
    사람들을 오도하고, 약속이 너무 얕아서 거의 모욕처럼 느껴짐

    • 작성자임
      명확히 하자면 ShadCN/Vite 공식 문서(https://ui.shadcn.com/docs/installation/vite)로 설치한 버튼 하나가 완전한 Nue SPA보다 훨씬 무거워짐
      React 개발자를 공격하려는 게 아니라, 웹 표준이 비대함의 판을 어떻게 뒤집을 수 있는지 보여주려는 것임
      이 비교를 더 잘 표현할 방법이 있는지 궁금함

  • 접근 방식은 정말 마음에 드는데 데모 https://mpa.nuejs.org/app/가 iOS Safari에서 제대로 동작하지 않음
    다만 내 버전 16.7.8이 오래돼서일 수도 있음
    스크롤이 안 되고, 레이아웃과 버튼에 이상한 줄바꿈이 있으며, 네이티브 검색 버튼이 커스텀 디자인 버튼 안에 박혀 아이콘이 2개가 됨

    • iOS Safari에서 스크롤이 이제 동작함
      빠른 수정이었음
    • 작성자는 예전 제출물 거의 전부에서 썼던 트릭을 다시 쓰고 있음
      비교 대상 컴포넌트보다 훨씬 적은 기능만 구현한 뒤, 자기 솔루션이 얼마나 작은지 보여줌
    • Android의 Chrome과 Firefox에서도 페이지 높이와 세로 스크롤이 깨짐
      Firefox에서는 댓글 상자가 메뉴 바 아래로 숨음
      아마 페이지 높이를 퍼센트나 vh로 강제한 듯한데, 보통 피해야 함
      강제가 필요하면 svh나 dvh를 써야 함

  • 코드 예제가 있는지 궁금함
    조금 찾아봤지만 못 찾았고, 새 프레임워크를 다루는 블로그 글에서는 코드 예제가 맨 처음에 있어야 한다고 봄

    • 현재 예제는 두 개 있음
      nue create simple-blog는 콘텐츠 중심 웹사이트를 보여줌
      nue create simple-mpa는 오늘의 SPA 데모이고, 여기서 MPA는 다중 페이지 애플리케이션을 뜻함
      클라이언트 측 라우팅과 뷰 전환이 콘텐츠가 많은 페이지와 앱 같은 뷰를 어떻게 매끄럽게 연결하는지 보여줌
      소스 코드는 여기 있음: https://github.com/nuejs/nue/tree/master/packages/examples
    • 나도 5분 동안 클릭해 봤지만 코드가 어떻게 생겼는지 보여주는 샘플을 찾지 못했음
답변달기