Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 109
Откровенно говоря, я тоже абсолютно не понял слепого следования этих крупных проектов за задумкой гугла.
Зачем все эти трудности?
Неужели сложно сделать, очень грубо говоря:
что приведет к загрузке страницы через аякс при включенном js, либо, в противном случае, к загрузке обычным способом.
Зачем все эти трудности?
Неужели сложно сделать, очень грубо говоря:
Some Pageчто приведет к загрузке страницы через аякс при включенном js, либо, в противном случае, к загрузке обычным способом.
Перемудрил с кодами :(
a href=«page1.php» onclick=«getPageThruAjax('page1.php')»>Some Page</a
a href=«page1.php» onclick=«getPageThruAjax('page1.php')»>Some Page</a
Лучше автоматически навесить обработчик после загрузки страницы.
Совершенно точно.
согласен, поэтому и написал «очень грубо говоря»
Но тогда document.href после перехода станет вида example.com/articles/first-non-ajax-opened-article#!articles/independed-ajaxloaded-article что сводит на нет все пляски с человекопонятными URL.
Надо javascript'ом первым делом проверку делать, по хешбенг-адресу пришли, или нет. И если нет, то с адреса вида example.com/articles/first-non-ajax-opened-article
переадресовывать на example.com/#!articles/first-non-ajax-opened-article
После чего навешивать обработчики на click по ссылкам.
И все будет ок.
переадресовывать на example.com/#!articles/first-non-ajax-opened-article
После чего навешивать обработчики на click по ссылкам.
И все будет ок.
чего это. при правильной реализации вообще никаких шарпов не надо. Юзер пользуется аяксом, адресуемым по нормальному урлу, паук и браузеры с выключеным яваскриптом просто переходят по классической ссылке.
Кстати, да — напоминают про history.pushState(), там никаких хешбенгов не надо.
Вот добрый и конструктивный совет: имея дело с кодами в комментариях (или блогозаписях) на Хабрахабре, заключайте коды между элементами <source> и </source>.
Будет вот что:
Немалую пользу также принесёт употребление кнопки «предпросмотр» перед употреблениемкнопки «написать».
Будет вот что:
<a href="page1.php" onclick="getPageThruAjax('page1.php')">Some Page</a>Немалую пользу также принесёт употребление кнопки «предпросмотр» перед употреблением
Весь вопрос в том, что именно вы получите по указанной ссылке.
В классической схеме построения сайтов на вопрос «дайте мне контент с новостью номер 245» нужно будет подгрузить окромя запрашиваемого контента всякие меню, футеры-хедеры, сайдбары и прочую лабудень.
В кусочечной схеме на данный вопрос будет выдан только нужный контент без мишуры. Это дает колоссальный выигрыш и по скорости разработки, и по производительности, и по тестированию и всяким другим критериям. Но вот незадача, чистый контент нельзя отдавать посетителям другим способом, кроме того, что описан в статье, т.е. сначала загрузить обертку для контента, а потом уже в нее сам контент.
В классической схеме построения сайтов на вопрос «дайте мне контент с новостью номер 245» нужно будет подгрузить окромя запрашиваемого контента всякие меню, футеры-хедеры, сайдбары и прочую лабудень.
В кусочечной схеме на данный вопрос будет выдан только нужный контент без мишуры. Это дает колоссальный выигрыш и по скорости разработки, и по производительности, и по тестированию и всяким другим критериям. Но вот незадача, чистый контент нельзя отдавать посетителям другим способом, кроме того, что описан в статье, т.е. сначала загрузить обертку для контента, а потом уже в нее сам контент.
(Микро)форматы в URL? Для неумеющих JS агентов — /page1 или /page1.html, для умеющих — /page1.xml или /page1.json? Таким образом мы вообще всю html-шаблонизацию перетащим на клиента, нечего ему сервер нагружать :)
Вы не поняли, что должно содержаться в /page1.html?
И, шаблонизация на клиенте — не всегда хорошо. Особенно на ИЕ.
И, шаблонизация на клиенте — не всегда хорошо. Особенно на ИЕ.
В page1.html содержится страница целиком, со всякими хидерами, футерами, сайдбарами для «глупых» агентов, в page1.json содержится основной контент этой страницы для «умных».
Для IE в функции getPageThruAjax() можно сделать исключение и грузить также page1.html :) Или сделать для «глупых» агентов адрес /page1, а для «умных» /page1.html, где грузится только отформатированный контент.
<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, где грузится только отформатированный контент.
Как ссылаться на контент page1.json? Вернее даже, как получить готовую страницу page1.html вместе с page1.json?
Зачем они вам вместе? Содержимое page1.json отрендерено на сервере в page1.html.
Хотя да, в случае json фокус с нормальными адресами не пройдёт. Но тоже, имхо, решаемо — есть заголовок XHR для запроса /page1 — отдаём только контент, нет — отдаём контент с лайаутом, а форматы xml/json оставляем для вспомогательных динамических элементов, автодополнения и т. п.
Хотя да, в случае json фокус с нормальными адресами не пройдёт. Но тоже, имхо, решаемо — есть заголовок XHR для запроса /page1 — отдаём только контент, нет — отдаём контент с лайаутом, а форматы xml/json оставляем для вспомогательных динамических элементов, автодополнения и т. п.
Итого, два механизма построения страниц вместо одного. Не кузяво, дорого, нулевой профит
В последнем случае один, просто по наличию/отсутствию XHR заголовка определяем отсутствие/наличие необходимости рендерить layout.
Два, данные в чистом виде и данные вместе с обвязкой.
Механизм-то один, например функция render($template, $data, $layout = '');
Вы путаете технологию и механизмы сбора данных для отображения.
Технология может быть одна. Но, вернемся к нашей задаче.
Как я уже писал выше, есть два способа построения страницы:
Насколько я понял, вы берете первый вариант и переносите рендеринг на сторону или сервера, или клиента, а я говорю про второй вариант, когда сервер выдает контейнер + кусочки. И запрашивая кусочек с интерфейса нужно будет возвращать его, а если это делает бот, то полностью отрендереную страницу.
Предложенный Гуглом вариант позволяет не мудрить с двумя механизмами формирования контента, а оставить один — кусочечный.
Технология может быть одна. Но, вернемся к нашей задаче.
Как я уже писал выше, есть два способа построения страницы:
- На запрос контента генерируется ответ с обвязкой и запрашиваемым контентом
- На запрос контента генерируется ответ только с данными
Насколько я понял, вы берете первый вариант и переносите рендеринг на сторону или сервера, или клиента, а я говорю про второй вариант, когда сервер выдает контейнер + кусочки. И запрашивая кусочек с интерфейса нужно будет возвращать его, а если это делает бот, то полностью отрендереную страницу.
Предложенный Гуглом вариант позволяет не мудрить с двумя механизмами формирования контента, а оставить один — кусочечный.
Пару секунд смотрел на заголовок и думал, что за новый язык такой — Web C#…
Сначала подумал, что web C# ломают… испугался!
Исправьте, пожалуйста, в тексте отрицание принципа «прогрессивного улучения»
Исправьте, пожалуйста, в тексте отрицание принципа «прогрессивного улучения»
-Такая хрупкость без реальной причины или выгоды перевешивает все недостатки.
Наверное все же перевешивает все преимущества.
Наверное все же перевешивает все преимущества.
HTML5 history избавит веб от этих проблем.
Уже успешно применяется на гитхабе в репозиториях и,прости господи, вконтакте.
Уже успешно применяется на гитхабе в репозиториях и,
Да, именно так оно и происходит.
Тем более, потом еще и поддерживать это все просто становится.
Тем более, потом еще и поддерживать это все просто становится.
Вот-вот! Тоже пережил тот период, когда Ext присобачивался везде, где только можно. Время разработки увеличивается раза в 3, результат далеко не всегда супер-кроссбраузерен, а при рендеринге особо заковыристых Ext-элементов, браузер начинает нещадно тормозить, а вместе с ним и вся система :((
Не, ну я не спорю — все получается так миленько, симпотно и всячески web 2.0-но, только оправдано ли это?
… А кстати есть ещё люди, делающие весь интерфейс на Ext.Layout — это вообще жесть неимоверная. Кто-то где-то забывает потереть зпт при создании объекта {x: 1, y: 2,}, и фсеее… весь сайт слетает напрочь!
В последнее время если и использую Ext, то только для создания отдельных объектов, типо гридов, диаграмм и т.п.
Не, ну я не спорю — все получается так миленько, симпотно и всячески web 2.0-но, только оправдано ли это?
… А кстати есть ещё люди, делающие весь интерфейс на Ext.Layout — это вообще жесть неимоверная. Кто-то где-то забывает потереть зпт при создании объекта {x: 1, y: 2,}, и фсеее… весь сайт слетает напрочь!
В последнее время если и использую Ext, то только для создания отдельных объектов, типо гридов, диаграмм и т.п.
Согласен по поводу «Excel в броузере».
Сделать круче хочется всегда — это бесспорно! Но с другой стороны любую фичу можно совершенстовать и отшлифовывать практически до бесконечности :) самое главное не прешанивать за пределы адекватности. Например если людям нужна обычная незайтеливая табличка, то врят ли стоит наворачивать систему гридов :))
Сделать круче хочется всегда — это бесспорно! Но с другой стороны любую фичу можно совершенстовать и отшлифовывать практически до бесконечности :) самое главное не прешанивать за пределы адекватности. Например если людям нужна обычная незайтеливая табличка, то врят ли стоит наворачивать систему гридов :))
рунету пока это не грозит (яндекс же)
создается впечатление что автор текста не совсем понимает для чего используется такая адресация и почему так проще для разработчиков, собссно он сам в этом и признается — «Зачем? Я не знаю.»
ну так и разобрался бы прежде чем писать чушь :)
суть текста «у меня вчера не открылся гокер, ололо», но избыточная серьезность тона изложения делает его… странным
на этой технологии работают все музыкальные сайты, в которых музычка не должна прерываться при переходе по страницам, какую альтернативу для них предложит автор?
создается впечатление что автор текста не совсем понимает для чего используется такая адресация и почему так проще для разработчиков, собссно он сам в этом и признается — «Зачем? Я не знаю.»
ну так и разобрался бы прежде чем писать чушь :)
суть текста «у меня вчера не открылся гокер, ололо», но избыточная серьезность тона изложения делает его… странным
на этой технологии работают все музыкальные сайты, в которых музычка не должна прерываться при переходе по страницам, какую альтернативу для них предложит автор?
Прямо таки похоже на драму с батхертом: у меня не получилось, потому всем так пользоваться нельзя.
Был блог, а стало небольшое приложение для просмотра этого блога. И свежо и удобно.
Был блог, а стало небольшое приложение для просмотра этого блога. И свежо и удобно.
А какая цель была? Может снизить нагрузку на железо и была основная цель?
Вы ретроград и распространяете унылость. Кирпич который тут перевели радость приносит только от попытки представить как автор его рожал. Огромные далеко идущие выводы из ошибки на одном единственном сайте.
Пачка риторических вопросов: Скажите зачем информационно-развлекательному сайту пользователи без JavaScript? Зачем чтобы его индексировали не основные поисковые системы? Нафига вообще бороться за SEO-URL'ы когда это состоявшийся медиа-проект и люди заходят на него по закладкам и из RSS лент?
Вот вы чуть пониже пишете ересь по поводу кеширования, может лучше потратить чуть побольше времени, выписать преимущества с разных сторон с учетом специфики проекта и тогда картина станет более сбалансированной. Потому что примерять свой негативный опыт к чужому проекту не выглядит убедительно, и уж тем более безапелляционно заявлять «точно не нужно». Я удивлен почему другие издания не экспериментируют в этой же области. Я бы с удовольствием сделал более интересный интерфейс для ленты-ру, если бы кто-то дал такую возможность. lifehacker.com дал пинок под зад тем кто думали что форматы устоялись. Отлично, на них будут равняться в будущем. Рискнули и стали первыми.
Пачка риторических вопросов: Скажите зачем информационно-развлекательному сайту пользователи без JavaScript? Зачем чтобы его индексировали не основные поисковые системы? Нафига вообще бороться за SEO-URL'ы когда это состоявшийся медиа-проект и люди заходят на него по закладкам и из RSS лент?
Вот вы чуть пониже пишете ересь по поводу кеширования, может лучше потратить чуть побольше времени, выписать преимущества с разных сторон с учетом специфики проекта и тогда картина станет более сбалансированной. Потому что примерять свой негативный опыт к чужому проекту не выглядит убедительно, и уж тем более безапелляционно заявлять «точно не нужно». Я удивлен почему другие издания не экспериментируют в этой же области. Я бы с удовольствием сделал более интересный интерфейс для ленты-ру, если бы кто-то дал такую возможность. lifehacker.com дал пинок под зад тем кто думали что форматы устоялись. Отлично, на них будут равняться в будущем. Рискнули и стали первыми.
Отбросьте личное и прочтите между строк. Написанное может оказаться правдой.
Конечно личности, я же не спорю с идеей, а реагирую на конкретную активность конкретного человека. Вы устроили борьбу с технологией и еще начали давать бизнес советы создателям сайта. Для меня это выглядело не убедительно. На ресурс заходят многие люди которые могут сформировать свое мнение, после прочтения ваших комментариев вся эта страница выглядела бы очень однобоко. Я работаю с этими технологиями и мой опыт успешный, почему бы не противопоставить свое слово вашему?
фреймы
В погоне за модой потеряна доступность.
Простые абстракции скрыты за ворохом фич.
$ 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.
Зачем? Мне это тоже не понятно.
Простые абстракции скрыты за ворохом фич.
$ 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.
Зачем? Мне это тоже не понятно.
А если так:
$ nc lifehacker.com 80
GET / HTTP/1.1
Host: lifehacker.com
В этом случае сервер отдаст кучу мусора — куски 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.
И эта безумно сложная реализация стремится стать единственно возможной.
Но не контент.
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.
И эта безумно сложная реализация стремится стать единственно возможной.
Занимался разработкой сайта работающего так же через ajax-запросы по содержимому #.
Многих проблем можно избежать:
1) Прописывать адреса ссылок как обычно, а уже на js отлавливать клик и менять текужещий #.
2) Из первого пункта вытекает нормальное индексирование и чтение всех микроформатов
3) Про кеширование не очень понял, но я не заметил проблем.
4) Для соц-виджетов просто передаю обычный url
Конечно есть подводные камни, но почти их все можно обойти, а на сложных сервисах можно ограничится частичным внедрением подобной технологии.
Многих проблем можно избежать:
1) Прописывать адреса ссылок как обычно, а уже на js отлавливать клик и менять текужещий #.
2) Из первого пункта вытекает нормальное индексирование и чтение всех микроформатов
3) Про кеширование не очень понял, но я не заметил проблем.
4) Для соц-виджетов просто передаю обычный url
Конечно есть подводные камни, но почти их все можно обойти, а на сложных сервисах можно ограничится частичным внедрением подобной технологии.
3) традиционные статичные страницы легко кешировать на люых уровнях, механизмы эти давно отлажены и работают. Такие дела.
А как данную проблему решает Facebook и Twitter?
Да, конечно, решения есть. Но это как будто вы сами ставите себе проблемы, а потом их решаете. Иногда в этом есть своя идея (мало времени, а надо чтобы было сделано), но зачастую все равно стоит держать в голове и придерживаться паттерна web-программирования, что сайт должен выдавать суть своего существования, — контент, без JavaScript'а. И проще это делать в прямом порядке — сначала контент, потом рюшечки и красивости.
Хорошая статья. Спасибо
Я эту статью еще в оригинале не понял. Какая-то слюнявая истерика.
И аргументация толком нет. По сути, гугл отлично индексит сайт — остальные побоку. Работает все это весьма круто и красиво. Трафик экономится — грузится при каждом клике только основной контент без всяких сайдбаров и хедеров/футеров. Почему по мнению автора трафика должно становиться больше, когда его на самом деле становится меньше? Кусок про неработающее кеширование не понял.
Ну накосячили что-то там, прилегли на несколько часов — с кем не бывает.
Плюс, в нормальных браузерах всегда будет реализовать history pushState и получить в итоге красивые чистые урлы, как раньше. Опять же, старые ссылки все тоже работают.
А баннеры с хреновым джаваскриптом просто не надо ставить. Ну или тестить на staging перед тем, как в продакшен выкатывать.
И аргументация толком нет. По сути, гугл отлично индексит сайт — остальные побоку. Работает все это весьма круто и красиво. Трафик экономится — грузится при каждом клике только основной контент без всяких сайдбаров и хедеров/футеров. Почему по мнению автора трафика должно становиться больше, когда его на самом деле становится меньше? Кусок про неработающее кеширование не понял.
Ну накосячили что-то там, прилегли на несколько часов — с кем не бывает.
Плюс, в нормальных браузерах всегда будет реализовать history pushState и получить в итоге красивые чистые урлы, как раньше. Опять же, старые ссылки все тоже работают.
А баннеры с хреновым джаваскриптом просто не надо ставить. Ну или тестить на staging перед тем, как в продакшен выкатывать.
С этими hash сайтами теперь много фейлов вылезает
Например у меня при открытии ссылки на gizmodo.com из rss перекидывает на gizmodo.de где конечно же вместо статьи я вижу заглавную страницу т.к. контент в зонах отличается.
Например у меня при открытии ссылки на gizmodo.com из rss перекидывает на gizmodo.de где конечно же вместо статьи я вижу заглавную страницу т.к. контент в зонах отличается.
> 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/ всё плодятся.
Народ, веб-хакеры и, вот, Google, всё твердят, а говносайты вроде Twitter, aeroflot.ru или habrahabr.ru/blogs/internet/110918/ всё плодятся.
Хотел опубликовать ссылку на пост в твиттере нажав на кнопку в конце поста:
но твиттер ответил:
А все из-за #! в заголовке статьи.
но твиттер ответил:
Sorry, that page doesn’t exist!А все из-за #! в заголовке статьи.
А ведь всё так мило начиналось. Браузеры не позволяют поменять урл страницы без её перезагрузки — авторы сайтов придумали ход конём, переносить значимые параметры в якорь — пользователи начинают копировать ссылку из адресной строки (для того, в частности, и мудрили) — авторы сайтов делают эту адресацию основной — сайты не индексируются поисковиками — гугл придумывает костыль — клиенты без JavaScript обламываются.
Клиенты без javascript вообще уже давно много где обламываются.
Сейчас уже позволяют, как я уже писал выше, через HTML5 history. Правда, в пределах текущего домена.
# — это специальный символ URL, который сообщает браузеру, что последующая часть адреса представляет собой ссылку на HTML элемент с таким id или именованый якорь (named anchor) текущей страницы.
Это очень частный случай. По большому счету, часть url, именуемая fragment, указывает на фрагмент данных. Содержательный смысл этого термина, трактуется клиентом по собственному усмотрению. Например это может быть начальной позицией для отображения видеопотока, состоянием приложения, css-селектором для фрагмента html и т.п.
Согласен, но так было в оригинале.
Но суть от этого не меняется, потому что все, что после # — это мета информация, относящаяся к контенту или ресурсу, загруженному по URL до #. Ну а идея в том, что эта мета-информация получается уже не мета, а прямо как обязательный параметр запроса.
Но суть от этого не меняется, потому что все, что после # — это мета информация, относящаяся к контенту или ресурсу, загруженному по URL до #. Ну а идея в том, что эта мета-информация получается уже не мета, а прямо как обязательный параметр запроса.
Всё верно: трактовка адресов зависит от конкретного приложения — если фрагмент считается обязательным, значит так надо. Тут нет противоречий.
Можно провести аналогию с привычными адресами: для таксиста важно знать название улицы и номер дома, куда подать машину; для почтальона обязательным будет так же номер квартиры (ведь он не может оставить вашу телеграмму просто где-то возле дома).
Можно провести аналогию с привычными адресами: для таксиста важно знать название улицы и номер дома, куда подать машину; для почтальона обязательным будет так же номер квартиры (ведь он не может оставить вашу телеграмму просто где-то возле дома).
По-моему, различных трактовок тут нет, так как есть спецификация URL, которая говорит, что все что после # — fragment identifier:
Т.е. фрагмент не может считаться обязательным (фрагмент URL, я так понимаю ваш поинт).
...additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed
Т.е. фрагмент не может считаться обязательным (фрагмент URL, я так понимаю ваш поинт).
Я понимаю вашу точку зрения. Думаю, корни заморочки нужно искать в том, что собой представляет архитектура клиент-сервер. Данная модель описывает *приложения*, которые состоят из нескольких взаимодействующих *программ*.
Модель назначает программам разные роли. Это дает опредленные бонусы разработчикам. Но с точки зрения конечного результата все это нужно воспринимать как составные части единого приложения. Т.е. сервер, браузер, прокси, джаваскипты, флеш-плееры и проч. это все программы, которые являются составными частями того приложения, результат работы которого вы можете наблюдать у себя на экране. Или не наблюдать, если какая-то программа падает. URL как таковые, тут совершенно не причем — они ни как не влияют на «живучесть» приложения в результате сбоев потому, что это всего лишь адреса. :)
Модель назначает программам разные роли. Это дает опредленные бонусы разработчикам. Но с точки зрения конечного результата все это нужно воспринимать как составные части единого приложения. Т.е. сервер, браузер, прокси, джаваскипты, флеш-плееры и проч. это все программы, которые являются составными частями того приложения, результат работы которого вы можете наблюдать у себя на экране. Или не наблюдать, если какая-то программа падает. URL как таковые, тут совершенно не причем — они ни как не влияют на «живучесть» приложения в результате сбоев потому, что это всего лишь адреса. :)
Совершенно согласен!
Я бы еще такую аналогию привел:
«Раньше» мы скачивали программы и устанавливали их на компьютере. Они могли воздействовать с ОС напрямую, а могли через виртуальную машину.
«Сейчас» мы буквально скачиваем приложения по URL-адресу и они сразу же исполняются (о чудо: без установки!) в своей собственной «виртуальной машине» — браузере.
Конечно, почтовые клиенты — самый яркий пример.
Я бы еще такую аналогию привел:
«Раньше» мы скачивали программы и устанавливали их на компьютере. Они могли воздействовать с ОС напрямую, а могли через виртуальную машину.
«Сейчас» мы буквально скачиваем приложения по URL-адресу и они сразу же исполняются (о чудо: без установки!) в своей собственной «виртуальной машине» — браузере.
Конечно, почтовые клиенты — самый яркий пример.
А вот я вашу уже не понимаю. Куда-то вы в другое ухеали :).
Какая-то странная статья ;-)
> The main problem is that LifeHacker URLs now don’t map to actual content.
Вообще-то, адрес ссылается на реальный контент только в том случае, когда адрес ссылается на реальную html-страницу.
Но в большинстве случаев страница генерируется на сервере. И, опять же, в большинстве случаев, URL преобразуется.
Сайт ровно с тем же успехом упадет, если забыть поставить ";" в серверном коде, как и если забыть поставить ";" в клиентском.
> The main problem is that LifeHacker URLs now don’t map to actual content.
Вообще-то, адрес ссылается на реальный контент только в том случае, когда адрес ссылается на реальную html-страницу.
Но в большинстве случаев страница генерируется на сервере. И, опять же, в большинстве случаев, URL преобразуется.
Сайт ровно с тем же успехом упадет, если забыть поставить ";" в серверном коде, как и если забыть поставить ";" в клиентском.
Вообще-то, адрес ссылается на реальный контент только в том случае, когда адрес ссылается на реальную html-страницу.
Но в большинстве случаев страница генерируется на сервере.
Не совсем так. URL — Uniform Resource Locator. В данном случае ресурса по ссылке нету, потому что отдается пустая страница, а дальше JS'ом уже достается сам контент.
Более того, это на 1 запрос реально делается к серверу 2, как раз чтобы получить контент.
А в чем разница для пользователя? Если он видит страницу, ему все равно, сгенерирована она на сервере или на клиенте. Если не видит, ему все равно, ошибка в JS или ошибка на сервере.
Запросов обычно не 1 и не 2. Главная страница Хабра, например, только что обратилась к серверу 75 раз (за картинками, джаваскриптами и ЦСС-ами).
Запросов обычно не 1 и не 2. Главная страница Хабра, например, только что обратилась к серверу 75 раз (за картинками, джаваскриптами и ЦСС-ами).
Разница для пользователя очень большая, особенно если этот пользователь какой-нибудь бот, у которого нет javascript'а, клиент с мобильника, где с JS тоже не все очевидно и трафик дороговат и тормозит.
Главная страница хабра не обратилась 75 раз, она обратилась столько только когда вы первый раз зашли на сайт, дальше вступает кэширование браузерное и т.п. и количество запросов сокращается. Но это необходимые действия. Когда у вас посещаемость выше 10К в день, не стоит увеличивать это количество еще 10К, так как это не пользователи, но трафик и ресурсы кушают.
Главная страница хабра не обратилась 75 раз, она обратилась столько только когда вы первый раз зашли на сайт, дальше вступает кэширование браузерное и т.п. и количество запросов сокращается. Но это необходимые действия. Когда у вас посещаемость выше 10К в день, не стоит увеличивать это количество еще 10К, так как это не пользователи, но трафик и ресурсы кушают.
Давайте не мешать все в кучу ;-)
Во-первых, не будем путать пользователей и ботов. Под пользователем я имел в виду человека, настоящего, живого.
Во-вторых, не будем делать один сайт на все случаи жизни. Не все сайты должны жить в ИЕ6. Не все сайты должны жить в мобильнике (и, если должны, то не в каждом мобильнике).
Конечно, если есть необходимость сделать сайт доступным для пользователя с отключенным JS (вдруг, и правда есть такая необходимость), его надо делать таким. С полной генерацией на сервере. Или, если нужен сайт на мобильном, можно сделать отдельную версию.
Но тут почему-то подвергается критике концепция, применимая для 90% сайтов. Концепция, которая ускоряет разработку и облегчает внесение изменений в продукт.
Во-первых, не будем путать пользователей и ботов. Под пользователем я имел в виду человека, настоящего, живого.
Во-вторых, не будем делать один сайт на все случаи жизни. Не все сайты должны жить в ИЕ6. Не все сайты должны жить в мобильнике (и, если должны, то не в каждом мобильнике).
Конечно, если есть необходимость сделать сайт доступным для пользователя с отключенным JS (вдруг, и правда есть такая необходимость), его надо делать таким. С полной генерацией на сервере. Или, если нужен сайт на мобильном, можно сделать отдельную версию.
Но тут почему-то подвергается критике концепция, применимая для 90% сайтов. Концепция, которая ускоряет разработку и облегчает внесение изменений в продукт.
Ну что значит «не мешать все в кучу»? Не путать пользователей, ботов, один сайт на все случаи жизни и т.п. — это все забавные отговорки.
Если вы зашли правильным клиентом, который работает согласно общепринятым нормам, отраженным в спецификации, то как-то странно получить валяющийся в корчах сайт. Логично?
Плюс к тому, заявлять что этот сайт работает только с включенным JS, это как еще пять лет назад говорить про то, что «сайт оптимизирован под разрешение 1024х768 и предназначен для Internet Explorer» или выкатывать полностью Flash сайт — выглядит дилетанством и доставляет кучу геммороя пользователю.
Этим самым вы пытаетесь переложить ответственность с себя, как с схалтурившего разработчика, на пользователя. У нас еще любят так про дороги говорить — «ну дорога не была рассчитана на такой грузопоток и такие сильные морозы» или «не нравится, вон там другой %whatever% есть».
Если вы не делаете сайт для себя и своих друзей, то стоит потрудиться сделать его нормально. Тем более, что поверьте, навешивать динамичность и классность, не так сложно при нормальной архитектуре, а следование «progressive enhancement» принципу — как-то уже делает архитектуру в правильном направлении, по крайней мере на клиенте будет все ОК.
Если вы зашли правильным клиентом, который работает согласно общепринятым нормам, отраженным в спецификации, то как-то странно получить валяющийся в корчах сайт. Логично?
Плюс к тому, заявлять что этот сайт работает только с включенным JS, это как еще пять лет назад говорить про то, что «сайт оптимизирован под разрешение 1024х768 и предназначен для Internet Explorer» или выкатывать полностью Flash сайт — выглядит дилетанством и доставляет кучу геммороя пользователю.
Этим самым вы пытаетесь переложить ответственность с себя, как с схалтурившего разработчика, на пользователя. У нас еще любят так про дороги говорить — «ну дорога не была рассчитана на такой грузопоток и такие сильные морозы» или «не нравится, вон там другой %whatever% есть».
Если вы не делаете сайт для себя и своих друзей, то стоит потрудиться сделать его нормально. Тем более, что поверьте, навешивать динамичность и классность, не так сложно при нормальной архитектуре, а следование «progressive enhancement» принципу — как-то уже делает архитектуру в правильном направлении, по крайней мере на клиенте будет все ОК.
Мне кажется, вы упускаете из виду стоимость и время разработки. (И, вместе с тем, сложность и гибкость системы.)
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 — значит, надо делать. Но, если этой необходимости нет, не надо ее выдумывать — это слишком дорого стоит.
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 — значит, надо делать. Но, если этой необходимости нет, не надо ее выдумывать — это слишком дорого стоит.
Разница в том что если JS заглючит, то фигу пользователь увидит, а не страницу. И получится вот так например (весь день сегодня такое):
А что увидит пользователь, если заглючит Java, Python или Ruby? :-)
А если интернет упадет, то вообще ничего не будет. Того что добавляется лишняя критическая система это не меняет.
Мы просто переносим эту критическую систему с сервера на клиент. А на клиенте построить DOM проще, чем на сервере.
И, таким образом, мы получаем более быстрый способ для создания более надежного сайта. (Если JS включен и интернет работает.)
И, таким образом, мы получаем более быстрый способ для создания более надежного сайта. (Если JS включен и интернет работает.)
Возможно я что-то не понимаю, но каким образом «на клиенте», где куча разных браузеров, ОС и прочих параметров что-то может работать надежнее чем «на сервере», где все под контролем?
JavaScript 1.5 работает, по сути, во всех браузерах. Но я не это имел в виду.
Например, сколько кода (и какого) нужно написать на сервере, чтобы сгенерировать список чекбоксов и отметить определенные из них? Циклы, проверки, шаблоны…
А на клиенте это две строки кода: первой строкой получим список чекбоксов, второй поставим галочки в нужных из них.
Конечно, я имею в виду «классическое» серверное программирование, где html-страница — это скорее string, чем DOM.
И, в любом случае, если планируется «навешивать» (слово-то какое!) JavaScript, то, получится, что код, первично генерирующий страницу, надо поддерживать и на сервере, и на клиенте. А это очень плохой сценарий. (Почти такой же, как одновременно поддерживать всю серверную часть на PHP и на Ruby :-)
Например, сколько кода (и какого) нужно написать на сервере, чтобы сгенерировать список чекбоксов и отметить определенные из них? Циклы, проверки, шаблоны…
А на клиенте это две строки кода: первой строкой получим список чекбоксов, второй поставим галочки в нужных из них.
Конечно, я имею в виду «классическое» серверное программирование, где html-страница — это скорее string, чем DOM.
И, в любом случае, если планируется «навешивать» (слово-то какое!) JavaScript, то, получится, что код, первично генерирующий страницу, надо поддерживать и на сервере, и на клиенте. А это очень плохой сценарий. (Почти такой же, как одновременно поддерживать всю серверную часть на PHP и на Ruby :-)
довольно острую проблему в эпоху web 2.0, а именно чистоту URL-адресов.
Это нифига не проблема — «чистота» адресов и её полезность весьма субъективна. URI это идентификатор. Ну давайте ещё поборемся за чистоту айдишников).
Вот меняться они, по хорошему, не должны — здесь я согласен с авторской критикой.
Чистота URLа, в моем понимании, это не только как он красиво выглядит, но и то, что он соответствует спецификации. Поразвернутее тут: habrahabr.ru/blogs/webdev/113842/#comment_3664853
Вся спецификация вот тут rfc2396. Синаксис URI, в самом общем случае, имеет вид:
Вот и весь обязательный синтаксис. Если посмотреть дальше, то окажется что и scheme не обязательна, т.к. существуют Relative URI. В остатке, по большому счету, важен только алфавит, а все остальные нюансы записи адресов — что считать обязательным, а что нет — это частное дело приложений.
<scheme>:<scheme-specific-part>
Вот и весь обязательный синтаксис. Если посмотреть дальше, то окажется что и scheme не обязательна, т.к. существуют Relative URI. В остатке, по большому счету, важен только алфавит, а все остальные нюансы записи адресов — что считать обязательным, а что нет — это частное дело приложений.
GitHub — молодцы, у них файлобраузер в репозиториях работает на AJAX, но URL меняет на нормальный, без «#!» (через новый API в браузерах, да). Что мешает остальным такое сделать?
> сайт Lifehacker.com был недоступен по причине неработающего JavaScript
Идиотизм на грани фантастики. Когда делаешь сайт — делай так чтобы весь контент с максимально возможными красивостями можно было получить только из выдачи веб-сервера, только потом накладываются рюшечки в виде CSS и уж в последнюю очередь, для совсем уж удобства и красоты — JS. У людей может быть отключен JS, не подгрузиться CSS и так далее, так что надо дать максимум возможностей при первой генерации страницы.
Идиотизм на грани фантастики. Когда делаешь сайт — делай так чтобы весь контент с максимально возможными красивостями можно было получить только из выдачи веб-сервера, только потом накладываются рюшечки в виде CSS и уж в последнюю очередь, для совсем уж удобства и красоты — JS. У людей может быть отключен JS, не подгрузиться CSS и так далее, так что надо дать максимум возможностей при первой генерации страницы.
Перепись уеб-староверов которые считают, что #! что-то принципиально меняет.
Бредятина какая то…
Так и не понял что авторы статьи предлагают. Не использовать AJAX для загрузки непосредственно контента? Ну-ну… А как сайтам с аудиоплеерами быть например?
Вообще проблемы не вижу. Есть кривые реализации конечно, но это же не значит что вся технология кривая.
Так и не понял что авторы статьи предлагают. Не использовать AJAX для загрузки непосредственно контента? Ну-ну… А как сайтам с аудиоплеерами быть например?
Вообще проблемы не вижу. Есть кривые реализации конечно, но это же не значит что вся технология кривая.
.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ломаем web c '#!' (hash-bang)