Каковы основные различия между популярными веб-фреймами?

В наши дни доступно множество фреймворков веб-приложений, почти для каждого языка. В вашем опыте, каковы их сильные и слабые стороны и уникальные возможности? Предполагая, что роскошь выбора, какие факторы приведут вас к рассмотрению одного другого другого?

Меня больше всего интересует непосредственный опыт людей с одной или несколькими фреймворками, а не исчерпывающее сравнение всего там. Надеюсь, у сообщества SO есть программисты, у которых есть хорошие и плохие впечатления от таких вещей, как Rails, ASP.NET, Django, TurboGears, или JSF. Было бы также здорово услышать, использует ли кто-либо из менее распространенных фреймворков, таких как Seaside или Weblocks.

Язык программирования является очевидным различием, но Java vs Ruby flamewar не будет очень забавным, и большинство из этих фреймворков, по-видимому, являются как минимум инвестициями в технологии, инструменты и сложность в качестве их языка выбора; поэтому меня больше интересуют такие вещи, как:

Скорость и удобство разработки
Препятствия на въезд - как с точки зрения подготовки разработчиков, так и необходимой инфраструктуры.
Lock-in - сколько кода вы могли бы сохранить, если бы вам пришлось переключать фреймворки?
Гибкость - позволяет ли структура вашей архитектуры или дизайна? (Будет ли это хорошо или плохо, вероятно, лучше всего оставить на отдельном обсуждении.)
Производительность, масштабируемость и стабильность - очевидно, в зависимости от разработчиков!

Ответ 1

Я кратко расскажу о каждой области для трех популярных фреймворков Python. Это основано только на моем личном опыте и наблюдениях.

Скорость разработки и удобство

Для TurboGears, Пилоны и Django скорость разработки примерно равна. Будучи современными структурами, легко начать работу на новом сайте и начать собирать страницы. Python отлично развивается и отлаживается, и я бы поставил любую инфраструктуру Python на более короткое время разработки, чем любая другая настройка, с которой я работал (включая PHP, Perl, Embedded Perl и С#/ASP.Net).

Барьеры для входа - обучение разработчиков и инфраструктура

Если вы знаете Python и готовы смотреть 20-минутное видеоуроки, вы можете создать довольно полный сайт типа вики с нуля, Или вы можете пройти через учебное пособие по сайтам по сайтам за 30 минут (включая установку). Это примеры TurboGears, но в двух других структурах есть почти одинаковые учебники.

Инфраструктура тестирования/разработки, которая выходит из коробки с этими фреймворками, как правило, достаточна для завершения большинства сайтов. В любой момент вы можете поменять компоненты для соответствия требованиям своей производственной среды. Например, SQLite отлично подходит для настройки ваших моделей и загрузки тестовых данных, но вы захотите установить MySQL (например) перед тем, как начать жить или хранить большие объемы данных.

Во всех случаях требования очень низки и полностью продиктованы вашими требованиями к масштабируемости, а не некоторыми особенностями структуры. Если вам удобно использовать определенный язык шаблонов или ORM, он, вероятно, подключится к нему.

Блокировочные

Это обобщенная проблема во всех средах. Когда вы выбираете язык, вы ограничиваете свои варианты повторного использования кода. Когда вы выбираете templater, вы снова заперты (хотя это легче изменить, в общем, чем другие вещи). То же самое касается вашего ORM, базы данных и т.д. Нет ничего такого, что сделало бы эти рамки специально, что поможет или затруднит блокировку.

Гибкость

Все о MVC с этими тремя структурами. Как вы сказали, это совсем другое обсуждение!

Производительность, масштабируемость и стабильность

Хорошо, если вы напишете хороший код, ваш сайт будет работать хорошо! Опять же, это проблема во всех рамках, рассмотренных различными методами разработки и, вероятно, выходит за рамки этого ответа.

Ответ 2

Django vs Struts.

Скорость разработки и удобство.

Django - запуск и запуск за время, необходимое для создания модели (в Python), определить сопоставления администратора (2-3 строки кода для каждого класса модели) и создать HTML-шаблоны для работы со стандартными представлениями мастер-детали.

Struts - нужно определить базу данных в SQL, а затем определить ORM-сопоставления в iBatis. Затем определите, протестируйте и создайте различные компоненты приложения, используя классы действий и страницы шаблонов JSP. О, и мне нужно определить EJB для перемещения данных из приложения в JSP. Все это должно было скомпилироваться, и мне нужно работать через множество деталей, чтобы получить что-то, что соответствует правилам компиляции.

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

Постоянный во всех фреймворках и языках. Это в значительной степени не имеет значения. Никакой язык или рамки по своей сути легко обучаться. Все веб-фреймворки имеют одинаковые требования к инфраструктуре.

Lock-in - сколько кода вы могли бы сохранить, если бы вам пришлось переключать фреймворки?

Это не имеет большого смысла. Если вы переключитесь с Tomcat на любой из производных Tomcat, вы можете сохранить много Java-кода. В противном случае вы обычно не сохраняете много кода при переключении фреймворка.

Гибкость. Рамки диктуют вашу архитектуру или дизайн? (Возможно, это будет хорошо или плохо, лучше всего оставить отдельное обсуждение.)

Собственно, это не отдельное обсуждение. Это точка. Рамки диктуют вашу архитектуру - и это хорошо. Действительно, структура - это код, который вам не нужно писать, тестировать, отлаживать или поддерживать. Хорошо, что ваше приложение ограничено каркасом проверенной, работоспособной структурой.

Производительность, масштабируемость и стабильность - очевидно, в зависимости от разработчиков!

Производительность - это язык (а не фреймворк). Это дизайн. В некоторой степени это также конфигурация реализации.

Масштабируемость - это рамки (а не язык). Это дизайн и настройка.

Стабильность по всем направлениям: ОС, язык, структура, дизайн, программирование, QA и конфигурация реализации.

Ответ 3

Это невероятно субъективный вопрос.. и этот тег, который вы должны добавить к своему вопросу. Как уже было предложено несколько комментариев, вы уже указали довольно хорошее руководство; что вы на самом деле спрашиваете? Там миллиард мнений о подобных вещах и, безусловно, нет правильного ответа!

Лично я начал использовать .html, перешел на php, попробовал ruby (ненавидел его), обнаружил Python/DJango.. и был счастлив с тех пор. Это очень уникальный путь, который нужно принять (возможно), поэтому ваш пробег может варьироваться:)