Если JUST будет быстрее, надо будет понять почему и сделать так у себя.
Про шаблонизатор, главная задача была научиться готовить JS на сервере.
Поэтому взяли 100% проверенный фомат. Я чуть позже напишу очень большой пост про fest там будут все за и против.
У нас среднее время трансформации на списке при нагрузочных тестах писем меньше 2ms.
Возможность использовать все возможности JavaScript в шаблона на сервере.
XSL и по скорости и по возможностям проигрывает, хоть я его и очень сильно люблю.
У нас работа с письмами реализована через аякс, но с поддержкой кнопки back.
Так вот вы открываете письмо, history в браузере физически меняется. Жмете back, браузер открывает предыдущую страницу, пытаясь проскролить body в пердыдущее положение. Но список писем отрисовывается аяксом и он не всегда не месте, т.е. высота страницы не та что была. После аякса мы доскроливаем в нужно положение, но будут неприятные передергивания скрола.
Чтобы небыло скачков мы делаем два дива, один с overflow и высота body всегда не больше высоты окна браузера. Браузеру скролировать нечего. А когда мы точно знаем что наполнили страницу содержимым, то сами скролим в нужную позицию.
Главная не трогалась очень давно. И в принципе главная это не типичный проект.
Мы ее оптимизируем, но вставка скиптов и стилей не всегда плохо. Часть скиптов и стилей у нас в коде для того, чтобы пользователь как можно быстрее увидел некоторые блоки. В ущерб остальным.
Плюс есть портальная навигация, выносить стили и скипты в файлы из нее может быть плохим решением. Дело в том, что на сервере проекты берут портальную навигацию как кусок html из одного места с системой доставки и кеширования, а раздают сами (я про сервера). В случае вставки ссылок на скрипт весь mail.ru и одноклассники будут брать этот скрипт из одного места, а это опасно. Если что-то случается с этим сервером, то миллионы пользователей увидят побитые страницы.
Еще есть аякс и инициализация объектов по действиям пользователя. Поэтому нет такого события, по которому однозначно можно понять что все компоненты проинициализировались и больше ничего не появится.
Лично я выбрал такие значения:
0 — нет очереди
>0 очередь указанной длинны
-1 в принципе хранить все что пришло.
Но на практике мне кроме 0 и 1 ничего не понадобилось.
Про доставку, в очередь надо смотреть только если появился новый слушатель и отдать ему все что в очереди.
Если слушатель уже висит то очередь бесполезна, он сразу ловит события как только они произошли.
Про реализацию. Как только в callback приходит observe или dispatch я проверяют что у объекта нет __UNIQID и дописываю его используя инкрементирующийся счетчик. Если есть, то использую имеющийся. Дальше у вас есть __UNIQID строкой, имя события строкой и данные. Из первых двух составляется ключ, вторыми наполняется массив, длина которого ограниченна длинной очереди. Ключ указывает на массив.
Она очень сильно зависит от реализации проекта.
Плюс вы можете сделать JS функцию lang('key') и прекрасно с этим жить.
Но если нужна прям логика то можно ее обернуть в <fest:script/>
Это достаточно легко встраивается в любую архитектуру.
Но, тем не менее, основной поинт что JavaScript на сервере это уже сегодня, и мы тоже это проверили на себе.
Но, допустим мы решаем что это приемлимо, всеравно будут блоки с шаблонизацией на сервере.
Про шаблонизатор, главная задача была научиться готовить JS на сервере.
Поэтому взяли 100% проверенный фомат. Я чуть позже напишу очень большой пост про fest там будут все за и против.
Возможность использовать все возможности JavaScript в шаблона на сервере.
XSL и по скорости и по возможностям проигрывает, хоть я его и очень сильно люблю.
У нас работа с письмами реализована через аякс, но с поддержкой кнопки back.
Так вот вы открываете письмо, history в браузере физически меняется. Жмете back, браузер открывает предыдущую страницу, пытаясь проскролить body в пердыдущее положение. Но список писем отрисовывается аяксом и он не всегда не месте, т.е. высота страницы не та что была. После аякса мы доскроливаем в нужно положение, но будут неприятные передергивания скрола.
Чтобы небыло скачков мы делаем два дива, один с overflow и высота body всегда не больше высоты окна браузера. Браузеру скролировать нечего. А когда мы точно знаем что наполнили страницу содержимым, то сами скролим в нужную позицию.
Мы ее оптимизируем, но вставка скиптов и стилей не всегда плохо. Часть скиптов и стилей у нас в коде для того, чтобы пользователь как можно быстрее увидел некоторые блоки. В ущерб остальным.
Плюс есть портальная навигация, выносить стили и скипты в файлы из нее может быть плохим решением. Дело в том, что на сервере проекты берут портальную навигацию как кусок html из одного места с системой доставки и кеширования, а раздают сами (я про сервера). В случае вставки ссылок на скрипт весь mail.ru и одноклассники будут брать этот скрипт из одного места, а это опасно. Если что-то случается с этим сервером, то миллионы пользователей увидят побитые страницы.
0 — нет очереди
>0 очередь указанной длинны
-1 в принципе хранить все что пришло.
Но на практике мне кроме 0 и 1 ничего не понадобилось.
Про доставку, в очередь надо смотреть только если появился новый слушатель и отдать ему все что в очереди.
Если слушатель уже висит то очередь бесполезна, он сразу ловит события как только они произошли.
Про реализацию. Как только в callback приходит observe или dispatch я проверяют что у объекта нет __UNIQID и дописываю его используя инкрементирующийся счетчик. Если есть, то использую имеющийся. Дальше у вас есть __UNIQID строкой, имя события строкой и данные. Из первых двух составляется ключ, вторыми наполняется массив, длина которого ограниченна длинной очереди. Ключ указывает на массив.