Chris Ferdinandi의 스매싱 팟캐스트 에피소드 21: 최신 모범 사례가 웹에 나쁜가요?

오늘날 우리는 최신 모범 사례가 웹에 나쁜지 묻고 있습니다. 현대적인 프레임워크가 우리를 잘못된 길로 인도하고 있습니까? 린 웹 전문가인 Chris Ferdinandi와 이야기를 나누었습니다.

메모 표시

• 팟캐스트에 대한 링크와 메모가 있는 Chris의 페이지
• 린 웹북
• 웹상의 크리스 퍼디난디
• 트위터의 크리스
• 바닐라 자바스크립트 팟캐스트

주간 업데이트

• "접근 가능한 HTML/CSS로 디자인 와이어프레임 변환"
  해리스 슈나이더만
• "Electron과 Vue로 데스크탑 앱 구축"
  티미 오모예니
• "가독성을 향상시키는 최신 CSS 기술"
  에도아르도 카바짜
• "리액트에서 스타일 구성 요소를 사용하는 방법"
  아데비 아데도툰 루크만
• "스케치로 포르쉐 911을 만드는 방법"
  니콜라 라자레비치

성적 증명서

Drew McLellan: 그는 Vanilla JS Pocket Guide Series의 저자이자 Vanilla JS Academy 교육 프로그램의 창시자이자 Vanilla JS 팟캐스트의 진행자입니다. 그는 팁 뉴스레터를 개발했으며 매주 거의 10,000명의 개발자가 이 뉴스레터를 읽습니다. 그는 Chobani 및 The Boston Globe와 같은 조직에서 개발자를 가르쳤습니다. 그리고 그의 JavaScript 플러그인은 Apple 및 Harvard Business School과 같은 조직에서 사용되었습니다. 무엇보다도 그는 사람들이 바닐라 자바스크립트를 배우도록 돕는 것을 좋아합니다. 그래서 우리는 그가 프레임워크보다 바닐라 자바스크립트를 선택하고 싶다는 것을 알고 있지만, 그가 범죄를 저질렀을 가능성이 가장 낮은 사람으로 경찰 라인업에서 한 번 뽑혔다는 것을 알고 계셨습니까? 내 Smashing 친구, Chris Ferdinandi를 환영하십시오. 안녕, 크리스. 잘 지내고 있나요?

크리스 퍼디난디: 오, 정말 대단하네요. 나를 주셔서 감사합니다.

Drew: 저는 오늘 이 Lean Web 개념에 대해 이야기하고 싶었습니다. 이것은 당신에게 매우 열정적이죠. 그렇지 않나요?

크리스: 네, 정말 그렇습니다.

Drew: 우리를 위해 무대를 마련해 주시지 않겠습니까? 린 웹에 대해 이야기할 때 우리가 해결하려는 문제는 무엇입니까?

크리스: 네, 좋은 질문입니다. 모든 청취자에 대한 경고처럼, 이 에피소드는 약간의 노인이 구름에 소리를 지르게 할 수 있습니다. 나는 그것을 피하기 위해 노력할 것입니다. 오늘날 우리가 웹을 위해 구축하는 방식을 볼 때, 그것은 약간 부풀려진 과도하게 엔지니어링된 엉망처럼 느껴집니다. 나는 오늘날 우리가 모범 사례라고 생각하는 많은 것들이 실제로 웹을 악화시킬 수 있다고 믿게 되었습니다.

Chris: Lean Web은 단순성, 성능 및 개발자 경험에 중점을 둔 웹 개발 접근 방식입니다. 개발자 경험이 아니라 죄송합니다. 개발자 경험보다는 사용자 경험, 그리고 팀 관점에서 쉽게 구축할 수 있습니다. 이것이 바로 오늘 우리가 가장 중점을 두는 부분이며 아마도 대화에서 다루게 될 것입니다.

Chris: 저는 실제로 우리가 개발자 경험을 개선한다고 생각하는 많은 것들이 일부 개발자를 위해 그렇게 하지만, 당신이 만들고 있는 일을 하고 있는 모든 사람들에게 반드시 그런 것은 아니라는 사실을 알게 되었습니다. 우리가 파헤칠 수 있는 문제도 많이 있습니다. 그러나 실제로 린 웹은 사용자를 위한 단순성과 성능에 초점을 맞추고 우리가 만드는 것을 만드는 사람들보다 우리가 만드는 것을 사용하는 사람들에 우선순위를 두거나 초점을 맞추는 것입니다.

Drew: 웹이 개발 플랫폼으로 성숙해짐에 따라 전문화에 대한 욕구가 계속 증가하고 있는 것 같습니다.

크리스: 네.

Drew: 풀스택을 다루던 사람들이 프론트엔드와 백엔드로 나뉩니다. 그런 다음 해당 프런트 엔드는 CSS 또는 JavaScript 개발을 수행하는 사람들로 나뉩니다. 그런 다음 JavaScript 내에서 점점 더 전문화됩니다. 누군가는 스스로를 React 개발자 또는 Angular 개발자라고 생각하고 마케팅할 수 있으며, 그들의 전체 정체성과 전망은 고도로 숙련된 특정 프레임워크를 기반으로 합니다. 이것이 웹에서 우리 작업의 핵심인 프레임워크에 대한 의존성입니까? 나쁜 일?

크리스: 미묘한 차이가 있습니다. 나는 항상 예, 항상 캠프에서 매우 강력했습니다. 제 생각에는 일반적으로 프레임워크와 도구에 대한 업계로서의 우리의 집착이 잠재적으로 우리에게 약간의 피해를 줄 수 있다고 생각합니다. 저는 프레임워크가 본질적으로 나쁘다고 생각하지 않습니다. 매우 좁은 범위의 사용 사례에 유용하다고 생각합니다. 그리고 우리는 당신이나 프로젝트를 위한 최선의 선택이 아닐 수도 있는 많은 상황을 포함하여 거의 모든 것에 그것들을 사용하게 됩니다.

Chris: 오늘날 웹에 있는 많은 문제에 대해 생각할 때 이러한 문제의 핵심은 프레임워크에 대한 과도한 의존에서 시작됩니다. 그 뒤에 오는 다른 모든 것은 여러 면에서 발생합니다. 왜냐하면 우리는 일반적으로 JavaScript인 프레임워크뿐만 아니라 웹에서 너무 많이 던지기 때문입니다. 나는 사람들에게 JavaScript를 작성하고 사용하는 방법을 전문적으로 가르치는 사람으로서 말합니다. 그게 내가 돈을 버는 방법이다. 그리고 저는 우리가 자바스크립트를 너무 많이 사용한다고 생각합니다. 이것은 때때로 약간 이상한 일입니다.

Drew: 큰 프레임워크가 등장하기 전, 우리는 jQuery 등으로 사용자 인터페이스와 사물을 구축하곤 했습니다. 그리고 프레임워크가 등장했고 상태 기반 UI라는 개념을 더 많이 제공했습니다.

크리스: 네.

Drew: 자, 그것은 당신이 제자리에 있어야 하는 상당히 복잡한 엔지니어링입니다. 더 적은 JavaScript로 작업하면 이와 같은 것을 사용하는 것이 제외됩니까, 아니면 직접 다시 구현해야합니까? 로드된 상용구를 만들고 있습니까?

Chris: 대부분은 당신이 하는 일에 달려 있습니다. 변경되지 않는 인터페이스가 있는 경우 상태 기반 UI를 빌드할 수 있습니다. 변경되지 않는 인터페이스가 있다면 솔직히 상태 기반 UI라고 말할 수 있습니다. 반드시 올바른 접근 방식은 아닙니다. 대신 할 수 있는 다른 일이 있을 수 있습니다. 정적 사이트 생성기, 일부 사전 렌더링된 마크업, 심지어 구식 WordPress 또는 PHP 기반 사이트를 생각해 보십시오.

Chris: 하지만 이것이 흥미로워지기 시작하는 곳은 보다 역동적이고 상호작용적인 인터페이스에 들어갈 때입니다. 앱뿐만이 아닙니다. 나는 사람들이 웹사이트와 앱 사이에 이 선을 그리는 것을 좋아한다는 것을 알고 있습니다. 그리고 제 생각에는 이 둘 사이에 이상한 혼합이 있고 그 선이 항상 명확하지는 않습니다. 사용자가 더 많은 작업을 수행하기 시작하면 무언가가 바뀝니다. 상태 기반 UI가 조금 더 중요해지고 있습니다. 그러나 그렇게 하기 위해 여전히 많은 코드가 필요하지 않습니다.

Chris: 저는 React 또는 Vue와 같은 것을 보고 있습니다. 이는 절대적으로 놀라운 엔지니어링 부분입니다. 나는 그 일을 하는 사람들에게서 빼앗고 싶지 않다. 나는 학습 연습으로 끝났고, 이러한 것들이 내부에서 어떻게 작동하는지 더 잘 이해하기 위해 나만의 미니 프레임워크를 구축했습니다. 다양한 움직이는 부분을 모두 설명하는 것은 정말 어렵습니다. 그래서 저는 이러한 도구를 만들고 작업하는 사람들을 대단히 존경합니다. 그러나 React와 Vue는 모두 축소하고 gzip으로 압축한 후 약 30킬로바이트입니다. 그래서 일단 포장을 풀면 그보다 훨씬 더 큽니다.

Chris: 전부는 아니지만 그 무게의 상당 부분이 가상 DOM이라고 하는 것에 할애됩니다. 유사한 API 또는 접근 방식을 사용하는 대안이 있습니다. React의 경우 30 대신 2.5킬로바이트 또는 약 3킬로바이트인 Preact가 있습니다. 크기의 10분의 1입니다. Vue의 경우 약 7KB인 Alpine JS가 대신 있습니다. 그래도 상당히 작습니다. 그들과 그들의 큰 형제 대응 물 사이의 가장 큰 차이점은 가상 DOM을 흘렸다는 것입니다. 그들은 한두 가지 방법을 포기할 수 있습니다. 그러나 일반적으로 코드 작업 방식은 동일한 접근 방식과 동일한 종류의 API이며 훨씬 더 작습니다.

Chris: 우리가 사용하는 많은 도구가 우리가 하려고 하는 일에 비해 잠재적으로 압도될 수 있다고 생각합니다. 상태 기반 UI가 필요하고 반응 데이터와 이러한 동적 인터페이스가 필요한 경우 좋습니다. 오늘 제가 시도하고 이야기하는 가장 큰 이유 중 하나는 도구를 절대 사용하지 않는 것입니다. 나에게 Vanilla JS는 코드의 모든 라인과 수행하는 모든 단일 프로젝트를 손으로 쓰는 것이 아닙니다. 그건 미친 짓이야. 나는 그것을 할 수 없었다, 나는 그것을 하지 않는다. 그러나 우리가 사용하는 도구에 대해 더 선택적으로 바뀌고 있습니다. 우리는 항상 이 모든 것이 들어 있는 멀티 툴인 스위스 아미 나이프를 찾습니다. 때로는 가위만 있으면 됩니다. 다른 모든 것들은 필요하지 않지만 어쨌든 우리는 그것을 가지고 있습니다.

Chris: 정말 먼 길입니다... 질문에 답을 해서 죄송합니다. 때로는 스스로 작성하거나 작성하고 싶은 것보다 더 많은 코드가 있지만, 우리가 필요하다고 생각하는 것만큼 많은 코드는 아닙니다. 내가 당신에게 프레임워크가 필요하지 않다고 말할 때, 나는 "글쎄, 당신이 프레임워크를 사용하지 않는다면, 당신은 기본적으로 당신 자신의 것을 작성하고 있는 것"이라는 아이디어에 대해 많은 반발을 받습니다. 그런 다음 자체 문제가 발생합니다. React나 Vue를 사용하는 것과 자신의 프레임워크를 작성하는 것 사이에 공간이 있다고 생각합니다. 아마도 조금 더 작은 것을 선택하는 것일 수도 있습니다. 수행하려는 작업에 따라 자체 프레임워크를 작성하는 것이 실제로 올바른 호출일 수 있는 이유가 있습니다. 모든 것이 매우 유동적이고 주관적입니다.

Drew: 학습 연습으로 자신의 상태 기반 프레임워크를 구현했다는 점은 매우 흥미롭습니다. 예전에 도서관이나 무언가에 손을 댈 때마다 내가 직접 구현할 수 있다는 생각을 하는 것을 좋아했던 기억이 납니다.

크리스: 물론이죠.

드류: 하지만 도서관에 찾아가는 번거로움을 덜어줬습니다. 이 코드를 직접 작성해야 한다면 어떤 접근 방식을 취해야 하는지 알고 있었습니다. 그리고 그것은 jQuery와 같은 것들을 사용하기 전까지는 사실이었습니다. 요즘에는 Vue 또는 React의 고유한 버전을 작성해야 하는 경우 해당 라이브러리에서 현재 모든 코드에서 무슨 일이 일어나고 있는지 거의 알 수 없다고 생각합니다.

Drew: 익숙하지 않은 우리에게 Preact와 같은 것이 가상 DOM을 삭제하고 모든 것을 훨씬 작게 만든다고 말할 때 가상 DOM이 우리에게 주는 것은 무엇입니까?

Chris: 그 질문에 답하기 위해 저는 약간 뒤로 물러서고 싶습니다. 프레임워크 및 기타 상태 기반 라이브러리가 제공하는 가장 좋은 것 중 하나는 DOM diffing입니다. UI를 그렇게 많이 업데이트하지 않는다면 “여기에 마크업이 어떻게 생겼는지 보여주는 문자열이 있습니다. HTML에서는 이 모든 마크업을 이 요소에 넣을 것입니다.” 변경해야 할 사항이 있으면 다시 변경합니다. 다시 그리기를 트리거하기 때문에 브라우저에서는 약간 비쌉니다.

Chris: 하지만 그보다 잠재적으로 더 중요하다고 생각합니다. 그렇게 하는 데 있어 문제 중 하나는 그 안에 어떤 종류의 대화형 요소가 있다는 것입니다. 양식 필드, 누군가가 집중한 링크입니다. 그 초점은 요소 때문에 잃습니다. 비슷해 보이는 새 항목이 있더라도 동일한 리터럴 요소가 아닙니다. 따라서 초점을 잃으면 스크린 리더를 사용하는 사람들에게 혼란을 줄 수 있습니다. 문제가 너무 많습니다.

Chris: 그 가치가 있는 상태 기반 UI는 DOM diffing을 위해 일부를 구현할 것입니다. 여기에서 "UI는 다음과 같아야 합니다. 현재 DOM에서 보이는 것은 다음과 같습니다. 무엇이 다른가?” 그리고 그것은 가서 그것들을 바꿀 것입니다. UI를 직접 수동으로 업데이트하는 작업을 효과적으로 수행하지만 내부적으로는 자동으로 수행됩니다. 따라서 "여기에 내가 원하는 모습이 있습니다."라고 말할 수 있습니다. 그러면 라이브러리나 프레임워크가 알아냅니다.

Chris: Preact나 Alpine과 같은 작은 것들은 실제로 직접 하고 있습니다. 그들은 UI가 어떻게 생겼는지에 대해 제공한 문자열을 HTML 요소로 변환하고 있습니다. 그런 다음 각 요소를 리터럴 DOM의 해당 부분과 비교합니다. 점점 더 커지고 더 커지는 UI로 끝남에 따라 DOM 쿼리를 반복적으로 수행하면 비용이 많이 들기 때문에 성능에 영향을 미칠 수 있습니다. 이것이 문제가 되는 인터페이스 유형을 파악하려면 Twitter의 "즐겨찾기" 버튼 또는 Facebook의 "좋아요" 버튼에서 요소를 마우스 오른쪽 버튼으로 클릭하고 검사하십시오. 그리고 해당 요소로 이동하는 div의 중첩을 살펴보십시오. 아주 아주 깊습니다. 그것은 12개 정도의 div와 같으며, 하나의 트윗을 위해 다른 하나가 다른 내부에 중첩되어 있습니다.

Chris: 그렇게 많은 레이어를 내리기 시작하면 성능에 실제로 영향을 미치기 시작합니다. 가상 DOM이 하는 일은 매번 실제 DOM을 확인하는 대신 JavaScript에서 UI가 어떻게 보이는지에 대한 객체 기반 맵을 생성하는 것입니다. 그런 다음 기존 UI를 교체하려는 UI에 대해 동일한 작업을 수행하고 두 항목을 비교합니다. 이는 실제 DOM에서 수행하는 것보다 이론상으로 훨씬 더 많은 성능입니다. 변경해야 할 항목의 목록을 얻으면 실행을 중단하고 변경을 수행합니다. 그러나 DOM을 한 번만 공격하면 됩니다. 모든 단일 요소를 매번 확인하는 것은 아닙니다. Twitter, Facebook 또는 QuickBooks 또는 이와 유사한 것과 같은 인터페이스가 있는 경우 가상 DOM이 아마도 많은 의미가 있을 것입니다.

Chris: 문제는... Preact와 React의 차이는 전체를 실제 코드웨이브로 풀기 전에 27킬로바이트라는 것입니다. 원시 다운로드, 압축 풀기 및 컴파일 시간만으로도 UI의 초기 로드에 상당한 대기 시간이 추가될 수 있습니다. 사용자가 Apple의 최신 장치가 아닌 경우에는 더욱 두드러집니다. 몇 년 전의 안드로이드 기기나 피처폰이라 할지라도, 개발도상국에 사람이 있다면 그것은 정말… 그리고 그 위에 추가 추상화로 인해 실제 상호 작용 시간이 더 느립니다.

Chris: 로드만 하는 것이 아니라 속도 면에서 비슷합니다. 누군가가 수행하는 각 미세 상호 작용과 발생해야 하는 변경은 거기에 있는 모든 추가 코드로 인해 약간 느려질 수 있습니다. 중첩된 요소와 데이터가 많은 정말 복잡한 UI가 있는 경우 가상 DOM의 성능 향상이 추가 코드 가중치보다 큽니다. 그러나 개발자가 React 또는 Vue를 사용하는 대부분의 일반적인 앱에 대한 일반적인 UI는 가상 DOM에서 얻을 수 있는 이점이 없으며 더 나을 것입니다. React의 편리함을 그대로 유지하고 싶다면 Preact를 사용하세요. 크기의 일부에 불과하며 정확히 동일한 방식으로 작동하며 더 많은 성능을 제공합니다. 이것은 내가 주장하는 경향이 있는 종류의 것입니다.

Chris: 작업에 적합한 도구를 선택하는 데 더 능숙해야 합니다. 이와 같은 접근 방식을 사용하면 가상 DOM이 실제로 의미가 있는 지점에 도달하면 직접 롤링하는 것보다 Preact를 React로 이식하는 것이 훨씬 쉽습니다. 그게 상황이야. 정말 걱정된다면 미래에도 대비할 수 있는 기능이 내장되어 있습니다.

Drew: 어떤 사람들은 Vue, React와 같은 프레임워크가 성능에 대해 매우 최적화되어 있어 많은 이점을 얻을 수 있기 때문에 번들러의 패키지 관리자와 페어링하여 원하는 코드만 다시 전송합니다. 확실히, 당신은 그것만으로도 이미 훨씬 앞서 있습니까?

크리스: 네. 동의하지 않습니다. 나는 그것 외에는 자세히 설명할 것이 별로 없습니다. 아마도… 번들러를 사용하더라도 여전히 React 코어가 필요합니다. 번들링을 사용하더라도 여전히 Preact와 같은 것을 사용하는 것보다 더 클 것입니다.

Chris: Drew, 이에 대한 질문을 이끌어 주셔서 감사합니다. 제 책인 The Lean Web과 같은 이름의 제 이야기에서 제가 이야기하는 다른 것 중 하나는 이러한 도구가 어떻게... 번들링에 대해 언급했습니까? 이 모든 JavaScript를 사용하여 발생하는 성능 저하를 해결하기 위해 수행하는 작업 중 하나는 이를 설명하기 위해 프런트 엔드에서 더 많은 JavaScript를 던지는 것입니다. 이를 수행하는 방법 중 하나는 패키지 관리자와 모듈 번들러입니다.

Chris: 언급했듯이... 모르는 분들을 위해 이 도구는... 작은 개별 JavaScript 비트를 모두 하나의 큰 파일로 컴파일할 도구입니다. 더 새로운 것들과 더 많은 것들... 나는 그것들을 사려깊다고 부르고 싶지 않습니다. 그러나 새로운 것들은 실제로 필요하지 않은 코드를 제거하는 트리 쉐이킹이라는 기능을 사용할 것입니다. 해당 코드에 실제로 수행한 작업에 사용되지 않는 종속성이 있는 경우 해당 항목 중 일부를 삭제하여 패키지를 가능한 한 작게 만듭니다. 그것은 실제로 끔찍한 생각은 아니지만, 일반적으로 종속성 위에 종속성 위에 종속성 카드의 매우 섬세한 집이 있는 종속성 상태라고 부르는 결과를 가져옵니다.

Chris: 프로세스를 설정하는 데 시간이 걸립니다. 그리고 NPM 설치를 실행한 다음 많은 종속성이 오래되었고 수정해야 할 항목을 파악하는 데 한 시간을 소비해야 한다는 것을 발견한 사람은 직접 고칠 능력이 없습니다. 그것은 모든 것입니다. 어쩌면 그것은 당신을 위해 작동하지만 내 종속성을 함께 얻으려고 애쓰지 않고 시간을 보내고 싶습니다.

Chris: 워크플로에 시간을 낭비한다고 불평하는 사람들의 트윗을 수집하기 시작했습니다. 내가 가장 좋아하는 사람 중 한 명인 Brad Frost는 몇 년 전에 현대 JS에서 진행한 작업이 jQuery에서는 10분이 걸릴 수 있다는 우울한 깨달음에 대해 이야기했습니다. 저는 jQuery 팬은 아니지만 프레임워크 작업에 관해서는 고통을 느낍니다.

Chris: 이러한 많은 도구의 또 다른 문제는 이러한 도구가 게이트키퍼가 되기 시작한다는 것입니다. 나는 당신이 정말로 이것에 뛰어들고 싶어하는지 아닌지 모릅니다, 드류. 그러나 JS에 대한 나의 큰 반발 중 하나는 워크플로의 모든 것입니다. 특히 "글쎄, 우리가 이미 HTML용으로 JS를 사용하고 있다면 CSS용으로도 사용하지 않겠습니까?"라고 말하기 시작할 때 특히 그렇습니다. 개발 과정에서 정말 재능 있는 많은 사람들을 제외하기 시작합니다. 커뮤니티 전체를 위한 프로젝트에 정말 큰 손실입니다.

Drew: 글쎄요, 저는 확실히… 2020년 초에 React를 배우기 시작했고 이를 제 스킬셋에 추가했습니다. 나는 거의 7개월 동안 그것을 하고 있다. 내가 가장 자신이 없는 부분 중 하나는 프로젝트 시작을 위한 도구를 설정하는 것입니다.

Drew: Hello World에 무언가를 가져오기 위해 일이 엄청나게 많은 것 같고 프로덕션 준비를 하기 위해 알아야 할 것이 훨씬 더 많습니다. 웹 개발자가 되기 위해 2020년에 해야 할 일로 이것이 제시된다면 개발을 시작하기가 더 어려워져야 합니다. 처음 접하는 사람은 큰 문제를 겪을 것입니다. 진입장벽이 정말 크겠죠?

크리스: 물론입니다. 여기서 다른 부분은 JavaScript 개발자가 항상 코드 기반에서 작업하거나 해당 코드 기반에 의미 있는 방식으로 기여하는 유일한 사람이 아니라는 것입니다. JavaScript를 알고 있어야 코드 기반 작업에 대한 요구 사항이 많을수록 해당 사람들이 실제로 프로젝트에 참여할 가능성이 줄어듭니다.

Chris: 그 예로 제가 이야기하고 싶은 WordPress는 최근에… 이 시점에서 최근에 말해서는 안 됩니다. 이제 몇 년이 지났습니다. 그러나 그들은 백엔드 스택을 본질적으로 나쁜 것이 아닌 PHP에서 JavaScript로 점점 더 많이 이동하고 있습니다. 그들의 새로운 편집기인 Gutenburg는 React를 기반으로 합니다.

Chris: 2018년에 WordPress의 수석 접근성 컨설턴트인 Rian Rietveld는 제가 거의 확실하게 살해당한 이름입니다... 그녀는 매우 공개적으로 자신의 직위에서 사임했고 그 이유를 매우 상세한 기사에서 문서화했습니다. 문제의 핵심은 그녀와 그녀의 팀이 이 편집기에 액세스할 수 있는지 확인하기 위해 감사해야 한다는 것이었습니다. WordPress는 이제 웹의 30%를 차지합니다. 그들의 목표는 출판을 민주화하는 것이므로 접근성은 그 중 정말 중요한 부분입니다. 모든 웹 프로젝트의 중요한 부분이어야 합니다. 그러나 특히 그들에게 이것은 매우 중요합니다. 그녀의 팀의 전체 업무는 다음을 확인하는 것입니다. 그녀의 팀의 전체 업무는 이 편집기에 액세스할 수 있도록 하는 것입니다. 그러나 그녀와 그녀의 팀 중 누구도 React 경험이 없었고 접근성 커뮤니티에서 해당 경험을 가진 자원 봉사자를 찾을 수 없었기 때문에 그녀와 그녀의 팀이 작업을 수행하는 것이 정말 어려웠습니다.

Chris: 역사적으로 그들은 오류를 식별한 다음 들어가서 수정할 수 있었습니다. 그러나 새로운 React 기반 워크플로에서는 버그를 식별한 다음 티켓을 제출하는 것으로 축소되었습니다. JavaScript 개발자가 작업 중인 다른 모든 기능 개발 요청과 함께 백로그에 추가되었습니다. 쉽게 고칠 수 있었던 많은 것들이 첫 번째 릴리스에 포함되지 않았습니다.

Chris: Rian이 사임한 지 약 1년 후인 2019년 5월에 Gutenburg에 대한 자세한 접근성 감사가 있었습니다. 전체 보고서는 329페이지였습니다. 요약본만 34페이지였습니다. 91개의 접근성 관련 버그를 아주 자세하게 문서화했습니다. 이것들 중 많은 부분은 정말... 단순하고 덜 매달린 과일이라고 부르고 싶지 않지만, 대부분은 Rian의 팀이 고칠 수 있고 개발자가 기능 개발에 집중할 수 있는 기본 사항이었습니다. 그것이 궁극적으로 그들이 하고 있는 것처럼 보이고 기능 개발에 많은 시간을 할애하고 이 작업을 나중으로 미루는 것이었습니다. 그러나 그 팀은 프로젝트에서 매우 중요하며 기술적인 선택으로 인해 갑자기 프로세스에서 제외되었습니다.

Chris: Alex Russell은 Chrome 팀의 개발자입니다. 그는 몇 년 전에 개발자 미끼와 스위치라는 이 기사를 썼습니다. 여기에서 그는 프레임워크에 대한 밀당론에 대해 이야기했습니다. 이러한 도구를 사용하면 더 빠르게 이동할 수 있고 더 빠르게 반복하고 더 나은 경험을 제공할 수 있다는 아이디어입니다. 더 나은 개발자 경험이 더 나은 사용자 경험을 의미한다는 것은 이러한 생각입니다. 나는 이것이 그 주장이 항상 사람들이 믿는 방식으로 진행되지 않는다는 것을 보여주는 아주 분명한 예라고 생각합니다. 모든 사람이 아니라 일부 사람에게는 더 나은 경험입니다.

Chris: CSS 개발자, 디자인 시스템에서 작업하는 사람들, 다른 사람들이 사용할 수 있는 도구를 만드는 능력은 때때로 이러한 도구 선택에 의해 제한됩니다. 제 경험상 저는 CSS를 더 잘했습니다. 지난 몇 년 동안 많이 바뀌었고 나는 예전만큼 좋지 않습니다. 내 경험상, 정말 고급 CSS 개발자들... 그리고 진정한 의미에서 말입니다. CSS 작업을 하는 사람들은 프로그래밍 언어로 작업하는 적절한 웹 개발자입니다. 그것은 매우 특별하거나 매우 전문적인 것일 수 있습니다. 내 경험상 자바스크립트를 아주 잘하는 사람들이 항상 자바스크립트도 잘하는 것은 아닙니다. 결국 한 가지에 깊이 빠져들고 다른 것들에 약간 미끄러지기 때문입니다. 이러한 기술로 작업할 수 있는 능력도 방해를 받습니다. 예전에는 그렇지 않았기 때문에 너무 나쁩니다.

Chris: 스택이 단순할수록 여러 분야의 사람들이 개발 프로세스에 참여하기가 더 쉬웠습니다. 더 이상 그렇지 않을 때 그것이 우리가 구축하는 것과 커뮤니티 전체에 해를 끼치는 것이라고 생각합니다.

Drew: 최근에 프로젝트에서 CSS 문제, 워크플로 문제를 처리하는 방법을 연구하는 중에 여러 프로젝트에서 작업하고 있고 번들 크기가 증가하고 이전 CSS가 제거되지 않는 것을 발견했습니다. 그것은 React 프로젝트였기 때문에 JavaScript 접근 방식에서 이러한 CSS 중 일부를 살펴보고 우리가 가진 문제를 해결하는 데 사용하는 것이 가장 좋았습니다. 매우 빠르게 명백해진 것은 이를 수행하는 솔루션이 하나뿐이 아니라는 것입니다. 이를 수행할 수 있는 다양한 방법이 있습니다.

Drew: JS의 CSS는 일반적인 접근 방식이지만 한 프로젝트에서 다음 프로젝트로 이동할 수 있으며 완전히 다른 방식으로 영향을 받습니다. 당신이 CSS 담당자이고 프로젝트에 대한 특정 접근 방식을 배운다고 해도 이러한 기술은 어쨌든 이전할 수 없습니다. JavaScript에 특히 익숙하지 않은 사람이 학습에 너무 많은 시간을 투자해야 하는지 확인하는 것은 매우 어렵습니다.

크리스: 네. 제가 생각하기에 당신이 방금 나온 또 다른 흥미로운 점은 제가 이것에 대해 이야기할 때 제가 받는 가장 큰 반발 중 하나는 프레임워크가 규칙을 적용한다는 것입니다. Vanilla JavaScript를 사용하고 있습니다. 이 녹색 필드-푸른 하늘이 있고 원하는 모든 것을 할 수 있는 프로젝트 종류입니다. React에는 작업을 수행하는 React 방식이 있습니다.

Chris: 하지만 내가 발견한 것 중 하나는 Reacty 접근 방식이 있지만 React로 작업을 수행하는 데 엄격하고 올바른 방법은 없다는 것입니다. 사람들이 좋아하는 것 중 하나입니다. 조금 더 유연합니다. 원하는 경우 몇 가지 다른 방법으로 작업을 수행할 수 있습니다. 뷰와 동일합니다. HTML에 속성이 있고 Vue가 이를 대체하는 HTML 기반 항목을 사용할 수 있지만 원하는 경우 JSX와 유사한 템플릿 종류의 구문을 사용할 수도 있습니다.

Chris: 여러 사람들이 React를 배울 때 불평하는 것을 들었습니다. 가장 큰 문제 중 하나는 Google에서 React에서 X를 수행하는 방법입니다. 그러면 해당 작업을 수행할 수 있는 12가지 다른 방법을 알려주는 12개의 기사를 볼 수 있습니다. 그렇다고 그들이 프로젝트에 가드레일을 두지 않는다는 말은 아닙니다. “나는 프레임워크를 선택했습니다. 이제 이것이 내가 그것을 사용하는 방법입니다.” 솔직히 그게 꼭 내가 원하는 것인지도 모르겠습니다. 나는 당신이 그 빡빡하게 갇힌 것을 원하지 않을 것이라고 생각합니다. 어떤 사람들은 아마도 그렇게 할 것입니다. 그러나 당신이 그것을 장점으로 선전한다면, 사람들이 때때로 말하는 것처럼 그렇게 확연하지는 않다고 생각합니다.

Chris: 더 이상 필요하지 않은 CSS를 언급하면서 흥미로운 사실을 알게 되었습니다. 나는 그것이 CSS 및 JS와 같은 합법적으로 흥미로운 것 중 하나라고 생각합니다. 또는 CSS를 JavaScript 구성 요소에 어떤 식으로든 묶을 수 있는 것은 해당 구성 요소가 누락되면 이론적으로 CSS도 함께 사라집니다. 나에게 이 중 많은 부분이 사람들의 문제에 엔지니어링을 던지는 것처럼 느껴집니다. 변함없이, 당신은 여전히 ​​어딘가에 있는 사람들에게 의존하고 있습니다. 그런 접근 방식을 절대 사용하지 말라는 것은 아니지만 확실히 이 문제를 해결할 수 있는 유일한 방법은 아닙니다.

Chris: HTML을 감사하고 CSS와 JavaScript를 사용하지 않고도 사용되지 않는 스타일을 추출하는 데 사용할 수 있는 도구가 있습니다. CSS를 "구식 방식"으로 작성하면서도 사용하지 않는 스타일을 계속해서 사용할 수 있습니다. CSS에 대한 저작 접근 방식은 JS와 유사한 출력으로 CSS를 제공하고 때때로 CSS 및 JS에서 얻을 수 있는 인간이 읽을 수 없는 이러한 횡설수설한 클래스 이름을 뱉어내지 않고 스타일 시트를 작게 유지합니다. X2354ABC처럼, 아니면 그냥 뱉어내는 이 말도 안되는 단어들.

Chris: 여기에서 노인이 구름에 소리를 지르는 것과 같은 것에 대해 본격적으로 빠져들기 시작합니다. 여기에서 내 개발자 나이를 실제로 보여주고 있습니다. 그러나 그렇습니다. 이러한 것들이 반드시 나쁜 것은 아니며 합법적인 문제를 해결하기 위해 만들어졌습니다. 나는 때때로 약간의… Facebook에 충분하다면, 우리에게 이런 일이 발생하는 것만으로도 충분하다고 생각합니다. 음, Facebook은 이 도구를 사용합니다. 우리가 실제 엔지니어링 프로그램이라면… 팀, 부서, 조직도 마찬가지입니다. 나는 그것이 그것에 대해 생각하는 올바른 방법이라고 생각하지 않습니다. 페이스북은 당신이 하지 않는 문제를 다루기 때문이며, 그 반대의 경우도 마찬가지입니다. 그들이 하는 일의 규모와 규모가 다를 뿐, 괜찮습니다.

드류: 맞아요. CSS 및 JavaScript와 같은 일부 항목은 폴리필과 거의 비슷합니다. 합법적인 문제가 있습니다. 해결할 방법이 필요합니다. 기술은 아직 해결 방법을 제공하지 않습니다. 웹 플랫폼이 발전하고 그 문제를 해결하기 위해 기다리는 동안, 우리가 지금 자바스크립트로 하는 이 일이 우리를 꿰뚫어 볼 것이고 우리는 괜찮을 것입니다. 우리는 그것이 나쁘다는 것을 압니다. 우리는 이것이 훌륭한 솔루션이 아니라는 것을 알고 있지만 지금 당장은 도움이 됩니다. 그리고 우리가 그것을 꺼내서 기본 솔루션을 사용할 수 있기를 바랍니다.

Chris: 당신이 이것을 꺼내는 것이 정말 재미있습니다. 말 그대로 어젯밤에 저는 작년부터 프로그레시브 웹 앱에 대한 Jeremy Keith의 강연을 보고 있었습니다. 그러나 그는 수십 년 전에 사람들이 JavaScript를 사용하도록 설득하려고 했던 방법에 대해 이야기하고 있었습니다. 그 당시에는 터무니없는 것처럼 보이지만 JavaScript는 새로운 것이었습니다. 그는 사람들에게 이 새로운 기능으로 마우스를 가져갈 때 링크의 색상을 변경하는 것과 같은 멋진 일을 할 수 있는 방법을 보여주었습니다. CSS가 당신을 위해 하는 일이기 때문에 지금 JavaScript가 필요하다는 것은 터무니없는 일입니다. 그러나 focus 속성이나 속성과 같은 것들은 그 당시에는 존재하지 않았습니다.

Chris: 그가 강연에서 말한 것 중 제가 정말 공감했다고 생각하는 것 중 하나는 JavaScript가 여러 면에서 이러한 소의 길을 열어준다는 것입니다. 이것은 아직 존재하지 않는 기능을 생성하거나 추가하는 데 사용할 수 있는 매우 유연하고 개방적인 언어입니다. 그리고 결국 브라우저는 이러한 기능을 따라잡아 보다 기본적인 방식으로 구현합니다. 하지만 시간이 걸립니다. 나는 당신이 이것에 대해 말하는 것을 완전히 이해합니다. 완벽한 솔루션은 아니지만 지금 우리가 가지고 있는 것입니다.

Chris: 제 생각에는 폴리필과 이러한 솔루션 중 일부의 가장 큰 차이점은 폴리필이 찢어지도록 설계되었다는 것입니다. 브라우저에서 아직 지원하지 않는 구현하고 싶은 기능이 있지만 이에 대한 일종의 사양이 있고 폴리필을 작성합니다… 브라우저가 따라잡으면 해당 폴리필을 제거할 수 있고 그럴 필요가 없습니다. 무엇이든 바꾸십시오. 그러나 이러한 도구 중 일부를 사용하는 경로로 이동하면 전체 코드 기반을 다시 작성해야 합니다. 정말 비싸고 문제가 많습니다. 절대 사용하지 말라는 것은 아니지만, 나중에 쉽게 뽑힐 수 있는 도구를 골라야 한다는 생각을 해야 한다는 생각이 강하게 듭니다. 더 이상 필요하지 않거나 플랫폼이 따라잡을 경우 이를 제거하기 위해 대대적으로 다시 작성할 필요가 없습니다.

Chris: 그래서 우리는 더 이상 사용하지 않는 많은 스타일을 갖게 되었습니다. 그래서 저는 개인적으로 렌더링된 마크업에 대해 CSS를 감사하고 필요하지 않은 것을 뽑아내는 빌드 도구 기술을 선호합니다. 플랫폼이 따라잡을 경우 모든 것을 변경할 필요 없이 빌드 도구의 일부를 꺼낼 수 있기 때문입니다. CSS와 JS는 같은 종류의 이점을 제공하지 않는 반면 이미 가지고 있는 것을 보강하는 것입니다. 나는 그 중 하나를 선택하고 있지만 이러한 많은 기술에 대해 더 광범위하게 생각합니다.

Chris: React 또는 Vue와 같은 것들이 브라우저가 결국 따라잡을 수 있는 일부 소 경로를 만들고 있다고 생각합니다. 동일하지 않더라도 유사한 접근 방식을 사용하므로 거기에 관련된 재작성이 덜할 수 있습니다. 그 주변에 연결되는 많은 생태계 항목은 그렇지 않을 수 있습니다.

Drew: 웹 플랫폼이 천천히 조심스럽게 움직이는 것이 맞다고 생각합니다. 5년 전만 해도 우리 모두 페이지에 JavaScript Carousels를 넣었다고 생각하실 것입니다. 그들은 어디에나 있었다. 모두가 JavaScript Carousels를 구현하고 있었습니다. 웹 플랫폼이 그 요구를 충족시키기 위해 뛰어올라 Carousel 솔루션을 구현했다면 사람들이 더 이상 Carousel에서 그렇게 하지 않기 때문에 아무도 사용하지 않을 것입니다. 그것은 단지 유행, 디자인 트렌드였기 때문입니다. 이에 대응하고 플랫폼 자체가 부풀어 오르고 해결해야 할 문제가 되는 것을 막으려면 훨씬 더 안정적인 속도로 움직여야 합니다. 그 결과 1999년에 작성한 HTML이 느린 프로세스 때문에 오늘날에도 여전히 작동합니다.

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it's related to the framework conversation. But it's the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you're getting all this benefit because you're not reloading the entire page framework. I feel like they don't always make good on those performance promises. 동의하시겠습니까?

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don't think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who's unfamiliar with those. When a single-page app, instead of having separate HTML files or if you're using something like a database driven site like WordPress, even though you don't have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That's what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don't have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that's slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they're not confused about where they are or what's going on. Because they can't see the change that's happening, they're hearing it announced. If you don't actually shift focus anywhere, that announcement doesn't happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don't necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website's being built, it doesn't always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you're going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it's not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it's being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. 전적으로. 전적으로. One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that's already there. So there's no reloading, they don't lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It's again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you'd have just a rectangle embedded in an HTML page which is your Flash Player, and you'd build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we're putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn't exist, I spell article like arcitle instead of article and the browser runs across that, it's going to be like, “Oh, I don't know what this is. Whatever, I'll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let's say I forget the B in bold, so I write old instead, font way old. The browser's going to be, “I don't know what this is. Whatever, we'll just keep going.” Your thing won't be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn't exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn't complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn't work at all.

Chris: There's an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don't disable it and most people are using devices that can actually handle modern JavaScript. That's true, but that's not the only reason why JavaScript doesn't work right, even if you have a linter there for example and you catch bugs ahead of time and things. There's plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we're recording this… a bad deploy took down Cloudflare. Interestingly as we're recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They're an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you'd like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn't part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone's in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it's probably even more now. That's a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There's just all sorts of reasons why JavaScript can fail and when it does, it's so catastrophic.

Chris: And so we built this web that should be faster than ever. It's 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. 그렇게 될 필요는 없습니다.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I've hammered on this a couple times. I'm not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn't mean obsolete. It doesn't mean never embrace new stuff, but don't be so quick to just jump on all the shiny new stuff just because it's there. I know it's one of the things that keeps this industry really exciting and makes it fun to work in, there's always something new to learn. But when you pick these new things, do it because it's the right tool for the job and not just because it's the shiny new thing.

Chris: 우리가 원하는 만큼 다루지 못한 다른 것 중 하나는 정말 중요하다고 생각합니다. 바로 플랫폼이 지난 몇 년 동안 정말 큰 발전을 이뤘다는 것입니다. 가능한 한 많이 수용하면 더 빠르고, 덜 취약하며, 브라우저에서 제공하는 것을 사용하는 것과 같은 종속성이 덜 필요하기 때문에 구축 및 유지 관리가 더 쉬운 웹 경험을 얻을 수 있습니다. -상자. 우리는 클래스와 같은 것을 선택하기 위해 jQuery가 필요했습니다. 이제 브라우저에는 이를 수행할 수 있는 기본 방법이 있습니다. JSX를 좋아하는 사람들은 JavaScript로 HTML을 보다 원활하게 작성할 수 있기 때문에 JSX를 좋아합니다. 그러나 추가 종속성 없이 동일한 수준의 용이성을 제공하는 Vanilla JavaScript의 템플릿 리터럴도 있습니다. HTML 자체는 이제 JavaScript가 필요했던 많은 것을 대체할 수 있습니다. 이는 절대적으로 놀라운 일입니다.

Chris: 우리는 CSS에 대해 조금 이야기했습니다. 하지만 링크 위로 마우스를 가져가면 JavaScript가 필요했습니다. 그러나 세부 정보 및 요약 요소와 같은 항목을 사용하면 스크립팅 없이 기본적으로 확장 및 축소 또는 아코디언 요소와 같은 공개를 만들 수 있습니다. 다음을 사용하여 자동 완성 입력을 수행할 수 있습니다. 나는 그 단어를 싫어합니다. 그러나 겸손한 입력 요소를 사용한 다음 몇 가지 옵션과 함께 관련되는 데이터 목록 요소를 사용합니다. 바닐라jstoolkit.com에서 이 항목이 어떻게 작동하는지 궁금하다면 플랫폼에서 제공하는 JavaScript 항목이 많이 있습니다. 그러나 나는 또한 JavaScript를 요구하는 데 사용되는 일부를 가지고 있으며 일부 코드 샘플이 이것과 함께 사용되기를 원하는 경우에도 흥미롭지 않을 수 있습니다.

Chris: CSS 측면에서 가장 인기 있는 Vanilla JS 플러그인은 앵커 링크까지 스크롤을 애니메이션으로 만들 수 있는 이 라이브러리입니다. 이건 정말 크다. 제가 작성해야 했던 코드 중 가장 어려운 부분입니다. 이제 CSS 한 줄로 완전히 대체되었으며 스크롤 동작이 부드럽습니다. 더 성능이 좋습니다. 쓰기가 더 쉽습니다. 동작을 수정하는 것이 더 쉽습니다. 더 나은 전반적인 솔루션입니다.

Chris: 우리가 더 했으면 하는 또 다른 일 중 하나는 다중 페이지 앱에 의존하는 것입니다. 최근에 Google에서 실제로 이 접근 방식을 추진하는 기사를 보았기 때문에 여기에서 약간 정당화되는 느낌이 듭니다. 이 거대한 각도와 프레임워크를 감안할 때 꽤 흥미롭다고 생각했습니다. Google이 몇 년 전에 시작한 모든 것, 굉장합니다. 그들이 이것으로 돌아 오는 것을 보는 것은 멋진 일입니다. 정적 사이트 생성기 및 Netlify 및 CDN 캐싱과 같은 멋진 서비스를 사용하여 다양한 보기에 대해 개별 HTML 파일을 사용하는 사람들을 위해 엄청나게 빠른 웹 경험을 만들 수 있습니다. 그래서 이런 특별한 것들에 의존하는 것입니다.

Chris: 그것이 현실적이지 않고 더 많은 JavaScript가 필요한 상황에서는 일종의 라이브러리가 필요합니다. 아마도 업계의 거대 기업을 찾는 대신 더 작고 모듈화된 접근 방식을 먼저 살펴보는 것이 좋습니다. React 대신 Preact가 작동할까요? Angular 대신... Vue 대신 Alpine JS가 작동할까요? 또한 현재 Svelt라고 하는 매우 흥미로운 사전 컴파일러가 있습니다. 이 사전 컴파일러는 프레임워크와 같은 경험을 제공한 다음 모든 코드를 Vanilla JavaScript로 컴파일합니다. 따라서 필요한 것만 있고 다른 것은 없는 아주 작은 번들을 얻을 수 있습니다. CSS와 JavaScript 대신 HTML을 CSS와 비교하고 우연히 남겨진 내용을 꺼내는 타사 CSS 린터를 삽입할 수 있습니까? Nicole Sullivan의 객체 지향 CSS와 같이 CSS를 작성하는 다른 방법이 대신 작동합니까? 우리는 그것에 대해 이야기하지 못했지만 사람들이 확인해야 할 정말 멋진 것입니다.

Chris: 그리고 세 번째이자 가장 중요한 부분이라고 생각합니다. 비록 구체적인 접근 방식이 아니라 더 많은 사람들이 염두에 두었으면 하는 점은 웹이 모든 사람을 위한 것이라는 점입니다. 오늘날 우리가 사용하는 많은 도구는 좋은 인터넷 연결과 강력한 장치를 가진 사람들을 위해 작동합니다. 그러나 구형 장치를 사용하고 인터넷 연결이 불규칙한 사람들에게는 작동하지 않습니다. 이것은 개발 도상국의 사람들만이 아닙니다. 이것은 또한 우리가 절대적으로 열악한 인터넷 연결을 가지고 있는 미국의 특정 지역에 있는 영국의 사람들입니다. 우리나라 중부 지역은 인터넷 속도가 매우 느립니다. 나는 그들이 역사적인 이유로 새로운 광대역을 연결할 수 없는 런던의 일부 지역이 있다는 것을 알고 있습니다. 그래서 당신은 정말로 나쁜 이 오래된 인터넷 연결이 남아 있습니다. 전 세계적으로 그런 곳이 있습니다. 지난번에 이탈리아에 갔을 때도 마찬가지였습니다. 그곳의 인터넷은 끔찍했습니다. 그 이후로 바뀌었는지 모르겠네요.

Chris: 오늘날 우리가 만드는 것이 항상 모든 사람에게 효과가 있는 것은 아닙니다. 그건 너무 안 좋은 일입니다. 왜냐하면 웹의 비전, 내가 그것에 대해 좋아하는 것은 그것이 절대적으로 모든 사람을 위한 플랫폼이라는 것이기 때문입니다.

Drew: 청취자가 이 접근 방식에 대해 더 알고 싶다면 The Lean Web이라는 책에서 이에 대해 자세히 설명했습니다. 온라인에서 사용할 수 있습니다. 실제 책입니까, 아니면 디지털 책입니까?

Chris: 둘 다 약간입니다. 음 ... 아니. 확실히 물리적인 책은 아니다. 당신은 leanweb.dev로 이동합니다. 온라인에서 전체 내용을 무료로 읽을 수 있습니다. 원한다면 아주 적은 금액으로 EPUB 및 PDF 버전을 사용할 수도 있습니다. 지금은 얼마인지 잊어버렸습니다. 나는 그것을 한동안 보지 않았다. 원하는 경우 모든 것이 온라인에서 무료입니다. 원한다면 이 주제에 대한 강연을 볼 수도 있습니다.

Chris: 하지만 저는 Smashing Podcast 청취자를 위한 특별 페이지도 gomakethings.com/smashingpodcast에 마련했습니다. 왜냐하면 저는 이름 짓는 일에 매우 창의적이기 때문입니다. 여기에는 책 외에도 오늘 우리가 이야기한 내용에 대한 많은 리소스가 포함됩니다. 그것은 우리가 다룬 많은 다양한 기술, 이러한 주제 중 일부에 대해 더 깊이 들어가 내 생각을 조금 확장한 내가 작성한 다른 기사와 연결됩니다. 사람들이 더 많은 것을 배우고 싶다면 그곳에서 시작하는 것이 가장 좋습니다.

드류: 굉장하네요. 감사합니다. 저는 린 웹에 대해 모두 배웠습니다. 최근에 무엇을 배웠습니까, 크리스?

크리스: 네, 몇 가지. 나는 프로그레시브 웹 앱에 대한 Jeremy의 비디오를 보면서 조금 더 일찍 이것을 암시했습니다. 나는 내가 작업하고 있는 어떤 것에도 특별한 필요가 없었기 때문에 몇 년 동안 내 자신의 프로그레시브 웹 앱을 실제로 작성하는 방법을 배우는 것을 미루고 있었습니다. 저는 최근에 남아프리카에 있는 제 학생 중 한 명으로부터 그들이 그곳에서 일어나고 있는 몇 가지 일 때문에 지속적인 정전을 겪고 있다는 것을 배웠습니다. 결과적으로 그녀는 전원이 꺼지고 학습 포털에 액세스하여 따라갈 수 없기 때문에 정기적으로 함께 하던 일부 프로젝트를 수행할 수 없습니다.

Chris: 저에게는 이제 누군가가 인터넷에 연결되어 있지 않아도 작동하는 경험을 구축하는 것이 더 높은 우선 순위가 되었습니다... 아마도 예전에 그랬을 수도 있다는 것을 깨달았고, 그래서 나는 그것을 파헤치기 시작했고 그것을 통합하기를 희망합니다. 다음 몇 주. 우리는 볼 것이다. 이에 대한 Jeremy Keith의 리소스는 절대적인 생명의 은인이었습니다. 그들이 존재해서 기쁩니다.

Chris: Drew, 당신이 이 질문을 하고 싶어하는 이유 중 하나는 사람들이 아무리 노련한 사람이라도 항상 배우고 있다는 것을 보여주기 위해서라고 말씀하셨습니다. 약간 관련된 일화입니다. 저는 제 생각에 웹 개발자로 일한 지 8년 정도 되었습니다. 문자 그대로 사용할 때마다 기울임꼴로 만들려면 여전히 CSS 속성을 Google에 검색해야 합니다. 웬일인지, 내 두뇌는 그것이 올바른 것이 아님에도 불구하고 기본적으로 텍스트 장식을 사용합니다. 나는 다른 것들의 몇 가지 조합을 시도할 것이고, 나는 항상 매번 한 단어가 틀립니다. 저도 가끔 이탤릭체 대신 이탤릭체로 씁니다. 응. 누군가가 "아, 난 절대 이런 걸 배우지 않을거야... 당신이 얼마나 노련한 사람이든 간에, 당신이 구글링을 반복해서 하는 정말 기본적인 것이 있다는 것을 알아두세요."라고 느끼는 적이 있다면.

Drew: 저는 22년, 23년 동안 웹 개발자로 일했고 Flexbox의 다른 속성을 매번 Google에서 검색해야 합니다. 23년 동안 사용했지만. 하지만 네, 어떤 것들은 단지... 제가 나이가 들면서 더 많은 것들이 있을 것입니다.

크리스: 네. 솔직히, 나는 구글링보다 더 쉽기 때문에 더 쉬운 복사-붙여넣기 참조를 갖기 위해 계속해서 구글링하는 것들로 전체 웹사이트를 구축하게 되었습니다.

드류: 나쁜 생각은 아닙니다.

Chris: 제가 게으른 편이에요. 나는 3초의 구글링처럼 나를 구하기 위해 전체 웹사이트를 만들 것이다.

Drew: 청취자가 Chris에 대해 더 알고 싶다면 웹에서 leanweb.dev에서 그의 책을, 그의 개발자 Tips 뉴스레터를 gomakethings.com에서 찾을 수 있습니다. Chris님은 Chris Ferdinandi의 Twitter에 있습니다. 그리고 바닐라jspodcast.com이나 팟캐스트를 자주 듣는 곳이면 어디에서나 그의 팟캐스트를 확인할 수 있습니다. 오늘 함께해주셔서 감사합니다, 크리스. 이별의 말이 있나요?

Chris: 아니요. 드류와 함께해주셔서 정말 감사합니다. 나는 완전히 스매싱 시간을 보냈습니다. 이것은 재미있는 일이었습니다. 채팅 기회를 주셔서 정말 감사합니다.