ทำไมเว็บเฟรมจึงไม่เรียบง่ายสง่าและสนุกเหมือนภาษาโปรแกรม? [ปิด]

เมื่อฉันคิดถึงภาษาการเขียนโปรแกรมใด ๆ - เช่น C, C ++, PHP, SQL, JavaScript, Python, ActionScript, Haskell, Lua, Lisp, Java และอื่น ๆ - ฉันก็ยอดเยี่ยมฉันชอบที่จะพัฒนาแอปพลิเคชั่นคอมพิวเตอร์โดยใช้ ของภาษาเหล่านั้น

แต่เมื่อฉันนึกถึงเว็บเฟรมเวิร์ก (ส่วนใหญ่ฉันทำ PHP) - เช่นเค้ก, CI, Symfony, Laravel, Zend, Drupal, Joomla, Wordpress, Rails, Django และอื่น ๆ - ฉันไม่ชอบพระเจ้าเลย

ทำไมไม่มีเฟรมเวิร์คของเว็บที่ให้โครงสร้างที่เรียบง่ายสนุกสนานและทรงพลังเช่นภาษาโปรแกรม?

ฉันมีคำถามนี้มาหลายปีเช่นกันแม้ว่าฉันจะอยู่ฝั่ง Python ก็ตาม ฉันไม่ได้มีคำอธิบายเดียวสำหรับปรากฏการณ์นี้ แต่นี่คือความคิดของฉันในเรื่อง:

• เว็บเฟรมเวิร์กต้องจัดการกับภาษามาร์กอัป XMLish - HTML ซึ่งเป็นส่วนหนึ่งของ HTML-CSS-JavaScript web-triad ปัจจุบันในแบบไคลเอนต์ - เซิร์ฟเวอร์ มันหมายถึงสามภาษาซึ่งโต้ตอบซึ่งกันและกัน DOM ของเบราว์เซอร์และโมเดลการเรียกใช้งาน (และโมเดลความปลอดภัย) ผลการทำงานแต่ละส่วน ("โมดูล") ควรมีรหัสในสามภาษา หากต้องการเพิ่มสิ่งนี้ภาษาตัวเลือกของ jQuery กำลังกลายเป็นอีกภาษาหนึ่งที่น่าสนใจ

• HTML + CSS ไม่มีโมเดลเสียงที่ชาญฉลาดและทางคณิตศาสตร์สำหรับการวางวัตถุ แม้แต่ Tcl / Tk ก็ยังดีกว่า IMHO ในการกำหนดผู้จัดการเรขาคณิต สิ่งนี้จะป้องกันโปรแกรมเมอร์จากการกำหนดการแสดง HTML ในเงื่อนไขที่เข้มงวดและพึ่งพาโชคแทน: "บางที div นี้อาจใช้เวลาส่วนใหญ่ในเบราว์เซอร์ส่วนใหญ่" แม้ว่าจะมีการพัฒนาด้านบวกบางประการเช่น HTML5 และ Twitter Bootstrap

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

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

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

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

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

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

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

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

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

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

สิ่งนี้จะเปลี่ยนแปลงหรือไม่? ฉันสงสัยมัน. มันจะต้องมีการเปลี่ยนแปลงพื้นฐานในสถาปัตยกรรมของเว็บ

โดยทั่วไปการพูดสาเหตุอาจมีหลายประการ:

1. ช่องว่างที่เป็นนามธรรมมีขนาดใหญ่กว่าในกรอบเคส ภาษาขั้นตอน / OOP ที่ทันสมัยให้สิ่งที่เป็นนามธรรมเหนือเครื่อง แต่เก็บบางเครื่องสร้าง (เช่นการกำหนดตัวแปรบางข้อมูล / การเขียนข้อมูลบางอย่างในหน่วยความจำหรือการเรียกขั้นตอน ฯลฯ ); ช่องว่างไม่ใหญ่มากในขณะที่กรอบพยายามให้นามธรรมสำหรับการพัฒนาโปรแกรมประยุกต์บนเว็บที่ทำงานด้วยแนวคิดมากขึ้น
2. กรอบงานอาจมีความซับซ้อนมากขึ้นจากมุมมองของโปรแกรมเมอร์ นี่เป็นผลสืบเนื่องของจุดแรก ภาษาการเขียนโปรแกรมค่อนข้างง่าย แต่ก็มีโครงสร้างที่เรียบง่าย (ถ้าสำหรับตัวแปรขั้นตอน ฯลฯ ) นอกจากนี้ไลบรารีมาตรฐานยังสรุปสิ่งที่ง่าย ๆ เช่นการเขียนถึง IO หรือการใช้คอลเล็กชัน ไลบรารี่มาตรฐานนั้นถูกทำให้เป็นโมดูลมากโดยมีการเชื่อมต่อเพียงเล็กน้อยหรือไม่มีเลยระหว่างโมดูลกับอีกโมดูลหนึ่ง คุณไม่จำเป็นต้องรู้ว่า IO ใช้คอลเลกชันหรือในทางกลับกัน หากต้องการทราบว่าหากบางส่วนของไลบรารีมาตรฐานค่อนข้างซับซ้อนจะถูกวางไว้ใน mini-framework (เช่น Java Collections Framework หรือเฟรมเวิร์ก Executors) ในกรอบกรณีที่คุณต้องการทราบถึงการไหลทั้งหมดชิ้นส่วนทั้งหมดเพื่อใช้เฟรมเวิร์กที่มีความแข็งแรงเต็มที่ อีกทั้งเฟรมเวิร์ก aa เป็นแอปพลิเคชั่นที่สร้างขึ้นมาแล้ว
3. มีทรัพยากรไม่มากนักที่อยู่ในกรอบงานเหมือนในภาษาโปรแกรม ฉันเชื่อว่านี่ไม่จำเป็นต้องอธิบายใด ๆ

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