Клиент vs. сервер

Все многообразие веб-технологий можно четко разделить на две большие категории: технологии могут быть клиентскими или серверными.

История развития веб-технологий пока что красноречиво демонстрировала нам тенденцию смещения акцентов в пользу обработки на стороне сервера.

И вправду, на заре становления Web серверных технологий не было вообще. Во времена HTML 2.0 сценарии CGI, за редким исключением, были чрезвычайно простыми и использовались лишь для обработки полей HTML-форм. Сегодня же мир серверных технологий красочен и разнообразен — это PHP, ASP, Java-сервлеты, ColdFusion (причем чаще всего не сами по себе, а в сочетании с клиент-серверными СУБД наподобие MySQL и PostgreSQL), простая и удобная штука — SSI, XML-парсинг на стороне сервера и прочая, прочая…

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

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

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

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

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

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

Отмеченная идеология, однако, уже до чертиков напоминает путешествие в Питер через Омск (ясное дело, не из Красноярска, а из златоглавой столицы, где меня угораздило родиться).

Ибо Консорциумом W3C уже давно были предложены решительно все средства для реализации принципа разграничения контента и представления на уровне конечного кода веб-страниц.

Речь идет, в первую очередь, о сочетании HTML (а лучше теперь уже XHTML) с CSS. Посудите сами — блочная модель, константные подстановки, правила, позволяющие определять индивидуальные стили оформления элементов страниц применительно к различным классам устройств вывода, — де-факто полностью реализуют функциональность CMS, только несравненно более элегантно, снимая с сервера львиную долю нагрузки.

А обработка XML в сочетании с XSLT на стороне клиента (современные браузеры уже сейчас поддерживают и такое — речь идет, в частности, о парсере msxml, встроенном в Internet Explorer) открывает и вообще неограниченные возможности. Скажу лишь, что XML + XSLT в ряде случаев позволяют отказаться даже от использования баз данных, ибо поддерживают присущую последним функциональность, как-то: логически упорядоченное хранение данных, выборки, сортировку и т. д.

Для того же, чтобы обеспечить должную совместимость и предсказуемость внешнего вида сайтов, необходима самая малость — во-первых, заставить браузеры проверять правильность и действительность кода, и, в случае обнаружения ошибок, банально не отображать страницу; а во-вторых — обеспечить корректность интерпретации тех или иных свойств и их значений всеми пользовательскими агентами в соответствии с рекомендациями W3C. В целях же «обратной совместимости» с ранее созданными сайтами целесообразно «по старинке» отображать все страницы без <!DOCTYPE …> или <?xml version="…"?>. Неправы те, кто думает, что это лишь несбыточные желания и ненаучная фантастика. Браузеры IE6 и Opera 7.x не так далеки от идеала, как думают многие, кто до сих пор верстает сайты таблицами!

Авторами «Информационного бума» уже неоднократно высказывались мысли в подтверждение цикличности, спиральности развития истории. Мне ничего не остается, кроме как тоже согласиться с этим тезисом — ибо совершенно очевидно, что усилиями W3C маятник вновь качнулся в сторону клиентских технологий, в пользу обработки данных на стороне клиента.

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

Конечно, CMS не исчезнут как класс — они видоизменятся качественно. Полагаю, что основной задачей «движков» будет реализация некоего административного интерфейса для удобного «вбивания» данных и легкой их модификации. Такая функциональность, конечно, возложена на системы управления контентом и сегодня, но традиционно считается чем-то неосновным, если даже не факультативным.

Напоследок — организационный момент. САМ предложил в июле отправить «Информационный бум» на летние каникулы, и большинство авторов согласилось месяцок отдохнуть. Так что, скорее всего, моя «юбилейная», десятая колонка выйдет в свет теперь только первого августа. (Хотя и сегодняшний выпуск в какой-то мере озарен светом юбилейности — поглядите на URL, это сотый текст из всех опубликованных здесь.) Вероятно, читатели немножко подустали от того, что многие мои колонки носили скорее концептуальный, нежели практический характер. Возможно, в августе я постараюсь отклониться от этой тенденции. До новых встреч!