กรณีศึกษาเกี่ยวกับความรู้สึกที่ถูกจำกัดโดยเว็บ

หรือบทความที่ร้อยบ่นเกี่ยวกับการพัฒนาเว็บ

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

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

จากนั้น Google IO 2018 ก็มาถึง และฉันก็บังเอิญไปพบกับ "วิดีโอที่ยอดเยี่ยม" ของ Jeff Posnick ใน PWA หลายหน้า แนวคิดในการใช้ความสามารถในการสตรีมของเบราว์เซอร์และการเขียน JavaScript สากล เพื่อให้คุณสามารถสร้าง HTML จากเซิร์ฟเวอร์สำหรับการโหลดครั้งแรกหรือเป็นทางเลือก จากนั้นจึงสร้างจากพนักงานบริการ ดูเหมือนเป็นแนวคิดใหม่จริงๆ ที่จะทำให้ แอพที่รวดเร็วและพร้อมใช้งาน ทั้งหมดนี้ใช้ไลบรารี เครื่องมือบรรทัดคำสั่ง หรือมีขั้นตอน/การกำหนดค่าการสร้างที่ซับซ้อนน้อยมาก

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

หลังจากดูวิดีโอสองสามครั้งและอ่านบล็อกเกี่ยวกับ สตรีมมิ่ง ฉันรู้สึกว่าในที่สุดฉันก็พบการออกแบบที่ฉันกำลังมองหาในที่สุด

โครงการ

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

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

ปัญหา

จาวาสคริปต์สากล

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

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

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

ดอมพาร์เซอร์

ขั้นตอนแรกที่แท้จริงในโครงการนี้เกี่ยวข้องกับการแยกวิเคราะห์ฟีด RSS ของพอดแคสต์ที่เลือกเพื่อรับข้อมูลตอน เบราว์เซอร์มีอินเทอร์เฟซ "DOMParser" ที่ทำให้แยกวิเคราะห์ XML ได้ง่าย น่าเสียดายที่ Node.js ไม่มีสิ่งใดในไลบรารีมาตรฐาน หลังจากค้นหาไลบรารีบางแห่งบน NPM ฉันพบหนึ่งรายการที่มี API เดียวกันกับ DOMParser ดังนั้น เมื่อผู้ใช้ค้นหาพอดแคสต์ ฉันจะดึงฟีด แยกวิเคราะห์ สร้าง HTML และสตรีมข้อมูลนั้นไปยังผู้ใช้ ยอดเยี่ยม! ตอนนี้ฉันแค่ต้องทำจากพนักงานบริการ

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

เนื่องจากฉันกำลังเขียน JavaScript สากล ฉันคิดว่าการเสียบโค้ดฝั่งเซิร์ฟเวอร์ของฉันคงไม่ใช่ปัญหา แต่คุณอาจเห็นว่าสิ่งนี้กำลังดำเนินไปอย่างไร คุณไม่สามารถทำสิ่งที่เกี่ยวข้องกับ DOM ในพนักงานบริการได้ นอกจากนี้ ดูเหมือนว่า DOMParser ที่ไม่ปลอดภัยสำหรับเธรดนั้นเป็น "ปัญหาเช่นกัน" ฉันมองหาไลบรารีภายนอกเล็กน้อยเพื่อแยกวิเคราะห์ XML ที่จะใช้งานได้กับพนักงานบริการ (ดูเหมือนว่าไลบรารีที่ฉันใช้ฝั่งเซิร์ฟเวอร์จะไม่ทำงาน) แต่ไม่พบสิ่งใดที่มี API เดียวกัน บางทีฉันอาจจะจู้จี้จุกจิกเกินไป แต่ฉันตัดสินใจยอมแพ้ ณ จุดนี้ เพราะในขณะที่ฉันกำลังจัดการกับเรื่องนี้ ปัญหาอื่นที่ใหญ่กว่านั้นก็ยังคงผุดขึ้นมาซึ่งทำให้ฉันรู้สึกว่าโครงการนี้ไร้ประโยชน์

คอร์ส

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

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

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

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

บทสรุป

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

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

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