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

Question

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

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

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

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

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

Заранее благодарим за ваши впечатления и идеи!

Answer 1

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

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

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

Answer 2

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

Answer 3

Основа Yesod основана на языке haskell.

Answer 4

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

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

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

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

Answer 5

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

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

Основы, основанные на продолжении, такие как ocsigen (ocaml) и приморский (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/

Answer 6

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

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

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

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

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

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

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

6. Embrace the Ecosystem. Meteor является открытым исходным кодом и интегрируется с существующими инструментами и инфраструктурами с открытым исходным кодом.

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