서서히 죽어가는 Internet Explorer와 점진적 향상의 미래
원문
Oliver Williams, https://alistapart.com/article/the-slow-death-of-internet-explorer-and-future-of-progressive-enhancement
해당 글은 A List Apart와 Oliver Williams의 허락을 받아 번역하였습니다.
Translated with the permission of A List Apart and Oliver Williams.
필자는 풀타임 개발자의 업무를 작은 회사에서 처음 맡았다. 우리는 BrowserStack을 가지고 있지 않았기 때문에 임시 변통 장치 실험실을 함께 만들었다. 부서진 1세대 iPad와 오래된 버전의 Safari로 그 웹사이트를 봤을때, 필자는 왜곡과 부서진 잔해들이 보였다. 필자는 한때 웹을 "상상할 수 있는 가장 적대적인 소프트웨어 엔지니어링 환경"이라고 생각했던 Douglas Crockford의 말을 떠올렸다.
'Chrome에서 가장 잘 작동합니다'라는 문제
이러한 어려움들 때문에 문제가 발생했다. 올해 초 Verge 의 광범위하게 공유 된 기사는 웹에서 볼 수있는 "Chrome에서 가장 잘 작동합니다."메시지에 대해 경고했다.
이 문제의 예가 더 있다. 널리 사용되는 메시징 앱 슬랙(Slack)은 Chrome에서만 음성 통화가 작동한다. 도움 요청에 대한 응답으로 Slack은 다음과 같이 설명했다. "모든 브라우저에서 기능을 지원하고 우선순위를 나누어 문제를 해결하려면 상당한 노력이 필요 하므로, 저희는 Chrome에서 훌륭한 경험을 제공하는 데 중점을 두고 있습니다."(강조는 필자가 넣었다.) Google 자체에서는 Google Meet, Allo, YouTube TV, Google 어스, YouTube Studio 등 사이트를 차례대로 구축하면서 대체 브라우저들을 완전히 차단했다. 이것은 분명히 나쁜 습관이지만 브라우저 간 호환성을 맞추는 것은 어려우며 많은 시간을 소모하게 한다는 것은 사실이다.
인상적인 기능 격차는 Chrome과 다른 모든 브라우저 사이의 일이 아니다. Internet Explorer와 다른 모든 주요 브라우저 사이에서도 간격이 갈수록 커지고 있다. 우리의 개발 관행이 과거에 의해 방해 받아야 하는가? 아니면 우리가 미래에 일부 사용자를 포기하는 일에 뛰어들어야 할까? 필자는 중도에 대해 이야기할 것이다. 우리는 웹의 이전 버전과의 호환성을 깨지 않으면서 더 쉽게 수정할 수 있다.
점점 더 벌어지는 격차
Chrome, Opera 및 Firefox는 지속적으로 새로운 기능을 제공한다. Edge와 Safari는 결국 따라 잡고 있다. 한편 Internet Explorer는 Windows 사용자들을 Edge쪽으로 밀어 붙이려하는 MS에 의해 버려졌다. IE는 보안 업데이트 말고는 받는 것이 없다. 클라이언트 측 개발자에게는 실망스러운시기이다. 우리는 새로운 기능들을 읽고 사용하려 하지만, 시장 점유율이 줄어들고 있는 단 하나의 브라우저 때문에 새로운 기능을 사용할 수 없는 경우가 많다.
2013 년부터 2018 년까지 Internet Explorer의 글로벌 시장 점유율을 보여주는 그래프로, 약 23 %에서 약 3 %로 감소했다. 2013 년 이후의 Internet Explorer의 세계 시장 점유율은 진한 파란색으로 표시된다. 현재는 3 %에 불과한다.
일부 새로운 기능은 아주 사소한 것이다 (caret-color!). 일부는 결코 사용할 수없는 특별한 사용 사례이다(WebGL 2.0, 웹 MIDI, 웹 블루투스). 하지만 다른 것들은 이미 가장 단순한 사이트에서도 거의 필수적이라고 느끼고 있다(object-fit, grid).
caniuse.com에서 Chrome에서 지원되지만 IE11에서는 사용할 수 없는 기능의 목록이다. 매우 긴 목록의 잘린 불완전한 스크린 샷이다.
점진적 향상의 약속과 현실
콘텐츠 기반 사이트의 경우 브라우저 지원에 대한 질문에 간단히 예 또는 아니오로 대답해서는 안된다. CSS와 HTML은 결함에 내성을 갖도록 설계되었다. 특정 브라우저가 shape-outside나 서비스 워커(service worker), font-display를 지원하지 않더라도 해당 기능을 계속 사용할 수 있다. 여러분의 웹 사이트는 폭발하지 않는다. 해당 기능이 지원되지 않는 브라우저에서는 그저 스타일리시한 문체나 성능 최적화만 잘 동작하지 않을 뿐이다.
CSS Grid 처럼, 다른 기능들을 사용하려면 조금 더 작업이 필요하다. 여러분의 페이지 레이아웃은 필요한만큼 진보된 것이 아니며, 그리드가 마침내 실제 레이아웃 시스템을 웹에 도입했다. 구조가 간단한 경우 주의를 기울여 사용하면 Grid는 이전 레이아웃 기법으로 정상적으로 되돌아 갈 수 있다. 예를 들어, 우리는 flex-wrap을 사용해서 돌아갈 수 도 있다. Flexbox는 지금은 개발자들 사이에서 사용해도 안전하다고 알려져 있지만, IE11에서는 버그 로 가득 차 있다.
.grid > * {
width: 270px; /* no grid fallback style */
margin-right: 30px; /* no grid fallback style */
}
@supports (display: grid) {
.grid > * {
width: auto;
margin-right: 0;
}
}위의 코드에서 그리드의 모든 직계 자식에 지정된 너비와 여백을 설정한다. 그리드를 지원하는 브라우저들에서는, 필자가 사용하는 grid-gap 대신에 margin 과 함께 항목의 폭을 정의하는 grid-template-columns속성을 사용하면 된다. 어렵지는 않지만 다른 레이아웃의 코드베이스에서 반복 될 경우 복잡도가 증가한다. 우리가 그리드 (그리고 결국 display: contents)로 전체 페이지 레이아웃을 만들기 시작할 때, IE에 대한 대체 수단을 제공하는 것은 점점 어려워 질 것이다. 복잡한 레이아웃 작업을 위해 우리는 @supports를 사용하여 효과적으로 동일한 문제를 두번 해결했다.
모든 기능을 향상 기능으로 사용할 수있는 것은 아니다. 어떤 것들은 필수적이다. 사람들은 2013 년부터 CSS 사용자 지정 속성에 대해 흥미를 느끼고 있지만, 여전히 널리 사용되지는 않고 있으며, 여러분은 이런 이유를 추측 할 수 있을 것이다. Internet Explorer는 CSS 사용자 지정 속성을 지원하지 않는다. 아니면 그림자 DOM을 사용해라. 사람들은 5년 넘게 이것에 대해 논의해 왔다. 마침내 Firefox와 Edge에 올해에 정착했고, Internet Explorer에도 적용 되 .... 는 일은 일어나지 않을 것이다. 여러분은 트랜스파일러(transpilers) 또는 폴리필(polyfill) 또는 prefix들로 패치를 지원할 수 없다.
지금 사용자들은 어느 때보 다 많은 브라우저를 선택할 수 있지만, IE는 홀로 불멸의 과거 웹과 우리를 묶어둔다. Chrome 전용 웹 사이트를 개발하는 것이 나쁜 개발 관행의 극단적인 상황을 대표한다면, 퇴화하고, 쓸모없는 좀비 브라우저에 자신을 속박하는 것은 또 다른 나쁜 관행을 대표한다.
억지 해결책의 문제(The problem with shoehorning)
최신 자바 스크립트 기능을 피하는 대신, 폴리필과 트랜스파일링을 사용하는 것이 표준이 되었다. ES6는 IE가 아닌 모든 곳에서 지원 되지만, 아직 우리는 모든 브라우저에서 코드의 번역된 버전을 보낸다. 트랜스파일링은 성능에 좋지 않다. 예를 들어, 5줄의 async 함수는 트랜스파일 되면 25줄의 코드로 바뀔 수 있다.
Alex Russell 은 바벨 (Babel)을 앞선 트랜스파일러인 Traceur의 개발을 주도했던 이전의 역할에 대해 "현재 상황에 대해 약간의 죄책감을 느낀다"고 말했다. "바벨 (Babel)의 오버헤드와 불쌍한 [webpack] foo의 조합이 사이트 성능을 완전히 떨어 뜨리는 흔적들을 많이 보고 있다.... 우리가 여전히 이런 게임을 하고 있다는 것이 슬프다."
여러분이 트랜스파일 할 수 없는 것은, 대부분 폴리필할 수 있다. Polyfill.io는 대단히 인기가 많아졌다. Chrome은 빈 파일을 전송 받는다. 하지만 IE의 오래된 버전은 태산 만큼의 폴리필을 받는다. 우리는 느리고 오래된 기계에 갇혀있는 사람들에게 오히려 가장 큰 페이로드를 보내고 있다.
어떤 일을 해야할까?
콘텐츠 우선 순위 지정
겨자 자르기(역: Mustard Cut 테크닉, https://css-tricks.com/server-side-mustard-cut/)는 BBC 뉴스의 프론트 엔드 팀에 의해 널리 보급 된 기술이다. 이 접근 방식은 브라우저 시장을 2개로 줄였다. 모든 브라우저는 기본적인 경험이나 핵심 콘텐츠를 받는다. JavaScript는 더 많은 기능을 갖춘 브라우저에서만 조건부로 로드된다. 다시 2012년으로 돌아가서, 그들이 만든 기준은 다음과 같다.
if ('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) {
// load the javascript
}BBC의 수석 개발자 인 Tom Maslen은 "지난 몇 년 동안 광대역이 제공한 미친 다운로드 속도 때문에 우리 업계가 게을러 지고 있다고 느낀다. 모든 사람들은 자신의 웹 페이지가 얼마나 무거운지에 대해서 걱정하지 않으려고 JS 라이브러리, CSS 파일 및 거대한 이미지를 DOM에 추가했다. 이런 것들은 복잡한 코드를 렌더링할 수 있는 광대역 속도나 하드웨어 용량을 항상 갖추고 있지 못한 모바일 플랫폼으로 계속 이어져 왔다."
반면 Guardian 은 Internet Explorer 8에서 자바 스크립트와 스타일 시트를 완전히 생략했다. 심지어 퇴보이다.
Internet Explorer 8 에서의 Guardian의 내비게이션의 모습. 복잡하지 않고 기능을 잘 나타낸다.
Nature.com은 비슷한 접근법을 사용하여 IE10보다 오래된 모든 것에 대해 매우 제한된 스타일 시트만을 제공한다.
Internet Explorer 9에 표시된 nature.com 홈페이지.
박물관에 침입해서 고대 컴퓨터를 훔쳐 넷스케이프 네비게이터를 열었으면, 당신은 여전히 이 웹 사이트들을 행복하게 볼 수 있을 것이다. 사용자는 사이트를 방문하여 콘텐츠를 찾는다. 그들은 예쁜 그라데이션이나 둥근 테두리 사각형을 보기 위해 오는 것이 아니다. 그들은 잠재적으로 구역질을 나게 하는 시차 스크롤 애니메이션을 보러 온 것도 아니다.
웹을 위해 개발하고있는 누군가는 얼마나 오래 되었든 상관 없이 브라우저 버그를 우연히 만났을 것이다. 모든 주요 브라우저에서 새 기능을 확인하면 완벽하게 작동한다 (단 하나만 제외하고). caniuse.com의 지원 정보를 암기하고 점진적 향상 기능을 사용한다고해서 사이트의 모든 기능이 예상대로 작동하는 것은 아니다.
Safari의 최신 버전에서 본 CSS 작업 그룹을위한 W3C 웹 사이트.
여러분의 코드가 얼마나 완벽하고 잘 작성되었는지에 관계없이, 때로는 여러분의 탓이 아닌 문제가 발생하기도 한다. 최신 브라우저에서도 말이다. 사이트를 적극적으로 테스트하지 않으면 여러분이 모르는 사이에 사용자가 버그를 만날 확률이 높아진다. 트랜스파일과 폴리필이 아닌 최선의 결과를 얻기 위해 우리는 가장 탄력 있고, 가능한 가장 견고한 형태의 HTML을 제공할 수 있다. 모든 브라우저의 오래된 버전에서 자신의 웹 사이트를 적극적으로 테스트할 수 있는 리소스가 있는 회사는 어디에도 없다. JavaScript가 제대로 작동하지 않으면 웹 환경이 손상되고 간단한 페이지를 사용할 수 없게 될 수 있다. 사용자가 대량의 폴리필을 전달하거나 및 잠재적인 JavaScript 오류를 발생시키게 하는 대신, 사용자에게 기본적인 기능만을 제공한다.
완벽한 단절
겨자 자르기는 앞으로 어떻게 될까? 여러분은 자바스크립트의 기능 질의를 통해 조건부로 스타일시트를 로드할 수 도 있지만, 자바 스크립트에 의존하는 것은 피하는 것이 가장 좋은 것이다. 그리고 @import를 @supports 블록 내부에서 사용할 수도 없다. 그렇다면 이제 미디어 쿼리와 우리만 남았다.
다음 쿼리를 실행하면 CSS 파일이 Internet Explorer 및 다른 버전의 다른 브라우저로 전달되지 않는다.
<link id="mustardcut" rel="stylesheet" href="stylesheet.css" media="
only screen,
only all and (pointer: fine), only all and (pointer: coarse), only all and (pointer: none),
min--moz-device-pixel-ratio:0) and (display-mode:browser), (min--moz-device-pixel-ratio:0)
">우리는 이 쿼리가 테스트하는 특정 기능에 대해서는 별로 관심이 없다. 이건 그저 레거시 브라우저와 최신 브라우저를 구분할 수 있는 해킹 방법일 뿐이다. 반짝이는 현대 사이트는 Edge, Chrome (및 Android 용 Chrome) 39+, Opera 26+, Safari 9+, iOS 9 이상 Safari 및 Firefox 47+에 제공된다. 필자의 쿼리는 Andy Kirk의 쿼리를 기반으로 한다. 여러분이 겨자 자르기 접근법을 원하지만 다른 지원 요구를 충족해야하는 경우, 그가 관리하는 Github Repository에 다양한 옵션이 있다.
동일한 미디어 쿼리를 사용하여 조건부로 자바 스크립트 파일을 로드할 수 있다. 이렇게 하면 구형 브라우저와 최신 브라우저간에 하나의 일관된 구분선이 생긴다.
(function() {
var linkEl = document.getElementById('mustardcut');
if (window.matchMedia && window.matchMedia(linkEl.media).matches) {
var script = document.createElement('script');
script.src = 'your-script.js';
script.async = true;
document.body.appendChild(script);
}
})();matchMedia는 CSS 미디어 쿼리의 힘을 JavaScript로 가져온다. matches속성은 쿼리의 결과를 반영하는 boolean 값이다. link태그 에서 정의한 미디어 쿼리가 true로 평가되면 JavaScript 파일이 페이지에 추가된다.
극단적인 해결책처럼 보일 수도 있다. 마케팅의 관점에서 보면, 방문자가 적은 사이트는 더 이상 "전문적인" 것으로 보이지 않는다. 그러나 우리는 오래된 기술에 갇힌 사람들을 위해 성능을 향상시켰고, 그들을 지원할 최소 브라우저 기준에 새로운 가능성을 열었다. 이것이 새로운 접근 방식인 것은 물론 아니다. 2001년에 A List Apart는 Netscape 4에 시각적 디자인을 제공하는 것을 중단했다. 해당 브라우저 사용자 간의 독자층이 올라갔다.
지금 프론트 엔드 개발은 가장 복잡한 상태다. 기술적으로 쓸모없는 브라우저를 지원하는 것은 개발 과정에 과도한 시간과 좌절을 추가하는 것이다. 테스트는 점점 부담 스러워 지고, 버그를 수정하는 시간이 늘어난다.
과거와 완벽히 단절함으로써 테스트 되지 않고 사이트를 망칠 수 있는 낡은 브라우저를 사용하는 사용자를 내버려 두지 않으면서, 현대적인 표준을 사용하여 현대 사이트를 구축하는 데 힘을 쏟을 수 있다. 우리는 막대한 양의 정신적 오버헤드를 아낄 수 있다. 만약 여러분의 콘텐츠가 실제로 가치를 지니고 있다면 화려한 장식물 없이도 살아남을 수 있다. 그리고 Windows 10의 Internet Explorer 사용자들을 위해 Edge 브라우저가가 사전 설치되어 있다. 단 한 번의 클릭으로 모든 기능을 사용할 수 있다.
Internet Explorer 11은 항상 존재하는 "오픈 마이크로 소프트 에지"버튼을 가지고 있다.
개발자는 MacBook Pro 와 초고속 인터넷 연결을 피해야한다. 개발자가 최첨단 기능을 사용할 수 있게 해주는 마법의 탄환은 없다. AutoPrefixer 와 폴리필이 필요할 수도 있다. 아시아 및 아프리카 지역에 대규모 사용자 기반을 구축할때는 자체 제한이있는 Opera Mini 및 UC Browser에서 멋지게 보이는 사이트를 만들어야한다. 당장은 다른 대안을 선택할 수도 있지만, 현대 웹이 제공하는 것을 사용하기 위해 사용자 경험과 개발자 경험의 입장 사이에서 선택을 해야할 것이다.