«Совершенный Ajax» – новый подход к построению настоящих клиент-серверных web-приложений

    «Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

    Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

    Вторая часть – более занудная будет содержать много технических деталей и выйдет в следующий раз.

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



    Попробуйте угадать: к какой архитектуре относятся web-приложения?

    К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

    Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:
    • Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.

    • Клиент — отвечает за взаимодействие с пользователем [1].

    Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте четко разделены.

    Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:
    1. Бизнес-логика не смешивается с пользовательским интерфейсом.
    2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
    3. Клиентский компьютер не требователен к ресурсам;
    4. И т.д.


    Но, относятся ли web-приложения к клиент-серверной архитектуре? Web-сервер

    Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

    Но! За реализацию интерфейса отвечает не клиент, а тоже сервер. На сервере происходит обработка клиентской формы. Сервер генерирует HTML-код пользовательского интерфейса.

    Браузер Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…

    Замечание:

    Здесь, правда, есть одна тонкость. Следует различать два понятия: web-приложения и систему «браузер — web-сервер». Web-приложения работают поверх браузера и web-сервера, так же как Java-приложения работают внутри JVM, приложения на .Net работают внутри .Net Framework, а протокол HTTP работает поверх TCP/IP.

    Система «браузер — web-сервер» действительно имеет клиент-серверную архитектуру: web-сервер принимает и обрабатывает запросы, а браузер визуализирует результат.

    Однако, здесь мы говорим не о системе «браузер — web-сервер», а о работающих внутри нее web-приложениях.


    Вряд ли такой подход можно назвать полноценной клиент-серверной архитектурой. Он имеет много недостатков:
    1. Смешивание бизнес-логики и пользовательского интерфейса;
    2. Сложно реализовать несколько пользовательских интерфейсов;
    3. Сторонни программы не могут обращаться к серверу (если не написан специальный api);
    4. Большая часть нагрузки по обработке интерфейса ложится на сервер.
    5. И т.д.


    Мейнфрейм Впрочем, мы знаем в истории пример подобной архитектуры. В 70-годы были распространены мейнфреймы. Мейнфрейм — такой огромный железный сундук (сервер), к которому подключались рабочие станции (клиенты). Причем, рабочая станция представляла собой просто монитор с клавиатурой. И любые действия клиента на рабочей станции обрабатывалось на сервере, порой даже такие как обработка нажатия на клавишу и обрисовка экрана [2]. Ну, мы знаем, насколько популярны мейнфреймы сегодня…

    Конечно, в современных web-приложениях часть интерфейсной логики реализуется на клиенте с помощью JavaScript. Ajax Часть данных загружается с помощью Ajax и визуализируется именно на клиенте.

    Но, тем не менее, многие действия связанные с пользовательским интерфейсом, по-прежнему, выполняются на сервере. Использование Ajax сейчас во многом даже усугубляет ситуацию, т.к. приводит к разбрасыванию реализации интерфейса между серверным и клиентским кодом.

    Так вот, я предлагаю подход «Совершенный Ajax», который призывает развить идею Ajax до логического конца и полностью отказаться от использования сервера для реализации пользовательского интерфейса web-приложений.

    Подход «Совершенный Ajax» построен на следующих принципах:
    • Web-сервер:
      • Реализует только бизнес-логику приложения и не генерирует ни строчки HTML-кода;

      • Взаимодействует с клиентом посредством web-служб: принимает текстовые запросы и возвращает только данные;
    • Пользовательский web-интерфейс:
      • Реализуется только на основе клиентских HTML, CSS, JavaScript.

      • Взаимодействует с web-сервером посредством объектно-ориентированной библиотеки-обертки над web службами;

      • Используется исключительно семантическая верстка.

        Элементы управления (вкладки, меню, деревья) описываются высокоуровневыми HTML-конструкциями.

      • Библиотека контролов придает HTML-конструкциям внешний вид и функциональность соответствующего элемента управления, просто навешивая нужные стили и обработчики событий, не меняя при этом HTML-код элемента.
    • Любой сторонний разработчик может реализовать свою версию пользовательского интерфейса, причем не только на HTML, но и на Flash, Windows, Mac и т.д.


    «Совершенный Ajax» в нашем проекте


    Опишу эту архитектуру на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”».

    Сервер


    В концепции «Севершенный Ajax» сервер должен удовлетворять одному-единственному условию: не генерировать ни строчки HTML-кода и осуществлять связь с внешним миром посредством web-служб. Во всем остальном его реализация ничем не ограничена.

    Здесь я опишу структуру сервера в нашем проекте, т.к. она имеет ряд интересных особенностей: использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и возможность использования SPARQL — языка запросов к Semantic Web.

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


    Архитектура сервера
    • СУБД — хранит данные.

    • Прототипное объектно-ориентированное ядро бизнес-логики — реализует объект- ную модель и функциональность приложения.

    • ORM — связывает базу данных с прототипным ядром бизнес логики.

    • Web-сервер — открывает функции программы для внешнего мира посредством web-служб.

    СУБД
    СУБД
    • Все данные хранятся в обычной реляционной базе данных.

    • Причем, используется только «чистый» SQL, без надстроек конкретных СУБД: хранимых процедур и т.д. Это делает базу данных независимой от той или иной СУБД.

    • Связь базы данных с объектным ядром бизнес-логики приложения осуществляется через прототипно-ориентированную ORM.

    Объектное ядро бизнес-логики
    Ядро бизнес-логики
    • Вся объектная модель приложения и его бизнес-логика заключена в прототипно-ориентированном ядре.

    • Ядро написано на серверном JavaScript, на базе платформы Mozilla Rhino.

    • Несмотря на недооцененность многими разработчиками, JavaScript — удивительно мощный, гибкий и красивый язык, превосходящий в ряде случаев по гибкости и функциональным возможностям таких монстров, как Java или C#. И мы используем по максимуму его возможности, такие как прототипно-ориентированное ООП, объекты-как-хеши, функциональное программирование, замыкания и т.д.

    • Также, прототипно-ориентированная парадигма JavaScript позволяет гораздо более гибко работать с базой данных через ORM.

    • Mozilla Rhino компилирует JavaScript в байт-код JVM.

      Благодаря этому, наш серверный JavaScript не становится «вещью в себе», а может использовать все обилие наработок мира Java.

    • Вообще, серверный JavaScript на основе Mozilla Rhino — это отдельная большая тема, и я постараюсь написать ряд статей по этому вопросу.

    Прототипно-ориентированная ORM
    ORM
    • ORM служит для связи реляционной БД с прототипным объектно-ориентированным ядром бизнес-логики.

    • Она позволяет не просто связывать две модели, но и строить объектные запросы любой сложности. Например: найди классы, ученики которых по тестам 10 самых молодых преподавателей имеют за осень средний балл больший, чем по весенним тестам 10 самых старших.

    • Использование ORM для прототипно-ориентированных языков — это мега круто!

      Реляционная модель БД гораздо ближе к прототипной модели ООП, нежели к классовй. Поэтому, применение прототипного похода решает ряд проблем, присущих современным класс-ориентированным ORM (см., например, статью Теда Ньюарда «Вьетнам компьютерной науки»).

    • Прототипная парадигма ORM позволяет удивительно гибко работать с данными.

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

      В частности, это дает возможность обращаться к БД на SPARQL — языке запросов Semantic Web.

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

    • Прототипно-ориентированная ORM — также отдельная большая тема, и я постараюсь посвятить ей ряд статей.

    Web-сервер
    Web-сервер
    • Web-сервер выполняет только одну-единственную задачу — связывает ядро бизнес-логики с внешним миром посредством web-служб.

    • При этом он не генерирует ни строчки HTML-кода.

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

      Например, при наличии соответствующих прав, через web-службы можно осуществить объектный запрос неограниченной сложности и получить произвольную выборку объектов.


    Клиент


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

    Однако, оно всегда имеет в комплекте «родной» web-интерфейс.

    Здесь я опишу его структуру.


    Архитектура клиента
    • Интерфейсное ядро — объектно-ориентированная библиотека, реализующая всю клиентскую логику и управляющая интерфейсом клиента.

    • Библиотека-обертка — объектно-ориентированная обертка над web-службами, осуществляющая связь клиентского интерфейса с сервером.

    • Семантическая верстка — используется для описания элементов интерфейса (контролов) посредством обычных HTML-конструкций;

    • Библиотека контролов — придает HTML-конструкциям внешний вид и функциональность соответствующего контрола.

    Интерфейсное ядро

    Интерфейсное ядро Интерфейсное ядро — объектно-ориентированная JavaScript-библиотека, управляющая всем клиентским web-интерфейсом:
    • Реализует интерфейсную логику приложения.

    • Взаимодействует с объектной моделью приложения на web-сервере через библиотеку-обертку.

    • Взаимодействует с элементами управления (контролами) посредством библиотеки контролов.

    • Осуществляет встраивание клиентского интерфейса нашего программы в web-интерфейсы других приложений.

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

      Например, благодаря этому, на стороннем сайте можно не только разместить модуль прохождения тестирования, но и модуль редактирования тестов, а также управления правами пользователей.

    • Управляет стилями интерфейса.

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

    • Управляет локализацией интерфейса.

    Библиотека обертка
    Объектно-ориентированная библиотека-обертка над web-службами
    • Клиентская реализация (как родной web-интрфейс, так и интерфейсы сторонних производителей) взаимодействует с объектной моделью и бизнес-логикой на сервере посредством web-служб.

    • Однако, работать с web-службами напрямую неудобно: это лишает нас объектного подхода и понижает упровень абстракции.

      Поэтому, гораздо удобнее работать через объектно-ориентированную библиотеку-обертку над web-службами. Библиотека обертка позволяет прозрачно работать с серверной объектной моделью приложения.

      Пример:

      Нам надо получить объект Морковкин Вася и сделать его учеником 3 «А» класса.

      Вместо низкоуровневой работы с web-службами, мы прозрачно работаем с объектной моделью приложения посредством библиотеки-обертки Sintez.

      //Получаем с сервера объект Морковкин Вася<br> var objStudent1 = Sintez.getStudent ("this.firstName = 'Вася' and this.secondName = 'Морковкин'");<br> //Получаем объект 3 "А" класс<br> var objClass1  = Sintez.getClass ("this.getClassNuber() = 3 and this.liter = 'А'");<br> //Делаем Васю учеником этого класса<br> objClass1.addStudent (objStudent1);<br>

      А уже библиотека-обертка кодирует вызов методов объектов как команды web-служб, пакует объекты перед отправкой их на сервер и распаковывает после получения.

    • Для того, чтобы свою версию интерфейса мог реализовать любой сторонний производитель на любой платформе, мы выпускаем библиотеки-обертки не только для web-интерфейса на JavaScript, но и для других распространенных технологий: .Net, Java, Delphi, Flash и др.

      Если для какой-то платформы мы еще не выпустили библиотеку-обертку, сторонний разработчик может ее реализовать и самостоятельно по заданной спецификации.

    • Кстати, если серверный язык программирования поддерживает интроспексию, библиотека обертка может генерироваться автоматически.

      Для этого, программа на сервере должна исследовать собственную объектную модель, и на ее основе сгенерировать код библиотеки-обертки для основных языков программирования.

      Пока мы пишем библиотеки-обертки вручную, но, думаю, скоро доберемся и до автоматической генерации.

    Семантическая верстка
    Семантическая верстка
    • Весь пользовательский интерфейс реализуется на основе чистых xHTML, CSS и JS.

      Несмотря на сильную недооцененность разработчиками, xHTML/CSS/JS является очень мощной и гибкой технологией построения интерфейсов.

    • Использование семантической верстки является высокоуровневым программированием; а несемантическая мешанина тегов – низкоуровневым.

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

      то при подходе «Совершенный Ajax» мы просто обязаны использовать высокоуровневую семантическую верстку!

    • Элементы управления (деревья, меню, вкладки и т.д.) описываются обычными высокоуровневыми HTML-конструкциями.

      Например, меню или дерево описывается как обычный список, а вкладки, как набор div’ов.

    • А уже библиотека контролов делает из этих HTML конструкций элементы управления.

    Библиотека контролов
    Библиотека контролов
    • Библиотека контролов придает HTML-конструкциям внешний вид и функциональность соответствующего элемента управления.

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

      Работа с контролом происходит через вызов методов объекта.

      Поскольку контролы не меняют код своей HTML-конструкции, элемент управления может быть «на лету» превращен в другой элемент простой заменой JS и CSS-классов.

      Пример:

      Дерево описывается не мешаниной тегов, а единой высокоуровневой HTML-кострукцией: вложенным списком.

      <ul id = "ulTree1"><br>  <li><br>   Элемент 1<br>   <ul><br>    <li><br>     Элемент 1-1<br>    </li><br>    <li><br>     Элемент 1-2<br>    </li><br>   </ul><br>  </li><br>  <li><br>   <!--...--><br>  </li><br> </ul><br>

      Для придания списку внешего вида и функциональности дерева, создается JS-объект Controls.Tree. Работа с деревом происходит через вызовы методов объекта.

      //Создаем дерево<br> var objTree1 = new Controls.Tree ($("ulTree1"));<br> //Выделяем все узлы дерева, вызывая метод selectAll () созданного объекта<br> objTree1.selectAll ();<br>

      В любой момент мы можем превратить дерево в меню, просто создав объект Controls.Menu:

      //Превращаем дерево в меню<br> var objMenu1 = new Controls.Menu ($("ulTree1"));<br>


    • В скором времени я собираюсь опубликовать статью на эту тему: «HTML — самый недооцененный язык построения интерфейсов в мире (СНЯПИМ)».

    Подробности технической реализации подхода «Совершенный Ajax» — во второй части.


    Примечания

    1. Речь идет о клиент-серверных приложениях с конечным пользователем. В клиент-серверных приложениях вроде «клиент — сервер базы данных», пользовательский интерфейс, разумеется, отсутствует.
    2. Позже, у мейнфреймов появились так называемые «умные клиенты», которые обладали собственным процессором и памятью, а наиболее продвинутые могли даже проверить форму перед отпракой на сервер. Это очень напоминает нынешнюю робкую попытку передать часть интерфейсной логики web-приложения на клиент с помощью Ajax.

    См. также


    На Хабре есть статьи со схожими идеями, например «Ajax-машина» и недавняя «Hivext: Платформа веб сервисов».
    Поделиться публикацией

    Комментарии 152

      +3
      для меня нечто новое и интересное…
        +2
        Спасибо.

        В принципе, подобные идеи (о полном отказе от генерации HTML-кода на сервере) в неявном виде витали в воздухе уже давно. См. например статью «Ajax-машина».

        Возможно, я прото один из первых сформулировал ее.
          +5
          Единственное, что не сформулировано — это зачем? какие из показателей станут лучше? скорость загрузки приложения? время отклика? уровень загруженности сервера? скорость разработки сайта?
            0
            Сейчас постараюсь написать подробный ответ.
              +3
              Любая модификация проекта станет намного легче.
                0
                Хм, опять же чем?
                  0
                  Нет, это как раз понятно. Потому что жизнь вокруг меняется, функциональные требования — тоже.
                  0
                  Нет.
                  Модификация проекта намного усложнится.
                  Представьте, что нужно будет добавить новый блок с данными — что разве не нужно будет переписывать генерацию кода?

                  И есть еще, более важный момент — кеширование!
                  В случае когда сервер генерит код интерфейса, можно использовать кеширование — один раз запросил, все остальные разы берутся из кеша…
                  В случае генерации кода у клиента, как вы собираетесь кешировать код?

                  Лично мне такой подход не нравится, нечего заставлять мой комп выполнять двойную работу — сперва генерировать код, а потом еще и отображать и с ним работать…
                    +1
                    Я имел в виду четкое разделение по обязанностям. Кеширование помогает снизить траффик между сервером и клиентом, зачем вообще что-то кешировать в интерфейсе при таком подходе?
                      0
                      А как же другая логика,
                      зачем каждый раз генерить сам интерфейс-то?
                      Он же не меняется, а меняются только данные.

                      К примеру, берем самую обычную «шапку» сайта, с меню первого уровня.
                      В вашем случае, при каждом обращении к страницам сайта, этот блок (меню) будет заного генериться и генериться. Но зачем такое нужно? Зачем тратить ресурсы на бессмысленную операцию — генерим то, что не меняется.
                      При генерациии на сервере, можно было интерфейс сгенерить единожды, а потом отдавать тока из кеша.
                        +1
                        Другая логика в разделении кода и представления и в распределении нагрузки. По-моему вполне логично.

                        По поводу кэширования. А оно просто не нужно в этом случае для клиентского интерфейса, кэшировать можно только отдаваемые данные.

                        К тому же мы снижаем нагрузку на сервер и распределяем ее на клиентов — что хорошо.

                        Идея, описанная в статье мне, в общем, понравилась.
                  0
                  Присоединюсь к этому вопросу — не понятна преследуемая цель. Если цель заключается в том, что «web-сервер не генерирует ни строчки HTML», то достаточно было только описать что уходит к клиенту и протокол сервера. На чем и как реализован сервер — уже становится не важно.
                  А модификации всегда идут легко, если система хорошо спроектирована.
                  Да, возможно статью более четко характеризовали словосочетания «Абсолютный» или «Полный Аякс»
                    0
                    Кстати вполне возможно, что все эти параметры разом :) Смотря как вы делали веб-приложения раньше, и какова будет реализация данного подхода.
                      0
                      Ну вот делал я приложения на основе, к примеру, GWT. Что мне даст совершенство вашего AJAX'а?
                      +2
                      Буду краток.

                      — скорость загрузки приложения:
                      будет меньше (хуже), чем у классического приложения, за счет того, что этап «запуска» такого приложения, по сути, этап полной загрузки исходного кода клиента. Но в дальнейшем таких «тяжелых» запросов не будет, а вот при классическом подходе очень даже возможно. В двух словах, график загрузки клиента сначала взлетит «в небо», по сравнению с классическим, но потом трафик будет идти только за счет относительно небольших ajax запросов, а в классике траф будет расти постоянно лесенкой, при каждой загрузке страницы. Это плюс любого ajax приложения вообще, с самого начала раскрутки ajax в инете графики были известны. [Плюшки: задачи проще делить физически между программистами/командами/фирмами и т.д., можно сделать несколько клиентов, можно опубликовать апи и т.д.]

                      — время отклика: что быстрее серверу, сформировать и выплюнуть html-страничку, (обычно это куча инклюдов или их аналогов, дергание кучи кода и т.д.) или же отдать компактный ответ в JSON (Ну или на худой конец в XML)? Подумайте сами. Плюс подхода — стандартизация, из клиента мы может обращаться к веб-сервису, для примера. [Разработка: проще построить стандартизированное монолитное приложение, проще сопровождать, можно обсудить подробнее]

                      — уровень загруженности сервера: прямо зависит от двух прошлых пунктов, сами сделайте вывод, что больше грузит сервер. (Если у вас не новостной проект и вы не отдаете статику) [Разработка: проще рулить нагрузкой, ваш клиент может обращатся к 3-4 независимым сервисам, допустим]

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

                      Простите, на работе нет времени на более подробный ответ.
                        0
                        — по скорости загрузки — не обязательно хуже. Код классов может пригружаться по мере использования (с ходу: фабрика при создании объекта проверяет наличие соответствующего класса, если его нет — то пригрузка js-файла и создание объекта)
                          0
                          — время отклика: тут стоило написать «объём передаваемых данных». Вы действительно считаете, что подставить данные в шаблон намного тяжелее, чем обернуть их в JSON или XML? Работа с файлами (например, обработка картинки), выборки из БД, вычисления — всё это останется неизменным.
                          Про плюс в виде стандартизации я не совсем понял. Что конкретно имеется ввиду?
                            +4
                            Если мы говорим про RIA приложения, т.е. про приложения достаточно нагруженные клиентской логикой, красивым UI и т.д. то да, я действительно считаю, что передать структуру, допустим «акции», обновляющиеся раз в минуту в виде:
                            {
                            {
                            имя: «MSFT»,
                            стоимость_в_уе:0,
                            страшный_параметр1:bla,
                            страшный_параметр2:bla-bla,
                            },
                            {
                            имя: «GOOG»,
                            стоимость_в_уе:0,
                            страшный_параметр1:bla,
                            страшный_параметр2:bla-bla,
                            }
                            }

                            гораздо мение накладно, чем каждый раз генерить полную страничку с этой информацией. И чем сложнее приложение (отображение истории, динамики и т.д.) тем больше будет заметна эта разница. Хотя, я может быть вас не совсем понял, тогда извиняюсь.

                            Под стандартизацией я подразумевал возможность проецировать архитектуру такого приложения на существующие идеологии веб-сервисов или REST, к примеру — и как итог получить в распоряжение весь инструментарий доступный для них: фреймворки, стандарты и т.д. Прошу прощения, не успеваю раскрыть мысль, нужно бежать.
                            0
                            Вижу проблему с SEO ;)
                              +1
                              Никаких проблем! RIA приложение это не блог или сайт строительной компании. Конечно тут могут быть разные варианты, но, к примеру, кому из разработчиков gmailа приходила в голову мысль о его проблемах с SEO?
                              0
                              Непонятно почему сформировать и выплюнуть html-страничку медленнее чем дать компактный ответ в JSON. Одного порядка должны быть величины, по-моему. При правильной организации приложения кучи инклуда и дерганье кучи кода не должно произойти. Ошибаюсь?
                                +1
                                Ну то на клиент пришел ответ { my_param = 32; } и js сделал my_element.innerHTML = my_param

                                А то на клиент пришел целый HTML с HEAD блоком, BODY с кучей элементов. Мало того что пришел больший объем информации, так еще эти все элементы браузер должен создать в памяти, а у каждого свой стилевой класс с кучей аттрибутов. Т.е. вместо того чтобы клиент просто сделал запись в innerHTML, браузер заного рендерит всю страницу.
                                  0
                                  Неверно я сформулировал, да. А если на клиент приходит не { my_param = 32; }, а кусок HTML-а, например? Парсинг HTML на стороне сервера не очень много времени должен занять. Трафика больше, да, но критично ли это?
                              0
                              Если ни хотите мучится с шаблонизатором и HTML, то xsl вам в руки вперед, зачем так все усложнять?
                                +1
                                Извиняюсь, не внимательно прочитал топик, для веб-приложений действительно интересный подход
                                0
                                меня интересует тот же самый вопрос. Совсем не понял, зачем все это надо в реальности? Может быть, в силу того, что я тут не все понял, я не понимаю зачем все это надо :)
                                0
                                Идея витает уже очень давно… и первым вы ее сформулировали разве что на Хабре.
                                Гдето годика полтора назад я начинал реализацию похожего по идеологии продукта. Сделали Дельфи-подобный конструктор экранных форм и реализацию на «клиенте»(в браузере), дело было всего лишь за созданием компонентов. К сожалению, по левым причинам разработку закрыли. думаю, что скоро появится что-то серьезное в эту тему.
                                  0
                                  Немного не в тему, но перед тем как прочесть автора, зашел в блог и посмотрел как сам автор «дружит» с web. Знаете, порадовало сразу, что блог проходит валидацию. Только после этого прочел всю статью.
                                  Уж больно она большая :) Если бы не прошел валидацию блог, врядли читал всю.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      +1
                                      Так ведь валидацию данных и проверку доступа на сервере никто не собирается менять, разве нет?
                                      Так что реализация не поменяется…
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  Бизнес-логика не смешивается с пользовательским интерфейсом

                                  А что, в Вашем случае на стороне клиента они не смешиваются?
                                    +1
                                    На стороне клиента реализуется интерфейсная логика.

                                    А на стороне сервера — бизнес логика.

                                    Сервер при этом не занимается несвойственным ему пользовательским интерфейсом.

                                    Вот и все :-)
                                      +1
                                      перечитал заново эту статью и Ajax-машину…
                                      Да, наверное не смешиваются (при правильном проектировании). Интересно, жду продолжения, пока обмозговать надо все это ))
                                    0
                                    в статье четко прослеживаются некоторые моменты из архитектуры Hivext. Спасибо что указали где подсмотрели :).
                                      0
                                      в статье четко прослеживаются некоторые моменты из архитектуры Hivext. Спасибо что указали где подсмотрели :).

                                      Ну не совсем :-) Мы используем подход «Совершенный Ajax» уже больше чем полтора года.

                                      Просто сформулировать его и написать статью я решил сейчас. Статья про Hivext чуточку опередила :)

                                      Но, еще раз повторю, идеи отказа от генерации HTML-кода на сервере в неявном виде витали в воздухе уже давно. И мы дошли до них разными путями.

                                      Я лишь решил сформулировать эту мысль явно.
                                        0
                                        думаю конкретно в генерации HTML кода на сервере нет ничего плохого, по сути это тот же XML, все зависит от выполняемой задачи

                                        по сути необходимо разделить представление данных от самих данных

                                        статья интересная, успехов в развитии
                                          +1
                                          Понравилась статья, спасибо! Сейчас размышляю над похожей архитектурой.
                                          Сейчас мне видятся такие плюсы от отказа генерации html на сервере:
                                          1) можно делать интерфейсы не только для веб, но и для десктоп. Вы об этом написали.
                                          2) Хорошо подходит для задач, типа обновлять курс валют каждые пару минут

                                          Но и минусы не далеко:
                                          1) Возможность делать интерфейсы для веб, десктопа и т.п. можно и другими способами — используя REST. Мне сейчас это кажется более удобным для этих задач. Тем более у Вас вся логика происходит все равно на Вашем сервере. Если бы нужно было некоторое время программе работать оффлайн, то тут Ваша архитектура могла бы выиграть.
                                          2) Для задач, типа обновления курса валют, можно вполне первый раз сгенерировать интерфейс на сервере и дальше подгружть данные по Аякс. Это выглядит просто легче в реализации для такой простой задачи.

                                          Т.е. получается пока выгода от такого подхода для меня сомнительна. Возможно, что я не врубился в какие-то тонкости. Хотелось бы врубиться :))
                                        0
                                        Интересная статья, правда как-то трудно переосмыслить что весь пользовательский интерфейс генерируется на клиенте. То есть понадобится ли для этого какая-то настройка клиента?
                                          0
                                          То есть понадобится ли для этого какая-то настройка клиента?
                                          Нет, зачем?

                                          Весь клиентский web-интерфейс представляет собой простой набор HTML-страниц.

                                          При стром подходе, данные «впечатывались» сервером.

                                          При новом подходе, web-страница сама загружает нужные данные через Ajax, и с помощью JS управляет собственным интерфейсом.

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

                                          И я хочу показать, что HTML-страницы ничем не хуже в этом плане, чем, например, WinForms.
                                            +1
                                            Интересно но данные о том как должна выглядеть страница, начальный шаблон страница (HTML) берутся с того же сервера. Скорее всего для полного понятия чего к кому нужно дождаться следующую публикацию, очень жду )))
                                              +1
                                              HTML может придти откуда угодно. С сервера он скачивается «прозрачно» в виде файла (который не генерируется динамически). Точно так же как скачиваются файлы *.js, *.css, картинки и т.п.
                                                0
                                                Но все равно — для каждой странице существует свое дерево тегов. Ведь так? Если мы хотим вставить небольшой компонент сайта на другой сайт — сделать машап, то нам придется запрашивать с сервера дерево этого маленького компонента. Вот и опять все сводится к тому, что у нас на сервере лежит куча шаблонов под разные компоненты. Да, в них нет стилей. Возможно это плюс. Но сейчас не пойму насколько это плюс.
                                                Если мы запрашиваем компонент с сервера, то скорее всего уже давно известно, что этот компонент будет в итоге списком, а не деревом. Так почему бы сразу не передать команду, что это список, а не выполнять код по инициализации этого списка.
                                                Т.е. я не пойму, когда возникают задачи, что нам нужно список вдруг превратить в дерево? Но сама идея интересная…
                                          0
                                          Ajax-машина хороша для административной зоны сайта, но для страниц где важна поисковая оптимизация это вряд ли подойдет — поисковые роботы не любят javascript.
                                            +3
                                            «Ajax-машина» или Архитектура «Совершенный Ajax» предназначена для web-приложений (программ).

                                            Для сайтов, Вы совершенно правы, следует использовать традиционный подход.
                                              0
                                              это смотря как выдавать javascript и как хранить контент,
                                              очень всё даже нравится этим роботам.
                                                +2
                                                можно ссылок или деталей?
                                                  +2
                                                  сохранять html версии страниц с контентом(можно его частью) для индексации в отдельную папку,
                                                  в robots.txt разрешить индексировать только её.
                                                  На каждой такой странице ставить ссылку типа «на главную» или «подробнее» которая уже ведёт юзера на сайт.
                                                  при обновлении страницы в базе обновлять и её файл.
                                                  js и css сжимать объединять и хранить в закрытой для роботов дирректории, как собственно всё остальное.

                                                  ах, да:
                                                  — это моё личное мнение, возможно в корне неверное, но до сих пор работающее )
                                                  — я не SEO'шник(плохо разбираюсь в способах раскрутки), у вас там пожалуй есть какие-нибудь свои заморочки о которых я не знаю.
                                                  просто:
                                                  — часто встречаю на первых местах в поисковиках, архивные страницы форумов, и файлы для печати.
                                                  — wordpress делает что-то типа.
                                                  — как-то делал сайтик… хостер не предоставлял mysql, все данные я решил хранить в обычных .txt, сайт быстро вылез на первую страницу яндекса без какой — либо дополнительной раскрутки.

                                                    0
                                                    ЗЫ: сформировал мысль!
                                                    Дай роботу то что он хочет, а сам делай то, что хочешь ты ))
                                                      0
                                                      То есть как сохранять отдельно?
                                                      Делать копии всех страниц в традиционном виде?
                                                      Или я не понял чего-то?
                                                        0
                                                        Да-да, именно так.
                                                        Только не говорите, что это нерациональное использование места на хостинге.
                                                          0
                                                          (1) Это нерациональное использование труда программиста — в итоге получается два сайта: один для пользователя, другой для поисковика.

                                                          (2) Еще есть проблема ссылок — при использовании ajax меняется содержимое страницы, но не адресная строка вашего браузера. Вы не сможете послать ссылку другу на интересный материал просто скопировав адресную строку.
                                                            0
                                                            Опередили. )
                                                              +1
                                                              пункт 1 — всё генерится автоматически, никакого труда программиста не требуется
                                                              пункт 2 — решаем через хэш
                                                                0
                                                                А подробнее можно? На данный момент для меня это пустые слова.
                                                                  0
                                                                  зацени как сделано durov.ru/, ссылки нормально передаются

                                                                  или kgdtour.ru/#159 — «корпоративным клиентам»(реализовано по-дурацки, но суть думаю ясна)

                                                                  habrahabr.ru/blogs/webdev/31211/ — тут много написано как «сэмулировать» переход по страницам.

                                                                    0
                                                                    блин, страница «корпоративным клиентам» — пустая
                                                                    вот лучше kgdtour.ru/#173 — «Контакты»
                                                                      0
                                                                      OK — про ссылки убедили. Будет сложно, конечно, реализовать когда на странице несколько динамических элементов и куча комбинаций их состояний, но это решаемо. Но хотелось бы посмотреть на более сложные примеры применения, а не только когда меняется контент в одной ячейке как на kgdtour.ru.
                                                                +1
                                                                > Это нерациональное использование труда программиста —
                                                                > в итоге получается два сайта: один для пользователя,
                                                                > другой для поисковика.

                                                                Я убиваться об стену делая нечто, что прокатит и тому и другому, сцуко очень рациональное использование!
                                                                0
                                                                Т.е. написать сайт два раза?
                                                                  0
                                                                  нет, просто после функции добавления записи в базу, дописать функцию (пере)записи того же в файл.html, с соответствующим заголовком и мета тегами.
                                                                    0
                                                                    Это подойдет для простого сайта типа kgdtour.ru — когда меняется только одна центральная часть, а представите когда на странице может быть несколько динамических элементов — количество комбинаций возрастает, замучаетесь генерировать.
                                                                      0
                                                                      habrahabr.ru/blogs/webdev/31211/ — тут автор рассказывает о вертикальных и горизонтальных ссылках, почитайте.
                                                                      и ещё раз — durov.ru/ отличный пример с «кучей динамических элементов».

                                                                      Генерирует все простой алгоритм автоматически, размер кода при этом особо не увеличивается.

                                                                      Знаете, подходы могут быть разные, мне так просто удобнее и нет смысла об этом спорить.

                                                                      Интересна точка зрения seo'шников, в плане эффективности такого подхода для раскрутки.
                                                                        0
                                                                        Я про durov.ru не понял — это пример того что сайт генерируется дополнительно для поисковиков. Приведите поисковый запрос по которому находится внутренняя страница сайта.
                                                                          0
                                                                          хм, пожалуй не приведу (

                                                                          durov.ru(ну и разсамил я его) — пример разделения вертикальных и горизонтальных переходов.

                                                                          для поисковиков как раз таки генерируются html страницы, которые в последствие ведут пользователя на сайт.
                                                                  0
                                                                  Всему свое. Пока для сайтов такой подход не подходит) им html для SEO + слой js для красоты и удобства.
                                                                  Яваскрипт и его последствия ставится в последнуюю очередь. И обычно без яваскрипта все работает также хорошо как и с ним.
                                                                  Для сайта JS нужен, чтобы сделать первичную валидацию на клиенте, различные энчанты форм и картинок + не особо нужные виджеты такие как чаты, ajax голосовалки, «загрузка статьи из читать дальше». Ни для чего больше js не подходит на обычном сайте.
                                                                  Для веб-приложений(емейл клиенты, админки ЦМС и т.п.) подход «все на javascript» идеален. SEO важно и совсем не нужено, у клиента все крутится быстро и красиво и без лишних затрат.
                                                        +12
                                                        О, вы говорите как раз о том моменте, когда мы, сделав JavaScript-RIA поняли, что он не предназначен для таких «богатых» вещей, как анимация, навороченный User eXperience и так далее. И поняли, что надо использовать специально созданные для этого технологии (Flex).

                                                        Хотя речь в статье идет не о способах реализации, а о архитектуре. Что ж, первое, что хотелось бы сказать, так это то, что «смешивание логики и интерфейсов» не говорит об использовании клиент-серверной или не-клиент-серверной архитектуры. Оно говорит о верном или неверном использовании, скажем, паттернов или приемов по развызыванию компонентов. Мысль о независимости и переносимости бизнес-логики верная. Но вот между моделью (бизнес-логикой) и интерфейсами существует как минимум односторонняя связь (модель не знает об интерфейсе, о конкретной реализации, но конкретная реализация знает о модели и привязана к ней). И от модели внутри интерфейса никуда не деться.

                                                        Далее. Веб-сервер вполне себе может отдавать HTML-код. Почему нет? Другое дело, что можно это (как мы и делали) логически отделять от обработки самой логики. хтмл отдается точно также как, скажем Flash-ролик или Silverlight-приложение. По кусочкам или целиком — не столь важно, зависит от проекта.

                                                        Но кроме всего прочего, что интересно, HTML дает бОльшую гибкость во многих моментах.
                                                        Представим ситуацию. Мы загружаем веб-страничку с JavaScript-скриптом, который сразу после загрузки обращается к серверу за данными, получает их и отображает. Вроде нормальное поведение клиентского приложения. НО! Почему бы этой страничке еще «будучи на сервере» не попросить у этого же сервера первичные данные? Часто это будет оптимальнее и это одна из фич веб-страничек.
                                                        Зачем отдавать на обработку клиенту то, что не влияет на производительность сервера, используя все мощи паттернов, кэширования и других приемов оптимизации структуры и производительности.
                                                        Снова встает вопрос о смешивании логики интерфейсов и бизнес-логики? Нет, не должен бы вставать. Правильно стройте архитектуру (используйте, допустим, MVC). Считаю, что физическое распределение кусков системы (клиент, сервер) никак не влияет в общем смысле на оптимальность структуры конечного решения.
                                                          +1
                                                          Соглашусь. Автор не совсем верно понимает модель «клиент-сервер» применительно к веб-приложению. В веб-приложении клиентом выступает не машина пользователя отдельно, а связка «машина пользователя + серверная прокся между клиентом и бизнес-логикой».

                                                          Попробую пояснить на пальцах:

                                                          на примере PHP:
                                                          бизнес-логика это: БД + скрипты, взаимодействующие (CRUD) с БД (Model)
                                                          клиент это: скрипты, получающие запросы от клиента и запускающие некие бизнес процесы (Controller) + скрипты, получающие от контроллера информацию, преобразующие её и выдающие пользователю (View) + «клиенты View» (умеющие читать и показывать пользователю информацию, а также дающие ему рычаги инициации бизнес-процессов).

                                                          Всё, что «нового» придумал автор — это отказ во View от преобразования данных из модели в html. Он её преобразует в json. И там, на его стороне уже стоит не просто браузер (который умеет читать и показывать html), но браузер с его javascript-ом/flash-ем/и т.д. и т.п. (который умеет читать и показывать его json).
                                                            0
                                                            Полностью поддерживаю! Я, кстати, понял без объяснения, по первому предложению :)
                                                            Вот я как раз (в случае с HTML) ЗА то, чтобы использовать этот вебовский «размазанный по сети» View себе во благо.

                                                            Кстати, даже в случае с Flash или Silverlight — перед отдачей приложений клиенту их можно инициализировать отчатсти на сервере, передать нужные стартовые параметры или даже собрать в соответствии с полномочиями пользователя. И я бы тоже считал эту серверную часть в определенном роде «клиентом».
                                                              0
                                                              Кстати, у Microsoft Live Labs был проект (сейчас почему-то сайт закрыт, как пишут — временно) — Volta.
                                                              Так вот, суть в том, чтобы создавать приложение, решать прикладную задачу, с возможностью ПОТОМ разнести части приложения по серверам/клиентам, как это будет оптимально в конкретной среде, инфраструктуре. Идея очень крутая, надеюсь, ее разовьют как следует в будущем.
                                                                0
                                                                Добавлю — перекомпиляция под конкретную архитектуру без переписывания кода!
                                                            +3
                                                            хм… привольно )) я уже года 2 занимаюсь подобной концепцией ))
                                                            очень было интересно прочитать другой взгляд на эту идею ))
                                                              +1
                                                              Довольно интересно, но может или что-то не так понял или не достаточно вник, но напомнило то что предоставляет Appcelerator. По крайней мере серверная часть, в виде сервисов, и клиентская, в виде единой библиотеки управляющей и отправкой приемом сообщений, и локализацией, и тд там реализованы.
                                                                0
                                                                У меня уже очень давно подобные идеи назревали, а Вы их очень четко формализовали. Спасибо. Очень интересно узнать технические подробности. Буду с нетерпением ждать продолжения.
                                                                  +3
                                                                  Вот кстати пример: W1 здесь используются почти все концепции, который вы описали. САМОЕ главное ни единой строчки HTML не генерируется на сервере.
                                                                    0
                                                                    что, и и и другие важные теги появляются из ниоткуда?
                                                                      0
                                                                      * и html и head и script
                                                                      странно, почему режет теги, а не превращает их в ентити? :(
                                                                      0
                                                                      Блин, какая классная штука! :)
                                                                      +1
                                                                      На мой взгляд, это очень тонкая архитектура. Если что-то где сломалось или что то где-то не до получилось сайт не будет работать. Конечно такое бывает редко но это его слабость.

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

                                                                      И, помойму, смысл кнопки обновить страницу пропадет, так как мы не можем это все обновить. или можем?

                                                                      посути разработка таких приложений может снизить нагрузку с сервера и повысить нагрузку на клиента и на программистов. а вот только на сколько? и при этом не будет ли сервер делать лишних телодвижений?
                                                                        +1
                                                                        Ну наверное якори будут проставляться.
                                                                        И обработчики этих якорей тоже будет.

                                                                        Недавно на хабре обсуждали эту тему.
                                                                        +1
                                                                        Один из плюсов такой архитектуры — очень легко и быстро сделать автоматическое тестирование. Как для пользовательского интерфейса, так и для сервисов.
                                                                          0
                                                                          поясните мысль, пожалуйста. в каком случае трудно будет сделать автоматическое тестирование?
                                                                            +2
                                                                            Под тестированием подразумевается функциональное (тестирование корректной работы интерфейса) и unit-тестирование. Легкость и быстрота — создание как системы тестирования (как правило одним Php/Perl/J-Unitom, Mercury или Selenium'ом дело не обходится), так и самих тестов.
                                                                            Конкретный случай — тестирование интерфейса по предопределенным данным. В случае сервисной модели (как описано в статье) в тесте указывается конкретный XML/JSON/Yaml/..., в случае генерации контента сервером — необходимо определять шаблонные переменные. И наоборот, в случае тестирования корректно сгенерированных данных — сравнение сгенерированного ответа с ожидаемым и проверка заполненность соответствующих шаблонных переменных.
                                                                              0
                                                                              j-php-и другим юнитам должно быть по барабану куда и в чем отдается. потому что тестировать ими надо не front-end, а бизнес логику. меркурями и тесткомплитами тестируется клиент, который так или иначе связан с html — здесь разницы нет.

                                                                              я не вижу ничего нового в топике — все это доступно даже на интуитивном уровне, правда возведено в абсолют. что касается тестирования, то в данном подходе вы просто имеете возможность отступить на один шаг к клиенту. но чем это проще — не понимаю, поэтому и спросил.
                                                                                0
                                                                                Согласен с мнением про топик).

                                                                                С тестированием же — может кому и достаточно тестирования _только_ на уровне одного компонента (серверная или клиентская часть), но вот кому-то в добавок требуется отслеживать корректный обмен данными между компонентами. Например, отлов бага с выводом — косяк в шаблоне или в вызываемом методе слоя view?
                                                                          0
                                                                          до «Здесь я опишу его структуру.» пропустил — философия не связанная ничем.
                                                                          с удовольствием почитал про совершенный аякс.

                                                                          а вот про размышления об архитектуре и что где должно генерится — это уже по месте лучше смотреть, а не абстрактно философствовать. сам аякс тоже не появится — первоначально кто-то должен его отдать. в том числе и в html виде.
                                                                          к тому же правильно отделив представление от логики на сервере, подобных неудобств в отсутствии webservice-only интерфейсов не замечаешь.

                                                                          о, забыл один момент — я же пошел посмотреть, чем гордится автор. хотел увидеть совершенный аякс. и таки ничего не нашел. где сервисы? где «никакого html в ответе»? :) вот это — "<h1>Length Required</h1>"?
                                                                          я это к тому, что если автор говорит о теории, о очень хочется увидеть что он на этой почве смог достигнуть.
                                                                            +2
                                                                            Я какраз занимаюсь такими приложениями :) Сеичас активно разрабатываю свой Объектный API (White API) на Prototype для построения формы приложения и реализации клиентской логики, буду писать адаптеры для плагинов прототайпа и jQuery. Весь вид генерится JavaScript'ом(с помошью билдера или ручками через new), облагораживается CSSом + JS. Элементы располагаются по дефалту абсолютно в пикселях.
                                                                            Плюс ко всему разрабатываю «Интегрированную браузерную среду для разработки веб-приложений приложений» поколения 2.0 (White RAD IDE 2).
                                                                            Разработка IDE уже близится к концу надеюсь к Новому Году выпустить альфу-бету-релизКандидит. Поддерживаемые IDE браузеры (Ff IE7+ Op Sa)
                                                                            Рабочая версия White RAD IDE 2
                                                                            Тщедушные примеры того, что пока умеет:
                                                                            Тестовый пример прошлой недели (из-за бага открывается только в FF; да URL него гигантский просто это формат передачи данных из окна дизайна к окну дабага/просмотра, в рабочей версии такого урла не будет)
                                                                            Маааленький пример (Ff IE Op Sa)
                                                                              +2
                                                                              Где-то в районе серверного JavaScript вы меня потеряли. Было бы здорово, если бы раскрывалась тема стоимости такой разработки, потому что в том виде как вы это все описали ощущение что это уже не распределенная система (n-tier), а размазанная по всему, чему только можно. С точки зрения нагрузки на сервер — безусловно, ура, сервер больше не стонет от унижения что ему приходится рендерить HTML. С точки зрения разработки и поддержки всего этого «тонкого эфира» — мне кажется будет больше мороки. Возможно для какой-нибудь крупной и богатой организации это и будет иметь смысл, но «в среднем по больнице» имхо дороговато выйдет.
                                                                                –2
                                                                                Я довно такое придумал.
                                                                                  –1
                                                                                  И я тоже давно, хотел запостить, но руки не доходили все вместе сложить =) Кто первый написал, тот и автор.
                                                                                    +1
                                                                                    Миру не нужны наши идеи. Миру нужны наши реализации.
                                                                                      0
                                                                                      Моя штука реализована, правда посмотреть её нельзя ибо интарнет…
                                                                                    0
                                                                                    Как-то вы на свой лад дали определение «клиент-сервер» приложений. Чем HTML не ответ на запрос?
                                                                                    Слишком уж сложные узлы архитектуры у вас получились, контролы на JS,… а почему не XSLT?
                                                                                    Вашей архитектурой вы пытаетесь отделить бизнес-логику приложения перенести на сервер, и тут нечего спорить, MVC рулит. Но, тем самым вы породили еще один слой логики (HTML — JS — WebServices) который опять же рулится на клиенте. Вот как раз это и есть «слабое звено» вашей архитектуры.
                                                                                      +1
                                                                                      Чем плохи толстые клиенты? и чем gmail последней версии плох? :)
                                                                                        0
                                                                                        ммм тут же речь не про «толстяков». Gmail — всетаки хорош наверно. Но gwt технология меня совсем не впечатлила, даже разочаровала. Свингерам наверно будет проще, писать на gwt, но сама архитектура это технологии мне совсем не понравилась(может я недостаточно углубился в ее изучении). Все вперемешку модель-вью-контроллер.
                                                                                          0
                                                                                          Помоему, приложения на «совершенном аяксе» какраз есть толстые клиенты, просто на другой платформе и в другой форме. :)
                                                                                        0
                                                                                        Ну XSLT то, кстати, ни при чем. Это только один из шаблонизаторов (хороший, кстати, и еще стандартизированный). Суть в том, что с любым шаблонизатором при грамотном использовании и грамотной архитектуре можно сделать круто. Про MVC вы совершенно правы, странно что еще не все матерые веб-разработчики его используют, хотя паттерну уже пара десятков лет точно.

                                                                                        А вот про «слабое звено» — это не так, опять же все зависит от того, как сделано. Это не плохая архитектура, ибо клиентская часть так или иначе будет зависеть от логики, а в прямой передаче данных ничего «эдакого» нету.
                                                                                          0
                                                                                          www.w3.org/TR/xslt
                                                                                          с XSLT конечно много ограничений, но зато вы вынесите логику JS на xslt. Вот это уже интереснее.

                                                                                          Здрасте, «клиентская часть так или иначе будет зависеть от логики» вы же как раз от этого и пытаетесь уйти. А получилось все наоборот, давайте начнем с того — что такое вью? и какая роль у JS в вью слое? разве это не логика некоего нового слоя «вью-модель» даже больше «вью-модель-контроллер»?
                                                                                            +1
                                                                                            всё верно. JS — это новый слой MVC на стороне браузера.

                                                                                            В javascript в браузере:
                                                                                            Model — это данные, сохранённые в хэшах + данные из DOM + скрипты, работающие с этими данными
                                                                                            View — это скрипты, осуществляющие манипуляции с CSS и DOM
                                                                                            Controller — это скрипты, вешающие хэндлеры событий и дёргающие Model на предмет данных и View на предмет отображения

                                                                                            Когда модели в JS не хватает локальных данных, или она «чувствует», что данные устарели, она дёргает веб-сервер. Т.е. становится клиентом для приложения веб-сервера (Apache, IIS и др.). При этом в самом веб-сервере происходит ещё несколько связей типа клиент-сервер. Например: Apache запускает PHP скрипты и получает от них то, что нужно выдать клиенту (Apache — клиент ПХП скрипта). PHP скрипт дёргает базу и получает из неё инфу (PHP — клиент СУБД)

                                                                                            При этом в самом PHP опять же несколько уровней «клиент-сервер»: есть скрипты-модели, дёргающие базы, а есть скрипты-контроллеры, дёргающие эти скрипты (контроллер стал клиентом для модели). вью может дёргать контроллер на предмет необходимости дополнительных данных (вью стал клиентом контроллера) и т.д.

                                                                                            Что самое смешное в этой ситуации, что общение браузера (IE, Firefox, Opera) с веб-сервером (Apache, IIS) тоже происходит по модели «клиент-сервер» и это сбивает новичков с толку — все без исключения полагают, что в веб-приложении «клиент» — это браузер с его движком рендеринга и скриптинга, а «сервер» — это связка apache+php+mysql. То, что модель клиент-сервер в веб-приложении находится на более высоком уровне — догадываются немногие. Отсюда и заявления по типу:

                                                                                            «Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом… „
                                                                                              0
                                                                                              Пока писал, вы почти все за меня сказали :)
                                                                                              0
                                                                                              Вы меня не совсем верно поняли. Я тут не спорю на эту тему, точнее не оспариваю вашу точку зрения :) Просто дополняю и описываю свое видение.

                                                                                              Да, совершенно верно, XSLT (как и любой другой шаблонизатор) отвечает за «логику представления» (View Logic). Эту же роль можно взвалить и на JS (частично или полностью). Но я за то, что в «True Web App» использовать как раз шаблонизатор, а JS оставить его роль, балансируя между ролью клиента и ролью сервера в формировании View.

                                                                                              Насчет MVC на клиенте вы совершенно правы — как в архитектуре всего приложения есть MVC, так есть эдакое «маленькое MVC» чисто на клиенте, в JavaScript'е, если хотите (стремление к разделению всех видов логики привело, например, к XForms). Но это вовсе не означает, что мы должны выбирать, какой из этих «MVC» использовать — считаю, что использовать надо оба по мере необходимости.
                                                                                                0
                                                                                                Да, вдобавок,

                                                                                                «но зато вы вынесите логику JS на xslt»

                                                                                                Мы можем перенести только логику формирования View, а не весь функционал JS (анимация, обработка клиентских событий). И я ЗА такой подход в веб-приложении. Если же «хочется большего» — считаю, что это повод смотреть в сторону pure-RIA (Flex, Silverlight, JavaFX).
                                                                                            –1
                                                                                            По-моему не очень разумно выносить много логики на яваскрипт (в т.ч. логику по рендерингу хтмл), по той просто причине что яваскрипт не является компилируемым языком, отсюда проблемы в отладке, поддержке и т д.
                                                                                            Аргумент в пользу уменьшения нагрузки на веб сервер тоже весьма спорный, убирая логику рендеринга с севера вы нагружаете клиент, хорошо ли это? А что если у пользователя отключен джаваскрипт, что он увидит у себя на экране?
                                                                                            В последнее время просматривается тенденция вынесения в яваскрипт как можно большей функциональности, по сути сократив функции веб-сервера до источника данных и хранения сессии. Как то это неправильно на мой взгляд…
                                                                                              +2
                                                                                              Могу лишь напомнить, речь идет о веб-приложениях, а не о простых сайтах. Не забывайте.
                                                                                                0
                                                                                                и что если это веб приложение, то значит в нём должно быть очень много яваскрипта?
                                                                                                  +1
                                                                                                  Не совсем. Обычно они предполагают Богатый юзерский интерфейс, часто делают яваскрипт обязательным для клиентов и предназначены не для того, чтобы юзер читал там новости или другой контент, а именно работал там. Следовательно ему должно быть удобно работать(поменьше перегружать страницу, быстро получать данные, иногда большого обьема и быстро же их смотреть). Таким «сайтам» наплевать, что думают о них поисковики, и т.д. и т.п. отличий много.
                                                                                                  0
                                                                                                  Практически любой веб сайт кроме статического HTML является веб-приложением (web application). Ну и что?
                                                                                                  +1
                                                                                                  Проблемы с отладкой и поддержкой яваскрипта такие же как и с любым серверым языком.
                                                                                                  Около 95% всех пользователей используют javascript. Если идет речь о десктопном решении, то такой сервис на толстых клиентах самое то. Даже мобильные платформы деражт js.
                                                                                                  Нагрузка на сервер уменьшается это точно. Теперь все тянет только СУБД + пара статических файлов. Нагружать клиент сеичас хорошо т.к. мощности компьютеров растут, все браузеры становятся все лучше и быстрее. Уменьшается объем трафика в разы → клиент не ждет.
                                                                                                  > сократив функции веб-сервера до источника данных и хранения сессии
                                                                                                  Просто это такой подход и у него такие запросы.
                                                                                                  0
                                                                                                  всё красиво, но больно уж хлипенько. можно использовать xslt и параллельно будет, где отрисовывать вьюху. но вот писать толстый клиент под каждый браузер, боже упаси.
                                                                                                    +1
                                                                                                    Чтобы конкретнее говорить о самой технологии «Соевершенный Ajax», стоит дождаться второй части, где уже будут «технические детали». Так что стоит обсуждать только «первую половину первой части» =)
                                                                                                    Итак, приступим.

                                                                                                    Во-первых, давайте возьмем некое «истинное» клиент-серверное приложение, например некоторый IM.
                                                                                                    Что мы там имеем? Все отображение «вшито» в клиент, он общается с клиентом по некоторому протоколу (XMPP, OSCAR и т.д.) и «получает голые» данные и сам решает как их отображать.

                                                                                                    Теперь возьмем Браузер. Он требует, чтобы ему кроме данных, передали то, КАК отображать интерфейс, это, если хотите, — Универсальный клиент. Кстати, кроме ХТМЛ есть еще XUL, например.

                                                                                                    Так, что как вы не бейтесь, все равно, Отображение генерится на сервере(HTML, CSS, JS, медия все берется с сервера). А вот чтобы не смешивать, надо использовать, как было сказано, паттерны (MVC, например). Ну, а про XML+XSL я вообще молчу.

                                                                                                    И в заключение.
                                                                                                    1) Веб браузер является клиентом, никаких противоречий тут нет
                                                                                                    2) У веб браузера своя специфика направленная на универсальность
                                                                                                    3) Веб браузер требует, чтобы сервер обяснил как ему отображать данные.
                                                                                                    4) Проблем с поддержкой сервером разнык клиентов нет
                                                                                                      +1
                                                                                                      У вас и у автора немного разные понятия клиента. Для автора клиентом является приложение, способоное работать с конкретной задачей, браузер выступает в качестве движка рендера пользовательского интерфеса, движка для скриптового языка и реализацией чистого http(s), а у вас это универсальный клиент для отображения html+css+js… Подход описанный в статье ни в коем случае не претендует на универсальность! Это нишевый подход для построения RIA приложений, использующий стандарты.

                                                                                                      Пожалуйста, не привязывайтесь только к HTML и иже. Я как-то говорил и повторю, что для меня главным для RIA приложения считается протокол, а не его реализация в конкретном клиенте. В вашем примере с IM можно красиво провести аналогию: есть ОДИН протокол и много клиентов, какие-то онлайновые, скажем, написаные на флеше, какие-то написаны только под Линукс, что-то под Мак и т.д.
                                                                                                      >> Так, что как вы не бейтесь, все равно, Отображение генерится на сервере(HTML, CSS, JS, медия все берется с сервера).
                                                                                                      В виде статики, во-первых. Во-вторых приложение очень легко и просто сделать локальным в полном смысле этого слова с помощью MozillaPrizm к примеру. В-третьих, при открытости протокола достаточно просто писать любые клиенты, какие вам угодно, хоть на Бейсике под ДотНет, хоть на ObjC под IPhone.

                                                                                                      +1
                                                                                                      Иконки приятные
                                                                                                        +1
                                                                                                        Молодец, Алик!
                                                                                                          +1
                                                                                                          Статья понравилась. Интересна производительность всего этого дела по сравнению со стандартным подходом. Бысрее, медленнее, есть ли кака-нибудь статистика?
                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                              0
                                                                                                              Не думаю, что производительность отличается в разы.
                                                                                                              Выигрышь будет в представлении данных (json / html)
                                                                                                              Тут вопрос о том, что быстрее json_encode или шаблонизатор на том же объеме данных.
                                                                                                              Для json решения ещё
                                                                                                              — Значительно уменьшается объем кэша страниц.
                                                                                                              — Значительно уменьшается объем трафика.
                                                                                                              Из дополнительных плюсов json:
                                                                                                              — В случае чего не надо парсить данные из html все и так открыто =) Как следствие множество клиентов для одного сервиса.
                                                                                                                +1
                                                                                                                Я как-то не уловил разницы с филосифией того же ExtJs кроме допонительного звена «семантическая верстка», которое так и не понял зачем нужно.

                                                                                                                Порпавьте, если я неправильно понял.
                                                                                                                1. Получаем данные от сервера
                                                                                                                2. На основании этих данных генерируем на клиенте html и вставляем в документ
                                                                                                                3. Применяем к этой разметке создание контролов

                                                                                                                Почему бы не пропустить ворой пункт и не генерировать контрол на основании данных?

                                                                                                                  +2
                                                                                                                  Всё верно. У ExtJS именно такая идеология и есть. Только они не указывают, что сервер должен быть Mozilla Rhino, что нужно использовать ORM и т.п. Им вообще всё равно, что там делает сервер — лишь бы данные отдавал. А автор просто смешал всё в кучу и выдал это за «Совершенный AJAX».

                                                                                                                  Если уж на то пошло, то AJAX вообще никакого отношения не имеет ни к базе данных, ни к серверной платформе, ни к отображению/генерации контролов
                                                                                                                  +1
                                                                                                                  фактически приведен подход к чистой архитектуре клиент-сервер, применяемой в распределенных, ресурсоемких ERP-системах, типа SAP ERP.
                                                                                                                  Сервер БД (собственно, база)
                                                                                                                  Аппликейшн сервер (один или несколько — собственно обработка бизнес-логики)
                                                                                                                  ГУИ (пользовательский интерфейс).

                                                                                                                  Развивая идею: бизнес-логика хранится в БД. Детали интерфейса хранятся в БД.
                                                                                                                  Аппликейшн сервер- вычисления, выбор из БД, передача инфы от пользователя и к пользователю.
                                                                                                                  ГУИ — отображение всего и вся (и не более).
                                                                                                                  ГУИ- набор методов для отображение разных объектов, обладающих определенными свойствами. Объекты передаются аппликейшном после выборки из БД и определенной обработки.
                                                                                                                    0
                                                                                                                    Автору «респект и уважуха». Не столько даже за саму статью, сколько за применении описаных принципов на практике. Многие любят рассуждать на подобные темы, но когда доходит до практики…
                                                                                                                      –3
                                                                                                                      ."… Полностью отказаться от использования сервера для реализации пользовательского интерфейса web-приложений..."

                                                                                                                      Как то это совсем не модно, в свете нынешних тенденций… Облачные вычисления, то да се ;)
                                                                                                                        0
                                                                                                                        клиентские машины — самое гигантское облако которое можно себе представить!
                                                                                                                        +1
                                                                                                                        забавно, я как раз на аналогичных принципах строю свое новое приложение :)
                                                                                                                          +2
                                                                                                                          Прочитал вместе со всеми комментариями. Так и не понял, зачем огород городить. Не понятно в чём выигрыш. Технологии развиваются довольно логично. Нужны богатые клиентские приложения — появляется Flex. 90% того, что можно было выжать из ява-скрипта (по-моему) выжали в ExtJS. Генераторы JS на разных серверных языках тоже плодятся как грибы, чтоб не писать ни одной строчки на JS вообще (видимо подход, обратный вашему). Если вам и того и другого недостаточно, то пора писать свои клиенты на той же Яве, а не мучить браузер.

                                                                                                                          Ну и маленькая добавочка. Вы там пишите, что не испольуете особенностей конкретной БД. Как раз сегодня с колегой дискутировал на подобную тему, только относительно языков. Универсальность — это конечно здорово, но в большинстве случаев не используя преимущество той или иной базы или языка вы затрудняете сами себе разработку и, в большенстве случаев, колечите производительность.
                                                                                                                            0
                                                                                                                            Про технологии — преимущества все-таки есть. Такое чувствуешь, когда плотно занимаешься этим вопросом.

                                                                                                                            Про БД — полностью +1. Универсализм и производительность всегда на разных концах. Я никак нормально не смог сделать так, чтобы и ораклисты не плевались и чтобы на mysql можно было бы разрабатывать.
                                                                                                                            0
                                                                                                                            Я так понял что формировать html-каркас приложения на сервере — это типа не круто=)
                                                                                                                            Давайте тогда сразу будем предоставлять просто доступ к базе данных только на чтение,
                                                                                                                            а народ пусть как хочет так и формирует представление. Так вообще полная свобода и все в восторге.

                                                                                                                            На самом деле вот maps.google.ru первый попавшийся «здоровый» пример описанной выше технологии (ну там выводится со старта пару див-ов, но, я надеюсь, это не смертельно) и никто не бегает, не кричит про переворот в мире веб=)

                                                                                                                            Кстати ждем от Вас реализаций в подкрепление теории.
                                                                                                                            Еще интересно про Rhino будет почитать=)
                                                                                                                              +1
                                                                                                                              Что я вижу в данном подходе: паттерн MVC, где слой V полностью вынесен на клиентский уровень и слой C распределен между клиентом и сервером. В результате чего:
                                                                                                                              + сервер разгружается на рендеринг HTML.
                                                                                                                              – сервер дополнительно нагружается сериализацией/десериализацией запросов/ответов между JSON<-->native language constructions(PHP, JAVA, RUBY, ...) умноженно на количество запросов/ответов.
                                                                                                                              – отладка клиентского слоя усложняется в разы.
                                                                                                                              – скорость отклика клиента увеличивается за счет увеличения количества запросов на сервер.
                                                                                                                              – эта скорость падает еще в случае зависимости запроса от ответа предыдущего ибо в таком случае их невозможно слать асинхронно, должна быть последовательность.

                                                                                                                              И в чем же данная системма дает прирост? В чем заключается упрощение и большая гибкость построения интерфейсов по сравнению с любым из серверных шаблонизаторов + открытое API для неHTML клиентов или сторонних сервисов, если такие предполагаются?
                                                                                                                                +1
                                                                                                                                А я думаю в ходе эволюции будет так:

                                                                                                                                Сервер отдает данные в формате xml. На клиенте эти данные обрабатываются при помощи соответствующей XSLT в любой формат (RSS, XHTML, PDF), а потом всё это это дело допиливается JS.

                                                                                                                                Т.е. мы получаем всегда от сервера только данные, а клиент уже решает, как их отобразить, в каком формате. Приправить все это REST'ом, получится, думаю, очень хорошо.

                                                                                                                                Осталось только ждать, когда все браузеры будут обрабатывать XSLT, и делать это одинаково.
                                                                                                                                  0
                                                                                                                                  Небольшой оффтоп.
                                                                                                                                  Упорно не пускает на вашем demo4school.sintest.ru/ под учётками Завуча и Учителя. Обзывает меня undefined. Под Морковкиным всё ОК
                                                                                                                                    0
                                                                                                                                    Думал над этой концепцией, когда возникла необходимость по просьбе клиентов написать интернет-магазин работающий полностью на аяксе(:
                                                                                                                                    В итоге был запущен smart.ru
                                                                                                                                    Как разработчику — мне понравилась концепция, и удобство разработки мне показалось выше чем в стандартной идеологии веб-приложений.
                                                                                                                                    Но все это пока очень далеко от совершенства, имхо
                                                                                                                                      0
                                                                                                                                      Писал пол года назад об этом подходе :)

                                                                                                                                      Кому интересен пример — добро пожаловать:

                                                                                                                                      habrahabr.ru/blogs/javascript/28814/
                                                                                                                                        –2
                                                                                                                                        еще одно похабное дерьмо из серии про всё по-немножку!
                                                                                                                                          0
                                                                                                                                          /* «Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода */

                                                                                                                                          Написали бы просто: «Товарищи! Используйте для отдачи даннных с сервера непременно JSON или XML!»

                                                                                                                                          Впрочем, статьи разные нужны. Но называть этот подход новым?! >_<
                                                                                                                                            0
                                                                                                                                            Мне кажется, что чрезмерное увлечение переносом генерации html на сторону клиента чревато осложнением разработки. ИМХО, проще написать код под одну платформу и быть на 100% уверенным, что получится именно тот html, который нам нужен, чем писать js-код, хоть и стремясь к кроссплатформенности, но всё равно тестируя это на зоопарке браузеров.

                                                                                                                                            Поэтому я лично стараюсь по возможности не усложнять клиентский код. Всё-таки его отладка дело куда более капризное, чем отладка серверного кода. На сервере хоть платформа одна.
                                                                                                                                              0
                                                                                                                                              tl;dr
                                                                                                                                              это индексируется поисковиками?
                                                                                                                                                0
                                                                                                                                                Алик, всё клево, много букв. Но смысл где? Зачем это все?
                                                                                                                                                  0
                                                                                                                                                  Как-то кидал на Хабр ссылку с презентацией на подобную тему: Scala.habrahabr.ru/blog/42015/

                                                                                                                                                  Ничего нового не узнал, но вот на серверную реализацию посмотрел бы.
                                                                                                                                                    0
                                                                                                                                                    К сожалению, ввы привели лишь маленький кусочек кода — поэтому понять вашу идею сложно но все же…

                                                                                                                                                    //Получаем с сервера объект Морковкин Вася
                                                                                                                                                    var objStudent1 = Sintez.getStudent («this.firstName = 'Вася' and this.secondName = 'Морковкин'»);
                                                                                                                                                    //Получаем объект 3 «А» класс
                                                                                                                                                    var objClass1 = Sintez.getClass («this.getClassNuber() = 3 and this.liter = 'А'»);
                                                                                                                                                    //Делаем Васю учеником этого класса
                                                                                                                                                    objClass1.addStudent (objStudent1);

                                                                                                                                                    Правилдьно ли я понимаю, что каждый вызов getStudent() генерирует AJAX-запрос? Следовтельно, чтобы выполнить какое-то действие, вам приходится делать несколько запросов? Это серьезно все замедляет для клиента, лучше бы делался один запрос и все выполнялось на быстром сервере. А если запросов 5? У меня с пингом 100-150 мс (fucking ADSL) это займет минимум секунду. А если 10?

                                                                                                                                                    Поясню.

                                                                                                                                                    1) Лишний HTTP-запрос — лишние тормоза. быстрее получить за раз 300 байт, чем 2 раза по 100. не верите — посчитайте сами с учетом пинга и скорости. Я бы вобще предпочел чтобы страница грузилась одним архивом, а не кусками как сейчас это сделано в HTTP.

                                                                                                                                                    2) На сервере выгоднее 1 раз проинициализироватьт приложение, сделать коннект к БД (который может занять больше времени чем само выполнение запроса), сделать 2 запроса, чем повторить все это по отдельности.

                                                                                                                                                    И еще. Имхо — лучше на сервере гененрировать и отдавать HTML чем городить всю эту кучу с JavaScript. Пользователям кривонаписанного фаерфокса вообще плохо, так как пока работает JS интерфейс ФФ подвисает, даже переключиться в другую вкладку нельзя. Пусть лучше трудится ваш быстрый сервер, чем мой несчастный процессор, на котором кроме браузера запущена куча приложений.

                                                                                                                                                    Если вы используете правильный HTML то передать данные в HTML-формате, или с вашей разметкой —разница невелика.

                                                                                                                                                    Вообще, с быстрым интернетом тормоза JS становятся намного чувствительнее, и важнее чем лишние 1000 байт переданные с сервера. Кроме того, если JS реализован криво, например, как отправка комментов на Хабре, работающая через раз, и при этом нельзя сделать отправку обычным POST запросом, это вообще мерзко.
                                                                                                                                                      0
                                                                                                                                                      Я бы вобще предпочел чтобы страница грузилась одним архивом, а не кусками как сейчас это сделано в HTTP.

                                                                                                                                                      Опять же палка о двух концах: с одной стороны меньше данных передается ОДНИМ запросом, но с другой стороны невозможно параллельное выполнение рендеринга/догрузки/дорендеринга, эти все процессы можно будет начать только после того, как все данные уже получены.
                                                                                                                                                        0
                                                                                                                                                        Почему, можно, тот же gzip например поточный алгоритм, позволяет распаковку «на ходу», сначала ессно HTML, потом CSS, потом может картинки или JS
                                                                                                                                                      0
                                                                                                                                                      По моему мнению делить на «клиента» и «сервер» по признаку географической отдалености не совсем перспективно. Как локальная сеть по сути уже не воспринимается пользователем в парадигме клиент-сервер, так уже сейчас в технологически развитых странах пользователь не различает, где находится «сервер»: в корпусе его компьютера, в соседней комнате или на соседнем материке. Разделение между клиентом и сервером происходит на уровне девелоперской парадигмы, а не там где подключаются провода. Если современные сервера берут на себя часть клиентских вычислений, по почему бы и наоборот клиенту не делать часть серверных вычислений? Совершенно нет необходимости заливать бетоном то место, где проходит эта граница.
                                                                                                                                                        +1
                                                                                                                                                        Может если уж делать, то делать так:
                                                                                                                                                        1. Сервер Бизнес логики:
                                                                                                                                                        БД + реализация бизнесЛогики
                                                                                                                                                        Работа через обмен данными XML

                                                                                                                                                        2. Сервер ренедринга ( представления )
                                                                                                                                                        Обмен с [1] по XML, с клиентами — чем угодно, в случае с web — HTML / CSS / JS

                                                                                                                                                        Плюсы такой технологии:
                                                                                                                                                        1) возможности кластеризации серверов бизнес логики, либо разделения их по функционалу
                                                                                                                                                        2) возможность кластеризации серверов рендеринга, либо разделения их по функционалу
                                                                                                                                                        3) возможность кэширования документов [2]
                                                                                                                                                        4) возможность использования разных реализаций [1] и [2], но работающих как единое целое.

                                                                                                                                                        А в данном случае вы получаете очень тяжоловесную систему, во первых получить один БОЛЬШОЙ файл гораздо быстрее и легче, чем обработать 10 мелких запросов ( а я боюсь что во время интенсивной работы их у Вас будет куда больше ), вы откзываетесь от легковесных клиентов, где далеко не всегда можно использовать JS — не есть хорошо. Вы зависимы от скорости выполнения клиентских JS, т.к. инасе работа с системой превратится в нудную тягомотину.

                                                                                                                                                        Увы и ах — не понятны цели — ЗАЧЕМ? чтобы было так красиво все? Далеко не всегда красивое решение — это лучшее решение. К сожелению.

                                                                                                                                                        P.S. Спс за топик — реально интересно было почитать.
                                                                                                                                                          0
                                                                                                                                                          Если вы организуете бизнес логику на сервере, то как вы реализовали передачу сообщений на клиента для обработки отображения?
                                                                                                                                                            0
                                                                                                                                                            В чем отличие от обычного представления?
                                                                                                                                                            Например в RoR есть метод respond_to, который определяет как именно отдать данные, в зависимости от запроса, в тч «ни строчки HTML»
                                                                                                                                                            Смысл выделения новых сущностей для меня теряется…
                                                                                                                                                            Кроме того формирование запроса по средством ORM не это ли есть бизнес логика? Или вы хотите сказать, что контроллер теперь в браузере?
                                                                                                                                                              0
                                                                                                                                                              Круг замкнулся. Для решения задач, который ставит перед собой «совершенный аякс», лет тридцать назад применялись тонкие клиенты, написанные на компилируемых языках программирования. Да и Java Web Start фактически позволяет решать те же самые задачи.
                                                                                                                                                                +1
                                                                                                                                                                «Совершенный Ajax» — очень громкое заявление. Ничего ему соответствующее не нашел в системе тестирования на сайте «Синтез», который больше напоминает студенческую поделку ;)
                                                                                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                                    0
                                                                                                                                                                    Adobe AIR еще одно средство для выноса и разделения клиента и сервера в веб. Тут есть еще локальный сторейдж с файлами, которые коммуницируют с удаленными сервисами.
                                                                                                                                                                      0
                                                                                                                                                                      в смысле не файлы коммуницируют а код, неточно написал :-)
                                                                                                                                                                      0
                                                                                                                                                                      Убивают отдельные идеи отдавать аяксом сверстанный html в веб-приложении. К примеру клиент просит сервер удалить файл, какой html должен вернуть сервер? Такой:
                                                                                                                                                                      <b>Да, я его удалил!</b>
                                                                                                                                                                      А в случае неудачи такой:?
                                                                                                                                                                      <b>этот гребаный файл не удаляется, потому что он занят другим приложением!</b>
                                                                                                                                                                      А клиент, допустим, в зависимости от полученного ответа должен поступать по разному, и теперь чтобы понять был ли выполнен запрос ему надо распарсить этот html!
                                                                                                                                                                      Или к примеру файловый менеджер, сервер отдает ему список файлов в виде таблицы со стоблцами «имя», «размер», «аттрибуты», и т.д. И теперь чтобы сделать нормальный кастомайзинг представления надо опять парсить html!
                                                                                                                                                                        0
                                                                                                                                                                        Вы изобрели велосипед, причем на квадратных колесах.

                                                                                                                                                                        Если вы хотите полноценной SOA — пожалуйста, свой сервер, свой протокол, спецификации и в итоге любые клиенты, втч. и c HTML

                                                                                                                                                                        Но зачем эти гектолитры геморроя?

                                                                                                                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.