Комментарии 178
Как джаваскриптер, я не фанат людей с отключенным JS — тормозит-то не JS, а куча баннеров с видео и древних счетчиков с блокирующими запросами. Сравните приложения без рекламы типа Gmail или Twine и некоторые новостные порталы.
Но не вставить хотя бы <noscript>Дорогой юзер, наш сайт не работает без JS.</noscript>, как это сделали Feedly, это все-таки совсем дно.
Так и не надо от них фанатеть, просто стоить учитывать что внезапно люди не захотят пользоваться вашими продуктами так как вы этого хотели.
Я вот тоже отключаю JS потому что проще смотреть сайты без него. Если уж есть какая то функция (ответить вам например) которая мне сейчас нужна то включаю. Все хорошо что в меру, а JS дает возможность делать все прилагая поменьше усилий и некоторые поддаются соблазну платя за это скоростью, трафиком и пользователями. И мне если честно совершенно плевать почему конкретно оно там тормозит, оно тормозит я не буду этим пользоваться. Если сайт ну слишком уж плох, я вношу его в список заблокированных (если слишком навязчиво просит отключить адблок или вообще коверкает контент страницы в ответ на применение адблока).
Я вот тоже отключаю JS потому что проще смотреть сайты без него. Если уж есть какая то функция (ответить вам например) которая мне сейчас нужна то включаю. Все хорошо что в меру, а JS дает возможность делать все прилагая поменьше усилий и некоторые поддаются соблазну платя за это скоростью, трафиком и пользователями. И мне если честно совершенно плевать почему конкретно оно там тормозит, оно тормозит я не буду этим пользоваться. Если сайт ну слишком уж плох, я вношу его в список заблокированных (если слишком навязчиво просит отключить адблок или вообще коверкает контент страницы в ответ на применение адблока).
НЛО прилетело и опубликовало эту надпись здесь
И Вы сравните новый Gmail и его лайтовую версию («html-версия», емнип). В разы отличается скорость работы, а не только первой загрузки. Прорывного функционала в новой версии я не нашёл, а красивые прогресс-барчики мне не нужны — пусть лучше письмо быстрее откроется.
Я считаю, что создавать сайты, способные работать без JS, вполне возможно.
Прикладывать силы для разработки/тестирования веб-приложений, которые могут работать без js — бесполезная трата времени и денег. Пользователей, которые отключают у себя JS — единицы.
Это же веб, а не App Store для JavaScript, мы должны быть уверены, что все всегда работает на любом устройстве с самыми базовыми функциями.
Нет. Мы должны быть уверены, что наша ЦА может посмотреть наш сайт. Ито, не вся. Если незначительный процент продолжает использовать совсем устаревшие браузеры, то чаще всего дешевле проститься с этими пользователями.
Непонятно, зачем автор вообще этим занималась. Но спасибо за перевод.
Пользователей, которые отключают у себя JS — единицы.
Сотни тысяч, и в отличие от вас, я могу доказать свое утверждение.
если незначительный процент продолжает использовать совсем устаревшие браузеры, то чаще всего дешевле проститься с этими пользователями.
Не в этом дело. Дело в том, что без JS у вас не получается впарить «вашей ЦА» статистику, следилки, рекламу, аналитику, вебвизор, баннеры и прочий буллшит, именно это так бесит хозяев сайтов.
Я надеюсь, что тренд «отключи JS — избавься от буллшита» будет развиваться. Черт побери, да это отличная идея для того, чтобы поднять вокруг нее хайп. Крайне полезная.
НЛО прилетело и опубликовало эту надпись здесь
Я бы начал с ответа на вопрос — зачем вам знать количество и регион.
НЛО прилетело и опубликовало эту надпись здесь
У нас видимо, разный подход просто. 1 можно понять по комментариям и в целом активности в статьях. Для eng/ru и любопытства — уже написали, да, access.log вполне сгодится. Там видны IP посетителей, и запрошенные ими страницы. Я на 146% уверен, что есть готовые скрипты для парсинга и построения красивых графичков на основе этого лога.
НЛО прилетело и опубликовало эту надпись здесь
Прекрасный пример: проблема решается на уровне IP, а пытаются решить на JS.
Эмм нет. Проблема не решается. Аналитика с js даёт возможность сделать отпечаток браузера и узнать сколько новых пользователей пришло. Это из самого тупого, что я не смог сделать по access.log.
Многовато вы хотите. Отпечаток браузера.
Для того, чтобы заработать денег и вложить их в производство нового и интересного вам же контента — достаточно логично.
Мне же нужно понимать кто конкретно пользуется плодами моего труда, чтобы знать аудиторию. Любому оратору нужно знать перед кем он будет ораторствовать, чтобы достичь своей цели эффективно. Так же и любому магазину/почте/автоконцерну необходимо знать, кто их клиенты. Конечно не паспортные данные и фотографию с членами семьи, но вот возраст, браузер и операционная система достаточно много может сказать лично мне и я бы уже мог предположить портрет ваших интересов.
Как всегда вопрос заключается в злоупотреблении, которым вы и хотите апеллировать. Да, есть люди которые собирают максимальную информацию на продажу. Карандашом можно человека зарубить, это же не значит, что нужно запретить и плохо относится к ножницам и ручкам.
Мне же нужно понимать кто конкретно пользуется плодами моего труда, чтобы знать аудиторию. Любому оратору нужно знать перед кем он будет ораторствовать, чтобы достичь своей цели эффективно. Так же и любому магазину/почте/автоконцерну необходимо знать, кто их клиенты. Конечно не паспортные данные и фотографию с членами семьи, но вот возраст, браузер и операционная система достаточно много может сказать лично мне и я бы уже мог предположить портрет ваших интересов.
Как всегда вопрос заключается в злоупотреблении, которым вы и хотите апеллировать. Да, есть люди которые собирают максимальную информацию на продажу. Карандашом можно человека зарубить, это же не значит, что нужно запретить и плохо относится к ножницам и ручкам.
Для того, чтобы заработать денег и вложить их в производство нового и интересного вам же контента — достаточно логично.
Так-то оно так, но не будем забывать, куда может привести дорога, вымощенная на первый взгляд благими намерениями.
Так же и любому магазину/почте/автоконцерну необходимо знать, кто их клиенты.
Перетопчутся. Если мне понадобятся услуги магазина/почты/автоконцерна, я приду к ним сам, куплю что надо и уйду. А потом постараюсь стереть их из собственной памяти, как информацию, утратившую нужность. Гарантия на бумажке написана.
я бы уже мог предположить портрет ваших интересов.
Мне не нужно, чтобы вы предполагали портрет моих интересов.
p.s. в настоящий момент обдумываю как раз концепт системы, которая будет нещадно корежить «отпечаток браузера» при отдаче его в сеть.
p.p.s я очень рад тому, что появляются вещи типа GDPR, которые позволяют хоть как-то контролировать и регулировать сбор информации, и надеюсь, что в этом плане гайки закрутят гораздо больше.
> приду к ним сам, куплю что над
Откуда только «почему не делают современных мощных телефонов на маленькие диагонали». Купить можно не что нужно, а что есть. Хорошо когда оно совпадает.
Откуда только «почему не делают современных мощных телефонов на маленькие диагонали». Купить можно не что нужно, а что есть. Хорошо когда оно совпадает.
я приду к ним сам, куплю что надо и уйду.Это только если людей со схожими запросами они уже обслужили и знают, что у них есть продукт подходящий именно вам. А так они будут делать то, что удобно им, а не вам. Будут почтовые марки не с индексами, а с точным адресом, фотографией получателя и примером их подписи. Будут не кружки с ручкой, а стаканы просто цилиндрической формы. Будут машины не с коробкой или вариатором, а просто напрямую с двигателем.
Им необходимо знать ваши потребности, чтобы произвести товар/услугу и продать её. Если они не продают её, то они прогорают и приходят те, кто угадывает с потребностями потребителей. Но ни один вменяемый человек не хочет гадать на кофейной гуще, поэтому и есть маркетологи, аналитики и иже с ними. Это экономика.
Мне не нужно, чтобы вы предполагали портрет моих интересов.А мне, как производителю крутых наушников, необходимо знать средне-статистическую форму уха, чтобы не пытаться продать вам треугольные. Мне нужно знать ваши слуховые параметры, потому что зачем вам наушники с чистыми 5 Гц, если вы ниже 20 не слышите?
Это всё необходимая для производства информация.
обдумываю как раз концепт системы, которая будет нещадно корежить «отпечаток браузера»Всё
я очень рад тому, что появляются вещи типа GDPR, которые позволяют хоть как-то контролировать и регулировать сбор информацииЯ тоже рад. Но заметьте, что закон ограничивает использование вашей информации и уведомляет вас о её сборе. Но он не запрещает собирать её и использовать. Потому что они знают, что это и сейчас есть, и раньше было двигателем прогресса.
Это только если людей со схожими запросами они уже обслужили и знают, что у них есть продукт подходящий именно вам.
Что подходит именно мне — я буду решать сам, а не маркетологи, которым надо впарить.
Если они не продают её, то они прогорают и приходят те, кто угадывает с потребностями потребителей
Именно так, это бизнес.
Мне нужно знать ваши слуховые параметры, потому что зачем вам наушники с чистыми 5 Гц, если вы ниже 20 не слышите?
Вам не нужно знать мои слуховые параметры, потому, что вам не нужно впаривать мне наушники с 20 Гц вместо 5 Гц. Я покупаю те, которые хочу сам, а не те, вагон которых у вас случайно завалялся на складе и которые надо срочно спихнуть (вспомним историю с BlueDio — эталон пиара). Мне не нравится, когда пытаются что-то там за меня решить, какое вообще кому дело, что я там слышу, а что нет, может я вообще по длине кабеля выбираю?
придумано уже производителями Tor браузера
У него с с популярностью все плохо, думаю. Нужен некий иной подход.
Я тоже рад. Но заметьте, что закон ограничивает использование вашей информации и уведомляет вас о её сборе. Но он не запрещает собирать её и использовать.
Это пока что. Сейчас мне очень нравится, когда я захожу на сайт и имею возможность выкрутить регулировку собираемой информации почти в ноль.
я буду решать сам… покупаю те, которые хочу самРынок всегда строится так, что за вами только выбор из ограниченного числа. Это единственное, что вы действительно решаете сами, но всё равно, если вам вот позарез нужен кабель с XLR наконечником или 2 парами наушников и одним концом, то вы их тупо не найдёте. Это ваша потребность, но она не совпадает с потребностями 50% других клиентов, поэтому эти наушники никогда никогда производить не будет.
У вас реально очень плохие представления о сборе данных и их использовании. Их используют для создания статистики. Им не нужны конкретно вы. Им нужно знать, к какой группе вы относитесь. И вам будут впаривать что-то (массажёр для простаты, тетрадки в клеточку, гаечный ключ на 14) только если 50% пользователей из вашей группы имеют такую потребность. Им в действительности глубоко насрать кто вы есть и чем вы занимаетесь, они продают и используют только цифры.
вагон которых у вас случайно завалялся на складе и которые надо срочно спихнуть
«Именно так, это бизнес». «Нам» нужно спихнуть это срочно, потому что иначе это убытки. Всё вполне логично и приемлемо.
У него с с популярностью все плохо, думаю. Нужен некий иной подход.Сначала попользуйтесь, а потом делайте умозаключения.
Сейчас мне очень нравится, когда я захожу на сайт и имею возможность выкрутить регулировку собираемой информации почти в ноль.И в ноль вы её выкрутить не сможете никогда в жизни. Вообще никогда)
Вам надо бы поговорить с реальными аналитиками, которые реально используют личные данные других людей, чтобы понять, как они используются и что они из них делают.
Сначала попользуйтесь, а потом делайте умозаключения.
А на основании чего вы сделали вывод, что я им не пользовался?
И в ноль вы её выкрутить не сможете никогда в жизни. Вообще никогда)
Успешно выкручиваю, всегда выставляя этот движок на «технологические куки», которые нужны для логина на сайт, а не для рекламы.
Вам надо бы поговорить с реальными аналитиками, которые реально используют личные данные других людей, чтобы понять, как они используются и что они из них делают.
Чтобы понять, что именно собирают и как можно улучшить систему подачи ложной информации в эти каналы.
НЛО прилетело и опубликовало эту надпись здесь
Я вообще поставил себя на место производителя. Но допустим я произвожу котиков с бантиками на голове. Хотя конкретно сейчас я продуцирую комментарии на хабре :D
Но меня как производителя на самом деле не интересует ваша заинтересованность в конкретном продукте или контенте, мне интересно то, что вы за этот продукт дадите мне. Это либо личное время, потраченное на просмотр рекламы, либо деньги, потраченные на месячную подписку/конкретный экземпляр, либо, если я у меня хватает денег и я не преследую эту цель, ответный контент (конкретно сейчас это комментарий).
По моему личному и очень субъективному потребительскому опыту, читать интереснее тех, кто пишет о том, что знает, а не пытается рассчитывать интересное его аудитории.Ну хабр хороший показатель того, что вообще оба вектора развития являются приемлемыми (есть тут и «независимые писатели», а есть ализар).
Но меня как производителя на самом деле не интересует ваша заинтересованность в конкретном продукте или контенте, мне интересно то, что вы за этот продукт дадите мне. Это либо личное время, потраченное на просмотр рекламы, либо деньги, потраченные на месячную подписку/конкретный экземпляр, либо, если я у меня хватает денег и я не преследую эту цель, ответный контент (конкретно сейчас это комментарий).
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Предположим что вы продаете бейсболки с надписью «FBI», красные мокасины или занижаете приоры.
Гугл аналитикс вам выдаст ваших покупателей. А вот максминд даст адрес офиса в Краснодаре.
Есть и более запутанные случаи, когда пользователь однокласников заходит через бесплатный впн.
Гугл аналитикс вам выдаст ваших покупателей. А вот максминд даст адрес офиса в Краснодаре.
Есть и более запутанные случаи, когда пользователь однокласников заходит через бесплатный впн.
И количество посещений, и регион отлично считаются на серверсайде.
Счетчик можно написать и самому, на php (или другом бэкендовом ЯП).
НЛО прилетело и опубликовало эту надпись здесь
Сотни тысяч на фоне скольки миллионов? :)
Докажите, если не сложно. Мне прям интересно. А затем сравните доход от этих пользователей и затраты на создание-сайта-без-js.
Докажите, если не сложно. Мне прям интересно. А затем сравните доход от этих пользователей и затраты на создание-сайта-без-js.
Докажите, если не сложно.
Идем сюда, смотрим статистику и звезды.
А затем сравните доход от этих пользователей и затраты на создание-сайта-без-js.
Тут я рассуждать просто не берусь — нет соответствующих знаний.
Как NoScript связан с полным отключением JS?
Он внезапно служит для этого. Достаточно просто включать его на всех сайтах и всех доменах, а не делать фильтры.
Я там ниже написал про отрубание ноги. Не обижайтесь, но вы сейчас именно так и делаете.
Кстати, по поводу рекламы. Многие сайты, в том числе Хабр существует за счет рекламы, которая вас «как пользователя не радует», но позволяет пользоваться качественным ресурсом бесплатно.
Почему бы не выключить себе CSS, например, или HTML? Именно из-за них вам показывают эту ужасную рекламу.
Кстати, по поводу рекламы. Многие сайты, в том числе Хабр существует за счет рекламы, которая вас «как пользователя не радует», но позволяет пользоваться качественным ресурсом бесплатно.
Почему бы не выключить себе CSS, например, или HTML? Именно из-за них вам показывают эту ужасную рекламу.
НЛО прилетело и опубликовало эту надпись здесь
Я там ниже написал про отрубание ноги. Не обижайтесь, но вы сейчас именно так и делаете.
Заодно с ногой я отрубаю длинные носы хозяев сайта, лишая их возможности следить за мной и втуливать мне ненужные вещи.
Хабр существует за счет
за счет чего он существует, ниже написали.
Почему бы не выключить себе CSS, например, или HTML?
Reader Mode — отличное изобретение, особенно при серфинге с мобильного.
Дохода от таких пользователей практически не будет, поскольку не загрузится реклама.
не загрузится реклама
Что меня, как пользователя, только порадует. Я на сайты хожу не рекламу смотреть.
Согласен, ведь в последнее время реклама становится все агрессивней.
На первых форматах глаз замыливался, развивалась баннерная слепота, и приходилось рекламщикам делать их более заметными, броскими и навязчивыми (попандеры, всплывашки).
Из-за этого и возникает желание установить uBlock какой нибудь и забыть об этом кошмаре. Как результат — сайты блокируют контент, требуя отключить блокировщик. И так по кругу :(
На первых форматах глаз замыливался, развивалась баннерная слепота, и приходилось рекламщикам делать их более заметными, броскими и навязчивыми (попандеры, всплывашки).
Из-за этого и возникает желание установить uBlock какой нибудь и забыть об этом кошмаре. Как результат — сайты блокируют контент, требуя отключить блокировщик. И так по кругу :(
Если это интернет-магазин и они ещё и банковские карточки не заводят, то их невозможность пользоваться сайтом не особо напрягает. Даже наоборот.
Не в этом дело. Дело в том, что без JS у вас не получается впарить «вашей ЦА» статистику, следилки, рекламу, аналитику, вебвизор, баннеры и прочий буллшит, именно это так бесит хозяев сайтов.
У меня сейчас на разработке один интересный и важный в своем кругу проект, в котором пользователи взаимодействуют с интерактивной картой. Что мне прикажете делать? Никаких баннеров, метрик и пр нет, зарабатываем на другом (потому что есть возможность заработать).
По поводу скорости работы. Хм… Все кешируется, а при следующем открытии сайта, все работает практически мгновенно даже при очень медленном интернете (по сети гоняется единицы килобайт).
Без JS, пришлось бы писать «по старинке» приложения под все актуальные десктопные и мобильные платформы, что оттянуло бы сроки реализации проекта и на порядок увеличило бы стоимость проекта.
Скоро их станет больше. Мобильный хром при плохой связи будет отрубать скрипты.
А firefox трекинг.
Может просто пора перестать создавать переусложненные веб-приложения, при разработке которых нельзя обойтись без js?
Судя по всему, подавляющее большинство разработчиков и заказчиков просто об этом не задумывается.
Судя по всему, подавляющее большинство разработчиков и заказчиков просто об этом не задумывается.
А как вы будете делать картографический сервис без JS? И сколько времени это займет?
Из 12 сайтов, указанных в статье, больше половины – веб-приложения, им нужна интерактивность, а ее правильнее делать через JS.
Из 12 сайтов, указанных в статье, больше половины – веб-приложения, им нужна интерактивность, а ее правильнее делать через JS.
Картографический сервис — это исключение. И, как и любое исключение, он лишь подтверждает правило.
И, как и любое исключение, он лишь подтверждает правило.
Не хочу придираться к словам, но исключение никогда не подтверждает правило.
НЛО прилетело и опубликовало эту надпись здесь
Существование исключений подтверждает существование правила, из которого эти исключения делаются. Если в правиле нет исключений, то это закон: Как правило, нельзя переезжать двойную сплошную линию, НО если регулировщик на это указывает, то можно — получается исключение. А вот в законе сохранения энергии — исключений нет.
Feedly, Youtube, Netflix, Google Maps — полноценные веб приложения, без JS им никак. Это 4 сайта из 12, одна третья часть статьи. Многовато, чтобы называть их исключениями.
Это в выборке их 1/3. И там применение js оправдано.
А среди всех вообще сайтов таких приложений подавляющее меньшинство. И даже там, где сейчас, следуя веяниям моды, запилили приложения, они зачастую не нужны. Вместе с тоннами js, мегабайтами трафика и многосекундными ожиданиями, пока все это загрузится и распарсится.
А среди всех вообще сайтов таких приложений подавляющее меньшинство. И даже там, где сейчас, следуя веяниям моды, запилили приложения, они зачастую не нужны. Вместе с тоннами js, мегабайтами трафика и многосекундными ожиданиями, пока все это загрузится и распарсится.
А что именно в YouTube не может работать без JS?
Нестандартные контролы плеера, к примеру. Т.е. даже если стандартный элемент video станет вдруг поддерживать формат DASH, отдаваемый серверами Youtube, у нас не будет возможности выбирать субтитры, качество и скорость воспроизведения, как минимум.
По крайней мере, до тех пор, пока на эти вещи не придумают стандарт и не реализуют его во всех браузерах.
По крайней мере, до тех пор, пока на эти вещи не придумают стандарт и не реализуют его во всех браузерах.
Понятное дело, что без JS не получится сохранить ютуб (и множество других сайтов) ровно в том виде, в котором они есть. Потому что они создавались для JS. Но без нестандартных контролов плеера можно жить. Ютуб умеет отдавать не DASH. Субтитры поддерживаются HTML5, выбор качества можно сделать с перезагрузкой страницы
К слову, если верить MDN, в Firefox 21-22 была поддержка DASH без JS
> он лишь подтверждает правило.
Механизм подтверждения — в студию!
Механизм подтверждения — в студию!
Гугл карты были созданы в 2005 году. Что то мне подсказывает что они были совсем не тем приложением и не с тем объемом трафика чем сейчас. Задачи не изменились, это все такая же карта, но отличаются они кардинально.
Точно? Я помню мобильные гугл-карты для symbian телефонов, без JS. Для передвижения карты были кнопки-ссылки по периметру. Каждое движение вызывало перезагрузку страницы. После 3-4 таких прокруток возникало желание закрыть браузер и посмотреть в бумажном атласе — быстрее будет.
JS однозначно улучшил удобство онлайн-карт.
JS однозначно улучшил удобство онлайн-карт.
Не спорю, улучшил, но я не за бинарную логику или запретить или все на JS. Я за что те же самые карты где без него ну никак были на JS, а там где есть возможность без него обойтись делали бы без него.
Было медленно и неудобно из за низкая скорость интернета. Сейчас если сделать грамотно на чистом HTML/CSS (SVG?), наверное будет быстрее чем на JS.
Не очень понятно как это получится. Как вы сделаете юзабельный drag-n-drop для карты без Javascript?
Было медленно потому, что загрузка синхронная, запросили один тайл влево, нельзя больше ничего трогать, пока страница с ним не прогрузится.
Теперь есть Javascript и Ajax, с которыми можно продолжать взаимодействовать со страницей (двигать карту в сторону), не дожидаясь полной загрузки.
Было медленно потому, что загрузка синхронная, запросили один тайл влево, нельзя больше ничего трогать, пока страница с ним не прогрузится.
Теперь есть Javascript и Ajax, с которыми можно продолжать взаимодействовать со страницей (двигать карту в сторону), не дожидаясь полной загрузки.
Справедливости ради, гугл-карты созданы не были. Созданы были keyhole-карты, а потом они уже были куплены гуглом. До сих пор, если смотреть в статусной строке, откуда грузятся тайлы, то это сервера kh01, kh02… Да и название формата kml из тех же источников.
Я считаю, что создавать сайты, способные работать без JS, вполне возможно. Я бы хотела серфить по сети, в которой вообще нет JavaScript. Черт, это мой выбор, как обычного пользователя!
Если вы готовы за это платить и вас таких достаточно много — то пожалуйста, «обычные пользователи». Всё будет.
В противном случае — неа. А статистика по юзерам из реальной жизни таки говорит нам, что во-первых таких людей достаточно немного, а во-вторых — платить они явно не собираются.
А ещё можно компьютер выключать и пытаться ходить в интернет без компьютера.
Перенос скриптов из головы в браузер и обратно вызывает много эмоций, но у тех кто не жил до первого этапа может не хватить аппаратного обеспечения для комбэка.
Отключение JS делится примерно на такие категории:
1. Давайте отрубим себе ногу и попробуем забраться на Эверест (сложные сервисы).
2. Давайте лишь прострелим себе ногу и сходим в магазин (новости, блоги).
Сайты из подборки в основном контентные (ну кроме Твиттера) и больше подходят ко второй категории. Вроде бы можно, но нафига?
Например, я периодически вожу бабушку на коляске в магазины. Мыло кто делает пандусы и во многих местах дорожка «так себе». Катаешь и материшься «почему не сделают все для инвалидов», а потом задумываешься с точки зрения бизнеса — а кому они нужны? (давайте только в мораль меня не тыкать, пожалуйста).
Пользователи без JS с точки зрения бизнес те же инвалиды. Можно под них подстраиваться, только зачем? Особенно если у вас какой-то динамический сервис, который реализовать без JS почти нереально — и зачем вам эти «js-инвалиды»?
1. Давайте отрубим себе ногу и попробуем забраться на Эверест (сложные сервисы).
2. Давайте лишь прострелим себе ногу и сходим в магазин (новости, блоги).
Сайты из подборки в основном контентные (ну кроме Твиттера) и больше подходят ко второй категории. Вроде бы можно, но нафига?
Например, я периодически вожу бабушку на коляске в магазины. Мыло кто делает пандусы и во многих местах дорожка «так себе». Катаешь и материшься «почему не сделают все для инвалидов», а потом задумываешься с точки зрения бизнеса — а кому они нужны? (давайте только в мораль меня не тыкать, пожалуйста).
Пользователи без JS с точки зрения бизнес те же инвалиды. Можно под них подстраиваться, только зачем? Особенно если у вас какой-то динамический сервис, который реализовать без JS почти нереально — и зачем вам эти «js-инвалиды»?
Проблема в том, что вы делаете вот эти ваши «динамические сервисы» не потому что в них существует такая потребность, а потому что это «стильно, модно, молодёжно» и вообще вы просто можете это сделать.
Вспомните нетбуки. Они появились именно как дешевое средство доступа в интернет, когда смартфоны и планшеты в массовых количествах просто отсутствовали. Так вот, сейчас доступ в интернет с нетбуков практически невозможен из-за чудовищного количества js. Причем речь не только о совсем древних atom'ах, но и практически о любых современных celeron'ах (всякие там gemini lake).
Вспомните нетбуки. Они появились именно как дешевое средство доступа в интернет, когда смартфоны и планшеты в массовых количествах просто отсутствовали. Так вот, сейчас доступ в интернет с нетбуков практически невозможен из-за чудовищного количества js. Причем речь не только о совсем древних atom'ах, но и практически о любых современных celeron'ах (всякие там gemini lake).
Зато отметьте, что с телефонов и планшетов интернет просматривают много людей и у них нет проблем как на нетбуках. Процессоры и система на них неоптимальны.
Проблемы есть. Вы никогда не пробовали что-нибудь купить с мобильного сайта недавно почившего ММ?) Я пробовал. Моё устройство с 4х1.8ГГц, 2 ГБ ОЗУ просто умирало на этом сайте, где господа девелоперы, вероятно, руководствовались трендом переноса всей тяжелой логики на фронт. И кроме этого говносайта таких сайтов десятки, сотни, тысячи. Либо бизнес-логику вынесут на фронт, либо мегабайты JS пришлют непонятно зачем, либо навешают рекламы так, что с ней устройство просто мрет.
Проблем нет, если есть отдельная мобильная версия или вовсе нативное приложение.
Странно, а как же мы жили до эры хайпа JS? До появления jQuery? Жили и по интернету ходили, а теперь вдруг резко — без JS никуда. Понимаю ленивенько это все, писать самому, а не фреймворками, но у всего своя цена.
Странно, как же мы жили до эры хайпа электричества — теперь можно умереть лизнув розетку.
Странно, как же мы жили до изобретения пороха — теперь можно остаться без руки по «счастливой» случайности.
Странно, как же мы жили без бытового газа — теперь можно подорвать 15-этажку одной спичкой.
Странно, как же мы жили без интернета — теперь можно сесть за фоточку в ВК.
Может проблема не в JS?
А, как выше написали про всякие Европы — проблема в людях?
Отключать JS ради отключения JS — глупо, как по мне.
Вы все равно захотите пользоваться чатиком без перезагрузки страницы или иметь возможность выделить человека на фото в ВК или листать Feedly с автоматической подгрузкой или обновлять комментарии на Хабре кнопочкой справа.
Странно, как же мы жили до изобретения пороха — теперь можно остаться без руки по «счастливой» случайности.
Странно, как же мы жили без бытового газа — теперь можно подорвать 15-этажку одной спичкой.
Странно, как же мы жили без интернета — теперь можно сесть за фоточку в ВК.
Может проблема не в JS?
А, как выше написали про всякие Европы — проблема в людях?
Отключать JS ради отключения JS — глупо, как по мне.
Вы все равно захотите пользоваться чатиком без перезагрузки страницы или иметь возможность выделить человека на фото в ВК или листать Feedly с автоматической подгрузкой или обновлять комментарии на Хабре кнопочкой справа.
Правильно, проблема не в js, а в том, что теперь на js делают и то, что раньше нельзя было сделать совсем (и это правильно), и то, что прекрасно можно сделать и без него. И особенно в том, что навешивается еще +100500 неведомой украшательной фигни, которая никак не влияет на качество контента (за которым мы и ходим в Сеть), зато греет душу дизайнеров (которых в основной массе мне хочется перебить сослать в Сибирь переквалифицировать в дворников) и жабаскриптеров в духе «смари как мы магём».
Отключать JS ради отключения JSЯ отключаю JS потому что некоторые «программисты» пишут по канонам "… як… як и в продакшен", а потом все это дело тормозит.
Вы все равно захотите пользоваться чатиком без перезагрузки страницы или иметь возможность выделить человека на фото в ВК или листать Feedly с автоматической подгрузкой или обновлять комментарии на Хабре кнопочкой справа.Ваше личное субъективное из пальца высосанное мнение.
Я отключаю JS потому что некоторые «программисты» пишут по канонам "… як… як и в продакшен", а потом все это дело тормозит.
Ага. Конечно. Объяснить почему? Потому что бюджет 5 тысяч, времени 3 дня и заказчик тебе в лицо говорит: «а зачем вам больше платить, там же делать нечего?»
Всё в мире программирования зависит от 3 факторов: мотивации, времени и квалификации. Если всего этого вдоволь, то можно написать и сайт без js на чистом css/html, если дело только в контенте. Вот только ведь заказчику нужно красиво, быстро, а главное, дёшево. Именно поэтому получаются сайты с мегатоннами js плагинов и миграторов от одной версии либы к другой (привет jq).
А есть вещи которые в априори невозможно сделать без js. Вот представьте себе, заходите на сайт дизайн-компании, а там вам предлагают сразу разрисовать вашу квартиру, а от вас требуется только 3 фотографии 2 стен. Круто неправда ли? Вот заказчик такие вещи хочет, и если создание 3d модели можно и на сервере сделать, то вот разрисовку этой модели делать на сервере — просто идиотизм.
Ну а если брать большие компании, то нужно понимать, что они знают сколько стоит каждая секунда загрузки страницы. Так что они максимально жмут всё, что только можно. Используют кеш везде, где только можно. Делают всё, что предусмотрено стандартами. Если таких пользователей без js, то есть таких как вы, меньше 3-4%, то они даже не подумают тратить на вас человекочасы.
До Вашего комментария не знал, что кнопочка справа — это обновить комментарии =) Обновлял комментарии кнопочкой F5.
Даже чаты были — новое сообщение и привет перезагрузка страницы. Хочешь обновить список чего-то — перезагружай всю страницу (а там уже не 8битные картинки 640x120 в шапке, а полноцветные под современные разрешения, ибо старые не завлекут платёжеспособную аудиторию), с кешем у всех беда (если сквид не подставить по дороге).
Лет… цать назад, во времена диалапа, чатики делались просто и аккуратно — на фреймах.
Вся страница не перезагружалась. Перезагружался фрейм с лентой сообщений — периодически, фрейм со списком юзеров — периодически, фрейм с формой отправки — по отправке. Все летало, причем на 28800 и на P1-133 о 16 метрах (не гигах!) памяти.
Но потом зародившимся сеорастам не понравилось, что тогдашние поисковики не умели во фреймы — и в итоге имеем, что имеем. Точнее, что нас имеет во все ресурсы…
Вся страница не перезагружалась. Перезагружался фрейм с лентой сообщений — периодически, фрейм со списком юзеров — периодически, фрейм с формой отправки — по отправке. Все летало, причем на 28800 и на P1-133 о 16 метрах (не гигах!) памяти.
Но потом зародившимся сеорастам не понравилось, что тогдашние поисковики не умели во фреймы — и в итоге имеем, что имеем. Точнее, что нас имеет во все ресурсы…
Я это прекрасно помню — я сам такое делал. Фреймы перезагружались целиком, даже при отсутствии новых сообщений (Фрейм — сам по себе страница и она перезагружалась целиком), для экономии (на 28800 вы были буржуям, некоторым достался 2400 с разрывами) и для уменьшения сбоев (страница могла недогрузиться) применялся 4й фрейм, который был пустым, зато перегружался часто и если было что-то новое, то он перезагружал соответствующий фрейм с отображением. Но это уже был так ненавидимый некоторыми JS.
на 28800 вы были буржуям, некоторым достался 2400 с разрывами
первый мамед был на 14400 ISA (98 год), второй, купленный в 2000 — сперва 28800, потом перешит на 57600. Сгорел при грозе году в 07, до сих пор рука не поднимается выкинуть… )))
Но это уже был так ненавидимый некоторыми JS.
Почему ненавидимый? Он хорош, когда его в меру. Но когда в странице js больше, чем хтмла просто потому, что афтар так может — возникает желание немножко ето попресекать… )))
Мне кажется, такая ситуация сложилась, в том числе, из-за того, что теперь сайты делают не верстальщики, а фронтенд разработчики. И, по большей части, это люди, которые не умеют верстать. Когда последний раз ходил на собеседования, из ~10 контор, только в двух задавали сложные вопросы по верстке. Обычно ограничивались вопросом про схлопывание отступов и от какой точки считается позиционирование. Зато примерно половина давала какие-то абстрактные задачи на js, которые вообще не имеют отношения к вебу.
В итоге получаем ситуацию, когда ради простой анимации на 10 кадров ставят отдельный npm-пакет, или когда тянут бутстрап в продакшн только ради сетки.
UPD. Из всех контор, в которые ходил на собеседование, только в одной был отдельно верстальщик. В остальных версткой занимался фронтенд разраб.
В итоге получаем ситуацию, когда ради простой анимации на 10 кадров ставят отдельный npm-пакет, или когда тянут бутстрап в продакшн только ради сетки.
UPD. Из всех контор, в которые ходил на собеседование, только в одной был отдельно верстальщик. В остальных версткой занимался фронтенд разраб.
НЛО прилетело и опубликовало эту надпись здесь
Если в современном мире делать все, что можно сделать версткой, на верстке без js:
- разметка станет стремной (оч сложно поддерживаемой)
- В некоторых случаях ренденринг будет медленным
- Напишут статью "я отключил css и у меня все залетало"
Вообще, без сарказма, лучше всего инет был, когда топ 100 сайтов работал в elinks.
А я до сих пор делаю сайты, которые всегда server-side first, а скрипты — просто приятное дополнение, которое может работать, а может и не работать. Меня постоянно обзывают тупым велосипедистом и отправляют учить тонны фреймворков.
НЛО прилетело и опубликовало эту надпись здесь
А разве это не так? IT-сообщество такое двуличное и мерзкое на поверку. С одной стороны все гнусят за обратную совместимость, необходимость поддержки устаревших технологий а-ля С++, выверенность стратегий развития, ответственность при принятии решений и всё такое; а с другой — всем на это давно наплевать, никто уже давно не задумывается о самых простых вещах, все считают, что у всех в мире бесплатный безлимитный стомегабитный канал, самое новое железо и куча свободного времени на ожидание загрузки их поделок. Ах да, попробовали бы вы, для начала, прежде чем говорить что всё это не так — скачать тот же chrome, имея на руках только links.
Справедливости ради отмечу, что ни одно мнение не может быть единственно правильным, но я за разумный подход в решениях о внешних зависимостях ПО, особенно в сторону их увеличения.
НЛО прилетело и опубликовало эту надпись здесь
С++ устаревший? Чего только смешного от этих фронтбекэнедеров не узнаешь.
> Понаблюдайте на плюсосрачи
А зачем? Можно просто использовать наиболее подходящий к задаче инструмент.
Не все сервисы могут жить без JS (тот же ютуб может разве что видеоролик на скачку отдать), а некоторые просто по соотношению затрат к выхлопу нецелесообразно делать с двойной поддержкой.
> Понаблюдайте на плюсосрачи
А зачем? Можно просто использовать наиболее подходящий к задаче инструмент.
Не все сервисы могут жить без JS (тот же ютуб может разве что видеоролик на скачку отдать), а некоторые просто по соотношению затрат к выхлопу нецелесообразно делать с двойной поддержкой.
Кажется, что если на сервере используется «канонический» изоморфный рендеринг, то сайт, если это какой-нибудь новостной ресурс или твиттер, будет более-менее для чтения работать и без всякого JS. На большее я бы не рассчитывал, конечно, например обычные формы без AJAX уже мало кто использует :).
НЛО прилетело и опубликовало эту надпись здесь
Все сильно зависит от реализуемого сервиса и, вообще говоря, ТЗ.
Не совсем понятно, о чём вы. «php/java/pyhton/etc» — это бекенд. «react/angular/vue» — это фронтенд. Технологии фронтенда никоим образом не мешают вам писать бекенд на чём угодно.
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется, что многие про такой способ уже и не знали никогда.
Не забыл, просто постановка вопроса странная — логичнее было бы спросить «чем лучше рендеринг и динамика на клиенте, чем рендеринг без динамики на сервере». Ваша формулировка звучала странно, поэтому решил уточнить.
Рендеринг на сервере никто не мешает делать, во многих случаях он и делается (например, у букинга идёт рендеринг на сервере с фоллбэком на клиентский рендеринг. При этом они, насколько я помню, используют реакт).
Так что вопрос скорее в том, зачем нужна джаваскриптовая динамика.
Навскидку могу сказать примерно следующие общие пункты:
1) Если у вас есть куча вариантов отображения контента и работы с ним (например, фильтрации), то делать на каждый чих запрос на бэк — боль.
2) Если у вас есть графики, то конечно можно рисовать их на бэке… Но всякое там масштабирование и фильтрация — опять же отдельные запросы на перерисовку — боль.
3) Чем меньше запросов на бек, тем меньше вероятности того, что что-то отвалится. Оптимально, если после загрузки у вас получается приложение, которое вообще не работает с беком, и независимо от наличия интернета.
4) Динамика позволяет догружать на страницу данные. Если вы их не можете ни догрузить ни отобразить, то показывать всё можно только одним куском — что во многих случаях тоже слишком больно. Опять же, JS позволяет грузить куски данных и кода постепенно, чего вы тоже не получите при классическом подходе.
5) Да, часть всякой красоты на клиенте можно реализовать на альтернативных технологиях — но многие из них до сих пор поддерживаются хуже, чем JS.
6) Есть такая волшебная штука как React Native. Она позволяет бодро сделать хорошее и отзывчивое мобильное приложение. В случае, если у вас этого нет — писать надо будет всё с нуля и исключительно на нативном языке платформы. Время, боль, дополнительные разработчики, разная кодовая база.
7) Во многих случаях «переложить работу на клиента» сильно экономит вам мощности, которые вы бы иначе тратили на тривиальные операции. Один клиент не заметит того, что у него выполняется мелкий JS, а вот миллион клиентских операций, которые вычисляются на сервере — это дорого.
В общем, всё очень сильно зависит от того, что вы делаете, как сказали выше.
Если у вас блог или новостная лента — то в целом можно обойтись и без JS. Тот же вашингтон пост и википедия тому примером (хотя без JS там не будет работать редактор статей). Кстати, возможно, вы удивитесь, но статические сайты без JS тоже собираются при помощи JS экосистемы — всякие генераторы статики, стилей, ресайзеры и прочий вебпак.
Если у вас куча динамики, технологий завязанных на динамику, или графики — то здесь без JS вам будет слишком грустно и больно. Как пример — карты, youtube, netflix, или моя компания — onetwotrip.
Рендеринг на сервере никто не мешает делать, во многих случаях он и делается (например, у букинга идёт рендеринг на сервере с фоллбэком на клиентский рендеринг. При этом они, насколько я помню, используют реакт).
Так что вопрос скорее в том, зачем нужна джаваскриптовая динамика.
Навскидку могу сказать примерно следующие общие пункты:
1) Если у вас есть куча вариантов отображения контента и работы с ним (например, фильтрации), то делать на каждый чих запрос на бэк — боль.
2) Если у вас есть графики, то конечно можно рисовать их на бэке… Но всякое там масштабирование и фильтрация — опять же отдельные запросы на перерисовку — боль.
3) Чем меньше запросов на бек, тем меньше вероятности того, что что-то отвалится. Оптимально, если после загрузки у вас получается приложение, которое вообще не работает с беком, и независимо от наличия интернета.
4) Динамика позволяет догружать на страницу данные. Если вы их не можете ни догрузить ни отобразить, то показывать всё можно только одним куском — что во многих случаях тоже слишком больно. Опять же, JS позволяет грузить куски данных и кода постепенно, чего вы тоже не получите при классическом подходе.
5) Да, часть всякой красоты на клиенте можно реализовать на альтернативных технологиях — но многие из них до сих пор поддерживаются хуже, чем JS.
6) Есть такая волшебная штука как React Native. Она позволяет бодро сделать хорошее и отзывчивое мобильное приложение. В случае, если у вас этого нет — писать надо будет всё с нуля и исключительно на нативном языке платформы. Время, боль, дополнительные разработчики, разная кодовая база.
7) Во многих случаях «переложить работу на клиента» сильно экономит вам мощности, которые вы бы иначе тратили на тривиальные операции. Один клиент не заметит того, что у него выполняется мелкий JS, а вот миллион клиентских операций, которые вычисляются на сервере — это дорого.
В общем, всё очень сильно зависит от того, что вы делаете, как сказали выше.
Если у вас блог или новостная лента — то в целом можно обойтись и без JS. Тот же вашингтон пост и википедия тому примером (хотя без JS там не будет работать редактор статей). Кстати, возможно, вы удивитесь, но статические сайты без JS тоже собираются при помощи JS экосистемы — всякие генераторы статики, стилей, ресайзеры и прочий вебпак.
Если у вас куча динамики, технологий завязанных на динамику, или графики — то здесь без JS вам будет слишком грустно и больно. Как пример — карты, youtube, netflix, или моя компания — onetwotrip.
React это кстати как раз серверный рендеринг. Запускается полноценный сервер nodejs который рендерит страницы. Просто на реакте мало кто пишет api например, хотя это реально.
Дешевле.
Для начала замечу, что одно не мешает другому — фронтенд может быть весь на React, но ведь кроме фронтенда нужно и с базой общаться, например и здесь нужны php/java/python/…
У меня тоже был период бунтарства и пуризма и я пробовал писать вручную SQL, делать всё на чистых формах, но я так скажу: HTML и CSS — гораздо большее говно, чем JS сам по себе.
Если нужны буквально 1-2 формы, то легче написать обычные формы.
Если проект разрастается до десятков форм, то легче сделать на Vue или чём-то типа этого.
Когда валидация разных типов данных в формах на клиенте становится рутиной, когда вдруг нужно использовать не только GET и POST, то лучше зайти на фреймворк.
Для начала замечу, что одно не мешает другому — фронтенд может быть весь на React, но ведь кроме фронтенда нужно и с базой общаться, например и здесь нужны php/java/python/…
У меня тоже был период бунтарства и пуризма и я пробовал писать вручную SQL, делать всё на чистых формах, но я так скажу: HTML и CSS — гораздо большее говно, чем JS сам по себе.
Если нужны буквально 1-2 формы, то легче написать обычные формы.
Если проект разрастается до десятков форм, то легче сделать на Vue или чём-то типа этого.
Когда валидация разных типов данных в формах на клиенте становится рутиной, когда вдруг нужно использовать не только GET и POST, то лучше зайти на фреймворк.
НЛО прилетело и опубликовало эту надпись здесь
uMatrix-плагин для браузера позволяет гибко и удобно отключать загрузку произвольных ресурсов на сайте, без необходимости отключать js целиком. Рекомендую!
LYNX уже обсуждали?
Одно время пробовал. Чудеснейше всё летает, заодно и без графики :). Даже гуглокапча позволяла решить её альтернативным образом. Правда с непривычки нереально сложно с непривычными хоткеями работать, но....
На мой взгляд, проблема кроется в скудных средствах взаимодействия HTML страницы и сервера. Если убрать JS, что у нас останется? POST и GET запросы. Даже такие вещи, как PUT и DELETE реализованы только в XMLHttpRequest, т.е. без JS недоступны. И так, у нас есть POST и GET. Оба метода перезагружают страницу целиком. Оба можно отправить по нажатию кнопки submit. GET запрос ещё можно запихнуть в ссылку. Всё. Как-то мало для современного веб приложения. Эта часть веб технологий словно застряла в девяностых. Именно поэтому, JS из инструмента для прикручивания всяких свистелок, превратился в основу современного веба.
Что с этим можно сделать? Как минимум, браузеры могли бы предоставить возможность отправлять submit асинхронно, оставаясь на текущей странице. А ещё, не лишней была бы возможность обновлять не всю страницу, а отдельно указанную часть документа. Сейчас всё это делается с помощью JS, но что мешает сделать такой функционал доступным без скриптов? Добавляем форме атрибут «async», и вот её submit уже не перезагружает страницу. А в ответе сервер указывает каким-нибудь образом, например с помощью селекторов, аналогичных используемых в CSS, куда именно в документ вставлять ответ, и как его вставлять: заменить текущее содержимое, или дополнить. Эти две функции уже решают огромный ворох задач, которые сегодня без скриптов не решить.
Что ещё можно добавить полезного? Пожалуй, веб сокеты. Ничто ведь не мешает браузеру, по просьбе сервера, начать слушать входящий поток данных. Как только данные пришли, обрабатываем их аналогично ответу на запрос, т.е. вставляем их в указанное место документа, либо, если это наоборот сервер просит что-то прислать, отправляем запрошенную часть документа серверу. Вот и всё. Ничего сложного.
Остаётся последняя часть мозаики — события. Одних submit'ов по нажатию кнопки мало. Необходимо добавить возможность отправлять submit по другим событиям: клики по любым элементам, смена фокуса, скроллинг, таймеры, обновление содержимого, ответ, либо сообщение через веб сокет от сервера и т.д. В принципе, ничего сложного в этом тоже нет. Конечно, некоторые события стоит оптимизировать с учётом того, что они будут обрабатываться на сервере. Тот же скроллинг, наверное, не имеет смысла непрерывно отслеживать, как это реализовано в JS. Скорее всего, нас заинтересует момент, когда прокрутка дошла до определённого элемента. На самом деле, это и в JS не помешало бы. В общем, систему событий конечно надо продумывать, она должна быть гибкой, и учитывать специфику.
Короче говоря, браузеру нужно реализовать логику коммуникаций клиента с сервером, с учётом современных реалий: асинхронные запросы, обновление части документа, поддержка постоянного соединения с сервером, гибкая событийная система. Тогда вся остальная логика сможет переползти на сервер. Можно будет писать SPA, такие как GMail, вообще без JS. А скрипты останутся для всяких вспомогательных вещей: как способ что-то оптимизировать, разгрузить сервер, улучшить отзывчивость и т.д. Ещё останутся такие вещи как webgl и canvas. Но это нужно далеко не всем сайтам. В любом случае, такой острой проблемы, как сейчас не будет. Станет вновь возможен принцип graceful degradation. Сейчас он во многом забыт, из-за того, что современный сайт со скриптами (даже не SPA), и сайт на ссылках и POST запросах — это два разных сайта. Между ними, зачастую нечего выделить в качестве общей базы, т.к. различие идёт с самого начала на уровне архитектуры. Способ взаимодействия с пользователем кардинально разный.
Что с этим можно сделать? Как минимум, браузеры могли бы предоставить возможность отправлять submit асинхронно, оставаясь на текущей странице. А ещё, не лишней была бы возможность обновлять не всю страницу, а отдельно указанную часть документа. Сейчас всё это делается с помощью JS, но что мешает сделать такой функционал доступным без скриптов? Добавляем форме атрибут «async», и вот её submit уже не перезагружает страницу. А в ответе сервер указывает каким-нибудь образом, например с помощью селекторов, аналогичных используемых в CSS, куда именно в документ вставлять ответ, и как его вставлять: заменить текущее содержимое, или дополнить. Эти две функции уже решают огромный ворох задач, которые сегодня без скриптов не решить.
Что ещё можно добавить полезного? Пожалуй, веб сокеты. Ничто ведь не мешает браузеру, по просьбе сервера, начать слушать входящий поток данных. Как только данные пришли, обрабатываем их аналогично ответу на запрос, т.е. вставляем их в указанное место документа, либо, если это наоборот сервер просит что-то прислать, отправляем запрошенную часть документа серверу. Вот и всё. Ничего сложного.
Остаётся последняя часть мозаики — события. Одних submit'ов по нажатию кнопки мало. Необходимо добавить возможность отправлять submit по другим событиям: клики по любым элементам, смена фокуса, скроллинг, таймеры, обновление содержимого, ответ, либо сообщение через веб сокет от сервера и т.д. В принципе, ничего сложного в этом тоже нет. Конечно, некоторые события стоит оптимизировать с учётом того, что они будут обрабатываться на сервере. Тот же скроллинг, наверное, не имеет смысла непрерывно отслеживать, как это реализовано в JS. Скорее всего, нас заинтересует момент, когда прокрутка дошла до определённого элемента. На самом деле, это и в JS не помешало бы. В общем, систему событий конечно надо продумывать, она должна быть гибкой, и учитывать специфику.
Короче говоря, браузеру нужно реализовать логику коммуникаций клиента с сервером, с учётом современных реалий: асинхронные запросы, обновление части документа, поддержка постоянного соединения с сервером, гибкая событийная система. Тогда вся остальная логика сможет переползти на сервер. Можно будет писать SPA, такие как GMail, вообще без JS. А скрипты останутся для всяких вспомогательных вещей: как способ что-то оптимизировать, разгрузить сервер, улучшить отзывчивость и т.д. Ещё останутся такие вещи как webgl и canvas. Но это нужно далеко не всем сайтам. В любом случае, такой острой проблемы, как сейчас не будет. Станет вновь возможен принцип graceful degradation. Сейчас он во многом забыт, из-за того, что современный сайт со скриптами (даже не SPA), и сайт на ссылках и POST запросах — это два разных сайта. Между ними, зачастую нечего выделить в качестве общей базы, т.к. различие идёт с самого начала на уровне архитектуры. Способ взаимодействия с пользователем кардинально разный.
То есть вы предлагаете расширить html, чтобы там было больше атрибутов и параметров для более гибкой конфигурации.
Можно будет писать SPA, такие как GMail, вообще без JS
То есть вместо тонны Javascript у нас будет тонна HTML. Не уверен, что это хорошая замена. Как отлаживать этот html? А если недостает какой-то фичи, то придется переписывать обратно на Javascript?
Откуда возьмётся тонна HTML? Логика будет на бэкенде. В том числе логика формирования HTML. Клиент получает готовую разметку. Единственное, что добавляется в HTML — это один атрибут для форм (async=true). Впрочем, может он и не у формы должен быть, а у того, кто инициирует отправку, например у кнопки submit. Что касается назначения обработчиков событий для элементов DOM, мне кажется что тут будет уместней отдельный формат, наподобие CSS, описывающий связь событий и обработчиков с элементами DOM, через селекторы. Этакая каскадная таблица событий (CES). Во-первых это разделит вёрстку и логику, во вторых позволит назначать события сразу нескольким элементам, в-третьих не будет путаницы с уже существующими атрибутами onclick, onload и т.д. Сохраняется обратная совместимость. Можно кстати и вовсе отойти от форм, и оперировать понятием запрос. Любые элементы DOM, можно привязывать к запросам через каскадные таблицы запросов (CQS). Какие элементы страницы будут включены в запрос, какие будут обновлены, при получении ответа и какими данными — всё это можно описывать в отдельных файлах по таким же принципам, что и таблицы стилей. Селекторы будут те же, только свойства задаются другие.
Впрочем, это всё детали реализации, которые я предложил просто навскидку. Можно придумать и что-то получше. Основная идея — научить HTML работать асинхронно с динамически меняющимися данными, без использования JavaScript. Без этих возможностей, говорить о серьёзном снижении объёмов JS кода просто бессмысленно. Есть ли в этом вообще смысл? Как показывает статья и комментарии к ней, многие считают что есть. Лично мне JS нравится, и я, как программист, не заинтересован в снижении его востребованности. Просто описал необходимый, на мой взгляд, минимум возможностей HTML, при котором я в принципе могу задуматься о разработке чего-то серьёзного без JS.
Впрочем, это всё детали реализации, которые я предложил просто навскидку. Можно придумать и что-то получше. Основная идея — научить HTML работать асинхронно с динамически меняющимися данными, без использования JavaScript. Без этих возможностей, говорить о серьёзном снижении объёмов JS кода просто бессмысленно. Есть ли в этом вообще смысл? Как показывает статья и комментарии к ней, многие считают что есть. Лично мне JS нравится, и я, как программист, не заинтересован в снижении его востребованности. Просто описал необходимый, на мой взгляд, минимум возможностей HTML, при котором я в принципе могу задуматься о разработке чего-то серьёзного без JS.
Вы как себе представляете объявления, куда конкретно вписывать результаты запроса сервера? Как вы себе представляете эти самые результаты ответа? Ведь в документ можно вставлять только готовый html, а те же комментарии на хабре состоят из 14-20 тегов (реально, вот конкретно ваш коммент тянет в чистом виде на столько тегов, это без внутреннего форматирования текста).
Слишком много совершенно новых технологий, в которых нет никакой нужды, вам так не кажется?
Кх-кх… Hyper Text Matching Language. Есть такое понятие как разделение ответственности. Не надо из html делать язык с декларативной логикой обработки запросов. Его задача — объяснить отрисовщику где заголовок, а где список с точечками, где абзац, а где ссылочка. Ему реальнонасрать на существование запросов как таковых не нужно ничего больше. Наличие в нём форм и правил валейдации в них уже достаточное отхождение от изначальной задачи.
Не стоит забывать, что хабр (и другие технические ресурсы) — сборище гиков. Каждый из которых выпендривается как может.
Как показывает реальная статистика — пользователям глубоко фиолетово как оно на самом деле работает. Для них главное — выполнение задачи. Если бы им реально было интересно и нужно делать что-то оптимально, то браузеры бы были просто отрисовщиками форм для CRUD сервисов, и никаких бы css не было бы и в помине.
Единственное, что добавляется в HTML — это один атрибут для форм (async=true).А как вы браузеру скажите куда вставлять результаты запросов? Значит ещё 1 аттрибут. А как вы браузеру скажите, чтобы он брал конкретное это событие onscroll и загружал конкретно этот запрос? Ну логично это сделать вообще через теги, так хоть читаться будет. Но у xml есть такая неприятная вещь, как малая читабельность и overkill по сравнению с тем же json.
Этакая каскадная таблица событий (CES)То есть тот же самый js, только урезанный по самые яйца.
CQS, CES
Слишком много совершенно новых технологий, в которых нет никакой нужды, вам так не кажется?
HTML работать асинхронно с динамически меняющимися данными
Кх-кх… Hyper Text Matching Language. Есть такое понятие как разделение ответственности. Не надо из html делать язык с декларативной логикой обработки запросов. Его задача — объяснить отрисовщику где заголовок, а где список с точечками, где абзац, а где ссылочка. Ему реально
Есть ли в этом вообще смысл? Как показывает статья и комментарии к ней, многие считают что есть.
Не стоит забывать, что хабр (и другие технические ресурсы) — сборище гиков. Каждый из которых выпендривается как может.
Как показывает реальная статистика — пользователям глубоко фиолетово как оно на самом деле работает. Для них главное — выполнение задачи. Если бы им реально было интересно и нужно делать что-то оптимально, то браузеры бы были просто отрисовщиками форм для CRUD сервисов, и никаких бы css не было бы и в помине.
Вы как себе представляете объявления, куда конкретно вписывать результаты запроса сервера?
Ну своё видение я описал. Каскадные таблицы. Плюсов достаточно много. Декларативность. Реактивность. Да и фронтендерам такой подход хорошо знаком.
В принципе, сервер мог бы и вручную в каждом ответе указывать с помощью селекторов, куда и чего вставлять. Но это не рационально, т.к. при правильной архитектуре приложения, ответы на один и тот же тип запроса будут помещаться в документ по одной и той же схеме, а не хаотично.
То есть тот же самый js, только урезанный по самые яйца.
По функционалу, а не по архитектуре. Изначально я описал возможности, которые позволили бы обходится без JS, с сохранением функционала. Естественно, что эти возможности будут дублировать часть функциональности JS. Это очевидное следствие. Чему тут удивляться? Что же до урезанности, то тут как посмотреть. Порой надо ограничиться ровно тем набором средств, который является необходимым и достаточным. Больше не всегда лучше. Цель реализовать все возможности JS не ставилась. Наоборот, ставилась цель реализовать лишь необходимый минимум, чтобы всё лишнее уехало на сервер, а качество GUI не пострадало.
Слишком много совершенно новых технологий, в которых нет никакой нужды, вам так не кажется?
Мой изначальный комментарий был как раз о том, что отказаться от JS, не заменив чем-нибудь другим, хотя бы самые критические из выполняемых им функций, невозможно. Что-то новое добавлять придётся в любом случае. Были времена, когда использование JS было дурным тоном. Но судить сегодняшних разработчиков по тем старым понятиям не справедливо. Потому что альтернативы нет. Я мог бы просто раскритиковать браузеры за отсутствие таких альтернатив. Но критика без предложений бесплодна, и такой критики, в данной теме, уже было предостаточно.
Hyper Text Matching Language. Есть такое понятие как разделение ответственности. Не надо из html делать язык с декларативной логикой обработки запросов. Его задача — объяснить отрисовщику где заголовок, а где список с точечками, где абзац, а где ссылочка.
Вообще-то «M» это Markup. И я как раз предложил декларативную логику положить рядом, в отдельных каскадных таблицах, а не включать её в HTML. В такой реализации даже атрибут async не нужен. Впрочем, давно уже пора признать, что HTML сейчас используется не так, и не для того, для чего он изначально задумывался. Вместо языка разметки документов он стал языком описания интерфейса. А интерфейс, в отличие от документа, содержит некоторую логику. События — часть этой логики. Документу они действительно не нужны. Документ состоит из параграфов, списков, заголовков — вот этого всего. И тут важно описать внешний вид и расположение. А интерфейс состоит из кнопок, выпадающих списков, полей ввода и т.д. Эти сущности без событий бесполезны. Кнопка должна что-то делать при нажатии на неё. Выбор элемента из выпадающего списка должен на что-то влиять, например на набор предлагаемых вариантов в соседнем списке — это вообще классика. И вот это всё без JS сегодня не сделать, т.к. в HTML, соответствующих возможностей так и не завезли, хотя использовать его для описания интерфейсов начали более десятка лет назад.
Не стоит забывать, что хабр (и другие технические ресурсы) — сборище гиков. Каждый из которых выпендривается как может.
Ну может кто-то и выпендривается. Это неизбежные издержки. Многим программистам это свойственно. Без этого ни одно обсуждение не обходится. Спокойно воспринимать подобные вещи — жизненно необходимый навык в нашей профессии. Да и где мне ещё обсуждать HTML и JS, как не на технических ресурсах? На форуме дачников?
Как показывает реальная статистика — пользователям глубоко фиолетово как оно на самом деле работает. Для них главное — выполнение задачи.
Пользователи вынуждены жрать что дают. Но они определённо будут рады, если сайт будет работать шустрее, батарейки в смартфоне будет хватать на дольше и т.д. А потому мы должны продолжать развивать наши технологии и методы разработки. Подобные обсуждения — часть процесса. Даже неудачная идея может натолкнуть кого-то на более удачную. Так развивается мысль. Поэтому не вижу смысла замалчивать идею, если он пришла мне в голову, и выглядит интересной.
Ну своё видение я описал.Мнение я ваше услышал и читал я всю ветку, так что первый комментарий я тоже помню. Ваше видение заключается не в модернизации текущей схемы доставки документов, а в создании принципиально новой схемы доставки контента и логики на совершенно других движках и с совершенно другим подходом к разработке, меня это убивает.
Ведь сейчас js даёт некую функциональную базу и базовые api, на основе которых можно реализовать все ваши подсистемы на уже существующем js, просто написав свой фреймворк :D
Я поделюсь своим мнением на этот счёт. Раньше были диафильмы и бумага для представления данных, считали всё люди. Потом человеку стало лениво, и он придумал счёты, дальше перескакиваем через несколько поколений счётных машин и приходим к изобретению ЭВМ. Дальше оказывается, что в них можно ещё и другие вещи загрузить и они могут текст показывать…
Думаю вектор мысли вы поняли. Я представляю себе js для веба как asm для процессоров. Есть платформа и стандартные функции. Дальше человеку хочется от этой платформы новых функций и он их расширяет с помощью либо использования комплекса старых, либо в корне меняя поведение платформы.
Сейчас js, а точнее es, развивается для того, чтобы стать как раз родительской платформой для других. Поэтому к нему я отношусь как к asm. Может когда-нибудь и сдохнет, но явно не скоро, но необходимые базовые функции он предоставить может, а на них можно сделать другую платформу, например с вашими технологиями. Для начала сделав их в виде фолбека на js, а потом уже и реализовав стандартные оптимизированные api в самом браузере.
Таким вот макаром сейчас в веб приходят как раз веб-компоненты. Сделали их реализацию на js, всем понравилось, все решили сделать это сахарком.
Ну может кто-то и выпендривается. Это неизбежные издержки. Многим программистам это свойственно.Я имею в виду, что выборка мнений в комментах и статье далеко не репрезентативная, так как все эти мнения основываются на технических знаниях, а реальные пользователи такими знаниями не обладают.
Пользователи вынуждены жрать что даютIT — сфера монополизированная. Конечный пользователь, не понимая что к чему, просто не может заявить, что хочет жрать что-то другое. В авто тоже разбираются не все поголовно, поэтому тренды задают (читай «дают жрать») именно производители.
они определённо будут рады, если сайт будет работать шустрееРады то они будут. Вот только им никто не даст такого, пока это не будет приносить деньги.
То есть вместо одной сущности (javascript) предлагается реализовать несколько новых (таблицы событий, запросов)? А в чем смысл? Просто чтобы не было Javascript? Так еще не факт, что подобное решение окажется достаточно производительным.
>каскадная таблица событий (CES)
С возможностью переписывания самой себя, т.е. тьюринг-полная. После чего вам на этакой каскадной таблице быстренько сделают компилятор из JS в неё, и всё станет по-прежнему, да ещё тормознее.
Тут с другой стороны заходить надо. Например, от экологии «ваши сайты жрут слишком много энергии, приходится слишком часто подзаряжать телефон, от этого большой ущерб природе и нерациональная трата ресурсов. А давайте-ка мы вас за это начнём штрафовать на уровне хостеров, безакцептными списаниями с баланса у хостера».
С возможностью переписывания самой себя, т.е. тьюринг-полная. После чего вам на этакой каскадной таблице быстренько сделают компилятор из JS в неё, и всё станет по-прежнему, да ещё тормознее.
Тут с другой стороны заходить надо. Например, от экологии «ваши сайты жрут слишком много энергии, приходится слишком часто подзаряжать телефон, от этого большой ущерб природе и нерациональная трата ресурсов. А давайте-ка мы вас за это начнём штрафовать на уровне хостеров, безакцептными списаниями с баланса у хостера».
Напоминает сайты на
ifrаme...
… Куда то деламь кнопка редактирования, а хабр вырезал запретное слово
Это точно не то что я себе представлял, когда писал комментарий выше. Можно ведь сделать всё по уму. Разметку можно не засорять, а вынести назначение всех дополнительных атрибутов в отдельные каскадные таблицы. Рендеринг на сервере.
Реализации могут быть разными. Насколько всё это будет масштабируемо, мне сейчас тяжело сказать, т.к. это была просто шальная мысль, даже толком не продуманная. При грамотном подходе может и выйдет что-то толковое.
А iframe это из разряда костылей. Впрочем, весь веб соткан из заплаток и стоит на костылях. Такая уж у него судьба.
Реализации могут быть разными. Насколько всё это будет масштабируемо, мне сейчас тяжело сказать, т.к. это была просто шальная мысль, даже толком не продуманная. При грамотном подходе может и выйдет что-то толковое.
А iframe это из разряда костылей. Впрочем, весь веб соткан из заплаток и стоит на костылях. Такая уж у него судьба.
Очень жаль, что в стандарте никогда не было способа встроить iframe без, собственно, фрейма, чтобы дочерний документ занимал сколько надо места, а не предопределённое прямоугольное пространство; ну и родительские CSS применялись. Т.е. нормальный include.
Был атрибут seamless от которого отказались. Почему не понятно.
Все уже обосрали js за то, что он грузит большие объёмы данных на клиент. Все обосрали js за то, что он долго работает. Все обосрали программистов за то, что они делают изначально на js, а не на чистом и кандовом pure html/css.
Ну что же. Только вот все забывают про то, что есть технологии кеширования, которые грузят js 1 раз и используют потом его же. Дальше уже считаем для каждого ресурса отдельно — каждая страничка по 400 килов на КАЖДЫЙ клик, или 500 килов js и 100 килов на подгрузку самого контента на каждой страничке.
Писать на чистом html css в разы больнее и дольше, чем на js. Для заказчика ещё и дороже, потому что найти верстальщика, реально знающего все чудности css и всю спецификацию html (не просто так придумали haml, sass и иже с ними) сложнее и дольше, чем фронтэндера с нормальной квалификацией, который может обойти все затыки css и сделать читаемый сайт. Заказчика не волнует на чём будет сделано, у него самым главным критерием всегда являются деньги. Пока сайт работает и заказчику не хочется ещё больше денег, он даже не задумается об оптимизации.
Так же нужно не забывать про рекламу. Если вы отключаете рекламу (допустим отключив js), то вы лишаете дохода производителя контента. Если вы лишаете дохода производителя контента, то он имеет полное право не предоставлять вам контент вообще. Ведь все делают работу, чтобы получить что-то от этого. Если производитель контента это делает для своего эго, то ему главное показать вам контент в любом случае. Если производитель контента хочет иметь хлеб на столе и воду в кране, то он будет продавать свой контент, ведь это его работа, лично руками и головой сделанная.
Ну что же. Только вот все забывают про то, что есть технологии кеширования, которые грузят js 1 раз и используют потом его же. Дальше уже считаем для каждого ресурса отдельно — каждая страничка по 400 килов на КАЖДЫЙ клик, или 500 килов js и 100 килов на подгрузку самого контента на каждой страничке.
Писать на чистом html css в разы больнее и дольше, чем на js. Для заказчика ещё и дороже, потому что найти верстальщика, реально знающего все чудности css и всю спецификацию html (не просто так придумали haml, sass и иже с ними) сложнее и дольше, чем фронтэндера с нормальной квалификацией, который может обойти все затыки css и сделать читаемый сайт. Заказчика не волнует на чём будет сделано, у него самым главным критерием всегда являются деньги. Пока сайт работает и заказчику не хочется ещё больше денег, он даже не задумается об оптимизации.
Так же нужно не забывать про рекламу. Если вы отключаете рекламу (допустим отключив js), то вы лишаете дохода производителя контента. Если вы лишаете дохода производителя контента, то он имеет полное право не предоставлять вам контент вообще. Ведь все делают работу, чтобы получить что-то от этого. Если производитель контента это делает для своего эго, то ему главное показать вам контент в любом случае. Если производитель контента хочет иметь хлеб на столе и воду в кране, то он будет продавать свой контент, ведь это его работа, лично руками и головой сделанная.
Кеширование то кеширует, а твиттор у меня на мобилке стабильно загружается только со второго раза.
есть технологии кеширования, которые грузят js 1 раз
Ну да.
Давайте вспомним отличную легенду, что, используя загрузку привычных и часто используемых библиотек вроде jquery с общественных cdn, мы экономим время загрузки, т.к. эти файлы берутся из кеша браузера. Вы сами соберите статистику, сколько версий только jquery только с одного cdn вы за сутки грузите своим браузером, и осознайте, что они все уже изрядный кусок кеша забивают (или вылезают из него, если говорить о мобилке). А cdn не один, а библиотечка не одна (и каждая — минимум min и «просто», да еще версий по 20, да еще по http и по https). При этом, по данным моего браузера, использование внешних библиотек не только не ускоряет, а часто замедляет загрузку сайтов.
Я к тому, что вера в кеширование должна быть основана на понимании, что кеши уже давно маловаты для всего того
Ну я говорю именно про нормальные SPA, которые как раз без js не работают совсем и которые делят бандлы на чанки и обновляют чанки в кешах. Последнее конечно только у вменяемых магов webpack получается, но не суть, на то они и НЕ горе-программисты. А вы про jq.
JQ — болезнь мелкого порога вхождения. Ведь вставить на wordpress ещё одну версию JQ для карусельки — святое дело, для любого фрилансера, которого заказчик попросил сделать что-то сложнее стандартного шаблона.
Нужно точно так же как и на рынке пластмассовых игрушек уметь разделять нормальные шахматы от китайских ложко-открывашек и слонозавров. На простые сайты есть спрос, и как ни странно, эти простые сайты генерируют самый оригинальный контент в интернете. Вот только у них нет денег сделать всё по феншую, вот они и делают как могут и как сами понимают. Захотели комментарии — нашли в интернете готовый just paste html — вставили и радуются. Появилась потребность в нормальном чате, подходящим по дизайну и со своими собственными фичами — вот тут уже и задумываются о том, как бы сделать всё хорошо, но всё равно дёшево и сердито. И только когда дело доходит до условных 5 нулей в ежемесячном обороте, задумываются о конверсии кнопок и цветов, о скорости загрузки и логичности ux.
JQ — болезнь мелкого порога вхождения. Ведь вставить на wordpress ещё одну версию JQ для карусельки — святое дело, для любого фрилансера, которого заказчик попросил сделать что-то сложнее стандартного шаблона.
Нужно точно так же как и на рынке пластмассовых игрушек уметь разделять нормальные шахматы от китайских ложко-открывашек и слонозавров. На простые сайты есть спрос, и как ни странно, эти простые сайты генерируют самый оригинальный контент в интернете. Вот только у них нет денег сделать всё по феншую, вот они и делают как могут и как сами понимают. Захотели комментарии — нашли в интернете готовый just paste html — вставили и радуются. Появилась потребность в нормальном чате, подходящим по дизайну и со своими собственными фичами — вот тут уже и задумываются о том, как бы сделать всё хорошо, но всё равно дёшево и сердито. И только когда дело доходит до условных 5 нулей в ежемесячном обороте, задумываются о конверсии кнопок и цветов, о скорости загрузки и логичности ux.
Да, вы правы, маги могут и делают хорошо, но сайтов, сделанных магами — наверное, 1%, а 99% остальных — ад, содом и гомора кешевыносительные поделки. Которые, из-за своей массовости, легко выдавливают из кеша и чанки, сделанные магами.
сайтов, сделанных магами — наверное, 1%, а 99% остальных —Низкий порог входа даёт такой результат. Вы на улице попросите 10 мелких парней за 5000 рублей ножиком выточить фигурку шахматного коня. Возьмётся каждый, ножём дерево резать каждый умеет, вот только шанс того, что среди них попадётсяад, содом и гоморакешевыносительные поделки.
Решил я проверить один мой сайт в Midori и K-Meleon. Всё показывает и переключает кроме того за что отвечает JavaScript. И консоли в них не нашёл и ошибок как в сатаром IE не показывают. Просто не работает и всё.
Честно говоря, я поражен, что такая примитивная «нубская» статья вызвала такую волну обсуждений в комментариях… Хабр, ты ли это?
Проблема в том, что все достоинства JS эффективно нейтрализуются косорукостью JS девелоперов. 90% JS кода является "лазанья код" и работает только потому что компьютеры в 2018 невероятно, фантастично быстрые.
Без JS сайт NY Times загрузился за 561 мс, объем данных — 957 кб. Божечки, вот это вот мы и должны считать нормальным!
Объем страницы в ~1 мегабайт БЕЗ js? Должны считать нормальным? Нет, спасибо.
НЛО прилетело и опубликовало эту надпись здесь
Их бы в lazy-load не помешало отправить. Если мегабайт при полной прокрутке страницы — более-менее, согласен, но если то, что нужно для рендера первого экрана — очень плохо.
lazy-load без JS?
:) ок, признаю, погорячился.
Просто перешел от «1 мб без js» на «просто 1 мб», забыв про первоначальный посыл.
Просто перешел от «1 мб без js» на «просто 1 мб», забыв про первоначальный посыл.
Звучит как вызов. Я думаю с помощью чекбокса или радио можно сделать. Ну и hover конечно.
Ну а вдруг )
Ого. Много! Это серьезная проблема.… была 18 лет назад.
Не у всех в мире последний МакБук и 100 мбит с пингом 20мс, к сожалению. Мегабайт не только скачать, его еще и распарсить и показать надо. А четверть пользователей закрывают сайт, если он не откроется за 4-5 секунд. Так что да, это серьезная проблема, что 18 лет назад, что сейчас.
18 лет назад это была не проблема, а «сайт не работает».
Какой увлекательный вброс для срача в коментариях :3 Камменты доставили пуще Брежнева.
Два чая автору!
Вот еще неплохая идея — «День без… компьютера»
Два чая автору!
Вот еще неплохая идея — «День без… компьютера»
поиск Google работает без проблем.
Ну хорошо, автозаполнения нет, дизайн а-ля 2000-е
Выделение мое. Да, да, наконец-то можно увидеть то, что, собственно, и нужно видеть на странице поисковика. Лично я был бы рад видеть просто «дизайн а-ля 2000-е», и, похоже, нашелся элегантный способ!
А вот и идея стартапа «ностальгия» или «машина времени». Некая веб-прокся, отправляющая запросы на совремЁнные сайты и, получив ответы, оформляющая их так, как это смотрелось… лет назад. И показывающая самую малость рекламы, оформленной строго в духе запрошенного времени )))
И показывающая самую малость рекламы, оформленной строго в духе запрошенного времени
В тред входит html-тег marquee!
Так ладно, когда нужно чуть поправить разметку страницы, но ведь есть сайты, активно прячущие контент от желающих из просмотреть в no-js виде (либо распарсить). Инстаграмм как пример.
И, да, не успеешь такую проксю напилить (правда, монетеризация непонятна), как набегут копирасты, мол, вы наш контент воруете. Аггрегаторы новостей с такими наездами постоянно сталковаются, а ведь это конторы, на которые так просто и не наехать.
И, да, не успеешь такую проксю напилить (правда, монетеризация непонятна), как набегут копирасты, мол, вы наш контент воруете. Аггрегаторы новостей с такими наездами постоянно сталковаются, а ведь это конторы, на которые так просто и не наехать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Один день без JavaScript: что может пойти не так?