Comments 49
Аллилуйя! Лучше и придумать почти нельзя, а где можно, там патчи пришлют.
Спасибо, я постарался учесть все по максимому, но с удовольствием выслушаю любые предложения/улучшения.
Нет, дело не в велосипеде, дело тут в очень простом. Суть данной библиотеки максимально снизить написание лишнего кода. А в будущем ее легко извлечь из проекта, при этом не затрагивая основной код сайта. Например если я буду писать с использованием библиотеки от balupton, и захочу отказаться от старых браузеров, то мне нужно будет переписать основной код сайта что бы вырезать эту библиотеку.

Еще один недостаток библиотеки представленной вами это громоздкость, весит она в разы больше, а с учетом того что сейчас довольно сильно развивается мобильный интернет, это не особо хорошо для них. Конечно это не огромный аргумент, но все же. Ну и конечно же что бы пользоваться библиотекой от balupton, ее нужно изучить, точнее прочитать документацию по ней. Плюс ко всему та библиотека не работает полноценно с браузером ИЕ7, хотя это тоже не аргумент, но все же маленький но аргумент.
History.js от balopton'а использую уже давно. Единственные косяки связаны с urlencode/decode (неверно работает со всякими японскими, китайскими и т.п. языками + избыточно работает с некоторыми системными символами). Чтобы выключить поддержку HTML4-браузеров ничего особенного делать не придется, если вы изначально пишите с умом. Достаточно будет просто загрузить History.js только с поддержкой HTML5.
Я и не заставляю отказаться от привычных инструментов, конечно же каждый выбирает то что ему по душе, тем и пользуется. Но зачем загружать «History.js только с поддержкой HTML5»? Вот этого я не могу понять, да конечно она будет поправлять косяки браузеров, а если их не сегодня а завтра поправят в браузерах? Конечно я утрирую и дождаться от разработчиков браузеров тяжело чего либо, но все же.

Суть в том что в моем случае я просто отключу библиотеку и сайт не упадет а продолжит работать как работал. Единственное что нужно будет сделать это заранее об этом подумать и прописывать где нужно примерно такой код:
// .........
if ( history.pushState ) {
    // .........
    var locationObject = history.location || window.location;
    // .........
}
// .........

Тем самым отключение моей библиотеки не нарушит работоспособность сайта в HTML5 браузерах, а в браузерах HTML4 просто будет обычный переход по ссылкам. Хотя конечно дело выбора и желаний.
Ну да. В случае с Балуптоноским методом, простое отключение библиотеки не поможет, так как у него используется объект History, а не history. Но, как и в вашем случае, можно будет сделать довольно быстро работоспособным код этот :)
Да и не понимаю я, зачем нужно использовать history.location. Если есть pushState.
Да и не понимаю я, зачем нужно использовать history.location. Если есть pushState.
Объект history.location содержит ссылку информирующую нас о том куда мы вернулись по истории, не зависимо от присутствия объекта state. То есть в в браузерах HTML5 для этих целей служит обычный window.location и/или document.location. Это я считаю один из важных параметров в отличии от объекта state, который на мой взгляд ввели избыточно.
Такое ощущение что есть специальные задроты которые только и ждут чтобы указать на «велосипеды». Если мир состоял только вами то вы никуда дальше от развития одноклеточных амеоб не дошли бы.
Я лично сам прошел долгий путь от велосипедирования и пришел к выводу что писать что-то свое целесообразно лишь когда:

1) похожего инструментария вообще нету
2) есть что-то похожее, но оно совсем не нравится

Задротства тут никакого не вижу, главное чтобы цели оправдывали средства.
Нету никаких граней, это же и коню понятно. Сами определяете границы. Некоторые пишут велосипеды «джаст фор фан» или ради практики в программировании.

Ничего не имею против велосипедов.
Я в таких случаях форкаю, и делаю так, чтобы «нравилось».

Осязание грани «велосипеда» и «инновации» считаю талантом. Нужно уметь вовремя остановиться.
Спасибо, я посмотрю на досуге на эту библиотеку, но сомневаюсь что в ней увижу что-то новое. Хотя моя цель была сделать библиотеку без добавления всяких лишних методов, которые нужно изучать.
Да, тут разные цели. Pages.js не имеет поддержи для старых браузеров, просто framework для упрощения разработки :).
Да вы правы, но при использовании моей библиотеки совместно с библиотекой Pages.js боюсь приведет к плачевному результату лишь по одной причине того что у меня реализован history.location который не будет учитывать Pages.js. Хотя конечно же можно попросить разработчиков той библиотеки добавить поддержку.
Тут вообще глобальный вопрос, должны ли мы поддерживать старые браузеры. History pushState разработан так, что сайт будет работать и без поддержки pushState, просто не так круто. А если у пользователей старых браузеров сайт один-в-один с современными браузерами, то какой смысл обновлять браузер ;).
Да, риторический вопрос, но с заказчиками не поспоришь. Если требуют, то либо делаем либо теряем заказчика, уж таковы реалии и с этим не поспоришь.
Ну для заказчика главное бизнес, чтобы деньги приносил, а не какие технологии используются :). Не думаю, что пользователи особо пострадают, если страница будет грузиться старым способом.

Тем более, обычно новые технологии отсутствуют на старых медленных браузерах и старых компьютерах. Так что при попытке заставить их показывать «как все», сайт будет просто больше тормозить.
Про тормоза, например, утечка памяти из-за особенностей сборщика мусора у старых IE — при обычной загрузке память будет очищаться при переходе между страницами.
Я посмотрел внимательнее на ваш плагин для jQuery, и вы можете добавить поддержку моей библиотеки изменив всего три строки кода в своем плагине.
Это строки 151, 152
        if ( Pages._lastUrl != location.href ) {
          Pages.open(location.pathname);
        }

заменить на:
        if ( Pages._lastUrl != ( history.location || location ).href ) {
          Pages.open( ( history.location || location ).pathname );
        }

И строку 448
    Pages._lastUrl = location.href;

заменить на:
    Pages._lastUrl = ( history.location || location ).href;

И у вас появиться поддержка моей библиотеки, как видите ничего сложного и трудоемкого производить не нужно.
Верно подметили, я с вами совершенно согласен. Но люди разные, кто-то имеет иной взгляд на это все.
А это нормально что при несколькоих кликах на 1 и ту же ссылку в историю попадают одинаковые сущности?
Да это совершенно нормально, поэтому это нужно отслеживать самостоятельно. Но это не глюк библиотеки, так как все браузеры HTML5 делают именно так и в спецификации противоречий этому я не нашел.
Я правильно понимаю, что нужно просто подключить эту либу и мое приложение, к примеру на backbone c pushState роутером, будет работать во всех браузерах без fallback-а на хеши?
нет, fallback-а на хеши конечно же будет присутствовать в браузерах HTML4 но для этого не нужно делать лишних телодвижений и писать лишний код. Суть в том если backbone использует при работе History объект window.location то скорее всего эта библиотека не совсем будет выполнять требования backbone.

К сожалению браузеры HTML4 не позволяют перезагрузить объект window.location и/или document.location, поэтому пришлось добавить дополнительный объект history.location, который и нужно добавить в тот код который тесно связан с объектом window.location при работе с HTML5 History API. В ином случае вполне возможно что библиотека будет корректно работать, но я не тестировал ее совместно с библиотеками которые осуществляют работу с историей.
Этого не нужно, потому как ссылки в тегах имеют обычный вид, то есть никакого хеша в ссылках, обычные всеми привычные ссылки. В примере указанной в статье это хорошо видно, и робот зашедший на страницу, спокойно может перейти по нужно ссылке.
Ну я бы правда не забывал про ссылки из HTML4 браузеров, которые используют якорь (знак # (hash)). Ведь пользователи старых браузеров тоже могут распространять ссылки с якорями по интернету. Для таких ссылок в вашей библиотеке можно использовать параметр «type=!», если не лень специально для старых браузеров делать поддержку hashbang (#!) на стороне бэкэнда. Я же верно размышляю?

Кстати, меня, если честно, слегка смутило, то что вы не используете git теги для версий библиотеки, а вместо этого создали директорию «old». С тегами было бы проще и вам и пользователям библиотеки.
Я же верно размышляю?

Да все верно

Кстати, меня, если честно, слегка смутило, то что вы не используете git теги для версий библиотеки, а вместо этого создали директорию «old». С тегами было бы проще и вам и пользователям библиотеки.

Ну я затруднений пока не вижу в этом, на сегодняшний день, версии меняются редко, так как библиотека во всем корректно работает. Ну или просто никто не присылает баг-репорты.
Кстати, кто знает, есть ли разница между window.onpopstate и window.addEventListener('popstate'...?
разницы нет никакой, разница лишь в том что при использовании addEventListener вы можете не ограничивать себя и назначать на тоже событие новые и новые перехватчики. Суть в том что событие popstate нельзя отменить и перехватить на стадии погружения. Поэтому разница тут не велика.
Вы делали просто обертку для удобства работы с HTML5 History API, моя же библиотека это не обертка, а расширение для HTML4 браузеров, что бы ваша обертка могла работать и в старых браузерах тоже.
Подскажите, что-то нигде не нашел информации о лицензии — под какой лицензией опубликована эта библиотека?
Да, уже нашел:

 * Dual licensed under the MIT and GPL licenses:
 *   http://www.opensource.org/licenses/mit-license.php
 *   http://www.gnu.org/licenses/gpl.html


Вы бы куда-нибудь это на видное место добавили — и в README, и сюда, и в какой-нибудь файл типа LICENSE в корень репозитария…
Да я тоже очень долго решал как применить то что вы привели по ссылке, хотя по приведенной вами ссылке это сырой способ, просто человек писавший метод objectStatic не полностью осведомлен о реалиях VB, от того его способ имеет кучу ошибок и ограничений, поэтому помимо этого мне пришлось перелопатить еще и MSDN что бы получить более полную картину по скрипту VB
Кстати насчет статьи про getters/setters я их еще применил в этом проекте https://github.com/devote/jsClasses#readme я как то о нем писал на хабре. Если вам интересно конечно их применение не только в библиотеке history.
Кстати как бы вы поступали с адресами страниц, при которых HTML-содержимое страниц на самом деле не меняется, а изменения применяются только для мультимедиа элементов на самой странице, т.е. адреса на контент которым управляют скрипты. Примеры: адреса слайдов в swf-презентации, адреса определённого видео-фрагмента. Я бы для таких адресов использовал именно якоря (hash), т. к. нужно учитывать, что HTML будет один, и дубликаты однотипного ресурса для поисковиков не хотелось бы создавать.

Ваша библиотека нормально будет работать при совместном использовании адресов без якорей и с ними в HTML5 и HTML4 браузерах?
Ваша библиотека нормально будет работать при совместном использовании адресов без якорей и с ними в HTML5 и HTML4 браузерах?

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

url: this.getAttribute( «href», 2 ) // двоечка нужна для ИЕ6-7

а можете объяснить, почему? нигде в документации не нашел второго аргумента. или это опечатка?
О втором параметре написано тут msdn.microsoft.com/en-us/library/ie/ms536429%28v=vs.85%29.aspx
Но так же вы можете почитать на форумах о проблеме получения ссылки у элемента HTMLAnchor средствами getAttribute, в ИЕ6-7 он возвращает абсолютную ссылку, вместо того что реально написано в атрибуте.
Only those users with full accounts are able to leave comments. Log in, please.