Как стать автором
Обновить

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

Красиво!
Недавно решал похожую задачку — нужно было сделать каталог для интернет-магазина, чтобы работал быстро у пользователей с очень медленным и ненадежным интернетом. В результате сделал на Silverlight с возможностью оффлайн работы. Хотя это, конечно, не так круто как HTML5. :)
На самом деле, в демке HTML5 нигде не используется. Я отметил это на картинке как безусловный атрибут в будущем.
Отлично, теперь пользователям с медленным и ненадежным интернетом нужно качать Silverlight.
Как я написал ниже, это в основном для мелкооптовых покупателей, которые активно каталогом пользуются. Им проще один раз скачать Silverlight чем мучаться с веб-интерфейсом.
Им проще перейти по следующей ссылку в гугле.
+1
Я бы закрыл вкладку после того, как мне бы предложили скачать и установить сильверлайт. И уверен, так бы сделали (и наверное сделали) 95% пользователей.
Пользователь приходит в магазин за товаром, и хочет его видеть как можно быстрее и заказать как можно проще.
Естественно, это не замена обычного каталога, а только дополнение для тех, кому это нужно. В отдельном разделе сайта есть страничка с описанием: попробуйте нашу программу для работы с сайтом, это дает такие-то преимущества, сильверлайт можно скачать здесь и т.д. Целевая аудитория — мелкооптовые покупатели из регионов, которые закупают в этом интернет-магазине товары и продают у себя.
Увы, что бы там не говорила Microsoft, до распространенности флэша сильверлайту еще очень и очень далеко.
Как видите, можно обойтись и без флеша и сильверлайста.
Javascript-движки современных браузеров очень быстрые.
Я и не спорю. Но требовалась возможность оффлайн-работы. Чтобы сделать что-то подобное, нужно было бы какой-нибудь google gears прикручивать.
Вот тут то вы и могли заюзать возможности HTML5, например Local DataBases
И вместо установки сильверлайта заставлять пользователей обновить браузер…
Мне так говорят многие знакомые, но про джаваскрипт. «У меня стоит noscript, если я увижу, что сайт требует джаваскрипт — я закрываю вкладку.» А мне приходится извращаться из-за таких дебилов.
НЛО прилетело и опубликовало эту надпись здесь
пользователей мобильных телефонов тоже дебилами называете? progressive enhancement никто не отменял.
для пользователей моб. телефонов делается отдельная версия сайта.
т.е. это уже три версии сайта?
— мобильная
— для десктопных браузеров без javascript/допотопных браузеров
— для новейших браузеров с поддержкой javascript

ещё раз повторю — progressive enhancement придуман уже давно. очень жаль, что немногие веб разработчики правильно понимают его суть. а это между прочим основа веба — как донести свой контент до миллионной аудитории, разнесенной в пространстве и времени.
мобильную версию, кстати, надо тоже не забыть поделить на:
— для примитивных смартфонов
— для мобильного вебкита
— нативные клиенты для iphone и android

всё это сейчас в моде. и в корне неверно. сами же создаём себе сложности.
Вы про progressive enhancement расскажите пользователям ie6 :)

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

Но, на данный момент, это невозможно.
> все получили доступ к данным в одинаково удобном виде

ну я же говорю — мало кто понимает концепцию. потому что лень разобраться. и отсюда фразы типа «на данный момент, это невозможно»
en.wikipedia.org/wiki/Progressive_enhancement

enhanced layout is provided by externally linked CSS
enhanced behavior is provided by unobtrusive, externally linked JavaScript
end user browser preferences are respected

как ни крути, под каждый девай создаётся отдельный «слой» css/js etc.
Вы про progressive enhancement расскажите пользователям ie6 :)

Firefox && Chrome && IE8 >> IE7 >> IE6 — regressive hacking ;)
Graceful degradation
IE8 можно тоже отделить от Хрома и Огнелиса
мне редко приходилось что-то отдельно для него допиливать. Может просто подсознательно избегаю таких вещей ;)
Я имею в виду пользователей, сознательно использующих noscript и говорящих «если сайт использует джаваскрипт, то он — не тру, говно, и вообще мерзость. Пользоваться этой дрянью не буду.»
как правило люди с таким подходом в свою очередь не часто использую сайты со сложным функционалом
вы знаете что у простых пользователей в большинстве сильверлайт уже установлен. ставится с винапдейтами
На хабре много «пользователе» которые априори ненавидят технологии silverlight и flash.
Им плевать, что у большинства пользователей эти плагины уже стоят.
А за что ненавидят? И вообще, как можно ненавидеть технологию? С головой поссорились?
На хабре 80% так или иначе адепты новой Империи Зла (смотрите Хабраиндекс).
Поэтому продукты от старой — ненавидятся автоматом :)
Новая Империя Зла это Гугл? Тогда непоказательно, их YouTube вполне себе использует флэш.
Была бы их воля… Но деньги зарабатывать для любого — важнее ненависти.
НЛО прилетело и опубликовало эту надпись здесь
Переводя ваши слова — вас бесит именно то что флеш отвратительно поддерживается вашей системой. То есть проблема именно в поддержке. При чём тут флеш?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
за то, что её приходиться устанавливать.

Пример google gears — она не критична нигде, где я видел её использование, в хроме она идет в коробке и я ей рад и пользуюсь.

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

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

Что же делает Флеш или Сильверлайт? «Для просмотра установите флеш» «Для просмотра потребуется сильврлайт»

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

А теперь давай подумаем, на кой мне изловчатся в установке непонятного софта на машину, только для того, что б просмотреть сайт метрополитена?
Раз вы говорите о WinXP, то Мозиллу и Хром вам тоже пришлось установить. Зачем вы это сделали, если в WinXP уже из коробки есть IE? Значит, у вас были причины их установить.

Люди, у которых есть необходимость в работе с сайтами, требующими флеш или сильверлайт, просто ставят их и не парятся.

Это просто технологии. Они имеют свою применяемость, а владельцы сайта выбрали эти технологии. Вы можете ненавидеть этих людей, но причём здесь флэш или сильверлайт?
Интересно, что уже два часа прошло, а про линукс так и не сказали вам. Говорю!
Аа… «у простых пользователей», извините.
А что, простые пользователи не в состоянии использовать какой-нибудь Linux?
Причем тут не в состоянии? Просто если вы, как и я после отправки первого своего камента, сабж перечитаете, то поймете, что речь идет о подавляющем большинстве. И в данном контексте «простой пользователь» — формулировка без капли неприязни или чего-то такого. Имеется ввиду человек использующий самый распространенный способ получения информации/технологию. Есть 100 500 статистик где наглядно показано, что линуксу 1% «десктопа» достается.
Да и вообще чего тут говорить… Внимательнее читайте, раз решили придираться.
Ubuntu популярна, её всё чаще ставят знакомым, родным, близким. Что касается «подавляющего большинства», такой формулировки я не увидел. И да, вы написали такой длинный возмущенный комментарий, что я на всякий случай скажу — минусовал не я.
Да за минусы я не парюсь, я не из активных пользователей сайта (хотя подумал что вы конечно :) ). Так и знал, что покажется что я возмущен, просто на хабре часто через 2-3 дня когда про тему забыли, кто нибудь напишет странный оффтоп придравшись к какому нибудь камменту, от которого пользы 0.
Кстати, я бы только был счастлив если бы людей использующих убунту, называли простыми пользователями. Но нам до этого далеко.
НЛО прилетело и опубликовало эту надпись здесь
И правильно сделали. JS очень мощный инструмент и не только в виде фишечек-рюшечек ;)
У меня включен Flash Blocker потому что флешь плагин течёт. А на большинстве сайтов флеш это баннер. Тоже самое с MonoLight. Поэтом если у меня есть выбор сайт на СВ, или Флешь или HTML то я выбиру html при прочих равных. Т.к. В инет магазинах покупают в основном люди близкие к IT индрустии то часть из них руководствуется тем же.
как мне сделать винапдейт на Debian 5.0 ядро 2.6.26
6.36 пардон
Несовместим с Silverlight на полные 100%. Примерно так же, как Windows и WINE.
помнится писали про сайт московского метро, что он мега красив и крут, но я его так и не увидел, ибо нужно было качать силверлайт и в итоге скачав его и перейдя на сайт, браузер завис нафиг и так раза 3 подряд. вот и подумайте оправдались ли усилия заказчиков и разработчиков, которые писали это говно на силверлайте. максимум флэш, сайты должны быть доступны!
Я бы не смог открыть такой каталог, т.к. у меня Linux ((( Лучше бы сделали апплет…
сделал на Silverlight

да ты же упоротый!
Интернет-магазин не та область, где можно использовать подобный подход.
Обоснуйте такой категоричный вывод
Очевидно же — поисковики не найдут ваш контент.
Мне кажется подобный подход куда лучше для админки данного магазина: возможность быстрее и комфортнее работать оператору.
Очевидно, что можно использовать обычные ссылки, которые будут вести на страницы с товарами. А при клике пользователя, запрашивать json-данные.
К тому же, сейчас все поисковики понимают xml-карты сайтов.

+ Автор использует json данные для поиска по товарам…
Опередили:)
Так же у них (поисковики) есть возможность импорта товаров.
Так никто не мешает делать нормальные линки на каждую единицу товара. Если не поддерживается клиентом — то выдаем дубовый html.
Опять же, sitemap никто не отменял.
И экспорт в Маркет — отдельный модуль.
Так что ничего особо критичного не вижу.
Прочитайте внимательно:
>> это не замена… но её (RIA) можно активировать, в случае использования посетителем современного браузера

проверяем с помощью jQuery браузер

if(!$.browser.ie6/7/8 по вкусу){
activateRIA();
}

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

Короче говоря — статья ни о чем. Ровным счетом.

P.S.
У вас в магазине можно ставить несколько раз галку в одном из фильтров (например цена до 14 000р и от 30 000 — 46 000 и при этом происходит не дизъюнкция результатов а конъюнкция)
Пару лет назал увидел один магазин ноутов с такой приблудой, правда без «кеширования», поддрежка / разрабока RIA магазина гораздо более трудоемкая => медленнее => более дорогая.
> Стоит ли оно того?
Зависит от ассортимента и аудитории. Мои наблюдения и сбор статистики по нескольким магазинам «не для гиков» показали, что люди в большинстве своем просматривают товар, просто перемещаясь по каталогу, оставляя фильтры без внимания. Внедряя подобные вещи, нужно тратиться на неслабое тестирование — клиент-сайд все-таки, и браузерный. Вообщем для большого магазина(в смысле — с большим ассортиментом) вещь не факт что подходящая, а для маленького — рискованная.
Даже если сделать pagination средствами ajax — это сильно ускорит работу магазина для конечного посетителя.
НЛО прилетело и опубликовало эту надпись здесь
Если отмечена цена ноутбука до 15.000, то можно сразу скрыть те параметры фильтра, выбрав которые не будет товара при поиске. Т.е. если стоит галочка на 15.000, было бы удобно, если галочка Объём оперативной памяти — 4 гб была бы неактивна, т.к. таких моделей нет в поиске.
это уже запары бизнес-логики
замечание по сортировке — это у вас она быстрая, а вот у некоторых не очень, потому всеравно на операцию ставьте хотя бы cursor: wait
за идею 5+
вопрос о совместимости — на чем и как тестировали? ие?
возможно стоит подгружать картинки товаров в data:uri?
Когда думал, как оптимизировать тяжёлый сайт, тоже задумался об data:uri. Погуглив достаточно и поигравшись понял, что это решение, к сожалению, очень сырое и бажное. Надо делать умное кэширование со стороне сервера и браузера — об этом я позже напишу.
эммм, оно не сырое, просто не работает нормально в ие, кроме магической 9-ки (в 8-ке ограничение в 32 кб на картинку).
умное кеширование — вы про _http://site.com/images.css?v1 или про что-то другое? если да, то схема ничем не отличается от создания того же массива JSON для js, дальше все зависит только от меры оптимизации — можно вообще сжимать сразу после изменения в gzip статические архивы и подсовывать nginx.

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

В целом, если ту же lenta.ru генерировать, учитывая модульность, статику данных и картинку в base64 можно очень разгрузить сервер.
Представьте себе, что RIA-вариант того же Хабра, отдаёт всем статический каркас страницы,
а client-side движок на js+jquery фетчет данные о текущих топиках и других «модульных» данных из статических json`ов, которые генерирует динамика сервера единожды.

Хабр может летать. Другой вопрос — это pageview сходит на нет, а этим хвастаются рекламодателям :)
Единственный минус открытость данных, кто угодно может стянуть полный ассортимент продукции… Является ли это секретом другой вопрос.
да в общем-то они и так в интернете. соскрейпить за полчаса-час можно
это даже плюс. Если я кулхацкер, к примеру — заскриптовал, а потом |grep «Asus rt-n16» :)
Какой недостаток я вижу сразу: если я захочу другу дать ссылку на новинки процессоров, отсортированные по цене, в магазине обычного типа я смогу это сделать:
www.citilink.ru/catalog/parts/cpu/?showOrder=6&available=1&showStatus=2

А в риа? На вашей демке урл не поменяется: sandbox.tematico.ru/citilink/#/cat/parts/cpu/

В общем риа еще пилить и пилить всякие такие мелочи
Конечно пилить. Я же не готовый интернет-магазин делал, а демку концепта. Всё это реализуемо.
Ясно что реализуемо, вопрос в том сколько это займет времени (и денег) на разработку и насколько такой магазин будет прибыльнее обычного (окупятся ли затраты).

Хотя если задача чисто имиджевая для раскрученного магазина то можно и заморочиться
Да ну, это элементарно решается через location.hash. Посмотрите как меняется урл в яндекс музыке или простоплеере без перезагрузки всей страницы. Сам такое реализовывал — делается на раз-два.
hashchange это всего-лишь возможность использовать хистори.
Сам функционал-то писать придётся на js (посмотрите исходники)
Ну так фукционала не так уж и много. Читать из location.href при загрузке страницы, чтобы показать нужную категорию и т.д., и писать в location.href при клике на ссылку, делать preventDefault чтобы не перезагрузилась страница.
В данном случае читать весь location.href не надо, достаточно location.hash
Все верно, это я опечатался.
Прочитайте внимательно:
>> это не замена обычной модели … но её (RIA) можно активировать как «слой», в случае использования посетителем современного браузера

проверяем с помощью jQuery браузер

if(!$.browser.ie6/7/8 по вкусу){
activateRIA();
}

Поисковик и пользователи ie6 будут получать стандартный вид интернет-магазина.
Да, я в курсе. Но проблема в том что тогда нужно писать два магазина. Один обычный, и второй RIA.

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

риа активируется в браузере, а сам по себе это просто html
Очень интересный «концепт», работает действительно быстро. Но соглашусь с критикой — это двойная разработка интернет-магазина, двойная поддержка, двойной дебаггинг. Возможно, стоит кешировать json-файлы выборок на стороне сервера и каждый раз их отдавать? Для наиболее актуальных выборок можно достичь сравнимой скорости без главных недостатков такого решения…
Всё верно и я это отметил в статье.

Но, если бы мой любимый компьютерный интернет-магазин дал возможность юзать его в RIA-варианте в хроме, опере или фф — было бы просто отлично. Акции магазина сильно бы выросли в моих глазах =)
Но количество потраченных денег осталось бы на прежнем уровне?:)
Даже не двойная. Обычно усложнение функционала в 2 раза приводит к усложнению разработки в 4 раза.
Проверил на IE 7 под XP, CPU dualcore 2 герца. На такой машине я предпочел бы сайт без логики на стороне клиента (RIA), тормоза просто недетские, а машина побыстрее среднестатистического нетбука будет.
Да IE7/8 в этом случае не айс по скорости. Тут зависит от интернет-магазина, где-то можно и включить RIA для осликов, а где-то лучше не включать.
Поиск в демке ведётся только по маленьким буквам. Если встречается хоть одна заглавная, то пишет, что ничего не найдено.
На всякий случай пишу :)
Странно, у меня в chrome, opera, ff, ie7/8 поиск не зависит от регистра.
Действительно странно. WinXP, Chrome:

Спасибо, fixed.
Ребят, а каких поисковиках идет речь?
Вы забыли правило, что мы сайты делаем для людей, а не для поисковиков.

Нужно просто уметь совмещать технологии.
AJAX тоже по началу все боялись.

Хорошая реализация, хорошей идеи.
Спасибо, автор!
Никто и не спорит что нужно совмещать. Только хороших работающих решений пока никто не предложил.

А забивать на поисковики не стоит, без них люди могут и не дойти до вашего суперудобного магазина.
Концепт интересен, и, в принципе, пользователю можно кидать по onload на загрузку эти файлы, чтобы при поиске они сразу использовались. Но, имхо, это достаточно локальная проблема. Ибо конкретный прирост в скорости (с RIA / без RIA) достаточно мал, чтобы о нем думать. Обычно необходимо первичную оптимизацию провести.
Всё-таки, как ни крути, полный релоад странички — это всегда как минимум запросы к серверу об изменениях всех файлов и ещё рендер скриптов, страницы (мелочь, но всё же) — это не может быть быстрее той же AJAX-подгрузки данных. В приципе.

Думаю это очевидно, что пользователю (а именно о них мы должны думать) субъективно вторая модель будет видеться быстрее.
99 секунд, как ни крути, быстрее, чем 100. Но нужно ли думать о разнице в 1 секунду?
Вы, видимо, не поняли о чём я.

После релоада странички обычным способом, даже если данные (все файлы) не изменились, браузеру надо в этом удостовериться, отправив запросы на сервер if-modified-since

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



10мс быстрее 700+мс.

Думать о разнице в 690мс стоит.
Пример искусственный, честно. Обычно при серверной перезагрузке страницы только HTML + счетчик запрашивается + время на рендеринг (которое в общем случае почти такое же выходит). Да, разница есть, 50-100 мс, наверное. Но на фоне непожатых, и необъединенных, и незакэшированных JS-файлов это фигня :)
Браузер при серверной перезагрузке страницы всегда запрашивает актуальность всех подключаемых файлов html/css/js/img/embedded etc.

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

При переходе на другую страницу запрашивается только хтмл+счётчики, при условии, что у всех объектов загруженных вначале указывается заголовок expires +n.

Если у объекта expires прошедший или такой же как и заголовок date, то даже, перейдя на другую страницу — они-таки проверятся на модификацию запросом if-modified-since.
Но на фоне непожатых, и необъединенных, и незакэшированных JS-файлов это фигня

Действительно, один раз загрузить эти данные — ничего страшного,

по сравнению с

каждый раз ждать ответа сервера на актуальность всех объектов страницы, какой бы она не была оптимизированной, объеденённой и закэшированной.
Если на сервер не отправлять данные о блокировке товара (бронировании), то на момент оформления заказа, нужного товара уже может не оказаться на складе (его купил кто то другой). Естественно для интернет магазинов это не особо критично, а вот при покупке билетов в кино/на самолет/на поезд данная модель не подходит, хотя опять же возможен какой то костыль.
Эти данные можно сделать отдельными запросами, которые не кэшируются. А основную часть можно кэшировать. Так как в описании того же кинофильма, например, ничего не поменяется :)
Если в диалоге «мой заказ» удалить все позиции, то 1 «призрачный» товар все же остается.
У меня эта концепция на бумаге уже как 2 года валяется, не слишком знаю JavaScript, хотя это и не очень сложно, думал все знали об этом и не делали из своих предубеждений.
Задумка у меня относилась не только к магазинам, но и социальным сетям.
Так можно ускорить любой сайт, даже Хабр может летать ;)
А где там собственно RIA?
Знакомьтесь www.ecwid.com/ (отечественная разработка)
Там используется 2.0 функционал — ajax подгрузка данных. Тут несколько иное.
Т.е. функционал всё-равно делается на сервер-сайде.

Я предложил концепт — функционала на клиенте.

В демке всё — статика. Динамика сервер-сайда отсутствует.
В Опере 10.63 «ничего не найдено» при выборе любых галочек в Статусе. В Хроме работает.

Уже fixed.
Мы в прошлом году подобный проект реализовали «вживую». Поиск частных объявлений: siftia.com
и сразу вам косяк


Проект неактивный, начальство на него забило. Вот, думаю сам добить на node.js, но в порядке частной инициативы. А пока работает, как работает — через пень-колоду. Я вообще удивлен, что через год, без обновления парсеров, он еще что-то (хотя и не полностью) ищет.
Кстати, это был не пиар, я просто хотел продемонстрировать, как мы такое реализовали.
тест
Этой идеи как минимум лет пятнадцать. Ведь когда вы кликаете на «авторизоваться», то попапы всплывают без перезагрузки.

Вашу демку тоже изобрели несколько лет назад: www.datatables.net/ и даже очень много раз изобрели: www.webdesignbooth.com/15-great-jquery-plugins-for-better-table-manipulation/

Хотя Вы подошли к делу более глобально, предложив спроектировать таким образом весь сайт. К сожалению, только на словах, без демки.
Ну здрасьте. А тот же гмейл разве не по такому же принципу? +1 предыдущему оратору — этой идее уже лет 15 =)
Проблема заключается в том, что на скорость работы слишком сильно влияет производительность пк пользователя. Сложность тестирования. Чем больше сайт — тем сложнее его будет делать в геометрической прогрессии и тем медленее он будет работать, независимо от кол-ва серверов у вас. Отлов багов у пользователей превращается в nightmare.

Ну и тд и тп.

Получается что для маленьких магазинов (не бутиков =)) — непозволительная роскошь, а для больших — слишком тяжелые затраты на поддержку.
Прежде, чем комментить, надо внимательно вчитываться в текст. И в заголовок. Потом опять. Внимательно. Потом смотреть файрбагом работу того, с чем сравниваете.

Серверный функционал и динамическая подгрузка данных ajax'ом данных от бэкэнда != клиентский функционал и загрузка данных в кэш из статики фронтэнда, без использования бэкэнда.

Да, гмейл работает по другому принципу. И он не интернет-магазин.

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

P.S. где в тексте упоминания о новизне идеи? это лишь применение гибрида новых технологии в сфере интернет-магазинов, не более.
при просмотре демки, хром просто отваливается
1. Зайдите в оригинальный интернет-магазин, поиграйтесь с сортировкой, фильтрами и т.п. — субъективно запомните скорость от отклика до отображения данных.
Сайт грузится ужасно долго, но поиск и фильтры работают превосходно. Несмотря на тормоза, пользоваться удобно, был бы такой магазин в моём городе — пользовался бы им.

2. Сравните скорость в демке интернет-магазина (RIA) (функционал реализован исключительно на стороне клиента с помощью javascript+jquery. Nginx отдаёт только статику. Никаких php, apache, mysql и т.п.).
Как программист — повосхищался подходом. Как пользователь — увидел, что автор настолько увлёкся наворотами, что забыл сделать версию без них, в итоге у меня получилось лишь увидеть подобную картинку, повосхищаться затемнением фона выбранного элемента и всё — ни списков, ни фильтров, ни даже товара по категориям мне увидеть не удалось.

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

Меня удивляют некоторые комментаторы, которые пишут, даже не вникнув (или не читав?) в текст топика, где отмечено, что это «слой», а не замена. Что это демо и не все реализовано, но реализуемо.

Это всего-лишь демонстрация подхода, возможности сделать RIA-слой для некоторой (продвинутой) аудитории своего интернет-магазина.

А на счёт конкуренции — на западе делают специальные версии сайтов под iPhone и iPad — а это немаленькие деньги на разработку. Они, по вашему, гонятся за «делами десятыми»? — Нет, это ещё один способ привлечь аудиторию, возможно от олдфаг-конкурентов.
{% trolling %}Меня просили «зайти, поиграться, сравнить». В точности это я и проделал.{% endtrolling %}
Вы меня убедили.
Кстати, раз уж вы программист, с удовольствием прикручу вашу версию для демки интернет-магазина для noscript'еров, т.е. сервер-сайд решение. Сколько у вас уйдёт личного времени на это?
У меня не noscript, отнюдь. JavaScript и Java включены, но не в этом суть. На сервере есть два типа решения — с использованием server-side-JavaScript и с использованием иного языка программирования. По поводу первого при работе с БД я не знаю абсолютно ничего. По поводу второго — в случае нормализованной базы достаточно сделать что-то вроде (код не проверял):

Для поиска доступных параметров:
filters = {}
for parameter_name in current_item_type.CAN_BE_FILTERED_ON:
    values_list = CurrentItemType.objects.distinct(parameter_name).values_list(parameter_name)
    filters[parameter_name] = [lst[0] for lst in values_list]

Для фильтрации объектов по параметрам:
queryset = current_item_type.objects.all()
for parameter_name in current_item_type.CAN_BE_FILTERED_ON:
    value_exact = request.GET.get(parameter_name)
    queryset = queryset.filter(**{parameter_name:value_exact})


И передать в шаблон queryset и filters и сформированный аналогичным образом current_filter. Много ли это времени займёт? Нет. А пагинацию добавить? В Paginator() обернуть queryset. А если приделать сортировку по любому полю? Ещё пять строчек. А группировку по любому? Ещё больше. А чтобы плясало и кофе варило? А чтобы и html-шаблоны я писал? А ещё чтоб сервер тоже я админил? В итоге получаем, что на вопрос «сколько у вас уйдёт времени» я ответить вам не смогу, не зная задачи в точности.
Как это не знаете задачи в точности? Исходники доступны. Сделать копию, только на сервер-сайд лад. Чтобы без JS работало.

Энивэй, вы явно не уловили намёка моего предыдущего комментария.
Давайте договоримся на том, что когда мне захочется познакомиться с языком JavaScript, ваш код будет одним из первых, который я почитаю?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.