С широким спектром доступных фреймворков для веб-разработки всегда существует постоянный стимул «попробовать что-то новое». Следовательно, некоторые из нас торгуют одной платформой за другую, никогда не будучи полностью удовлетворенными конечными результатами. Конечно, всегда найдутся ниши, в которых данный веб-фреймворк будет отлично работать. Но есть много людей, которые решили использовать C ++, Java или C # для создания, скажем, настольных приложений. То же самое не совсем верно, когда речь идет о приложениях для веб-разработки. Джоэл Спольски касается этого в тексте ссылки .
Скажем, если бы я построил такую платформу: какими были бы функциональные требования? Цель здесь состоит в том, чтобы перечислить конкретные функциональные ожидания (определенные кратко, конечно, для публикации в стеке). Лучший ответ будет выбран в зависимости от количества голосов.
Чтобы все начали, ниже приведен неполный список требований. Обратите внимание, что эти элементы были намеренно оставлены несколько абстрактными с намерением, чтобы люди могли извлечь из них более конкретные элементы:
Непротиворечивость ООП: плавный обмен данными и представление собственных объектов между модулями на стороне сервера и на стороне клиента : То есть с учетом функции на стороне клиента: clientFoo() и функции на стороне сервера: serverFoo() можно передавать объект obj любого типа T, не требуя сортировки:
define clientFoo() {
T obj = createObject()
serverFoo(obj)
}
OR
define serverFoo() {
T obj = createObject()
clientFoo(obj)
}
Это добавляет требование, чтобы собственные представления объектов были одинаковыми как на стороне клиента, так и на стороне сервера, включая всю композицию, межклассовую связь и семантику инкапсуляции. По сути, совершенно неважно, находится ли данный класс или данный экземпляр на стороне клиента или на стороне сервера.
Функциональная согласованность: беспроблемное функционирование и выполнение потоков : Нужно уметь создавать функцию на стороне клиент / сервер и передавать ее через границу для выполнения. Это включает в себя единую поддержку многопоточности (которая должна работать согласованно как на стороне клиента, так и на стороне сервера).
Совместимость нескольких сеансов приложений : Прекрасным примером здесь является межприкладное «вырезание и вставка» (как упомянуто в статье, указанной выше). Я не говорю о тривиальном копировании текста в браузере в другой экземпляр браузера (или вкладку). Что, если кто-то хочет вставить, скажем, контактный объект в MySocialApp в YetAnotherSocialApp? Этот вид обмена данными между приложениями важен.
Согласованный кросс-браузерный интерфейс, совместимый с : создание «диалоговых окон» AJAX, индикаторов хода выполнения, вкладок и т. Д. Должно быть достижимо с помощью API, который является таким же цельным, как и остальная среда интеграция клиент / сервер, описанная выше. Да, да, он должен работать одинаково во всех браузерах (при этом различия браузера полностью невидимы для разработчика).