Dev ใกล้ถึง JavaScript UI ที่ซับซ้อน [ปิด]

ฉันพยายามที่จะเข้าใจภูมิทัศน์ของวิธีการที่แตกต่างกันและแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับการพัฒนา JavaScript ฝั่งไคลเอ็นต์ที่ซับซ้อน

ฉันไม่แน่ใจว่าจะติดป้ายประเภทของแอปพลิเคชันนี้ได้อย่างไรอาจเป็นAJAXหรือRIA ที่หนักหน่วง (แต่ไม่ใช่ปลั๊กอินเช่น Flash / Silverlight) ฉันหมายถึงเว็บแอปที่มีคุณสมบัติเหล่านี้:

• จำลอง UX ของเดสก์ท็อปแบบเนทีฟ / เนทีฟใน JavaScript
• มีพฤติกรรมส่วนใหญ่ / ทั้งหมดใน JS ฝั่งไคลเอ็นต์โดยใช้เซิร์ฟเวอร์เป็น data-API (JSON / Html-Templates)

สิ่งนี้ตรงกันข้ามกับการใช้เว็บเซิร์ฟเวอร์สำหรับการแสดงผล UI ซึ่งสร้าง HTML ทั้งหมดในรูปแบบการรีเฟรชหน้า

ตัวอย่างบางส่วนคือ:

• Google Docs / Gmail
• MindMeister
• การพิจาณาติดตาม

เมื่อเราก้าวไปข้างหน้าสู่ HTML5 ฉันสามารถเห็นรูปแบบของการพัฒนา RIA นี้ด้วย JavaScript จำนวนมากกลายเป็นเรื่องปกติและจำเป็นในการแข่งขัน

คำถาม: ดังนั้นวิธีการทั่วไปที่เกิดขึ้นในการจัดการการพัฒนา JS แบบหนักเหล่านี้คืออะไร?

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

Google ได้เข้าหาปัญหาโดยการสร้าง GWT ที่รวบรวมจากภาษาระดับสูงกว่า (Java) ถึง JS โดยพึ่งพาโครงสร้างพื้นฐานการพัฒนาที่มีอยู่ซึ่งภาษาระดับสูงกว่ามี (Eclipse, เครื่องมือพิมพ์ดีดแรง, เครื่องมือการปรับโครงสร้างใหม่) พร้อมกับเบราว์เซอร์ที่เข้ากันได้ ปัญหาอื่น ๆ อยู่ห่างจากผู้พัฒนา

มีเครื่องมืออื่น ๆ เช่น Script # for C # ที่ทำสิ่งที่คล้ายกัน ทั้งหมดนี้ทำให้ JS มากขึ้นในบทบาทของ IL (ภาษาระดับกลาง) กล่าวคือ "คุณไม่เคยเขียนด้วยภาษาระดับต่ำอีกต่อไป"

แต่ 'คอมไพล์ถึง JS' นี้ไม่ใช่วิธีการเดียว ไม่ชัดเจนว่า GWT เป็นวิธีการที่โดดเด่น ... หรือจะกลายเป็นจริง

ผู้คนกำลังทำอะไรกับ JavaScript ลูกค้าที่รวย คำถามเกี่ยวกับการปรับทิศทาง:

• ร้านค้าส่วนใหญ่สร้างหัตถกรรมด้วยตนเอง (บน libs เช่น jQuery และคณะ)
• หรือมีวิธีการที่แตกต่างกันมากมายโดยไม่มีแนวปฏิบัติที่ดีที่สุดเกิดขึ้นอย่างชัดเจน?
• ร้านค้าส่วนใหญ่หลีกเลี่ยงการพัฒนามาตราส่วน RIA เพื่อให้ง่ายต่อการพัฒนารูปแบบฝั่งเซิร์ฟเวอร์ / หน้าวาดใหม่หรือไม่? ถ้าเป็นเช่นนี้จะมีอายุหรือไม่
• การรวบรวม JS อาจจะเป็นแนวโน้มในอนาคตหรือไม่ หรือนี่มันผิดปกติเหรอ?
• พวกเขาจัดการความซับซ้อนและการสร้างโครงสร้างใหม่ของไคลเอ็นต์ JS ได้อย่างไร
• การทำให้เป็นโมดูลและการกระจายการทำงานข้ามทีม?
• แอปพลิเคชั่นการบังคับใช้และการทดสอบรูปแบบฝั่งไคลเอ็นต์เช่น MVC / MVP เป็นต้น

ดังนั้นแนวโน้มที่จะเกิดขึ้นในอนาคตของ JavaScript และ HTML5 ที่หนักหนาสาหัสของเราคืออะไร

ขอบคุณ!

แอพพลิเคชั่นบนเว็บส่วนใหญ่ที่ฉันเห็น (และผู้พัฒนาเว็บที่ฉันพูดคุยด้วย) ที่เคลื่อนไหวในทิศทางนี้กำลังใช้ jQuery เป็นฐาน

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

แค่ความเห็นของฉัน ...

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

Google พยายามขาย GWT เป็นสภาพแวดล้อมการดำเนินการ X-platform ที่รวดเร็วมากพร้อมการรวมฝั่งเซิร์ฟเวอร์ที่เหมาะสม แต่อย่างที่คนอื่นชี้ไปแล้วมันไม่ได้เป็นอย่างนั้น - JQuery และ YUI นั้นเร็วถ้าไม่เร็วขึ้น และง่ายกว่าการทำโปรไฟล์และปรับแต่งหน้าเว็บของคุณเมื่อมีการประกอบกันด้วยตนเองเพื่อให้คุณควบคุม CSS, มาร์กอัปและ JavaScript ได้อย่างสมบูรณ์

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

ในโครงการปัจจุบันของเราเราใช้ Stripes - เฟรมเวิร์กอิงแอ็คชั่นระดับต่ำ - และ JQuery ทางฝั่งไคลเอ็นต์ มันง่ายมากที่จะทำ Ajax เมื่อคุณเห็นตัวต่อทั้งหมด: นี่คือโค้ดฝั่งเซิร์ฟเวอร์ของคุณซึ่งทำงานกับข้อมูล นี่คือรหัสฝั่งไคลเอ็นต์ของคุณ - สำหรับการดึงข้อมูลและทำให้สิ่งต่าง ๆ เกิดขึ้นบนหน้าเว็บ นี่คือ CSS ของคุณนี่คือมาร์กอัปของคุณนี่คือเทมเพลตของคุณ - ทุกอย่างสะอาดและแยกออก สามารถขยายได้อย่างง่ายดาย, แฮ็ก, ปรับได้และ debuggable ฉันรักมัน.

ฉันรัก JQuery ด้วยทัศนคติที่มีต่อความเร็วและความเรียบง่าย ฉันชอบ YUI3 สำหรับการแยกส่วนและวิดเจ็ตที่ครอบคลุม ฉันชอบ YUI CSS ที่ให้ความมั่นคงแก่เบราว์เซอร์ ฉันชอบ JavaScript สำหรับชิ้นส่วนที่ดี ฉันรัก Java ที่ให้ฉันทำงานให้เสร็จ

แค่จูบแล้วคุณจะสบายดี!

ฉันเคยได้ยินชื่อ "แอปพลิเคชันหน้าเดียว" เหล่านี้

นี่คือสภาพแวดล้อมใหม่และกฎยังไม่ได้เขียนทั้งหมด ฉันทำงานกับแอปพลิเคชันหน้าเดียวที่ค่อนข้างใหญ่ในปีที่แล้ว (2010) และนี่คือเครื่องมือที่เราใช้

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

รหัสส่วนหน้าคือ javascript เราใช้jQueryเพื่อทำการจัดการองค์ประกอบของเพจPureสำหรับการสร้างเทมเพลตและRequireJsเพื่อแยกโค้ดออกเป็นโมดูล (เครื่องมือสร้าง RequireJs ถูกใช้เพื่อให้การดาวน์โหลดที่เหมาะสมที่สุด)

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

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

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

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

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

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

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