Python-сообщество

Lexander, это зависит от того, какой сайт делать. Сегодня контентная часть всё дальше уходит на второй план, а гуугл постепенно учится работать с современными приложениями. Я всё жду, когда хром начнёт отправлять гууглу не только посещённые ссылки, но и индекс с DOM-дерева страницы…

PooH, там слишком много разных чудес. Надо пользовать.
Правда кривая изучения уж очень резкая…

Отредактировано ZZZ (Июль 29, 2013 11:32:00)

ZZZ
это зависит от того, какой сайт делать.

Да, потому и написал, что для сайтов в виде веб-приложений вполне себе подходит.

ZZZ
Сегодня контентная часть всё дальше уходит на второй план

Судя по докладам на последней конференции в Одессе, контент - и еще раз контент.

ZZZ
гуугл постепенно учится работать с современными приложениями. Я всё жду, когда хром начнёт отправлять гууглу не только посещённые ссылки, но и индекс с DOM-дерева страницы

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

Я думаю, что само появление шаблонизаторов, работающих на клиенте (в браузере) стало возможным только из-за возросшей мощности техники и скорости движков.
Под влиянием огромной армии javascript-программистов эта вся движуха распространилась на сервера и мы стали очевидцами появления node.js с собратьями.

Однако, браузеры хоть и позволяют достаточно быстро работать с большими кусками кода и сложными манипуляциями на клиенте, но остаются все еще неоптимизированными под такой механизм.
Посмотрите на события при работе веб-приложения и сравните с работой традиционного способа заполнения шаблонов на сервере. Слишком много времени и ресурсов тратиться на обслуживание манипуляции с DOM, т.к. браузер старается поскорее привести в актуальное состояние DOM и дать возможность пользователю работать с ним дальше.
А на мобильных платформах становится уже критичным не только необходимая вычислительная мощность, но и, как следствие, энергозатраты.
На мобильных еще есть куда более энергозатратные участки, оптимизацию которых клиент оценит гораздо больше: WiFi, GPS.

Резюмируя, на рынке уже есть специалисты под эти технологии, но сам рынок еще не готов их использовать: как финансово, так и технологически.

Ну не знаю… По мне так куда приятнее отдать часть работы клиенту, чтобы он радовался отзывчивому интерфейсу даже при плохой сети, а мы радовались уменьшению нагрузки. Благо, что современное клиентское железо позволяет это без особого труда.
Единственная реальная проблема, это отдача контента поисковикам. Но думаю, что это будет полностью решено уже в ближайшее время.

P.S. И да, бизнес прекрасно рискует и не имеет ничего против новых технологий. Это программисты боятся всего нового.

А я вот не понимаю что поисковику индексировать в веб-аппе. Веб-апп это же сервисы для зарегеных юзеров. Т.е. если есть какой-то контент который хотелось чтобы проиндексировался, то он должен быть для анона, значит для анона делаем отдельный html выхлоп, поисковик его проиндексирует и будет на него отправлять. Или как?

А чем не нравится такой вариант - контролер отдает в шаблон список инициализированных блоков, а шаблон просто вызывает для каждого блока из списка render. Каждый блок имеет собственный шаблон. По такому принципу работают формы в Django, ToscaWidgets, да много где еще.

Обязательно посмотрю, как-то не задумывался об этом. Спасибо. При таком варианте вроде бы ничего не дублируется и можно расширять приложение без правки основного шаблона..

AngularJS - это хорошо, но тогда, как я понимаю, нельзя будет реализовать кеширование на уровне веб-сервера..

Вставка блоков веб-сервером - слишком экзотично для наших задач. Если идти таким путем, то тогда и впрямь делать шаблонизацию полностью на клиенте и передавать только данные..

За подсказку про Pyramid - спасибо. К сожалению, у меня немного опыта с Python для веба, буду это наверстывать.

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

Отредактировано maxfox (Июль 29, 2013 18:29:29)

maxfox
AngularJS - это хорошо, но тогда, как я понимаю, нельзя будет реализовать кеширование на уровне веб-сервера..

можно, запрашивайте блоки через GET с параметрами, они и будут кешироваться. (+ кеш худее)

ZZZ
Ну не знаю… По мне так куда приятнее отдать часть работы клиенту, чтобы он радовался отзывчивому интерфейсу даже при плохой сети, а мы радовались уменьшению нагрузки. Благо, что современное клиентское железо позволяет это без особого труда.
Единственная реальная проблема, это отдача контента поисковикам. Но думаю, что это будет полностью решено уже в ближайшее время.

Я написал несколько больших проектов - нахапал кучу граблей, и теперь разделяю как разные типы: web-приложения и сайты. И я больше согласен с Lexander, для приложений ajax (knockoutjs/angularjs/…) для сайтов - шаблонизация на сервере + некоторые плюшки и редактирование через ajax.

Есть у меня не маленький сайт почти полностью на knockout.js (вся шаблонизация на клиенте), спустя 2 года я считаю это архитекртурной ошибкой. С этим конечно можно жить, но минусов хватает. Например скорость загрузки, при пинге = 100мс, сверстанная на сервере страница прилетает через 130мс. С ajax-ом, базовый html (болванка) прилетает через 100мс (он не кешируется т.к. все урлы разные!) далее загрузка js, - ещё + 100мс (для ответа что файл не изменен, хотя можно ускорить) потом летит запрос на текущий объект + 100мс, + у меня ещё подъезжают справочники через GET (хотя они обычно закешированы на клиенте), в итоге имеем более 300 мс - это в 2-3 раза. А если js-скриптов у клиента нет, то загрузка этих jquery, angular, ….. то первый ajax летит через 500..800 мс. Конечно это все ещё будет оптимизироваться, есть идея как приблизиться к 1 варианту по скорости, но пока так.

На счет

Но думаю, что это будет полностью решено уже в ближайшее время.

я сомневаюсь, сейчас основной метод парсинга ajax приложений - это escaped_fragment, из мажоров его поддерживают яндекс и гугл, бинг забил болт на это. Этому методу 5 - 7 лет, и улучшений не предвидится.
Как то так.

забыл написать, что сайты на 80-99% используются как “на посмотреть”, т.е. на 90% случаев там ajax не нужен.