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

> Clean Markdown view of GeekNews topic #25400. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25400](https://news.hada.io/topic?id=25400)
- GeekNews Markdown: [https://news.hada.io/topic/25400.md](https://news.hada.io/topic/25400.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-29T09:41:02+09:00
- Updated: 2025-12-29T09:41:02+09:00
- Original source: [htmhell.dev](https://www.htmhell.dev/adventcalendar/2025/27/)
- Points: 24
- Comments: 5

## Summary

**HTML과 CSS만**으로 **인터랙션을 구현하는 흐름**이 확산되고 있습니다. `details`·`summary`, `datalist`, `popover` 같은 표준 요소를 활용하면 아코디언, 자동완성, 모달 등 기존에 **JavaScript가 담당하던 기능을 네이티브하게 처리**할 수 있습니다. 이러한 접근은 **다운로드·파싱·메모리 사용량을 줄여** 전반적인 성능을 높이고, JavaScript는 복잡한 로직에만 집중하도록 돕습니다.

## Topic Body

- 웹에서 **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](https://aarontgrogg.com/blog/2023/05/31/replace-js-with-no-js-or-lo-js-options/)”에서 확인 가능  
- **JS 최소화와 성능 최적화**를 통한 사용자 경험 개선 강조

## Comments



### Comment 48404

- Author: labeldock
- Created: 2025-12-29T16:44:30+09:00
- Points: 3

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

### Comment 48400

- Author: skageektp
- Created: 2025-12-29T15:12:16+09:00
- Points: 1

> ** 와 ** 요소로 JS 없이 아코디언 구현 가능  
  
뭔가 내용이 짤린거같아요

### Comment 48406

- Author: xguru
- Created: 2025-12-29T16:51:15+09:00
- Points: 1
- Parent comment: 48400
- Depth: 1

수정해두었습니다~!

### Comment 48399

- Author: shakespeares
- Created: 2025-12-29T14:59:10+09:00
- Points: 1

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

### Comment 48368

- Author: neo
- Created: 2025-12-29T09:41:02+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46407337) 
- 모든 예시를 **인라인**으로 넣지 않은 게 아쉬움  
  코드펜 링크 대신 HTML 대체 예시를 직접 페이지에 넣었으면 훨씬 설득력 있었을 것 같음  
  - 완전 공감함. 종종 FooMaker v1.0 같은 걸 클릭하면, 정작 일반적인 사용 예시는 없고 **엉뚱한 예외 케이스**만 보여주는 경우가 많음  
  - 처음엔 25년 된 글인 줄 알았음. **디더링된 GIF**가 완전 복고 감성임  
  - 나도 인라인 예시가 없어서 답답했지만, 이게 **게스트 블로그 포스트**라면 어느 정도 이해는 감  
- `<details>` / `<summary>` 태그의 잠재력이 정말 대단함  
  거의 모든 걸 할 수 있는데, 대부분의 컴포넌트 라이브러리가 이걸 무시함  
  aria 속성도 필요 없고 접근성도 기본 제공됨  
  - 예전엔 cmd+f 검색이 닫힌 details 안의 텍스트를 못 찾는 게 단점이었는데, 이제는 **hidden="until-found"** 속성과 이벤트로 해결 가능함  
  - 다만 **애니메이션 처리**는 까다로움. display 전환에 대한 트랜지션을 브라우저가 기본 지원하지 않음  
  - ctrl+f로 검색하면 details가 자동으로 열리는 기능도 있음  
  - `<details>`는 **GitHub** 같은 마크다운 기반 사이트에서도 작동함. 긴 로그를 접어서 깔끔하게 올릴 수 있음  
  - 순수 CSS로도 구현 가능함. 예시로 [Go101 문서](https://docs.go101.org/std/pkg/io.html)에서 “+”를 눌러 확장할 수 있음. 또 [탭 패널 데모](http://tmd.tapirgames.com/demos.html#section-demo-4)도 있음. **Modern CSS**의 힘을 보여줌  
- 핵심은 “no JavaScript”가 아니라, HTML이 이미 **잊혀진 기능들**(폼, 다이얼로그, 검증, 내비게이션 등)을 다루고 있다는 점임  
  책 [“You Don’t Need JavaScript”](https://theosoti.com/you-dont-need-js/)를 쓰면서 느낀 건, 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 블로그 글](https://developer.chrome.com/blog/a-customizable-select) 참고  
- 순수 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에 대한 반감은 단순한 기술 문제가 아니라 **광고 생태계에 대한 불신**에서 비롯된 것임