20P by GN⁺ 3일전 | ★ favorite | 댓글 5개
  • 웹에서 JS 의존 기능을 HTML/CSS로 대체할 수 있는 최신 방법들을 소개
  • details·summary , datalist , popover 등 표준 요소를 활용해 아코디언, 자동완성, 모달, 오프스크린 내비게이션을 구현
  • 이러한 접근은 다운로드·평가·메모리 사용량을 줄여 성능과 사용자 경험을 개선
  • 각 기능별로 CodePen 예시, MDN 문서, 브라우저 호환성 정보가 함께 제공
  • JS를 꼭 필요한 영역에만 사용하고, HTML/CSS의 발전된 기능을 적극 활용해야 함

HTML과 CSS로 JS 기능 대체

  • 오랜 기간 JavaScript는 HTML과 CSS로 구현할 수 없는 기능을 담당해 왔음
    • 그러나 HTML과 CSS의 기능이 확장되면서, 일부 JS 기능을 네이티브 웹 기술로 대체 가능
  • JS는 다운로드·압축 해제·평가·메모리 유지가 필요하므로, 가능한 기능은 HTML/CSS로 이관하는 것이 효율적
  • JS는 복잡한 로직에 집중하고, 단순 UI 제어는 HTML/CSS에 위임하는 방향 제시

아코디언 / 확장 콘텐츠 패널

  • detailssummary 요소로 JS 없이 아코디언 구현 가능
    • 콘텐츠를 클릭으로 열고 닫을 수 있으며, open 속성으로 기본 상태 지정
    • 동일한 name 속성을 사용하면 하나의 패널만 열림
  • CSS로 스타일링하거나 JS로 열림/닫힘을 제어할 수도 있음
  • 관련 자료: MDN details 문서, CodePen 예시, 브라우저 호환성 표

자동완성 제안 입력창

  • input datalist 조합으로 자동 필터링 드롭다운 구현
    • 입력 시 제안 목록이 자동으로 필터링됨
    • 텍스트 외에도 number, time 등 다양한 입력 타입 지원
  • Firefox는 현재 텍스트 기반 입력만 지원하며, 모바일 접근성 제약 존재
  • 관련 자료: MDN datalist 문서, SitePoint 튜토리얼, 브라우저 호환성 표

모달 / 팝오버

  • popoverpopovertarget 속성으로 JS 없는 모달·팝오버 구현
    • auto, hint, manual 세 가지 모드 제공
    • auto는 외부 클릭이나 ESC로 닫힘, manual은 수동으로만 닫힘
  • Firefox 및 iOS는 hint 모드 미지원
  • 관련 자료: MDN popover 문서, Chrome 블로그, CodePen 예시, 접근성 관련 영상

오프스크린 내비게이션 / 콘텐츠

  • popover 기능을 활용해 오프스크린 내비게이션 메뉴 구현 가능
    • nav 요소를 사용해 의미 부여, CSS translate로 화면 안팎 이동
    • 외부 클릭 시 닫히며, popover="manual"로 수동 닫기 설정 가능
    • ::backdrop 가상 요소로 배경 반투명 처리 가능
  • 관련 자료: MDN Popover API, Chrome 블로그, CodePen 예시

결론

  • JS의 강력함을 인정하되, 필요한 곳에만 사용해야 함
  • 최근 HTML/CSS의 발전으로 JS 없는 대안이 다수 등장
  • 더 많은 예시는 작성자의 블로그 글 “Replace JS with No-JS or Lo-JS Options”에서 확인 가능
  • JS 최소화와 성능 최적화를 통한 사용자 경험 개선 강조

이런 시도는 가끔 내가 오버엔지니어링 하고 있는지 성찰은 가능하지만 풍성한 요구사항이 있는 실무의 관점에서는 차력쇼에 가까움

** 와 ** 요소로 JS 없이 아코디언 구현 가능

뭔가 내용이 짤린거같아요

수정해두었습니다~!

한계가 분명히 있고, AI가 활성화 된 순간.. 이런 리팩토링을 할 필요가 있을까요?
JS 콘텐츠 차단 이런 부분을 고려한건가요?

Hacker News 의견들
  • 모든 예시를 인라인으로 넣지 않은 게 아쉬움
    코드펜 링크 대신 HTML 대체 예시를 직접 페이지에 넣었으면 훨씬 설득력 있었을 것 같음
    • 완전 공감함. 종종 FooMaker v1.0 같은 걸 클릭하면, 정작 일반적인 사용 예시는 없고 엉뚱한 예외 케이스만 보여주는 경우가 많음
    • 처음엔 25년 된 글인 줄 알았음. 디더링된 GIF가 완전 복고 감성임
    • 나도 인라인 예시가 없어서 답답했지만, 이게 게스트 블로그 포스트라면 어느 정도 이해는 감
  • <details> / <summary> 태그의 잠재력이 정말 대단함
    거의 모든 걸 할 수 있는데, 대부분의 컴포넌트 라이브러리가 이걸 무시함
    aria 속성도 필요 없고 접근성도 기본 제공됨
    • 예전엔 cmd+f 검색이 닫힌 details 안의 텍스트를 못 찾는 게 단점이었는데, 이제는 hidden="until-found" 속성과 이벤트로 해결 가능함
    • 다만 애니메이션 처리는 까다로움. display 전환에 대한 트랜지션을 브라우저가 기본 지원하지 않음
    • ctrl+f로 검색하면 details가 자동으로 열리는 기능도 있음
    • <details>GitHub 같은 마크다운 기반 사이트에서도 작동함. 긴 로그를 접어서 깔끔하게 올릴 수 있음
    • 순수 CSS로도 구현 가능함. 예시로 Go101 문서에서 “+”를 눌러 확장할 수 있음. 또 탭 패널 데모도 있음. Modern CSS의 힘을 보여줌
  • 핵심은 “no JavaScript”가 아니라, HTML이 이미 잊혀진 기능들(폼, 다이얼로그, 검증, 내비게이션 등)을 다루고 있다는 점임
    “You Don’t Need JavaScript”를 쓰면서 느낀 건, JS는 새로운 기능을 추가하기보다 플랫폼의 기존 기능을 보완하는 경우가 많다는 것임
    • 이런 책이 더 많아졌으면 좋겠음. 단순히 프레임워크를 배우는 게 아니라 문제 해결 중심의 책이 필요함
    • 예전엔 브라우저 지원이 부족해서 개발자들이 우회로를 만들었고, 그게 표준처럼 굳어졌다고 생각함. 최근엔 CSS 기능 출시 속도가 빨라져서 masonry 레이아웃도 실험 단계에 들어감
  • 대부분의 HTML 기능은 훌륭하지만, <input><datalist>는 실사용엔 부족함
    사용자는 오타 허용, 보조 텍스트, 모바일 UX 등을 기대하지만 datalist는 이를 충족하지 못함
    • datalist에서 표시 텍스트와 실제 값(value)을 분리할 수 없다는 게 제일 불편함
    • 대부분의 경우 select가 더 적합하지만, select에는 검색 기능이 없음
    • 기본 스타일이 너무 투박하고 못생김
    • 안드로이드에서는 드롭다운이 아예 안 보임
    • 기기마다 다르게 동작해서 결국 JS를 추가해야 함. HTML만으로는 호환성 지옥에 빠짐
  • 최근 여러 프론트엔드 면접을 봤는데, 여전히 React 중심의 JS 실력만 평가함
    HTML의 의미적 사용이나 접근성은 거의 신경 쓰지 않음
    • 팀이 React를 쓰면, DOM API를 직접 쓰는 사람은 팀 적합성에서 탈락할 수 있음
    • 별도 CSS 파일을 쓰면 컴포넌트가 훨씬 깔끔해짐. Tailwind는 나쁘지 않지만 면접에서 쓰고 싶진 않음
    • HN 밖에서는 HTML 순수주의에 관심 있는 사람은 거의 없음
  • 코드펜 링크만 걸고 예시를 페이지에 직접 넣지 않은 게 거슬림
    “HTML만으로 구현하자”는 글인데 외부 서비스에 의존하는 게 모순처럼 느껴짐
    • 개인적으로는 괜찮다고 생각함. 코드펜은 북마크와 문법 하이라이트가 편리함. 다만 링크 부패(link rot) 위험이 있음
    • 그래도 인라인 예시와 코드펜 링크를 둘 다 제공했으면 좋았을 것 같음
    • HTML만 강조하면서 2MB짜리 코드펜 UI를 로드해야 하는 건 UX적으로 역설적
  • 커스터마이즈 가능한 select 기능이 곧 나올 예정이라 기대 중임
    WHATWG stage 3에 있고, JS 기반 드롭다운의 악몽 같은 구현을 대체할 수 있을 듯
    Chrome 블로그 글 참고
  • 순수 HTML은 익숙하고 편안하지만, 오늘날 기능적인 웹앱을 만들기엔 한계가 있음
    HTMX나 Phoenix LiveView 같은 대안도 써봤지만 완전한 해결책은 아님
    결국 현대 JS를 받아들이는 게 현실적이라는 생각이 듦
    • JS를 조금만 써도 HTML만 쓸 때보다 훨씬 멀리 갈 수 있음. 요즘 웹은 JS 남용으로 사용성 악화가 심각함
    • HTMX를 과하게 복잡하게 생각하는 듯함. 서버 상태를 기준으로 hx-select / hx-target을 활용하면 단순하게 유지 가능함
    • <marquee> 태그는 쇼핑몰의 수평 스크롤 구현에 적합했는데, 지금은 JS로 억지로 구현함. HTML이 더 많은 UI 패턴을 자체적으로 지원했으면 함
    • React에서 marquee 효과를 구현하려다 토큰 낭비를 많이 했음. 완벽한 루프도 아니고 그냥 애니메이션 꼼수였음
    • Elixir와 Phoenix를 쓴다면 Gleam도 고려할 만함. JS로 컴파일됨
  • HTML과 JS는 서로 다른 목적을 가진 도구임
    복잡한 웹앱은 JS가 필수지만, HTML만으로도 가능한 영역이 많음
    • Google Earth 같은 건 당연히 JS가 필요하지만, Gmail 수준은 HTML로도 가능하다고 생각함. 브라우저 벤더의 트렌드와 과대광고가 HTML 발전을 막고 있음
    • htmx는 JS와 보완 관계임. JSON 대신 구조화된 하이퍼텍스트를 주고받는 게 핵심임. 실제로 htmx + 약간의 JS로 꽤 복잡한 앱을 빠르게 만들었음
    • HTML이 더 많은 기능을 기본 제공해야 함. 예를 들어 HTTP verbs 지원, 입력 컨트롤 개선
    • 많은 JS-heavy 사이트는 사실 htmx로 충분히 대체 가능함. 도구 선택은 습관의 문제임
  • “JS가 아코디언이나 내비게이션 메뉴를 관리할 필요는 없다”는 말에 공감함
    하지만 JS는 이제 데이터 수집과 광고 추적의 핵심 도구가 되어버림
    JS 없이도 빅테크가 같은 수준의 감시와 광고 서비스를 구현할 수 있을지 궁금함
    결국 JS에 대한 반감은 단순한 기술 문제가 아니라 광고 생태계에 대한 불신에서 비롯된 것임