เฟรมเวิร์ก JavaScript เพื่อสร้างแอปพลิเคชันหน้าเดียว [ปิด]


101

เป้าหมายของฉันคือการย้ายเว็บแอปพลิเคชันที่มีอยู่ไปยังแอปพลิเคชันหน้าเดียว RESTful (SPA) ขณะนี้ฉันกำลังประเมินเฟรมเวิร์กเว็บแอปพลิเคชัน Javascript หลายรายการ


ความต้องการของฉันมีดังต่อไปนี้:

  • ชั้นข้อมูล RESTful (เช่น ember-data)
  • MV * - โครงสร้าง
  • เส้นทางแบบไดนามิก
  • การสนับสนุนการทดสอบ
  • การเข้ารหัสตามแบบแผน
  • การสนับสนุน SEO
  • การสนับสนุนประวัติเบราว์เซอร์
  • เอกสาร (API-) ที่ดี
  • พร้อมสำหรับการผลิต
  • ชุมชนที่อยู่อาศัย

กระดูกสันหลัง

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

เอมเบอร์

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

เชิงมุม

Angular.jsเป็นกรอบงานที่แพร่กระจายอย่างกว้างขวางเช่นกันซึ่งดูแลโดย Google แต่ฉันไม่คุ้นเคยกับเชิงมุม สำหรับฉันโครงสร้างดูเหมือนไม่ชัดเจนคำอธิบายขาดความรับผิดชอบโดยรวมของแต่ละส่วนของกรอบการทำงานและการนำไปใช้งานนั้นดูอ้อมค้อม เพื่อให้ตรง: นี่เป็นเพียงความประทับใจส่วนตัวของฉันและอาจมาจากความรู้ที่ขาดหายไป

แบทแมนและดาวตก

ตามที่ฉันเข้าใจทั้งสองเฟรมเวิร์กจำเป็นต้องมีส่วนของเซิร์ฟเวอร์เช่นกัน และเนื่องจากเราต้องการแบ็กเอนด์ RESTful ไม่ว่าจะเป็นภาษาเทคนิคหรือซอฟต์แวร์อะไรก็ตามนี่ไม่ใช่สิ่งที่เราต้องการ นอกจากนี้ backend API ยังมีอยู่แล้ว (RoR)

Knockout , CanJSและSpine

ฉันไม่ได้เจาะลึกลงไปในผู้สมัครสามคนนี้ บางทีนี่อาจจะเป็นก้าวต่อไปของฉัน


ดังนั้นคำถามของฉันตอนนี้:

  • ฉันขาดกรอบสปาที่ดีหรือไม่?
  • คุณจะแนะนำ / แนะนำกรอบอะไร
  • คุณจะหลีกเลี่ยงกรอบการทำงานที่กล่าวถึงหรือไม่?
  • ประสบการณ์ของคุณในแอปพลิเคชัน SP ที่ใหญ่กว่าคืออะไร?

PS: ฉันอยากจะแนะนำบล็อกโพสต์ที่ยอดเยี่ยมจาก Steven Anderson (ผู้พัฒนาหลักจาก Knockout.js) เกี่ยวกับการประชุม "Throne of JS" (จากปี 2012) และเฟรมเวิร์กจาวาสคริปต์โดยทั่วไป

PS: ใช่ฉันรู้ว่ามีคำถามเกี่ยวกับ SO อยู่แล้ว แต่เนื่องจากการพัฒนาอย่างรวดเร็วและรวดเร็วสำหรับ SPAs ส่วนใหญ่จึงล้าสมัยไปแล้ว


ตรวจสอบกรอบการทำสปาที่น่าพิศวงที่ฉันเพิ่งเปิดที่มา: knockout-spa github.com/onlyurei/knockout-spa
onlyurei

คำตอบ:


81

เมื่อเร็ว ๆ นี้ฉันต้องตัดสินใจเกี่ยวกับกรอบงาน JavaScript SPA ในโครงการด้วย

  • เอมเบอร์

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

  • กระดูกสันหลัง

    Backbone เป็นเฟรมเวิร์กแรกที่เรามองอย่างจริงจัง ฉันไม่แน่ใจว่าฉันเข้าใจว่าทำไมคุณถึงคิดว่ามันไม่มี "โครงสร้างที่กำหนดไว้อย่างดี"? Backbone ค่อนข้างชัดเจนเกี่ยวกับวิธีแบ่ง Model และ View code บางทีคุณอาจหมายความว่าไม่มีเทมเพลตแอปบางประเภท? อย่างไรก็ตาม Backbone ดูเหมือนจะมุ่งเน้นไปที่โมเดล / ส่วนที่มีผลผูกพัน REST แต่ไม่ได้กำหนดอะไรสำหรับการเชื่อมต่อมุมมอง หากการผูกโมเดลมีความสำคัญสำหรับคุณและคุณกำลังใช้ Rails อยู่ก็ควรจะทำสิ่งนี้ได้อย่างง่ายดาย น่าเสียดายที่บริการบนเว็บสำหรับแอปของฉันไม่ค่อยตรงกันและฉันต้องเขียนวิธี.syncและ.parseวิธีการของตัวเองสำหรับทุกอย่าง การแยก Model และ View code เป็นสิ่งที่ดี แต่เนื่องจากเราต้องเขียนการผูกทั้งหมดตั้งแต่เริ่มต้นจึงไม่คุ้มค่า

  • น็อกคู่ต่อสู้

    สิ่งที่น่าพิศวงเปรียบเสมือนหยินสู่กระดูกสันหลังของหยาง ในกรณีที่ Backbone มุ่งเน้นไปที่ Model Knockout เป็นเฟรมเวิร์ก MVVM และมุ่งเน้นไปที่ View มีobservableWrapper สำหรับคุณสมบัติของวัตถุ JavaScript และใช้data-bindแอตทริบิวต์เพื่อผูกคุณสมบัติกับ HTML ของคุณ ในที่สุดเราก็ไปกับ Knockout เนื่องจากการผูกมุมมองเป็นสิ่งที่เราต้องการสำหรับแอปของเราเป็นหลัก (... บวกอื่น ๆ ตามที่กล่าวไว้ในภายหลัง ... ) หากคุณชอบมุมมองของ Knockout และการผูกโมเดลของ Backbone นอกจากนี้ยังมีKnockBackซึ่งรวมทั้งสองเฟรมเวิร์ก

  • เชิงมุม

    ดูสิ่งนี้หลังจากที่ Knockout - น่าเสียดายที่เราทุกคนดูมีความสุขมากกับการที่ Knockout ดูการผูกมัด มันดูซับซ้อนและยากกว่าที่จะเข้าสู่ Knockout และมันใช้แอตทริบิวต์ HTML ที่กำหนดเองจำนวนมากเพื่อทำการผูกซึ่งฉันไม่แน่ใจว่าฉันชอบ ... ฉันอาจลองดู Angular อีกครั้งในภายหลังเพราะเนื่องจากฉันเจอคนหลายคนที่ชอบเฟรมเวิร์กจริงๆ - บางทีเรา เพิ่งดูว่ามันสายเกินไปสำหรับโครงการนี้

  • แบทแมน , ดาวตก , CanJS , กระดูกสันหลัง

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

  • Afterword

    ดังที่ฉันได้กล่าวไปแล้วเราลงเอยด้วยการใช้ Knockout เพราะสำหรับโครงการของเราการมุ่งเน้นไปที่การผูกมุมมองนั้นสำคัญกว่า นอกจากนี้เรายังใช้RequireJSสำหรับ modularization ทางแยกและHasherเพื่อจัดการการกำหนดเส้นทางและประวัติจัสมินสำหรับการทดสอบรวมถึงJQuery , Twitter BootstrapและUnderscore.js (และอาจเป็นไลบรารีอื่น ๆ ที่ฉันลืมในขณะนี้)

    การพัฒนาแอป Javascript นั้นเหมือนกับระบบนิเวศของ Java มากกว่าระบบนิเวศของ Rails Rails เป็นแกนกลางที่มั่นคงของสิ่งต่างๆที่คุณจะใช้สำหรับทุกแอพ (Rails framework) และชุมชนมีการปรับแต่งมากมายที่นอกเหนือจากนั้น (อัญมณี) Java จัดเตรียม ... ภาษา จากนั้นคุณสามารถเลือก Java EE หรือ Spring หรือ Play หรือ Struts หรือ Tapestry และเลือก JDBC หรือ Hibernate หรือ TopLink หรือ Ibatis เพื่อคุยกับฐานข้อมูล จากนั้นคุณสามารถใช้ Ant หรือ Maven หรือ Gradle เพื่อสร้างได้ และเลือก Tomcat หรือท่าเทียบเรือหรือ JBoss หรือ WebLogin เพื่อให้ทำงานได้ใน. ดังนั้นจึงมีความสำคัญมากขึ้นในการเลือกสิ่งที่คุณต้องการและสิ่งที่ทำงานร่วมกันมากกว่าการเลือกกรอบกับการใช้งาน


ขอบคุณมากสำหรับคำตอบโดยละเอียด คำถามบางอย่างเกี่ยวกับ knockout.js: 1) มีชั้นข้อมูลบางประเภทเพื่อให้โมเดลอยู่ในส่วนหน้า / แบ็กเอนด์ในการซิงค์หรือไม่ 2) การสนับสนุนในการรวมเทมเพลตหนึ่งเข้ากับอีกเทมเพลตหนึ่งเป็นอย่างไร (อาจใช้ร่วมกับ requireJS) 3) การใส่ไฟล์ทั้งหมด (โมเดลมุมมองตัวควบคุมตัวช่วย ฯลฯ ) แยกจากกันและในโฟลเดอร์ต่างๆเป็นเรื่องง่ายหรือไม่? นอกเหนือจากคำถามเหล่านี้ฉันตั้งค่าคำตอบของคุณเป็นยอมรับเนื่องจากคุณให้ข้อมูลมากมาย
Christopher Will

@Christopher จะขอบคุณ! 1. ) เช่นเดียวกับ Backbone ที่ทิ้งไว้ให้คุณดูการผูกสิ่งที่น่าพิศวงจะมอบให้คุณสำหรับ REST-> การผูกโมเดล มีตัวอย่างบางส่วนในเอกสาร - knockoutjs.com/documentation/json-data.htmlหรือคุณสามารถใช้ KnockBack เพื่อรวม Backbone's REST-> Model ประชากร
เนท

2. ) ขึ้นอยู่กับความหมายของคุณ - สิ่งที่น่าพิศวงมีการผูกข้อมูลในตัวที่ช่วยให้คุณนำคอลเล็กชันจากแบบจำลองผูกกับแท็กรายการหรือแท็กตารางและสำหรับแต่ละเทมเพลตที่แสดงผลเทมเพลตที่ระบุ สำหรับเนื้อหาขนาดใหญ่เช่นวิธีสร้างมุมมองโดยรวมและสลับออก - นั่นยังค่อนข้างเป็นคู่มือ (อย่างน้อยวิธีที่ฉันทำก็ยังคงเรียนรู้) - RequireJS w / ปลั๊กอินข้อความช่วยให้ทำสิ่งนี้ได้ง่ายขึ้นเล็กน้อย แต่คุณยังต้องระบุตรรกะและสลับ divs - ฉันแค่ทำสิ่งนี้ในวิธีการที่ตอบสนองต่อเส้นทางของฉัน คุณอาจสามารถวางสายกิจกรรม Knockout เพื่อทำสิ่งนี้ได้
เนท

3. ) RequireJS คือสิ่งที่ช่วยให้คุณทำสิ่งนี้ได้
เนท

ขอบคุณเนท ฉันคิดว่าฉันจะลอง KnockBack .. ฟังดูมีแนวโน้มดี และแน่นอนกับไลบรารีที่คุณกล่าวถึงเช่นกัน (requireJS ทางแยกและอื่น ๆ )
Christopher Will

8

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

คุณสมบัติหลักที่คุณจะหลงรัก:

  1. ชุมชนที่มีการศึกษาและทีมงานที่คิดค้นรูปแบบการออกแบบที่สมบูรณ์แบบ อนุสัญญาที่ยิ่งใหญ่และสถาปัตยกรรมแบบแยกส่วน / เชิงวัตถุ ด้วยทัศนคติการเขียนโปรแกรม CrossBrowser :)
  2. โครงสร้าง MV * สร้างวิดเจ็ต UI ด้วยเทมเพลต. htm ภายนอกและสำหรับการใช้งานจริงสร้างจาวาสคริปต์และเทมเพลตทั้งหมดของคุณให้เป็น. js ขนาดเล็กและเล็ก
  3. สร้างคลาสที่มีการสืบทอด ตัวตั้งค่าคุณสมบัติเครื่องมือฟังก์ชันมากมาย
  4. กลไก pub / ย่อย (ตั้งชื่อหัวข้อใน dojo)
  5. การควบคุม UI จำนวนมากตั้งแต่การควบคุมรูปแบบการตรวจสอบความถูกต้องกล่องโต้ตอบ / คำแนะนำเครื่องมือไปจนถึงแผนภูมิที่โดดเด่นและปรับแต่งได้สูง (แต่น้ำหนักเบา) และโซลูชันตารางข้อมูล
  6. ระบบทดสอบหน่วยที่ดีชื่อ DOH นอกจากนี้ยังมีหุ่นยนต์เพื่อสร้างการทำงานของเมาส์ / คีย์บอร์ดอีกด้วย
  7. เครื่องมือค้นหา (เช่น JQuery) ชื่อ NodeList พร้อมคุณสมบัติ jquery ทั้งหมดและแม้แต่ปลั๊กอินจำนวนมาก
  8. และส่วนที่ดี แต่ไม่สมบูรณ์ มีโมดูล JsonRest เพื่อใช้กับบริการ REST ของคุณ เป็นเครื่องมือที่มีประโยชน์ แต่ขาดคุณสมบัติมากมาย

เพื่อเอาชนะปัญหาเหล่านี้เราได้พัฒนาตัวสำรวจ AJAX การจัดการข้อผิดพลาดและโซลูชันสากลการโหลดและการแจ้งเตือน เราทำได้อย่างง่ายดายโดยใช้รูปแบบและโครงสร้าง dojo framework หากคุณไม่ต้องการทำเช่นนั้นบางทีคุณอาจต้องใช้กรอบงานอื่นสำหรับส่วนนี้

เมื่อมองไปที่ SPA ที่ยอดเยี่ยมในเว็บคุณจะพบว่าทั้งหมดนั้นได้รับการปรับแต่งและใช้หลายเฟรมเวิร์ก แต่ประสบการณ์ของเรากับ Dojo คนเดียวนั้นยอดเยี่ยมมาก ดังนั้นฉันขอแนะนำให้คุณอย่าคิดถึงกรอบการทำงานอื่น ๆ เนื่องจากทั้งหมดนั้นไม่สมบูรณ์สำหรับสปา แต่ในที่สุดคุณก็มีตัวเลือกอื่น (ซึ่งฉันไม่แนะนำและไม่มีข้อมูลรายละเอียด) ไปกับเฟรมเวิร์ก JAVA ที่สามารถสร้าง SPAs โดยสร้าง UI และจาวาสคริปต์โดยอัตโนมัติ


สวัสดี! ตอนนี้คุณใช้ Dojo หรือไม่? คุณมีบล็อกเกี่ยวกับ Dojo หรือไม่?
Dunaevsky Maxim

ไฮ! ใช่เรายังคงใช้มันสำหรับผลิตภัณฑ์เดียวกันและเราดูแลรักษามัน มีการเขียนกรอบงานภายในองค์กรไว้ที่ด้านบนของ dojo และเราจะเพิ่มเข้าไปในแต่ละวัน .. ไม่ฉันไม่มีบล็อกสำหรับสิ่งนั้น หากคุณกำลังจะเริ่มด้วยปัจจุบันถือว่าเป็นเครื่องมือเก่า พวกเขายังคงทำงานบน Dojo 2.0 แต่ตอนนี้อาจจะดีกว่าถ้าใช้ตัวเลือกอื่น ๆ เรามี React / Angular ที่ด้านบนสุดของรายการ
Unicornist
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.