ข้อดีข้อเสียของแอปพลิเคชันเว็บ HTML / JavaScript เท่านั้น [ปิด]

ฉันมาจากพื้นหลังในรูปแบบ ASP.NET และพบว่าการเขียนโค้ดด้านเซิร์ฟเวอร์มีประสิทธิภาพมากในอดีต อย่างไรก็ตามเมื่อเร็ว ๆ นี้ฉันต้องการเลิกใช้โค้ดฝั่งเซิร์ฟเวอร์ของส่วนหน้าและแทนที่ด้วย HTML / JavaScript ที่บริสุทธิ์ซึ่งเข้าถึงข้อมูลผ่านทาง JSON webservices ฉันไม่มีประสบการณ์จริงในเรื่องนี้ดังนั้นฉันจึงอยากได้ยินว่านี่เป็นรุ่นที่ผ่านการทดลองและทดสอบแล้วหรือไม่ นอกจากนี้ยังมีข้อผิดพลาดรอบตัวมันคืออะไร?

ฉันพบว่าการควบคุมผู้ใช้ ASP.NET มีประโยชน์มากดังนั้นฉันจึงอยากจะรักษาทฤษฎีเอาไว้โดยการเก็บแม่แบบมาร์กอัปในไฟล์ HTML แยกต่างหากบนเซิร์ฟเวอร์ สิ่งเหล่านี้จะถูกดึงและใช้งานผ่าน jQuery AJAX และ jQuery HTML plugin plugin ตามลำดับ

ข้อมูลใด ๆ ที่จะได้รับการชื่นชมอย่างมาก

ป.ล. ขออภัยสำหรับคำถาม noob แต่สถาปัตยกรรมเว็บประเภทนี้เรียกว่า web-2.0 หรือฉันไม่ได้ติดตามอย่างสมบูรณ์หรือไม่

ฉันใช้เทคนิคนี้เฉพาะสำหรับเว็บแอปพลิเคชันที่เรากำลังทำอยู่ แบ็กเอนด์ของฉันโฮสต์บน Google App Engine โดยใช้ Java SDK และส่วนหน้าของฉันใช้ HTML, CSS และ JavaScript (พร้อม jQuery)

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

ข้อได้เปรียบ: การทำงานกับนักออกแบบเว็บไซต์

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

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

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

รหัสฝั่งเซิร์ฟเวอร์และ HTML / CSS Handoffs

ในโครงการที่ผ่านมาเขาต้องส่ง HTML และ CSS ให้กับนักพัฒนา Java ที่จะใช้ HTML และ CSS ของเขาและเขียนใหม่อย่างสมบูรณ์โดยใช้เทคโนโลยี JSP การดำเนินการนี้ใช้เวลานานและมักจะทำให้เกิดความแตกต่างเล็กน้อย แต่สำคัญในการแสดงผลหน้าเว็บจริงรวมทั้งการตรวจสอบความถูกต้องในเครื่องมือตรวจสอบ W3C

โดยรวมแล้วเรามีความสุขมากกับเทคนิคนี้และฉันยังมีศูนย์ JSP หรือโค้ดฝั่งเซิร์ฟเวอร์ในหน้า HTML ของฉัน

ข้อผิดพลาดของเทคนิค REST / JSON

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

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

ข้อได้เปรียบ: สามารถสร้างแอปพลิเคชันอื่น ๆ บนแพลตฟอร์มได้

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

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

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

ฉันไม่สามารถเน้นได้มากพอว่าสถาปัตยกรรมนี้สามารถใช้ซ้ำได้ทั้งในระดับแอปพลิเคชันและระดับ HTML / CSS / JavaScript และฉันขอแนะนำให้คุณลองทำในโครงการต่อไปของคุณ

แน่นอนว่ามันเป็นกลยุทธ์ที่ปฏิบัติได้ แต่ไม่ใช่กระสุนเงิน

ข้อดี :

• หากทำถูกต้องแอปพลิเคชันที่พัฒนาด้วยวิธีนี้จะตอบสนองได้ดีมาก
• คุณมีการแยกตรรกะที่ชัดเจน (บนเซิร์ฟเวอร์) และการนำเสนอ (บนไคลเอนต์); เซิร์ฟเวอร์ไม่ต้องกังวลกับเรื่องการนำเสนอของแอปพลิเคชัน
• การใช้แบนด์วิดท์เครือข่ายที่มีประสิทธิภาพมากขึ้นอาจเป็นไปได้ (คุณกำลังส่งข้อมูลดิบเท่านั้น, ไม่มีแผ่นข้อมูลการนำเสนอ)
• ง่ายต่อการพัฒนา GUI ที่คล้ายกับเดสก์ท็อปเนื่องจากคุณจะพึ่งพากระบวนทัศน์คำขอ / ตอบกลับน้อยลง

ข้อเสีย :

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

มันเป็นไปได้อย่างแน่นอนและอาจเป็นกำลังใจให้เป็นแนวปฏิบัติที่ดีที่สุด สิ่งที่คุณเสนอคือการแยก UI จากตรรกะทางธุรกิจเพื่อให้มีการแยกข้อกังวลอย่างชัดเจน นี่เป็นสิ่งที่ดีจริงๆ

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

เมื่อคุณแยกแอปพลิเคชันออกเป็น 2 ส่วนคุณสามารถแทนที่ UI อย่างสมบูรณ์ด้วยสิ่งอื่น - โปรแกรมเดสก์ท็อปหรือ UI อื่นสำหรับมือถือเมื่อเทียบกับเบราว์เซอร์เดสก์ท็อป

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

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

หากคุณยังคงใช้ ASP.NET WebForms และต้องการเร่งความเร็วแอปพลิเคชันของคุณนี่คือสิ่งที่คุณควรทำ:

• การออกแบบโปรแกรมของคุณด้วยSOLIDในใจ
• ปิดใช้งานViewStateในทุกหน้าและการควบคุมผู้ใช้

• อย่าใช้การควบคุมฝั่งเซิร์ฟเวอร์

  <%: VeiwModel.Title%> แทนที่จะเป็น <asp: ตัวอักษร id = "ชื่อ" runat = "เซิร์ฟเวอร์">

• ในแบ็กเอนด์ให้แทนที่เมธอด OnInit และทำการเริ่มต้นทั้งหมดที่นั่น:

  การป้องกันการลบล้างเป็นโมฆะ OnInit (System.EventArgs e) {CreateViewModel (); base.OnInit (จ); }

• บีบอัดไฟล์. css และ. js ทั้งหมดเป็น 1 โดยใช้SquishIt

• โหลดภาพที่ขี้เกียจ
• แคชวัตถุที่ซับซ้อน

ในที่สุดตรวจสอบ www.porsche.se นั่นไม่ใช่เว็บไซต์ที่รวดเร็วใช่มั้ย