ใน บริษัท ของเราเราต้องสร้างเว็บอินเตอร์เฟสบนแพลตฟอร์มลินุกซ์ในตัว ฉันเห็นตัวเลือก 2 แบบ: คุณใช้เทคโนโลยีที่ HTML และ JavaScript ถูกสร้างขึ้นบนฝั่งเซิร์ฟเวอร์ (คิดว่า JSP, Grails แต่เป็นสิ่งที่ใช้ C ++ และสร้าง HTML / JavaScript) หรือคุณสร้าง 'ไคลเอนต์' HTML5 แอ็พพลิเคชันที่พูดถึง JSON หรือ XML สร้างแบ็กเอนด์

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

AJAX

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

ฉันมีประสบการณ์มากมายเกี่ยวกับ XML และแทบไม่มีเลยกับ JSON ทุกสิ่งที่ฉันรู้เกี่ยวกับ XML ทำให้ฉันแนะนำให้คุณใช้ JSON ถ้าเป็นไปได้

ข้อดี AJAX:

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

AJAX จุดด้อย:

• การดีบัก JavaScript
• ความซับซ้อน?
• สิ่งที่คุณสามารถทำได้ด้วย JavaScript นั้นมักเป็นไปไม่ได้เลยที่คนตาบอดหรือคนพิการใช้
• อาจต้องใช้รหัสทั้งหมดเพิ่มเติม (พื้นที่เก็บข้อมูลโดยรวมที่ใหญ่กว่าบนอุปกรณ์ฝังตัวของคุณ)

ไคลเอ็นต์ / เซิร์ฟเวอร์

เว็บแอปพลิเคชันทั้งหมดใช้สถาปัตยกรรมไคลเอนต์ - เซิร์ฟเวอร์ โปรโตคอล HTTP บังคับให้เว็บแอปพลิเคชันทำงานแบบนั้น AJAX ใช้วิธีแก้ไขปัญหาสำหรับข้อ จำกัด การออกแบบ แต่โมเดลพื้นฐานพื้นฐานของ HTTP ยังคงเป็นไคลเอนต์ - เซิร์ฟเวอร์ ฉันจะไม่ติดใจเรื่องทั้งหมดเกี่ยวกับวิธีที่ดีที่สุดในการใช้ MVC กับเว็บแอปพลิเคชัน หากคุณต้องทำ MVC ด้วยเหตุผลทางการเมืองดูที่ Ruby / Rails ที่จริงแล้ว Rails เป็นสถาปัตยกรรมที่ยอดเยี่ยมสำหรับการคัดลอก (หรือใช้)

บริการเทียบกับแอพ

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

C / Web

ว้าว. ฉันทำงานใน C และ Assembly เป็นเวลา 3 ปีก่อนที่จะเปลี่ยนเป็นการพัฒนาเว็บไซต์ ฉันไม่สามารถนึกถึงภาษาที่แย่กว่านี้ในการเขียนเว็บแอปพลิเคชันโดยเฉพาะจากมุมมองด้านความปลอดภัย การตรวจสอบความถูกต้องของอินพุตและการหลีกเลี่ยงเอาต์พุตนั้นสำคัญมาก ... SANSจะเผยแพร่รายการข้อผิดพลาดที่พบบ่อยที่สุดทุกปี บัฟเฟอร์โอเวอร์โฟล, การฉีด, ปัญหาข้ามไซต์ (การเข้ารหัสเอาต์พุตที่ไม่เหมาะสม) ... ข้อผิดพลาดทั้งหมดนี้เป็นเรื่องง่ายที่จะทำใน C หรือแอสเซมบลี อย่างน้อยภาษาอย่าง Java มี String ซึ่งมีภูมิคุ้มกันต่อการโอเวอร์โฟลว์และกลไกการจัดการข้อยกเว้นซึ่งโดยทั่วไปจะป้องกันข้อผิดพลาดแบบ off-one จากการอนุญาตให้โค้ดที่เป็นอันตรายเข้าถึงหน่วยความจำระบบ ไม่ต้องพูดถึงการจัดการชุดอักขระสากล (ใช้UTF-8เมื่อทำได้)

หากคุณต้องการใช้ C เพื่อเหตุผลด้านหน่วยความจำหรือเฟิร์มแวร์นั่นคือสิ่งที่คุณต้องทำ แค่ระวัง!

สนับสนุนเบราว์เซอร์

ขั้นตอนแรกในการสร้างเว็บแอปพลิเคชันคือการค้นหาว่าเบราว์เซอร์ใดที่ลูกค้า ของคุณจะใช้ W3SchoolsและWikipediaเป็นแหล่งข้อมูลสถิติทั่วไปที่ดี แต่ YMMV

ตอนนี้ฉันทำงานที่ไหนเราตรวจสอบว่าแอปพลิเคชันของเราสร้าง XHTML 1.0 Transitional HTML ที่ถูกต้องเท่านั้น นอกจากนี้เรายังใช้ Doctype เฉพาะและการจัดรูปแบบที่จำเป็นเพื่อหลีกเลี่ยงโหมด Quirks ใน IE ซึ่งทำให้ HTML แบบข้ามเบราว์เซอร์ง่ายต่อการเขียน (ดูเคล็ดลับในบล็อกของฉัน ) เราทดสอบเวอร์ชันล่าสุดของ IE 3 เวอร์ชันรวมถึง Firefox และ Chrome บน Windows และ Linux (Safari ใช้เครื่องมือเรนเดอร์ตัวเดียวกับ Chrome) ด้วยการตรวจสอบความถูกต้องและการทดสอบแอปพลิเคชันของเราทำงานได้ทุกที่ (Windows, Mac, Linux, iPhone, Android, ฯลฯ ) ยกเว้น BlackBerry

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

สรุป

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

คุณอาจต้องใช้ CSS และการบีบอัดรูปภาพเพื่อสร้างสิ่งที่ดูดีและตอบสนองได้อย่างรวดเร็ว JavaScript, เว็บเซิร์ฟเวอร์และเบราว์เซอร์เป็นส่วนเพิ่มเติมของความรู้ที่คุณต้องการในที่สุด

หากคุณสร้าง HTML บนฝั่งเซิร์ฟเวอร์ฐานรหัสของคุณอาจจะเล็กลงและคุณอาจไม่จำเป็นต้องเรียนรู้ JavaScript โมเดลฝั่งเซิร์ฟเวอร์หมายความว่าโปรแกรมเมอร์ของคุณกำลังเขียนโค้ด (C?) ที่สร้าง HTML ที่สามารถดูได้โดยตรงก่อนที่จะถูกส่งไปยังไคลเอนต์ โมเดล AJAX หมายถึงโปรแกรมเมอร์ของคุณกำลังเขียน JavaScript ที่สร้าง HTML ฉันไม่ได้ตระหนักถึงเครื่องมือมากมายสำหรับการตรวจสอบหรือแม้แต่ดูรหัส HTML ที่สร้างขึ้นโดย JavaScript ภายในเบราว์เซอร์ทำให้การเขียนโปรแกรมยากขึ้นอย่างถูกต้อง

ที่ที่ฉันทำงานตอนนี้เราใช้วิธีไฮบริดซึ่งบางครั้งเกี่ยวข้องกับรหัส Java ที่สร้าง JavaScript ที่สร้าง HTML หากพวกคุณยังใหม่ต่อการพัฒนาเว็บนั่นไม่ใช่จุดเริ่มต้น ฉันเดาว่าฉันต้องบอกว่าถ้าคุณไม่มีเหตุผลที่น่าสนใจในการใช้โมเดล AJAX ฉันจะเริ่มต้นด้วยรุ่นเก่าฝั่งเซิร์ฟเวอร์ - HTML- รุ่นและดูว่ามันทำให้คุณได้รับไกลแค่ไหน

สิ่งหลังมีข้อได้เปรียบที่ทำให้บริการ "ข้อมูลทั่วไป" ของคุณ "(สิ่งใดก็ตามที่อาจหมายถึงในบริบทของคุณ)

ลูกค้า HTML ของคุณเป็นเพียงหนึ่งในผู้บริโภคที่เป็นไปได้ของข้อมูลนั้น คิดว่าแอป iOS, แอป Andriod, แอพ Windows 8, API, ฯลฯ - เหมือนผู้บริโภครายอื่น

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

แรกวิธีการเป็นแบบดั้งเดิมมากขึ้นได้รับมีมานานหลายปีและเอกสารที่ดี (แม้ว่า C ++ ไม่ได้โดยทั่วไปเป็นภาษาที่นิยมสำหรับที่)

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

โดยรวมแล้วขึ้นอยู่กับข้อ จำกัด อื่น ๆ เช่นความคุ้นเคยของทีมและกรณีศึกษาทางธุรกิจ

คำถามบางข้อที่สามารถช่วยคุณประเมินทางเลือกของคุณ:

1. ทีมมีประสบการณ์ด้านภาษาและแพลตฟอร์มหรือไม่?
2. ทีมยินดีที่จะเรียนรู้วิธีการและเทคโนโลยีใหม่ ๆ หรือไม่?
3. แอปพลิเคชันใช้ประโยชน์จากการตั้งโปรแกรมได้ง่ายกว่าสำหรับอุปกรณ์อื่น ๆ (iPhone, android, windows 8, ฯลฯ ) หรือไม่
4. แอปอื่นภายในหรือภายนอกจะรวมเข้ากับบริการหรือข้อมูลที่มีประโยชน์กับแอปพลิเคชันหรือไม่

สำหรับแอปพลิเคชัน "อินทราเน็ต" ดังกล่าวฉันใช้วิธีไคลเอนต์ไขมัน (JavaScript / HTML5-app + JSON) กับ ExtJS4

สำหรับเว็บไซต์ "อินเทอร์เน็ต" ปกติฉันจะใช้วิธี "คลาสสิค" มากกว่า

ลูกค้าต้องแสดงไซต์ต่อไปดังนั้นทำไมไม่ชาร์จพวกเขาด้วยกระบวนการทั้งหมดและเพียงแค่ให้ข้อมูลพวกเขากรอกมันเพียงรหัสเซิร์ฟเวอร์สำหรับการสร้างการตอบสนอง (เพียงแค่ธรรมดา JSON หรือ XML) ซึ่งช่วยประหยัดประสิทธิภาพ นอกจากนี้เนื่องจากมีลูกค้ามากกว่าเซิร์ฟเวอร์เสมอระบบทั้งหมดจึงขยายตัวได้ดีกว่ามากหากลูกค้าทำงานให้มากขึ้น

รหัสลูกค้าจะได้รับพร้อมกับ HTTP คุณยังสามารถส่งเวอร์ชันใหม่ไปยังผู้ใช้ได้อย่างง่ายดายโดยไม่มีกลไกการอัพเดตที่ไม่ชัดเจน (เพียงแทนที่ HMTL / JS / CSS)

เหตุผลเดียวที่ฉันจะใช้วิธีคลาสสิกในเว็บไซต์ปกติคือเครื่องมือค้นหา