Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Поддерживаю! Более того, реализация подобного уже была (да и может есть еще), это XML + клиентский XSLT. В целом очень верный подход был, если постичь XSL язык. У XSL трансформации на сервере была проблема с нагрузкой, но на клиенте же только ограниченная поддержка браузерами (только FF и IE умели). Но может уже все поддерживают? Не проверял давно.
Сейчас все поддерживают. Да и вроде изначально все поддерживали?
В яндекс-почте используется например.
В яндекс-почте используется например.
XSLT 1.0 понимают все браузеры, XSLT 2.0 — к сожалению, ни один.
Хотя я и занимаюсь разработкой сайтов уже который год, и как бы должен проявлять креативность и как бы стараюсь уйти от вариантов — так делали в 2000е, но иногда заходя на сайт с мегакреативной навигацией и всяческими параллаксами, мне хочется плакать от того, что я иногда даже не понимаю в какой части сайта я нахожусь и куда мне кликать — мой мозг разрывает от многообразия, то есть посещая новый сайт у меня уходит кучу времени для того, чтобы его изучить, зачастую я такие сайты сразу же закрываю, т.к. мне просто жаль своего времени. БЕСИТ! Разнообразие — это хорошо, но всего должно быть в меру!
За частую мне и вправду хочется видеть лишь один плаин текст и пользоваться Ctrl+F.
За частую мне и вправду хочется видеть лишь один плаин текст и пользоваться Ctrl+F.
У XSLT просто ужасно громоздкий синтаксис, поэтому пользоваться им для написание шаблонов очень не удобно.
К сожалению в вебе все настолько привыкли к разному на каждом сайте дизайну и к предложениям «сайт за сто баксов» что даже если вы сверстаете layout а браузер нарисует его по своему, то заказчику это не понравится, он захочет вообще не так, тут на три пикселя вправо, тут кнопка ваааще не такая, а вот тут можно чтобы оно сверху выехало. И флешку например.
Вообще я вас конечно понимаю, сам бы был не против отдать один раз шаблон и потом только данные менять (в принципе есть подобные проекты, но тоже не все в порядке, вот выше написали уже), но когда html делался, никто не думал, что нужно будет строить UI, думали о том как показать информацию про кафедру универа.
Так что вероятно революции не будет, может в html 10 что-то подобное добавят :)
Вообще я вас конечно понимаю, сам бы был не против отдать один раз шаблон и потом только данные менять (в принципе есть подобные проекты, но тоже не все в порядке, вот выше написали уже), но когда html делался, никто не думал, что нужно будет строить UI, думали о том как показать информацию про кафедру универа.
Так что вероятно революции не будет, может в html 10 что-то подобное добавят :)
Слышали про мобильные приложения?
Слышал, я андроид-разработчик. А что?
Это хорошо. Разработчики нам нужны (:
Я к тому, что в мобильных приложениях, сейчас пробуют разные модели. В том числе и некоторые те, которые описаны в статье.
Я к тому, что в мобильных приложениях, сейчас пробуют разные модели. В том числе и некоторые те, которые описаны в статье.
Да, я понял к чему вы клоните.
Честно говоря я вообще не в курсе, что там на других платформах происходит. И про всякие там Titanium и подобные только в теории слышал.
В классическом фреймворке (в смысле, который делает Гугл) разделение данных и представления конечно есть, но фреймворк не заставляет отделять логику представления (показать/спрятать/перекрасить) от бизнес логики. Данные загружаются способом «найти элемент и присвоить значение», а не пачкой. Есть конечно адаптеры, но они не для всего применимы.
Честно говоря я вообще не в курсе, что там на других платформах происходит. И про всякие там Titanium и подобные только в теории слышал.
В классическом фреймворке (в смысле, который делает Гугл) разделение данных и представления конечно есть, но фреймворк не заставляет отделять логику представления (показать/спрятать/перекрасить) от бизнес логики. Данные загружаются способом «найти элемент и присвоить значение», а не пачкой. Есть конечно адаптеры, но они не для всего применимы.
Да ну ладно вам. Это уж слишком. Если исправлять, то хочу заметить, что говорить «Андроид-разработчик» в целом не очень правильно, это калька с Android developer. А если привести параллели с «инженер-программист», то получается что «Андроид-разработчик» — удел научной фантастики.
Или вы намекаете, что я «Андроид-разработчик» в кавычках? :)
Или вы намекаете, что я «Андроид-разработчик» в кавычках? :)
Все это понимают. Однако нельзя одним махом изменить фундаментальные основы Интернета.
Понятно, что сейчас уже html тяжел и на резкие повороты никто не согласен, и я это понимаю. Для начала стоит добавить то, без чего жить тяжко. Очень много усилий пропадает даром, а это печально.
А я не вижу проблем :) Например, план такой:
1. создаем некий поддомен html10.site.com, распространяем ссылку на него
2. показываем на нем контент типа:
3. Пишем плагины для популярных браузеров, плагин в случае нахождения data вместо body уберет мета-редирект из head и прогонит весь <data/> через указанный в нем шаблонизатор (для простоты скажем написанный на JS), который уже и отрендерит правильный html.
4. Браузеры без плагина (а если хорошо пойдет, то встроенного модуля) соответственно будут перенаправлены на «старую» версию сайта.
Продолжением сего (в более далеком будущем) будет рендеринг уже без html, по сценарию предложенному sysprg в эссе Web must die.
1. создаем некий поддомен html10.site.com, распространяем ссылку на него
2. показываем на нем контент типа:
<html>
<head>
<meta http-equiv="refresh" content="0; url=http://www.site.com"> <!-- мгновенно редиректим на стандартный HTML для браузеров не поддерживающих HTML10 -->
</head>
<data template="/templates/mainpage.js">
</>
<!-- пошли данные, например в xml -->
<posts>
<post>
<title>...</title>
<text>...</text>
</post>
...
</posts>
...
</data>
</html>
3. Пишем плагины для популярных браузеров, плагин в случае нахождения data вместо body уберет мета-редирект из head и прогонит весь <data/> через указанный в нем шаблонизатор (для простоты скажем написанный на JS), который уже и отрендерит правильный html.
4. Браузеры без плагина (а если хорошо пойдет, то встроенного модуля) соответственно будут перенаправлены на «старую» версию сайта.
Продолжением сего (в более далеком будущем) будет рендеринг уже без html, по сценарию предложенному sysprg в эссе Web must die.
Let's Holy war begin!
Я еще со времен первых html сайтов, когда не было ajax-а и был медленный интернет, не понимал, зачем тягать здоровенные html страницы после изменения 2-х байтов полезной информации.
Тут, имхо нет смысла привязываться к каким-то конкретным технологиям Redis и т.д.
Мое видение такое, хорошо бы перенести процесс рендеринга на клиентскую сторону, отделив мух от котлет, т.е. данные от верстки.
Допустим пользователь переходит по странице, ему в ответ летит шаблон(ы) на основе того же html и отдельно данные в любом формате xml, jsom…
На клиентской стороне данные натягиваются а шаблон, получая на выходе любимую всеми браузерами html страницу.
Данные всегда связаны с конкретным шаблоном, разные части сайта могут рендерится по отдельности, собираясь потом в целостную картинку, каждая часть из которой может изменяться в зависимости от действий пользователя.
Для поисковиков это тоже будет лафа, им будет проще индексировать такой контент, в разы уменьшится объем трафика, запрашиваемого поисковиками.
Правда от проблем с html, приведенных в вышеуказанной статье это не избавит, но та проблема лежит несколько в иной плоскости и решать ее нужно как-то иначе.
Тут, имхо нет смысла привязываться к каким-то конкретным технологиям Redis и т.д.
Мое видение такое, хорошо бы перенести процесс рендеринга на клиентскую сторону, отделив мух от котлет, т.е. данные от верстки.
Допустим пользователь переходит по странице, ему в ответ летит шаблон(ы) на основе того же html и отдельно данные в любом формате xml, jsom…
На клиентской стороне данные натягиваются а шаблон, получая на выходе любимую всеми браузерами html страницу.
Данные всегда связаны с конкретным шаблоном, разные части сайта могут рендерится по отдельности, собираясь потом в целостную картинку, каждая часть из которой может изменяться в зависимости от действий пользователя.
Для поисковиков это тоже будет лафа, им будет проще индексировать такой контент, в разы уменьшится объем трафика, запрашиваемого поисковиками.
Правда от проблем с html, приведенных в вышеуказанной статье это не избавит, но та проблема лежит несколько в иной плоскости и решать ее нужно как-то иначе.
jquery templates
Ага, классная штука, вообще странно, что как-то пока слабо это все распространено.
Есть ли примеры каких-то серьёзных сайтов где бы использовались jquery templates? Бегло нагуглив не нашел ничего интересного.
А вообще такой подход порождает много вкусностей. Это и кастомные шаблоны для популярных сайтов. Огромное поле деятельности для дизайнеров по их разработке. И кастомные локализации на все языки.
Есть ли примеры каких-то серьёзных сайтов где бы использовались jquery templates? Бегло нагуглив не нашел ничего интересного.
А вообще такой подход порождает много вкусностей. Это и кастомные шаблоны для популярных сайтов. Огромное поле деятельности для дизайнеров по их разработке. И кастомные локализации на все языки.
а как поисковики воспримут такой сайт?
Откройте для себя клиентский XSLT. Последних этак года два оно уже массово вполне юзабельно.
P.S. Хотя лично для себя по дефолту остановился на ctpp и у меня серверная сторона таки да, только данные и генерирует.
P.S. Хотя лично для себя по дефолту остановился на ctpp и у меня серверная сторона таки да, только данные и генерирует.
Так а что мешает сделать крос-платформенное приложение, которое будет действовать так как вы описали? И вообще не трогать веб.
Ну, может так случится, что появление Twitter Bootstrap и подобных ему решений станет тем благом, которое всех спасет. В конце концов должна же быть от твиттера польза.
Мне кажется проблема еще в том, что вступают в противоречие взгляды на мир дизайнера и программиста. Любой шаблонизатор, который генерирует представления по какой-то встроенной логике, это больше программа, чем описание. Там надо оперировать циклами, условиями и вызовами функций. А CSS и, в некотором роде HTML (на уровне декларации блоков), это чисто декларативный код более понятный дизайнеру. А вот совместить ясность CSS и гибкость JavaScript в одном флаконе пока не удается. Т.е. средств позволяющих просто указать где что расположено и как от чего зависит и меняется — нет. А сервер или клиент будет порождать конечный результат это не так принципиально… имхо :)
Как по мне, так html и есть голые данные, шаблон с данными, если угодно. Конечно, если использовать его по изначально задуманному назначению. а с появлением css flexbox и grid это должно стать еще ближе к реальности. данные размечены в html, оформление в css. Если юзеру угодно изменить представление — user styles в помощь.
а ExtJS, Qooxdoo, ObjectiveJ не решат для вас этих проблем? сервер для таких приложений именно так и выглядит, как вы и описали. Вместо qml — JS. Фреймворк реализует стандартные компоненты.
Уже с год вполне успешно используем на проекте JavaScriptMVC, который как раз и соответствует описанному поведению, когда сервер занимается почти исключительно отдачей данных. В целом — впечатления весьма и весьма положительные. Основной минус — нередко на клиент «утекает» больше данных, чем нужно на самом деле. Хотя это, естественно, исправимо.
Где это вы такой минус нашли?
$.Model.findAll(params, success(items), error)
params {Object} — data to refine the results. An example might be passing {limit: 20} to limit the number of items retrieved.
Ну как же. Когда рендеринг идет на сервере, то мы отправляем в итоге на клиент только те поля объекта, которые нужны в данном конкретном случае. А тот же $.Model.findAll(...) предполагает возвращение с сервера объекта со всеми полями, которые где-либо используются. Да, конечно можно через params указывать, насколько подробную информацию нужно вернуть с сервера, но это добавляет новые проблемы. Так что пока идеального решения нет.
Ваши фантазии уже реализованы в мобильных приложениях.
> И заметьте: каждый дизайнер изголяется над созданием/стайлингом/размещением контролов, которые уже ДАВНО есть в ЛЮБОЙ ОС. Так зачем столько телодвижений для создания такого же, но другого? Чтобы что?
Что бы твой сайт/приложение не выглядел унылым ГОВНОМ, и был узнаваем на фоне конкурентов. Что бы в любой ОС он отображался одинаково и не зависил от стилей ОС. Ты конечно можешь сказать что нахера это тебе не надо, но пользователи твоего сайта вряд ли будут приятно удивлены если они зайдут на твой сайт с разных устройств и увидят разное отображение.
HTML — это очень удобный и гибкий инструмент, на базе которого можно реализовать различный задачи.
P.S.: комментирую раз в день, так что меня до завтра не троллить.
Что бы твой сайт/приложение не выглядел унылым ГОВНОМ, и был узнаваем на фоне конкурентов. Что бы в любой ОС он отображался одинаково и не зависил от стилей ОС. Ты конечно можешь сказать что нахера это тебе не надо, но пользователи твоего сайта вряд ли будут приятно удивлены если они зайдут на твой сайт с разных устройств и увидят разное отображение.
HTML — это очень удобный и гибкий инструмент, на базе которого можно реализовать различный задачи.
P.S.: комментирую раз в день, так что меня до завтра не троллить.
Странно, что это чуть ли не единственный комментарий подобного рода. Присоединяюсь к этому мнению, а также предлагаю автору поста нарисовать 2-3 сайта со стандартными контролами.
Что бы в любой ОС он отображался одинаково и не зависил от стилей ОС.
… … …
Это из-за вот таких вот дядь невозможно менять стили винды на ночные, темные, чтобы глазам было проще ночью?
Может для Вас веб — это элемент исскуства, но не стоит забывать что все «дизайны» — это приложение к запрашиваемым данным, причём навязываемое, ибо я не запрашивал сервер поделиться дизайнерскими рюшечками. Я просил данные, и как можно скорее. Просто представте «данные» и «оформление» как два разных элемена. Где приоритет?
Дизайн сайтов ближе к рекламе или если хотите к журналу. Нельзя же писать всю рекламу черным шрифтом по белому фону, даже если это самый простой способ передать информацию. Люди просто не будут замечать разницу.
Так же если все сайты будут набираться из 20 шаблонов это запутает пользователей этих сайтов. Фирма «Рога и копыта» и «Копыта и рога», черт возьми, на каком же из этих светлозеленых сайтов я был вчера?
Так же если все сайты будут набираться из 20 шаблонов это запутает пользователей этих сайтов. Фирма «Рога и копыта» и «Копыта и рога», черт возьми, на каком же из этих светлозеленых сайтов я был вчера?
Можно например сделать браузер для qml страничек и просто открывать qml'ки лежащие на сервере.
Сразу получаем из коробки нормальную модульность, нормальную асинхронность, разделение логики и представления и кучу всего вкусного плюс визуальный редактор всего этого безобразия.
Вот только это всё равно, что встать на пути поезда, несущегося на скорости 400километров в час.
Короче говоря, чтобы этот дивный новый мир наступил нужно старый разрушить до основания!
Хотя казалось бы! Ну всё есть уже чтобы этот мир прямо сегодня обьявить созданным!
Сразу получаем из коробки нормальную модульность, нормальную асинхронность, разделение логики и представления и кучу всего вкусного плюс визуальный редактор всего этого безобразия.
Вот только это всё равно, что встать на пути поезда, несущегося на скорости 400километров в час.
Короче говоря, чтобы этот дивный новый мир наступил нужно старый разрушить до основания!
Хотя казалось бы! Ну всё есть уже чтобы этот мир прямо сегодня обьявить созданным!
Вот еще пример разделения сервера и клиента: Cowboy and Batman.js for Erlang Web Development. По моему, очень красивое решение…
Кстати, а для чего каждый сайт должен иметь уникальный дизайн?
Если вы, гражданские, такие умные, то почему строем не ходите?
По-моему, вы ломитесь в открытую дверь. Подобные подходы давно уже мейнстрим.
— Все веб-приложения написанные на фреймворках, подобных backbone.js работают в этой (или близкой) архитектуре.
— Большинство веб-приложений использующих couchDB работают в близкой архитектуре (порой вообще без написания чего-либо на серверной стороне).
— Да просто «большинство веб-приложений»… НО! «Приложений», а не «сайтов». «Сайтам» с минимальной прикладной логикой удобнее обходиться «классической» вебовской архитектурой.
— Все веб-приложения написанные на фреймворках, подобных backbone.js работают в этой (или близкой) архитектуре.
— Большинство веб-приложений использующих couchDB работают в близкой архитектуре (порой вообще без написания чего-либо на серверной стороне).
— Да просто «большинство веб-приложений»… НО! «Приложений», а не «сайтов». «Сайтам» с минимальной прикладной логикой удобнее обходиться «классической» вебовской архитектурой.
По поводу приближения веб-приложений к десктопным: оно, конечно, хорошо понажимать кнопочки, подвигать контролы на странице. Но нельзя забывать и о том, что классная черта веба — это его адресуемость. Веб в отличие от веб-приложений публикует контент, а не просто его отражает. Написав статью, мы получаем ссылку, которая однозначно стандартным образом ссылается именно на эту статью. Если же сайты станут фактически серверами приложений, то как адресовать веб? Как его индексировать?
Лучший подход — это когда в гипертекст внедряется объект-приложение. В ряде случаев (когда, например, не нужны индексирование и уникальный адрес) этот объект заполняет страницу. Собственно, для такого уже давно были адекватные средства (Flash, Java-апплеты, Silverlight), которые, тем не менее, страдали от тех или иных недостатков. Надо сказать, что связка HTML5 + CSS3 + JS тоже не лишена недостатков. Почему побеждает именно она — вопрос сложный.
Браузер знает, что получит HTML. А если сделать, как предлагается в статье, что получится? Ну будет браузер получать SOAP по некоторому предложенному WSDL или JSON. Так их тоже можно поломать, если кривыми руками полезть в серверную логику. И, надо сказать, что с тем же SOAP, который когда-то рекламировали в качестве серебряной пули, на практике тоже хватает проблем. И c JSON хватает.
Лучший подход — это когда в гипертекст внедряется объект-приложение. В ряде случаев (когда, например, не нужны индексирование и уникальный адрес) этот объект заполняет страницу. Собственно, для такого уже давно были адекватные средства (Flash, Java-апплеты, Silverlight), которые, тем не менее, страдали от тех или иных недостатков. Надо сказать, что связка HTML5 + CSS3 + JS тоже не лишена недостатков. Почему побеждает именно она — вопрос сложный.
последствия html в виде валидации вообще всех данных омерзительны: браузер не знает заранее что получит, поэтому не может натравить правильные фильтры на данные. А чтобы он это знал, он сам их должен просить явно
Браузер знает, что получит HTML. А если сделать, как предлагается в статье, что получится? Ну будет браузер получать SOAP по некоторому предложенному WSDL или JSON. Так их тоже можно поломать, если кривыми руками полезть в серверную логику. И, надо сказать, что с тем же SOAP, который когда-то рекламировали в качестве серебряной пули, на практике тоже хватает проблем. И c JSON хватает.
Тоже хотел сказать, что попытки уйти от HTML уже предпринимались с разной долей охвата «рынка» – это я про Flash, Java-апплеты и Silverlight. Но так и не охватили всего ареала обитания HTML.
В чём причина? Попробуйте для начала подсчитать % мобильных устройств, которые поддерживают хотя бы одну из этих технологий.
Строго говоря, конечно, это не совсем причина, а конечный эффект первопричин. Вот некоторые из них:
Flash – я не специалист, но на каждом столбе трубится о его уязвимостях.
Java-апплеты – это моё имхо, конечно, но SWING-контролы своим дизайном заставят плакать не только Сами Знаете Кого, но и простых смертных. Не говоря уже об ограниченности функционала.
Silverlight – не раз у меня была возможность дать зелёный переходу на эту технологию в своих «епархиях», но она изначально ограничена пользователями Маков и Виновза (Моно при всём уважении не в счёт). Для общедоступных сайтов, а не только для внутренних/корпоративных это не подходит. Только московский метрополитен, наверное, может себе позволить разрабатывать сайты в двух вариантах: на Сильвере и обычном HTML.
В чём причина? Попробуйте для начала подсчитать % мобильных устройств, которые поддерживают хотя бы одну из этих технологий.
Строго говоря, конечно, это не совсем причина, а конечный эффект первопричин. Вот некоторые из них:
Flash – я не специалист, но на каждом столбе трубится о его уязвимостях.
Java-апплеты – это моё имхо, конечно, но SWING-контролы своим дизайном заставят плакать не только Сами Знаете Кого, но и простых смертных. Не говоря уже об ограниченности функционала.
Silverlight – не раз у меня была возможность дать зелёный переходу на эту технологию в своих «епархиях», но она изначально ограничена пользователями Маков и Виновза (Моно при всём уважении не в счёт). Для общедоступных сайтов, а не только для внутренних/корпоративных это не подходит. Только московский метрополитен, наверное, может себе позволить разрабатывать сайты в двух вариантах: на Сильвере и обычном HTML.
Вопрос: а почему мобильные устройства не поддерживают эти технологии? Чьё упущение: производителей устройств (прошивок) или авторов технологий? Тут ругаются на HTML5, что, мол, много памяти кушает. Ну я согласен, что в силу своих особенностей JavaScript прожорлив. Но почему никто не оптимизировал те же Java-апплеты под мобильники? Ведь сейчас апплеты кушают памяти побольше, и я даже понимаю, почему. Но делать почему-то никто ничего не хочет. В том числе латать уязвимости в Flash или делать кроссплатформенный Silverlight. Поэтому и имеем HTML5 со всеми его (родовыми, а не потому что лень поправить) недостатками.
Кстати, про Java не согласен. Аплеты долго грузятся, кушают много памяти, глючат и медленно работают. Внешний вид Swing-приложений легко поменять с помощью LAF (тот же Nimbus уже давно встроен в JRE), а возможностей там более чем, по сравнению с тем, что предлагает HTML (хотя соглашусь, что маловато по сравнению с современными продвинутыми тулкитами вроде QT или даже WPF).
Кстати, про Java не согласен. Аплеты долго грузятся, кушают много памяти, глючат и медленно работают. Внешний вид Swing-приложений легко поменять с помощью LAF (тот же Nimbus уже давно встроен в JRE), а возможностей там более чем, по сравнению с тем, что предлагает HTML (хотя соглашусь, что маловато по сравнению с современными продвинутыми тулкитами вроде QT или даже WPF).
Много тут в комментах приводили в пример JS фреймворков и библиотек, которые якобы решают описанную автором проблему. Все это прекрасно и все молодцы, что разбираетесь в куче технологий. Однако меня печалит то, что скоро понадобится минимум Core i3 c 4GB памяти для банального веба.
Моего нетбука на простеньком атоме уже частенько не хватает для сайтов с классными JS-либами. Проц под 100% нагрузкой. Так вот открыл браузер и в нем несколько сайтов и все — закончились ресурсы.
Такими темпами скоро появятся на загрузке сайтов скрипты, которые проверяют достаточность ресурсов.
Так вот зашел на сайт, а тебе бац — «ваша система не соответствует минимальным требованиям нашего сайта» :)
Моего нетбука на простеньком атоме уже частенько не хватает для сайтов с классными JS-либами. Проц под 100% нагрузкой. Так вот открыл браузер и в нем несколько сайтов и все — закончились ресурсы.
Такими темпами скоро появятся на загрузке сайтов скрипты, которые проверяют достаточность ресурсов.
Так вот зашел на сайт, а тебе бац — «ваша система не соответствует минимальным требованиям нашего сайта» :)
Уже достали со своей ненавистью к HTML… Простите, вырвалось.
Собственно. Если вам нужно генерить UI — возьмите ExtJS, Dijit, да хоть Uize — есть куча JS-библиотек для построения UI. Если вам нужно удобнее генерить этот-самый UI на сервере — делюсь идеей, однажды у меня была: сделать процесс разработки сайта аналогичным разработке программы. Убрать термины «клиент» и «сервер», забыть про ajax. Ну как-то так:
И сделать биндинги ко всем популярным языкам программирования. И удобную библиотеку для создания и изменения UI.
Собственно. Если вам нужно генерить UI — возьмите ExtJS, Dijit, да хоть Uize — есть куча JS-библиотек для построения UI. Если вам нужно удобнее генерить этот-самый UI на сервере — делюсь идеей, однажды у меня была: сделать процесс разработки сайта аналогичным разработке программы. Убрать термины «клиент» и «сервер», забыть про ajax. Ну как-то так:
var a = getData('foo'); // получаем запрос из SQL-базы
alert(a); // выводим напрямую на страницу
И сделать биндинги ко всем популярным языкам программирования. И удобную библиотеку для создания и изменения UI.
Странно, что XML+XSLT упомянули, но никто не вспомнил про RSS — для выдачи контента ведь это самое оно!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ох уж этот web