Jeremy Wagner와 함께하는 스매싱 팟캐스트 에피소드 45: 책임감 있는 자바스크립트란 무엇입니까?

이 에피소드는 전문가가 클라이언트 사이트를 구축하고 복잡한 프로젝트를 관리하며 온라인에서 비즈니스를 성장시킬 수 있는 플랫폼인 Wix의 친애하는 친구들의 친절한 지원을 받았습니다. 감사합니다!

이 에피소드에서는 책임감 있는 자바스크립트에 대해 이야기합니다. 코드에 책임이 있다는 것은 무엇을 의미하며 프로젝트에 어떻게 다르게 접근해야 합니까? 나는 전문가인 Jeremy Wagner와 이야기를 나누었습니다.

메모 표시

• 책임감 있는 자바스크립트 웹사이트
• A Book Apart에서 책 구입
• 제레미의 개인 웹사이트
• 트위터의 제레미

주간 업데이트

• 스티븐 후버가 쓴 터치 시대의 피츠 법칙
• Web Design Done Well: 완전히 무의미한 사람(Frederick O'Brien 작성)
• Nick Babich & Gleb Kuznetsov가 작성한 음성 사용자 인터페이스 생성에 대해 알고 싶은 모든 것
• Leonardo Losoviz가 작성한 블록 프로토콜에 WordPress 가입의 의미
• Knut Melvar가 쓴 Markdown에 대한 생각

성적 증명서

Drew McLellan: 그는 현재 Google에서 일하고 있는 테크니컬 라이터, 웹 성능 괴짜, 개발자 및 연사입니다. 그는 A List Apart, CSS-Tricks 및 Smashing Magazine에 기고했으며, A Book Apart를 위한 Responsible JavaScript라는 새로운 제목의 저자입니다. 그래서 우리는 그가 숙련된 기술자이자 커뮤니케이터라는 것을 압니다. 하지만 그가 스탠드업 패들 보드를 타고 세계 일주를 하고 싶어한다는 사실을 알고 계셨습니까? 내 스매싱 친구, Jeremy Wagner를 환영하십시오. 안녕 제레미, 잘 지내?

제레미 와그너: 굉장합니다. 잘 지내고 있나요?

드류: 저는 아주 좋습니다. 감사합니다. 저는 오늘 책임 있는 자바스크립트에 대한 이 아이디어에 대해 이야기하고 싶었습니다. 이것은 일종의 새로운 접근 방식이나 기술입니까, 아니면 책임감 있게 JavaScript를 사용하는 것에 대해 말 그대로 말하는 것입니까?

Jeremy: 말 그대로 책임감 있게 JavaScript를 사용하는 것에 대해 이야기하고 있습니다. 따라서 HTTP 아카이브에 따르면 모바일 장치에서 다운로드한 JavaScript 양이 작년에 약 290킬로바이트에서 거의 500킬로바이트로 약 58% 증가했습니다.

드류: 와.

Jeremy: 그래서 책임감 있게 JavaScript를 사용하는 것에 대해 이야기할 때 우리가 구축하고 있는 것이 무엇인지, 우리가 구축하고 있는 목표가 현대 웹 개발 관행에 따라 제공되는 목표를 비판적으로 평가하는 것은 사용자 우선 접근 방식입니다. 말하다. 그리고 제 생각에 그것은 일종의... 혀를 내두를 정도가 아닐 수도 있지만 저는 현대 웹 개발에 손을 대고 있지 않았습니다. 그러나 현대 웹 개발의 부산물 중 하나는 프로젝트에 종속성을 추가하는 것이 매우 쉽다는 것입니다. 모든 것이 MPM 설치이며 모든 MPM 설치에는 비용이 있습니다. 그 비용은 다양합니다. 그러나 우리가 보는 것은 그 HTTP 아카이브 데이터에서 95번째 백분위수... 가장 느리거나 가장 느리지는 않지만 가장 많은 JavaScript를 제공하는 경험의 5%를 의미합니다. 이는 작년에 약 875 증가했습니다. 킬로바이트에서 약 1.4메가바이트.

드류: 와.

Jeremy: 그래서 엄청난 양의 JavaScript가 전송되고 로딩 성능과 런타임 성능에 영향을 미칩니다.

Drew: 거기에서 성능에 대해 언급하셨습니다. 내 관점에서 볼 때 현대 웹 경험은 HTML과 CSS가 10%, JavaScript가 90%인 것 같습니다. 그리고 거기에는 일종의 성능 고려 사항이 있어야 합니다. 제 말은, 당신은 우리가 전송하는 데이터의 양에 대해 이야기했지만 많은 JavaScript를 가지고 있다는 다른 성능 고려 사항이 있습니다.

제레미: 맞아. 그래서 인터넷 연결 속도가 느리고... 제가 사는 곳이 미국인데, 주요 도시에서 충분히 벗어나면 어디로 가든지... 인터넷 속도가 얼마나 느릴 수 있는지 대처하기가 조금 어려워집니다. 이러한 농촌 지역의 일종이며 사람들이 이와 같은 지역에 사는 데 중요합니다. 따라서 메가바이트의 JavaScript를 출시하기 시작할 때 로딩 성능 측면은 이미 충분히 도전적이지만 iPhone X 또는 iPhone 13과 같이 iPhone이 없는 사람을 상대해야 할 수도 있습니다.

Jeremy: 그들은 그저 피처폰에 있을 수도 있고 그저 인생을 탐색하려고 애쓰는 저가형 안드로이드 폰일 수도 있습니다. 내 말은, 온라인 뱅킹, 실업 지원 또는 기타 정부 지원과 같은 지원 포털에 대해 생각해 보십시오. 온라인 학습, 광대역 인터넷이 잘 제공되지 않는 대도시 지역이나 느린 장치를 사용하는 사람들에게 운이 좋지 않은 사람들에게 과도한 JavaScript가 실제로 해로운 영향을 미칠 수 있는 곳이 많이 있습니다. . 제 생각에는 개발자로서 우리는 다음을 보는 경향이 있습니다. MacBook 또는 이러한 고급형 장치를 구입하고 JavaScript를 과도하게 사용하면 이러한 문제가 어디에서 발생할 수 있는지 실제로 알지 못하는 경우가 있습니다.

Drew: 그리고 당신이 거기에서 언급한 것처럼, 때때로 이런 종류의 일로 인해 불이익을 받는 서비스에 액세스할 수 없어 가장 손해를 보는 사람은 개인입니다. 빠른 데이터 연결이 없거나 매우 유능한 장치가 없는 사람들은 때때로 모든 것을 의미하는 서비스에 액세스합니다. 액세스할 수 있는 모든 것을 의미합니다. 그래서 어떤 면에서는 거의 인권 문제가 된다.

제레미: 네. 내 말은, 우리는 웹 성능이 비즈니스 가치 측면에서 틀에 박히는 것을 보는 경향이 있습니다. 나는 어떤 e-com의 성능 컨설턴트였고, 주요 식품 회사, 주요 e-com… 같은 상점, 전자 제품 아울렛과 같이 그렇게 하고 싶은 유혹을 많이 받죠, 그렇죠? 비즈니스를 위해 일할 때 분명히 재무 상태가 양호하고 웹 성능이 중요한 역할을 하기를 원하기 때문입니다. 나는 그것을 증명하는 많은 사례 연구가 있다고 생각합니다. 그러나 인간적인 측면이 있고 식료품점과 같은 비즈니스와 같은 비즈니스에도 있습니다. 네, 수익 중심입니다. 그들은 건전한 재정을 원하므로 웹 성능이 그 일부이지만 중요한 요구 사항도 충족하고 있습니다. 맞습니까? 꼭 먹어야 하는 것처럼요, 그렇죠?

Jeremy: 그리고 어떤 사람들처럼 이런저런 이유로 집에 가야 할 수도 있습니다. 그들은 차에 쉽게 탑승하지 못할 수도 있습니다. 그들은 차가 없을 수도 있습니다. 그래서 그들은 생계를 유지하기 위해 이러한 서비스에 의존하고 있습니다. 하지만 그 이상으로 필요한 경우 지원, 특히 위기 개입과 같은 유형의 지원이 필요합니다. 학대를 받고 집에서 쫓겨난 파트너가 스마트폰으로 눈을 돌리고 Google을 눌러 위기 개입 및 지원을 위한 포털을 찾으려고 한다는 말은 그다지 터무니없는 일이라고 생각하지 않습니다. 그리고 JavaScript는 이러한 유형의 목표를 방해하고 인간의 필요를 충족시킬 수 있습니다. 조금 지나치게 의지하는 경향이 있을 때.

Drew: 제 말은, 우리는 지난 18개월 동안 COVID와 사람들이 격리되고, 당신이 말했듯이 식료품 배달을 주문해야 하는 상황에서 일종의 어렴풋이 보았습니다. 그 시점에서 웹은 그들에게 생명줄이 됩니다. 그들은 날씨가 좋지 않다고 느끼고 있으며, 격리되고 음식과 필수 물품을 구해야 하기 때문에 숙소를 떠날 수 없습니다. 네, 제 생각에 그것은 우리 모두의 일상 생활에서 점점 더 중요한 부분이 되어가고 있다고 생각합니다.

제레미: 맞습니다. 그리고 일종의 장치 이야기로 돌아가서, Tim Kadlec은 2년 전에 놀라운 작품을 썼습니다. 제 생각에는 2년, 아마도 3년 전의 일이라고 생각합니다. 그러나 그것은 Long Tail of Performance의 우선 순위 지정이라고 불렸습니다. 그리고 그것을 보면… 그래서 웹 성능 용어에서 우리는 실험실 데이터와 현장 데이터에 대해 이야기합니다. 그리고 실험실 데이터는 등대를 실행하거나 웹페이지가 어떻게 작동하는지 확인하기 위해 웹페이지 테스트에서 웹사이트를 던질 때와 같습니다. 이것들은 모두 정말 유용한 도구이지만 해당 필드 데이터를 보면 실제로 청중이 누구인지 더 큰 그림과 더 큰 관점을 얻기 시작합니다. 그리고 이 기사에서 Tim Kadlec은 롱테일 성능의 우선 순위를 지정하는 것이 무엇을 의미하는지 설명합니다. 이 모든 장치는... 개발자인 우리가 가지고 있는 장치만큼 강력하지 않을 수 있습니다.

Jeremy: 그리고 그 기사의 이면에 있는 아이디어는 우리가 90번째 또는 95번째 백분위수에 집중할 수 있고 그 사람들을 위한 경험을 개선할 수 있다면 빠른 장치를 사용하는 사람들을 포함하여 모든 사람을 위해 더 빠른 웹을 구축하고 있다는 것입니다. 그리고 미국의 데이터 포인트를 공격하면 statcounter.com에서 가져온 것입니다. 28 포인트와 같은 것... 약 28%의 사람들이 이 도구가 캡처하는 iOS 기기를 사용합니다. 그리고 그 중 약 21%가 Android입니다. 그리고 Android는 모놀리식(monolithic)이 아니기 때문에 기기의 롱테일(long tail) 중 상당 부분을 차지하는 경향이 있습니다. 여러 기기 제조업체에서 Android 휴대폰을 만들지만 전 세계와 대조적으로 전 세계는 미국이 아니기 때문에 iOS를 사용하는 사람의 약 16%, Android를 사용하는 사람의 약 41%입니다. 따라서 더 느리거나 잠재적으로 더 느린 경험의 우선 순위를 정하는 것이 좋습니다.

Drew: 귀하의 책에서 장치 열 조절에 대한 내용을 읽었습니다. 거기에 어떤 우려가 있습니까?

Jeremy: 걱정거리가 있습니다. 저는 마이크로프로세서 전문가가 아닙니다. 저는 글을 너무 많이 쓰는 웹 개발자일 뿐입니다. 하지만... 열 조절의 이면에 있는 아이디어는 휴대폰과 태블릿뿐만 아니라 모든 시스템에 존재하며, 마이크로프로세서는... 과도한 작업 부하를 받거나 일반적으로 작업 부하일 뿐이며 그 작업의 낭비는 열입니다. 따라서 장치에는 이를 완화할 수 있는 방법이 있습니다. 랩톱에 수동 냉각 장치와 능동 냉각 장치가 모두 있는 것처럼.

Jeremy: 그래서 수동 냉각 장치는 방열판이나 일종의 방열판과 같습니다. 그리고 그 활성 부분은 열을보다 효율적으로 분산시키는 팬과 같습니다. 맞춤형 PC 빌드와 같은 일부는 상대적으로 극단적인 예인 수랭식 냉각과 같은 것을 사용할 수 있지만 휴대전화에는 그런 기능이 없습니다. 일, 그렇지?

Jeremy: 따라서 이러한 장치가 이러한 과중한 작업 부하에 대처하기 위해 장치가 클록 속도를 높일 수 있는 상태에 들어갈 때까지 클록 속도를 줄이는 것과 같이 프로세서 속도를 인위적으로 줄일 수 있습니다. 그리고 그것은 의미가 있습니다. 왜냐하면 당신이 수많은 JavaScript를 씹고 있다면, 이러한 큰 덩어리가 와이어를 따라 내려와 처리를 시작하기 때문입니다. 그렇죠? 따라서 컴파일 및 실행에서 평가 및 구문 분석을 통해 많은 처리가 필요합니다. 메가바이트 또는 두 개의 JavaScript로 이를 수행하고 다른 탭과 같은 백그라운드에서 진행 중인 많은 다른 프로세스가 있는 경우 상태를 표시할 수 있는... 가능성이 높아집니다. 장치가 열 조절 상태에 들어갈 수 있으며, 이는 추가 작업을 수행할 능력이 없음을 의미합니다.

Drew: 일종의 부정적인 피드백 루프입니다. 그렇지 않아? 당신은 장치에 많은 작업을 제공합니다. 매우 뜨거워지고 다시 스로틀링해야 하기 때문에 실제로 해당 작업을 실행할 수 있는 능력이 떨어집니다.

제레미: 맞아. 그리고 다시 말하지만, 저는 마이크로프로세서 전문가가 아닙니다. 만약, 만약, 만약에, 만약, 만약에, 만약에, 만약에, 이것에 정말로 친숙한 엔지니어가 아마도 몇몇 세부사항에 대해 저를 수정할 수 있다면, 그러나 일반적인 생각은 그렇습니다, 그 환경적 압력이 증가함에 따라, 장치는 덜 할 수 있다는 것입니다. 압력이 감소할 때까지 이러한 과중한 작업 부하에 대처하십시오.

Drew: 그래서 우리는 최신 Apple M1 Max에서 모든 종류의 장치에 대한 JavaScript를 작성하고 있습니다. Max가 새로운 프로세서입니다. 그렇지 않습니까? 랩톱은 웹 페이지를 렌더링하기에 충분한 종류의 작동 RAM이 거의 없는 장치에 이르기까지 다양합니다. 그러나 웹은 이렇게 시작되지 않았습니다. 더 어린 청취자들은 우리가 JavaScript 없이 대화형 웹 경험을 구축하는 데 사용했다는 사실에 관심을 가질 수 있습니다. 우리의 크고 무거운 프레임워크가 우리의 실행을 취소할 것입니다.

Jeremy: 프레임워크에는 시간과 장소가 있으며 이 책에서 발췌한 내용을 읽는 사람들은 내가 반프레임워크라는 생각을 가질 수 있습니다. 그리고 저는 여러 프레임워크에 대해 확실히 비판적이지만, 그것들은 목적에 부합하며 좋은 사용자 경험을 유지하거나 좋은 사용자 경험을 제공할 수 있는 방식으로 프레임워크를 사용하는 것이 가능합니다. 하지만 우리가 충분히 하지 않는다고 생각하는 것은 이러한 프레임워크가 런타임 성능에 미치는 영향 측면에서 일종의 비판적으로 평가하는 것입니다. 그렇죠? 그래서 제가 말하는 유형은 버튼을 클릭하면 장치가 해당 입력에 응답하는 데 1초 정도 걸릴 수 있습니다. 백그라운드에서 너무 많은 일이 진행되기 때문입니다. 분석 수집과 같은 타사 JavaScript 항목이 있고 스레드에서 실행되는 다른 항목도 있습니다.

Jeremy: 프레임워크의 런타임 성능을 비판적으로 평가하지 않으면 사용자에게 더 나은 서비스를 제공할 수 있는 몇 가지 기회를 테이블에 남겨 둘 수 있습니다. 좋은 예는 항상 반응 대 사전 행동을 사용하는 것입니다. 나는 한동안 이 드럼을 두드리고 있었다. 얼마 전에 모바일 탐색 메뉴와 같은 기본 클릭 상호 작용을 프로파일링한 CSS-Tricks에 대한 기사를 작성했습니다. 사소해 보이지만 모든 장치에서 반응이 더 나은 런타임 성능을 제공하지만 기본적으로 동일한 API를 가지고 있다는 사실을 알게 되었습니다. 차이점이 있습니다. 약간의 차이점이 있고 사전 실행 호환성으로 문서화할 수 있는 항목이 있지만 간단합니다... 그리고 간단한 선택이라고 말하면 안 됩니다. 하지만 그 선택, 그 근본적인 선택은 경험의 차이일 수 있습니다 그것은 모든 사용자 또는 적어도 대부분의 사용자에게 정말 잘 작동하거나 일부 사용자에게만 잘 작동하는 경험입니다. 그것이 의미가 있기를 바랍니다.]

Drew: 내 말은, 모든 프레임워크와 빌드 도구를 사용하여 트리 쉐이킹과 같은 작업을 수행하고 번들을 제공하고 브라우저에 전달하는 방법을 최적화하는 데 항상 더 나은 것 같습니다. 큰 프레임워크를 사용할 때 프레임워크가 모든 추상화로 인해 더 적은 코드를 제공할 수 있도록 하는 큰 응용 프로그램을 작성하고 있다고 생각하는 전환점이 있습니까?

Jeremy: 대답하기 어려운 질문입니다. 그 중 한 측면은 프레임워크 자체가 최적화할 수 없는 코드의 양을 나타낸다는 것입니다. 그래서 pre-act 또는 like... 또는 spell과 같은 얇은 프레임워크를 갖는 것이 많은 도움이 됩니다. 그러나 내가 본 문제는 HTTP 아카이브의 데이터가 이 지점을 지원한다고 생각합니다. 마이크로프로세서와 네트워크의 이러한 발전이 더 빨라질 때마다 우리는 그 이득을 소비하는 경향이 있는 것 같습니다. 그렇죠?

Jeremy: 우리는 우리가 실제로 발전하지 못하는 이 런닝머신 위에 있는 경향이 있습니다. 그리고 저는 프레임워크의 역사가 무엇인지에 대해 천리안이 없는 것처럼... 또는 죄송합니다. 프레임워크의 미래가 어떻게 생겼는지 모릅니다. 나는 수집할 수 있는 약간의 효율성 이득이 있다고 확신합니다. 그러나 원시 JavaScript가 얼마나 많은 면에서 현장에서 볼 수 있는 것은... JavaScript의 원시 양만 사용되는 것입니다. 이것이 우리가 일종의 자동화 방식으로 해결할 수 있는 문제라고 말하지 않습니다. 나는 우리가 해야 한다고 생각합니다. 우리는 인간이어야 하고 사용자에게 가장 좋은 영향을 미치는 결정을 내리고 개입해야 합니다. 그렇지 않으면 우리가 이 러닝머신에서 내리는 모습을 볼 수 없을 것입니다. 제 경력이 아닐 수도 있지만 잘 모르겠습니다.

Drew: 이 책에서 웹사이트와 웹 앱에 대해 이야기하고 차이점을 이해하고 함께 작업하는 것이 개발 및 최적화 방법에 대한 전략을 선택하는 데 어떻게 도움이 되는지 설명합니다. 그것에 대해 조금 알려주세요.

Jeremy: 정말 좋은 질문입니다. 그리고 이 책의 서곡인 Responsible JavaScript Part One이라는 이름으로 A List Apart에 썼던 동명 기사에서 이에 대해 씁니다. 우리가 이 용어에 많은 내용을 담고 있다는 것입니다. 테크니컬 라이터로서, 나는 두 가지가 상호 교환적으로 사용되는 것을 봅니다. 내가 본 것은 웹사이트에 관한 것인데, 이는 일종의 다중 연령 경험이라는 의미입니다. 그렇죠? 문서 모음입니다. 이제 문서... 이러한 문서에는 이러한 작은 섬과 같은 기능이 포함되어 있을 수 있습니다. 최근에 사람들이 작업을 완료할 수 있도록 하는 기능의 작은 섬이라는 용어가 사용되었습니다.

Jeremy: 하지만 웹 앱과 웹 앱에는 기능과 같은 기본 앱의 의미가 있습니다. 따라서 우리는 단일 페이지 응용 프로그램에 대해 이야기하고 있으며 복잡한 상호 작용을 유도하는 많은 양의 JavaScript에 대해 이야기하고 있습니다. 그리고 웹 앱 모델이 이해가 되는 경우가 있습니다. 예를 들어 Spotify가 이에 대한 좋은 예입니다. 웹 앱으로 더 잘 작동합니다. 그것을 사용하거나 다중 페이지 응용 프로그램으로 설계하고 싶지는 않을 것입니다. 전통적인 웹 사이트와 비슷하지만 모든 프로젝트에 대한 기본값이 "클라이언트 측 라우터 및 무거운 프레임워크와 같은 단일 페이지 애플리케이션을 제공하고 서버에서 클라이언트로 렌더링하는 이 처리." 나는 그것이 의도하지 않았지만 사용자를 제외하지만 그럼에도 불구하고 제외하는 지점에 도달하기 시작하는 지점이라고 생각합니다.

Drew: 우리가 웹사이트를 게시하고 웹사이트에 상호작용 기능이 있을 수 있다는 접근 방식을 취하는 사람들과 "우리는 소프트웨어 회사, 우리는 제품, 소프트웨어 제품 및 우리가 이를 통해 전달할 플랫폼을 만드는 것은 여러 플랫폼을 위한 기본 애플리케이션이 아니라 웹입니다.” 그들은 완전히 다른 방식으로 문제에 접근하고 있습니까? 그 시점에서 전망에 따라 고려 사항이 다른가요?

Jeremy: 어려운 질문입니다. 그래서-

드류: 말하기 어려웠습니다.

Jeremy: 회사는... 좋은 예가 뉴스와 같을 것입니다. 그렇죠? 그들은 말 그대로 문서, 기사의 모음이기 때문에 일종의 웹 사이트 모델에 의해 잘 제공됩니다. 그리고 그러한 경험을 개발하는 사람들은 아마도 Spotify와 같은 회사나 Envision과 같은 대형 웹 응용 프로그램이나 그런 유형을 가진 회사와는 다른 기술을 가지고 있을 것입니다. 그리고 네, 제 생각에 그들은 다른 각도에서 이 문제에 접근할 것입니다. 제가 본 방식은 세그먼트가 있다는 것입니다... 또는 적어도 이것이 제가 웹 개발 커뮤니티를 전반적으로 인식한 방식은 비전통적인 소프트웨어 개발에서 온 웹 개발자의 세그먼트가 있다는 것입니다. 배경 맞죠? 저도 그런 사람 중 한 명입니다. 어렸을 때 웹을 만지작거리고 있었죠. 맞죠?

Jeremy: 중학교 때와 같이 내가 정말 좋아했던 비디오 게임처럼 모두를 위해 어리석은 팬 페이지를 만들었습니다. 그리고 저는 그런 종류의 컴퓨터 과학 교육을 받은 적이 없습니다. 그 과정에서 제가 배운 컴퓨터 과학 개념이 있습니다. 그런 다음 개발자의 일부가 있습니다. 특히 지난 5~10년 동안 더 컴퓨터 과학 지향적인 방식으로 접근하는 개발자가 있다고 생각합니다. 그리고 저는 그것이… 이러한 차이점과 경험으로 인해 각 그룹이 웹용으로 개발하는 최선의 방법에 대한 결론을 도출하게 될 것이라고 생각합니다. 하지만 웹을 위해 지속적으로 개발할 수 있는 유일한 방법은 웹을 위해 무엇을 만들고 있는지 비판적으로 평가하고 해당 제품의 사용자에게 가장 적합한 접근 방식을 조정하는 것뿐입니다. 그리고 그것이 내가 이러한 것들을 평가할 때 웹사이트와 웹 앱 모델이 제 머리 속에 자리잡는 곳입니다.

드류: 네. 흥미롭네요. 내 말은, 책에서 당신은 실제로 내 작업의 일부를 인용합니다. 매우 감사합니다. 그리고 내가 선택한 기본적으로 PHP Apache에서 지루한 기술을 선택하고 손으로 굴린 JavaScript를 약간만 사용하면 특정 최적화를 수행할 필요 없이 기본적으로 매우 빠른 사용자 경험을 만들 수 있습니다. 나는 그것이 사이트에 와서 콘텐츠를 보는 프런트 엔드 방문자에게 훌륭한 사용자 경험을 제공한다고 생각합니다.

Drew: 하지만 사실, 저는 일단 로그인하고 사이트에 물건을 게시하면 콘텐츠를 저작할 수 있는 환경과 비슷하다고 느낍니다. 자바스크립트를 많이 사용하는 웹 앱 접근 방식보다는 웹사이트 접근 방식으로 구축하는 데 약간의 어려움을 겪는다고 생각합니다. 그래서 제 생각에는… 멋진 정적 HTML과 CSS와 자바스크립트의 작은 비트로 프런트 엔드를 계속 게시해야 합니다. 그러나 콘텐츠 저작 경험을 제공하려는 백엔드는 다른 기술을 선택하는 것이 더 나을 수 있습니다. 항상 한 가지일 필요는 없기 때문에 매우 흥미롭습니다. 바이너리 선택이 아닙니다. 스펙트럼에 가깝다고 할까요?

제레미: 물론이죠. 그리고 웹 개발이 이와 같은 스펙트럼이라는 것에 대해 커뮤니티에서 더 많은 토론을 보기 시작했다고 생각합니다. 내 책에 관심이 있을 수 있는 사람들을 위해 정확히 말하면 스펙트럼의 웹 사이트 측면에서 나온 것입니다. 그리고 다시, 나는 그것이 항상 좋은 기본값과 같다고 느끼기 때문입니다. 어떻게 빌드하고 싶은지 모르겠다면 JavaScript 사용을 최소화하고 클라이언트에 더 많은 작업을 푸시하는 것을 최소화하는 방식으로 빌드하는 것이 가장 좋습니다. 즉, 알아차린 것은 훌륭한 경험이라고 생각합니다. 나는 이러한 잘 낡고 일종의 정말로 "지루한" 기술이 당면한 작업에 정말 잘 작동한다고 생각합니다. 그리고 그것은 일종의 개방적이고 개발자를 위한 활성화와 같은 방식으로 그렇게 합니다. 맞습니까?

Jeremy: 이러한 종류의 작업을 실제로 수행하기 위해 상태 관리 저장소 또는 상태 관리 프레임워크에 대해 깊은 지식이 필요하지 않습니다. 그리고 나는 그 특별한 접근 방식이 주목을 받았다고 생각합니다. 그러나 귀하의 요점에 따르면 모든 웹사이트에는 클라이언트의 모든 것을 관리하는 프레임워크와 같은 모든 클라이언트 측 라우팅과 그런 유형의 모든 것을 처리하지 않고 스펙트럼의 중간으로 더 가까이 이동할 수 있는 기회가 있다고 생각합니다. 나는 섬의 접근 방식이 그것이 어떻게 생겼는지 탐구하기 시작했다고 생각합니다. 그리고 나는 아마도 의도하지 않게 일부 섬 유형의 일을 했다는 것을 인정할 것입니다. 나는 우리가 꽤 오랫동안 그것에 이름을 붙이지 않았다고 생각합니다. 하지만 이제 중간 지점처럼 좋은 사용자 경험을 제공하지만 여전히 더 인터랙티브한 웹 경험을 보기 시작할 수 있다고 생각합니다. 바라건대 그것은 심하게 구불 구불하지 않았습니다.

Drew: 그것은 우리가 Flash의 섬을 삽입하거나-

제레미: 네.

Drew: 페이지에서 이것이 우리의 작은 대화형 섹션이고 나머지는 일종의 흐름입니다.

Jeremy: 예, Flash처럼, 맙소사, 대학 졸업 후의 제 개인 포트폴리오 세 번은 고급 Flash 모조품과 호버 효과에 정말 형편없었습니다. 그리고 그 내용은 정말, 정말 재미있었습니다. 그리고 우리가 더 이상 Flash를 사용하지 않기 때문에 사라질 것 같은 풍부한 콘텐츠가 있는 것처럼 가끔 그리워집니다. 그리고 그것은 정말 안타까운 일이지만 어떤 면에서 그것은 우리가 이야기하고 있는 이런 종류의 섬에 대한 일종의 선구자였습니다. 정적인 웹 페이지와 모든 것을 가질 수 있지만 그 중간에 딱 떨어지는 것처럼 정말 풍부하게 상호 작용하는 경험을 하게 될 것입니다.

Drew: 오랫동안 점진적 개선은 웹 경험을 구축하는 모범 사례로 간주되어 왔습니다. 아직도 그럴까요?

Jeremy: 저는 그것이 아마도... 아마도… 아니 아마도 점진적인 향상을 하는 것이 더 많은 작업이라는 것을 인정할 것입니다. 왜냐하면 어떤 면에서 당신은 개발 경험을 일종의 분기점으로 만들고 있기 때문입니다. 서버가 이러한 주요 상호 작용과 같은 종류를 처리할 수 있는 방식으로 웹 사이트의 실행 가능한 최소 기능을 제공하려고 합니다. 하지만 그 위에 "자, 이제 JavaScript를 사용하여 이 상호 작용을 좀 더 원활하게 하고 싶습니다."라고 말합니다. 나는 여전히 그것이 웹사이트나 앱, 제품으로 목표를 달성할 수 있는 실행 가능한 방법이라고 생각합니다.

Jeremy: 하지만 내가 말하고 싶은 것은 웹사이트의 모든 단일 상호작용이 이러한 동기식 탐색 패턴에 의해 촉진되어야 한다는 것을 결코 권장하지 않는다는 것입니다. 따라서 좋은 예와 같이 이코노믹 웹사이트의 체크아웃 페이지에는 확실히 서버 경로가 있어야 합니다. 장바구니에 물건을 추가할 수 있는 서버 경로가 있어야 하며, JavaScript를 좀 더 즐겁게 만들어 좀 더 빠르고 비동기적으로 처리할 수 있을 만큼만 JavaScript를 뿌릴 수 있어야 합니다.

Drew: 성과를 측정할 때. 우리는 주로 Google에서 핵심 Web Vital에 대해 많이 듣습니다. 그것들이 정말로 우리가 측정해야 할 벤치마크인가? 아니면 Google이 우리가 생각하기를 바라는 것입니까? 이제 귀하가 Google에서 일하기 시작한 어려운 질문에 감사드립니다.

제레미: 네, 네. 알다시피, 나는 여기에서 나 자신을 위해 말하는 것입니다. 나는 웹 바이탈이… 초기 핵심 웹 바이탈이 사용자 경험의 어떤 부분이 중요한지를 정의하는 좋은 시도라고 생각합니다. 누적 레이아웃 이동 및 가장 큰 Contentful 페인트와 같은 메트릭은 우리가 실제로 수량화하기 시작하지 않은 방식으로 경험에 대해 생각하기 시작한다고 생각합니다. 특히 누적 레이아웃 전환 이전에, 화를 내는 순간이 있었다면 버튼이 페이지나 다른 곳에서 움직이는 것을 좋아하기 때문입니다. 측정하는데 도움이 되는 부분이라고 생각합니다. 그것은 불완전하다. 그리고 핵심 웹 바이탈에 대해 작업하는 사람이라면 누구나 이러한 지표 중 일부에서 개선이 필요하다는 데 동의할 것이라고 생각합니다. 내가 완전히 동의하지 않는 다른 지표가 있습니다. 첫 번째 입력 지연과 마찬가지로 핀을 배치하기가 어려운 메트릭입니다.

Jeremy: 정말 유용한 것 같아요, 그렇죠? 말 그대로 사용자가 만드는 첫 번째 상호 작용에 대한 지연과 상호 작용을 측정하고 싶지만 컨텍스트가 약간 부족하기 때문입니다. 일부… 많은 것들이 영향을 미칠 수 있기 때문입니다. 항상 JavaScript에 연결되는 것은 아니기 때문입니다. 첫 번째 입력 지연은 양식 필드를 포커싱하여 발생하는 지연을 나타낼 수 있습니다. 맞습니까? 그런 유형의 것, HTML의 것. 제 생각에는 이러한 메트릭... 첫 번째 입력 지연과 같은 메트릭은... 긴 작업 API의 항목, 요소 타이밍 및 이러한 유형의 항목과 같은 항목으로 컨텍스트화할 수 있는 경우 유용할 수 있습니다. 나는 궁극적으로 핵심 웹 바이탈의 미래가 무엇이 좋은 사용자 경험을 만드는지 측정하는 데 도움이 되고 도구가 될 것임을 증명할 것이라고 생각합니다. 그건 제 개인적인 생각입니다.

Drew: 제 생각에 그것은 항상 자신에 대해 측정할 수 있는 것 중 하나입니다. 자신의 개선 사항을 측정하거나 점수가 변경되면 경험이 악화되는지 여부, 신호등에 대해 그다지 신경 쓰지 않고 자신이 알고 있는 것에 대해 관심을 가질 수 있습니다. 사이트의 컨텍스트 및 변경으로 인해 개선된 방법에 대해 설명합니다.

Jeremy: 누적 레이아웃 전환과 같은 메트릭이 훌륭하다고 생각하지만 약간의 개선을 통해 이점도 얻을 수 있습니다. 그대로 누적 레이아웃 이동은 대부분 로드 중에 발생하는 레이아웃 이동을 측정합니다. 그리고 우리가 알고 있듯이 사용자가 페이지를 방문하고 페이지를 방문하면 언제든지 레이아웃 전환이 발생할 수 있습니다. 그렇죠? 그래서 확실히 우리가 그런 종류의 현상을 관찰하는 방법을 개선하기 위해 할 수 있다고 생각하는 작업이 있습니다.

Drew: 레이아웃 안정성은 점진적 향상으로 작업할 때 실제로 달성하기가 조금 더 어려운 것 중 하나라고 생각합니다. 때때로 서버에서 렌더링된 페이지를 로드한 다음 클라이언트에서 개선하기 시작할 때 이러한 종류의 레이아웃 전환을 생성할 위험이 있을 수 있습니다. 그렇지 않습니까?

제레미: 물론이죠. 여러 가지 이유로 구성 요소의 치수가 변경될 수 있기 때문에 구성 요소의 수화 작업이 까다로워지는 부분입니다. 클라이언트에서 실행될 때까지 평가되지 않는 상태로 인해 서버에서 렌더링되지 않는 콘텐츠가 클라이언트 측 구성 요소에 있을 수 있는 것과 같습니다. 굉장히 어려운 문제입니다. 나는 여기에 앉아서 내가 그것에 대한 은총알 같은 것을 가지고 있는 척하지 않을 것입니다.

Drew: 저는 경험을 시작할 때 엄청난 양의 JavaScript 번들을 미리 다운로드하고 실행하는 문제에 대한 서로 다른 기술인 가져오기 및 코드 분할의 동적 유형에 대해 조금 이야기하고 싶었습니다. 특히 가장 단순한 소규모 프로젝트에서 많은 작은 요청을 하여 과도하게 최적화할 위험이 있습니까? 아니면 처음부터 이러한 문제가 발생할 것이라고 선점하는 일종의 구현에 전혀 해가 되지 않는 것입니까? 아니면 성능 문제가 실제로 나타날 때까지 기다렸다가 그런 종류의 문제를 생각해야 합니까?

Jeremy: 그래서 나는 당신이 방금 말한 것의 뒷부분이 이것을 이끌어내는 좋은 방법이라고 추천하고 싶습니다. 물론 이러한 최적화를 매우 빠르고 쉽게 달성할 수 있는 경우가 아니면 조기 최적화를 시도해서는 안 됩니다. 그러나 초기에 최적화하는 데 많은 노력이 필요하고 실제로 성능 문제가 많지 않은 경우에는 다음과 같이 주장합니다. 코드 분할은 아마도 일어날 필요가 없는 일입니다. 해당 기능을 미리 로드할 수 있습니다.

Jeremy: 하지만 예를 들어, 나는 책에서 이것에 대해 이야기합니다. 큰 JavaScript 조각에 의해 구동되는 높은 가치의 상호 작용이 있고 나에게 큰 JavaScript 조각은 20KB를 의미할 수 있습니다. 유선을 통해 압축되어 60KB JavaScript 청크가 될 수 있기 때문입니다. 그런 다음 기본 번들 또는 무수히 많은 번들에서 이를 꺼낼 수 있다면 사이트가 배송될 수 있고 시작 성능에 도움이 될 것입니다.

Jeremy: 하지만 이 책에서 나는 언제... 또는 적어도 사용자가 높은 가치의 상호작용을 할 수 있는지를 인지하려고 시도하는 것에 대한 기술에 대해 논의합니다. 그래서 제가 사용하는 예제는 JavaScript 덩어리입니다. HTML 양식 유효성 검사는 훌륭하지만 스타일 지정이 불가능하고 매우 간단하기 때문에 양식의 내용을 유효성 검증하는 데 사용됩니다. 유형은 이메일과 같습니다. 그것은 그것을 특정 방식으로 평가합니다. 그러나 클라이언트에서 양식을 확인하는 것은 스타일을 지정할 수도 있기 때문에 정말 유용합니다. 그리고 우리는 브랜드 미학이 무엇인지 또는 웹사이트의 미학이 무엇인지에 더 가깝게 검증의 모양을 정렬할 수 있습니다. 그래서 이 예에서 내가 한 것은 사용자가 초점을 맞추면... 양식의 필드 중 하나에 초점을 맞추더라도 바로 그 지점에서 JavaScript의 일부를 미리 로드하는 것입니다.

Jeremy: 그때쯤이면 네트워크에서 양식을 작성하는 데 시간이 조금 걸리므로 동적 가져오기가 호출될 때 현금을 받을 수 있도록 네트워크에서 이를 풀 시간이 충분하기 때문입니다. 이미 사전 로드된 것을 가져옵니다. 여기저기서 조금씩 해오던 일인데, 모든 상황에서 하기 힘든 일이에요. 예를 들어, 일부 장치에는 미세한 포인터가 없기 때문에 마우스를 가져갈 때 항상 안정적으로 이 작업을 수행할 수 없습니다. 그들은 ... 그들은 ... 탭 입력, 맞습니까? 따라서 호버는 예를 들어 미세한 포인터가 있는 경우와 다른 시간에 발생합니다.

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

Jeremy: 출시 이후 계속해서 하고 있는 일은 CSS 페인트 API를 엉망으로 만드는 것입니다. 저는 페인트 API를 정말 좋아합니다. 내 말은, 그것은 항상 그 자체로 존재했던 종류의 것입니다.... 캔버스처럼 2D 컨텍스트가 하나의 일이었기 때문입니다. 왜냐하면 그건... 모르는 사람들을 위해 CSS 고통 API는 2D 캔버스 컨텍스트를 포함하고 매개변수화하고 CSS로 제어할 수 있는 방법입니다. 이전에는 그런 종류의 애니메이션을 만들 수 없었습니다.

Jeremy: 그리고 최근에 블로그 새로 고침을 하고 있습니다. 즉… 나는 거대한 Final Fantasy 괴짜입니다. 방금 다시 플레이한 Final Fantasy II와 같이 15개 정도 있고 16개는 언젠가 나올 예정이지만 일종의 복고풍 분야입니다. 그래서 저는 CSS 페인트 API를 사용하여 다른 타일을 사용하는 무작위 세계를 생성했습니다. 그래서 강과 같은 것들이 흐르고 잔디 타일과 나무와 같은 것들이 있습니다. 그리고 사용자가 어두운 모드에서 내 웹사이트를 방문하는 것처럼 매개변수화하면 페인트 작업이 마치 밤인 것처럼 렌더링됩니다. 그 위에 일종의 오버레이와 그런 유형이 있을 것입니다.

Jeremy: 하지만 페인팅 API는 훌륭합니다. Tim Holman에게 큰 소리로 외쳐야 합니다. 그, 나는 JSConf Australia에서 그를 보았고 그는 제너레이티브 아트웍에 대해 이야기했습니다. 정말 그냥, 정말 관심이 가는 것 같았습니다. 그런 다음 Sam Richard는 전날 CSSConf에서 CSS 페인팅 API에 대해 이야기하면서 이 두 가지가 함께 나왔을 때 "와, 정말 멋지네요."라고 말했습니다. 그래서 실제로 Paintlets라는 작업을 수행했습니다! 그것은 Paintlets.Herokuapp.com이고 Chrome을 방문하고 불행히도 아직 잘 지원되지 않기 때문에 해야 합니다. 무작위로 생성된 여러 다른 무작위 삽화를 볼 수 있습니다. 그리고.. 예, 저는 단지... 제가 겪었던 일입니다. 죄송합니다. 그것에 대한 긴 이야기.

드류: 놀랍군. 그거 좋을 거 같아.

제레미: 네. 응.

Drew: 청취자 여러분, Jeremy의 소식을 더 듣고 싶으시다면 Twitter에서 @malchata를 찾아보고 그의 개인 웹사이트 jeremy.codes에서 프리젠테이션, 비디오 및 프로젝트를 작성할 수 있습니다. Responsible JavaScript는 지금 A에서 구할 수 있습니다. 따로 예약하세요. 이에 대한 자세한 정보는 relatedjs.dev에서 찾을 수 있습니다. 오늘 함께 해주셔서 감사합니다 제레미, 이별의 말은 없었나요?

Jeremy: 가능한 한 최선의 방법으로 웹용으로 빌드하고 사용자를 염두에 두십시오. 그것이 제 만트라의 일종이며 이 책이 그런 생각을 조금이나마 지켜주길 바랍니다.