Какие существуют фреймворки для веб-приложений следующего поколения? Как они выходят за рамки RoR, Django и т. Д.? - PullRequest
3 голосов
/ 12 июля 2010

В настоящее время самые популярные платформы веб-приложений включают Ruby-on-Rails , Django и различные PHP-фреймворки, такие как Drupal и Joomla . Тем не менее, я читал о некоторых «веб-приложениях» следующего поколения, которые утверждают, что по-разному подходят к веб-разработке.

Возможно, самым известным примером является фреймворк Seaside , построенный на языке Smalltalk. На странице About перечислены 4 ключевых функции:

  1. Программная генерация HTML
  2. Обработка запросов на основе обратного вызова
  3. Встроенные компоненты
  4. Модальное управление сессиями

Поскольку я разрабатываю довольно сложное имитационное веб-приложение, которому нужны функции, схожие с настольным приложением, такие как сложные интерактивные формы, поток задач, множество диаграмм и визуальных элементов, а также гибкость и повторное использование пользовательского интерфейса (множество виджетов). ), Функции Seaside 2, 3 и 4 звучат довольно привлекательно.

Таким образом, я хотел бы услышать от других (продвинутых) веб-разработчиков о том, какие существуют платформы «следующего поколения» с открытым исходным кодом для веб-приложений, что делает их «лучше», чем более знакомые инструменты, такие как Django / RoR, и что с помощью этих новых инструментов можно создавать приложения, которые было бы трудно / болезненно делать со старыми платформами, например Я понимаю, что управление сеансами / состояниями Seaside на основе продолжений делает приложения с сохранением состояния намного проще, чем глобальные переменные сеанса. Насколько это полезно?

Заранее спасибо за ваш опыт и понимание!

Ответы [ 6 ]

3 голосов
/ 28 апреля 2013

MFlow - это веб-фреймворк, написанный на Haskell, в стиле Seaside, но без проблем продолжений (проблемы с постоянством и масштабируемостью)

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

Основанные на продолжениях фреймворки, такие как ocsigen (ocaml) и seaside (smalltalk), прекрасно обрабатывают кнопку назад, они сохраняют состояние в обычных переменных, и навигацию можно понять, прочитав код. И они в основном RESTFul до определенного уровня. Но эти структуры не масштабируемы и имеют проблемы с постоянством из-за врожденных проблем продолжений.

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

В MFlow не только каждая страница, но и вся навигация безопасна во время компиляции, и она не разделяет вышеуказанные проблемы. Он обладает хорошими свойствами основанных на продолжениях фреймворков, но он масштабируемый, так как вместо продолжений он использует ведение журнала и возврат. Он использует стандартные веб-библиотеки Haskell: WAI, formlets, stm, blaze-html. Имеет систему сменных автономных компонентов.

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

module Main where
import MFlow.Wai.Blaze.Html.All

main= do
  addMessageFlows  [("sum", transient . runFlow $ sumIt )]
  wait $ run 8081 waiMessageFlow

sumIt= do
  setHeader $ html . body
  n1 <- ask $  p << "give me the first number"  ++>  getInt Nothing
  n2 <- ask $  p << "give me the second number" ++>  getInt Nothing
  ask $ p << ("the result is " ++ show (n1 + n2)) ++> wlink () << p << "click here"

Состояние можно сделать постоянным с небольшими изменениями.

http://hackage.haskell.org/package/MFlow

Здесь приведены примеры и инструкции: http://haskell -web.blogspot.com.es /

3 голосов
/ 13 июля 2010

Побережье отлично подходит для нас. Мы разрабатываем на Pharo и разворачиваем его на VPS с Gemstone OODB, и в настоящее время мы развиваемся примерно в пять раз быстрее, чем моя бывшая компания в ASP.NET MVC.

Комбинация без кода базы данных, сгенерированного HTML (без шаблонов) и JavaScript (Scriptaculous / jQuery / RaphaelJs) работает очень хорошо.

Пункт 1 действительно важен. Я никогда не видел систему на основе шаблонов, которая была бы достаточно СУХОЙ (хотя, вероятно, есть основанная на lisp).

Я также играл с ранними выпусками капучино, и было бы хорошо, если у вас есть опыт работы с какао / nextstep, но это (через несколько месяцев после первого публичного релиза) не было достаточно закончено для нас.

3 голосов
/ 12 июля 2010

Фреймворк Yesod, основанный на языке haskell.

2 голосов
/ 12 июля 2010

Python-эквивалентом Seaside Framework от Smalltalk является Nagare - похоже, что это способная система, хотя в настоящее время документация непоследовательна по глубине и ширине, и я не нахожу много историй / опыта разработчиков сэто онлайн.Также интересно, что для поддержки продолжений используется Stackless Python .

2 голосов
/ 12 июля 2010

Честно говоря, до тех пор, пока вы обращаетесь к каждому взаимодействию пользовательского интерфейса с сервером и обратно, вы никогда не будете получать "настольные" возможности. Я в основном отказался от серверных фреймворков. Мои веб-приложения - это JavaScript и веб-сервисы, где я стараюсь минимизировать объем серверного кода. Осталось лишь немногое, я обернулся в Zend Framework, но слой сохранения и проверки данных действительно не требует такого большого количества кода.

Я использую ExtJS для кода javascript, но есть много хороших структур javascript ( Cappuccino , SproutCore , GWT , Додзё , ...).

Все действительно богатое взаимодействие в конечном итоге оказывается javascript, поэтому, если вы собираетесь выбрать платформу, выберите ту, которая действительно хорошо интегрируется с javascript. Очевидно, что инструменты Javascript имеют преимущество. GWT, насколько я понимаю, волшебен тем, что это не javascript, но вы можете притворяться, что не сталкивались с проблемами. Порт javascript в Quake II - это проект GWT, так что он о чем-то говорит.

1 голос
/ 03 марта 2015

Я считаю, Meteor - это настоящий веб-фреймворк следующего поколения. Как следует из названия, это убивает динозавров.

Почему следующего поколения? Позвольте мне перечислить некоторые его особенности, взятые из его документации .

  1. Данные о проводе. Метеор не отправляет HTML по сети. Сервер отправляет данные и позволяет клиенту отображать их.

  2. Один язык. Meteor позволяет писать как клиентскую, так и серверную части вашего приложения на JavaScript.

  3. База данных везде. Вы можете использовать те же методы для доступа к вашей базе данных с клиента или сервера.

  4. Компенсация задержки. На клиенте Meteor предварительно выбирает данные и моделирует модели, чтобы они выглядели так, как будто вызовы серверных методов мгновенно возвращаются.

  5. Реактивность полного стека. В Метеоре в реальном времени по умолчанию. Все слои, от базы данных до шаблона, обновляются автоматически при необходимости.

  6. Охватите экосистему. Метеор с открытым исходным кодом и интегрируется с существующими инструментами и средами с открытым исходным кодом.

  7. Простота равна производительности. Лучший способ сделать что-то простым - это сделать его простым. Основной функционал Meteor имеет чистые, классически красивые API.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...