바닐라 자바스크립트로 DOM 조작을 완벽하게 습득하기

 (phuoc.ng)
6P by GN⁺ | ★ favorite | 댓글 1개
  • 본문은 바닐라 자바스크립트를 사용한 Document Object Model (DOM) 조작 마스터링에 대해 논의합니다.
  • Angular, VueJS, React, Solid, Svelte와 같은 현대 도구의 사용에도 불구하고 웹 개발을 위해 브라우저 DOM API 이해의 중요성을 강조합니다.
  • 저자는 기본 브라우저 API, 이해하기 쉬운 예제, 실시간 데모, 팁 및 모범 사례, 실제 사용 사례, 현대 브라우저 및 인터넷 익스플로러와의 호환성을 포함한 자료 모음을 제공합니다.
  • 이러한 자료는 기본, 중급, 고급의 세 가지 레벨로 나뉩니다.
  • 기본 레벨에는 사용자의 색상 체계 선호에 따라 파비콘을 동적으로 변경하거나, 웹페이지의 읽는 시간을 계산하고, CSS 루트 변수를 동적으로 업데이트하는 작업이 포함됩니다.
  • 중급 레벨에는 Shift+Tab 키 조합을 사용하여 텍스트 영역에서 들여쓰기를 제거하거나, 전체 화면 모드로 들어가고, 스핀 입력을 구축하는 작업이 포함됩니다.
  • 고급 레벨에는 사용자 정의 커서를 생성하거나, HTML 문자열을 살균하고, 사용자 정의 스크롤바를 생성하는 작업이 포함됩니다.
  • 저자는 모달을 열 때 레이아웃이 이동하는 것을 피하고, 텍스트 노드의 경계 사각형을 얻는 등의 팁도 제공합니다.
  • 본문은 프론트엔드 기술 콘텐츠에 대한 저자의 뉴스레터 구독 초대로 마무리됩니다.

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 예시 목록이 훌륭하고, 몇 개만 훑어봐도 세심함과 디테일이 놀라울 정도임
    React 같은 플랫폼에서 더 작고 미니멀한 구현으로 옮기면서 표준 JS로 복잡한 패턴을 어떻게 처리할지 자주 막히는데, 막상 코드를 보면 “거대한 라이브러리에 수많은 속성을 넘기는 것보다 훨씬 쉽네” 싶을 때가 있음

    • RiotJS 메이저 업데이트를 3~4번 겪고 나서 비슷한 깨달음을 얻었음
      미니멀한 JS 프레임워크도 순수해 보이는 기능 요청이 쌓이다 보면 결국 훅, 이벤트, 부작용 땜질의 괴물이 되기 쉬움
      요즘은 jQuery도 쓰지 않고, ES 모듈 같은 건 코드 정리에 쓰지만 굳이 npm 명령을 실행할 필요는 없음. 이건 벤더로 끌어와야 하는 물건이 아니라 전역 브라우저 표준임
      요즘은 MDN을 성경처럼 봄. 믿고 따라가면 거의 끝까지 데려다주고, 프레임워크는 어느 지점부터 오히려 발목을 잡음. 5년 전만 해도 이 정도는 아니었지만, 브라우저 API가 모듈, flexbox, grid 같은 강력하고 일관된 기본 요소로 빠르게 수렴했음
    • 원문 예시들은 웹 클라이언트 프레임워크와 경쟁하는 성격은 아님. 프레임워크가 푸는 일반 문제는 상태 관리와 상태 변화 시 UI 갱신임
      예를 들어 원문 예시 대부분은 React를 쓰더라도 직접 작성해야 하는 코드에 가까움

  • 사이드 프로젝트로 아직 이름 없는 “웹 디자이너를 위한 vim” 같은 걸 만들고 있음. Webflow처럼 브라우저에서 웹사이트나 컴포넌트를 만들지만, 전부 명령 언어로 구동되는 방식임
    처음엔 프레임워크 없이 하겠다고 마음먹었음. 2009년부터 이 일을 했고 프레임워크를 만지기 전부터 JS를 오래 써왔으니, 네이티브 DOM API면 충분하다고 생각했음
    그런데 DOM 안팎으로 데이터를 옮기는 일이 너무 지루하고 오류가 많아서, 정신 건강을 위해 결국 미니 프레임워크를 직접 쓰기 시작했음. 그제야 애초에 프레임워크를 쓰기 시작한 이유가 떠올랐음. 결국 어떤 형태로든 프레임워크를 쓰게 되며, 차이는 직접 만든 맞춤형이냐 커뮤니티가 만든 업계 표준이냐뿐임
    상호작용이 적은 사이트라면 네이티브 DOM도 좋고, React를 쓰는 대부분의 사이트는 사실 필요 없을 수 있음. 하지만 제품에 조금이라도 뉘앙스나 복잡도가 있으면 프레임워크를 쓰고 번거로움을 피하겠음. 결국 Svelte로 옮겼고 훨씬 만족함

    • 초미니멀 프로젝트는 결국 jquery나 lodash의 절반을 다시 구현하게 됨. 트리 셰이킹이 잘 되는 ramda 같은 좋은 라이브러리를 찾아 아껴 쓰는 편이 훨씬 쉬움
    • “프레임워크를 고르지 않으면 직접 만들게 된다”는 말이 딱 맞음
    • 이건 애플리케이션을 만드는 경우라서, 설명만 봐도 DOM 상호작용을 감싸는 편이 낫다고 추정 가능함
      상호작용이 필요한 웹사이트라면 DOM 조작이 더 근본적이고 보편적인 기술을 쓰고, 빌드 과정이 가볍거나 없고, 실행도 빠르며, 명시적이라는 점에서 더 나은 선택일 수 있음
      물론 회색지대는 많지만, 이 사례는 프레임워크가 이득인 범주에 정확히 들어감
    • 요즘 SvelteKit은 SSR 중심이고, Svelte 자체에는 기본 클라이언트 사이드 라우터가 없음. CSR 단일 페이지 앱에 Svelte를 써보려다 포기했음

  • value.startsWith('javascript:')만으로는 취약점이 생김. URL 앞에 임의의 공백이 올 수 있으니 최소한 value.trim().startsWith('javascript:')가 필요함
    그래도 차단 목록보다 허용 목록이 낫다고 봄. http:, https:와 필요하면 mailto:, ftp:, sftp: 정도만 허용하고, /로 시작하는 상대 URL은 어쩌면 허용할 수 있음
    다만 실제로 URL이 될 수 있는 모든 속성을 정확히 다뤄야 하므로, 결국 몇 가지 태그와 그 속성만 허용하는 방식이 낫겠음

  • 알아두면 유용한 목록으로 보이고, 전부 보진 않았지만 지금까지는 괜찮아 보임
    첫 번째 예시를 눌러보니 window.matchMedia('(prefers-color-scheme: dark)')를 불필요하게 두 번 실행하고 있음
    setFavicon을 이벤트 리스너 콜백으로 쓸 거라면 콜백에 전달되는 event 매개변수의 event.matches를 쓰면 됨
    개인적으로는 HTML에서 처리하는 쪽이 더 좋음. JS가 꺼진 사용자도 지원하기 때문임
    https://phuoc.ng/collection/html-dom/change-the-favicon-dyna...

    • HTML에서 처리하면 다른 테마 콘텐츠가 잠깐 번쩍이는 현상도 막을 수 있음. theme-color 메타에도 같은 방식을 적용할 수 있는데, 디테일에 신경 쓰는 PWA 개발자에게는 잘 안 쓰이지만 훌륭한 기능임

  • “textarea 자동 확장” 기법은 새 CSS 속성인 form-sizing 때문에 낡아가고 있음
    https://chriscoyier.net/2023/09/29/css-solves-auto-expanding...
    이 새 CSS 속성을 쓰지 않더라도, 요소의 height를 조정하는 방식은 이상적이지 않고 버벅일 수 있음
    더 나은 접근은 숨겨진 거울 요소를 쓰는 것임
    https://css-tricks.com/the-cleanest-trick-for-autogrowing-te...

  • 여기 있는 것들 중 꽤 여러 개는 더 나은 네이티브 API가 있는데도 오래되고 어색한 API를 쓰고 있음
    예를 들어 “요소 교체”는 ele.parentNode.replaceChild(newEle, ele);로 되어 있지만, Chrome 54 미만, Firefox 49 미만, Safari 10 미만을 목표로 하지 않는다면 그냥 ele.replaceWith(newEle)를 쓰면 됨
    replaceWith는 노드 하나를 여러 노드나 텍스트로 바꾸는 것도 가능함
    마찬가지로 “NodeList 순회”도 배열 전개 후 forEach를 쓰라고 하지만, 그냥 for (let ele of nodelist) ...면 됨

    • NodeList가 살아 있는 객체일 수 있다는 점은 기억해야 함. 순회 중 그 목록을 조작하면 예상 밖 결과가 나올 수 있음

  • 좋음. 북마크했음. 비슷한 결의 좋은 자료로 https://youmightnotneedjquery.com/도 있음
    웹 작업을 자주 하진 않지만, 할 때마다 그쪽의 프레임워크 과잉증에 완전히 의욕이 꺾임. 새 React 프로젝트가 의존성 수백 개로 시작하는 건 통제를 벗어났고, 그 복잡성의 무게가 놀라움
    반면 기본 탑재된 크로스 플랫폼 브라우저 기술은 그 어느 때보다 강력하고, 흔한 작업을 하는 코드량도 그리 많지 않음
    프런트엔드 개발자들, 괜찮은가?

    • React나 npm을 전혀 좋아하진 않지만, 일부 프레임워크는 순수 DOM API가 제공하지 않는 유용한 것들을 주므로 여전히 자리가 있다고 봄
      예를 들어 애플리케이션 상태 관리와 라우팅은 순수 DOM API만 쓰면 직접 구현해야 하는 큰 부분임
      앱 복잡도에 따라 별일 아닐 수도 있지만, 기본 앱을 넘어가는 순간 이런 추가 기능의 값어치는 빠르게 커짐. 다만 NPM이 필요한 걸 쓰고 있다면 골치 아파짐
    • 같은 결의 또 다른 훌륭한 자료로 멋진 https://javascript.info/가 있음
      기본 플랫폼과 그 기능을 좋아하는 프런트엔드 개발자로서, 중첩 CSS, 컨테이너 쿼리, ES6 이후 전반적으로 나아진 JS 경험처럼 좋은 것들이 오는 건 기쁨
      동시에 버튼이나 굵은 글자 같은 사소한 것에도 컴포넌트를 쓰는 사람이 너무 많아 놀랍기도 함
      프레임워크 자체는 좋아하지만, 많은 프레임워크와 라이브러리 마케팅은 CSS와 순수 DOM 조작이 미친 듯이 어렵고, NPM에서 아무 패키지나 끌어오는 게 빠르고 쉬울 뿐 아니라 전문적인 일이라는 믿음에 기대고 있음
    • 통제를 벗어났다는 데 동의함. 그런데 지난 1년 동안 플랫폼 팀으로 옮겨 처음으로 DevOps 쪽 도구를 다루기 시작했는데, 그 복잡도도 프런트엔드에 못지않음
      Kubernetes, Helm, Terraform, CircleCI 같은 것들만 봐도 층층이 쌓인 용어의 양이 터무니없음
    • “강력한 크로스 플랫폼 기술”로 사소하지 않은 일을 해본 적이 있는지 궁금함. 그리고 React만 선택지는 아님

  • 여러 DOM 함수가 자동으로 갱신되는 live HTMLCollection을 반환한다는 걸 알았을 때 정말 놀랐음
    프레임워크 열풍 이전이나, 다시 프레임워크 없이 개발하는 흐름이 조금 인기를 얻기 전후로 이 기능이 실제 프로덕션 코드에서 얼마나 적극적으로 쓰였는지 궁금함

  • 오래된 것이 다시 새것이 됨. 첫 프런트엔드 역할은 1999년에 웹 애플리케이션을 만드는 일이었음
    트리뷰 드래그 앤 드롭, 클릭해서 편집, 사실상 단일 페이지 앱 같은 멋진 기능까지 전부 “Vanilla” JS로 만들었음
    가장 어려운 부분은 Netscape와 Internet Explorer의 차이를 조율하는 일이었음

    • 상태와 그 변경은 어떻게 관리했는지 궁금함
      왜 이제는 그런 걸 하는 법을 모르는 것처럼 보일까 ;]

  • 요즘 가장 마음에 드는 순수 JavaScript 기능은 Chrome 1.0과 IE 시절부터 있던 Element.insertAdjacentHTML임
    특히 백틱을 쓰는 여러 줄 문자열과 함께 쓰면 유용하다는 말로는 부족함. 이렇게 오래전부터 있었는데 1년쯤 전에서야 알았다는 게 믿기지 않음
    insertAdjacentHTML(position, text)는 지정한 텍스트를 HTML이나 XML로 파싱하고, 결과 노드를 DOM 트리의 지정한 위치에 삽입함
    원래 DOM만으로 하면 li 요소를 만들고, a 요소를 만들고, 자식으로 붙이고, href 속성을 설정하고, 텍스트 값을 넣은 뒤 ul에 삽입해야 했음. 아니면 큰 문자열로 모아 innerHTML로 넣어야 했고, 기존 목록을 수정하는 건 더 고통스럽고 장황했음

    1. https://developer.mozilla.org/en-US/docs/Web/API/Element/ins...
답변달기