자바스크립트를 HTML만으로 대체하기

• 웹에서 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에 위임하는 방향 제시

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

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

자동완성 제안 입력창

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

모달 / 팝오버

• popover 및 popovertarget 속성으로 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 최소화와 성능 최적화를 통한 사용자 경험 개선 강조

[skageektp]

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

뭔가 내용이 짤린거같아요

[xguru]

수정해두었습니다~!

[shakespeares]

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

[GN⁺]

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에 대한 반감은 단순한 기술 문제가 아니라 광고 생태계에 대한 불신에서 비롯된 것임

[labeldock]

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