Smashing Podcast ตอนที่ 45 กับ Jeremy Wagner: JavaScript ที่รับผิดชอบคืออะไร?

ตอนนี้ได้รับการสนับสนุนอย่างดีจากเพื่อนรักของเราที่ Wix ซึ่งเป็นแพลตฟอร์มสำหรับมืออาชีพในการสร้างไซต์ลูกค้า จัดการโครงการที่ซับซ้อน และขยายธุรกิจทางออนไลน์ ขอขอบคุณ!

ในตอนนี้ เรากำลังพูดถึง JavaScript ที่มีความรับผิดชอบ ความรับผิดชอบของโค้ดหมายความว่าอย่างไร และเราควรเข้าหาโครงการอย่างไรให้แตกต่างออกไป ฉันได้พูดคุยกับผู้เชี่ยวชาญ Jeremy Wagner เพื่อหาคำตอบ

แสดงหมายเหตุ

• เว็บไซต์ JavaScript ที่รับผิดชอบ
• ซื้อหนังสือจาก A Book Apart
• เว็บไซต์ส่วนตัวของ Jeremy
• Jeremy บน Twitter

อัพเดทประจำสัปดาห์

• กฎของฟิตส์ในยุคสัมผัส เขียนโดย Steven Hoober
• การออกแบบเว็บทำได้ดีมาก: ไร้จุดหมายอย่างสมบูรณ์แบบ เขียนโดย Frederick O'Brien
• ทุกสิ่งที่คุณอยากรู้เกี่ยวกับการสร้างส่วนต่อประสานผู้ใช้ด้วยเสียงที่เขียนโดย Nick Babich & Gleb Kuznetsov
• ผลกระทบของ WordPress เข้าร่วม Block Protocol เขียนโดย Leonardo Losoviz
• ความคิดเกี่ยวกับ Markdown เขียนโดย Knut Melvar

การถอดเสียง

Drew McLellan: เขาเป็นนักเขียนด้านเทคนิค ผู้คลั่งไคล้ประสิทธิภาพเว็บ นักพัฒนาและวิทยากร ปัจจุบันทำงานที่ Google เขาเขียนบทให้กับ A List Apart, CSS-Tricks และ Smashing Magazine และเป็นผู้แต่งชื่อใหม่, Responsible JavaScript for A Book Apart เรารู้ว่าเขาเป็นช่างเทคนิคและผู้สื่อสารที่มีทักษะ แต่คุณรู้หรือไม่ว่าเขาต้องการท่องโลกรอบโลกด้วยกระดานโต้คลื่นแบบยืน เพื่อนที่ยอดเยี่ยมของฉัน ยินดีต้อนรับ Jeremy Wagner สวัสดี เจเรมี สบายดีไหม

Jeremy Wagner: ฉันยอดเยี่ยมมาก คุณเป็นอย่างไรบ้าง?

ดริว : ฉันสบายดี ขอขอบคุณ. วันนี้ฉันอยากคุยกับคุณเกี่ยวกับแนวคิด Responsible JavaScript นี่เป็นแนวทางหรือเทคนิคใหม่ๆ หรือคุณกำลังพูดถึงการใช้ JavaScript อย่างมีความรับผิดชอบอย่างแท้จริง

Jeremy: ฉันกำลังพูดถึงการใช้ JavaScript อย่างมีความรับผิดชอบอย่างแท้จริง จากการเก็บถาวร HTTP เราพบว่าจำนวน JavaScript ที่ดาวน์โหลดโดยอุปกรณ์มือถือเพิ่มขึ้นเกือบ 58% จากประมาณ 290 กิโลไบต์เป็นเกือบ 500 กิโลไบต์ในปีที่แล้ว

ดริว : ว้าว

Jeremy: ดังนั้น เมื่อฉันพูดเกี่ยวกับการใช้ JavaScript อย่างมีความรับผิดชอบ มันเป็นวิธีแรกที่ผู้ใช้จะพูด... เพื่อประเมินอย่างมีวิจารณญาณว่าเรากำลังสร้างอะไร และเป็นเป้าหมายของสิ่งที่เรากำลังสร้าง ซึ่งให้บริการโดยแนวทางปฏิบัติในการพัฒนาเว็บไซต์สมัยใหม่ ดังนั้น พูด. และฉันเดาว่าเป็นแบบนั้น... อาจจะไม่คุ้นหูนัก แต่ฉันไม่ได้เชี่ยวชาญด้านการพัฒนาเว็บสมัยใหม่ แต่ผลพลอยได้อย่างหนึ่งของการพัฒนาเว็บสมัยใหม่ก็คือ การเพิ่มการพึ่งพาอาศัยกันในโครงการทำได้ง่ายมาก ทุกอย่างเป็นการติดตั้ง MPM และการติดตั้ง MPM ทุกครั้งมีค่าใช้จ่าย ซึ่งค่าใช้จ่ายแตกต่างกันไป แต่สิ่งที่เราเห็นคือในข้อมูลที่เก็บถาวรของ HTTP เปอร์เซ็นไทล์ที่ 95… หมายถึง 5% ของประสบการณ์ที่ช้าที่สุด… หรือไม่ใช่ช้าที่สุด แต่ส่ง JavaScript มากที่สุด ซึ่งเพิ่มขึ้นในปีที่แล้วประมาณ 875 กิโลไบต์ถึงประมาณ 1.4 เมกะไบต์

ดริว : ว้าว

Jeremy: ดังนั้น JavaScript จำนวนมากจึงถูกถ่ายโอน และมีทั้งประสิทธิภาพการโหลดและประสิทธิภาพของรันไทม์

Drew: คุณพูดถึงการแสดงที่นั่น ดูเหมือนว่าประสบการณ์การใช้เว็บสมัยใหม่จากมุมมองของฉันจะเหมือนกับ HTML 10% และ CSS และ JavaScript 90% และต้องมีการพิจารณาประสิทธิภาพในเรื่องนั้นด้วย ฉันหมายถึง คุณพูดถึงปริมาณข้อมูลที่เรากำลังถ่ายโอนออกไป แต่ก็มีข้อควรพิจารณาด้านประสิทธิภาพอื่นๆ เกี่ยวกับการมี JavaScript จำนวนมาก

เจเรมี: ถูกต้อง ดังนั้น การมีการเชื่อมต่ออินเทอร์เน็ตที่ช้า และคุณรู้… ที่ที่ฉันอาศัยอยู่ในสหรัฐอเมริกา ถ้าคุณออกไปนอกเมืองใหญ่ๆ ไกลพอ มันจะค่อนข้างยากขึ้นอยู่กับว่าจะไปที่ใด… เพื่อรับมือกับความช้าของอินเทอร์เน็ต ประเภทของพื้นที่ชนบทเหล่านี้และมีความสำคัญต่อผู้คนที่อาศัยอยู่ในพื้นที่เช่นนี้ ดังนั้นประสิทธิภาพการโหลดของมันจึงมีความท้าทายมากพอเมื่อคุณเริ่มส่ง JavaScript เมกะไบต์ แต่คุณอาจกำลังเผชิญกับใครบางคนที่ไม่มี iPhone… เช่น iPhone X หรือ iPhone 13

Jeremy: พวกเขาอาจจะแค่ใช้ฟีเจอร์โฟนหรือเหมือนกับโทรศัพท์ Android ราคาประหยัด แค่พยายามใช้ชีวิต ฉันหมายถึง คิดถึงสิ่งต่างๆ เช่น ธนาคารออนไลน์ ความช่วยเหลือการว่างงาน หรือความช่วยเหลืออื่นๆ ของรัฐบาล พอร์ทัลเช่นนั้นสำหรับการสมัคร การเรียนรู้ออนไลน์ มีหลายสถานที่ซึ่ง JavaScript ที่มากเกินไปอาจส่งผลเสียต่อผู้ที่อาจไม่โชคดีพอที่จะอาศัยอยู่ในพื้นที่เมืองใหญ่ หรือแม้แต่ในพื้นที่เมืองใหญ่ที่อินเทอร์เน็ตบรอดแบนด์และผู้ที่ใช้งานช้ากว่าให้บริการไม่ดี . ฉันคิดว่าในฐานะนักพัฒนา เรามีแนวโน้มที่จะมองว่า… เราซื้อ MacBooks หรืออุปกรณ์ระดับไฮเอนด์เหล่านี้ และบางครั้งเราไม่เห็นจริงๆ ว่าปัญหาเหล่านี้อาจเกิดขึ้นที่จุดใดเมื่อเราใช้ JavaScript มากเกินไป

ดรูว์: และอย่างที่คุณพูดถึงในบางครั้ง อาจเป็นบุคคลที่มีจุดยืนมากที่สุดที่จะสูญเสียโดยไม่สามารถเข้าถึงบริการที่ถูกลงโทษโดยสิ่งนี้ คนเหล่านั้นที่ไม่มีการเชื่อมต่อข้อมูลที่รวดเร็วหรือไม่มีอุปกรณ์ที่มีความสามารถ บางครั้งเข้าถึงบริการที่หมายถึงทุกอย่างเพื่อ... มันหมายถึงทุกสิ่งสำหรับพวกเขาที่พวกเขาสามารถเข้าถึงได้ ดังนั้นมันจึงกลายเป็นปัญหาสิทธิมนุษยชนที่เกือบจะเป็นไปในทางใดทางหนึ่ง

เจเรมี: ใช่ ฉันหมายถึง เรามักจะเห็นว่าประสิทธิภาพของเว็บถูกจัดกรอบในแง่ของมูลค่าทางธุรกิจ ฉันเป็นที่ปรึกษาด้านประสิทธิภาพของ e-com บางบริษัทและเช่นบริษัทอาหารรายใหญ่ e-com รายใหญ่... เช่น ร้านค้า เช่น ร้านขายเครื่องใช้ไฟฟ้า และมันน่าดึงดูดใจมากที่จะทำเช่นนั้นใช่ไหม เพราะเมื่อคุณทำงานเพื่อธุรกิจ ฉันหมายถึงชัดเจนว่าคุณต้องการให้การเงินมีสุขภาพที่ดีและประสิทธิภาพของเว็บก็มีบทบาทในสิ่งที่ฉันคิด ฉันคิดว่ามีหลายกรณีศึกษาที่พิสูจน์ได้ อย่างไรก็ตาม มีแง่มุมของมนุษย์และแม้กระทั่งสำหรับธุรกิจ เช่น พูดเหมือนร้านขายของชำและอะไรแบบนั้น ใช่ พวกเขากำลังขับเคลื่อนรายได้ พวกเขาต้องการมีการเงินที่ดีและประสิทธิภาพของเว็บก็เป็นส่วนหนึ่ง แต่พวกเขาก็ตอบสนองความต้องการที่สำคัญเช่นกันใช่ไหม เหมือนคุณต้องกินใช่มั้ย?

เจเรมี: และเหมือนบางคนอาจต้องอยู่บ้านด้วยเหตุผลใดก็ตาม พวกเขาอาจจะไม่สามารถขึ้นรถได้ง่ายๆ พวกเขาอาจไม่มีรถ ดังนั้นพวกเขาจึงต้องพึ่งพาบริการเหล่านี้เพื่อรับการยังชีพ แต่ยิ่งไปกว่านั้น ความช่วยเหลือหากพวกเขาต้องการ และโดยเฉพาะอย่างยิ่ง เช่น การแทรกแซงในภาวะวิกฤต และเรื่องประเภทนั้น ฉันไม่คิดว่ามันพูดเกินจริงมากที่จะบอกว่าคู่หูที่ถูกทารุณกรรมและถูกไล่ออกจากบ้านอาจหันไปใช้สมาร์ทโฟนและกด Google เพื่อพยายามหาพอร์ทัลสำหรับการแทรกแซงและความช่วยเหลือในภาวะวิกฤต และ JavaScript ก็สามารถเข้ามาขวางทางเป้าหมายประเภทเหล่านั้นและเพื่อตอบสนองความต้องการของมนุษย์เหล่านั้นได้ เมื่อเรามีแนวโน้มจะพึ่งพิงมันเพียงเล็กน้อยมากเกินไป

ดรูว์: ฉันหมายถึง เราเคยเห็นแวบหนึ่งในช่วง 18 เดือนที่ผ่านมาหรือประมาณนั้นกับโควิดและผู้คนที่ต้องแยกจากกัน และอย่างที่คุณพูด จำเป็นต้องสั่งของชำให้ไปส่ง เว็บกลายเป็นเส้นชีวิตสำหรับพวกเขา ณ จุดนั้น พวกเขารู้สึกไม่สบาย ออกจากที่พักไม่ได้เพราะต้องแยกจากกัน ต้องหาอาหาร และซื้อเสบียงที่จำเป็น ฉันคิดว่ามันเป็นส่วนสำคัญของชีวิตประจำวันสำหรับเราทุกคน

เจเรมี: แน่นอน เมื่อย้อนกลับไปที่เรื่องราวของอุปกรณ์ Tim Kadlec เขียนงานที่น่าทึ่งเมื่อสองสามปีก่อน ฉันคิดว่ามันเป็นสองปี หรืออาจจะเป็นเมื่อสามปีก่อน แต่มันถูกเรียกว่า Prioritizing the Long Tail of Performance และเมื่อคุณดูสิ่งนั้น... ในสำนวนเกี่ยวกับประสิทธิภาพของเว็บ เราจะพูดถึงข้อมูลในห้องปฏิบัติการกับข้อมูลภาคสนาม และข้อมูลในห้องปฏิบัติการก็เหมือนกับการที่คุณใช้งาน lighthouse หรือคุณกำลังทดสอบเว็บไซต์ในการทดสอบหน้าเว็บเพื่อดูว่ามันทำงานเป็นอย่างไร สิ่งเหล่านี้เป็นเครื่องมือที่มีประโยชน์จริงๆ แต่เมื่อคุณดูข้อมูลภาคสนาม คุณจะเริ่มได้ภาพที่ใหญ่ขึ้นและมุมมองที่กว้างขึ้นว่าใครคือผู้ฟังของคุณจริงๆ และในบทความนี้ Tim Kadlec พูดถึงความสำคัญของการจัดลำดับความสำคัญของประสิทธิภาพ หมายความว่าอุปกรณ์เหล่านี้ทั้งหมด… อาจไม่แข็งแกร่งและทรงพลังเท่ากับอุปกรณ์ที่เราในฐานะนักพัฒนาซอฟต์แวร์อาจมี

Jeremy: และแนวคิดเบื้องหลังบทความก็คือถ้าเราสามารถมุ่งเน้นไปที่เปอร์เซ็นไทล์ที่ 90 หรือ 95 นั้นได้ เราก็… และปรับปรุงประสบการณ์นั้นสำหรับคนเหล่านั้น เรากำลังสร้างเว็บที่เร็วขึ้นสำหรับทุกคน รวมถึงเว็บไซต์ที่ใช้อุปกรณ์ที่รวดเร็ว และโจมตีจุดข้อมูลในสหรัฐอเมริกาและนี่มาจากเช่น statcounter.com บางอย่างเช่น 28 จุด… ผู้คนประมาณ 28% อยู่ในอุปกรณ์ iOS ที่เครื่องมือนี้จับภาพ และประมาณ 21% ของพวกเขาเป็น Android และ Android มีแนวโน้มที่จะเป็นตัวแทนของส่วนที่ดีของอุปกรณ์ส่วนท้ายนั้น เพราะ Android ไม่ใช่อุปกรณ์แบบเสาหิน ผู้ผลิตอุปกรณ์หลายรายผลิตโทรศัพท์ Android แต่ตรงกันข้ามกับโลก เนื่องจากโลกเป็นมากกว่าแค่สหรัฐอเมริกา มีคนประมาณ 16% ที่ใช้ iOS และประมาณ 41% ของผู้ที่ใช้ Android ดังนั้นการจัดลำดับความสำคัญของประสบการณ์ที่ช้ากว่าหรืออาจช้ากว่านั้นจึงคุ้มค่าจริง ๆ

Drew: ฉันอ่านหนังสือของคุณเกี่ยวกับการควบคุมปริมาณความร้อนของอุปกรณ์ ซึ่งไม่ใช่สิ่งที่ฉันเคยคิดมาก่อนเลย มีข้อกังวลอะไรบ้าง?

Jeremy: ข้อกังวลที่นั่น และฉันไม่เหมือนผู้เชี่ยวชาญไมโครโปรเซสเซอร์ไม่ว่าด้วยวิธีใด ฉันเป็นแค่นักพัฒนาเว็บที่อาจเขียนมากไปหน่อย แต่... ดังนั้น แนวคิดเบื้องหลังการควบคุมปริมาณความร้อนและมีอยู่ในทุกระบบ ไม่ใช่แค่ในโทรศัพท์และแท็บเล็ต นั่นคือไมโครโปรเซสเซอร์จะ... เมื่อต้องทำงานหนักเกินไปหรือ แค่ปริมาณงานโดยทั่วไป ของเสียของงานนั้นก็คือความร้อน ดังนั้นอุปกรณ์ต่างๆ มีวิธีบรรเทาปัญหานี้ เช่นเดียวกับแล็ปท็อปของคุณที่มีทั้งอุปกรณ์ระบายความร้อนแบบพาสซีฟและแบบแอคทีฟ

เจเรมี: เหมือนกับอุปกรณ์ทำความเย็นแบบพาสซีฟก็เหมือนแผงระบายความร้อนหรือตัวกระจายความร้อนบางชนิด และส่วนแอคทีฟของสิ่งนั้นก็เหมือนกับพัดลมเพื่อกระจายความร้อนได้อย่างมีประสิทธิภาพมากขึ้น บางอย่างเช่นการสร้างพีซีแบบกำหนดเองอาจใช้เช่นการระบายความร้อนด้วยของเหลวซึ่งเป็นตัวอย่างที่ค่อนข้างรุนแรงกว่า แต่โทรศัพท์มือถือไม่มีสิ่งนั้นเพราะคุณจะใส่พัดลมไว้ที่ไหนถ้าพกพาได้ สิ่งใช่มั้ย?

เจเรมี: ดังนั้น เพื่อให้อุปกรณ์เหล่านี้สามารถรับมือกับภาระงานหนักเหล่านี้ พวกเขาอาจลดความเร็วของโปรเซสเซอร์แบบเทียม เช่น ลดอัตรานาฬิกาลงจนกว่าอุปกรณ์นั้นจะเข้าสู่สถานะที่อัตรานาฬิกานั้นจะเพิ่มขึ้น และนั่นมีความหมายเพราะถ้าคุณกำลังเคี้ยวจาวาสคริปต์เป็นตัน ๆ คุณต้องการชิ้นใหญ่ ๆ เหล่านี้ที่เริ่มดำเนินการใช่ไหม? ดังนั้นจึงเป็นการประมวลผลจำนวนมากผ่านการประเมินและการแยกวิเคราะห์ในการรวบรวมแล้วดำเนินการ และถ้าคุณทำอย่างนั้นด้วย JavaScript หนึ่งหรือสองเมกะไบต์ และคุณมีกระบวนการอื่นๆ มากมายที่เกิดขึ้นในพื้นหลัง เช่น แท็บต่างๆ สิ่งนั้น ที่สามารถทำให้สถานะของคุณ... ที่เพิ่มโอกาสที่ อุปกรณ์อาจเข้าสู่สภาวะควบคุมความร้อน ซึ่งหมายความว่าจะมีความสามารถน้อยกว่าในการทำงานพิเศษนั้น

ดรูว์: มันเลยเป็นวงวนความคิดเห็นเชิงลบ ใช่มั้ย? คุณให้อุปกรณ์ทำงานมากมาย มันร้อนมากและจากนั้นก็ไม่สามารถทำงานนั้นได้จริง ๆ เพราะต้องเค้นกลับ

เจเรมี: ถูกต้อง และอีกครั้ง ฉันไม่ใช่ผู้เชี่ยวชาญด้านไมโครโปรเซสเซอร์ ฉันแน่ใจว่าหากวิศวกรที่คุ้นเคยกับสิ่งนี้จริงๆ อาจแก้ไขรายละเอียดบางอย่างให้ฉันได้ แต่แนวคิดทั่วไปก็คือ ใช่ เมื่อแรงกดดันจากสิ่งแวดล้อมนั้นเพิ่มขึ้น อุปกรณ์ก็ไม่สามารถ รับมือกับงานหนักเหล่านี้จนกว่าแรงกดดันนั้นจะลดลง

Drew: เรากำลังเขียน JavaScript สำหรับอุปกรณ์ทุกประเภทตั้งแต่ Apple M1 Max ล่าสุดเป็นโปรเซสเซอร์ใหม่ใช่ไหม แล็ปท็อปไปจนถึงอุปกรณ์ที่แทบไม่มี RAM ที่ใช้งานได้เพียงพอที่จะแสดงหน้าเว็บ แต่เว็บไม่ได้เริ่มต้นแบบนี้ ผู้ฟังที่อายุน้อยกว่าอาจสนใจที่จะรู้ว่าเราเคยสร้างประสบการณ์เว็บแบบโต้ตอบโดยไม่ต้องใช้ JavaScript เลย เฟรมเวิร์กที่ใหญ่และหนักหน่วงของเราจะทำให้เราต้องเลิกทำ

เจเรมี: ฉันจะบอกว่ากรอบงานมีเวลาและสถานที่ และคนที่อ่านข้อความที่ตัดตอนมาจากหนังสือเล่มนี้อาจเข้าใจว่าฉันต่อต้านกรอบ และฉันวิพากษ์วิจารณ์เฟรมเวิร์กหลาย ๆ อันอย่างแน่นอน แต่พวกมันมีจุดประสงค์และเป็นไปได้ที่จะใช้มันในลักษณะที่จะรักษาประสบการณ์ผู้ใช้ที่ดีหรืออาจส่งผลให้ผู้ใช้ได้รับประสบการณ์ที่ดี แต่สิ่งที่ฉันไม่คิดว่าเราทำมากพอคือการประเมินเฟรมเวิร์กเหล่านี้ในเชิงวิพากษ์ในแง่ของอันตราย... ประสิทธิภาพของรันไทม์ใช่ไหม ประเภทของสิ่งที่คุณกำลังพูดถึง ซึ่งถ้าคุณคลิกปุ่ม และอุปกรณ์จะใช้เวลาเพียงเสี้ยววินาทีหรือสองวินาทีในการตอบสนองต่ออินพุตนั้น เพราะมีอะไรเกิดขึ้นมากมายในเบื้องหลัง คุณมีสิ่งของ JavaScript ของบุคคลที่สาม เช่น การรวบรวมการวิเคราะห์ จากนั้นคุณก็มีเหมือนกับสิ่งอื่นๆ ที่ทำงานบนเธรด

Jeremy: และถ้าคุณไม่ประเมินประสิทธิภาพรันไทม์ของเฟรมเวิร์กอย่างมีวิจารณญาณ คุณอาจจะทิ้งโอกาสบางอย่างไว้บนโต๊ะเพื่อให้บริการผู้ใช้ของคุณได้ดียิ่งขึ้น ตัวอย่างที่ดี ฉันชอบที่จะใช้ is react กับ pre-act ฉันเคยตีกลองนี้มาซักพักแล้ว ฉันทำบทความเกี่ยวกับ CSS-Tricks เมื่อไม่นานมานี้ซึ่งมีการโต้ตอบการคลิกพื้นฐานเช่นเมนูการนำทางบนมือถือ และฟังดูไม่สำคัญ แต่สิ่งที่คุณพบก็คือว่าในอุปกรณ์ทั้งหมดนั้นการตอบสนองนั้นให้ประสิทธิภาพรันไทม์ที่ดีขึ้น แต่โดยพื้นฐานแล้วมี API เดียวกัน มีความแตกต่าง มีข้อแตกต่างเล็กน้อยและสิ่งต่างๆ ที่สามารถเขียนทับได้ด้วยการใช้ตัวช่วยก่อนการกระทำ แต่นั่นง่าย... และฉันไม่ควรพูดทางเลือกง่ายๆ แต่ทางเลือกนั้น ทางเลือกพื้นฐานนั้นสามารถสร้างความแตกต่างระหว่างประสบการณ์ได้ ที่ทำงานได้ดีสำหรับผู้ใช้ทุกคนหรืออย่างน้อยผู้ใช้ส่วนใหญ่ หรือประสบการณ์ที่ใช้งานได้ดีสำหรับบางคนเท่านั้น หวังว่าคงจะพอเข้าใจบ้าง]

Drew: ฉันหมายถึงด้วยเฟรมเวิร์กและเครื่องมือสร้างทั้งหมด ดูเหมือนว่าพวกเขาจะดีขึ้นตลอดเวลาที่ทำสิ่งต่างๆ เช่น การเขย่าต้นไม้และการเพิ่มประสิทธิภาพบันเดิลที่จัดส่ง และวิธีการส่งไปยังเบราว์เซอร์ เมื่อใช้เฟรมเวิร์กขนาดใหญ่ มีจุดเปลี่ยนที่คุณคิดว่าคุณกำลังเขียนแอปพลิเคชันขนาดใหญ่นี้ที่ใด มีโค้ดของคุณเองมากจนเฟรมเวิร์กทำให้คุณสามารถจัดส่งโค้ดน้อยลงเนื่องจากสิ่งที่เป็นนามธรรมทั้งหมดหรือไม่

Jeremy: นั่นเป็นคำถามที่ตอบยาก แง่มุมหนึ่งก็คือ ตัวเฟรมเวิร์กแสดงถึงจำนวนโค้ดที่คุณไม่มีวันปรับให้เหมาะสมได้ ดังนั้นการมีเหมือนกรอบบาง ๆ เช่นก่อนการแสดงหรือจำนวนไลค์ใด ๆ ... หรือเช่นการสะกดคำนั่นช่วยได้มาก แต่ปัญหาที่ฉันพบและฉันคิดว่าข้อมูลจากประเภทไฟล์เก็บถาวร HTTP รองรับประเด็นนี้คือ ดูเหมือนว่าทุกครั้งที่เรามีความก้าวหน้าเหล่านี้ในไมโครโปรเซสเซอร์และเครือข่ายที่เร็วขึ้น ก็คือเรามักจะกินกำไรนั้น จริงไหม?

Jeremy: เรามักจะอยู่บนลู่วิ่งที่เราไม่เคยก้าวหน้าจริงๆ และฉันไม่รู้ เหมือนกับว่าฉันไม่มีญาณทิพย์เกี่ยวกับประวัติศาสตร์ของ... หรือขออภัย อนาคตของเฟรมเวิร์กจะเป็นอย่างไร ฉันแน่ใจว่าสามารถรวบรวมประสิทธิภาพที่เพิ่มขึ้นได้ แต่สิ่งที่เราเห็นในฟิลด์ในแง่ของจำนวน JavaScript ดิบนั้นเป็นอย่างไร… ปริมาณ JavaScript ดิบเท่านั้นที่ถูกใช้ ไม่ได้บอกฉันว่านี่เป็นปัญหาที่เราสามารถทำได้โดยอัตโนมัติ ฉันคิดว่าเราต้อง… เราต้องเป็นมนุษย์และเข้าไปแทรกแซงและตัดสินใจเพื่อประโยชน์สูงสุดของผู้ใช้ ไม่อย่างนั้น ฉันไม่เห็นว่าเราจะลงจากลู่วิ่งนี้ อาจไม่ใช่ในอาชีพการงานของฉัน แต่ฉันไม่รู้

Drew: ในหนังสือ คุณพูดถึงเว็บไซต์และเว็บแอป และการทำความเข้าใจความแตกต่างและสิ่งที่คุณกำลังทำงานด้วยช่วยให้คุณเลือกกลยุทธ์สำหรับวิธีพัฒนาและเพิ่มประสิทธิภาพได้อย่างไร บอกเราหน่อยเกี่ยวกับเรื่องนั้น

Jeremy: นั่นเป็นคำถามที่ดีจริงๆ และฉันเขียนเกี่ยวกับเรื่องนี้ในบทความชื่อนี้ที่ฉันเขียนสำหรับ A List Apart ที่เรียกว่า Responsible JavaScript Part One ซึ่งเป็นบทโหมโรงของหนังสือเล่มนี้ นั่นคือเราโหลดคำศัพท์นี้มาก เช่นเดียวกับนักเขียนด้านเทคนิค ฉันเห็นว่าทั้งสองใช้สลับกันได้ สิ่งที่ฉันเห็นคือกับเว็บไซต์ ความหมายก็คือ มันเป็นประสบการณ์แบบหลายวัยใช่ไหม เป็นการรวบรวมเอกสาร ในตอนนี้ เอกสาร… เอกสารเหล่านั้นอาจมีฟังก์ชันการทำงานที่ฝังตัวเหมือนเกาะเล็กๆ เหล่านี้ อย่างที่คำนี้เคยเป็นมาก่อน คือเกาะเล็กๆ ของฟังก์ชันที่ช่วยให้ผู้คนทำสิ่งต่างๆ ให้เสร็จสิ้นได้

Jeremy: แต่ก็มีเหมือนเว็บแอปและเว็บแอปที่มีความหมายแฝงของแอปแบบเนทีฟ เช่น ฟังก์ชันการทำงาน เรากำลังพูดถึงแอปพลิเคชันหน้าเดียว เรากำลังพูดถึง JavaScript จำนวนมากเพื่อขับเคลื่อนการโต้ตอบที่ซับซ้อน และมีบางครั้งที่รูปแบบเว็บแอปเหมาะสม ตัวอย่างเช่น Spotify เป็นตัวอย่างที่ดีในเรื่องนี้ ที่ทำงานได้ดีกว่าในฐานะเว็บแอป คุณคงไม่อยากลองใช้มันหรือออกแบบมันเป็นแอพพลิเคชั่นที่มีหลายหน้า เช่นเดียวกับเว็บไซต์แบบดั้งเดิม แต่ฉันคิดว่ามันไม่ใช่ค่าเริ่มต้นที่ยั่งยืนเพราะเมื่อคุณเริ่มต้นสำหรับทุกโครงการคือการพูดว่า "เราจำเป็นต้องจัดส่งแอปพลิเคชันหน้าเดียวเช่นเราเตอร์ฝั่งไคลเอ็นต์และเฟรมเวิร์กที่หนักหน่วงและออฟโหลดทั้งหมด ของการประมวลผลการเรนเดอร์จากเซิร์ฟเวอร์เหมือนไปยังไคลเอนต์” ฉันคิดว่านั่นคือจุดที่คุณเริ่มถึงจุดที่คุณยกเว้นผู้ใช้แม้ว่าจะไม่ได้ตั้งใจ แต่ก็ยังยกเว้นพวกเขา

ดรูว์: มีช่องว่างขนาดใหญ่ไหม คุณคิดว่าระหว่างคนที่ใช้แนวทางของเราจะเผยแพร่เว็บไซต์และมันอาจมีฟังก์ชันเชิงโต้ตอบและผู้ที่พูดว่า “เราเป็นบริษัทซอฟต์แวร์ เราเป็น การสร้างผลิตภัณฑ์ ผลิตภัณฑ์ซอฟต์แวร์ และแพลตฟอร์มของเราที่เราจะนำเสนอผ่านทางเว็บ แทนที่จะเป็นแอปพลิเคชันแบบเนทีฟสำหรับหลายแพลตฟอร์ม” เป็นไปได้ไหมที่พวกเขากำลังเข้าใกล้ปัญหาในรูปแบบที่ต่างไปจากเดิมอย่างสิ้นเชิง? ข้อควรพิจารณาแตกต่างกันไปตามแนวโน้มของคุณ ณ จุดนั้นหรือไม่?

เจเรมี: นั่นเป็นคำถามที่ยาก ดังนั้น-

Drew: มันยากสำหรับฉันที่จะพูด

Jeremy: ฉันจะบอกว่าบริษัทที่... ตัวอย่างที่ดีก็เป็นเหมือนข่าวใช่ไหม รูปแบบเว็บไซต์ใช้งานได้ดี เพราะแท้จริงแล้วมันคือชุดของเอกสาร บทความ และคนที่พัฒนาประสบการณ์เหล่านั้นอาจจะมีทักษะที่แตกต่างจากบริษัทอย่าง Spotify หรือบริษัทที่มีเว็บแอปพลิเคชันขนาดใหญ่อย่าง Envision หรืออะไรทำนองนั้น ใช่แล้ว ฉันคิดว่าพวกเขาจะมาที่นี้จากมุมที่ต่างกัน วิธีที่ฉันดูคือมีส่วน...หรืออย่างน้อยนี่คือวิธีที่ฉันรับรู้ชุมชนการพัฒนาเว็บโดยรวมคือมีกลุ่มคน ของนักพัฒนาเว็บที่มาจากการพัฒนาซอฟต์แวร์ที่ไม่ใช่แบบดั้งเดิม เบื้องหลังใช่ไหม และฉันก็เป็นหนึ่งในคนเหล่านี้ ฉันกำลังซ่อมแซมเว็บเมื่อตอนที่ฉันยังเป็นเด็กใช่ไหม

Jeremy: เหมือนตอนมัธยมต้นและทำแฟนเพจโง่ๆ ให้ทุกคนชอบเล่นเกมในตอนที่ฉันชอบมากๆ และฉันไม่เคยได้รับการศึกษาด้านวิทยาการคอมพิวเตอร์แบบนั้นมาก่อน มีแนวคิดเกี่ยวกับวิทยาการคอมพิวเตอร์ที่ฉันหยิบขึ้นมาตลอดทาง นอกจากนี้ยังมีส่วนของนักพัฒนาอีกด้วย โดยเฉพาะอย่างยิ่งผมคิดว่าในช่วง 5-10 ปีที่ผ่านมา ซึ่งเข้ามาใกล้สิ่งนี้ด้วยวิธีการที่มุ่งเน้นวิทยาการคอมพิวเตอร์มากกว่า และฉันคิดว่านั่นจะ... ความแตกต่างและประสบการณ์เหล่านั้นจะนำแต่ละกลุ่มมาสรุปผลของตนเองเกี่ยวกับวิธีที่ดีที่สุดในการพัฒนาเว็บ แต่ฉันคิดว่าวิธีเดียวที่คุณจะทำได้จริงๆ... ที่คุณสามารถพัฒนาได้อย่างยั่งยืนสำหรับเว็บคือการประเมินอย่างมีวิจารณญาณว่าคุณกำลังสร้างอะไร และพยายามปรับแนวทางที่ตอบสนองผู้ใช้ผลิตภัณฑ์เหล่านั้นได้ดีที่สุด และนั่นคือสิ่งที่รูปแบบเว็บไซต์และเว็บแอปอยู่ในหัวของฉันเมื่อฉันประเมินสิ่งเหล่านี้

ดริว : ครับ มันน่าสนใจ ฉันหมายถึง ในหนังสือ คุณอ้างถึงงานของฉันจริงๆ ขอบคุณมาก. และการเลือกเทคโนโลยีที่น่าเบื่อของฉันโดยพื้นฐานแล้ว PHP Apache และ JavaScript ที่รีดด้วยมือสามารถสร้างประสบการณ์ผู้ใช้ที่ฉับไวตามค่าเริ่มต้นโดยไม่จำเป็นต้องทำการเพิ่มประสิทธิภาพใด ๆ ฉันคิดว่านั่นทำให้ประสบการณ์การใช้งานที่ยอดเยี่ยมสำหรับผู้เยี่ยมชมส่วนหน้าที่เข้ามาและดูเนื้อหาบนเว็บไซต์

Drew: แต่จริงๆ แล้ว ฉันรู้สึกเหมือนสภาพแวดล้อมนั้นสำหรับการเขียนเนื้อหาแบบพลิกกลับ เมื่อคุณลงชื่อเข้าใช้และเผยแพร่เนื้อหาของคุณบนเว็บไซต์ ฉันคิดว่ามันทนทุกข์ทรมานเล็กน้อยจากการสร้างด้วยวิธีเว็บไซต์ แทนที่จะเป็นแนวทางเว็บแอป JavaScript ที่หนักหน่วง มากเสียจนฉันกำลังคิด… หรือบางทีมันอาจจะต้องเป็นทั้งสองอย่าง ฉันต้องเผยแพร่ส่วนหน้าต่อไปใน HTML และ CSS แบบคงที่ที่ดีและ JavaScript เล็กน้อย แต่แบ็กเอนด์ที่ฉันต้องการมอบประสบการณ์การเขียนเนื้อหาอาจเป็นทางเลือกเทคโนโลยีที่แตกต่างออกไปจะดีกว่า มันค่อนข้างน่าสนใจเพราะมันไม่จำเป็นต้องเป็นสิ่งหนึ่งเสมอไปหรืออย่างอื่นทำ? มันไม่ใช่ตัวเลือกไบนารี มันเป็นสเปกตรัมมากกว่าที่คุณจะพูด?

เจเรมี: ใช่แน่นอน และฉันคิดว่าเราเริ่มเห็นการพูดคุยกันมากขึ้นในชุมชนเกี่ยวกับการพัฒนาเว็บที่เป็นคลื่นความถี่แบบนั้น เพื่อให้ตรงไปตรงมาสำหรับผู้ที่อาจสนใจหนังสือของฉัน มันมาจากเว็บไซต์ของสเปกตรัมอย่างแน่นอน และอีกครั้ง เพราะฉันรู้สึกว่านั่นเป็นค่าเริ่มต้นที่ดีเสมอ หากคุณไม่รู้ว่าคุณต้องการสร้างอะไรอย่างไร อาจเป็นการดีที่สุดที่จะลองสร้างมันในลักษณะที่ลดการใช้ JavaScript ให้น้อยที่สุดและลดการผลักดันงานเพิ่มเติมไปยังไคลเอนต์ ที่กล่าวว่าฉันคิดว่าการสังเกตเป็นประสบการณ์ที่ยอดเยี่ยม ฉันคิดว่าเทคโนโลยีที่สวมใส่ได้ดีและ "น่าเบื่อ" จริงๆ เหล่านี้ทำงานได้ดีกับงานที่ทำอยู่ และมันทำในลักษณะที่เปิดกว้างและเปิดใช้งานสำหรับนักพัฒนาใช่ไหม?

Jeremy: คุณไม่จำเป็นต้องมีความรู้เชิงลึกเกี่ยวกับสิ่งที่ชอบ... เกี่ยวกับร้านการจัดการของรัฐหรือกรอบการจัดการของรัฐเพื่อดึงสิ่งเหล่านี้ออกไปจริงๆ และฉันคิดว่าการสังเกตนั้นได้รับการบริการอย่างดีจากวิธีการนั้น แต่สำหรับประเด็นของคุณ ฉันคิดว่ามีโอกาสในเว็บไซต์ใด ๆ ที่จะเข้าใกล้ช่วงกลางของสเปกตรัมมากขึ้นโดยไม่ต้องเข้าไปที่การกำหนดเส้นทางฝั่งไคลเอ็นต์ทั้งหมดเช่นเฟรมเวิร์กที่หนักหน่วงซึ่งจัดการทุกอย่างในไคลเอนต์และประเภทนั้น ฉันคิดว่าแนวทางของเกาะกำลังเริ่มสำรวจสิ่งที่ดูเหมือน และฉันจะยอมรับว่า ฉันอาจจะทำบางอย่างเกี่ยวกับหมู่เกาะโดยไม่ได้ตั้งใจ ฉันคิดว่าเรามีมาระยะหนึ่งแล้ว เราแค่ยังไม่ได้ตั้งชื่อมันจริงๆ แต่ฉันคิดว่าตอนนี้เราได้ระบุแล้วว่าเหมือนเป็นจุดกึ่งกลาง เราอาจเริ่มเห็นประสบการณ์เว็บที่ให้ประสบการณ์ผู้ใช้ที่ดี แต่ก็ยังมีการโต้ตอบกันมากขึ้น หวังว่าจะไม่คดเคี้ยวมาก

ดรูว์: มันเหมือนพิณย้อนกลับไปเล็กน้อย จนถึงวันที่เราจะฝังเกาะแฟลชหรือ-

เจเรมี: ใช่

Drew: บางอย่างในหน้าเว็บที่เป็นส่วนโต้ตอบเล็กๆ ของเรา และส่วนที่เหลือก็หมุนเวียนไปรอบๆ

Jeremy: ใช่แล้ว เช่นเดียวกับ Flash โอ้ พระเจ้า การทำซ้ำสามครั้งในแฟ้มผลงานส่วนตัวของฉันเมื่อตอนเรียนจบมหาวิทยาลัย เป็นเรื่องเส็งเคร็งสำหรับการทำ Flash knockoffs ขั้นสูง และชอบเอฟเฟกต์แบบโฮเวอร์ และเรื่องนั้นก็สนุกจริงๆ และบางครั้งฉันก็คิดถึงมันเหมือนมีเนื้อหามากมายที่กำลังจะหายไป เพราะเราไม่ได้ใช้ Flash อีกต่อไป และนั่นก็แย่จริงๆ แต่ในแง่หนึ่ง มันก็เป็นบรรพบุรุษของเกาะแบบนี้ ที่เรากำลังพูดถึงอยู่ ซึ่งก็คือคุณสามารถมีได้เหมือนกับหน้าเว็บแบบคงที่และทุกอย่าง แต่แล้วคุณจะมีประสบการณ์แบบอินเทอร์แอกทีฟที่อุดมสมบูรณ์จริงๆ แบบเดียวกับที่วางไว้ตรงกลาง

Drew: การเพิ่มประสิทธิภาพแบบก้าวหน้าถือเป็นแนวทางปฏิบัติที่ดีที่สุดในการสร้างประสบการณ์เว็บมาอย่างยาวนาน ยังคงเป็นอย่างนั้นอยู่ไหม คุณคิดว่า?

Jeremy: ฉันยอมให้มันเป็นไปได้... ฉันไม่อาจจะยอมให้มันทำงานมากขึ้นในการเพิ่มประสิทธิภาพแบบก้าวหน้า เพราะในทางใดทางหนึ่ง คุณกำลังแบ่งแยกประสบการณ์การพัฒนาของคุณ คุณกำลังพยายามนำเสนอฟังก์ชันการทำงานขั้นต่ำของเว็บไซต์ในลักษณะที่เซิร์ฟเวอร์สามารถจัดการกับการโต้ตอบที่สำคัญเหล่านี้ได้ แต่ยิ่งไปกว่านั้น คุณกำลังพูดว่า "เอาล่ะ ตอนนี้ฉันต้องการอำนวยความสะดวกให้การโต้ตอบนี้ราบรื่นยิ่งขึ้นด้วย JavaScript" ฉันยังคิดว่ามันเป็นวิธีที่ใช้ได้ในการบรรลุเป้าหมายด้วยเว็บไซต์ แอป หรือผลิตภัณฑ์ของคุณ

Jeremy: แต่สิ่งที่ฉันจะพูดก็คือฉันไม่เคยแนะนำว่าทุกการโต้ตอบบนเว็บไซต์จะต้องได้รับการอำนวยความสะดวกด้วยรูปแบบการนำทางแบบซิงโครนัสนี้ ตัวอย่างที่ดีอาจเป็นหน้าชำระเงินสำหรับเว็บไซต์ econ ของคุณควรมีเส้นทางเซิร์ฟเวอร์อย่างแน่นอน คุณควรมีเส้นทางของเซิร์ฟเวอร์เพื่อเพิ่มของลงในรถเข็น และจากนั้นคุณควรจะจัดเรียง JavaScript ให้เพียงพอเพื่อทำให้สิ่งนั้นน่าพอใจยิ่งขึ้นเล็กน้อย เพื่อให้สิ่งต่างๆ เร็วขึ้นเล็กน้อยและไม่พร้อมกันมากขึ้น

Drew: เมื่อพูดถึงการวัดประสิทธิภาพ เราได้ยินมามากมายเกี่ยวกับ Core Web Vitals ส่วนใหญ่มาจาก Google สิ่งเหล่านี้เป็นเกณฑ์มาตรฐานที่เราควรจะวัดหรือไม่? หรือนั่นคือสิ่งที่ Google ต้องการให้เราคิด? ฉันขอขอบคุณที่คำถามนี้อาจเป็นคำถามยากที่คุณเริ่มทำงานที่ Google

เจเรมี: ใช่ ใช่ คุณก็รู้ ฉันกำลังพูดเพื่อตัวเองที่นี่ ฉันคิดว่า Web Vitals คือ... Web Vitals หลักเริ่มต้นเป็นความพยายามที่ดีในการกำหนดว่าส่วนใดของประสบการณ์ผู้ใช้มีความสำคัญ ฉันคิดว่าตัววัด เช่น การเปลี่ยนเลย์เอาต์สะสมและ Contentful Paint ที่ใหญ่ที่สุด เริ่มคิดถึงประสบการณ์ในแบบที่เราไม่ได้เริ่มหาปริมาณจริงๆ ก่อนหน้านั้นจะมีการปรับเลย์เอาต์แบบสะสม เพราะหากมีช่วงไหนที่คุณโกรธก็เพราะปุ่มนั้นชอบที่จะย้ายไปรอบๆ เพจหรืออะไรทำนองนั้น ฉันหมายความว่า ฉันคิดว่านั่นเป็นประโยชน์ในการวัด มันไม่สมบูรณ์ และฉันคิดว่าใครก็ตามที่ทำงานเกี่ยวกับ Core Web Vitals จะเห็นด้วยว่าต้องมีการปรับปรุงในเมตริกเหล่านี้ มีตัวชี้วัดอื่นๆ ที่ฉันไม่จำเป็นต้องเห็นด้วยทั้งหมด เช่นเดียวกับการหน่วงเวลาอินพุตครั้งแรกเป็นเมตริกที่ยากต่อการปักหมุด

Jeremy: ฉันคิดว่ามันมีประโยชน์จริงๆ ใช่ไหม เพราะสิ่งที่คุณพูดอย่างแท้จริงคือเราต้องการวัดความล่าช้าและการโต้ตอบในการโต้ตอบครั้งแรกที่ผู้ใช้สร้างขึ้น แต่มันขาดบริบทเล็กน้อยใช่ไหม เพราะบางอย่าง… หลายๆ อย่างสามารถส่งผลกระทบต่อมันได้ เพราะไม่จำเป็นต้องผูกติดอยู่กับ JavaScript เสมอไป การหน่วงเวลาอินพุตครั้งแรกอาจแสดงถึงการหน่วงเวลาที่เกิดขึ้นจากการเน้นฟิลด์แบบฟอร์มใช่ไหม ของแบบนั้น ของใน HTML ฉันคิดว่าตัววัดเหล่านั้น… ตัววัดเช่นการหน่วงเวลาอินพุตครั้งแรกสามารถ… สิ่งเหล่านี้อาจเป็นประโยชน์หากคุณสามารถกำหนดบริบทด้วยสิ่งต่าง ๆ เช่นรายการจาก API งานที่ใช้เวลานาน การกำหนดเวลาองค์ประกอบ และประเภทของสิ่งต่าง ๆ เหล่านั้น ท้ายที่สุด ฉันคิดว่า Core Web Vitals ในอนาคตจะพิสูจน์ได้ว่ามีประโยชน์และเป็นเครื่องมือในการวัดว่าอะไรที่ทำให้ผู้ใช้ได้รับประสบการณ์ที่ดี นั่นเป็นความเห็นส่วนตัวของฉัน

ดรูว์: ฉันเดาว่ามันเป็นหนึ่งในนั้นที่คุณสามารถวัดกับตัวเอง วัดการปรับปรุงของคุณเองหรือว่าประสบการณ์ของคุณแย่ลงหรือไม่ถ้าคะแนนของคุณเปลี่ยนไป ไม่สนใจเรื่องสัญญาณไฟจราจรมากนัก แต่สนใจสิ่งที่คุณรู้ เกี่ยวกับบริบทของไซต์ของคุณและวิธีที่การเปลี่ยนแปลงได้ทำการปรับปรุง

Jeremy: ฉันคิดว่าตัววัด เช่น การเปลี่ยนเลย์เอาต์สะสมนั้นยอดเยี่ยม แต่ก็สามารถได้รับประโยชน์จากการปรับปรุงเล็กน้อยเช่นกัน การเปลี่ยนแปลงเค้าโครงสะสม ส่วนใหญ่จะวัดการเลื่อนเค้าโครงที่เกิดขึ้นระหว่างการโหลด และอย่างที่เราทราบกันดีว่าเมื่อผู้ใช้เข้าชมหน้าใดหน้าหนึ่งและเข้าสู่หน้าที่มีการเปลี่ยนแปลงเลย์เอาต์เมื่อใดก็ได้ ใช่ไหม มีงานแน่นอนที่ฉันคิดว่าสามารถทำได้เพื่อปรับปรุงวิธีที่เราสังเกตปรากฏการณ์ดังกล่าวอย่างแน่นอน

Drew: ฉันคิดว่าความเสถียรของเลย์เอาต์เป็นหนึ่งในสิ่งที่ทำได้ยากมากเมื่อคุณทำงานกับการเพิ่มประสิทธิภาพแบบก้าวหน้า บางครั้งเมื่อคุณโหลดหน้าที่แสดงผลของเซิร์ฟเวอร์แล้วเริ่มปรับปรุงในไคลเอนต์ อาจเกิดอันตรายจากการสร้างการเปลี่ยนเลย์เอาต์ประเภทนั้น ใช่ไหมล่ะ

เจเรมี: แน่นอน และนั่นเป็นสาเหตุที่ความชุ่มชื้นของส่วนประกอบกลายเป็นเรื่องยุ่งยาก เนื่องจากขนาดของส่วนประกอบนั้นอาจเปลี่ยนแปลงได้จากหลายสาเหตุ เช่นเดียวกับที่อาจมีเนื้อหาอยู่ในองค์ประกอบฝั่งไคลเอ็นต์ที่ไม่แสดงผลบนเซิร์ฟเวอร์เนื่องจากสถานะที่ไม่ได้รับการประเมินจนกว่าจะดำเนินการบนไคลเอ็นต์ เป็นปัญหาที่ยากมาก ฉันจะไม่นั่งที่นี่และแสร้งทำเป็นว่าฉันมีกระสุนเงินสำหรับมัน

Drew: ฉันต้องการพูดคุยเกี่ยวกับไดนามิกของการนำเข้าและการแยกโค้ด ทั้งสองเป็นเทคนิคที่แตกต่างกันสำหรับปัญหาในการดาวน์โหลดและเรียกใช้ JavaScript ชุดใหญ่ล่วงหน้าในช่วงเริ่มต้นของประสบการณ์ มีความเสี่ยงที่จะเพิ่มประสิทธิภาพมากเกินไปด้วยการส่งคำขอขนาดเล็กจำนวนมาก โดยเฉพาะอย่างยิ่งในโปรเจ็กต์ขนาดเล็กที่ง่ายที่สุด หรือเป็นสิ่งที่พวกเขาไม่เป็นอันตรายอย่างยิ่งในการปรับใช้การจัดเรียงตั้งแต่แรกเริ่มที่คุณจะมีปัญหาเหล่านี้ หรือคุณควรรอจนกว่าคุณจะเห็นปัญหาด้านประสิทธิภาพก่อนที่จะคิดเกี่ยวกับสิ่งเหล่านั้น

Jeremy: ดังนั้น ฉันจะแนะนำส่วนท้ายของสิ่งที่คุณเพิ่งพูดไปเป็นวิธีที่ดีในการนำไปสู่สิ่งนี้ เราไม่ควรพยายามปรับให้เหมาะสมก่อนเวลาอันควร เว้นแต่แน่นอนว่าการเพิ่มประสิทธิภาพเหล่านั้นสามารถทำได้อย่างรวดเร็วและง่ายดาย แต่ถ้าต้องใช้ความพยายามอย่างมากในการเพิ่มประสิทธิภาพตั้งแต่เนิ่นๆ เมื่อไม่มีปัญหาด้านประสิทธิภาพมากนัก ฉันขอเถียงว่า การแยกรหัสอาจเป็นสิ่งที่ไม่ต้องเกิดขึ้น คุณอาจจะโหลดฟังก์ชันนั้นไว้ล่วงหน้าก็ได้

Jeremy: แต่ยกตัวอย่างเช่น ฉันพูดถึงเรื่องนี้ในหนังสือ หากคุณมีการโต้ตอบที่มีมูลค่าสูงซึ่งขับเคลื่อนโดย JavaScript ชิ้นใหญ่ และสำหรับฉัน JavaScript ชิ้นใหญ่อาจหมายถึง 20 กิโลไบต์เพราะผ่านสายที่ถูกบีบอัดและนั่นอาจเป็นกลุ่ม JavaScript ขนาด 60 กิโลไบต์ จากนั้น หากคุณสามารถดึงสิ่งนั้นออกมาในบันเดิลหลักหรือบันเดิลใดๆ ของคุณได้ ไซต์ของคุณอาจกำลังจัดส่ง คุณจะช่วยเพิ่มประสิทธิภาพในการเริ่มต้น

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 paint API ฉันชอบ paint API มาก ฉันหมายความว่ามันมีอยู่เสมอในตัวของมันเอง…. ในแบบของมันเอง เนื่องจากบริบท 2D ของ canvas นั้นเป็นสิ่งที่มีอยู่แล้ว เพราะนั่นคือ… สำหรับผู้ที่ไม่รู้ตัว CSS pain API เป็นวิธีการที่คุณสามารถฝังบริบทแคนวาส 2 มิติและกำหนดพารามิเตอร์และควบคุมด้วย CSS ซึ่งเปิดโอกาสที่น่าสนใจมากมาย เช่น คุณสามารถสร้างภาพเคลื่อนไหวให้กับสิ่งต่าง ๆ ที่ ก่อนหน้านี้คุณไม่สามารถเคลื่อนไหวและสิ่งนั้นได้

Jeremy: และเมื่อเร็วๆ นี้ ฉันได้ทำการรีเฟรชบล็อก นั่นคือ… ฉันเป็นคนคลั่งไคล้ Final Fantasy ตัวยง เหมือน Final Fantasy II ที่ฉันเพิ่งเล่นซ้ำ ดังนั้น มี 15 ตัวในนั้นและ 16 ตัวจะออกมาในบางครั้ง แต่มันก็เป็นแนวย้อนยุค ดังนั้นฉันจึงใช้ CSS paint API เพื่อสร้างการสุ่มทั่วโลกโดยใช้ไทล์ต่างๆ จึงมีแม่น้ำและสิ่งต่างๆ ที่ชอบไหลผ่าน กระเบื้องหญ้าและต้นไม้ และอะไรแบบนั้น และการกำหนดพารามิเตอร์ให้เหมือนกับว่าผู้ใช้เข้าชมเว็บไซต์ของฉันในโหมดมืด... งานระบายสีนั้นจะแสดงราวกับว่าเป็นเวลากลางคืน มันจะมีแบบซ้อนทับกับของแบบนั้น

Jeremy: แต่ API การวาดภาพนั้นน่าทึ่งมาก ฉันต้องตะโกนบอก Tim Holman เขา ฉันเห็นเขาที่ JSConf Australia และเขาได้พูดคุยเกี่ยวกับงานศิลปะเชิงสร้างสรรค์ นั่นเป็นเพียงจริงๆ มันเหมือนทำให้ฉันสนใจ จากนั้น แซม ริชาร์ด ที่ CSSConf เมื่อวันก่อนพูดคุยเกี่ยวกับ CSS การวาดภาพ API เมื่อทั้งสองสิ่งนี้มารวมกันสำหรับฉัน มันก็เหมือนกับ "ว้าว นี่มันเจ๋งมาก" ดังนั้นฉันจึงทำสิ่งที่เรียกว่า Paintlets! มันเป็น Paintlets.Herokuapp.com หากคุณเข้าชมและ Chrome และคุณต้องไป โชคไม่ดีที่มันยังไม่รองรับอย่างดีเยี่ยม คุณสามารถเห็นงานศิลปะต่างๆ ที่สุ่มขึ้นมาแบบสุ่มๆ และ.. ใช่ ฉันเพิ่ง... นั่นคือสิ่งที่ฉันได้รับ ขอโทษด้วย เรื่องยาวเกี่ยวกับที่

ดริว : น่าทึ่งมาก เป็นความคิดที่ดี.

เจเรมี: ใช่ ใช่.

Drew: หากคุณผู้ฟังที่รักอยากฟัง Jeremy มากกว่านี้ คุณสามารถพบเขาบน Twitter ที่ซึ่งเขาคือ @malchata และค้นหางานเขียนของเขา วิดีโอ และโครงการต่างๆ บนเว็บไซต์ส่วนตัวของเขา jeremy.codes, Responsible JavaScript พร้อมใช้งานแล้วจาก A จองอพาร์ท และคุณสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ที่ ขอบคุณที่มาร่วมงานกับฉันในวันนี้ เจเรมี คุณมีคำพรากจากกันบ้างไหม?

Jeremy: ก้าวไปข้างหน้าและสร้างเว็บด้วยวิธีที่ดีที่สุดที่คุณทำได้ และพยายามจดจำผู้ใช้เอาไว้ นั่นเป็นมนต์ของฉันและฉันหวังว่าหนังสือเล่มนี้จะทำให้เรื่องนี้ติดใจ