플레인 바닐라 웹

 (plainvanillaweb.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Plain Vanilla Web은 에디터와 브라우저, 웹 표준만으로 웹사이트와 웹 애플리케이션을 만드는 방법을 정리한 튜토리얼임
  • 구성 요소, 스타일링, 사이트, 애플리케이션을 나눠 Web Components, 최신 CSS, 클라이언트 측 라우팅과 상태 관리를 바닐라 방식으로 다룸
  • 현대 웹 프레임워크의 편의보다 프레임워크·툴링 복잡성을 줄이는 선택에 초점을 둠
  • HTML, CSS, JavaScript에 이미 익숙한 독자를 대상으로 하며, 웹 개발을 막 시작한 사람에게는 아직 적합하지 않음
  • 단기 편의를 일부 포기하더라도 단순성과 사실상 제로 유지보수에 가까운 장기 이점을 얻는 접근을 지향함

웹 표준만으로 만드는 사이트와 애플리케이션

  • Plain Vanilla Web은 HTML, JavaScript, CSS를 중심으로 웹사이트와 웹 애플리케이션을 만드는 방법을 안내함
    • 필요한 것은 에디터와 브라우저, 웹 표준임
    • 빌드 도구, 프레임워크, 서버 측 로직에 의존하지 않는 방식을 다룸
  • 학습 흐름은 네 가지 영역으로 구성됨
    • Components: Web Components로 plain HTML, JavaScript, CSS 위에 더 높은 수준의 프리미티브를 만듦
    • Styling: 최신 CSS를 활용해 CSS Modules, PostCSS, SASS의 편의 기능을 대체함
    • Sites: 빌드 도구, 프레임워크, 서버 측 로직 없이 바닐라 웹사이트를 만들고 온라인에 배포함
    • Applications: 클라이언트 측 라우팅과 상태 관리를 위한 바닐라 전략으로 싱글 페이지 애플리케이션을 만듦

적합한 독자와 시작 경로

  • 이 접근은 현대 웹 프레임워크가 주는 풍부한 기능보다 복잡성 감소를 우선함
    • 프레임워크와 툴링 부담을 줄이는 대신 단기적인 편의 일부를 포기함
    • 장기적으로는 단순성과 사실상 제로 유지보수에 가까운 상태를 목표로 함
  • HTML, CSS, JavaScript를 이미 다룰 줄 알고 툴링 복잡성에서 벗어나고 싶은 사람에게 맞음
  • 다음 단계는 Web Components를 사용해 콘텐츠, 스타일, 동작을 조합하는 방법을 배우는 것임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 바닐라냐 프레임워크냐 논쟁을 넘어서, 이제는 이걸 웹사이트로 만들 필요가 있나를 먼저 묻게 됨
    특히 B2B SaaS에서 웹 애플리케이션의 실제 필요성을 꽤 냉소적으로 보기 시작하면, 브라우저를 건드리지 않고도 사업을 얼마나 멀리 끌고 갈 수 있는지 놀랄 때가 있음
    웹사이트와 애플리케이션을 만드는 데 쓴 시간 대부분은 결국 관리자가 어딘가의 데이터베이스 필드를 바꿔 고객 기대대로 동작하게 하는 관리자용 UI/UX였음
    많은 경우 설정 템플릿, 즉 Excel 파일을 고객사에 보내고 그 결과를 같은 SQL 테이블에 직접 적재·병합하는 편이 100배 빠르고 쉽고 덜 번거로움
    웹은 UI/UX의 한 형태일 뿐이고, 사용자가 제품이나 사업과 상호작용하는 유일한 방식은 아님. 이메일과 평면 파일이 어떤 웹 솔루션보다 훨씬 유연할 때가 많음

    • 온라인으로 유골함을 파는데, 웹사이트에는 이메일 링크만 있고 장바구니가 없음
      오프라인 유골함 매장에도 장바구니는 없을 텐데, 가상 매장이라고 꼭 있어야 할 이유가 없음
      전문 목공 도구도 온라인에서 양식만 작성해 샀고, 나중에 부품과 송장이 와서 결제하면 됐음. 마음만 먹으면 그냥 안 내도 되는 구조였음
      온라인이든 오프라인이든 상거래 방식은 정말 많고, 잘 들여다보면 주변에 흥미로운 사람들이 흥미로운 방식으로 장사하고 있음
    • 스프레드시트를 보내면 업로드해주겠다는 방식은 좋은 사용자 경험이 아니었음
      문서화도 없는 셀 덩어리일 뿐이고, 문서가 있어도 어차피 안 읽을 가능성이 큼
      사용자가 잘못할 수 있는 일이 너무 많고, 내가 이메일로 알려주기 전까지는 피드백도 받지 못함
      각 필드에 어떤 선택지가 있는지도 모르고, 비표준 값을 넣기 쉽고, 헤더 행의 오타 하나가 오류 없이 데이터 손실로 이어질 수도 있음
      경험 많은 사용자에게는 가장 쉬운 방식일 때도 있지만, 사용자가 저지를 수 있는 모든 실수를 계속 지원하는 건 엄청난 부담임
    • 먼저 잊지 말아야 할 건, 사람들은 웹 이전부터 못생긴 녹색 텍스트 모드 화면으로도 사업을 해왔고, WWW 이전에도 FIDO, GOPHER, IRC, 이메일 같은 합리적인 형태의 웹 비슷한 것들이 있었다는 점임
      이 모든 것이 하이퍼링크로 연결된 건 훌륭하고 편리하지만 기술적으로는 도전이기도 했고, 1992년 이후 30년 동안 FAANG이 만든 결과가 오늘날처럼 얽히고 초복잡한 기술 지옥으로 이어졌음
      W3C 표준화까지 고려하면 바닐라 웹조차 꽤 복잡함
      보안 여부와 별개로, 제품 수명이 긴 장비라면 훨씬 단순한 소프트웨어로도 운영할 수 있음
      이제 LLM 보조 코딩 덕분에 보일러플레이트의 고통이 견딜 만해지면서 이런 바닐라 접근이 돌아오길 바람
      한때 HTML을 정말 싫어했지만, 멍청한 Facebook/Instagram 페이지나 이벤트에서 이미지를 배치하려 애쓰는 것보다 직접 웹사이트를 프롬프트로 만들고 내 콘텐츠를 다시 소유하는 편이 훨씬 즐거움
    • 내 경우는 오히려 반대로 갔음. 회사 내부 카페 메뉴 웹사이트가 있는데, 전체를 보려면 클릭이 너무 많았음
      처음엔 데이터를 긁어서 더 나은 조작 방식을 가진 웹사이트를 만들 생각이었지만, v0는 데이터를 Google Sheets에 밀어 넣는 형태가 됐음
      v1은 필요 없었음. Google Sheets의 UI가 필터링, 즉 아침/점심 구분, 접근 제어, 기본 분석까지 해결했고 동료 7명 정도가 매일 씀
    • B2B SaaS 시스템에서 고객이 스스로 관리·설정하게 하려면 어떤 형태로든 상호작용이 필요하고, 그 과정에서 브라우저를 쓰지 않을 것이라고 기대하는 고객이 얼마나 될지는 의문임
      입력 정보 검증이나 시스템 규칙 강제가 없다면, 그런 사이트나 애플리케이션이 올바른지부터 의심하게 됨
      Excel 파일을 받아 SQL 테이블에 직접 적재·병합하는 방식은 목적 적합성, 오류 감지·보고, 업무 흐름, 역할 기반 접근 제어 같은 핵심 소프트웨어 공학 개념을 시스템이 강제하면서 더하는 가치를 없애버림
      듣기에는 좋아도 이 방식은 확장되지 않고, 언젠가는 반드시 장애 상태로 이어질 가능성이 큼

  • 프레임워크에 반대하는 건 아니지만, 많은 경우 불필요하다고 봄. 실제 코드를 한 줄도 쓰기 전에 페이지에 JavaScript 100KB를 더해야 하는 이유를 늘 의심해왔음
    팀과 함께 https://restofworld.org를 프레임워크 없이 만들었고, 설문·아웃리치·자발적 이메일을 통한 피드백은 특히 사용성과 읽기 경험 측면에서 압도적으로 긍정적이었음
    언젠가 프레임워크를 도입할 수도 있음. 프레임워크의 명확한 구조가 끝없는 논쟁을 줄여주는 점은 인정함
    하지만 지금은 순수 JavaScript가 우리에게 아주 잘 맞음

    • 이런 댓글이 이 논의가 항상 엇갈리는 좋은 예라고 봄
      한쪽에는 30명 이상 팀에서 웹사이트가 아니라 완전한 웹 애플리케이션을 만드는 사람들이 있음
      이들은 프레임워크 없는 선택지를 보자마자 자기 사용 사례에 꼭 필요한 수십 가지 기능을 어떻게 처리하냐고 묻고, 답은 그 기능들이 필요 없다는 것임. 왜냐하면 그건 블로그이기 때문임
      반대로 대규모 웹 애플리케이션을 해본 적 없는 사람들도 많아서, 블로그를 프레임워크 없이 만드는 게 이렇게 쉬운데 왜 프레임워크가 존재하는지 의아해함
      웹이 엄청나게 다양한 종류의 소프트웨어를 호스팅한다는 데 동의하고, 프레임워크에 찬성하든 반대하든 어떤 종류의 소프트웨어를 말하는지 분명히 하면 좋겠음
      이 경우는 WordPress 블로그임
    • 페이지는 훌륭하고 빠르게 로드되지만, 원문에서 말하는 접근과는 관련이 없어 보임
      이미 가장 큰 프레임워크인 WordPress를 쓰고 있고, 단지 정적 렌더링을 하고 있을 뿐임
      원문은 빌드 도구 없이 현대 웹 표준을 쓰고, 전처리가 필요한 것을 쓰지 않는 방식을 말함
      페이지의 표현을 빌리면 “그저 편집기, 브라우저, 웹 표준”임
    • 내가 기업 환경에서 계약자로 작업한 앱들에서는 100KB가 고려 대상이 된 적이 없음
      대규모 팀에서 일하는 경우가 많았고, 여러 업무용 애플리케이션이 React를 쓰는 다중 팀 모노레포도 있었음
      업무용 앱이나 B2B에서는 초기 페이지 로드를 아무도 신경 쓰지 않기 때문에 100KB는 완전히 무의미함
      사용자들은 매일 앱을 쓰므로 새 프로덕션 배포가 있기 전까지 JS/CSS/정적 자산은 거의 항상 브라우저 캐시에서 제공됨. 배포 주기도 보통 몇 주 단위임
      게다가 사용자는 사막 어딘가의 3G가 아니라 적어도 Ethernet이나 WiFi를 씀
      Next.js 같은 더 똑똑한 프레임워크를 쓰면 경로별로 JS 조각이 잘 나뉘고, 파일명에 콘텐츠의 sha256 해시가 들어가 불변 자산이 됨
      웹서버에서 Cache-Control: immutable로 제공하도록 설정하면 새 버전을 확인하러 왕복 요청조차 하지 않음
      Next.js는 백그라운드에서 조각을 미리 로드하거나 링크에 마우스를 올렸을 때 hover와 click 사이 시간을 활용해 조각을 미리 로드하는 기능도 있음
      초기 렌더링은 정적 HTML이고 hydration은 사용자가 전혀 눈치채지 못하게 일어남
    • 사이트가 좋고 흥미로운 기사도 있었음
      다만 바닐라 대 프레임워크 논의에서 예시를 들고 가보면 복잡한 애플리케이션이 아니라 기사 중심의 뉴스 사이트인 경우가 조금 짜증남
      이런 상황이라면 애초에 프레임워크를 쓰지 않았을 것임
      짜증나는 방향이 두 가지인데, 첫째는 애초에 프레임워크가 필요 없던 사이트에 사람들이 프레임워크를 쓰고 있다는 점이고, 자주 보는 뉴스 사이트 몇 곳도 동작 방식이 우스워서 분명히 그런 경우로 보임
      둘째는 그런 예시가 근거로 제시된다는 점임. 내 작업 대부분은 매우 상호작용적인 사이트라서, 결국 “그래도 내 경우엔 안 되겠지”라고 생각하게 됨
      바닐라로도 할 수는 있겠지만 결과적으로 사이트 전용 프레임워크 같은 것을 만들게 될 느낌임
      현재는 프레임워크와 일관된 패턴을 쓰되, 다른 의존성은 최대한 줄이는 방식으로 감
    • 사용성은 일급 시민이어야 함
      그런데 우리는 로딩 화면, 컴포넌트 hydration, 시간과 전력을 먹는 애니메이션, 성가신 모달을 완성한 듯함

  • 약 2천 명 사용자를 대상으로 일하는데, 그들은 반응성 같은 것에 별 관심 없음
    모놀리스를 만들고, 편하게 만들고, 페이지 새로고침을 받아들이고, 현실 세계에서는 아무도 그걸 신경 쓰지 않으니 그냥 일을 끝내면 됨

    • 반대로 원래 네이티브 데스크톱 애플리케이션으로 구현됐던 많은 시스템이 이후 웹으로 이전됐음
      이 이동은 기술적으로 강한 동기가 있다기보다 실용적인 이유가 큼. 네이티브 애플리케이션 배포가 너무 비싸기 때문임
      웹은 마침내 애플리케이션을 저렴하게 배포할 수 있는 널리 퍼진 표준을 제공함
      안타깝게도 웹 UI를 만드는 기술은 여전히 다소 평범함
      X11, Java, Flash, Silverlight, .NET 그리고 직접 겪어보지 못한 수많은 대안에서 역사가 몇 번 잘못 꺾인 게 아쉬움
      언젠가 누군가 웹 애플리케이션 개발을 편하게 만드는 방법을 찾고, 더 넓은 커뮤니티가 받아들이길 바람
    • 깨진 단일 페이지 애플리케이션을 다중 페이지 애플리케이션보다 훨씬 더 많이 봤음
      단일 페이지 애플리케이션이 전환율과 사용자 경험을 개선한다고 여겨지는 걸 생각하면 아이러니함
      변명할 여지가 없는 대기업도 마찬가지임. Reddit은 휴대폰에서 거의 못 쓸 수준이고, X는 모바일 이미지 로딩이 한 달 내내 그냥 망가져 있었음
      단일 페이지 애플리케이션을 만들고 있는데 그게 Twitter나 콘텐츠 소비 플랫폼이 아니고, API 주도 구조가 꼭 필요한 것도 아니라면 진지하게 멈추는 게 좋음
      똑똑한 게 아니고 경험을 개선하는 것도 아니며, 다른 프로그래머 취향에만 맞추는 것임
      수십억 달러짜리 회사들도 완벽하게 못 굴리는데, 당신이 해낼 리 없음
    • 지금 시대에 꽤 현실과 동떨어진 생각임
      요즘 소프트웨어 대부분은 120년 전의 기계식 장치보다 한 자릿수 규모로 더 느리고 덜 반응적으로 느껴짐
    • CSS만으로도 @view-transition을 써서 부드러운 전환을 만들 수 있음
      https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
    • 그래도 npm 패키지를 가져오지 않고 CSS와 JS만으로도 매우 단순한 새로고침 기반 동적 동작을 만들 수 있음

  • 아주 좋음. 우리가 이런 세상에 살았으면 좋겠음
    W3C 기술밖에 없던 “이전 시대” 출신인데, 그때는 너무 미성숙해서 괴로웠고 “jQuery는 알지만 JS는 모르는” 사람들을 채용하기도 했음
    솔직히 query selector 이후의 프레임워크들은 테스트 프레임워크를 제외하면 강한 비용 대비 효과를 설득하기 어렵다고 봄. 테스트 프레임워크는 꽤 훌륭함
    하루 수억 건을 처리하는 사이트를 운영하며 엄청난 자원을 투입하고 있지만, 우리가 스스로 만든 React 감옥에 갇혀 있음
    모든 실패는 복잡성에서 나옴. 강하게 결합된 상태 기계들이 해킹되고, 얽히고, 축소되고, 컴파일되고, 트랜스파일되고, 또 뭔가 더해져서 프로덕션에서는 읽을 수 없는 찐득한 덩어리가 됨
    소스맵이 있다는 건 알지만, 필요할 때만 쓰고 그것도 깨질 수 있는 또 하나의 복잡성 계층이며 실제로 깨짐
    프레임워크 이전의 좋았던 시절이 그리움
    아마 향수와 KISS 원칙 등이 판단을 흐리고 있을 수도 있음. 결국 프레임워크가 만들어진 데는 이유가 있음
    그래도 새 엔지니어가 바닐라를 배우는 게 프레임워크를 하나씩 계속 배우는 것보다 더 어렵다고 상상하기는 힘듦

    • 나도 이전 시대 출신이고, 이 모든 것의 큰 문제 중 하나는 문서 형식 위에 이것저것 덧붙여 전 세계 애플리케이션 생태계를 만들기로 결정했다는 점이라고 봄
      HTML은 텍스트 문서를 더 쉽게 전송하고 렌더링하기 위한 얇은 마크업 계층일 뿐이었고, HTTP도 마찬가지였음
      텍스트 대비 마크업 비율은 꽤 높아야 했지만, 오늘날은 아마 1보다 낮을 것임
      그런데 어떤 이유로든, 아마 전 세계에 쉽게 게시할 수 있었기 때문에, 애플리케이션 개발의 미래를 이 계층 위에서 GUI를 완전히 재발명하는 방향으로 정해버렸음
      React가 내부에서 하는 일을 들여다보면, UI를 만드는 합리적 방식처럼 보이게 하려고 수십 년치 해킹과 요령을 잘 조직해둔 것에 가깝음
      Excel 문서와 Visual Basic을 해킹해 애플리케이션을 만들기로 한 세계나, 모든 앱이 PostScript를 영리하게 쓰는 PDF 파일이 되는 세계를 상상해보면 됨
      우리가 집단적으로 해온 일이 얼마나 말도 안 되는 시도인지 떠올리면, 웹사이트가 제대로 렌더링되고 더 중요하게는 코드베이스를 어느 정도 조직화할 수 있는 합리적 개발 절차를 위해 JS 수 MB를 요구하는 것도 그리 놀랍지 않음
    • 현실적으로 잘 조직된 회사라면 “프레임워크를 계속 배운다”기보다 React를 배우고 끝임
      컴파일, 축소, 기타 빌드 세부사항을 걱정하지 않아도 됨. 작동하는 빌드 시스템이 빌드와 소스맵을 처리하고, 깨지거나 불안정해지면 고치는 문화가 있기 때문임
      한동안 웹에서 떨어져 있다가 몇 년 전 돌아온 입장에서, 순수 React나 Next.js 애플리케이션은 옛날식 웹앱보다 훨씬 작업하기 좋음
      웹이 드디어 발버둥치며 일반 소프트웨어 개발 모범 사례의 세계로 끌려온 느낌임
      JS가 최고의 프로그래밍 언어는 아니지만 제대로 된 프로그래밍 언어이고 일을 해냄
      사람들이 라이브러리를 쓰고 코드를 작성해 보통 객관적으로 더 쉽고 좋은 방식으로 문제를 풀기보다, CSS 같은 튜링 완전성 이하의 늪에서 몸을 비트는 걸 선호하는 게 계속 이해되지 않음
    • 나도 같은 느낌임
      React와 Angular, 특히 초기 Angular는 ES2015가 주류가 되기 전에 만들어졌으니 처음 나왔을 때는 사용할 이유가 있었다고 봄
      그 이후로는 새 프런트엔드 프레임워크를 계속 배워야 하는 끊임없는 변화에 지쳤음
      React 안에서도 컴포넌트를 작성하는 방식이 여러 가지이고, 상태 관리자도 여러 종류임
    • 현대 세계에서 핵심 앱은 반응성, 즉 데이터 모델 변경에 따라 뷰가 업데이트되는 기능이라고 봄
      리스너를 직접 만들고 차등 업데이트를 처리하고 이벤트 리스너 제거와 정리를 관리하는 건 수동 메모리 관리와 비슷함
      예전에는 jQuery로 가끔 그렇게 했고, 그건 할 수 있는 일 중 가장 오류가 나기 쉬운 일임. 상태가 뒤엉킨 지옥임
      컴포넌트를 대체로 선언적 뷰 방식으로 모듈화할 방법을 찾는다면 바닐라 JS 표면으로 다시 기어 올라갈 의향이 있지만, 그 전에는 아님
      그냥 기능이 빠져 있다고 봄
    • 하루 수억 건 규모라면 애플리케이션보다는 정적 사이트에 가까운 구조라고 봐도 되나?

  • 아직 Web Components에 확신이 없음
    특히 지금은 @scoped와 import{type:css}가 있어서, 요소를 정적으로 렌더링해 보내고 현대 JS로 동적으로 갱신하는 방식에도 여전히 장점이 많다고 봄
    사람들이 보통 그렇게 구현하는 방식에는 확신이 없고, React/Svelte 같은 일반적인 프레임워크 바깥에서 계속 혁신을 시도해야 한다고 생각함
    하지만 내가 운영하는 여러 서로 다른 유형의 사이트 어디에도 Web Components의 어떤 부분이 유용할지는 전혀 보이지 않음

    • Web Components는 내가 가진 문제를 해결하지 못하고, 원하지 않는 새 문제를 더함
      Components 페이지의 Shadow DOM 언급 25개와 Styling 페이지의 언급 14개 중 상당수는 사이트가 Shadow DOM 사용을 권장했기 때문에 새로 생긴 문제를 해결하는 내용임
      Shadow DOM 자체가 해결하려는 문제도, 내 앱 전용으로 작성되고 내 앱에서만 쓰일 컴포넌트에는 없는 문제임
    • Web Components는 깔끔한 추상화 경계를 제공함
      직접 만든 태그에 추가 메서드를 붙여 컴포넌트 내부 데이터 갱신 로직을 캡슐화할 수 있음
    • 이제 Unobtrusive JavaScript로 돌아갈 때라고 봄
      이를 위해서는 직접 작성할 수 있는 가벼운 라이브러리나 관행이 필요함
      HTMX는 가벼워서 좋지만 script 태그 같은 느낌이 있음
      URL과 메서드는 평범한 HTML에 두고, hx-target 같은 것은 필요하면 data- 속성을 사용해 JavaScript가 결정하는 편이 더 좋겠음
      그러면 쓰지 않는 HTMX 기능이 전부 포함되지 않음
    • Shadow DOM은 Web Component 없이도 쓸 수 있음. Web Component와 Shadow DOM은 서로 직교하는 개념임
      Web Component는 특정 요소에 JavaScript를 붙이는 방법임. 다른 방법도 있지만, 서버 사이드 렌더링을 하고 JavaScript 프레임워크를 쓰지 않을 때처럼 이 방식이 더 깔끔하게 느껴질 때가 있음
      Shadow DOM은 스타일을 정리하는 방법임. 다른 방식도 있지만 완전한 격리를 제공하고 최근 3년 정도의 브라우저와 호환되기 때문에 유용하다고 봄
    • 웹 컴포넌트에서는 “요소를 정적으로 렌더링해 보내고 현대 JS로 동적으로 갱신”하는 개념이 내부적으로 어떻게 달라지는지 궁금함

  • JS 파일에서 커스텀 컴포넌트를 만들기 시작하면 사실상 자기만의 마이크로프레임워크를 쓰는 것 아닌가?
    번들러나 컴파일러, 예를 들어 TS에서 JS로 변환하는 도구는 필요 없을 수 있음
    하지만 어느 순간 컴포넌트의 fetch() 비동기 업데이트가 필요하고, 그 컴포넌트들이 다른 컴포넌트와 상태를 공유해야 할 수 있음
    그 지점부터는 직접 만든 것이든 남의 것이든 프레임워크 영역에 들어감
    그런 기능을 갖추면서도 작은 단일 JS 파일에 들어가는 프레임워크가 나오면 좋겠음
    특히 공유 상태에 따른 컴포넌트 업데이트를 할 수 있고, 매번 DOM 전체를 갱신하지 않는다면 더 좋음

    • 바닐라 JS에서 로컬 상태 관리와 서버 측 동기화를 구현하는 라이브러리를 찾아봤고, 가장 나은 선택지는 @tanstack/query-core[1]와 @signaldb/core[2]였음
      전자는 의존성이 없고, 모듈 JS 코드를 모두 합쳐 단일 파일에 넣어도 축소 전 전체 크기가 89.18 kB임
      트리 셰이킹과 축소를 하는 최적화 번들러를 쓰면 더 작아질 수 있음
      [1]: https://www.npmjs.com/package/@tanstack/query-core
      [2]: https://www.npmjs.com/package/@signaldb/core
    • 그래서 Lit과 FAST 같은 Web Components용 마이크로프레임워크가 늘고 있음
      내 Butterfloat도 Web Components에서 꽤 잘 동작한다고 보지만, 유일한 의존성이 RxJS라서 마이크로프레임워크가 아니라고 따질 사람도 있을 것임
      RxJS는 사람들이 기억하는 것만큼 비대하지는 않지만 그런 평판이 있음
      Shadow DOM은 DOM 성능에 도움이 되지 않고 어떤 것은 더 나쁘게 만들 수도 있음
      Web Component가 Shadow DOM 안에서 DOM 성능이 형편없다면 전체 DOM 성능도 눈에 띄게 나빠질 수 있음
      점점 Shadow DOM은 하려는 일에 비해 과하게 복잡하고, 대부분의 Web Components에는 실제로 필요 없으며, 없을 때 자기 성능 문제도 더 잘 파악할 수 있다고 생각하게 됨
      과격하게 말하면 Shadow DOM은 성능 좋은 UI를 만들기 위한 것이 아니라 더 튼튼한 iframe을 원하는 광고주를 위해 만들어진 것 같음

  • 이 끝없는 논의는 웹 앱과 웹 사이트의 차이를 생각하면 훨씬 쉬워짐
    둘은 항상 뒤섞여 말해지고, 물론 약간 겹치는 벤 다이어그램 영역은 있지만 기본적으로 완전히 다른 짐승이고 완전히 다른 기술적 접근이 필요함

  • 좋은 자료임
    웹을 만드는 사람이라면 누구나 웹이 어떻게 동작하는지 이해하고, 기초 웹 스택을 사용할 줄 알아야 한다고 봄
    웹 플랫폼 자체를 활용한 다음, 트레이드오프를 인식한 상태에서 각자 판단에 따라 빌드 시스템과 선호 프레임워크를 쓰면 됨
    개인적으로 Remix와 React Router v7+에서 가장 좋아하는 점 중 하나는 웹 표준을 활용하고 더 적게 해서 더 많이 하는 철학에 명시적으로 맞춰져 있다는 점임
    예를 들어 서버 데이터를 변경할 때 HTML form 태그를 쓰는 식임
    또한 브라우저 내장 CSS만으로 성능 좋고 접근 가능하며 유연한 웹 레이아웃을 구현하는 눈이 트이는 기법을 보여주는 https://every-layout.dev를 강력히 추천함
    맥락상 1998년부터 전문적으로 웹 개발에 관여해왔음

  • 내가 극소수이거나 어쩌면 유일할 수도 있지만, 프레임워크를 정말 견딜 수 없음
    강력할 수는 있지만 그만큼 비대함과 복잡성도 있음
    내 생각에는 이런 “강력함”은 제어 역전 프레임워크 대신 라이브러리로도 쉽게 얻을 수 있음
    보통 짧고 헷갈리는 프레임워크 언어를 배운 뒤에는 Java, C#, JavaScript, Python 같은 기반 언어와 함께 그 프레임워크 언어까지 알아야 함
    프레임워크가 이렇게 인기 있는 이유는 제품 오너와 관리자들이 개발자가 쓰는 도구 수를 체크하는 걸 좋아하기 때문이라고 느낌. 그래야 자신들이 중요하고, 지식 있고, 효율적인 것처럼 보임

    • 프레임워크의 큰 장점은 팀들이 아키텍처를 두고 덜 싸우게 된다는 점이라고 봄
      프레임워크가 그 결정을 대신 내려주기 때문임
      또한 그 아키텍처가 특정 문제군에서 잘 동작해온 검증된 이력도 있음
      호환되는 인재를 찾기도 훨씬 쉬움
      프레임워크를 쓴다면 같은 프레임워크로 몇 년 일해본 사람을 찾아 빠르게 쓸모 있어질 가능성에 더 안전하게 걸 수 있음
      자체 맞춤 시스템이라면 신입이 기존 시스템의 기묘함과 뉘앙스에 익숙해지고 덜 망가뜨리기까지 몇 년이 걸릴 수도 있음
    • 대기업과 특정 팀에는 합의할 표준이 필요함
      문제는 책임자가 충분한 검토 없이 잘못된 프레임워크를 밀어붙이는 경우가 잦고, 아무도 말하지 않거나 피드백을 무시한다는 것임
      게다가 그 프레임워크가 사내 제작이면 훨씬 나쁨
      완전히 망가진 것을 만들어놓고도 비판을 잘 받아들이지 않음
    • 동의함. 이건 커리어 중심 헛소리 빙고임
      주니어가 시니어보다 우위를 얻을 기회를 줌. “JavaScript 마이크로프레임워크 2025 #10도 모르세요?” 같은 식임
      시간 단위 과금에 얽힌 사람들, 직원과 컨설턴트 모두에게 “리팩터링”할 이유를 만들어주고 마법의 돈나무를 계속 살려둠
    • 어떤 사람들은 일할 때 스스로를 돕기 위해 프레임워크를 만듦
      어떤 사람들은 프레임워크를 만들 생각조차 없지만, 습관과 패턴이 강하게 반복되다 보면 자연스럽게 프레임워크가 생김
      누군가에게 도움이 되는 방식이 당신을 얽히게 만들 수도 있고, 그건 정상임
      미워하기보다는 그 프레임워크가 왜 특정한 일을 특정한 방식으로 하는지 이해해보는 편이 낫다고 봄

  • WebComponents가 다른 웹 프레임워크에서 말하는 컴포넌트의 좋은 대체재라고 보지 않음
    우선 객체나 배열 같은 복잡한 값을 속성으로 지원하지 않음
    작성해야 하는 보일러플레이트가 너무 많고, 여전히 반응성도 없음
    나는 signals[1]를 써서 바닐라에 가까운 JS를 작성함
    W3C가 내놓는 모든 것이 정전이 되어야 하는 건 아니며, XHTML이 그 증거임
    [1] https://wrnrlr.github.io/prelude/

    • Shadow DOM을 완전히 무시하면 WebComponents의 보일러플레이트 상당수가 사라지고, 그냥 그렇게 해도 됨
      객체와 배열도 옛 점진적 향상 시대, 즉 jQuery/Knockout 시대의 웹처럼 data- 속성과 dataset 속성을 통해 속성으로 지원할 수 있음
      그 시절과 비슷하게 정적 사이트 생성이나 서버 사이드 렌더링 지원을 위해 해당 속성에 대한 JSON 직렬화·역직렬화는 여전히 지원하고 싶을 것임
    • 함께 볼 만한 것들:
      Meiosis Pattern:
      https://meiosis.js.org/docs/01-introduction.html
      Mithril:
      https://mithril.js.org/
답변달기