เปลี่ยนแอปเนทีฟอายุ 13 ปีไปสู่ React Native
(ridicorp.com)เรื่องราวประสบการณ์ที่ Ridibooks ได้พบระหว่างกระบวนการเปลี่ยนจากแอปเนทีฟไปเป็น React Native
- เหตุผลที่เลือก React Native
-
เดิมทีผู้ใช้ค้นหาคอนเทนต์และชำระเงินบนเว็บ แล้วใช้แอปเป็นตัวอ่าน แต่ได้ตัดสินใจนำฟังก์ชันค้นหาและชำระเงินมาไว้ในแอปด้วย เพื่อรับมือกับการเปลี่ยนแปลงได้รวดเร็วและบรรลุเป้าหมายภายในเวลาที่กำหนด จึงตัดสินใจนำเทคโนโลยีที่พัฒนาแบบข้ามแพลตฟอร์มได้มาใช้
-
ระหว่างที่ชั่งใจระหว่าง Flutter / React Native พบว่า React Native มีชุมชนที่เสถียรและคึกคักกว่าเล็กน้อย จึงตัดสินใจเลือก React Native
- ฐานแบบ Native vs ฐานแบบ React Native
-
มีการพิจารณาว่าจะวาง React Native บนแอปเนทีฟเดิม หรือจะวางเนทีฟบน React Native แทน
-
หากวาง React Native บนเนทีฟ จะทำให้ endpoint ของแต่ละหน้าต่างกัน และการจัดการ app lifecycle ซับซ้อนขึ้น
-
หากวางเนทีฟบน React Native โค้ดเนทีฟเดิมจะต้องถูกแก้ไขหนึ่งรอบเพื่อให้เข้ากันได้กับ React Native และในอนาคตก็ต้องเขียนใหม่เป็น React Native อยู่ดี
-
เนื่องจากมีแผนจะย้ายฟังก์ชันส่วนใหญ่ทั้งหมดไปยัง React Native อยู่แล้ว จึงตัดสินใจเลือกแนวทางวางเนทีฟบน React Native
- การนำหน้าจอเนทีฟกลับมาใช้ซ้ำ
- เพื่อให้ตอบสนองต่อการเปลี่ยนแปลงได้รวดเร็วภายในเวลาที่กำหนด จึงตัดสินใจเขียนหน้าจอใหม่ด้วย React Native และคงหน้าจอเดิมแบบเนทีฟไว้ (โดยจะค่อย ๆ เปลี่ยนหน้าจอเนทีฟไปเป็น React Native แบบค่อยเป็นค่อยไป)
- การนำโค้ดเนทีฟกลับมาใช้ซ้ำ
-
จะสามารถถ่ายทอดแก่นแท้ของเนทีฟที่ Ridibooks สั่งสมจากการดูแลรักษามา 13 ปีเข้าสู่ React Native ได้หรือไม่? เดิมทีแอปเนทีฟใช้ Swift และ Kotlin จึงมีการตรวจสอบว่าสามารถนำสิ่งเหล่านี้มาใช้ใน React Native ได้ตามเดิมหรือไม่
-
สามารถใช้งานแบบเดิมได้ด้วยการสร้าง bridge
- ความยากลำบากในกระบวนการนำไปใช้
-
ขนาด bundle และการใช้หน่วยความจำเพิ่มขึ้น
-
ขนาด bundle อยู่ในระดับที่คาดไว้ แต่หน่วยความจำแย่มาก จึงต้องใส่ใจกับการปรับแต่งประสิทธิภาพอย่างมาก
-
ยากที่จะเชื่อถือ third-party library
-
มองข้ามทั้งฝั่งเนทีฟและฝั่งฟรอนต์ไม่ได้ นักพัฒนาเนทีฟต้องเรียนรู้งานฝั่งฟรอนต์ และนักพัฒนาฝั่งฟรอนต์ก็ต้องเรียนรู้งานฝั่งเนทีฟ การแลกเปลี่ยนความรู้ระหว่างกันคือกุญแจสู่ความสำเร็จ
- React Native ดีเพราะแบบนี้
-
ประสิทธิภาพการพัฒนาสูง
-
เป็นแพลตฟอร์มที่เหมาะกับการทำงานร่วมกัน
ด้วย React Native ทำให้สามารถบรรลุ product roadmap ภายในเวลาที่กำหนด พร้อมมีสภาพแวดล้อมและประสิทธิภาพการทำงานที่รับมือกับการเปลี่ยนแปลงได้รวดเร็ว จากนี้ไปมีแผนจะเปลี่ยนพื้นที่ฝั่งเนทีฟไปเป็น React Native อย่างจริงจัง แต่ตัว viewer จะยังคงรักษาไว้ต่อไป เพราะมีองค์ความรู้ที่สั่งสมมา 13 ปี เพื่อมอบประสบการณ์ผู้ใช้ที่ดีที่สุด
11 ความคิดเห็น
ไม่แน่ใจว่าคุณเคยลองค้นหาคีย์เวิร์ดใน Google Trends หรือเปล่า แต่ ecosystem ของ RN แทบจะกำลังตายอยู่แล้วครับ/ค่ะ ในทางกลับกัน Flutter กำลังเติบโตแบบก้าวกระโดด อ้างอิงไว้ก่อนว่าผม/ฉันเป็นนักพัฒนาเนทีฟครับ/ค่ะ
ในมุมของผู้ใช้ ดูเหมือนว่าแอปเดสก์ท็อปจะมีประสิทธิภาพแย่ลงกว่าเวอร์ชันก่อนนะครับ แต่ก่อนตอนเปลี่ยนหน้าแทบไม่รู้สึกถึงความหน่วงเลย แต่ช่วงนี้กระตุกอยู่ตลอดครับ
อยากให้มีการไฮไลต์ในเวอร์ชันเดสก์ท็อปหน่อย... ไม่แน่ใจว่าเป็นเพราะปัญหาลิขสิทธิ์อะไรทำนองนั้นเลยทำไม่ได้หรือเปล่า อืม
ช่วยใส่ใจแอปเดสก์ท็อปบ้างเถอะ ไม่ใช่มีแต่มือถือ.. ฮือๆ
ในฐานะคนที่ใช้แอปเดสก์ท็อปของ Ridibooks มาอย่างยาวนาน ก็อดรู้สึกเสียดายไม่ได้ว่าการตัดสินใจครั้งนี้เหมือนจะคำนึงถึงแค่มือถืออย่างเดียวหรือเปล่า ไม่ใช่แค่ผมคนเดียวด้วย เพราะคนที่บอกว่าใช้แอปเดสก์ท็อปกันนี่สิบคนก็สิบคนต้องทนทุกข์กับบั๊กที่เกิดขึ้นต่อเนื่อง... (หนักกว่าแอปเก่าที่ทำบน Qt เสียอีก)
ได้ยินคนรอบตัวบ่นเรื่องปัญหาของแอปเดสก์ท็อปกันเยอะมากจริง ๆ..
แม้ว่าผมเองจะไม่ได้อยู่ในฝั่งที่ลงมือพัฒนาโดยตรง แต่พอเห็นกระแสชื่นชม Flutter ในคอมมูนิตี้ที่ผมเจออยู่บ่อย ๆ ก็เลยลองคุยกับนักพัฒนาแอปในบริษัทดู ปรากฏว่าเขาชอบ React มากกว่าน่ะครับ โดยบอกว่าฐานผู้ใช้และตลาดการจ้างงานก็ดีกว่าด้วย เลยอยากลองฟังความเห็นของคนอื่น ๆ เหมือนกันครับ
เนทีฟกำลังพัฒนาอย่างรวดเร็วมาก ประเด็นสำคัญคงอยู่ที่ว่า RN จะตามความเร็วนั้นได้หรือไม่
สำหรับคำถามนี้ ถ้าเทียบกับ Flutter แล้วจะเป็นอย่างไรบ้าง?
แอนดรอยด์น่าจะไม่มีปัญหาเหมือนเดิม แต่ไม่แน่ใจว่าจะตาม iOS ได้หรือเปล่า
ผมคิดว่าไม่ควรมองข้ามต้นทุนของเอนโทรปีที่เกิดจากการรวมเป็นหนึ่งเดียว
เคยพัฒนาและเปิดตัวด้วย React Native เมื่อ 2~3 ปีก่อน...
ส่วนตัวคิดว่ามีข้อเสียมากกว่าข้อดี..
https://m.blog.naver.com/PostView.naver/…
ก็แทบจะเลิกสนใจไปแล้ว... แต่ความนิยมก็ยังคงอยู่เหมือนเดิมนะครับ