약 15년 전, 저는 여행사, 공항 직원, 항공사를 위한 앱을 만드는 회사에서 일하고 있었습니다. 또한 UI 구성 요소와 단일 페이지 앱 기능을 위한 자체 내부 프레임워크를 구축했습니다. 필드, 버튼, 탭, 범위, 데이터 테이블, 메뉴, 날짜 선택기, 선택 및 다중 선택 등 모든 것에 대한 구성 요소가 있었습니다. 심지어 div 구성요소도 있었습니다. 그건 그렇고 우리의 div 구성 요소는 훌륭했습니다. 이를 통해 모든 브라우저에서 둥근 모서리를 수행할 수 있었는데, 믿거나 말거나 당시에는 쉬운 일이 아니었습니다.
우리의 작업은 JS, Ajax, 동적 HTML이 우리를 미래로 이끄는 혁명으로 여겨졌던 우리 역사의 한 시점에 이루어졌습니다. 갑자기 페이지를 동적으로 업데이트하고, 서버에서 데이터를 가져오고, 다른 페이지로 이동할 필요가 없어졌습니다. 이는 느리고 두 페이지 사이의 화면에 큰 흰색 직사각형이 깜박이는 것처럼 보였습니다. Jeff Atwood(StackOverflow의 창립자)가 유명하게 만든 문구가 있었는데, 그 내용은 다음과 같습니다. “JavaScript로 작성할 수 있는 모든 애플리케이션은 결국 JavaScript로 작성될 것입니다.”— Jeff Atwood
당시 우리에게는 이것이 실제로 그러한 앱을 만들겠다는 용기처럼 느껴졌습니다. JS로 모든 것을 할 수 있다는 것은 포괄적인 승인처럼 느껴졌습니다. 그래서 우리는 JS로 모든 작업을 수행했고, 작업을 수행하는 다른 방법을 연구하는 데는 시간을 들이지 않았습니다. 우리는 HTML과 CSS가 무엇을 할 수 있는지 제대로 배우고 싶은 동기를 실제로 느끼지 못했습니다. 우리는 웹을 전체적으로 진화하는 앱 플랫폼으로 인식하지 못했습니다. 우리는 특히 브라우저 지원과 관련하여 이를 해결해야 할 문제로 생각했습니다. 작업을 완료하려면 더 많은 JS를 추가하면 됩니다. 시간을 내어 웹의 작동 방식과 플랫폼에서 사용할 수 있는 기능에 대해 자세히 알아보는 것이 도움이 되었습니까? 물론, 실제로 필요하지 않은 코드를 삭감할 수도 있었을 것입니다. 하지만 당시에는 그다지 많지 않았을 수도 있습니다. 아시다시피 그 당시에는 브라우저 차이가 꽤 컸습니다. Internet Explorer가 여전히 지배적인 브라우저이고 Firefox가 2위를 차지했지만 Chrome이 빠르게 인기를 얻으면서 시장 점유율을 잃기 시작한 시기였습니다. Chrome과 Firefox는 웹 표준에 꽤 능숙하게 동의했지만 앱이 실행되는 환경 때문에 오랫동안 IE6를 지원해야 했습니다. IE8 지원이 허용되었을 때에도 우리는 여전히 브라우저 간의 많은 차이점을 처리해야 했습니다. 그뿐만 아니라 당시의 웹에는 플랫폼에 내장된 기능이 그다지 많지 않았습니다.
오늘로 빨리 감아보세요. 상황이 엄청나게 변했습니다. 우리는 이전보다 이러한 기능을 더 많이 보유하고 있을 뿐만 아니라 이러한 기능을 사용할 수 있는 속도도 증가했습니다. 그러면 다시 질문하겠습니다. 시간을 내어 웹이 어떻게 작동하는지, 플랫폼에서 무엇을 사용할 수 있는지 자세히 알아보는 것이 오늘 도움이 될까요? 물론 그렇습니다. 오늘날 웹 플랫폼을 이해하고 사용하는 방법을 배우면 다른 개발자에 비해 큰 이점을 얻을 수 있습니다. 성능, 접근성, 응답성 등을 모두 함께 작업하거나 UI 기능만 제공하는 등 책임 있는 엔지니어로서 작업을 수행하려는 경우 사용 가능한 도구를 알면 목표를 더 빠르고 효과적으로 달성하는 데 도움이 됩니다. 더 이상 도서관이 필요하지 않은 몇 가지 사항 오늘날 어떤 브라우저가 지원되는지 알면 문제는 무엇을 버릴 수 있는가 하는 것입니다. 2025년에 둥근 모서리를 만들려면 div 구성 요소가 필요합니까? 물론 그렇지 않습니다. border-radius 속성은 현재 사용되는 모든 브라우저에서 15년 이상 지원되어 왔습니다. 더욱 멋진 코너를 위한 코너 형태도 곧 출시될 예정입니다. 현재 모든 주요 브라우저에서 사용할 수 있고 코드베이스의 기존 종속성을 대체하는 데 사용할 수 있는 비교적 최근 기능을 살펴보겠습니다. 요점은 사랑하는 라이브러리를 모두 즉시 버리고 코드베이스를 다시 작성하는 것이 아닙니다. 다른 모든 것에 관해서는 먼저 브라우저 지원을 고려하고 프로젝트와 관련된 다른 요소를 기반으로 결정해야 합니다. 다음 기능은 세 가지 기본 브라우저 엔진(Chromium, WebKit 및 Gecko)에 구현되어 있지만 브라우저 지원 요구 사항이 다르기 때문에 바로 사용하지 못할 수도 있습니다. 하지만 지금은 이러한 기능에 대해 알아보기에 좋은 시기이며, 언젠가는 이를 사용할 계획을 세울 수도 있습니다. 팝오버 및 대화상자 Popover API,
물론 인터넷 연결 속도도 향상되었을 수 있지만 모든 사람에게 해당되는 것은 아닙니다. 그리고 모든 사람이 동일한 장치 기능을 갖고 있는 것은 아닙니다. 대신 플랫폼으로 수행할 수 있는 작업에 대해 타사 코드를 가져오는 것은 아마도 더 많은 코드를 제공하고 결과적으로 평소보다 더 적은 고객에게 도달한다는 의미일 것입니다. 웹에서 로딩 성능이 좋지 않으면 이탈률이 높아지고 브랜드 평판이 손상됩니다. 장치에서 더 적은 코드 실행 또한 플랫폼 위에서 더 적은 JavaScript 추상화를 사용하면 고객의 장치에 제공되는 코드가 더 빠르게 실행될 가능성이 높습니다. 또한 기본적으로 응답성이 더 뛰어나고 접근성이 더 높을 것입니다. 이 모든 것이 더 많은 고객과 더 행복한 고객으로 이어집니다. 내 동료 Alex Russell의 연간 성능 불평등 격차 블로그를 확인하세요. 여기에는 부의 불평등으로 인해 수십억 명의 사용자가 있는 시장에서 프리미엄 장치가 거의 없다는 것을 보여줍니다. 그리고 이 격차는 시간이 지남에 따라 점점 커지고 있습니다.
내장된 석조 레이아웃 곧 출시될 예정이며 제가 매우 기대하는 웹 플랫폼 기능 중 하나는 CSS Masonry입니다.
메이슨(Masonry)이 무엇인지부터 설명하겠습니다. 벽돌이란 무엇입니까? Masonry는 몇 년 전 Pinterest에서 인기를 끌었던 레이아웃 유형입니다. 이는 항목이 트랙 시작 부분에 최대한 가깝게 포장되는 독립적인 콘텐츠 트랙을 생성합니다.
많은 사람들은 Masonry를 포트폴리오와 사진 갤러리를 위한 훌륭한 옵션으로 보고 있으며 확실히 그렇게 할 수 있습니다. 하지만 Masonry는 Pinterest에서 보는 것보다 더 유연하며 폭포수 같은 레이아웃에만 국한되지 않습니다. 벽돌 레이아웃에서:
트랙은 열 또는 행일 수 있습니다.
콘텐츠 트랙이 모두 같은 크기일 필요는 없습니다.
항목은 여러 트랙에 걸쳐 있을 수 있습니다.
항목은 특정 트랙에 배치될 수 있습니다. 항상 자동 배치 알고리즘을 따를 필요는 없습니다.
데모 다음은 Chromium에서 곧 구현될 CSS Masonry를 사용하여 만든 몇 가지 간단한 데모입니다. 항목(이 경우 제목)이 여러 트랙에 걸쳐 있을 수 있는 방법을 보여주는 사진 갤러리 데모:
다양한 크기의 트랙을 보여주는 또 다른 사진 갤러리:
일부 트랙이 다른 트랙보다 넓고 일부 항목이 레이아웃의 전체 너비에 걸쳐 있는 뉴스 사이트 레이아웃:
항목을 특정 트랙에 배치할 수 있음을 보여주는 칸반 보드:
참고:이전 데모는 대부분의 웹 사용자가 아직 사용할 수 없는 Chromium 버전으로 제작되었습니다. 왜냐하면 CSS Masonry는 브라우저에서 이제 막 구현되기 시작했기 때문입니다. 그러나 웹 개발자들은 이미 수년 동안 라이브러리를 사용하여 Masonry 레이아웃을 만들어 왔습니다. 오늘날 벽돌을 사용하는 사이트 실제로 Masonry는 오늘날 웹에서 매우 일반적입니다. Pinterest 외에 제가 찾은 몇 가지 예는 다음과 같습니다.
그리고 덜 명확하지만 몇 가지 예는 다음과 같습니다.
그렇다면 이러한 레이아웃은 어떻게 만들어졌습니까? 해결 방법 내가 본 한 가지 트릭은 대신 Flexbox 레이아웃을 사용하여 방향을 열로 변경하고 줄바꿈으로 설정하는 것입니다. 이 방법을 사용하면 서로 다른 높이의 항목을 여러 독립 열에 배치하여 석조 레이아웃의 느낌을 줄 수 있습니다.
그러나 이 해결 방법에는 두 가지 제한 사항이 있습니다.
항목의 순서는 실제 석조 레이아웃의 순서와 다릅니다. Flexbox를 사용하면 항목이 첫 번째 열을 먼저 채우고 가득 차면 다음 열로 이동합니다. Masonry를 사용하면 항목은 사용 가능한 공간이 더 많은 트랙(또는 이 경우 열)에 쌓이게 됩니다. 그러나 또한 더 중요한 것은 이 해결 방법을 사용하려면 Flexbox 컨테이너에 고정 높이를 설정해야 한다는 것입니다. 그렇지 않으면 래핑이 발생하지 않습니다.
타사 Masonry 라이브러리 고급 사례의 경우 개발자는 라이브러리를 사용해 왔습니다. 이에 대한 가장 잘 알려지고 인기 있는 라이브러리는 간단히 Masonry라고 하며 NPM에 따르면 일주일에 약 200,000회 다운로드됩니다. Squarespace는 또한 코드 없는 대안을 위해 Masonry 레이아웃을 렌더링하는 레이아웃 구성 요소를 제공하며 많은 사이트에서 이를 사용합니다. 두 옵션 모두 JavaScript 코드를 사용하여 레이아웃에 항목을 배치합니다. 내장형 벽돌 이제 Masonry가 내장 CSS 기능으로 브라우저에 나타나기 시작했다는 사실이 정말 기쁩니다. 시간이 지나면 Grid나 Flexbox처럼 Masonry를 사용할 수 있게 될 것입니다. 즉, 해결 방법이나 타사 코드가 필요하지 않습니다. Microsoft의 우리 팀은 Edge, Chrome 및 기타 여러 브라우저의 기반이 되는 Chromium 오픈 소스 프로젝트에 기본 제공 Masonry 지원을 구현해 왔습니다. Mozilla는 실제로 2020년에 Masonry의 실험적 구현을 제안한 최초의 브라우저 공급업체였습니다. 그리고 Apple도 이 새로운 웹 레이아웃 기본 기능을 구현하는 데 매우 관심을 보였습니다. 기능을 표준화하는 작업도 CSS 작업 그룹 내에서 일반적인 방향과 새로운 표시 유형인 그리드 레인에 대한 합의를 바탕으로 진행되고 있습니다. Masonry에 대해 자세히 알아보고 진행 상황을 추적하려면 내 CSS Masonry 리소스 페이지를 확인하세요. 머지않아 Masonry가 Grid나 Flexbox처럼 기본 기능이 되면 간단히 사용하고 다음과 같은 이점을 누릴 수 있습니다.
더 나은 성능, 더 나은 반응성, 사용하기 쉽고 코드가 더 간단합니다.
이에 대해 좀 더 자세히 살펴보겠습니다. 더 나은 성능 벽돌과 같은 레이아웃 시스템을 직접 만들거나 대신 타사 라이브러리를 사용한다는 것은 화면에 항목을 배치하려면 JavaScript 코드를 실행해야 함을 의미합니다. 이는 또한 이 코드가 렌더링을 차단한다는 것을 의미합니다. 실제로 JavaScript 코드가 실행될 때까지 아무것도 나타나지 않거나 항목이 올바른 위치에 있거나 올바른 크기로 표시되지 않습니다. 석조 레이아웃은 웹 페이지의 주요 부분에 자주 사용됩니다. 이는 코드가 주요 콘텐츠를 다른 경우보다 늦게 표시하게 하여 인지된 성능과 검색 엔진 최적화에 큰 역할을 하는 LCP 또는 콘텐츠가 포함된 최대 페인트 지표를 저하시킨다는 것을 의미합니다. 저는 간단한 레이아웃과 DevTools의 느린 4G 연결을 시뮬레이션하여 Masonry JS 라이브러리를 테스트했습니다. 라이브러리는 그다지 크지 않지만(24KB, 7.8KB gzipped), 제 테스트 조건에서는 로드하는 데 600ms가 걸렸습니다. 다음은 Masonry 라이브러리의 긴 600ms 로드 시간과 그 동안 다른 렌더링 활동이 발생하지 않았음을 보여주는 성능 기록입니다.
또한 초기 로드 시간 이후에는 다운로드한 스크립트를 구문 분석하고 컴파일한 다음 실행해야 했습니다. 앞에서 언급했듯이 이 모든 것이 페이지 렌더링을 차단하고 있었습니다. 브라우저에 내장된 Masonry 구현을 사용하면 로드하고 실행할 스크립트가 없습니다. 브라우저 엔진은 초기 페이지 렌더링 단계에서만 해당 작업을 수행합니다. 더 나은 반응성 페이지가 처음 로드될 때와 마찬가지로 브라우저 창 크기를 조정하면 해당 페이지의 레이아웃이 다시 렌더링됩니다. 하지만 이 시점에서 페이지가 Masonry JS 라이브러리를 사용하고 있다면 스크립트를 다시 로드할 필요가 없습니다.여기. 그러나 항목을 올바른 위치로 이동하는 코드가 실행되어야 합니다. 이제 이 특정 라이브러리는 페이지가 로드될 때 이 작업을 수행하는 데 꽤 빠른 것 같습니다. 그러나 창 크기 조정 시 항목을 다른 위치로 이동해야 할 경우 항목에 애니메이션을 적용하므로 이는 큰 차이를 만듭니다. 물론 사용자는 개발자만큼 브라우저 창 크기를 조정하는 데 시간을 소비하지 않습니다. 그러나 이 애니메이션 크기 조정 환경은 꽤 불편할 수 있으며 페이지가 새로운 크기에 적응하는 데 걸리는 시간을 더 많이 느끼게 합니다. 사용 용이성과 더 간단한 코드 웹 기능을 사용하는 것이 얼마나 쉬운지, 코드가 얼마나 단순한지는 팀에 큰 변화를 가져올 수 있는 중요한 요소입니다. 물론 최종 사용자 경험만큼 중요할 수는 없지만 개발자 경험은 유지 관리 가능성에 영향을 미칩니다. 내장된 웹 기능을 사용하면 다음과 같은 중요한 이점이 있습니다.
HTML, CSS, JS를 이미 알고 있는 개발자는 해당 기능을 쉽게 사용할 수 있을 것입니다. 왜냐하면 이 기능은 나머지 웹 플랫폼과 잘 통합되고 일관성을 갖도록 설계되었기 때문입니다. 기능 사용 방식에 중대한 변경이 도입될 위험이 없습니다. 해당 기능이 더 이상 사용되지 않거나 유지 관리되지 않게 될 위험은 거의 없습니다.
내장형 Masonry의 경우 레이아웃 프리미티브이기 때문에 JS 없이 Grid나 Flexbox처럼 CSS에서 사용합니다. 또한 gap과 같은 다른 레이아웃 관련 CSS 속성도 예상대로 작동합니다. 알아야 할 트릭이나 해결 방법은 없으며, 배운 내용은 MDN에 문서화되어 있습니다. Masonry JS lib의 경우 초기화는 약간 복잡합니다. 열과 간격 크기를 설정하려면 숨겨진 HTML 요소와 함께 특정 구문이 있는 데이터 속성이 필요합니다. 또한 열을 확장하려는 경우 문제를 피하기 위해 간격 크기를 직접 포함해야 합니다.
<스타일> .track-sizer, .항목 { 너비: 20%; } .gutter-sizer { 폭: 1rem; } .항목 { 높이: 100px; 마진 블록 끝: 1rem; } .item:n번째-자식(홀수) { 높이: 200px; } .item--너비2 { 너비: 계산(40% + 1rem); }
이것을 내장된 Masonry 구현의 모습과 비교해 보겠습니다. <스타일> .컨테이너 { 디스플레이: 그리드 레인; 그리드 레인: 반복(4, 20%); 간격: 1rem; } .항목 { 높이: 100px; } .item:n번째-자식(홀수) { 높이: 200px; } .item--width2 { 그리드-열: 범위 2; }
그리드에서와 마찬가지로 간격과 스패닝 트랙이 범위 2로 수행되는 곳 등을 사용할 수 있고 간격 크기를 포함하는 올바른 너비를 계산할 필요가 없는 더 간단하고 컴팩트한 코드입니다. 무엇이 사용 가능하고 언제 사용 가능한지 어떻게 알 수 있나요? 전반적으로 문제는 JS 라이브러리를 통해 내장된 Masonry를 사용해야 하는지 여부가 아니라 언제 사용해야 하는지입니다. Masonry JS 라이브러리는 놀랍고 수년 동안 많은 행복한 개발자와 사용자를 위해 웹 플랫폼의 공백을 채워 왔습니다. 물론 내장된 Masonry 구현과 비교하면 몇 가지 단점이 있지만 해당 구현이 준비되지 않은 경우에는 중요하지 않습니다. 나는 브라우저 공급업체에서 일하기 때문에 이러한 멋진 새 웹 플랫폼 기능을 쉽게 나열할 수 있고 따라서 앞으로 어떤 일이 일어날지 알고 있는 경향이 있습니다. 그러나 개발자들은 설문 조사를 거듭하면서 새로운 것을 추적하는 것이 어렵다는 점을 자주 공유합니다. 최신 정보를 유지하는 것은 어렵고, 어쨌든 기업이 항상 학습을 우선시하는 것은 아닙니다. 이를 돕기 위해 간단하고 간결한 방식으로 업데이트를 제공하여 필요한 정보를 신속하게 얻을 수 있는 몇 가지 리소스는 다음과 같습니다.
웹 플랫폼에는 탐색기 사이트가 있습니다. 릴리스 정보 페이지에 관심이 있을 수 있습니다. 그리고 RSS가 마음에 드신다면 릴리스 노트 피드와 새로 출시된 기준 및 광범위하게 사용 가능한 피드를 확인해 보세요.
웹플랫폼 상태 대시보드: 다양한 기준 연도 페이지가 마음에 드실 겁니다.
Chrome 플랫폼 상태의 로드맵 페이지.
시간이 조금 더 있으면 브라우저 공급업체의 릴리스 노트도 읽어보실 수 있습니다.
크롬 가장자리 파이어폭스 사파리
더 많은 리소스를 보려면 내 웹 플랫폼 탐색 치트시트를 확인하세요. 내 일은 아직 구현되지 않았습니다 그것은 문제의 다른 측면입니다. 추적할 시간과 에너지, 방법을 찾더라도 자신의 의견을 전달하고 즐겨 사용하는 기능을 구현하는 데에는 여전히 불만이 있습니다. 특정 버그가 해결되거나 특정 기능이 아직 누락된 브라우저에 제공되기를 수년 동안 기다려왔을 수도 있습니다. 제가 말씀드리고 싶은 것은 브라우저 공급업체는 귀를 기울이고 있다는 것입니다. 저는 개발자 신호와 피드백을 항상 논의하는 여러 조직 간 팀의 일원입니다. 우리는 각 브라우저 공급업체 내부와 포럼, 오픈 소스 프로젝트, 블로그 및 설문조사를 통한 외부/공개 등 다양한 피드백 소스를 살펴봅니다. 그리고 우리는 개발자가 특정 요구 사항과 사용 사례를 공유할 수 있는 더 나은 방법을 만들기 위해 항상 노력하고 있습니다. 따라서 가능하다면 브라우저 공급업체에 더 많은 것을 요구하고 필요한 기능을 구현하도록 압력을 가해 주십시오. 시간이 걸리고 위협적일 수도 있지만(진입 장벽이 높다는 것은 말할 것도 없고) 효과가 있다는 것도 알고 있습니다. 귀하(또는 귀하 회사)의 목소리를 들을 수 있는 몇 가지 방법은 다음과 같습니다. 연례 JS 현황, CSS 현황 및 HTML 현황 설문조사에 참여하세요. 브라우저 공급업체가 작업 우선순위를 정하는 데 큰 역할을 합니다. 여러 브라우저에서 일관되게 구현하기 위해 특정 표준 기반 API가 필요한 경우 다음 Interop 프로젝트 반복 시 제안서를 제출하는 것이 좋습니다. 시간이 더 필요하지만 Shopify와 RUMvision이 어떻게 Interop 2026에 대한 희망 목록을 공유했는지 생각해 보세요. 이와 같은 자세한 정보는 브라우저 공급업체가 우선순위를 정하는 데 매우 유용할 수 있습니다. 브라우저 공급업체에 영향을 미칠 수 있는 더 유용한 링크를 보려면 내 웹 플랫폼 탐색 치트시트를 확인하세요. 결론 마무리하면서, 이 기사를 통해 다음과 같은 몇 가지 사항에 대해 생각해 볼 수 있기를 바랍니다.
Masonry 및 기타 향후 웹 기능에 대한 기대가 큽니다. 사용해 보고 싶은 몇 가지 웹 기능. 내장된 기능을 위해 제거할 수 있는 사용자 정의 또는 타사 코드 몇 가지. 앞으로 나올 내용을 추적하고 브라우저 공급업체에 영향을 미치는 몇 가지 방법입니다.
더 중요한 것은 웹 플랫폼의 잠재력을 최대한 활용함으로써 얻을 수 있는 이점을 여러분에게 확신시켰기를 바랍니다.
