Problems with Delivering Applications via the Browser
From Blognone
ปัญหาของแอพพลิเคชันในเบราว์เซอร์
เมื่อเว็บแอพพลิเคชันพัฒนาจนมีความซับซ้อนในระดับหนึ่ง มันก็เริ่มถึงขีดจำกัดทั้งด้านความสามารถของเบราว์เซอร์ และความง่ายในการใช้งานของแอพพลิเคชัน ยิ่งเว็บแอพพลิเคชันนิยมมากเท่าไร ปัญหาเหล่านี้ก็ยิ่งกลายเป็นเรื่องสำคัญ
เว็บเบราว์เซอร์ถูกออกแบบมาเพื่อรับส่งและแสดงเอกสาร HTML และแนวคิดหลักนี้ก็ยังคงอยู่มาจนถึงปัจจุบัน เมื่อนำเว็บเบราว์เซอร์มาใช้งานแอพพลิเคชัน มันจึงเกิดปัญหาด้านความแตกต่างระหว่างการแสดงเอกสารกับการใช้งานเป็นแอพพลิเคชัน ซึ่งเราแยกเป็นหมวดหมู่ได้ดังนี้
Contents |
ปัญหาในส่วนติดต่อผู้ใช้
แอพพลิเคชันที่ใช้ผ่านเว็บเบราว์เซอร์มักมีส่วนติดต่อผู้ใช้ของตัวเอง ซึ่งมักจะขัดแย้งกับส่วนติดต่อผู้ใช้ของเว็บเบราว์เซอร์ และอาจส่งผลให้เกิดความสับสนของผู้ใช้ (ปัญหาระดับต่ำสุด) ไปจนถึงความผิดพลาดของแอพพลิเคชัน (ปัญหาร้ายแรง) ตัวอย่างคลาสสิคของเรื่องนี้คือปุ่ม Back ในเบราว์เซอร์ ปุ่ม Back นี้ถูกต้องตามหลักการถ้าเราใช้เบราว์เซอร์สำหรับดูเอกสาร แต่ถ้าใช้เป็นแอพพลิเคชันแล้วมันไม่เหมาะสมนัก ถึงแม้ว่าจะมีวิธีการแก้ไขปัญหานี้หลายๆ แบบ แต่มันยิ่งทำให้ผู้ใช้สับสนว่า ตกลงแล้วเว็บแอพพลิเคชันตัวนี้รองรับปุ่ม Back หรือไม่ หรือว่ากดปุ่ม Back แล้วจะทำให้ข้อมูลที่กรอกไว้หายไปทั้งหมด
การใช้งานร่วมกับเดสก์ท็อป
โมเดลความปลอดภัยของเบราว์เซอร์ (ซึ่งจำกัดสิทธิ์ในการเข้าถึงระบบ) ส่งผลให้เว็บแอพพลิเคชันไม่สามารถเรียกใช้ความสามารถของระบบปฏิบัติการแบบเดียวกับแอพพลิเคชันทั่วไปได้ (ซึ่งผู้ใช้คาดหวังว่ามันจะทำได้) ตัวอย่างเช่น คุณไม่สามารถลากไฟล์ไปใส่ในเว็บแอพพลิเคชัน แล้วหวังว่าจะให้เว็บแอพพลิเคชันนั้นเปิดไฟล์ได้เหมือนแอพพลิเคชันทั่วไป เว็บแอพพลิเคชันไม่สามารถใช้งานร่วมกับแอพพลิเคชันอื่นๆ ในเครื่องของผู้ใช้ได้
RIA พยายามแก้ปัญหานี้โดยพัฒนาส่วนติดต่อผู้ใช้ที่ใกล้เคียงกับแอพพลิเคชันแบบปกติมากขึ้น แต่มันก็ยังไม่สามารถเชื่อมช่องว่างความแตกต่างระหว่างเว็บเบราว์เซอร์กับเดสก์ท็อปได้
ต้องเชื่อมต่ออินเทอร์เน็ตเสมอ
เว็บแอพพลิเคชันถูกส่งมาจากเซิร์ฟเวอร์และไม่เก็บไว้บนเครื่องของผู้ใช้ ผู้ใช้ต้องเชื่อมต่ออินเทอร์เน็ตเสมอเพื่อใช้งาน ถึงแม้ว่าจะมีความพยายามจากหลายกลุ่มที่ทำให้เว็บแอพพลิเคชันใช้งานแบบออฟไลน์ได้ แต่ก็ยังไม่มีวิธีที่ได้รับการยอมรับในวงกว้าง และไม่สามารถทำงานในเบราว์เซอร์ที่แตกต่างกันได้ หรือไม่ก็จำเป็นต้องติดตั้งซอฟต์แวร์เสริมลงในเครื่องจึงจะใช้งานได้ ที่สุดแล้วแอพพลิเคชันแบบออฟไลน์เหล่านี้ยังต้องอาศัยการจัดการของผู้ใช้ด้วยตนเอง ซึ่งมีความซับซ้อนสูงเกินกว่าจะรับได้
Lowest Common Denominator
ยิ่งแอพพลิเคชันซับซ้อนมากขึ้นและเข้าสู่ขีดจำกัดของ JavaScript กับ DHTML นักพัฒนาเว็บแอพพลิเคชันก็ยิ่งปวดหัวกับความแตกต่างของเว็บเบราว์เซอร์แต่ละตัว รวมถึง API ที่แตกต่างกัน ปัญหาเหล่านี้มักถูกแก้ด้วยการเขียนโค้ดสำหรับเบราว์เซอร์แต่ละตัวโดยเฉพาะ ซึ่งในระยะยาวแล้วยากแก่การดูแล และกินเวลาของนักพัฒนาซึ่งควรใช้ไปในการพัฒนาฟีเจอร์ใหม่ๆ มากกว่า
ถึงแม้ว่าเฟรมเวิร์ค JavaScript จะกำลังนิยมในการแก้ปัญหาเหล่านี้ ( to be done - แปลคำว่า Lowest Common Denominator ไม่ถูก)...
การที่เว็บแอพพลิเคชันได้รับความนิยมถึงแม้จะมีข้อจำกัดเหล่านี้ ก็เป็นเพราะจุดแข็งของเว็บที่มีโมเดลในการพัฒนาที่ดี และสะดวกในการสร้างแอพพลิเคชันข้ามแพลตฟอร์ม ดังนั้นถ้าเราสามารถมีแพลตฟอร์มการพัฒนาที่รวมเอาข้อดีของทั้งเบราว์เซอร์ และความสามารถของแอพพลิเคชันสำหรับเดสก์ท็อปเข้าด้วยกันได้ ย่อมจะเป็นสิ่งที่ดีเป็นอย่างมาก และ Adobe Integrated Runtime ก็พยายามตั้งเป้าจะไปให้ถึงจุดนั้น