Я очень рад, что закончились эти времена, когда web разработчики создавали 2 версии сайта - с поддержкой JS и без нее. Мне нравится решение, которое использует VK.com. Они решили не подстраиваться под отсталого от технологий пользователя и не пускают на сайт всех тех, у кого отключены JS или Cookies. И это не мешает ему оставаться самым популярным сайтом рунета...

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

Проблема ведь не в том, что «злые пользователи» не хотят включать JavaScrpit. Проблема в том, что он не всегда доступен. И имеет смысл сделать опыть от исползования вашего сервиса максимально приятным. Поэтому offline first. Поэтому прогрессивное улучшение.

В JS есть такие события, как onload, в jQuery есть $(document).ready Не вижу проблем с медленным интернетом.

Разрабатывайте на здоровье. :) Все инструменты есть

@vyushin Как эти события помогут сайту работать до того, как загрузился джаваскрипт?

Я писал к вопросу о медленном интернете. Событие onload требует только включенных JS в браузере, $(document).ready выполняется тогда, когда DOM документа готов. В хандлерах описывается JS логика и дело сделано - жители деревень с диалапом молятся на вас.

@vyushin вы явно не потрудились прочесть статью и решили перейти сразу к коментариям. Посмотрите какие в ней есть кейсы для нестабильного и медленного интернета.

А проблема с подменой JS скриптом WI-FI провайдерами часто решается переходом на HTTPS.

Ну уж если вообще стоит жесткая блокировка на загрузку JS и вы над этим думаете, тогда может быть стоит еще подумать над работой сайтов в случае, когда отключают электричество и обеспечить пользователей бесперебойниками? Жители деревень после такой заботы о пользователях поставят всем разрабочтикам памятники при жизни. :)

@SilentImp, единственное что я не понял - это посыл статьи. Какой вывод можно сделать из нее?

Посыл: при разработке проектов стоит использовать прогрессивное улучшение и offline first.

над работой сайтов в случае, когда отключают электричество

это ты не починишь, а отключенный интернет можешь. offline first наше всё

единственное что я не понял - это посыл статьи. Какой вывод можно сделать из нее?

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

Не могу согласиться с вашей точкой зрения т. к. она регрессивна... Зачем копаться в мусорном баке со старыми браузерами и медленным интернетом? Наступил век облачных технологий, open API сервисах, WEB 3.0. Какой offline first?? Какие сайты без JS?? О чем вы вообще??? Я не понимаю, ребята. Наверное мы живем на разных планетах. Только online, только хардкор. :) Каждому свое.

регрессивность — субъективный параметр

Зачем копаться в мусорном баке со старыми браузерами и медленным интернетом?

у человека в поезде на айпаде с последним хромом есть ненулевая вероятность не получить ваш JS, или получить но допустим через пару минут. И это заметьте топовое устройство с топовым браузером. О чём вы?

Наступил век облачных технологий, open API сервисах, WEB 3.0. Какой offline first? Какие сайты без JS??

Только миллиард людей подключён к интернету. Новые пользователи из африки и индии пользуются преимущественно смартфонами с медленным интернетом. И у них есть деньги.

Даже с современными технологиями, например ReactJS, можно сделать сайт работающий без JS. Изоморфность приложения очень выручает при этом. @ilyabirman рассказал в советах о том, как можно обойтись малой кровью http://artgorbunov.ru/bb/soviet/20111005/

@vyushin Прочти пожалуйста: - Designing Offline-First Web Apps (Разработка веб-приложений по принципу «Автономность прежде всего») - Say Hello to Offline First

И затем посмотри: - Look ma, no backend! - Gregor Martynus - Front-Trends 2013

После этого мы сможем снова обсудить достоинства и недостатки offline first

Давайте не будем устраивать холивар. Все мы имеем право на свою собственную точку зрения и можно найти достоинства и недостатки каждой из них. Желаю всем, кто это делает, удачи в разработке сайтов для жителей Африки. Мужайтесь.

Хотелось бы узнать у автора: стоит-ли мне быть готовым к тому, что у пользователя выключен монитор или нет процессора?

Хотелось бы узнать у автора: стоит-ли мне быть готовым к тому, что у пользователя выключен монитор или нет процессора?

Как блин я попал в этот тред и зачем? Отпишите меня

Илья Бирман

@ilyabirman на твою статью сослались чуть выше. Этот тред — комментарии к статье http://frontender.info/everyone-has-js/

Мои извинения.

@Barlog-M ты считаешь что пользователь всегда онлайн? Серьезно?

И думаешь, что не стоит учитывать при разработке сайта/веб-приложения ситуации, когда пользователь, например, заехал в туннель метро и потерял соединение на пару минут?

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

И это будет конкурентным преимуществом и аргументом при ценоформировании. Весомым аргументом.

Подумайте над этим.

Потерял соединение в процессе работы или в процессе загрузки? Речь про серьёзное приложение или про вконтактик? Допустим каждое действие пользователя в приложении должно быть обработано на сервере во избежание подделки или нарушения целостности — как в таком случае быть? А бывают приложения, где это не надо?

Речь про серьёзное приложение или про вконтактик?

Про любое.

Потерял соединение в процессе работы или в процессе загрузки?

Стоит обрабатывать оба сценария. В случае если скриптов нет вообще, имеет смысл использовать подход мягкой деградации/прогрессивного улучшения. Например вместо запроса аякс просто позволить пользователю кликнуть по ссылке. Естественно она не сработает, если нет соединения, но пользователь сразу увидет в чем беда и когда соединения появится и он обновит страничку, то работа будет продолжена. Не будет ситуации, когда что то не работает наясно почему. Есть явный отклик на действия пользователя.

Если у нас пропало соединение после загрузки скриптов:

Допустим каждое действие пользователя в приложении должно быть обработано на сервере во избежание подделки или нарушения целостности — как в таком случае быть?

Сохранить данные и отправить их по событию появления соединения. Про это можно прочесть например тут

Похожий подход более высокоуровнево реализован в том же HOODIE Пару докладов и статей на эту тему я приводил в одном из комментариев выше.

А бывают приложения, где это не надо?

Да, конечно.

Ребята, отключите меня

Илья Бирман (с телефона)

@ilyabirman, я упомянул тебя, но это не вызывает подписи само по себе; ты был автоматически подписан после первого своего реплая. Зайди в ишью https://github.com/FrontenderMagazine/everyone-has-js/issues/1 и нажми кнопку "Unsubscribe" справа, пожалуйста. Это будет самый быстрый способ

1. Если приложение не может без чего-либо работать, оно не должно работать. Эмуляция функциональности — обман пользователя.
2. Надежда на то, что соединение вот-вот восстановится само собой, а не через час, день или после перезагрузки программы или устройства — обман пользователя.
3. Замена javascript ссылками — удел сайтов, но не приложений, подразумевающих интерактивность.

Если приложение не может без чего-либо работать, оно не должно работать. Эмуляция функциональности — обман пользователя.

Так в том то и дело, что может. Ну сохранит оно данные в локалсторадж, а не на сервер, и синхронизирует когда будет возможность. И? Это лучше чем выдать ошибку и потерять данные. Не хочешь обманывать (что очень верно) — проинформируй о том, что данные сохранены локально. Но не теряй их.

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

Никоим образом. Это вполне реальный кейс, который имеет смысл обрабатывать. Не восстановится через 5 минут — ну и ладушки. Подождем до синхронизации столько, сколько нужно. Думаю сообщить пользователю об отсутствии соединения и сохранить все изменения локально это лучше, чем безмолвно зависнуть с ошибкой. Верно?

Замена javascript ссылками — удел сайтов, но не приложений, подразумевающих интерактивность.

Зависит от того как реализовано приложение, но в целом — что с того? Отличное решение как минимум для сайтов, которое стоит взять на вооружение.

Пример: сохранили данные локально в сторадж. В случае полной обработки всего на сервере это будут команды серверу о том, что делал клиент и параметры к ним. На сервере за время оффлайна данные изменились и эти сохранённые команды пользователя с сохранёнными же параметрами выполнены быть не могут — обман пользователя.

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

Я не вижу каким образом обработка кейсов ненадежного соединения может затронуть пользователя у которого интернет не пропадает.

Не хочешь обманывать пользователя — проинформируй его о проблеме.

То, как ты решаешь проблему синхронизации данных и решаешь ли — вопрос в данном случае второстепенный и зависит от конкретного проекта.

То, о чем я говорю это не панацея. Это способ сделать проект более надежным и удобным с точки зрения пользователя. Не больше. Но и не меньше.

С помощью одного лиш CSS сложно на обычном сайте сделать доступным весь функционал, показ форм, меню и т.д. А значит как быть, если у человека нет js?

@Tom910 Прочтите cтатью Progressive enhancement is still important, как рекомендовал автор. Или хотя бы статью в вики. Прогрессивное улучшение в качестве подхода при разработке позволяет в значительной мере нивелировать проблему.

Ну и следует учитывать ситуацию, когда скрипты загрузились, но пропало соединение. Тогда всё становится ещё проще.

Мой рост — почти 2 метра. Тем не менее, я не могу одеваться в ту одежду, которая мне нравится. Я должен идти на компромисс с самим собой и фабриками и кружить по городу в поисках джинс (например), которые будут подходить мне по размеру, цене, качеству и будут удовлетворять вкусу. Так вот: если ты попал в условия, в которых у тебя не работает яваскрипт — ищи выход сам. Сайты не затачиваются под слепых людей, хотя их очень много среди сидящих в интернете, но должны затачиваться под планктон, сидящий с фаерволами? Нет, спасибо. Лично я не готов.

@maxsolovev согласен полностью. Волку наплевать, что о нем думает овца (есть такая поговорка)

Сайты не затачиваются под слепых людей,

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

Абсолютно плевать на 0.000001% жителей Земли, у которых по каким-то причинам отключен (о боже!) или как-то иначе не доступен Яваскрипт.

@artuska если бы ты повнимательнее ознакомился с материалами, то увидел бы, что это не 0.000001% а ~ 1.1%. Вполне значимое число платежеспособных пользователей. Это если не учитывать временные проблемы, которые возникают из за потери соединения.

Ну и да, мне остается надеяться, что ни один из славных ребят, которые высказали аналогичное отношение к проблеме и на милю не будет подпущен ни к одному значимому для меня сервису.

@SilentImp ну ребята, ну 0.000001% это же просто шутка, набор ноликов, смысл в другом.

А в чём?

@SilentImp смысл в том, что количество человек, у которых вообще есть доступ к интернету, но у ктоторых отключен или не доступен Яваскрипт ничтожно мало, о них не нужно беспокоиться.

@SilentImp «не будет подпущен ни к одному значимому для меня сервису» — я думаю, вы проедете под тоннелем в поезде, а потом просто нажмете на рефреш, и все ресурсы нормально подгрузятся и всё будет хорошо и ваш любимый сервис не произведет на вас плохое впечатление за это непродолжительное время, пока вы едете в тоннеле и интернет барахлит.

@maxsolovev ты кажется не очень понял суть проблемы. Это не проблема пользователя в принципе. Это проблема владельца ресурса. Это он не может из за подобных проблем что то продать. Это от него уходят пользователи к конкуренту, у которого offline-first есть.

И это … сайты «затачиваются» для слепых людей, если они являются частью целевой аудитории ресурса. Можешь поговорить о проблемах доступности и том, как они решаются с https://twitter.com/roman01la У него есть опыт в этом вопросе.

смысл в том, что количество человек, у которых вообще есть доступ к интернету, но у ктоторых отключен или не доступен Яваскрипт ничтожно мало, о них не нужно беспокоиться

Есть куча людей в развивающихся странах, у которых настолько медленный интернет, что у них ~есть~ будет джаваскрипт сразу после того, как он у них загрузится, а это может занять не одну минуту

@artuska на чем основано твое заявление о «ничтожно мало». Какие то статистические данные? 1.1% (по UK, у нас, вероятно больше, согласно https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/) это пренебрежительно мало? Это люди, которым можно что то продать. И которым ты не сможешь ничего продать просто потому что не потрудился сделать ресурс доступным для них.

И самое главное — проблемы с соединением повсеместны. Это даже не 1.1%, это 100%. Ты никогда сам не мог загрузить сайт когда ехал в транспорте или выехал за город из за ненадежного соединения? Как это влияет на конверсию, не задумывался? Подсказка: это её прилично уменьшает. И ты зарабатываешь меньше чем мог бы. Нужно ли тебе или твоему заказчику больше денег или это «пренебрежительно мало» — решай сам, конечно.

И это … сайты «затачиваются» для слепых людей, если они являются частью целевой аудитории ресурса. Можешь поговорить о проблемах доступности и тем, как они решаются с https://twitter.com/roman01la У него есть опыт в этом вопросе.

Антон прав — сайты затачиваются; со мной тоже можно обсудить a11y. Можно посмотреть вот этот доклад с введением в доступность http://iamstarkov.com/a11y-2013/

@iamstarkov Спасибо за доклад, было интересно как сделать лучше сайт для слепых.

Я просто ставлю style="display:none" на тег <body> и в самом конце главного JS файла меняю это свойство на block. В итоге пользователь увидит сайт только после того как JS файлы загрузились и сработали. Поддерживать "offline first", это как поддерживать старых браузеров как IE6-7. Из за таких людей разработка идет медленнее.

Я просто ставлю style="display:none" на тег и в самом конце главного JS файла меняю это свойство на block.

— это пять!

Недавно верстальщик делал mobile-first через js. В итоге страница была кашей до полной загрузки js :(

Все, кто прочитал статью и считает offline first плохой идеей, дайте этой идее пять минут или пару дней на переваривание

Есть у кого-нибудь статистика по пользователям без поддержки js?

@azamat-sharapov поинтересуйся сколько будет ждать пользователь видя белый экран до того, как закроет вкладку браузера и никогда больше туда не вернется.

@ssbb а какое отношение имеет mobile-first к js?

@divone в статьи и комментариях приводится 1.1% для UK

поинтересуйся сколько будет ждать пользователь видя белый экран до того, как закроет вкладку браузера и никогда больше туда не вернется.

@SilentImp если у пользователя медленный интернет, это он скорее всего сам понимает и будет ждать, пока сайт грузиться. Есть другие факторы, от чего "сайт долго может не показаться": - Тяжелые скрипты - Я на свою работу редко когда добавляю огромные библиотеки, очень редко мне приходилось jQuery добавить, JS я умею писать. Использую webpack, чтобы упаковать все скрипты (даже CSS туда) в один JS файл, чтобы запросов HTTP много не отправлять (лучше об этом думай, чем этот "offline first"). Использую также lazy-loading, для мало важный скриптов, которые при загрузки не понадобятся и грузятся только по дополнительному запросу (после загрузки станицы уже). Небольшие картинки ставлю data:image ссылками. - К тому ж, я это "в общем" говорю, для примера. Кто мешает поставить индикатор загрузки? вместо белого экрана можно показать хоть что. Даже можно показать 90% сайта (контент например), который от JS не зависит. Если я сказал ставлю display:none на <body>, это не значит что я использую его везде, как будто ничего больше не знаю. - Сервера - возьми тот вКонтакте для примера: живу в Бангкоке, пользуюсь нормальным интернетом и этот ВК постоянно тормозит. Это значит нужно думать о разных точках мира и по возможности купить небольшие сервера из разных точек, чтобы кешировать сайт в них. Вы ранее говорили об Африке. Купи лучше сервер и ставь сайт туда, если уж тебе Африка так важна для твоего бизнеса (или хоть о чем сайт).

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

@azamat-sharapov, вы правы и все это понимают. Есть более важные вещи при разработке сайта (и некоторые из них вы перечислили). Идеи offline для online проекта утопичны в принципе.

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

Но пытаться сделать offline для online приложения или сайта - это утопия. Такие идеи можно продать только неосведомленному и некомпетентному заказчику, но более-менее осведомленный и компетентный человек никогда не купит такие идеи.

@azamat-sharapov

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

Или не понимает. Или не будет. Никаких гарантий. И самое главное — если у вас есть конкурент, у которого аналогичный магазин или сервис загрузится на медленном интернете быстрее и не теряет работоспособности — каким он воспользуется? То о чем я говорю может быть конкурентным преимуществом. Насколько оно будет существенным — решать вам и, да, это зависит от проекта. Я думаю что в общем случае на offline-first и прогрессивное улучшение вполне стоит обратить внимание.

Есть другие факторы, от чего "сайт долго может не показаться"

Да, конечно. И в целом их, насколько это возможно, стоит исключать.

лучше об этом думай, чем этот "offline first"

Да, это важно. Но при этом offline first никак не исключает.

вместо белого экрана можно показать хоть что.

Да, можно, в целом я все равно считаю это скверной практикой. Хотя самому приходилось использовать. Например, когда использовал l20n для реализации многоязычности в собственном CV. Сейчас думаю, что мог бы этого избежать и результат был бы лучше.

Если я сказал ставлю display:none на , это не значит что я использую его везде, как будто ничего больше не знаю.

Того факта, что пример ужаснен, это не отменяет. И если кто то, упаси боже, воспримет его буквально, то какой то сервис потеряет клиентов, а клиенты, вероятно, возможность воспользоваться сервисом.

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

То, что стоит использовать CDN правда, конечно стоит. Но это, опять таки, никак не отменяет ни прогрессивное улучшение, ни offline-first.

@RealJTG удалил ваш комментарий. Какжется, проблема с кодировкой.

@vyushin не говорите, пожалуйста, за других. Я например с вами категорически не согласен. Прежде чем говорить что подход прогрессивного улучшения или offline-first утопичен — ознакомьтесь с вопросом.

Никакого отношения к десктопным приложениям offline-first не имеет. Это, по сути, прослойка, улучшающая опыт пользователя, насколько это возможно, в случае потери соединения.

Ссылки на материалы, с которым стоит ознакомится, я приводил выше.

Этот подход позволяет улучшить опыт использование вашего сервиса. Может стать вашим конкурентным преимуществом. Как и подход прогрессивного улучшения позволит его улучшить. Или даже мягкой деградации.

@vyushin @azamat-sharapov Суть offline-first в том, что ваше приложение становится более устойчиво к проблемам сети, обеспечивает лучший опыт использования в её отсутствие. Это можно делать по разному и конкретика будет зависить от проекта. Стоит ли выгода человекочасов, которое придется потратить на внедрение такого подхода в конкретном проекте — решайте сами. Зависит. Но не рассказывайте, пожалуйста, о том что offline-first «утопичен» или, тем более, «вреден». Это определенно не так.

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

Пользователи не отключили JavaScript?

ссылка ведет на статью 2013 года. Вам не кажется, что эта статистика несколько устарела? :)

Зачем копаться в мусорном баке со старыми браузерами и медленным интернетом? Наступил век облачных технологий, open API сервисах, WEB 3.0. Какой offline first?? Какие сайты без JS?? О чем вы вообще??

вот это я и называю "упоение технологиями". Вон с корабля прогресса всех, кто не может держать наши суперсовременные браузеры, отжирающие на рендер страницы 'hello world' полгига оперативки! Утопить всех лохов, у которых нет 16 гигов оперативки на компе! Убить всех идиотов, которые едут в деревню и теряют там интернет - всё, ВСЁ, вы поняли, они больше не люди, их больше нет в нашем интернете!

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

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

да не в сервере дело (хотя и в нем тоже), а в диал-ап (модеме) 14400 у пользователя. Кто-нибудь еще помнит, что такое модем и каково было забирать почту на ДШ-АТС, или я тут один такой... мамонт? :)

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

Божечки-кошечки! Если мне платит тольо тот 1.1% людей у которого отключен по каким-лиюо проблемам js, то конечно разработчику будет ано указание заниматься этим в первую очередь, если же поддержка вашего offlne first будет стоить мне 30%(любое большое значение) бюджета, а приносить 0.5%(любое маленькое значение) прибыли, проще говоря, если мои затраты не окупятся на поддержку чего угодно в том числе offline first, то это не нужно. Пример с джинсами выше просто потрясающий.

@Neftedollar вся суть статьи в том, что нет возможности измерить постоянный процент offline, так как интернет может отвалиться по любой причине и не зависящим от вас обстоятельствам. То есть аффектив всех сразу, в том числе и лояльных пользователей, а это дорого стоит бизнесу