Почему преобладают веб-фреймворки, основанные на действиях?

фреймворки на основе компонентов, такие как Wicket, Tapestry, JSF или ASP.Net Web Forms, стали более популярными за последние годы.

[Нужна цитата]?

Я серьезно сомневаюсь в этом утверждении. MVC захватил сферу блогов и твиттеров .Net. Очень сложно найти кого-то, кто сказал бы «мы будем использовать веб-формы для нашего следующего проекта».

MVC лучше соответствует природе Интернета без сохранения состояния. Компонентные каркасы - это абстракция, которую веб-разработчики не хотели.

Почему вещи популярнее? Причин несколько: хорошее взаимодействие с пользователем, быстрый цикл разработки, дешевые вещи и т. Д.

Но иногда

самый громкий

или самый раскрученный (рельсы, хотя это здорово ;-))

или самый высокомерный (яблоко)

или вещи с самым агрессивным маркетингом (Microsoft)

победит.

Это называется эволюцией.

Кстати: я с Thevs. Фреймворки на основе компонентов будут окончательными победителями (например, GWT / Vaadin или wicket).

Инерция. После того, как вы много вложили в одну технологию, становится все труднее перейти на что-то лучшее. И это не в 10 раз лучше, потому что тогда все (даже генеральный директор) увидели бы, что изменение необходимо.

Я считаю, что это потому, что фреймворки, основанные на действиях, дают разработчикам (и дизайнерам) больше контроля над внешним видом страницы. Компонентные фреймворки пытаются (безуспешно, ИМХО) скрыть тот факт, что Интернет - это Интернет. Они пытаются сделать веб-программирование чем-то вроде программирования собственного инструментария виджетов рабочего стола, такого как WinForms или Cocoa.

Но Интернет очень, очень отличается от этого. Я думаю, что фреймворки, основанные на действиях, популярны, потому что они это признают.

ИЗМЕНИТЬ

Очевидно, некоторые люди неправильно поняли, что я имею в виду, поэтому позвольте мне пояснить. Я НЕ критикую веб-приложение, которое кажется пользователям функционирующим как настольное приложение. У меня абсолютно нет проблем с этим.

Я говорю о основной методологии и философии кодирования. Каждый тег в системе библиотеки тегов отображает HTML определенным образом, аналогично виджету в библиотеке программирования для настольных компьютеров, такой как Cocoa или WinForms. Некоторые системы позволяют настраивать отображаемый HTML, но иногда это может быть нетривиальной задачей. Он будет отображать классы CSS и т. Д., Над которыми вы либо мало контролируете, либо должны прилагать особые усилия для контроля. Он претендует на роль черного ящика, но этого не может быть, потому что, если вы хотите стилизовать визуализированный HTML или нацелить его на JavaScript, вы должны понимать его структуру и так далее.

Я подозреваю, что разработчики используют фреймворки MVC как простой способ раскрытия сервисов, а не как фреймворки веб-приложений на основе действий (с моей стороны это чистое предположение). т.е. они используют их для запросов AJAX. Я бы предсказал, что концепция фреймворков, основанных на действиях, незаметно исчезнет в течение следующих двух лет, вместе с (в некоторой степени) концепцией MVC в этом контексте.

Я думаю, вы только видите эти фреймворки, которые видны повсюду. Но большинство программистов используют собственные (настраиваемые) или гораздо более простые модели фреймворка (например, ExtJS или JQuery) и молча выполняют свою работу.

РЕДАКТИРОВАТЬ: Кстати, я думаю, что модель MVC пытается имитировать старую и, вероятно, устаревшую модель разделения бизнеса / презентации, которая была предложена для устаревших приложений некоторое время назад. Я не вижу будущего для этой модели (через 2-3 года). AJAX уже меняется во всех отношениях, с которыми вы работаете с серверной частью.