Comments 53
UFO just landed and posted this here
UFO just landed and posted this here
«Переложить навигацию и загрузку с HTTP в Javascript» – Javascript тоже использует HTTP для загрузки. Очень странный комментарий.
В остальном – спасибо за ваше мнение, но давайте обойдемся без троллинга и холиваров. Эта статья не о том как клево или не клево использовать RICH. Она для тех, кто свой выбор уже сделал.
В остальном – спасибо за ваше мнение, но давайте обойдемся без троллинга и холиваров. Эта статья не о том как клево или не клево использовать RICH. Она для тех, кто свой выбор уже сделал.
UFO just landed and posted this here
Угу. Лучше уж использовать что-то типа continious integration. Сделали обычный сайт, затем на него навесили аякс. Тем более, что многие фреймворки давно уже имеют встроенные хелперы типа $this->isXmlRequest(). Тогда никто не потеряет в функциональности. Плюс, хешбенг несет в себе жуткие ограничения на архитектуру (если его используете, то нельзя отдавать страницы без него). Лучше уж History API + обычный хеш (либо вовсе для старых браузеров отказаться от аякса).
UFO just landed and posted this here
Яндексу можно пытаться скармливать «escaped_fragment-ированные» ссылки в Sitemap.
В целом состояние с индексацией AJaX — печальное. Львиная доля форумов и блог-движков (включая Хабр) и часть мессенджеров не понимают ссылки с хешбенгами, соответственно, получение веса от внешних ссылок для таких страниц закрыто. Обычные люди не понимают, как такие ссылки передавать и как по ним переходить. При загрузке страница мигает (контент на /-странице заменяется контентом по ссылке из хешбенга).
Из приятного — на горизонте маячит HTML5 History API, который частично проблему передачи и непривычного вида ссылок решит.
В целом состояние с индексацией AJaX — печальное. Львиная доля форумов и блог-движков (включая Хабр) и часть мессенджеров не понимают ссылки с хешбенгами, соответственно, получение веса от внешних ссылок для таких страниц закрыто. Обычные люди не понимают, как такие ссылки передавать и как по ним переходить. При загрузке страница мигает (контент на /-странице заменяется контентом по ссылке из хешбенга).
Из приятного — на горизонте маячит HTML5 History API, который частично проблему передачи и непривычного вида ссылок решит.
На самом деле, History API сделает только хуже. Если есть возможность генерировать сразу весь HTML на сервере, то порционная его загрузка – это полумера. Настоящее веселье заключается в переносе на клиент вообще всего представления, включая рендеринг. И тогда History API просто не работает. Вообще.
Лично я считаю, что будущее за браузером в виде виртуальной машины, а web-сервера станут просто REST Application-серверами. При таком подходе hashbang'и, конечно, костыль. Но лучше ничего просто нет. Поэтому это вопрос проникновения и привычки. Ну и наличия критической массы инструментов, таких как Hashbang, которые решают типовые проблемы, связанные с таким технологическим стэком.
Лично я считаю, что будущее за браузером в виде виртуальной машины, а web-сервера станут просто REST Application-серверами. При таком подходе hashbang'и, конечно, костыль. Но лучше ничего просто нет. Поэтому это вопрос проникновения и привычки. Ну и наличия критической массы инструментов, таких как Hashbang, которые решают типовые проблемы, связанные с таким технологическим стэком.
Да почему же? History API вполне себе работает. Пример — ippk.sfedu.ru (к оформлению и содержимому не цепляйтесь :)). Попробуйте походить по ссылкам. Для браузеров, которые не понимаю History API (к примеру, старый IE), видны простые ссылки. И индексируется отлично ;).
Нет нет, вы не совсем меня поняли. Он работает, безусловно. Я лишь про то, что Hashbang создан для случаев, когда рендеринг шаблонов выполняется в браузере. А сервер ничего не рендерит вообще. Если мы используем History API, у нас нет способа разграничить серверную часть и клиентскую. А с #! – есть.
Хм, видать и в правду плохо вас понял. Но, если рассмотреть картину идеального взаимодействия клиента с сервером, то, на мой взгляд, на клиенте должна быть просто картинка и все, как некий видеопоток с возможностью отсылать на сервер действия мышки, клавиатуры и т.п., а сервер возвращает следующие кадры. В итоге от клиента требуется минимума производительности, что сэкономит батарею и цену железа под такой клиент, но возрастет нагрузка на сервер, что, по моему мнению, обойдется дешевле. Вроде что-то подобное пытаются сделать с видеоиграми…
Спорный момент. Серверов всегда меньше чем клиентов. Игры слишком максималистичный вариант – это скорее исключение. Рендеринг шаблонов не такая затратная операция для браузера. Но стоит ее умножить на миллион клиентов, как она становится затратной для сервера. То есть на клиенте мы ее не замечаем, но:
1) Передаются только данные в JSON, канал разгружается от лишнего HTML.
2) Мы управляем рендерингом там же, где работает код, который управляет динамикой. Это невероятно удобно и дает много доп. возможностей. Это, на самом деле, основная цель. Мы можем добавить эффекты в переходы между страницами, хорошо структурировать клиентский код и т.п. Javascript'а в современных ресурсах все больше и сопрягать его с серверной частью все сложнее.
3) Ну и нагрузка на сервера меньше. Для сложных представлений рендеринг – вполне заметная операция.
4) Удобнее кооперироваться. Я противник четкого выделения ролей в команде, но всегда есть люди, которым больше нравится писать на Ruby и люди, которым больше нравится возиться с прямым взаимодействием с пользователем. С таким подходом обе категории становятся счастливее :).
Я вначале написал, что Hashbang создавался после нашего повального увлечения другой нашей разработкой, Joosy. Посмотрите 3 первых гайда (0,1,2) на guides.joosy.ws – вот как и с чем мы работаем
1) Передаются только данные в JSON, канал разгружается от лишнего HTML.
2) Мы управляем рендерингом там же, где работает код, который управляет динамикой. Это невероятно удобно и дает много доп. возможностей. Это, на самом деле, основная цель. Мы можем добавить эффекты в переходы между страницами, хорошо структурировать клиентский код и т.п. Javascript'а в современных ресурсах все больше и сопрягать его с серверной частью все сложнее.
3) Ну и нагрузка на сервера меньше. Для сложных представлений рендеринг – вполне заметная операция.
4) Удобнее кооперироваться. Я противник четкого выделения ролей в команде, но всегда есть люди, которым больше нравится писать на Ruby и люди, которым больше нравится возиться с прямым взаимодействием с пользователем. С таким подходом обе категории становятся счастливее :).
Я вначале написал, что Hashbang создавался после нашего повального увлечения другой нашей разработкой, Joosy. Посмотрите 3 первых гайда (0,1,2) на guides.joosy.ws – вот как и с чем мы работаем
Зато сервера могут быть нагружены постоянно и использовать свой ресурс по максимуму, а клиентское железо, в большинстве случаев, большую часть своей «жизни» простаивает. Цены растут и цена простоя вместе с ними.
А Joosy обязательно рассмотрю повнимательнее как некую концепцию.
А Joosy обязательно рассмотрю повнимательнее как некую концепцию.
Честно говоря, мне совершенно непонятен Ваш подход, Владимир. Издавна люди стремились к кластеризации. Сервер и так будет нагружен, ему с головой хватит обработки бизнес-логики и удерживания СУБД. А клиентские машины представьте себе как эдакий огромный кластер, который обрабатывает именно часть с представлением.
Я не могу представить себе ситуацию, когда на любом современном железе (включая мобильные телефоны) люди будут жаловаться, что де «не открывается сайт, комп перегружен». А вот от перегрузки серверов все падает регулярно. Сервера не просто и так не простаивают, они не справляются. А вот клиентские мощности как-раз не задействованы вообще.
Я не могу представить себе ситуацию, когда на любом современном железе (включая мобильные телефоны) люди будут жаловаться, что де «не открывается сайт, комп перегружен». А вот от перегрузки серверов все падает регулярно. Сервера не просто и так не простаивают, они не справляются. А вот клиентские мощности как-раз не задействованы вообще.
Ну а смысл, к примеру, мощного процессора в телефоне / ноутбуке и т.п., когда он просто лежит и не работает (ну, почти не работает). А так железо бы работало. То, что под мое представление идеального нет инфраструктуры — на то он и идеал, что не достижим :).
Ну а сайты на мобилках-то открываются, вот только проблемы с производительность вполне могут быть. Ну и проблема с не обновляемым ПО… Возможно все это можно было бы решить, если бы сервер отдавал просто видеопоток.
Ну а сайты на мобилках-то открываются, вот только проблемы с производительность вполне могут быть. Ну и проблема с не обновляемым ПО… Возможно все это можно было бы решить, если бы сервер отдавал просто видеопоток.
С рендерингом их не будет. Проверено. С эффектами, любым сложным взаимодействием с клиентом – да. С рендерингом – нет.
Касательно вашего представления о мире – я понял, это действительно идеал. Процессоры в телефонах уже есть. Не использовать их глупо. Вот такая простая логика. А что могло бы быть в теории… Люди же ходили по этому пути – были простые терминальные клиенты. Не пошло. В первую очередь потому, что сделать facebook, который всем будет стрим видео раздавать интерактивного – это на порядки больше нагрузки. А им ее и так хватает. Это просто не работает :\
Касательно вашего представления о мире – я понял, это действительно идеал. Процессоры в телефонах уже есть. Не использовать их глупо. Вот такая простая логика. А что могло бы быть в теории… Люди же ходили по этому пути – были простые терминальные клиенты. Не пошло. В первую очередь потому, что сделать facebook, который всем будет стрим видео раздавать интерактивного – это на порядки больше нагрузки. А им ее и так хватает. Это просто не работает :\
Хватит уже говорить, что рендринг страницы\шаблона\представления выполняется на сервере, на сервере максимум может генерироваться разметка, а ее рендринг всегда происходит в браузере.
Толсто. Разметка тоже рендерится из шаблонов.
Что-что делается с разметкой?
Ре́ндеринг (англ. rendering — «визуализация») — термин в компьютерной графике, обозначающий процесс получения изображения по модели с помощью компьютерной программы.
Вы упорно путаете термины рендеринг и генерация…
Ре́ндеринг (англ. rendering — «визуализация») — термин в компьютерной графике, обозначающий процесс получения изображения по модели с помощью компьютерной программы.
Вы упорно путаете термины рендеринг и генерация…
guides.rubyonrails.org/layouts_and_rendering.html
docs.djangoproject.com/en/dev/ref/templates/api/
www.smarty.net/docsv2/en/caching
Так уж и быть, покормлю тролля :).
docs.djangoproject.com/en/dev/ref/templates/api/
www.smarty.net/docsv2/en/caching
Так уж и быть, покормлю тролля :).
Я использую простой способ.
ээм, простите, что это? и как оно помогает при индексации RICH-сайтов?
А разве в сайты написанные на Ruby нельзя вставить JavaScript?
Принцип же точно такой же остается: вешаем обработчик на ссылки. В зависимости от состояния JS (выключен или включен) запрос будет отправлен AJAX'ом или по старинке
Принцип же точно такой же остается: вешаем обработчик на ссылки. В зависимости от состояния JS (выключен или включен) запрос будет отправлен AJAX'ом или по старинке
Мой пример надо доработать, добавив после 17 строки:
history.pushState({}, '', this.href);ах вы о progressive enhancement.
это совершенно другой случай. у нас кроме одной стартовой страницы, больше никакая разметка не формируется на стороне сервера. все шаблоны и т.п. рендерятся через JS, c сервера приходит только JSON. мы намеренно отказались от progressive enhancement для клиентов, которые не работают с JS, чтобы получить максимум гибкости и не дублировать серверный и клиентский код.
это совершенно другой случай. у нас кроме одной стартовой страницы, больше никакая разметка не формируется на стороне сервера. все шаблоны и т.п. рендерятся через JS, c сервера приходит только JSON. мы намеренно отказались от progressive enhancement для клиентов, которые не работают с JS, чтобы получить максимум гибкости и не дублировать серверный и клиентский код.
UFO just landed and posted this here
UFO just landed and posted this here
и тогда придётся писать сайт не на JS, а и на JS, и на Ruby. это сведёт к нулю всю гибкость разработки RICH-приложений.
UFO just landed and posted this here
буду рад, если вы опишите возможный сценарий. как сейчас это на деле:
если впилить History API, то когда приходит запрос на /some/page, придётся его рендерить на сервере, а если это переход со страницы, то рендерить на клиенте. сейчас же запрос может прийти только вида /!#/some/page, поэтому нам хватает рендеринга _только_на_клиенте_.
поэтому, прошу пояснить про цели и кривые инструменты.
если впилить History API, то когда приходит запрос на /some/page, придётся его рендерить на сервере, а если это переход со страницы, то рендерить на клиенте. сейчас же запрос может прийти только вида /!#/some/page, поэтому нам хватает рендеринга _только_на_клиенте_.
поэтому, прошу пояснить про цели и кривые инструменты.
UFO just landed and posted this here
> то прогоняется на сервере через рендерер
вот она, главная проблема. у нас вообще нет на серверах рендереров. зачем нам делать два рендеринга (клиентский и серверный) для одного и того же? только чтобы у пользователей не было "#!" в строке браузера? сомнительный повод для увеличения объёма работы в более, чем 1.5 раза.
вот она, главная проблема. у нас вообще нет на серверах рендереров. зачем нам делать два рендеринга (клиентский и серверный) для одного и того же? только чтобы у пользователей не было "#!" в строке браузера? сомнительный повод для увеличения объёма работы в более, чем 1.5 раза.
UFO just landed and posted this here
Нет, это не правда. Как минимум потому что шаблоны всегда содержат минимальный код (хотя бы хелперы). А это разные языки на сервере и на клиенте. И это только одна проблема из тысяч. Я подозреваю, что Вы просто никогда не делали рендеринга на клиенте отсюда и недопонимание. А про фреймворк – это вообще просто слова. Вы когда говорите, что что-то можно решить чем-то таким магическим, ссылку в студию. А то слова такие слова.
Отсутствие индексации в Яндексе нас не пугает, так как проекты на западный рынок.
Серьезно, Вы действительно считаете, что все эти люди зря придумали Backbone? И он зря такой популярный? А ведь это именно та парадигма, которую мы используем. Какие все глупые, не используют progressive enhancement! К сожалению, реальность выглядит иначе. А Ваша позиция напоминает мне картинку «JPG JPG JPG! No thinking required!»
Отсутствие индексации в Яндексе нас не пугает, так как проекты на западный рынок.
Серьезно, Вы действительно считаете, что все эти люди зря придумали Backbone? И он зря такой популярный? А ведь это именно та парадигма, которую мы используем. Какие все глупые, не используют progressive enhancement! К сожалению, реальность выглядит иначе. А Ваша позиция напоминает мне картинку «JPG JPG JPG! No thinking required!»
UFO just landed and posted this here
Да при чем тут лучшее решение или нет :). Просто очевидно совершенно, что Вы – теоретик. Потому что год назад я размышлял так же как Вы. Просто посмотрите на свои ссылки. Я просил у Вас решение проблемы рендеринга, а вы мне дали ссылку на свой гитхаб. Спасибо :). По ссылке – какой-то вводный материал для тех, кто вообще не понимает о чем речь. Опять же, потрясающее доказательство ваших слов :).
Давайте по пунктам:
— никто не заставляет пихать хелперы в шаблоны
Вот это ровно то, в чем Вы нас пытаетесь уличить. Вы под кривые задачи подгоняете парадигму. Код и хелперы в шаблонах – это нормально и удобно. Это есть почти всегда. Простейшие шаблонизаторы вроде mustache банально неудобно использовать. Они усложнят разработку на порядок.
— рендерим то на сервере, то на клиенте
Вы создаете себе тьму проблем. И в ответ на их перечисление: «ну есть же фреймворк!» и пункт 1. Очень обоснованные ответы :). И ссылок не даете. Так кто там подгоняет парадигму под кривые цели?
А еще Вы меня школьником назвали :(. Ну ай-ай-ай. А я Вам могу с тем же успехом сказать, что вы консервативны как старик ;). Но давайте на этом остановимся с личностями, ок?
— 8< — А что же мы получаем от нашей парадгимы:
1) Мы не используем рендеринг на сервере вообще. Мы раздаем REST. Единая база кода для всех приложений, в браузере, на десктопе, в мобильных.
2) Благодаря тому, что шаблоны изначально оседают в браузере мы не тратим ни канала, ни серверного времени на рендеринг. И если Вы думаете, что это малое время, то Вы заблуждаетесь. В сложных проектах и сложных представлениях – это ОЧЕНЬ большое время.
3) У нас нет жуткой смеси из Ruby и JS для динамики. Каждый язык выполняет свою цель.
И единственная (я подчеркиваю, единственная!) проблема – это индексация. Мы ее решили. Если кому-то еще нужно, с сообществом поделились. На этом предлагаю вопрос закрыть.
Давайте по пунктам:
— никто не заставляет пихать хелперы в шаблоны
Вот это ровно то, в чем Вы нас пытаетесь уличить. Вы под кривые задачи подгоняете парадигму. Код и хелперы в шаблонах – это нормально и удобно. Это есть почти всегда. Простейшие шаблонизаторы вроде mustache банально неудобно использовать. Они усложнят разработку на порядок.
— рендерим то на сервере, то на клиенте
Вы создаете себе тьму проблем. И в ответ на их перечисление: «ну есть же фреймворк!» и пункт 1. Очень обоснованные ответы :). И ссылок не даете. Так кто там подгоняет парадигму под кривые цели?
А еще Вы меня школьником назвали :(. Ну ай-ай-ай. А я Вам могу с тем же успехом сказать, что вы консервативны как старик ;). Но давайте на этом остановимся с личностями, ок?
— 8< — А что же мы получаем от нашей парадгимы:
1) Мы не используем рендеринг на сервере вообще. Мы раздаем REST. Единая база кода для всех приложений, в браузере, на десктопе, в мобильных.
2) Благодаря тому, что шаблоны изначально оседают в браузере мы не тратим ни канала, ни серверного времени на рендеринг. И если Вы думаете, что это малое время, то Вы заблуждаетесь. В сложных проектах и сложных представлениях – это ОЧЕНЬ большое время.
3) У нас нет жуткой смеси из Ruby и JS для динамики. Каждый язык выполняет свою цель.
И единственная (я подчеркиваю, единственная!) проблема – это индексация. Мы ее решили. Если кому-то еще нужно, с сообществом поделились. На этом предлагаю вопрос закрыть.
UFO just landed and posted this here
Видите, по делу сказать нечего :). Я потратил 5 абзацев текста чтобы объяснить Вам отличия парадигмы, используемой нами, от той, которую описываете Вы. Это _разные_ подходы. Не один кривой, а другой нет. А разные способы разработки. С разными целями и разными инструментами. Я задал Вам _конкретные_ вопросы. И конкретно все прокомментировал про ссылки. Но это, похоже, был бисер.
P.S. Но вот «и что вам каждую ссылку должны разжевывать» – это как-то перебор, чтоли. www.google.com/. Вот Вам ссылка. Идите и учите матчасть. А то буду я вам еще тут ссылки разжевывать %). Вот как это звучит.
P.S. Но вот «и что вам каждую ссылку должны разжевывать» – это как-то перебор, чтоли. www.google.com/. Вот Вам ссылка. Идите и учите матчасть. А то буду я вам еще тут ссылки разжевывать %). Вот как это звучит.
Главное понимать — нужно ли этот контент индексировать. Не вижу смысла делать single-page javascript app доступный для индексации сегодня. Вся суть rich в том, что приложение, а не вэб-сайт. В чем понт индексировать панель управления например?
Люди, делающие подобные поделки, не понимают, что ajax — это всего лишь транспорт информации в другом формате, по другому каналу.
Есть канал html, есть json (грубо говоря, ajax).
Поясняю. То есть, на странице должны быть обычные ссылки и сайт должен работать нормально без js. Но как только js включён, на ссылки вешаются обработчик, который запрашивает данные через ajax-канал и выводит/обновляет информацию в нужном виде в нужном месте (зависит от приложения, от простого body.replaceHtml(newHtml) до сложного обновления только нужных блоков).
Есть канал html, есть json (грубо говоря, ajax).
Поясняю. То есть, на странице должны быть обычные ссылки и сайт должен работать нормально без js. Но как только js включён, на ссылки вешаются обработчик, который запрашивает данные через ajax-канал и выводит/обновляет информацию в нужном виде в нужном месте (зависит от приложения, от простого body.replaceHtml(newHtml) до сложного обновления только нужных блоков).
Яндекс таки научился индексировать сайты с hashbang-адресацией тем же методом, что и Google, да и глупо было бы изобретать свой.
Sign up to leave a comment.
Индексация AJAX-сайтов