Smashing Podcast ตอนที่ 21 กับ Chris Ferdinandi: แนวทางปฏิบัติที่ดีที่สุดสมัยใหม่ไม่ดีสำหรับเว็บหรือไม่?

วันนี้ เรากำลังถามว่าแนวทางปฏิบัติที่ดีที่สุดสมัยใหม่ส่งผลเสียต่อเว็บหรือไม่ กรอบงานสมัยใหม่พาเราไปสู่เส้นทางที่ผิดหรือไม่? ฉันพูดคุยกับ Chris Ferdinandi ผู้เชี่ยวชาญด้าน Lean Web เพื่อหาคำตอบ

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

• หน้าของ Chris พร้อมลิงก์และหมายเหตุสำหรับพอดแคสต์
• หนังสือเว็บแบบลีน
• Chris Ferdinandi บนเว็บ
• คริสในทวิตเตอร์
• วานิลลา JavaScript พอดคาสต์

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

• “การแปล Wireframes การออกแบบเป็น HTML/CSS ที่เข้าถึงได้”
  โดย Harris Schneiderman
• “การสร้างแอพเดสก์ท็อปด้วยอิเล็กตรอนและ Vue”
  โดย Timi Omoyeni
• “เทคนิค CSS สมัยใหม่เพื่อปรับปรุงความชัดเจน”
  โดย Edoardo Cavazza
• “วิธีการใช้องค์ประกอบที่มีสไตล์ในการตอบสนอง”
  โดย Adebiyi Adedotun Lukman
• “วิธีการสร้าง Porsche 911 ด้วย Sketch”
  โดย นิโคลา ลาซาเรวิช

การถอดเสียง

Drew McLellan: เขาเป็นผู้แต่ง Vanilla JS Pocket Guide Series ผู้สร้าง Vanilla JS Academy Training Program และโฮสต์ของ Vanilla JS Podcast เขาพัฒนาจดหมายข่าว Tips ซึ่งนักพัฒนาเกือบ 10,000 คนอ่านทุกวันธรรมดา เขาสอนนักพัฒนาในองค์กรต่างๆ เช่น Chobani และ The Boston Globe และปลั๊กอิน JavaScript ของเขาถูกใช้โดยองค์กรต่างๆ เช่น Apple และ Harvard Business School ที่สำคัญที่สุด เขาชอบช่วยให้ผู้คนเรียนรู้ Vanilla JavaScript เรารู้ว่าเขาต้องการเลือก Vanilla JavaScript มากกว่าเฟรมเวิร์ก แต่คุณรู้หรือไม่ว่าเขาเคยถูกเลือกให้เข้าร่วมกลุ่มตำรวจว่าเป็นคนที่มีแนวโน้มน้อยที่สุดที่จะก่ออาชญากรรม เพื่อนที่ยอดเยี่ยมของฉัน ได้โปรดต้อนรับคริส เฟอร์ดินานดี สวัสดีคริส คุณเป็นอย่างไรบ้าง?

Chris Ferdinandi: โอ้ฉันยอดเยี่ยมมาก ขอบคุณที่มีฉัน

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

คริส : ครับ มากด้วย

Drew: ทำไมคุณไม่จัดฉากให้เราดูล่ะ? เมื่อเราพูดถึง Lean Web ปัญหาที่เราพยายามแก้ไขคืออะไร?

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

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

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

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

คริส: ครับ.

Drew: คนที่เคยครอบคลุม Full Stack จากนั้นเราแบ่งออกเป็นส่วนหน้าและส่วนหลัง จากนั้นส่วนหน้านั้นก็แยกออกเป็นผู้ที่พัฒนา CSS หรือ JavaScript จากนั้นใน JavaScript ก็มีความเชี่ยวชาญมากขึ้น บางคนอาจคิดว่าตัวเองและทำตลาดตัวเองในฐานะนักพัฒนา React หรือนักพัฒนา Angular และอัตลักษณ์และมุมมองทั้งหมดของพวกเขาขึ้นอยู่กับเฟรมเวิร์กเฉพาะที่พวกเขามีทักษะสูง การพึ่งพาเฟรมเวิร์กนี้เป็นแกนหลักของงานบนเว็บของเราหรือไม่ สิ่งที่ไม่ดี?

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

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

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

คริส: ครับ.

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

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

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

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

Chris: ไม่ใช่ทั้งหมด แต่ส่วนสำคัญของน้ำหนักนั้นอุทิศให้กับสิ่งนี้ที่เรียกว่า DOM เสมือน มีทางเลือกอื่นที่ใช้ API หรือแนวทางที่คล้ายกัน สำหรับ React คุณมี Preact ซึ่งมีขนาด 2.5 กิโลไบต์หรือประมาณ 3 กิโลไบต์แทนที่จะเป็น 30 ซึ่งเป็นขนาดหนึ่งในสิบ สำหรับ Vue คุณมี Alpine JS แทน ซึ่งมีขนาดประมาณ 7 กิโลไบต์ ยังเล็กกว่าอย่างเห็นได้ชัด ความแตกต่างที่สำคัญระหว่างสิ่งเหล่านั้นกับคู่หูของพวกเขาคือพวกเขาได้กำจัด DOM เสมือน พวกเขาอาจทิ้งวิธีการหนึ่งหรือสองวิธี แต่โดยทั่วไป มันเป็นแนวทางเดียวกันและเป็น API ประเภทเดียวกันในการทำงานกับโค้ด และมีขนาดเล็กกว่ามาก

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

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

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

คริส: แน่นอน แน่นอน

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

Drew: สำหรับพวกเราที่ไม่คุ้นเคย เมื่อคุณพูดบางอย่างเช่น Preact จะดร็อป Virtual DOM และทำให้ทุกอย่างเล็กลงมาก DOM เสมือนนั้นให้อะไรกับเรา

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

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

Chris: สิ่งที่ UI ตามรัฐที่คุ้มค่ากับน้ำหนักของมันจะถูกนำไปใช้บางส่วนสำหรับ DOM diffing โดยที่พวกเขากล่าวว่า "นี่คือสิ่งที่ UI ควรมีลักษณะเช่นนี้ นี่คือสิ่งที่ดูเหมือนตอนนี้ใน DOM ต่างกันอย่างไร?” และจะไปเปลี่ยนแปลงสิ่งเหล่านั้น มันทำสิ่งที่คุณจะทำอย่างมีประสิทธิภาพเพียงแค่อัปเดต UI ด้วยตนเอง แต่มันทำเพื่อคุณภายใต้ประทุน คุณพูดได้เลยว่า “นี่คือสิ่งที่ฉันต้องการให้เป็นแบบนั้น” จากนั้นไลบรารีหรือเฟรมเวิร์กก็คิดออก

Chris: สิ่งเล็กๆ อย่าง Preact หรือ Alpine พวกเขากำลังทำอย่างนั้นโดยตรง พวกเขากำลังแปลงสตริงที่คุณระบุ UI ที่ควรจะเป็นองค์ประกอบ HTML จากนั้นพวกเขากำลังเปรียบเทียบแต่ละองค์ประกอบกับชิ้นส่วนที่สอดคล้องกันใน DOM ที่แท้จริง เมื่อคุณลงเอยด้วย UI ที่ใหญ่ขึ้นเรื่อยๆ อาจมีนัยเกี่ยวกับประสิทธิภาพเนื่องจากการสืบค้น DOM ซ้ำแล้วซ้ำเล่าจะมีราคาแพง หากคุณต้องการทราบประเภทของอินเทอร์เฟซที่สิ่งนี้กลายเป็นปัญหา ให้คลิกขวาและตรวจสอบองค์ประกอบบนปุ่ม "รายการโปรด" บน Twitter หรือปุ่ม "ถูกใจ" บน Facebook และดูการซ้อน div ที่นำคุณไปยังองค์ประกอบนั้น มันลึกมาก มันเหมือนกับ divs หลายสิบตัวซ้อนกันหนึ่งตัวในที่อื่นสำหรับทวีตเดียวนั้น

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

Chris: ความท้าทายของมันคือ… ความแตกต่างระหว่าง Preact และ React คือ 27 กิโลไบต์ ก่อนที่คุณจะแตกไฟล์ทั้งหมดลงใน codewave จริงของมัน เวลาในการดาวน์โหลดและแตกไฟล์และคอมไพล์ดิบเพียงอย่างเดียวสามารถเพิ่มเวลาแฝงเล็กน้อยให้กับการโหลดเริ่มต้นบน UI นั่นจะยิ่งเด่นชัดขึ้นหากผู้ใช้ของคุณไม่ได้ใช้อุปกรณ์รุ่นล่าสุดจาก Apple แม้แต่อุปกรณ์ Android เมื่อสองสามปีที่แล้ว หรือฟีเจอร์โฟน หรือถ้าคุณมีผู้คนในประเทศกำลังพัฒนา จริงๆ แล้ว… เวลาที่ต้องไปต่อจะช้าลง และยิ่งไปกว่านั้น เวลาโต้ตอบจริงจะช้าลงเนื่องจากสิ่งที่เป็นนามธรรมเพิ่มเติม

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

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

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

คริส: ครับ ฉันไม่เห็นด้วย ฉันไม่มีอะไรจะอธิบายเพิ่มเติมนอกจาก… ฉันเดาว่าอาจจะใช่ แต่ไม่ใช่จริงๆ แม้จะมี Bundler คุณก็ยังต้องการ React core นั้น แม้ว่าจะมีการรวมกลุ่มเข้าด้วยกัน แต่ก็ยังใหญ่กว่าการใช้ Preact

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

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

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

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

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

Drew: แน่นอน ฉันเป็น… ฉันเริ่มรับ React เมื่อต้นปี 2020 เพิ่มทักษะนั้นในชุดทักษะของฉัน ฉันทำมาเกือบเจ็ดเดือนแล้ว ฉันต้องบอกว่าส่วนหนึ่งที่ฉันมั่นใจน้อยที่สุดคือการตั้งค่าเครื่องมือในการเริ่มต้นโครงการ

Drew: ดูเหมือนว่ามีงานหนักมากที่จะได้บางอย่างมาที่ Hello World และยังมีอะไรอีกมากที่คุณต้องรู้เพื่อเตรียมมันให้พร้อมสำหรับการผลิต นั่นจะทำให้การพัฒนายากขึ้นในการเริ่มต้น หากสิ่งนี้ถูกหยิบยกขึ้นมาเป็นสิ่งที่คุณควรทำในปี 2020 เพื่อเรียนรู้ที่จะเป็นนักพัฒนาเว็บ คนที่มาใหม่จะมีปัญหาจริง มันจะเป็นอุปสรรคจริง ๆ ในการเข้าใช่ไหม?

คริส: แน่นอน ส่วนอื่น ๆ ที่นี่คือนักพัฒนา JavaScript ไม่ได้เป็นเพียงคนเดียวที่ทำงานบนฐานรหัสหรือมีส่วนร่วมในวิธีที่มีความหมายต่อฐานรหัสนั้น ยิ่งเราทำให้การรู้ JavaScript เป็นข้อกำหนดสำหรับการทำงานกับฐานโค้ดมากเท่าใด โอกาสที่คนเหล่านั้นจะสามารถเข้าร่วมในโครงการได้จริงก็จะยิ่งน้อยลงเท่านั้น

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

Chris: ในปี 2018 Rian Rietveld หัวหน้าที่ปรึกษาด้านการเข้าถึงข้อมูลของ WordPress ซึ่งผมเกือบเป็นคนฆ่าชื่อนั้น… เธอลาออกจากตำแหน่งอย่างเปิดเผยและได้บันทึกว่าทำไมในบทความที่มีรายละเอียดจริงๆ แก่นของปัญหาคือเธอและทีมของเธอได้รับมอบหมายให้ตรวจสอบตัวแก้ไขนี้เพื่อให้แน่ใจว่าจะสามารถเข้าถึงได้ WordPress ประกอบด้วยตอนนี้ 30% ของเว็บ เป้าหมายของพวกเขาคือการทำให้การเผยแพร่เป็นประชาธิปไตย ดังนั้นการเข้าถึงจึงเป็นส่วนสำคัญอย่างยิ่ง ควรเป็นส่วนสำคัญของโครงการเว็บใดๆ แต่สำหรับพวกเขาโดยเฉพาะ มันสำคัญมาก งานทั้งหมดของทีมของเธอคือการทำให้แน่ใจว่า... งานทั้งหมดของทีมของเธอคือทำให้แน่ใจว่าผู้แก้ไขนี้จะสามารถเข้าถึงได้ แต่เนื่องจากเธอหรือใครก็ตามในทีมของเธอไม่มีประสบการณ์เกี่ยวกับ React และเนื่องจากพวกเขาไม่พบอาสาสมัครในชุมชนการช่วยการเข้าถึงด้วยประสบการณ์นั้น มันจึงทำให้เธอและทีมของเธอทำงานได้ยาก

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

Chris: ในเดือนพฤษภาคมปี 2019 ประมาณหนึ่งปีหลังจากที่ Rian ลาออก มีการตรวจสอบการช่วยสำหรับการเข้าถึงอย่างละเอียดใน Gutenburg รายงานฉบับเต็มมี 329 หน้า บทสรุปสำหรับผู้บริหารเพียงอย่างเดียวคือ 34 หน้า บันทึกข้อบกพร่องที่เกี่ยวข้องกับการช่วยสำหรับการเข้าถึง 91 รายการโดยละเอียด สิ่งเหล่านี้หลายอย่างจริงๆ… ฉันไม่ต้องการที่จะเรียกมันว่าผลไม้แขวนง่าย ๆ แต่ส่วนมากเป็นสิ่งพื้นฐานที่ทีมของ Rian สามารถแก้ไขได้และจะทำให้นักพัฒนามีอิสระในการมุ่งเน้นไปที่การพัฒนาคุณสมบัติ ดูเหมือนว่าพวกเขาจะลงเอยด้วยการใช้เวลามากในการพัฒนาคุณลักษณะและผลักดันสิ่งนี้ออกไปในภายหลัง แต่ทีมนั้นสำคัญมากสำหรับโปรเจ็กต์ และจู่ๆ พวกเขาก็ถูกล็อกออกจากกระบวนการเนื่องจากทางเลือกทางเทคนิค

Chris: Alex Russell เป็นผู้พัฒนาในทีม Chrome เขาเขียนบทความนี้เมื่อสองสามปีก่อนโดยใช้ชื่อว่า The Developer Bait and Switch ซึ่งเขาได้พูดถึงข้อโต้แย้งเกี่ยวกับเฟรมเวิร์ก แนวคิดที่ว่าเครื่องมือเหล่านี้ช่วยให้คุณเคลื่อนไหวได้เร็วขึ้น และด้วยเหตุนี้ คุณจึงสามารถทำซ้ำได้เร็วขึ้นและมอบประสบการณ์ที่ดีขึ้น เป็นแนวคิดที่ว่าประสบการณ์นักพัฒนาซอฟต์แวร์ที่ดีขึ้นหมายถึงประสบการณ์ผู้ใช้ที่ดีขึ้น ฉันคิดว่านี่เป็นตัวอย่างที่ชัดเจนมากว่าการโต้แย้งนั้นไม่ได้เป็นไปตามที่ผู้คนเชื่อเสมอไป เป็นประสบการณ์ที่ดีกว่าสำหรับบางคน ไม่ใช่สำหรับทุกคน

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

Chris: เมื่อสแต็กง่ายขึ้น คนจากหลากหลายสาขาวิชาจะเข้าร่วมในกระบวนการพัฒนาได้ง่ายขึ้น ฉันคิดว่านั่นเป็นความเสียหายต่อทั้งสิ่งที่เราสร้างและชุมชนโดยรวม เมื่อไม่เป็นเช่นนั้นอีกต่อไป

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Drew: ฉันคิดว่าถูกต้องแล้วที่แพลตฟอร์มเว็บจะเคลื่อนไหวช้าและระมัดระวัง คุณคิดว่าถ้าห้าปีที่แล้ว เราทุกคนใส่ JavaScript Carousels บนหน้าเว็บของเรา พวกเขาอยู่ทุกที่ ทุกคนใช้ JavaScript Carousels หากแพลตฟอร์มของเว็บได้กระโดดและใช้โซลูชัน Carousel เพื่อตอบสนองความต้องการดังกล่าว มันก็จะไม่ถูกนั่งอยู่ที่นั่นโดยไม่มีใครใช้ เพราะผู้คนจะไม่ทำอย่างนั้นกับ Carousels อีกต่อไป เพราะมันเป็นแค่แฟชั่น เทรนด์การออกแบบ ในการรับมือและหยุดตัวแพลตฟอร์มให้บวมและกลายเป็นปัญหาที่ต้องแก้ไข แพลตฟอร์มต้องเคลื่อนไหวอย่างมั่นคงมากขึ้น The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

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. It doesn't have to be that way.

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 เพราะช่วยให้คุณเขียน HTML ใน JavaScript ได้อย่างราบรื่นยิ่งขึ้น แต่เรายังมีเทมเพลตตัวอักษรใน Vanilla JavaScript ที่มอบความสะดวกในระดับเดียวกันโดยไม่ต้องพึ่งพาเพิ่มเติม HTML เองสามารถแทนที่หลายสิ่งหลายอย่างที่เคยต้องใช้ JavaScript ซึ่งน่าทึ่งมาก

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

คริส: ในด้าน CSS ปลั๊กอิน Vanilla JS ที่ได้รับความนิยมมากที่สุดของฉันคือไลบรารีนี้ที่ให้คุณเลื่อนดูลิงก์สมอเคลื่อนไหวลงไปได้ มันใหญ่มาก. เป็นโค้ดที่ยากที่สุดที่ฉันเคยเขียนมา และตอนนี้มันถูกแทนที่ด้วย CSS บรรทัดเดียว พฤติกรรมการเลื่อนที่ราบรื่น มันมีประสิทธิภาพมากขึ้น มันง่ายกว่าในการเขียน ปรับเปลี่ยนพฤติกรรมได้ง่ายขึ้น เป็นเพียงวิธีแก้ปัญหาโดยรวมที่ดีกว่า

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

Chris: ในสถานการณ์ที่มันไม่สมจริงสำหรับคุณ ซึ่งคุณต้องการ JavaScript มากกว่านี้ คุณต้องมีไลบรารีบางประเภท บางทีอาจพิจารณาวิธีการที่มีขนาดเล็กลงและเป็นโมดูลมากขึ้นก่อน แทนที่จะมองหายักษ์ใหญ่ของอุตสาหกรรม แทนที่จะเป็น React Preact จะใช้งานได้หรือไม่ แทนที่จะเป็นเชิงมุม… ฉันหมายถึงแทนที่จะเป็น Vue Alpine JS จะทำงานได้หรือไม่ นอกจากนี้ยังมีพรีคอมไพเลอร์ล่วงหน้าที่น่าสนใจจริงๆ ซึ่งตอนนี้เรียกว่า Svelt ซึ่งให้ประสบการณ์เหมือนเฟรมเวิร์ก จากนั้นจึงคอมไพล์โค้ดทั้งหมดของคุณเป็น Vanilla JavaScript ดังนั้น คุณจะได้ชุดรวมเล็ก ๆ เหล่านี้ที่มีเพียงสิ่งที่คุณต้องการและไม่มีอะไรอื่น แทนที่จะเป็น CSS และ JavaScript คุณสามารถใส่ CSS linter ของบุคคลที่สามที่จะเปรียบเทียบ HTML ของคุณกับ CSS ของคุณและดึงสิ่งที่หลงเหลืออยู่ในนั้นโดยบังเอิญได้หรือไม่? วิธีอื่นในการเขียน CSS ของคุณ เช่น CSS เชิงวัตถุโดย Nicole Sullivan จะทำงานแทนหรือไม่ เราไม่ได้พูดถึงเรื่องนั้นเลยจริงๆ แต่มันเป็นสิ่งที่เจ๋งจริงๆ ที่ผู้คนควรลองดู

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

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

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

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

Chris: แต่ฉันยังได้จัดทำหน้าพิเศษสำหรับผู้ฟัง Smashing Podcast ที่ gomakethings.com/smashingpodcast อีกด้วย เพราะฉันมีความคิดสร้างสรรค์มากในการตั้งชื่อสิ่งต่างๆ ซึ่งรวมถึงแหล่งข้อมูลมากมายนอกเหนือจากหนังสือ เกี่ยวกับสิ่งที่เราพูดถึงในวันนี้ มันเชื่อมโยงกับเทคนิคต่างๆ มากมายที่เรากล่าวถึง บทความอื่น ๆ ที่ฉันเขียนซึ่งเจาะลึกเข้าไปในบางหัวข้อเหล่านี้และขยายความคิดของฉันอีกเล็กน้อย หากผู้คนต้องการเรียนรู้เพิ่มเติม นั่นอาจเป็นจุดเริ่มต้นที่ดีที่สุด

ดรูว์: เยี่ยมมาก ขอขอบคุณ. ฉันได้เรียนรู้ทุกอย่างเกี่ยวกับ Lean Web ช่วงนี้คุณเรียนรู้อะไรไปบ้าง คริส?

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

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

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

Drew: ฉันเป็นนักพัฒนาเว็บมา 22, 23 ปีแล้ว และยังต้องให้ Google คุณสมบัติต่างๆ สำหรับ Flexbox ทุกครั้ง แม้ว่าฉันจะใช้สิ่งนั้นมา 23 ปีแล้ว แต่ใช่ บางอย่างก็แค่… อาจจะมีมากกว่านั้นเมื่อฉันโตขึ้น

คริส: ครับ จริงๆ แล้ว ฉันลงเอยด้วยการสร้างเว็บไซต์ทั้งหมดที่ฉันใช้ Google ซ้ำแล้วซ้ำเล่า เพื่อให้มีการอ้างอิงการคัดลอกและวางที่ง่ายกว่า เพราะนั่นง่ายกว่า Googling

Drew: นั่นไม่ใช่ความคิดที่แย่

คริส : นั่นแหละที่ฉันขี้เกียจ ฉันจะสร้างเว็บไซต์ทั้งหมดเพื่อช่วยตัวเองให้เหมือนกับ Google สามวินาที

ดรูว์: หากคุณผู้ฟังต้องการทราบข้อมูลเพิ่มเติมจากคริส คุณสามารถหาหนังสือของเขาได้ทางเว็บที่ leanweb.dev และจดหมายข่าวเรื่องเคล็ดลับสำหรับนักพัฒนาของเขา และอื่นๆ ที่ gomakethings.com Chris อยู่บน Twitter ที่ Chris Ferdinandi และคุณสามารถดูพอดแคสต์ของเขาได้ที่ vanillajspodcast.com หรือที่ใดก็ตามที่คุณได้รับพอดแคสต์เป็นประจำ ขอบคุณที่มาร่วมงานกับเราในวันนี้ คริส คุณมีคำพรากจากกันบ้างไหม?

Chris: ไม่ ขอบคุณมากที่มีฉัน Drew ฉันมีเวลาที่ยอดเยี่ยมอย่างแน่นอน งานนี้สนุกมาก ฉันซาบซึ้งมากที่มีโอกาสมาสนทนา