Native และ PWA: ทางเลือก ไม่ใช่ผู้ท้าชิง!

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

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

ด้วย Progressive Web Apps (PWAs) ที่รุกล้ำเข้ามาในพื้นที่ของการพัฒนาแบบเนทีฟ ฉันคิดว่านี่อาจเป็นเวลาที่ดีที่จะถอยออกมาและทบทวนแนวทางทั้งสองนี้เพื่อสร้างผลิตภัณฑ์ ความหวังของฉันคือการที่เราทุกคนจะเดินจากไปพร้อมกับความสามารถในการมองเห็นจุดแข็งของแต่ละแนวทางอย่างชัดเจนโดยหวังว่าจะพบสิ่งที่เหมาะสมสำหรับผลิตภัณฑ์ที่เราสร้างขึ้น

การเปรียบเทียบอย่างรวดเร็วไฟ

ตั้งแต่เริ่มต้นมา ประสบการณ์บนเว็บก็ถูกนำมาเปรียบเทียบกับทุกอย่างตั้งแต่ซอฟต์แวร์เดสก์ท็อป ("แอปดั้งเดิม") ไปจนถึงซีดีรอมเชิงโต้ตอบ แฟลช และล่าสุด ไปจนถึงแอปบนอุปกรณ์เคลื่อนที่ แม้จะถูกประกาศว่าตายไปแล้วหลายครั้ง แต่เว็บก็ยังยืนกราน ในหลายกรณี มันมีอายุยืนกว่าผู้ถูกกล่าวหาว่าเป็นฆาตกร (RIP Flash)

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

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

เมื่อเทียบกับข้อได้เปรียบด้านประสิทธิภาพ การพัฒนาแบบเนทีฟมีการเข้าถึงคุณลักษณะของอุปกรณ์ (และรุ่นก่อนหน้า) ที่มากกว่า (และก่อนหน้า) เช่น NFC, Bluetooth, เซนเซอร์ตรวจจับความใกล้เคียงและแสงแวดล้อม และอื่นๆ เว็บเข้าถึงฟีเจอร์เหล่านี้ได้อย่างต่อเนื่องเช่นกัน แต่จะล้าหลังเสมอเนทีฟเพราะต้องพัฒนา API ดั้งเดิมก่อนที่เว็บจะเข้าถึงฟีเจอร์เหล่านี้ได้ และการทำให้เป็นมาตรฐานทั่วทั้งเบราว์เซอร์ต้องใช้เวลา

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

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

พนักงานบริการเป็นหนึ่งในสามหลักทางเทคนิคของ กปภ. อีกรายการหนึ่งคือ Web App Manifest แม้ว่าจะฟังดูน่าเบื่อเล็กน้อย แต่ Web App Manifest เป็นเครื่องมือที่ทรงพลังอย่างเหลือเชื่อที่ช่วยให้เว็บไซต์สามารถโฆษณาตัวเองเป็นแอปได้ รูปแบบไฟล์ JSON ที่ค่อนข้างตรงไปตรงมานี้ให้ข้อมูลมากมายเกี่ยวกับเว็บไซต์ที่อธิบาย และช่วยให้เบราว์เซอร์และระบบปฏิบัติการที่รู้จัก PWA ติดตั้งไซต์ได้ราวกับว่าเป็นซอฟต์แวร์ดั้งเดิม

ร้านแอปบางแห่งเริ่มจัดทำดัชนี PWA โดยใช้ไฟล์ Manifest เพื่อเติมข้อมูลรายการที่เกี่ยวข้อง จากมุมมองของผู้ใช้ PWAs ใน App Store ไม่ได้แตกต่างไปจากแอปดั้งเดิมที่อยู่รายรอบ สิ่งเหล่านี้สามารถติดตั้งได้ ถอนการติดตั้งไม่ได้ และยังสามารถเปิดเผยการตั้งค่าไปยังเครื่องมือการจัดการแอพของระบบปฏิบัติการพื้นฐาน นอกจากนี้ยังควรสังเกตด้วยว่า PWA ไม่จำเป็นต้องให้ผู้ใช้ติดตั้งไว้อย่างชัดเจนเพื่อใช้งาน เพราะพวกเขาอาศัยอยู่บนเว็บ

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

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

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

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

อย่างไรก็ตาม การพัฒนาแบบเนทีฟมีความโดดเด่นในด้านใด ก็คือการสร้างความมั่นใจในระดับคุณภาพที่สอดคล้องกันสำหรับ UI ที่สร้างขึ้นโดยใช้ SDK (Software Development Kits) Native SDK ส่วนใหญ่มีเครื่องมือสำหรับการทดสอบประสิทธิภาพ การออกแบบ ฟังก์ชันการทำงาน และอื่นๆ พวกเขายังรวมถึงรหัสต้นแบบ ระบบการออกแบบ และเครื่องมืออื่นๆ ที่ช่วยยกระดับข้อเสนอซอฟต์แวร์ดั้งเดิมโดยรวม แน่นอนว่ามีเครื่องมือที่คล้ายคลึงกันสำหรับเว็บ แต่พวกมันกระจัดกระจายอยู่ทั่วทั้งเว็บและไม่เป็นสากลในสภาพแวดล้อมการพัฒนาที่แตกต่างกันทั้งหมดที่ผู้คนใช้ในการสร้างเว็บไซต์ ไม่มีหน่วยงานเดียวที่กำหนดประสบการณ์การใช้เว็บที่มีคุณภาพและจัดหาเครื่องมือเพื่อสร้างประสบการณ์เหล่านั้น (แม้ว่าหลายๆ คนจะพยายามแล้วก็ตาม)

เมื่อพูดถึงการจัดหาพนักงานเพื่อพัฒนาผลิตภัณฑ์ การจ้างผู้ที่รู้วิธีสร้างสำหรับเว็บจะง่ายกว่าอย่างแน่นอน ขณะที่ฉันพิมพ์ ดัชนีภาษาการเขียนโปรแกรมในปัจจุบันจัดอันดับ JavaScript เป็นภาษาที่ได้รับความนิยมมากที่สุด โดยมี Java อยู่เบื้องหลัง C# อยู่ในอันดับที่ 5, HTML ในอันดับที่ 7, CSS ในอันดับที่ 9 และ Swift อยู่ในอันดับที่ 15 การอ้างอิงโยงดัชนีนี้แท็ก Stack Overflow โดยมีการเปลี่ยนแปลงบรรทัดในที่เก็บสาธารณะบน GitHub ดังนั้นจึงควรใช้เม็ดเกลือ แต่มีข้อบ่งชี้ที่ค่อนข้างชัดเจนว่าผู้คนจำนวนมากรู้จัก (และใช้เทคโนโลยี) เว็บ ในทางกลับกัน การค้นหาและจ้างนักพัฒนาเจ้าของภาษาที่มีความสามารถมักจะเป็นเรื่องยาก เพราะมีพวกเขาน้อยกว่าและเป็นที่ต้องการสูง

ความสามารถที่ขาดแคลนหมายความว่าคุณมีแนวโน้มที่จะต้องจ่ายเงินมากขึ้นสำหรับการพัฒนาโดยเจ้าของภาษา ทุกโครงการมีความแตกต่างกันอย่างเห็นได้ชัดและมีคุณสมบัติและข้อกำหนดที่แตกต่างกัน แต่สามารถอธิบายให้เห็นถึงต้นทุนการพัฒนาโดยเฉลี่ยเป็นการเปรียบเทียบได้ Comentum แนะนำว่าการสร้างเว็บแอปขนาดปานกลางมีตั้งแต่ 10,000 ถึง 150,000 เหรียญสหรัฐ ในแง่พื้นฐานแล้ว Appster ประมาณการว่าโปรเจ็กต์แอปบนอุปกรณ์เคลื่อนที่ขนาดปานกลางมีราคาระหว่าง 110,000 ดอลลาร์สหรัฐ ถึง 305,000 ดอลลาร์สหรัฐในการสร้าง อาจปลอดภัยที่จะถือว่าโปรเจ็กต์แบบเนทีฟมักจะมีราคาสูงเป็นสองเท่าในการพัฒนาเป็นโปรเจ็กต์บนเว็บ และนั่นก็แล้วแต่แพลตฟอร์ม แอพที่มาพร้อมเครื่องมักจะใช้เวลานานกว่าในการพัฒนา

เป็นที่น่าสังเกตว่ามีตัวเลือกสำหรับการสร้างซอฟต์แวร์เนทีฟโดยใช้เทคโนโลยีเว็บโดยไม่ต้องสร้าง PWA กรอบงานเช่น React Native, PhoneGap, Ionic และ Appcelerator Titanium ช่วยให้คุณสร้างโค้ดเนทีฟจาก HTML, CSS และ JavaScript การใช้หนึ่งในเครื่องมือเหล่านี้สามารถลดต้นทุนด้านบุคลากรและการพัฒนาของคุณ เมื่อเทียบกับการจ้างทีมนักพัฒนาที่เป็นเจ้าของภาษา แต่ในแง่ของการเข้าถึงคุณสมบัติอุปกรณ์ โครงการของคุณจะถูกจำกัดเฉพาะที่เฟรมเวิร์กได้นำไปใช้ วางแผนตามนั้น

เมื่อพัฒนาแอปแล้ว คุณต้องพิจารณาต้นทุนการบำรุงรักษาอย่างต่อเนื่องของแอปหรือแอปดังกล่าวด้วย ในการตอบแบบสำรวจที่ดำเนินการโดย Clutch Dom & Tom แนะนำให้ตั้งงบประมาณ 50% ของราคาเริ่มต้นของผลิตภัณฑ์ในปีแรก, 25% ในปีที่สอง และระหว่าง 15-25% ทุกปีหลังจากนั้น

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

มาดูโครงการสมมติสองสามโครงการเพื่อนำความแตกต่างระหว่างการพัฒนาสำหรับ Native และ PWA ให้ชัดเจนยิ่งขึ้น

โปรเจ็กต์ #1: แอพเนทีฟที่มีอยู่

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

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

หากการแทนที่แอพเนทีฟที่มีอยู่ด้วย PWA ดูเหมือนคิดไม่ถึงสำหรับคุณ ให้พิจารณาสิ่งนี้: Starbucks และ Twitter กำลังสำรวจแนวคิดนี้อยู่แล้ว

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

โครงการ #2: แอปข้ามแพลตฟอร์มที่มีอยู่

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

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

โครงการ #3: ผลิตภัณฑ์ข้ามแพลตฟอร์มใหม่

หากคุณกำลังเริ่มต้นโครงการใหม่ที่มุ่งเป้าไปที่มากกว่าหนึ่งแพลตฟอร์ม การสร้างและบำรุงรักษามันไว้ในที่เดียวเนื่องจาก PWA ควรอยู่บนโต๊ะอย่างแน่นอน ขึ้นอยู่กับงบประมาณและพนักงานของคุณ มีแนวโน้มที่จะยืดงบประมาณของคุณให้ไกลที่สุด อย่างไรก็ตาม หากผลิตภัณฑ์ของคุณต้องการการเชื่อมต่อโดยตรงกับฮาร์ดแวร์หรือระบบปฏิบัติการ คุณยังอาจต้องใช้งานแบบเนทีฟ แต่ก่อนที่คุณจะไปยังเส้นทางนั้น ให้เขียนรายการความต้องการทั้งหมดของคุณ แล้วตรวจสอบว่าเว็บทำอะไรได้บ้าง (และสิ่งที่ทำไม่ได้) อย่าลืมตรวจสอบการสนับสนุนในเบราว์เซอร์มากกว่าหนึ่งตัวด้วย

โครงการ #4: ผลิตภัณฑ์ที่เน้นไฮเปอร์ใหม่

หากคุณกำลังสร้างผลิตภัณฑ์ใหม่และส่วนหนึ่งของจุดประสงค์ทั้งหมดของผลิตภัณฑ์นั้นก็คือการเชื่อมต่ออย่างลึกซึ้งกับแพลตฟอร์มเฉพาะ ทุกวิถีทาง ให้สร้างสำหรับแพลตฟอร์มนั้น ตัวอย่างเช่น หากผลิตภัณฑ์ของคุณใช้แพลตฟอร์มข้อความของ Apple หรือการผสานรวมกับ HomeKit ทุกวิถีทาง ให้สร้างสำหรับ iOS และ/หรือ macOS ใน Swift หากผลิตภัณฑ์ของคุณตอบสนองความต้องการของผู้ใช้ได้ดีที่สุดผ่านวิดเจ็ตหรือคุณกำลังสร้างตัวเรียกใช้งานแบบกำหนดเอง คุณควรสร้าง Android ขึ้นมา และคุณจะต้องใช้ Java

อย่างไรก็ตาม คุณลักษณะพื้นเมืองทั้งหมดไม่ใช่สวนที่มีกำแพงล้อมรอบ แม้ว่า Alexa ของ Amazon, Siri ของ Apple และ Google Assistant ต่างก็ต้องการโค้ดเนทีฟ (หรือ JSON API) เพื่อรวมเข้ากับแอปของคุณ Cortana ของ Microsoft ที่น่าสนใจจะเปิดใช้งานเสียง PWA ของคุณโดยใช้เฉพาะไฟล์ XML ที่เชื่อมโยงจากส่วน head ของ HTML ของคุณ บางทีคนอื่นอาจจะเดินตาม

กปภ. หรือ พื้นเมือง? ทางเลือกเป็นของคุณ

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

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

ทรัพยากรที่เกี่ยวข้องกับการประปาส่วนภูมิภาค

• ช่างก่อสร้าง กปภ
  เครื่องมือสร้างเว็บไซต์ถึง PWA 3 ขั้นตอนพร้อมคำแนะนำและสูตรอาหารที่เป็นประโยชน์ นอกจากนี้ยังช่วยให้คุณสามารถเปลี่ยน PWA ของคุณให้เป็นแอปพื้นฐานที่ติดตั้งได้สำหรับ Windows, Android และ iOS
• แผนที่ถนนโปรเกรสซีฟสำหรับเว็บแอปโปรเกรสซีฟของคุณ
  Jason Grigsby กล่าวถึงวิธีที่ทีมของเขาเริ่มผสมผสานแง่มุมต่างๆ ของ PWA เข้ากับเว็บไซต์ของพวกเขาในช่วงหลายเดือน แสดงให้เห็นอย่างชัดเจนว่าสามารถเพิ่มฟีเจอร์ต่างๆ ได้ทีละน้อยได้อย่างไร
• ใช่ โครงการเว็บนั้นควรเป็น PWA
  ภาพรวมของโอกาส UX (และความเสี่ยง) ของ PWAs เขียนโดยคุณอย่างแท้จริง
• เว็บแอปแบบโปรเกรสซีฟบน MDN
  ศูนย์กลางสำหรับข้อมูลทางเทคนิคทั้งหมดที่คุณต้องการทราบเกี่ยวกับคุณลักษณะของ กปภ. ที่มีคุณภาพ
• เว็บทำอะไรได้บ้างวันนี้
  ดู API ที่อุปกรณ์ ระบบปฏิบัติการ และเบราว์เซอร์ของคุณรองรับ สิ่งที่คุณพบอาจทำให้คุณประหลาดใจ
• ฉันสามารถใช้
  ฐานข้อมูลที่สรุปว่า API และคุณลักษณะใดบ้างที่มีอยู่ในเบราว์เซอร์หลักๆ ทุกตัว และวิธีที่การสนับสนุนนั้นวัดเทียบกับเบราว์เซอร์ที่ผู้คนใช้งานจริง นอกจากนี้ยังสามารถให้มุมมองที่ยอดเยี่ยมในการย้อนเวลาเพื่อดูว่าคุณลักษณะบางอย่างที่เข้ากันได้แบบย้อนหลังเป็นอย่างไร