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

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

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

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

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

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

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

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

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

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

Блокировка

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

Гибкость

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

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

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

Джанго против Struts.

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

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

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

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

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

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

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

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

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

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

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

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

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