Ломаем web c '#!' (hash-bang)

Original author: Mike Davies
  • Translation
Ниже предлагается перевод статьи, обращающей внимание на, на мой взгляд, довольно острую проблему в эпоху web 2.0, а именно чистоту URL-адресов.

На примере сайта Lifehacker.com показано какими проблемами может обернуться слепое следование state-of-the-art технологиям, погоней за SEO и отрицание принципа «прогрессивного улучшения» (progressive enhancement).


На прошлой неделе, в понедельник, сайт Lifehacker.com был недоступен по причине неработающего JavaScript. Lifehacker.com, наряду с остальными сайтами компании Gawker, отображали пустую главную страницу без контента, рекламы и всего остального. Переход с результатов поиска Google на подстраницы переправлял обратно на главную.

Javascript-зависимые URL


Gawker, как и Twitter до него, перестроил свои сайты на полную зависимость от JavaScript'а, включая URLы его страниц. JavaScript не смог загрузиться, что привело к отсутствию контента и сломаным URLам.

Новые адреса страниц выглядят теперь следущим образом: http://lifehacker.com/#!5753509/hello-world-this-is-the-new-lifehacker. До понедельника, адрес был тем же, только без #!..

Идентификаторы фрагментов


# — это специальный символ URL, который сообщает браузеру, что последующая часть адреса представляет собой ссылку на HTML элемент с таким id или именованый якорь (named anchor) текущей страницы. В случае lifehacker.com, текущая страница — это главная страница.

Получается, что до понедельника сайт состоял из миллиона страниц, а теперь это 1 страница с миллионом идентификаторов фрагментов.

Зачем? Я не знаю. Twitter ответил на этот вопрос, когда перешел на такую же технологию, что Google так сможет проиндекировать твиты. Это так, но того же можно было достичь и с предыдущей правильной структурой адреса, с меньшими затратами.

Решение проблемы

Синтакс адреса с #! (hash-bang) впервые вышел на арену web-разработки, когда Google анонсировал способ для веб-разработчика сделать сайт доступным для индексации роботом.

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

Гугл потратил много времени, чтобы решить эту проблему, не преуспел в этом и решил зайти с другого конца. Вместо попыток отыскать этот мифический контент, пусть владельцы сайта сами сообщат о нем. Для этого была разработана спецификация.

Надо отдать должное, что Google аккуратно сакцентировал внимание разработчиков, о том, что они должны делать сайты с «прогрессивным улучшением» (progressive eтhancement) и не полагаться на JavaScript в рамках контента:

If you’re starting from scratch, one good approach is to build your site’s structure and navigation using only HTML. Then, once you have the site’s pages, links, and content in place, you can spice up the appearance and interface with Ajax. Googlebot will be happy looking at the HTML, while users with modern browsers can enjoy your Ajax bonuses.


Т.е. синтаксис адресов с #! был специально разработан для сайтов кладущих с прибором на фундаментальный принцип веб-разработки, и дал таким сайтом глоток жизни, чтобы их контент был обнаружен ботом.

И теперь, этот спасательный круг, похоже, принимается как Единственный Верный Путь веб-разработки инженерами Facebook, Twitter и теперь Lifehacker.com

Чистые URLы

В спецификации Google, #!-адреса называются как «prettyURLs», и они трансформируются ботом в нечто более гротескное.

В прошлое воскресенье, адрес Lifehacker'а выглядил например так: http://lifehacker.com/5753509/hello-world-this-is-the-new-lifehacker.

Хорошо. 7-значный код в середине — единственный непонятный фрагмент, но он требуется CMSкой для однозначного определения статьи. Поэтому, это практически «чистый» адрес.

Сегодня, таже самая статья доступна по адресу: http://lifehacker.com/#!5753509/hello-world-this-is-the-new-lifehacker.Теперь адресс менее «чист», чем предыдущий, так как добавление #! фундаментально меняет структуру адреса:
  • Адрес /5753509/hello-world-this-is-the-new-lifehacker становится просто /
  • Добавлен новый идентификатор фрагмента !5753509/hello-world-this-is-the-new-lifehacker добавляется к адресу.
Достигли мы чего-либо? Нет. Но коверкание адреса на этом не заканчивается.

Спецификация Гугла говорит о том, что адрес будет переделан в адрес с параметрами, т.е. в: http://lifehacker.com/?_escaped_fragment_=5753509/hello-world-this-is-the-new-lifehacker.

Таким образом, именно этот адрес возвращает контент, т.е. этот адрес является каноническим (canonical), т.е. то что будет индексировать бот.

Похоже на: http://example.com/default.asp?page=about_us

Lifehacker.com вместе с Gawker просто забили на 10-летний опыт по чистым адресам и пришли обратно к типичному ASP-сайту (Сколько еще достанется от Frontpage'а?).

В чем проблема?

Основная проблема, что адреса Lifehacker.com не указывают на контент. Каждый URL указывает на главную страницу. Если вам повезло и с JavaScript'ом у вас все хорошо, на главную страницу положится нужный контент.

Более заковыристый по сравнению с обычным адрес, более подверженный ошибкам и более хрупкий подход.

Получается, что запрашивая адрес привязанный к контенту, инициатор запроса контент не получает. Т.е. поломка заложена в конструкции. Lifehacker.com умышленно не дает ботам ходить по ссылкам за интересным контентом. Конечно, если не прыгать через обруч придуманный Гуглом.

Так и зачем нужен этот обруч?

Назначение #!

Так и зачем использовать #!-адреса если этот синтетический адрес, который должен быть еще и переделан в другой, который будет непосредственно отдавать контент?
Из всех причин, самая сильная — «Потому что так круто!». Я сказал самая сильная, а не сильная.

Инженеры будут бурчать что-то про сохранение состояния в Ajax-приложениях. И честно говоря, это идиотская причина для ломания адреса таким способом. Адрес в аттрибуте href все равно может быть нормально сформированной ссылкой на контент. Так как вы все равно используете JavaScript, испортить ее можно позже, в своем обработчике клика по ссылке, добавив в нужное место #!.. Так получится, что поддержание состояния есть, и без ненужного закрытия сайта от ботов и вообще всего не-Javascript'ового.

Запретить всех ботов (кроме Гуглбота)

Все небраузерные агенты (пауки, аггрегаторы, индексирующие сканеры), которые полностью поддерживают как HTTP/1.1 и спецификацию URL (RFC-2396, например) не смогу пройтись по Lifehacker.com, конечно, кроме Гуглбота.

Таким образом надо рассмотреть следующие последствия:
  1. Кэширование больше не работает, так как промежуточные серверы не имеют канонического представления контента и соотвественно не кэшируют ничего. Это приводит к тому, что Lifehacker открывается дольше, Gawker несет бОльшие убытки из-за увеличенного трафика.
  2. HTTP/1.1 и RFC-2396 совместимые краулеры не увидят ничего кроме пустой домашней страницы. Т.е. приложения и сервисы, которые построены на таких краулерах получают соответствующий эффект.
  3. Потенциальное использование микроформатов значительно сокращается, т.е. только браузерные и Гугловые аггрегаторы смогут увидеть микроформатные данные.
  4. Facebook Like виджеты, которые используют идентификаторы страниц потребуют дополнительных действий, чтобы страница была Like'нута (по умолчанию, так как главная страница единственная, на которую указывают прямые URLы, а все «кривые» с #! будут пониматься как ссылка опять же на главную).

Зависимость от идеального JavaScript

Если контент не может быть получен по URL, получается, что сайт сломан. Gawker осознанно пошли на этот шаг с ломанием ссылок. Они оставили доступность своего сайта на откуп всяким JavaScript -ошибкам.
  • Невозможность загрузить JS привела к 5 часовой недоступности всех сервисов Gawker'а в прошлый понедельник (07/02/2011).
  • Отстуствие точки с запятой (;) в конце объекта или массива, объявленного литералом, вызовет ошибку в Internet Explorer'е.
  • Случайно оставленная console.log() опять же вызовет падения у пользователя невооруженного девелоперскими тулами.
  • Рекламные вставки постоянно оказываются с ошибками. Ошибка в рекламном блоке — нету сайта. А опытные веб-разработчики знают, что самый унылый код как раз в рекламных баннерах.
Такая хрупкость без реальной причины и выгода, не перевешивающая все недостатки. Существуют гораздо лучшие методы, чем тот, который применил Lifehacker. Даже HTML5 и его History API были бы лучшим решением.

Кошмар архитектуры

Gawker/Lifehacker нарушили принцип «постепенного улучшения» и поплатились за это сразу же падением их стайта в день запуска. Каждый промах в JavaScript будет приводить к падению и прямо сказываться на доходах Gawker и доверии их аудитории.

Дополнительная литература
  • http://www.tbray.org/ongoing/When/201x/2011/02/09/Hash-Blecch
  • http://blog.benward.me/post/3231388630
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 109

    +7
    Откровенно говоря, я тоже абсолютно не понял слепого следования этих крупных проектов за задумкой гугла.
    Зачем все эти трудности?
    Неужели сложно сделать, очень грубо говоря:
    Some Page
    что приведет к загрузке страницы через аякс при включенном js, либо, в противном случае, к загрузке обычным способом.
      +4
      Перемудрил с кодами :(
      a href=«page1.php» onclick=«getPageThruAjax('page1.php')»>Some Page</a
        +18
        Лучше автоматически навесить обработчик после загрузки страницы.
          +1
          Совершенно точно.
            +2
            согласен, поэтому и написал «очень грубо говоря»
              –1
              Но тогда document.href после перехода станет вида example.com/articles/first-non-ajax-opened-article#!articles/independed-ajaxloaded-article что сводит на нет все пляски с человекопонятными URL.
                0
                Надо javascript'ом первым делом проверку делать, по хешбенг-адресу пришли, или нет. И если нет, то с адреса вида example.com/articles/first-non-ajax-opened-article
                переадресовывать на example.com/#!articles/first-non-ajax-opened-article

                После чего навешивать обработчики на click по ссылкам.

                И все будет ок.
                  +4
                  чего это. при правильной реализации вообще никаких шарпов не надо. Юзер пользуется аяксом, адресуемым по нормальному урлу, паук и браузеры с выключеным яваскриптом просто переходят по классической ссылке.

                    +1
                    Кстати, да — напоминают про history.pushState(), там никаких хешбенгов не надо.
                  +64
                  Вот добрый и конструктивный совет: имея дело с кодами в комментариях (или блогозаписях) на Хабрахабре, заключайте коды между элементами <source> и </source>.

                  Будет вот что:

                  <a href="page1.php" onclick="getPageThruAjax('page1.php')">Some Page</a>

                  Немалую пользу также принесёт употребление кнопки «предпросмотр» перед употреблением кнопки «написать».
                    +3
                    сердечно благодарю :)
                  0
                  Весь вопрос в том, что именно вы получите по указанной ссылке.

                  В классической схеме построения сайтов на вопрос «дайте мне контент с новостью номер 245» нужно будет подгрузить окромя запрашиваемого контента всякие меню, футеры-хедеры, сайдбары и прочую лабудень.

                  В кусочечной схеме на данный вопрос будет выдан только нужный контент без мишуры. Это дает колоссальный выигрыш и по скорости разработки, и по производительности, и по тестированию и всяким другим критериям. Но вот незадача, чистый контент нельзя отдавать посетителям другим способом, кроме того, что описан в статье, т.е. сначала загрузить обертку для контента, а потом уже в нее сам контент.
                    0
                    (Микро)форматы в URL? Для неумеющих JS агентов — /page1 или /page1.html, для умеющих — /page1.xml или /page1.json? Таким образом мы вообще всю html-шаблонизацию перетащим на клиента, нечего ему сервер нагружать :)
                      0
                      Вы не поняли, что должно содержаться в /page1.html?

                      И, шаблонизация на клиенте — не всегда хорошо. Особенно на ИЕ.
                        0
                        В page1.html содержится страница целиком, со всякими хидерами, футерами, сайдбарами для «глупых» агентов, в page1.json содержится основной контент этой страницы для «умных».

                        <a href="page1.php" onclick="getPageThruAjax('page1.php')">Some Page</a>
                        предлагаю заменить на
                        <a href="page1.html" onclick="getPageThruAjax('page1.json')">Some Page</a>


                        Для IE в функции getPageThruAjax() можно сделать исключение и грузить также page1.html :) Или сделать для «глупых» агентов адрес /page1, а для «умных» /page1.html, где грузится только отформатированный контент.
                          0
                          Как ссылаться на контент page1.json? Вернее даже, как получить готовую страницу page1.html вместе с page1.json?
                            0
                            Зачем они вам вместе? Содержимое page1.json отрендерено на сервере в page1.html.

                            Хотя да, в случае json фокус с нормальными адресами не пройдёт. Но тоже, имхо, решаемо — есть заголовок XHR для запроса /page1 — отдаём только контент, нет — отдаём контент с лайаутом, а форматы xml/json оставляем для вспомогательных динамических элементов, автодополнения и т. п.
                              +1
                              Итого, два механизма построения страниц вместо одного. Не кузяво, дорого, нулевой профит
                                –1
                                В последнем случае один, просто по наличию/отсутствию XHR заголовка определяем отсутствие/наличие необходимости рендерить layout.
                                  0
                                  Два, данные в чистом виде и данные вместе с обвязкой.
                                    0
                                    Механизм-то один, например функция render($template, $data, $layout = '');
                                      0
                                      Вы путаете технологию и механизмы сбора данных для отображения.

                                      Технология может быть одна. Но, вернемся к нашей задаче.

                                      Как я уже писал выше, есть два способа построения страницы:
                                      1. На запрос контента генерируется ответ с обвязкой и запрашиваемым контентом
                                      2. На запрос контента генерируется ответ только с данными


                                      Насколько я понял, вы берете первый вариант и переносите рендеринг на сторону или сервера, или клиента, а я говорю про второй вариант, когда сервер выдает контейнер + кусочки. И запрашивая кусочек с интерфейса нужно будет возвращать его, а если это делает бот, то полностью отрендереную страницу.

                                      Предложенный Гуглом вариант позволяет не мудрить с двумя механизмами формирования контента, а оставить один — кусочечный.
                  +41
                  Пару секунд смотрел на заголовок и думал, что за новый язык такой — Web C#…
                    +20
                    Может лучше заголовок изменить на что-то вроде: «Ломаем web c помощью '#'!», видимо не у одного меня такой диссонанс возник.
                      0
                      Да, пожалуй. Заменил.
                        0
                        Спасибо.
                        • UFO just landed and posted this here
                        +18
                        Каждый по-своему видит, я увидел #!/bin/…
                        +4
                        Сначала подумал, что web C# ломают… испугался!

                        Исправьте, пожалуйста, в тексте отрицание принципа «прогрессивного улучения»
                          0
                          Да, исправил. Спасибо.
                          +1
                          -Такая хрупкость без реальной причины или выгоды перевешивает все недостатки.
                          Наверное все же перевешивает все преимущества.
                            0
                            Оп, точно.
                            +8
                            HTML5 history избавит веб от этих проблем.
                            Уже успешно применяется на гитхабе в репозиториях и, прости господи, вконтакте.
                              +3
                              И в гуглокниге про HTML5
                            • UFO just landed and posted this here
                                0
                                Да, именно так оно и происходит.
                                Тем более, потом еще и поддерживать это все просто становится.
                                  0
                                  Вот-вот! Тоже пережил тот период, когда Ext присобачивался везде, где только можно. Время разработки увеличивается раза в 3, результат далеко не всегда супер-кроссбраузерен, а при рендеринге особо заковыристых Ext-элементов, браузер начинает нещадно тормозить, а вместе с ним и вся система :((
                                  Не, ну я не спорю — все получается так миленько, симпотно и всячески web 2.0-но, только оправдано ли это?
                                  … А кстати есть ещё люди, делающие весь интерфейс на Ext.Layout — это вообще жесть неимоверная. Кто-то где-то забывает потереть зпт при создании объекта {x: 1, y: 2,}, и фсеее… весь сайт слетает напрочь!
                                  В последнее время если и использую Ext, то только для создания отдельных объектов, типо гридов, диаграмм и т.п.
                                  • UFO just landed and posted this here
                                      0
                                      Согласен по поводу «Excel в броузере».
                                      Сделать круче хочется всегда — это бесспорно! Но с другой стороны любую фичу можно совершенстовать и отшлифовывать практически до бесконечности :) самое главное не прешанивать за пределы адекватности. Например если людям нужна обычная незайтеливая табличка, то врят ли стоит наворачивать систему гридов :))
                                  +4
                                  рунету пока это не грозит (яндекс же)

                                  создается впечатление что автор текста не совсем понимает для чего используется такая адресация и почему так проще для разработчиков, собссно он сам в этом и признается — «Зачем? Я не знаю.»

                                  ну так и разобрался бы прежде чем писать чушь :)

                                  суть текста «у меня вчера не открылся гокер, ололо», но избыточная серьезность тона изложения делает его… странным

                                  на этой технологии работают все музыкальные сайты, в которых музычка не должна прерываться при переходе по страницам, какую альтернативу для них предложит автор?
                                  • UFO just landed and posted this here
                                      +1
                                      Прямо таки похоже на драму с батхертом: у меня не получилось, потому всем так пользоваться нельзя.

                                      Был блог, а стало небольшое приложение для просмотра этого блога. И свежо и удобно.
                                      • UFO just landed and posted this here
                                          +1
                                          А какая цель была? Может снизить нагрузку на железо и была основная цель?
                                          • UFO just landed and posted this here
                                              0
                                              Нет, не того же вида. Вы хоть раз делали сайты по кусочному методу? Выше я уже писал, как кусочный метод может в десяток раз сократить нагрузку на сервер.
                                            0
                                            Вы ретроград и распространяете унылость. Кирпич который тут перевели радость приносит только от попытки представить как автор его рожал. Огромные далеко идущие выводы из ошибки на одном единственном сайте.

                                            Пачка риторических вопросов: Скажите зачем информационно-развлекательному сайту пользователи без JavaScript? Зачем чтобы его индексировали не основные поисковые системы? Нафига вообще бороться за SEO-URL'ы когда это состоявшийся медиа-проект и люди заходят на него по закладкам и из RSS лент?

                                            Вот вы чуть пониже пишете ересь по поводу кеширования, может лучше потратить чуть побольше времени, выписать преимущества с разных сторон с учетом специфики проекта и тогда картина станет более сбалансированной. Потому что примерять свой негативный опыт к чужому проекту не выглядит убедительно, и уж тем более безапелляционно заявлять «точно не нужно». Я удивлен почему другие издания не экспериментируют в этой же области. Я бы с удовольствием сделал более интересный интерфейс для ленты-ру, если бы кто-то дал такую возможность. lifehacker.com дал пинок под зад тем кто думали что форматы устоялись. Отлично, на них будут равняться в будущем. Рискнули и стали первыми.
                                            • UFO just landed and posted this here
                                                +1
                                                Отбросьте личное и прочтите между строк. Написанное может оказаться правдой.
                                                  0
                                                  Конечно личности, я же не спорю с идеей, а реагирую на конкретную активность конкретного человека. Вы устроили борьбу с технологией и еще начали давать бизнес советы создателям сайта. Для меня это выглядело не убедительно. На ресурс заходят многие люди которые могут сформировать свое мнение, после прочтения ваших комментариев вся эта страница выглядела бы очень однобоко. Я работаю с этими технологиями и мой опыт успешный, почему бы не противопоставить свое слово вашему?
                                                  • UFO just landed and posted this here
                                          +4
                                          фреймы
                                            +2
                                            спасибо. не надо. следующий!)
                                            –8
                                            В погоне за модой потеряна доступность.
                                            Простые абстракции скрыты за ворохом фич.

                                            $ nc lifehacker.com 80
                                            GET / HTTP/1.1

                                            HTTP/1.1 400 Bad Request
                                            Date: Tue, 15 Feb 2011 16:28:46 GMT
                                            Server: Apache

                                            Новые механизмы работают только на очень сложных браузерах. Контент недоступен для пользователей иных операционных систем, браузеров. Ничем не лучше зависимости от ActiveX.

                                            Зачем? Мне это тоже не понятно.
                                              +5
                                              А если так:
                                              $ nc lifehacker.com 80
                                              GET / HTTP/1.1
                                              Host: lifehacker.com
                                              
                                              
                                              =)
                                                –1
                                                В этом случае сервер отдаст кучу мусора — куски javascript, шаблоны.
                                                Но не контент.

                                                HTML, содержащий только контент, можно читать как есть:

                                                $ curl example.com/сепульки
                                                <head>Сепульки — Космическая энциклопедия</head>
                                                <body>
                                                <h1>Сепульки</h1>
                                                Важный элемент цивилизации <a href="/адриты">ардритов</a> с планеты <a href="/энтеропия">Энтеропия</a>
                                                <h2>См. также</h2>
                                                <ul>
                                                <li><a href="/сепулькарии">Сепулькарии</a></li>
                                                </ul>
                                                </body>

                                                Или прогнать через простейший фильтр:

                                                $ function get() { curl $1 | html2md`host $1`; }
                                                $ get example.com/сепульки
                                                Сепульки
                                                ========

                                                Важный элемент цивилизации [ардритов](http://example.com/адриты) с планеты [Энтеропия](http://example.com/энтеропия)

                                                ## См. также

                                                * [Сепулькарии](http://example.com/сепулькарии)

                                                А можно преобразовать в latex и отрендерить в ps/pdf, используя авторский CSS. Или заменить эти (обычно кривые) стили своими. Такое богатство возможностей обеспечено простотой конструкции.

                                                «Современные» браузеры — лишь одна из возможных моделей интерфейса сети. Её сложность понимаешь лишь в попытке реализации. Нет, я говорю не о написании интерфейса к webkit, а о реализации рендера, javascript и DOM.

                                                И эта безумно сложная реализация стремится стать единственно возможной.
                                              • UFO just landed and posted this here
                                              +3
                                              Занимался разработкой сайта работающего так же через ajax-запросы по содержимому #.
                                              Многих проблем можно избежать:

                                              1) Прописывать адреса ссылок как обычно, а уже на js отлавливать клик и менять текужещий #.
                                              2) Из первого пункта вытекает нормальное индексирование и чтение всех микроформатов
                                              3) Про кеширование не очень понял, но я не заметил проблем.
                                              4) Для соц-виджетов просто передаю обычный url

                                              Конечно есть подводные камни, но почти их все можно обойти, а на сложных сервисах можно ограничится частичным внедрением подобной технологии.
                                                +1
                                                3) традиционные статичные страницы легко кешировать на люых уровнях, механизмы эти давно отлажены и работают. Такие дела.
                                                  0
                                                  А как данную проблему решает Facebook и Twitter?
                                                    0
                                                    У них инфраструктура другого масштаба, таких проектов хорошо если с несколько десятков по миру наберется. Немного читал о кеширующих серверах Google и смею предположить, что Facebook тоже может себе позволить аналогичное специализированное решение.

                                                    Я вот не могу :)
                                                      0
                                                      Поделитесь, пожалуйста, ссылкой на статейку про кеши гугла.
                                                        0
                                                        Это было с полгода назад, статья только в очень общих словах обрисовывала, как все работает. Линка, если коротко, дать не могу
                                                  0
                                                  Да, конечно, решения есть. Но это как будто вы сами ставите себе проблемы, а потом их решаете. Иногда в этом есть своя идея (мало времени, а надо чтобы было сделано), но зачастую все равно стоит держать в голове и придерживаться паттерна web-программирования, что сайт должен выдавать суть своего существования, — контент, без JavaScript'а. И проще это делать в прямом порядке — сначала контент, потом рюшечки и красивости.
                                                    0
                                                    сайт должен выдавать суть своего существования, — контент, без JavaScript'а. И проще это делать в прямом порядке — сначала контент, потом рюшечки и красивости.


                                                    Согласен, так и делал.
                                                  0
                                                  Хорошая статья. Спасибо
                                                    +10
                                                    Я эту статью еще в оригинале не понял. Какая-то слюнявая истерика.

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

                                                    Ну накосячили что-то там, прилегли на несколько часов — с кем не бывает.

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

                                                    А баннеры с хреновым джаваскриптом просто не надо ставить. Ну или тестить на staging перед тем, как в продакшен выкатывать.
                                                      0
                                                      * всегда можно будет
                                                        –5
                                                        Что тут непонятно? Был нормальный сайт, а стало говно. Речь не о технологии в сферическом вакууме, а о том как ее применили в конкретном случае. При переходе по ссылкам глючит каждый второй раз.
                                                        +1
                                                        С этими hash сайтами теперь много фейлов вылезает
                                                        Например у меня при открытии ссылки на gizmodo.com из rss перекидывает на gizmodo.de где конечно же вместо статьи я вижу заглавную страницу т.к. контент в зонах отличается.
                                                          0
                                                          С мобильной версией аналогично.
                                                          –1
                                                          > If you’re starting from scratch, one good approach is to build your site’s structure and navigation using only HTML. Then, once you have the site’s pages, links, and content in place, you can spice up the appearance and interface with Ajax.

                                                          Народ, веб-хакеры и, вот, Google, всё твердят, а говносайты вроде Twitter, aeroflot.ru или habrahabr.ru/blogs/internet/110918/ всё плодятся.
                                                            +2
                                                            Хотел опубликовать ссылку на пост в твиттере нажав на кнопку в конце поста:

                                                            image
                                                            но твиттер ответил:

                                                            Sorry, that page doesn’t exist!

                                                            А все из-за #! в заголовке статьи.
                                                              +2
                                                              Ну так это уже баг хабра, который не энкодит URI для передачи его в ссылке в твиттер.
                                                              +1
                                                              А ведь всё так мило начиналось. Браузеры не позволяют поменять урл страницы без её перезагрузки — авторы сайтов придумали ход конём, переносить значимые параметры в якорь — пользователи начинают копировать ссылку из адресной строки (для того, в частности, и мудрили) — авторы сайтов делают эту адресацию основной — сайты не индексируются поисковиками — гугл придумывает костыль — клиенты без JavaScript обламываются.
                                                                0
                                                                Клиенты без javascript вообще уже давно много где обламываются.
                                                                  0
                                                                  Сейчас уже позволяют, как я уже писал выше, через HTML5 history. Правда, в пределах текущего домена.
                                                                  +2
                                                                  # — это специальный символ URL, который сообщает браузеру, что последующая часть адреса представляет собой ссылку на HTML элемент с таким id или именованый якорь (named anchor) текущей страницы.

                                                                  Это очень частный случай. По большому счету, часть url, именуемая fragment, указывает на фрагмент данных. Содержательный смысл этого термина, трактуется клиентом по собственному усмотрению. Например это может быть начальной позицией для отображения видеопотока, состоянием приложения, css-селектором для фрагмента html и т.п.
                                                                    0
                                                                    Согласен, но так было в оригинале.

                                                                    Но суть от этого не меняется, потому что все, что после # — это мета информация, относящаяся к контенту или ресурсу, загруженному по URL до #. Ну а идея в том, что эта мета-информация получается уже не мета, а прямо как обязательный параметр запроса.
                                                                      0
                                                                      Всё верно: трактовка адресов зависит от конкретного приложения — если фрагмент считается обязательным, значит так надо. Тут нет противоречий.

                                                                      Можно провести аналогию с привычными адресами: для таксиста важно знать название улицы и номер дома, куда подать машину; для почтальона обязательным будет так же номер квартиры (ведь он не может оставить вашу телеграмму просто где-то возле дома).
                                                                        0
                                                                        По-моему, различных трактовок тут нет, так как есть спецификация URL, которая говорит, что все что после # — fragment identifier:

                                                                        ...additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed


                                                                        Т.е. фрагмент не может считаться обязательным (фрагмент URL, я так понимаю ваш поинт).
                                                                          +1
                                                                          Я понимаю вашу точку зрения. Думаю, корни заморочки нужно искать в том, что собой представляет архитектура клиент-сервер. Данная модель описывает *приложения*, которые состоят из нескольких взаимодействующих *программ*.

                                                                          Модель назначает программам разные роли. Это дает опредленные бонусы разработчикам. Но с точки зрения конечного результата все это нужно воспринимать как составные части единого приложения. Т.е. сервер, браузер, прокси, джаваскипты, флеш-плееры и проч. это все программы, которые являются составными частями того приложения, результат работы которого вы можете наблюдать у себя на экране. Или не наблюдать, если какая-то программа падает. URL как таковые, тут совершенно не причем — они ни как не влияют на «живучесть» приложения в результате сбоев потому, что это всего лишь адреса. :)
                                                                            0
                                                                            Совершенно согласен!

                                                                            Я бы еще такую аналогию привел:

                                                                            «Раньше» мы скачивали программы и устанавливали их на компьютере. Они могли воздействовать с ОС напрямую, а могли через виртуальную машину.

                                                                            «Сейчас» мы буквально скачиваем приложения по URL-адресу и они сразу же исполняются (о чудо: без установки!) в своей собственной «виртуальной машине» — браузере.

                                                                            Конечно, почтовые клиенты — самый яркий пример.
                                                                              0
                                                                              А вот я вашу уже не понимаю. Куда-то вы в другое ухеали :).
                                                                      +2
                                                                      Какая-то странная статья ;-)

                                                                      > The main problem is that LifeHacker URLs now don’t map to actual content.

                                                                      Вообще-то, адрес ссылается на реальный контент только в том случае, когда адрес ссылается на реальную html-страницу.

                                                                      Но в большинстве случаев страница генерируется на сервере. И, опять же, в большинстве случаев, URL преобразуется.

                                                                      Сайт ровно с тем же успехом упадет, если забыть поставить ";" в серверном коде, как и если забыть поставить ";" в клиентском.
                                                                        0
                                                                        Вообще-то, адрес ссылается на реальный контент только в том случае, когда адрес ссылается на реальную html-страницу.

                                                                        Но в большинстве случаев страница генерируется на сервере.


                                                                        Не совсем так. URL — Uniform Resource Locator. В данном случае ресурса по ссылке нету, потому что отдается пустая страница, а дальше JS'ом уже достается сам контент.

                                                                        Более того, это на 1 запрос реально делается к серверу 2, как раз чтобы получить контент.
                                                                          +1
                                                                          А в чем разница для пользователя? Если он видит страницу, ему все равно, сгенерирована она на сервере или на клиенте. Если не видит, ему все равно, ошибка в JS или ошибка на сервере.

                                                                          Запросов обычно не 1 и не 2. Главная страница Хабра, например, только что обратилась к серверу 75 раз (за картинками, джаваскриптами и ЦСС-ами).

                                                                            0
                                                                            Разница для пользователя очень большая, особенно если этот пользователь какой-нибудь бот, у которого нет javascript'а, клиент с мобильника, где с JS тоже не все очевидно и трафик дороговат и тормозит.

                                                                            Главная страница хабра не обратилась 75 раз, она обратилась столько только когда вы первый раз зашли на сайт, дальше вступает кэширование браузерное и т.п. и количество запросов сокращается. Но это необходимые действия. Когда у вас посещаемость выше 10К в день, не стоит увеличивать это количество еще 10К, так как это не пользователи, но трафик и ресурсы кушают.
                                                                              +2
                                                                              Давайте не мешать все в кучу ;-)

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

                                                                              Во-вторых, не будем делать один сайт на все случаи жизни. Не все сайты должны жить в ИЕ6. Не все сайты должны жить в мобильнике (и, если должны, то не в каждом мобильнике).

                                                                              Конечно, если есть необходимость сделать сайт доступным для пользователя с отключенным JS (вдруг, и правда есть такая необходимость), его надо делать таким. С полной генерацией на сервере. Или, если нужен сайт на мобильном, можно сделать отдельную версию.

                                                                              Но тут почему-то подвергается критике концепция, применимая для 90% сайтов. Концепция, которая ускоряет разработку и облегчает внесение изменений в продукт.
                                                                                0
                                                                                Ну что значит «не мешать все в кучу»? Не путать пользователей, ботов, один сайт на все случаи жизни и т.п. — это все забавные отговорки.

                                                                                Если вы зашли правильным клиентом, который работает согласно общепринятым нормам, отраженным в спецификации, то как-то странно получить валяющийся в корчах сайт. Логично?

                                                                                Плюс к тому, заявлять что этот сайт работает только с включенным JS, это как еще пять лет назад говорить про то, что «сайт оптимизирован под разрешение 1024х768 и предназначен для Internet Explorer» или выкатывать полностью Flash сайт — выглядит дилетанством и доставляет кучу геммороя пользователю.

                                                                                Этим самым вы пытаетесь переложить ответственность с себя, как с схалтурившего разработчика, на пользователя. У нас еще любят так про дороги говорить — «ну дорога не была рассчитана на такой грузопоток и такие сильные морозы» или «не нравится, вон там другой %whatever% есть».

                                                                                Если вы не делаете сайт для себя и своих друзей, то стоит потрудиться сделать его нормально. Тем более, что поверьте, навешивать динамичность и классность, не так сложно при нормальной архитектуре, а следование «progressive enhancement» принципу — как-то уже делает архитектуру в правильном направлении, по крайней мере на клиенте будет все ОК.
                                                                                  +2
                                                                                  Мне кажется, вы упускаете из виду стоимость и время разработки. (И, вместе с тем, сложность и гибкость системы.)

                                                                                  Progressive enhancement, graceful degradation, IE6, IE5, IE4, print version, handheld version, iPhone version, Android version, IE Mobile version, WAP version, high bandwidth version, low bandwidth version…

                                                                                  Изменение требований к сайту может изменить стоимость и время разработки в 10 раз. И, вместе с тем, будет больше кода, который сложнее поддерживать. Каждое последующее изменение сайта будет стоить дороже (в деньгах и в часах).

                                                                                  Самый простой случай progressive enhancement умножает количество кода в два раза: один генерируется на сервере, другой на клиенте.

                                                                                  И, даже если у клиента есть деньги и время, у него все равно есть проблемы: разработчики занимаются вещами, которые нужны 2% пользователей, вместо вещей, которые нужны 98% пользователей.

                                                                                  Очень часто лучше сказать НЕТ и сконцентрироваться на важном. Деньги, время и ресурсы всегда ограничены, их нужно тратить на важные вещи.

                                                                                  P. S. Опять же, повторюсь, если действительно есть необходимость делать сайт без JS — значит, надо делать. Но, если этой необходимости нет, не надо ее выдумывать — это слишком дорого стоит.
                                                                              +1
                                                                              Разница в том что если JS заглючит, то фигу пользователь увидит, а не страницу. И получится вот так например (весь день сегодня такое):

                                                                                +2
                                                                                А что увидит пользователь, если заглючит Java, Python или Ruby? :-)
                                                                                  0
                                                                                  А если интернет упадет, то вообще ничего не будет. Того что добавляется лишняя критическая система это не меняет.
                                                                                    0
                                                                                    Мы просто переносим эту критическую систему с сервера на клиент. А на клиенте построить DOM проще, чем на сервере.

                                                                                    И, таким образом, мы получаем более быстрый способ для создания более надежного сайта. (Если JS включен и интернет работает.)
                                                                                      +1
                                                                                      Возможно я что-то не понимаю, но каким образом «на клиенте», где куча разных браузеров, ОС и прочих параметров что-то может работать надежнее чем «на сервере», где все под контролем?
                                                                                        0
                                                                                        JavaScript 1.5 работает, по сути, во всех браузерах. Но я не это имел в виду.

                                                                                        Например, сколько кода (и какого) нужно написать на сервере, чтобы сгенерировать список чекбоксов и отметить определенные из них? Циклы, проверки, шаблоны…

                                                                                        А на клиенте это две строки кода: первой строкой получим список чекбоксов, второй поставим галочки в нужных из них.

                                                                                        Конечно, я имею в виду «классическое» серверное программирование, где html-страница — это скорее string, чем DOM.

                                                                                        И, в любом случае, если планируется «навешивать» (слово-то какое!) JavaScript, то, получится, что код, первично генерирующий страницу, надо поддерживать и на сервере, и на клиенте. А это очень плохой сценарий. (Почти такой же, как одновременно поддерживать всю серверную часть на PHP и на Ruby :-)
                                                                                          +1
                                                                                          Это разные ситуации. В случае интерактивных страниц вопросов нет, ajax рулит. Но в случае когда это новостной сайт с одной статьей на страницу, я вообще не вижу преимуществ. Вся выгода от меньшего количества трафика при переходах между статьями убивается лагами и глюками.
                                                                          +1
                                                                          довольно острую проблему в эпоху web 2.0, а именно чистоту URL-адресов.

                                                                          Это нифига не проблема — «чистота» адресов и её полезность весьма субъективна. URI это идентификатор. Ну давайте ещё поборемся за чистоту айдишников).
                                                                          Вот меняться они, по хорошему, не должны — здесь я согласен с авторской критикой.
                                                                            0
                                                                            Чистота URLа, в моем понимании, это не только как он красиво выглядит, но и то, что он соответствует спецификации. Поразвернутее тут: habrahabr.ru/blogs/webdev/113842/#comment_3664853
                                                                              +3
                                                                              Вся спецификация вот тут rfc2396. Синаксис URI, в самом общем случае, имеет вид:
                                                                              <scheme>:<scheme-specific-part>
                                                                              

                                                                              Вот и весь обязательный синтаксис. Если посмотреть дальше, то окажется что и scheme не обязательна, т.к. существуют Relative URI. В остатке, по большому счету, важен только алфавит, а все остальные нюансы записи адресов — что считать обязательным, а что нет — это частное дело приложений.
                                                                            0
                                                                            GitHub — молодцы, у них файлобраузер в репозиториях работает на AJAX, но URL меняет на нормальный, без «#!» (через новый API в браузерах, да). Что мешает остальным такое сделать?
                                                                              0
                                                                              А что за новый API? Я как-то раньше считал, что это невозможно без поощрения фишеров.
                                                                              0
                                                                              Скорее всего, немного другая аудитория, которая может и не сидеть на последних версиях определенных браузеров.
                                                                              0
                                                                              > сайт Lifehacker.com был недоступен по причине неработающего JavaScript

                                                                              Идиотизм на грани фантастики. Когда делаешь сайт — делай так чтобы весь контент с максимально возможными красивостями можно было получить только из выдачи веб-сервера, только потом накладываются рюшечки в виде CSS и уж в последнюю очередь, для совсем уж удобства и красоты — JS. У людей может быть отключен JS, не подгрузиться CSS и так далее, так что надо дать максимум возможностей при первой генерации страницы.
                                                                                +2
                                                                                Перепись уеб-староверов которые считают, что #! что-то принципиально меняет.
                                                                                  +3
                                                                                  Бредятина какая то…

                                                                                  Так и не понял что авторы статьи предлагают. Не использовать AJAX для загрузки непосредственно контента? Ну-ну… А как сайтам с аудиоплеерами быть например?

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

                                                                                    Only users with full accounts can post comments. Log in, please.