▲

플레인 바닐라 웹

 (plainvanillaweb.com)
2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • HTML, CSS, JavaScript만을 사용한 기본 웹 개발 기술에 대한 설명
  • 빌드 도구와 프레임워크 없이 표준 웹 기술만으로 사이트와 애플리케이션 구현 방법 소개
  • 웹 컴포넌트 및 현대적인 CSS 기능을 활용한 구조화와 스타일링 방법을 다룸
  • 프레임워크의 복잡성과 유지 관리 부담 없이 심플한 개발 환경과 장기적인 이점을 추구함
  • 이미 웹 표준 기술을 익힌 개발자를 주 타겟으로 하는 튜토리얼

Plain Vanilla 웹 개요

웹 개발에서 빌드 도구와 프레임워크 없이 표준 웹 기술만으로 사이트와 애플리케이션을 만드는 주요 기법에 대한 개요임

  • 에디터, 브라우저, 웹 표준만을 활용하는 환경 설명임
  • 초기 설정 및 서버 사이드 논리 없이 생산 환경 배포가 가능한 구조를 소개함

다루는 주제

1. 컴포넌트(Components)

  • 웹 컴포넌트를 이용해, HTML, JavaScript, CSS만으로 고수준 구성 요소로 조합하는 방법임
  • React나 Vue 같은 프레임워크 컴포넌트 접근 방식을 대체하는 방법임

2. 스타일링(Styling)

  • 최신 CSS의 강력함을 활용해 CSS Modules, PostCSS, SASS가 제공하는 편의성 대체 방법임
  • 고전적인 CSS에서 벗어나 구조적이고 모듈화된 스타일 구성 개념 제공임

3. 사이트(Sites)

  • 웹 컴포넌트 기반으로 웹 프로젝트를 구성하고, 빌드 도구나 서버 사이드 없이 배포하는 방법임
  • 실질적이고 단순한 배포 워크플로 제시임

4. 애플리케이션(Applications)

  • 싱글 페이지 웹 애플리케이션을 바닐라 기법만으로 만드는 방법임
  • 라우팅, 상태 관리 방식 설명임

권장 대상

이미 HTML, CSS, JavaScript를 어느 정도 다룰 수 있는 개발자를 대상으로 함

  • 웹 개발을 처음 시작하는 사람에게는 Odin Project나 MDN과 같은 기초 학습 경로를 추천함

왜 바닐라 방식인가

현대 프레임워크들은 구조적이고 강력한 기능을 빠르게 제공하지만, 도구 및 프레임워크 복잡성 증가와 꾸준한 유지 관리 부담이 수반됨

  • 플레인 바닐라 방식은 단기적 편의성 일부를 포기하는 대신, 단순함과 사실상 제로-유지 관리라는 장기적 이점 제공임
  • 오늘날의 브라우저들은 우수한 웹 표준 지원으로 이러한 접근이 실제로 가능함
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 나는 이제는 "바닐라냐 프레임워크냐" 논쟁에서 벗어나 '이거에 정말 웹사이트가 필요한가?'라는 관점으로 생각함
    웹앱, 특히 B2B SaaS 분야에 실제로 그런 웹이 필요한지가 회의적으로 느껴지기 시작하면, 브라우저를 손대지 않고도 비즈니스를 꽤 멀리까지 끌고 갈 수 있다는 사실을 발견하게 됨
    내가 웹사이트, 앱을 만드는 데 쏟았던 시간의 대부분은 관리형 UI/UX, 즉 관리자가 데이터베이스 필드를 바꿔서 애플리케이션이 고객 기대에 맞게 동작하게 하는 부분에 집중되어 있었음
    여러 상황에서, 비즈니스에 단순히 설정 템플릿(엑셀 파일 등)을 주고 결과를 SQL 테이블에 직접 삽입·병합하는 방식이 훨씬 빠르고 쉬우며 쓸데없는 작업이 적음
    웹은 한 가지 UI/UX 방식만 제공함. 이메일이나 평문 파일이 오히려 더 유연함

    • Digital-first 컨설팅 회사들이 B2B 영역에서 쓸데없이 멋진 웹앱을 만드느라 기민하지 못한 걸 자주 봄
      특히 정부기관 등 구매자가 제대로 알지 못하고 자주 과다 비용을 지불하는 문제가 있음
      구매 담당자들이 무엇이 필요한지 더 교육받을 필요가 있음
    • 나는 온라인에서 유골 단지를 판매함. 내 사이트에는 이메일 링크만 있음. 쇼핑 카트 없음
      실제 유골 단지 매장이 카트를 갖고 있지 않은데, 가상 매장이 왜 필요하겠음
      특수 목공 공구를 온라인으로 구매할 때도, 단순히 폼에 입력 후 부품을 송장과 함께 받았으며, 원하는 경우 결제를 하지 않아도 상관없었음
      온/오프라인 모두 다양한 방식의 커머스가 존재하며, 흥미로운 방식으로 살아가는 사람들을 유심히 보면 곳곳에서 발견 가능함
    • 거의 CRUD 이상이 아닌 내부 툴의 경우, 웹은 외부 컨설턴트가 한 번에 만들거나 사내 팀이 영원히 돌볼 수 없는 상황에서 가장 쓸모 있음
      유지보수 역량이 조금만 있으면, 엑셀 템플릿 + 간단한 커스텀 스크립트 방식이 훨씬 유연해짐.
      최종 사용자가 결국 원시 데이터 다루는 수준의 유저라면 매우 효과적임
    • B2B 영역이 SaaS 전에는 100% 이런 식으로 운영됨
      그리고 여전히 B2B의 99%는 이 방식을 따름

  • 나는 프레임워크를 반대하지 않음. 다만 많은 경우 불필요하다고 느낌
    코드 한 줄도 쓰기 전에 왜 100KB짜리 JS를 추가해야 하는지 늘 의아했음
    내 팀과 함께 https://restofworld.org 를 아무 프레임워크 없이 지음
    서베이, 아웃리치, 이메일 피드백 모두 사용성과 읽는 경험 면에서 굉장히 긍정적이었음
    나중에 프레임워크도 쓸 수는 있으나, 아직까지는 그냥 바닐라 JS가 매우 잘 맞음

    • 이 댓글이 이런 논의에서 늘 나타나는 단절의 좋은 예시임
      한쪽에는 30명 이상 팀에서 대형 웹앱을 만드는 이들이 있고, 이들은 프레임워크 없이 만든다 하면 곧바로 큰 규모의 필수 기능 처리에 대한 의문이 쏟아짐
      하지만 그 답은 해당 기능을 필요로 하지도 않으며, 블로그 같은 용도이기 때문에 애초에 프레임워크의 필요성이 없음
      반대로 엄청난 대규모 웹앱 경험 없는 사람들은 "왜 사람들은 프레임워크를 쓰냐"라고 생각함
      웹은 정말 다양한 소프트웨어의 집합체임.
      그러니 프레임워크에 대해 논할 때, 대상이 어떤 소프트웨어 종류인지 명확히 밝혀야 한다고 생각함
      이 경우, 이것은 워드프레스 블로그임
    • 페이지가 훌륭하고 로딩도 좋지만, 이건 TFA(원글)가 설명한 방식과는 관계가 없음
      워드프레스라는 대형 프레임워크를 쓰고 있고, 단지 정적으로 렌더링하고 있음
      TFA는 빌드 툴 아예 없이, 최신 웹 표준만을 사용하는 것을 말함. 오직 에디터, 브라우저, 웹표준만 쓰는 것임
    • "코드 한 줄도 안 쓰고 100KB JS를 왜 추가해야 하냐"
      내가 일한 기업용 앱에서는 100KB 걱정은 전혀 필요 없음
      대부분 다중 팀이 만든 대형 앱이고, React 등 썼음.
      Lob/B2B에서 초기 페이지 로드는 아무도 신경 안 씀
      유저들은 매일 앱을 쓰며, 대부분 브라우저 캐시에서 바로 정적 자산을 쓸 수 있음
      Next.js 같은 스마트 프레임워크 쓰면 라우트 단위로 내용이 불변(immutable)하게 chunk로 분리됨
      초기 렌더는 정적 HTML이라 사용자 입장에서 하이드레이션도 눈에 띄지 않음
    • 사이트가 멋짐. 좋은 기사도 발견함
      하지만 바닐라 vs 프레임워크 논쟁에서 이런 예시가 늘 뉴스/기사 사이트임을 보면 복잡한 앱에 해당하지 않기 때문에 "난 애초에 프레임워크 안 썼을 것"이란 생각이 듦
      결국 실사용 예시는 더 상호작용 많은 앱이 필요함
      요즘은 프레임워크와 일관된 패턴만 쓰고, 다른 의존성은 최소화하는 방식 선호함
    • 이 구조의 장점 중 하나는 브라우저의 앞/뒤 역사 탐색이 아주 빠르다는 점임
      아이폰에서는 항상 뒤로 갔을 때 전체 페이지가 다시 로딩되는게 너무 익숙해져 있었음
    • 축하함! 사용성 확보가 1등이라고 생각함
      그러나 개발자들은 재미삼아 로딩 스크린, 하이드레이팅 컴포넌트, 과한 애니메이션, 짜증나는 모달 등에 집착함
    • 프레임워크를 쓰지 않아서인지는 모르겠지만, 뒤로/앞으로 탐색 시 URL은 곧바로 바뀌는데 페이지가 업데이트되지 않아 같은 기사에 머무는 문제가 있음
      또, 무한 스크롤은 스크롤 바 위치로 내가 어디 있는지 추적이 힘들게 만들기 때문에 사용성에 치명적임
    • Rest of World가 호주에서도 아주 빠르게 작동하며, 처음 보는 환상적인 뉴스 사이트임.
      구축에 참여한 점 칭찬함
    • 워드프레스로 정적 페이지 생성한 것의 미학임
    • 대다수 프레임워크는 100KB의 JS 필요 없음
      Mithril 같은 경우 모든 기능이 10KB gzipped에 가능함
    • 바닐라 예시들의 문제는 페이지들이 지나치게 단순하고 UX도 기본만 들어있는 경우임
      검색 기능 있는 리액티브 테이블, 라벨·검증·에러가 제대로 된 폼, 이런 행동성을 직접 구현한다고 생각하면, Svelte UI 라이브러리와 25KB 오버헤드로 잘 만들어진 검증된 제품을 쓸 수 있는데 왜 굳이 직접 만들겠음
    • 메인 이미지는 200KB가 넘는데, 100KB 논쟁 의미 없음
      그리고 워드프레스도 프레임워크임
      프레임워크 써도 느리지 않음. 워드프레스든 뭐든
    • 현대 웹의 비대함을 보여주는 좋은 예시임
      너무 빠름
    • 진짜 빠름!
    • Rest of World 대단히 좋아함
    • "100KB JS를 왜 추가해야 하냐"
      개발자 생산성을 위한 것임(이론적으론).
      실제로는 그다지 도움 안되는 경우도 많음
    • 사이트가 진짜 빠름. 예전에도 이런 저널리즘 봤던 적 있음
      이 접근방식의 날카로운 문제점이 있었는지 궁금함
    • 뭐? 그건 불가능함
    • 누구도 100KB 신경 안 씀

  • 약 2천 명 유저를 위한 시스템을 개발하고 있는데, 이들은 리액티브한 UI를 전혀 신경 쓰지 않음
    모노리스 만들고, 페이지 새로고침에도 신경쓰지 말고, 그냥 일 처리에 집중하는 방식이 제일임

    • 반론으로, 많은 기존 데스크톱 앱들이 결국 웹으로 이전됨
      그 동기가 크게 기술적이지 않고, 네이티브 앱 배포가 너무 비용이 커서임
      웹은 앱 배포 표준을 저렴하게 제공하나, UI 기술은 여전히 별로임
      과거 X11, Java, Flash 등 여러 어중간한 시도들이 있었고, 언젠가 더 편한 웹앱 개발 방법이 생기길 바람
    • CSS의 @view-transition 만으로도 부드러운 트랜지션 가능함
      https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
    • 요즘 시대에는 너~무 둔감한 의견임
      대부분 소프트웨어가 120년 전 기계식 장치보다 훨씬 느리고 덜 반응함
    • 그냥 CSS, JS만으로도 초단순한 새로고침 다이나믹스를 쉽게 만들 수 있음
      npm 패키지 불러올 필요 없음
    • React와 서버 간 분리도 엉망임
      백엔드는 express/node, 전체 코드는 같이 있는데, dev 환경에서는 서버가 리액트 기본 서버로 구동되고, 실제 배포에선 다르게 돌기 때문에, 결과적으로 괴상한 방식의 빌드·운영이 필요해져 dev 서버의 편의성(핫 리로드 등)이 무색해짐
    • SPA가 MPA보다 더 깨진 걸 많이 경험함
      Reddit, X(Twitter 등) 같은 대기업 SPA도 모바일에서 너무 불안정했음
      트위터 급이 아니면, 또는 API 기반 플랫폼이 아니면 굳이 SPA 고집할 필요 없다고 생각함
      수십억 회사를 포함해 누구도 제대로 구축 못한 걸, 내가 더 잘할 수 있다는 자신감은 금물임
    • 바닐라 방식의 장점은 기존 SSR 사이트도 확장 가능하다는 점임
      모든 걸 React로 뜯어고칠 필요 없음
      원문 저자가 말한 고급 SPA-like 기능들은 옵션 사항임
    • 실용주의적인 유저들은 신경 안 쓰지만, 그냥 막 클릭하는 유저들은 메인 피드로 돌아가기 위해 기다리기보다 뒤로가기 버튼을 누르게 되고, 그 타이밍이 CDN에서 최신 프레임워크를 받아오는 시간보다 더 빠름
    • 페이지 새로고침이 정말 빨라야만, 나는 그 의견에 동의함
    • 사용자들이 실제로 페이지 리프레시 자체를 전혀 신경 안 쓴다는 점을 어떻게 아는지 묻고 싶음
      이탈한 사람까지 조사해봤는지 궁금함

  • 이런 세상에 살고 싶음
    나는 프레임워크 이전 시대에서 왔으며, 그 시절은 아직 미성숙했고, jQuery만 아는 사람도 흔했음
    지금은 post-query selector 프레임워크의 비용 대비 효과가 크다고 보기 어렵다고 느껴짐(테스트 프레임워크는 별개로 아주 좋음)
    우리는 React라는 프레임워크 감옥에 갇혀 있고, 모든 실패는 스파게티화된 복잡성의 결과임
    state machine은 하드코딩으로 꼬이고, 번역·압축·트랜스파일된 결과물은 알아보기 힘든 상태임
    소스맵도 유지보수의 또 다른 복잡성 레이어임
    프레임워크가 만들어진 이유는 인정하나, 신규 엔지니어가 바닐라 JS보다 프레임워크 계속 배우는 게 더 쉽다고는 상상하기 힘듦

    • 나도 그런 옛날 시절을 경험했고, 가장 큰 문제는 우리가 문서 포맷 위에 앱 생태계를 쌓기로 했다는 점임
      HTML은 텍스트 렌더링 좀 더 쉽게 하려고 만든 마크업에 불과했고, HTTP도 마찬가지였음
      과거엔 text-to-markup 비율이 높아야 했으나, 지금은 완전히 뒤바뀜
      하지만 앱 개발을 전부 이 위에 얹은 게 미래라고 믿었고, React의 내부도 보면 수십 년간의 꼼수와 트릭임
      예전에는 엑셀+VB로 앱을 만들거나, PDF+PostScript 조합으로 앱 만드는 것처럼 말도 안되는 시도였음
      그렇게 해왔으니 JS 수MB, JS 메가바이트 소모가 과하게 느껴짐
    • 내게 있어 요즘의 킬러앱은 반응성임
      데이터 변경에 UI가 곧바로 반응하는 부분인데, 이걸 수동으로 리스너 만들고 diff 업데이트하고, 이벤트 해제까지 하면 거의 수동 메모리 관리하는 느낌임
      jQuery 시절 그랬고, 실수 많았음
      구성요소(Component) 기반으로 뷰-선언형으로 모듈화가 가능해지면 그때 가서 바닐라 JS로 돌아가겠지만 나는 아직은 절대 무리로 봄
      결정적 요소가 부족함
    • 나 역시 KISS 원칙 등에 젖은 향수인지 헷갈릴 때가 있음
      React, Angular는 ES2015 전엔 분명 의미 있었음
      그 이후엔 프런트엔드 프레임워크 변화에 질렸음
      React 안에서도 component 방식, 상태관리 방식이 계속 바뀜
    • 수억 뷰 서비스를 한다면 실제로는 정적 사이트에 훨씬 가까운 구조일 것이라 상상함

  • 나는 Web Components에 아직 동의하지 않음
    특히 @scoped, import {type:css} 등 최근 기능이 있어도, 그냥 요소를 정적으로 렌더한 후, 최신 JS로 동적으로 업데이트하는 게 훨씬 의미 있다고 봄
    대부분의 Web Components 방식에 회의적이고, 계속 React/Svelte 같은 프레임워크 바깥에서 혁신해야 한다고 믿음
    Web Components가 내가 운영하는 여러 사이트에 유용하다고 느낀 적 없음

    • Web Components는 내 문제가 해결되는 게 아니라, 오히려 새로운 문제가 추가됨
      Shadow DOM 관련해서 페이지마다 몇십 번씩 언급되는데 이건 오히려 도입함으로써 생기는 문제 해결이 대부분임
      내 앱 전용 컴포넌트라 Shadow DOM 문제도 없음
    • "정적 요소 렌더 + 최신 JS로 동적 갱신"
      Web Components는 backend에서 어떤 식으로 이걸 처리하나 궁금함
    • Web Components는 명확한 추상화 경계를 제공함
      자신만의 태그에 추가 메서드를 붙이고, 업데이트 로직도 컴포넌트 내부에서 캡슐화 할 수 있음
    • 다시 Unobtrusive JS(비침입형 JS)로 돌아가야 한다고 생각함
      가벼운 라이브러리 위주 또는 직접 작성할 수 있는 실천법이 필요함
      HTMX는 일부 좋으나, 여전히 script 태그처럼 동작하고, URL/메서드는 HTML에만 명확하게 두고, hx-target 같은 건 JS에서 data- attribute로만 지정하면 충분함
      안 쓰는 HTMX 기능까지 모두 포함되는 건 원치 않음

  • 나는 Web Components가 다른 프레임워크에서 컴포넌트라 부르는 요소의 대체품이라고 생각하지 않음
    복합값(Object, Array 등)을 속성에 넣을 수 없고, 보일러플레이트가 너무 많으며, 반응성도 없음
    나는 signals[1] 방식으로 바닐라 JS류 코딩을 함
    모든 W3C 표준이 정답은 아니고, XHTML 실패 사례를 참고해야 함
    [1] https://wrnrlr.github.io/prelude/

  • http://youmightnotneedjs.com

  • 이건 취미로 웹페이지 만드는 이들에게 잘 맞는 접근 같음
    프레임워크는 표준화, 모범사례 내장 설계, 그리고 빠른 개발 착수를 위한 목적임
    웹사이트 자체에는 본질적 가치가 없고, 그 내용을 어떻게 효율적으로 노출하고 제 시간에 올바르게 개발하느냐가 관건임
    이런 점에서 프레임워크는 현재/미래 비용을 낮춰줌

    • 이게 '공식적인 내러티브'이지만, 실제로 항상 맞는 건 아님
      실제 대기업에서 의사결정은 유행·관행·인기 프레임워크에 대한 방어적 의식에 따라 좌우되고, 복잡성 증가로 인한 생산성 저하가 추적되지 않으며, 오히려 잘못된 결정이 개인/팀 인센티브엔 맞음
      즉, "합리적 선택일 수밖에 없다"는 논리로 프레임워크 선택을 정당화할 수 없음
    • React 및 관련 프레임워크들이 만든 프로젝트가 완벽하게 관리되지 못한 사례도 많이 목격함
      애초에 프레임워크를 쓴다고 해서 자동으로 모범사례가 지켜지는 것도 아니고, 오히려 더 과하게 비대해지고 느린 시스템이 만들어질 수 있음

  • 정말 훌륭한 자료임
    웹을 만든다면 기초 기술의 원리를 꼭 알고, 웹 플랫폼을 십분 활용할 수 있어야 한다고 생각함
    그 위에 빌드 시스템/프레임워크 사용 여부는 트레이드오프만 인지한 채 자유롭게 선택하면 됨
    개인적으로 Remix(/React-router v7+)를 좋아하는 것은 웹 표준 철학과 맞닿아있기 때문임
    즉, 더 적은 개발로 더 많은 것(서버 데이터 변경을 HTML form만으로도 가능)을 이룰 수 있음
    또 https://every-layout.dev 도 추천함. 브라우저 네이티브 CSS만으로 구현하는 고성능·접근성·유연성 레이아웃의 다양한 테크닉을 배울 수 있음
    나 자신은 1998년부터 전문가로 웹 개발에 종사함

  • 지난주에 완전히 바닐라만으로 작은 프로젝트를 구현해서 매우 잘 작동하고 있음
    Mastodon 긴 스레드 작성 웹툴임
    만드는 내내 "프레임워크 없이 내가 뭔가 잘못하고 있는 건가?" 하는 생각이 들었음
    다른 사람들은 모두 프레임워크를 기대하는 분위기임
    Splinter, splinter.almonit.club, 참고할 사람은 참고하면 됨

답변달기