Чому веб-рамки не є простими, елегантними та веселими, як мови програмування? [зачинено]

Коли я думаю про майже будь-яку мову програмування - на зразок C, C ++, PHP, SQL, JavaScript, Python, ActionScript, Haskell, Lua, Lisp, Java і т. Д. - я, як приголомшливо, хотів би розробити комп'ютерну програму за допомогою будь-якої цих мов.

Але коли я замислююся над веб-рамками (я роблю здебільшого PHP) - на кшталт Cake, CI, Symfony, Laravel, Zend, Drupal, Joomla, Wordpress, Rails, Django тощо - я як бог ні.

Чому не існує веб-рамок, які надають мені прості, веселі та потужні конструкції, як мова програмування?

У мене це питання теж було роками, хоча я перебуваю на стороні Python. У мене немає єдиного пояснення цього явища, але ось мої думки з цього приводу:

• Веб-фреймворки повинні мати справу з мовою розмітки XMLish - HTML, що є частиною поточної веб-тріади HTML-CSS-JavaScript в режимі клієнт-сервер. Він означає три мови, які взаємодіють між собою, DOM браузера та модель виконання (та модель безпеки). Насправді кожен фрагмент функціональності ("модуль") повинен мати свій код на всіх трьох мовах. Щоб додати до цього, мова селектора jQuery стає ще однією мовою, про яку потрібно піклуватися.

• У HTML + CSS відсутня інтуїтивно зрозуміла та математично обгрунтована модель розміщення об'єктів. Навіть Tcl / Tk краще IMHO у визначенні геометрійних менеджерів. Це не дозволяє програмісту чітко визначати візуалізацію HTML і покладатися на удачу: "можливо, цей дів буде працювати більшу частину часу в більшості браузерів". З цього боку є деякі позитивні зрушення, наприклад, HTML5 та Twitter Bootstrap.

• Веб-технології органічно виросли, і з нею виросли рамки, тому їх форма не потрібна елегантна. Це означає, що програміст повинен пам’ятати API, які є неоптимальними, будуть застарілими тощо

• Веб-браузери все ще мають незначну несумісність, і це додає непотрібної складності веб-рамкам

• Загальна архітектура - безлад. Це розділене мислення бек-енд-фронту, які пов'язані разом із запитом / відповіддю на стороні бекенда та керованим даними візуалізацією на передній частині. Порядок виконання не дуже чітко визначений (синхронізація вимагає зусиль) та розміщення стилів, сценаріїв до належних слотів (майже всі js-сценарії потрібно розмістити до кінця тегу тіла тощо). Кешування - ще один аспект, який охоплює від бекенда до проксі (ів) до переднього кінця. І я навіть не згадую обробку форми!

• Веб-фреймворк обов'язково займається більшістю цих складностей, додаючи безліч понять і обробляючи труби.

• Робота в веб-індустрії зазвичай розподіляється між графічним дизайнером, веб-дизайнером / веб-програмістом та програмістом, який є мінімальним набором ролей. Перші два не обов'язково мають навички програмування, тому їм потрібні різні абстракції та інструменти, а рамки повинні також полегшувати їх

Підводячи підсумок, веб-рамки намагаються абстрагувати велику складність (самі зростаючі комплекси), але це дуже важко досягти через швидкий розвиток стандартів та інших рухомих частин. Мови програмування набагато зріліші, тому що зазвичай не проблема не використовувати нові функції.

Думаю, зробити зручну веб-рамку можна буде лише після того, як будуть встановлені стандарти GUI (охоплюють різні режими роботи, наприклад мобільні пристрої), і базові технології будуть досить стабільними.

Веб-фреймворкам бракує простих конструкцій, оскільки в області веб-технологій таких речей немає. Абстракції нижнього рівня обов'язково просочуються на більш високий рівень.

Я думаю, що багато чого стосується обмежень WWW. Зокрема, немає вбудованого способу зберігання стану між сервером і клієнтом. Клієнт запитує деякі дані, сервер надає їх і з'єднання закрите. Таким чином, всі ці веб-платформи повинні скласти власний метод збереження стану між викликами сервера.

Мені довелося зробити невеликий веб-додаток один раз, і в той час я ніколи не робив жодного серверного / клієнтського програмування. Мені знадобилося кілька тижнів, щоб все зрозуміти, і найважча частина намагалася змусити мене обстежити, де знаходиться клієнт і сервер.

Чи це колись зміниться? Я сумніваюся в цьому. Це вимагало б кардинальних змін в архітектурі Інтернету.

Взагалі, причини можуть бути безліч:

1. Розрив абстракції більший у випадку рамки. Сучасна процедура / мова OOP забезпечує абстрагування машини, але зберігає деякі машинні конструкції (наприклад, призначення змінної деяких даних / записування деяких даних у блок пам'яті або виклик процедури тощо); розрив не такий великий, в той час як рамки намагаються забезпечити абстракцію для розробки веб-додатків, які оперують набагато більшою кількістю концепцій.
2. Рамки можуть бути складнішими з точки зору програміста; це як наслідок першого пункту. Мова програмування досить простий, він має прості конструкції (якщо, наприклад, для змінних, процедур тощо). Також стандартна бібліотека резюмує прості речі, такі як запис в IO або використання колекцій. У стандартній бібліотеці вона також дуже модулюється, мало або взагалі немає зв'язку між модулем з іншим; вам не потрібно знати IO, щоб використовувати колекції або навпаки. Зауважимо, що якщо деякі частини стандартної бібліотеки є досить складними, вони розміщуються в міні-рамках (наприклад, Framework Collection Collection або Framework Executors). У випадку з рамкою вам потрібно знати весь потік, всі частини, щоб використовувати каркас на повну силу. Також aa Framework - це вже вбудований додаток;
3. Не стільки ресурсів закладено в рамки, скільки в мові програмування. Я вважаю, що цьому не потрібно ніяких пояснень.

Ах, але ви бачите, що саме в цьому проблема. Рамки не повинні бути завершеними Тьюрінгом. Вони повинні складатися з більш обмежених абстракцій, які можуть бути складені разом для виконання конкретного набору завдань в стислій формі. Тому всі ці рамки, про які ви згадали, не цікаві саме тому, що вони не містять обмеженого набору абстракцій. Вони пропонують витікаючі абстракції, ніж самі по собі складають абстрактну машину, що більш ніж ймовірно завершує Тьюрінга. Поняття " дивні машини " - це найближче, про що я думаю. Усі ці рамки - це "дивні машини" для веб-додатків, а "дивна машина" - це протилежність тому, що має бути рамка.