Hacker News 의견

• 내 불만 중 하나는 웹사이트가 onclick 핸들러로 네비게이션을 구현하는 것임
  그냥 <a> 태그를 쓰면 새 탭 열기, 접근성 장치 통합, 오른쪽 클릭 메뉴 등 모든 게 자동으로 잘 작동함
  네비게이션이라면 자바스크립트 수프 대신 링크를 써야 함

  • 최근 몇 년간 이런 식으로 구현하는 사례가 늘었음
    아마 프레임워크 영향이나 무관심 때문일 것임
    그래도 전통적인 방식이 UX 면에서는 거의 항상 더 나음
    <a> 태그를 대체하려는 사람들에게는 약간의 불편함이 있기를 바람
  • React로 시작한 개발자들이 기초 HTML 개념을 배우지 않고 바로 “재미있는 것”으로 뛰어든 게 문제라고 생각함
    이런 사람들이 잘못된 패턴을 만들어서 후속 개발자들이 그대로 따라감
    <div>를 버튼처럼 꾸며야 했던 경우는 극히 드물었음
  • JS 기반 스크롤도 없애야 함
    나는 마우스 가운데 버튼으로 스크롤을 자주 하는데, 많은 사이트가 이걸 망가뜨림
  • 이 얘기를 들으니 Microsoft Office 365의 링크 체커가 떠오름
    왼쪽 클릭하면 안전성 검사 페이지가 뜨는데, 가운데 클릭하면 그냥 바로 이동함
  • 최근 참여한 React 프로젝트에서도 모든 네비게이션이 onClick으로 되어 있음
    사실상 링크인 요소조차 전부 클릭 핸들러로 처리되어 있어서 이해가 안 됨

• 대부분의 버튼에는 type="button"을 명시해야 함
  기본값은 submit이라 폼 안에 있으면 자동으로 제출됨
  아마 일부 개발자들이 이걸 몰라서 <div>를 쓰는 듯함

  • OP의 긴 글에서 이 핵심 정보가 빠졌다고 생각함
    기본 타입 버튼은 이상하게 동작해서 JS 핸들러를 건너뛰기도 함
  • 기본값은 <input type="submit">에 해당하고 <button>은 다름
  • 나도 이걸 직접 겪으며 배움
  • <div>를 쓰면 type="submit" 문제를 피할 수 있음
    <div>는 처음부터 비어 있어서 필요한 기능만 추가할 수 있고, 나중에 수정도 쉬움
    반면 <button>은 기본 동작을 이해하려면 문서를 봐야 함
    결국 명시적 제어 vs 내장 기능의 선택 문제임

• “그 목적에 맞게 만들어진 HTML 요소를 그대로 쓰자”는 방향으로 글을 확장했으면 좋겠음
  많은 SPA 개발자들이 HTML 요소의 의미를 잘 몰라서 매번 바퀴를 다시 만듦

  • 요소들이 좀 더 스타일링 가능했으면 좋겠음
    예를 들어 기본 date picker는 너무 못생겨서 JS 기반으로 대체하게 됨
  • “플랫폼을 그대로 사용하라”는 말이 HTML5 이후 프론트엔드에서 자주 나오지만, 아직 모든 곳에 퍼지진 않음
  • 실제로는 대부분의 개발자가 HTML 요소를 거의 모르고, DIV 하나로 모든 걸 해결하려 함
  • 2010년쯤에는 브라우저마다 버튼 스타일이 달라서 직접 만들어야 했음
    그래서 커스텀 버튼이 생겨난 배경이 있음

• 요즘은 클릭 가능한 영역을 찾느라 화면을 이리저리 누르는 세대가 생겼음
  10년 전 누군가가 링크 드래그를 텍스트 선택보다 중요하게 만들어서 이제는 텍스트 선택이 거의 불가능함
  이걸 고치려면 브라우저를 포크해야 할지도 모름

  • 나는 링크를 드래그해서 백그라운드 탭으로 여는 습관이 있음
    Alt(또는 Option) 키를 누르면 링크 안의 텍스트를 선택할 수 있음
  • iOS에서 전화번호를 복사하려다 자동으로 전화 걸리는 것도 비슷하게 짜증남
    정말 원치 않는 동작임
  • 선택 불가능한 텍스트는 미치게 함
    macOS의 TextSniper 앱을 쓰면 영역을 선택해 OCR로 텍스트를 복사할 수 있음
    덕분에 Google Analytics도 조금 쓸 만해짐
  • 나도 링크 안의 일부 텍스트를 선택하려다 실패하는 일이 많음
    이런 문제는 더 자주 언급되어야 함
  • 링크 텍스트 선택용 브라우저 확장도 있음
    예전엔 Select Like A Boss, 지금은 Drag-Select Link Text라고 함

• Chrome의 기본 스타일시트에 button {align-items: flex-start}가 있어서 flexbox 크기 오류로 한참 헤맸음
  그래도 가능한 한 올바른 HTML 요소를 쓰려 하지만, 작은 사이드 프로젝트에서는 <div>가 더 편할 때가 있음

  • appearance: none 속성이 버튼 스타일 초기화에 유용함
    나는 .unbuttonify 클래스를 만들어서 버튼처럼 동작하지만 다른 모양을 내게 함
  • 프론트엔드 개발자라면 CSS 기본기를 알아야 한다는 점을 강조하고 싶음

• 가능한 한 요소를 본래 의도에 맞게 사용해야 함

• 버튼에 대한 두 가지 불만이 있음
  하나는 어차피 스타일을 다시 입혀야 한다는 점,
  또 하나는 버튼을 중첩할 수 없다는 경고임
  이건 현실적으로 꽤 자주 마주침

• LLM이 이런 잘못된 패턴을 자주 생성함
  브라우저의 기본 기능을 무시하고 복잡하게 구현하는 경우가 많음
  나는 Claude에게 이런 코드를 단순화하라고 자주 지시함
  TypeScript에서도 에러 처리 방식을 이상하게 만드는 경향이 있음

  • LLM은 코드를 쓰는 능력은 뛰어나지만, 소프트웨어 엔지니어링 감각은 부족함
  • 토큰 예측 특성상, LLM은 복잡한 패턴을 더 자주 선택함

• 나는 가능한 한 버튼을 기본으로 사용함
  단, 실제로는 링크처럼 동작해야 하는 경우엔 <a> 태그를 씀

  • URL이 바뀌면 링크, 안 바뀌면 버튼으로 구분하는 편임
  • “웹앱 내에서 이동하는 하이퍼링크”라면 그건 <a> 태그임

• 왜 <div>를 쓰자는 의견이 나오는지 궁금했음

  • 아마 <div>가 이상한 외형 커스터마이징에 더 유리해서일 것임
    그래서 버튼처럼 보이지도, 동작하지도 않게 됨
  • 예를 들어 TV Tropes 같은 사이트는 긴 목록을 “폴더” 형태로 접었다 펼치는데, 이걸 <div onclick>으로 구현했었음
  • 가장 흔한 이유는 기본 버튼 스타일을 덮어쓰기 귀찮아서임