[spoiler]Основная фишка новой волны веб-программирования -- создание систем в духе RESTful API. Главная идея его с прикладной точки зрения -- открытый программный интерфейс, позволяющий линейно наращивать мощность системы. Но RESTful API не должен поддерживать сохранение состояния клиента на сервере -- то есть сервер должен выдавать клиенту исключительно "автономные" сведения в стандартном формате, которые никак не связаны с предысторией обращений. А для достижения эффективности всемерно поощряется кэширование, и на основном сервере, и на промежуточных, и на клиенте.
Так, музыкальный сервис SoundCloud.com полностью переработал UI, однако серверной части, реализованной в формате RESTful, это не коснулось. Понятно, что это вполне реализуемо например при грамотном применении паттернов программирования, однако специфика данного проекта именно в использовании принципов REST.
Современные js-архитектуры идут еще дальше. JavaScript как своеобразный наследник Java силен тем, что один и тот же код традиционно может без модификации выполняться и на клиенте, и на сервере, и умная система способна динамически перераспределять нагрузку, грамотно распределяя исполнимую логику между сервером и браузерами клиентов. Этот подход реализован например в системе Meteor, где предлагается программировать нужную логику, не заботясь о том, на каком из звеньев она будет работать. Все API, включая и клиентские интерфейсы, и запросы к СУБД, реализуются в едином коде, который можно запускать в любом окружении. Условно говоря, клиентский код пишется так, словно он запущен на сервере и может обращаться к нужным функциям напрямую.
Интересное выступление (слайды slideshare.net/LeaVerou/turning-to-the-client-side) презентовала Lea Verou.
В соответствии с принципами REST, сервер должен быть "ленивым". В классическом варианте ленивый сервер отвечает за файлы, данные и безопасность. Но в новых подходах бесконечная масштабируемость системы достигается за счет того, что удается отказаться от концепции "дедик"-сервера. Где в данный момент выполняется некая логика (на одном из множества равноправных серверов или на одном из множества клиентов), значения для программиста не имеет. Соответственно, и выделение физического места для файлов и данных становится задачей виртуализации. Вопросы СУБД и безопасности снимаются подобным же образом: данные могут храниться локально с помощью, например, стандарта IndexedDB (большие объемы структурированных и индексированных данных на клиенте); кроме того, сегодня доступно множество готовых облачных сервисов, решающих вопросы и с данными, и с безопасностью.
Вещи эти в принципе достаточно очевидные для разработчиков клиент-серверных систем применительно к новым облачно-виртуальным веяниям, однако речь о принципиально новых подходах к проектированию веб-систем, когда понятия и клиента, и сервера размываются. Недаром упомянутая конференция была первой по теме JavaScript, проведенной под эгидой O'Reilly. Актуальность же подобные подходы приобретают только в связи с появлением проектов на миллионы пользователей, а классические клиент-серверные архитектуры корпоративного профиля, по понятным причинам, ориентированы максимум на тысячи клиентов.
Главным препятствием к реализации подобных распределенных систем массового применения до недавнего времени оставалась проблема кроссдоменных/кросссерверных запросов из браузера -- из соображений безопасности они запрещены. Фактически единственной более-менее удовлетворительной реализацией считается JSONP, и некоторые наработки выполнены в рамках HTML5. Однако в апреле вышел рабочий драфт (www.w3.org/TR/access-control/) W3C-консорциума по стандарту Cross-Origin Resource Sharing (CORS, полноценные XMLHttpRequests), в отношении которого все эксперты единодушно выказывают позитивные оценки. Интересно, что CORS уже худо-бедно, но браузерами поддерживается, временная проблема пока в кривоватой реализации. Но тем не менее на CORS уже реализовано немало веб-систем будущего -- например, множество интерфейсов Google, включая YouTube. Есть с кого брать пример.