รีบไปที่ฝั่งไคลเอ็นต์ในการพัฒนาเว็บ

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

เหตุผลที่เป็นเช่นนั้น? ใหม่และ "กระจาย" ลูกค้าฝั่งพัฒนาใน HTML5 / JS อาจจะดีกว่าโซลูชั่นฝั่งเซิร์ฟเวอร์ขนาดใหญ่และคิดว่าดีได้อย่างไร

นี่คือความจริง:

รีบไปที่ฝั่งไคลเอ็นต์ในการพัฒนาเว็บ

แต่มันไม่ได้ จำกัด อยู่ที่ฝั่งไคลเอ็นต์ แต่เป็นการเคลื่อนไหวสแต็คแบบเต็ม

ฉันรู้ว่ามันอาจจะน่าแปลกใจ ได้โปรดฟังฉันออก

เหตุผลที่เป็นเช่นนั้น? ใหม่และ "กระจาย" ลูกค้าฝั่งพัฒนาใน HTML5 / JS อาจจะดีกว่าโซลูชั่นฝั่งเซิร์ฟเวอร์ขนาดใหญ่และคิดว่าดีได้อย่างไร

ก่อนอื่นทั้งคู่ต่างก็มีความคิดที่ดี

ประการที่สองเพราะมันดีกว่า

คำถามที่ดี.

แต่ "ดีกว่า" เป็นอัตวิสัยดังนั้นคำตอบสำหรับคำถามของคุณคืออะไรดีกว่าโดยเฉพาะ?

ไปที่คำถามอีกครั้ง:

"การกระจาย" การพัฒนาฝั่งไคลเอ็นต์ใน HTML5 / JS อาจเหนือกว่าโซลูชันฝั่งเซิร์ฟเวอร์ขนาดใหญ่ได้อย่างไร

Because small is nimble.
And big is clunky.

มันคือความยืดหยุ่น

ดูเหมือนจะไม่เป็นเรื่องใหญ่ ทำมัน? มีความยืดหยุ่น

อย่างไรก็ตามความยืดหยุ่นรองรับทุกอย่าง หนึ่งการปรับปรุงความยืดหยุ่น - ปรับปรุงทุกอย่าง

การบำรุงรักษา ขยาย scalability modularity การใช้งาน UX

และมันก็เร็วกว่าที่จะใช้ นี่คือความจริง เร็วขึ้นและดีขึ้น

This is why Windows 8 made JS a first-class citizen.

HTML5 - JS ไม่ใช่แฟชั่นและจะไม่หายไป เราเห็นเฉพาะเมล็ดพันธุ์ของเทคโนโลยีที่จะเติบโตเพื่อมอบเนื้อหาในการคำนวณและพฤติกรรมการโต้ตอบกับแท็บเล็ต แท็บเล็ต

โทรศัพท์สมาร์ทโฟนเป็นสื่อที่มีการนำมาใช้เร็วที่สุดตั้งแต่ทีวีในปี 1950 ตอนนี้เรามีสมาร์ทโฟนไม่เพียง - เรามีแท็บเล็ต

มีการพัฒนาที่ Mozilla และ Windows แล้วระบบปฏิบัติการที่จะทำงานบนอุปกรณ์ในอนาคตในตลาดของพวกเขา -> HTML / JS

โซลูชั่นและนวัตกรรมจำนวนมากยังคงอยู่

สแต็กเต็มของ JS เกิดขึ้นตามความยืดหยุ่น

ฉันหวังว่าจะช่วย

เรื่องนี้มีสองด้านเสมอ; ทั้งฝั่งเซิร์ฟเวอร์และรหัสฝั่งไคลเอ็นต์มีข้อดีข้อเสีย

ข้อดีของการเขียนสคริปต์ฝั่งไคลเอ็นต์รวมถึง:

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

แต่สคริปต์ฝั่งเซิร์ฟเวอร์ก็มีข้อดีมากมายเช่นกัน:

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

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

hype ที่สังเกตมาจากการรวมกันของสองการพัฒนาล่าสุด:

1. HTML5 และโคโรน่าของเทคโนโลยีที่เกี่ยวข้อง มันใช้เวลานานเกินไป แต่ในที่สุดเราก็มีมาตรฐานที่มีทุกสิ่งที่คุณต้องการในการสร้างเว็บแอปพลิเคชันที่เหมือนเดสก์ท็อปแบบไดนามิกโดยไม่มีการแฮ็กแฮ็คและเบราว์เซอร์หลัก ๆ
2. พลังการประมวลผลที่มีอยู่ พีซีเดสก์ท็อปสินค้าโภคภัณฑ์ในปัจจุบันมีประสิทธิภาพเทียบเท่ากับเว็บเซิร์ฟเวอร์ระดับเริ่มต้นโทรศัพท์มือถือระดับลูกค้าเป็นคอมพิวเตอร์ตั้งโต๊ะในทางปฏิบัติของปี 2548 และการใช้งานจาวาสคริปต์ที่ทันสมัยมีประสิทธิภาพเพียงพอที่จะปรับสมดุลประสิทธิภาพ: ทรัพยากร

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

ฝั่งเซิร์ฟเวอร์จะอยู่รอบ ๆ เสมอ คุณไม่สามารถนั่งเคียงข้างลูกค้าสำหรับทุกสิ่ง ตัวอย่างเช่นคุณไม่ต้องการใช้การออกแบบ Backbone.js MVC สำหรับไมโครคอนโทรลเลอร์ของคุณส่งพารามิเตอร์แบบเรียลไทม์จากเครนเหนือศีรษะของโรงงานผลิต

อย่าเชื่อโฆษณา

ฉันได้ทำการสลับในปี 2009 จากกรอบงาน PHP ฝั่งเซิร์ฟเวอร์ไปยังโซลูชัน ExtJS ฝั่งไคลเอ็นต์ที่เชื่อมโยงกับบริการเว็บฝั่งเซิร์ฟเวอร์

เหตุผลของการย้ายถิ่นสำหรับฉันคือ:

1. ความปลอดภัยที่ดีขึ้นด้วยการลดจำนวนจุดสิ้นสุดและรหัสบนเซิร์ฟเวอร์
   ด้วยการย้ายไปยังบริการบนเว็บคุณจะตรวจสอบอินพุตที่ขอบเขตบริการเว็บและควบคุม I / O ของเซิร์ฟเวอร์ได้อย่างแม่นยำยิ่งขึ้น ไม่มีเลเยอร์ UI ฝั่งเซิร์ฟเวอร์ที่จะทำให้ยุ่งเหยิงสถาปัตยกรรมความปลอดภัยของคุณ
2. ปรับปรุงประสิทธิภาพเนื่องจากมีการปัดเศษเซิร์ฟเวอร์น้อยลง
   สถาปัตยกรรมเปลี่ยนแปลงเพื่อให้การดึงข้อมูลสามารถเกิดขึ้นได้น้อยลงและข้อมูลสามารถแคชภายในเครื่องด้วยการแสดงผล UI ที่ไม่ต้องการการไปกลับเลย Roundtrips เป็นสิ่งที่ทำลายประสิทธิภาพการทำงานของเว็บแอป
3. ปรับปรุงประสิทธิภาพเนื่องจากความสามารถในการแคชของ UI
   UI เลเยอร์ UI สามารถโฮสต์บน CDN ได้อย่างสมบูรณ์ ฉันได้สร้างแอปพลิเคชันเว็บแบบออฟไลน์ด้วยการผลักรหัส UI ลงในแคชแอป HTML5
4. ความเที่ยงตรงที่สูงขึ้นของ UI (ตัวควบคุมฝั่งไคลเอ็นต์ที่หลากหลาย)
5. นักพัฒนาบุคคลที่สามสามารถใช้ API เดียวกับ Front-end ของฉันใช้และฉันสามารถใช้ API ข้ามโมดูลได้อย่างง่ายดายหากพวกเขาแบ่งปันคุณสมบัติ
   นี่หมายถึงการพัฒนาน้อยกว่า QA เอกสารประกอบ ...
6. ฉันชอบการเขียนโปรแกรมใน JavaScript ดีกว่า PHP, Python หรือ Java

แต่อย่าทำผิดพลาดสิ่งที่เกิดขึ้นตอนนี้เป็นเรื่องจริง มันจะระเบิดและเว็บแอปจำนวนมากจะใช้สถาปัตยกรรม UI ฝั่งเซิร์ฟเวอร์อีกครั้ง

อีกปัจจัยหนึ่งที่ผลักดันความกระตือรือร้นในการแก้ปัญหาฝั่งไคลเอ็นต์คือการเติบโตของแอพมือถือ หากคุณสร้างเว็บไซต์อย่างหนักตาม JavaScript ฝั่งไคลเอ็นต์และ AJAX และสร้างแอพ iOS และ Android แบบดั้งเดิมมีโอกาสที่ดีที่ทั้งสามสามารถใช้บริการ REST เดียวกันเพื่อทำข้อมูลทั้งหมดได้อย่างเต็มที่ .

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

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

เหล่านี้คือเหตุผลที่แม้ว่าจะมีความไม่แน่นอนเทคโนโลยีด้านลูกค้าได้รับความนิยมมากขึ้น นอกจากนี้ JS และ HTML / CSS ยังรองรับเบราว์เซอร์ที่ทันสมัยเกือบทั้งหมด

แอปพลิเคชั่นสองส่วนนี้ไม่สามารถอยู่แยกจากกันได้ และอินเทอร์เน็ตดูเหมือนจะไม่ถูกทิ้งไว้ที่ใดในอนาคตอันใกล้
ฉันไม่คิดว่าbig server-side frameworksมันจะหายไปเหมือนกัน จะมี บริษัท ที่สามารถจ่ายได้และจะใช้ประโยชน์ที่สำคัญของพวกเขา

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

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

ความตื่นเต้นที่คุณคาดไม่ถึงมานานแล้ว ฉันเห็นเมื่อ Shockwave และตัวต่อแฟลชถูกแนะนำมี "การกลับมาครั้งใหญ่" ของส่วนติดต่อผู้ใช้ที่หลากหลายเมื่อไลบรารี js ที่ซับซ้อนถูกจัดส่งครั้งแรกกับ motools จากนั้นจึงมี jQuery (ฉันเริ่มใช้พวกเขาตามลำดับนี้) มี Flex และ JavaFX แต่ไม่มีใครสามารถมีส่วนแบ่งตลาดใหญ่ได้ บางคนต้องการปลั๊กอินที่มักจะเปิดเผยผู้ใช้ปลายทางถึงช่องโหว่ด้านความปลอดภัยส่วนอื่นอาจไม่ทำงานบนฝั่งไคลเอ็นต์เนื่องจากการตั้งค่าแบบกำหนดเองบางอย่าง (เช่น JavaScript ถูกปิดใช้งานในเบราว์เซอร์ของลูกค้า)

ในอีกด้านหนึ่งโซลูชันฝั่งเซิร์ฟเวอร์มักจะเขียนเพียงครั้งเดียว คุณไม่ต้องกังวลว่าทุกอย่างจะล้มเหลวและจะต้องเขียนใหม่เมื่อ Firefox / Chrome / IE / Opera ใหม่ได้รับการจัดส่งแล้ว คุณไม่จำเป็นต้องกังวลว่าลูกค้าจะพยายามดัดแปลงแอปของคุณและ / หรือทำให้ข้อมูลเสียหาย

เห็นด้วยอย่างแน่นอนกับความรู้สึกของคุณ ฉันยังเชื่อว่านอกเหนือจากสิ่งที่คุณกำลังบอกว่าเราจะเห็นการลดลงอย่างมากในส่วนที่เหลือและเพิ่มขึ้นอย่างมากใน websockets สำหรับวิธีหลักที่เราเห็นเว็บไซต์สื่อสารกลับไปยังเซิร์ฟเวอร์ของพวกเขา Vert.x, Node.js ฯลฯ ฝั่งเซิร์ฟเวอร์ทั้งหมดรวมทั้งฝั่งไคลเอ็นต์กำลังย้ายไปที่การเขียนโปรแกรมที่ขับเคลื่อนด้วยเหตุการณ์ Java EE, PHP, Rails และอื่น ๆ พวกเขาทั้งหมดต้องปรับตัวหรือจะสูญเสียอย่างรวดเร็ว