Как стать автором
Обновить

Комментарии 131

В каждой такой статье задаюсь вопросом: а зачем лепить функционал в CSS?

1. Ленивую загрузку, например, без JS вы не сделаете.
2. Аналогично. Шаг в сторону и прийдется вешать JS.
3. Как вы его вызовете из другого места? Ленивая загрузка опять же?
4. Свайп от левого края на CSS не отработаешь.
5-6. Снова шаг в сторону и каюк каруселям.

Все эти крутые штуки типа морды лица Гомера создаются просто по приколу. В остальных случаях JS выпоняет свою задачу на отлично, если конечно уметь им пользоваться.

Если сайту нужно свайп-меню, галерейка и модальные окна, на 99% можно быть уверенным, что для других серьезных задач понадобится JS. Тогда зачем городить этот огрод в неполоденном месте? :)
В каждой такой статье задаюсь вопросом: а зачем лепить функционал в CSS?
Затем, чтобы такие параноики, как я, могли пользоваться функционалом сайта без включения скриптов.

Впрочем, меню, реализованные на JS, меня совершенно не беспокоят: если страница адекватна и внушает доверие, то я просто включаю скрипты. Непрятности доставляют только сайты, которые вообще не рендерят контент без включения скриптов (при этом поисковикам отдают нормальные версии страницы).

при этом поисковикам отдают нормальные версии страницы

Не факт, сейчас многие поисковики выполняют JS, чтобы получить актуальную версию страницы.
Поисковики вроде теперь умеют в js, разве нет?
Сценариев много, навскидку: описание товаров на Ebay и других онлайн-аукционах. Ebay уже объявил, что в этом году будет блокировать JS, разрешая только HTML и CSS для страниц описания товаров.
Я как раз про это и говорю — CSS должно отвечать за визуализацию, а JS за функционал. У Ебея как раз все впорядке с таким подходом.
Разного рода меню, табы, слайдеры и карусели очень активно используются в описаниях товаров на Ebay. Теперь их придется реализовывать без JS.
Как минимум реализация табов на CSS проще чем на JS. Она не зависит от используемого JS-фреймворка/библиотеки одинаково хорошо работает как с серверным рендером так и с клиентским. Она не требует обертки директивой или компонентом под Angular или React, в отличие от jQuery плагинов. Эта реализация работает во всех браузерах уже лет 5 как, пережила jQuery, Prototype, Backbone и первый Angular. И у меня нет причин полагать, что не переживёт React и второй Angular.
Мир клином на jQuery, Prototype, Backbone и прочих не сошелся, реализуйте табы на нативном js (помните еще о таком?). И будет и во всех браузерах работать, и к фреймворкам не привязано, и счастье в семье.

Это просто примеры реализации, причем не требующие никаких больших трудозатрат во внедрении на сайт.
По поводу свайпов и тач событий — да, на css это не обработаешь.
"Шаг в сторону" — можно сказать про многое. В том числе и про js: другой скрипт может тормозить загрузку ваших скриптов; jquery обновилась, и каруселька сломалась и тд. (это чисто примеры).
Приведенные в статье варианты реализации можно использовать для каких-то конкретных случаев (хотя меню и модальное окно я использую и на рабочих проектах).
Модальное окно можно вызвать из любого места на странице. В описании к примеру написано, как это сделать.

1. 2. Когда нужно будет — повесить js на элемент будет не сложно.
3. Точно также как и функционал с js. Или тот уже html разметки не требует?
4.5. Бессмысленные аргументы. Там где нужен js — там пусть будет js, никто с этим не спорит.

Вводя в оборот понятие «Огород», почему вы имеете под ним ввиду именно css а не js?
Потому что прополку граблями не делают. Можно конечно, но зачем?
Так и функционал на CSS неделают. Тоже можно, но зачем?

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

Автор же пытается переделать на CSS то, что должен делать и прекрасно делает JS.
С таким же успехом можно аякс-отправку заказов сделать на CSS: input:checked + img {display:block;}
А в ссылке картинки указать скрипт на заказ. И в картинке отдавать текст «Заказ принят».
Работать будет, т.к. изначательно картинки с display:none не загружаются.
И вроде все хорошо, но нафига? Примеры автора просто слишком примитивны, но в реальном применении такое не прокатит.
картинки с display:none не загружаются

Немного не верно. Следует уточнить, что они загружаются, если представлены в виде img, но не загружаются если установлены через background.
Хм, ну я не экспериментировал на современных браузерах, но точно помню, что пару лет назад именно img {display:none} не загружалось. Как минимум в Opera
НЛО прилетело и опубликовало эту надпись здесь
Например для даркнета, где пользователям предлагают отключать js.
Я думаю мы говорим об обычном интернете :)

Считаю это костылем. Стили в css, функционал и логика в js. Имхо, абсолютно все, что представлено в этой статье, должно быть сделано на js.

javascript — опасен. Он тьюринг-полный, он может завешивать браузер полностью, он может сливать информацию пользователя третьим лицам. Браузеры так и не научились запихивать javascript в надёжную песочницу, поэтому пользователям остаётся только блокировать его целиком.

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

Это по сути не язык программирования… Как он может быть полным по Тьюрингу?

Не совсем верно — CSS в сочетании с HTML позволяет «строить» клеточные автоматы (Правило 110), являя собой пример тьюринговой машины, т. е. быть тьюринг-полным. Но не уверен, что об этом знали минусуюшие…

Да на brainfuck тоже можно писать, только толку?

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

Да, бесчисленные демки Гомеров Симпсонов и прочих троллейбусов из хлеба «на чистом CSS» приучили нас считать горы несемантичных тегов их неотъемлемой частью, но по-моему это неправильно. А без разметки на голом CSS мало что можно сделать (хотя кое-что всё-таки можно:)
JS медленный. Анимация через CSS, например, даёт бОльшую плавность, чем силами JS.
Не JS медленный, а DOM.

Анимация — это стили, они должны быть сделаны на css. Я ведь написал это в своем комменте.

Всё, что может быть сделано без JavaScript, должно быть сделано без JavaScript.
Очень многие очень серьезные штуки, включая брузерные инженерные системы (количество которых стремительно растет, ибо удобно всегда иметь актуальную версию клиента на любой машине с браузером, ничего не устанавливая) можно сделать без JS или почти без JS
Беда в том, что если вы пишете что-то сложнее форума — это такой невозбранный объем адского гемороя, что вы либо получите неподдерживаемый гроб, либо не получите продукт вообще
Писать все без JS имеет смысл в двух случаях: нечем заняться и это что-то чрезвычайно нишевое и специфическое, требующее сверхъестественной стабильности и совместимости
В остальных случаях — инструмент под задачу

Ага, чтобы программисты видели кучу сложночитаемого и сложноподдержимоего кода. Слайдеры на CSS — не читаемый код.

Ну и используйте js, здесь лишь описан пример как можно, меня это поразило, как опыт очень ценно, мало ли где и что надо будет.
Если человек умеет делать вещи, которые все шлёпают на JS, то это лишь "+" ему в карму как фронтендера. Это отличный показатель навыков и уровня.
Кстати, отличное задание для сосискателей :-)
Для модальных окон есть более естественная реализация через селектор :target — пример. Кстати, через :target можно сделать и все остальные примеры кроме меню. Причём, при выборе вкладки или при открытии модального окна соответствующим образом изменяется адрес страницы: добавляется #dialog, #tab1, #tab2. И, соответственно, при обновлении страницы откроется та же самая вкладка или то же самое диалоговое окно. В этом преимущество по сравнению с checkbox. Плюс CSS-стили выглядят гораздо проще.

Наверное было бы интересно, если бы вы сделали всё то же самое, но через :target. Единственная проблема это что при закрытии диалогового окна вы переходите по адресу # и перескакиваете в начало страницы. Тут приходится уже использоваться JavaScript:
document.getElementById('close-button').addEventListener('click', function (e) {
  e.preventDefault(); history.go(-1); });

Ага. А что если я открыл ссылку с #dialog в новой вкладке браузера? Оно же не закроется. Или в другой уже открытой? Вместо решения задачи начинаются танцы с бубном, как же мне закрыть окно, сохранив текущую страницу и позицию скролла. Причем на том же JavaScript.
Таких вопросов много. Как сделать первую вкладку в табах по умолчанию открытой? И самый главный вопрос — как сделать 2 элемента с табами на одной странице?

Да, новую вкладку браузера не учел, нужна проверка. В этом случае просто ничего не делаем:
document.getElementById('close-button').addEventListener('click', function (e) {
  if (history.length > 1) {
    e.preventDefault();
    history.back();
  }
});

Чтобы первая вкладка таба была по умолчанию открытой, у неё адрес должен быть просто #.

Два элемента с табами — это из той же области, что два фрейма на странице. Очень старая проблема: адрес один, а страницы две. К какой из них относится адрес? Эта проблема более глубокая, чем JavaScript vs HTML+CSS.

Тут идеального решения нет. Если в табах реально отображается основное содержимое страницы, то совершенно естественно ссылаться на каждый таб через свой якорь. Если в HTML+CSS уже есть этот механизм, то почему бы им не пользоваться? Вы же для таблиц используете тег table, а не отрисовываете их на JavaScript? Если табов может быть несколько или если требуется асинхронная подгрузка их содержимого, то, да, нужен JavaScript.

К тому же, у меня встречный вопрос :) Как средствами JavaScript открыть сразу нужную вкладку таба, если стоит такая задача? Это можно сделать только с помощью якорных ссылок, которые из коробки поддерживаются HTML+CSS. Какой смысл тут городить JavaScript?
В этом случае просто ничего не делаем:

Тогда '#' остается.


Чтобы первая вкладка таба была по умолчанию открытой, у неё адрес должен быть просто #.

Пробую пример отсюда, не работает.


Два элемента с табами — это из той же области, что два фрейма на странице. Очень старая проблема: адрес один, а страницы две. К какой из них относится адрес? Эта проблема более глубокая, чем JavaScript vs HTML+CSS.

Это одна страница, фреймы здесь ни при чем. В бизнес-приложениях часто встречается вариант, когда в форме редактирования объекта поля разделены на вкладки, а внизу еще вкладки с информацией, связанной с объектом в целом — комменты, лог изменений и т.д. Или другой вариант, когда есть табы и модальное окно. Весело будет, если при открытии окна пол-странцы в фоне исчезнет.
image


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

Можно через якорь, можно через GET-параметр, можно через local storage или cookies, если надо запоминать. Отличие в том, что это не будет влиять на отображение остальных элементов. А через split можно и несколько табов обрабатывать.


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

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

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

Да, насчет вкладки по умолчанию вы правы, тут всё несколько сложнее, но есть решение через комбинатор селекторов ~. Вот, пример. Я не призываю отказываться от JavaScript, если что, я библиотеку для теории категорий на нём пишу :) Но и про селектор :target знать не лишне и использовать его иногда, явно штука не бесполезная.
Идеальный сайт может по максимуму работать с отключённым JavaScript. К сожалению, таких сайтов всё меньше и меньше, а фреймворков JS всё больше и больше.
Всё это привело к тому, что для работы какого-нибудь интернет-банка (например, на букву Т), требуется выкачать 500 кБайт заgzipованных скриптов, хотя большую часть функционала можно реализовать вообще без скриптов.
Идеальный программист должен быть с бородой и в свитере, а также сидеть на диалапе в 32 кб/с. Стойте, а какой сейчас год? Оу, 2017.

А жалкие 500Кб скриптов позволили сделать какой-то нормальный интернет-банк, заменяющий 5 часов поездок в банк на каждый чих.
А зачем делать интернет банк в вебе? Зачем майкрософт сделало новый скайп плагином для браузера (электрон)?

Почему бы просто не сделать приложение, которое можно скачать. Например на джаве, как делали до этого.
К электрону я тоже отношусь не очень. Но вот предлагать ставить всем джаву, когда у всех уже есть браузер в котором можно сделать тоже самое, то это, мягко говоря, глупо.
А если всем поставить джаву, то в следующий раз у всех уже будет джава.
И она таки лучше подходит для сложного GUI, чем html+css+js.
А если всем поставить джаву, то в следующий раз у всех уже будет джава.
Ну сначала поставьте ее всем. Вы удивитесь насколько неохотно пользователь ставит то, что ему не нужно, чтобы заработало то, что и так уже в вебе работает.
И она таки лучше подходит для сложного GUI, чем html+css+js.
Таки с чего вы взяли?
— Нет, ребята, я не гордый.
Не загадывая вдаль,
Так скажу: зачем мне java?
Я согласен на web-app.

Повторюсь: зачем еще следить за новой сущностью — jvm, если у меня у всех уже есть установленный браузер?

В чем-то десктопные GUI действительно лучше, но в среднем (для клиент-банка) они примерно равны с вебом.
В чем-то десктопные GUI действительно лучше, но в среднем (для клиент-банка) они примерно равны с вебом.
Ну так в чем же? Я вовсе не холиварю и прекрасно понимаю различия (а не то, что одно лучше другого). Просто со стороны эти заявления нелепо выглядят без аргументации.
Я подразумевал скорее «десктопный GUI может быть в чем-то лучше web-app».
То что одно лучше другого я как раз не утверждал. Они по-своему специфичны, но в целом равны.
Так в чем же, в чем может быть «в чем-то лучше»? Ну здравый интерес же, расскажите.
Не знаю. Это было предположение. Может быть лучше, а может быть и нет, подтвердить не могу — мало опыта для этого. Возможно есть какие-то проблемы, которые десктопными приложениями будут решаться эффективнее, чем в вебе, но 90% повседневных задач современный веб может решить без проблем.
Ну так вот, десктоп лучше только в том плане, что там есть инструменты, которые стабилизировались десятилетиями, когда вебу (такому, какому мы его сейчас видим) всего несколько лет, и, несомненно, вся эта каша вызывает обоснованное недовольство со стороны десктоп-разработчиков. С другой же стороны, технология веб-платформы практически полностью покрывает требования и запросы любого типичного приложения. Само собой, если вам нужна оптимальная бд под задачу или, например, udp или еще не дай бог какая экзотика уже не в рамках того же «любого типичного приложения», то ничего вы не получите. Это обоснованное ограничение платформы, которая выполняется в удаленном пользовательском браузере. Вспомните апплеты и флэш, которые умели все, где они теперь?

Возвращаясь к нашему вопросу, все вышеперечисленное к GUI имеет ровно никакого отношения, и, если сравнивать десктопную вертску (если такая имеется, как например в wpf или qt), то там ровно то же самое, только вот работа с темами корявая, ибо нет удобной декларативности css. Если верстка отсутствует (как саме знаете где), то тут я вообще не знаю, насколько уместны все эти разговоры про преимущества платформы (сами знаете какой).
> jvm, если у меня у всех уже есть установленный браузер?

И вы почему-то думаете, что этот браузер — мозилла или хромиум. К сожалению, после того как и тот и другой подло внесли в свою дистрибуцию бинарные программы (chromium — какую-то хрень для аудио, а firefox — DRM), у меня нет ни того, ни другого. Хрен с два ваша замечательная программа, написанные под четыре браузера (хром, файерфокс, эдж или сафари) будет работать у меня. А JVM — унифицирован.

А теперь посчитайте: у какого процента пользователей есть JVM, а у какого процента пользователей — обычный браузер.

Вы фанатик. А миллиарды других людей нет.

Бинарники, запускаемые в JVM, вас значит не смущают?

openjdk я собираю лично

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

Для банка у меня готова специальная виртуальная машина. Чтобы он не выбрался, и чтобы ему не мешали. Очевидно.

А весь остальной используемый софт я собираю сам.
Хм, а вы случайно ось себе из исходников не собираете? А то закрадываются подозрительные сомнения…
Конечно, это же несложно.
И все исходники вычитываете перед этим?

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

Тогда не получилось бы поконопатить мозги пользователям хабра.
(Это из разряда «Мне пожалуйста свиной стейк. Только он веганский? Потому что я веган. Я не ем мясо. И вы не ешьте. Но мне нужен стейк. Из свиньи. Но чтоб веганский.»)
копировать неудобно и работать неудобно. Одно дело, когда у тебя есть исключительный случай и большая потребность — ради банковских операций я готов приложить все усилия, чтобы получить безопасность. Тратить такие же усилия на чтение баша — абсурд. Рассовывать каждый сайт по своей виртуалке — так может и память закончится досрочно

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

UI главной Хабра за сколько времени сделаете?)

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

А зачем делать еще одно нативное приложение для разных платформ, которое нужно юзерам устанавливать, ради которого нужно нанимать несколько новых программистов ради мобильных платформ, если можно просто сделать РЕАЛЬНО кроссплатформу через веб, до которой будет проще добраться (запустить сайт значительно проще)?


P.S.: Электрон — зло, конечно, имхо, там все в принципе можно и в браузере запустить (и запускают, веб-версия скайпа есть и используется мной, если мне вдруг нужно в 2017 скайп запустить)

Java — это тоже кроссплатформенно. А у веба есть свои заморочки — кросс браузерность. И написание типичного GUI на вебе не проще чем на классических GUI фреймворках.
Опять вы за свое?
НЛО прилетело и опубликовало эту надпись здесь
Поэтому админ должен сидеть с прерывистого 3G. Ну или лучше не сидеть, и не админ, а отдел тестирования должен тестировать такой кейс, как заход с мобильного из зоны с плохим покрытием сети.

А можно уехать куда-то в тундру или тестировать с отключенным интернетом. Где грани разумного?
НЛО прилетело и опубликовало эту надпись здесь
Для жителей с плохим интернетом уже сделали хорошо — сжали скрипты с 5Мб до 500Кб. И это стало оптимальным решением по затратам на разработку и прибыли от этих клиентов. И у жителя «нетундры» есть преимущество — можно найти более подходящий канал связи.

Нужно делать хорошо и удобно большинству, а не подстраиваться под меньшинство (теория «диктатуры меньшинства»).

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

Почему сейчас все интернет-магазины гоняются за долями секунд в выдачи контента? Ответ простой — высокая конкуренция. А т.к. товар, цены, условия очень похожи, то есть профит в ускорении сайта. Что самое интересное — далеко не у всех ИМ получается сделать быстрый и удобный сайт.

А что же с банками? Я ищу в первую очередь надежный банк, который не аухнет при первом скачке курса. Мне как-то все-равно, если клиент-банк будет грузиться минуту, вместо 1,52 секунды. Также не сильно беспокоит сколько будет запросов и сколько Мб загрузится, больше интересна комиссия за перевод и процент по вкладу.

И да, лучше ждать 10 минут ответа от клиент-банка, сидя в кафе, чем 2 часа ругаться с бабуськами.
Нужно делать хорошо и удобно большинству, а не подстраиваться под меньшинство

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


И да, лучше ждать 10 минут ответа от клиент-банка, сидя в кафе, чем 2 часа ругаться с бабуськами.

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

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

«с бабуськами» — это образное собирательное выражение. Чтобы попасть в банк оффлайн надо как минимум надеть штаны. (Кстати, как раз вчера около часа бродил вокруг банка, т.к. «программисты всё сломали, ничего не работает»:)
Также не сильно беспокоит сколько будет запросов и сколько Мб загрузится

Вот в этом и проблема. Если это сайт с минимумом JS, то будет один клик — один запрос. Ответ не пришёл из-за проблем со связью — не беда, кликаем ещё раз и добиваемся результата.


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

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

Для телефонов есть приложение, которое есть меньше траффика. Зачем запускать браузер, елси уже есть приложение?


Разве что древне-непопулярная платформа, тогда извините :)

НЛО прилетело и опубликовало эту надпись здесь
Это уже где-то на грани абсурда:

Разрабатывается удобный веб-сайт для ПК и всего, для чего загрузить разово( к слову о кэшировании ) 500Кб — не проблема.
@
Для всего остального, есть мобильное приложение.
Которое, по случаю чего, можно и отключать, когда оно не надо.
@
Нет, оно жрёт батарейку, требует много разрешений( будто бы оно банковское, в самом то деле!:) ) и… и вообще… хочу сайт… но… но не такой, который есть, а, как бы такой, но… но чтоб красивый и удобный, и… именно без JS и всё реализовывалось на CSS и под мобильный и… и чтоб мобильный его полностью поддерживал — ведь приведённый в статье( и подобных статьях, гуляющих по интернетам) ужас на CSS одинаково идеально и стабильно работает и отображается на всех устройствах и браузерах, даже старых, то ли дело, ненавистный JS и… да не просто под мобильный, а такой, для которого даже приложение тянуть — ощутимая нагрузка на батарею.

Ну разве не абсурд?)

Разрабатывается удобный веб-сайт для ПК и всего, для чего загрузить разово( к слову о кэшировании ) 500Кб — не проблема.

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


Главный жирный минус подобных веб-приложений — однооконность. Хотите открыть несколько писем gmail в разных окнах — пожалуйста, загрузите по экземляру в каждое окно, каждое из которых будет кушать больше 100 мегабайт. Хотите открыть второе окно Т-банка? А авторизоваться по-новой не хотите?


Собственно, можно сказать, что у Т больше нет мобильного сайта, есть только приложение: одно — программа для смартфона, второе — веб-приложение.

НЛО прилетело и опубликовало эту надпись здесь
Сказано красиво, только вот… приложение, в случае полноценного отключения/остановки, НЕ может работать, когда ему вздумается — оно начинает работать именно тогда, когда его запускают.

Это уж вопрос к соотв. специалистам — для чего конкретно каждое из разрешений требуется.

Вполне логично решит( что устарело ). Это и всевозможные обновления контента/услуг/функционала и безопасности, а не просто проггеры сидят, да думают, как бы ещё бедным пользователям насолить — «лишних» 30 мб их заставить качать, что ли).
А вообще, если не нравится автообновление, то, в случае с Play Market'ом, оно отключается в пару кликов. Посему, нет, оно не может просто так решить и начать качать, если на то нет согласия пользователя( хотя бы молчаливого, т.е дефолтного ).

Хотя, если даже акка в гуглплей нет… На андроиде… То, дальнейшие вопросы( в т.ч безопасности и источников приложений, которые «могут работать, когда им вздумается») отпадают)
НЛО прилетело и опубликовало эту надпись здесь

Представьте себе, в некоторых местах 3G/4G настолько ужасен, что диалап кажется раем, при EDGE вообще молчу. И это не глушь в Сибири, а обычные города-миллионники. Добавим тяжесть скриптов, и получаем, что сайт Т для меня при использовании мобильника полностью закрыт.


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


А "ущербные" компании типа Яндекса и Гугля предлагают пользователям для работы с почтой облегчённый HTML интерфейс, и он очень удобен.

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

Неправда ваша, никакой корреляции между предоставляемыми услугами и качеством разработки фронтенда нет, новая версия ТКС-банка действительно ужасает своей монструозностью, разучились делать эффективно и красиво.
А жалкие 500Кб скриптов позволили сделать какой-то нормальный интернет-банк

Пользователи с вами не согласны, почитайте комментарии.

Не рубите так с плеча, про идеальный сайт. Я вообще думаю, что бизнес во многом сейчас решает быть или не быть js на сайте. Про интернет банкинг, могу сказать, что без js вообще нельзя — есть и логика защиты процеса работы с данными и шифрование и трюки-крюки простите за слег.

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

А если мне нужен клиентбанк на макбуке, или айпаде, или лептопе дочери (да да у нее линукс стоит). Мне на этот зоопарк как поставить клиент банки? А если у меня счета в нескольких банках, а я с семьей поехал отдохнуть и допустим с собой только айпад и деньги нужно перекинуть со счета на карту? Что делать то?

То, что банки сделали клиент банки в браузере, это не просто плюс, это просто огромный плюсище и респект им!

PS Юзаю клиент банки приват и райфайзен банков. Удобно и юзабельно.

PSS согласен только с одним. К разработке надо подходить с умом. Не надо из танка по воробьям.
Мне, почему-то сразу, вспомнилась история о том, как программисты разных уровней реализовали пример hello word. Программист начального уровня написал одну строчку, а гуру — шесть экранных страниц текста.

Вывод: каждый будет пользоваться тем, что ему удобно.
Прям вспомнился язык Hex, который компилируется в 18 ( или сколько там) языков, простое хеллоу ворлд оно превратило в 18 классов.

Тем не менее по статье, интересный подход, вряд ли буду использовать, но симпотично.
CSS сам по себе практически не умеет в состояния. Но мастерски умеет придавать визуальное великолепие состояниям того, у чего они есть:). Соответственно, для ховеров/фокусов форм, например, CSS идеален, и делать это через JS-обработчики — изврат. А для переключения произвольных панелей, наоборот, изврат — пихать в разметку левые инпуты чисто для привязки стилей. Всё имхо:)
Для панелей, табов, диалоговых окон и т.п. есть селектор :target. Просто люди привыкли делать это на JavaScript и им даже в голову не приходит, что это совершенно просто и естественно делается средствами HTML и CSS.

Переход по ссылкам-якорям внутри страницы, ведь, абсурд делать на JavaScript через ручной скроллинг. Хотя, стоп, даже на этом сайте навигация по новым комментариям именно так и сделана.
Мне кажется, вы путаете посылку с выводом. Из того, что поведение перехода по ссылке-якорю иногда можно (и даже нужно) визуально представить как переключение таба или открытие диалога, не следует, что любое переключение табов/открытие диалогов нужно (и можно) реализовывать через ссылки-якоря. Простейший контрпример из соседней ветки комментариев — две панели табов на странице. Так что надо знать оба способа и не видеть во всем гвозди просто потому, что освоили один молоток).

Ну и по поводу того же скроллинга между якорями не надо забывать, что плавный скроллинг выглядит естественнее резкого, а нативный scroll-behavior появился не так давно и по-прежнему не работает в Safari (т.е. на славящейся своей плавностью платформе, для которой резкие перескоки особенно чужеродны). Так что технически, да, вроде бы абсурд — но комфорт пользователя превыше пуризма разработчика.
Меню и анимашки на CSS3 работают плавнее, чем реализованные через JavaScript. В этом главное достоинство CSS3. В остальном часто легче использовать JavaScript, т.к. в CSS3 на данным момент слишком уж много получается запутанного текста.
А зачем обходиться без JavaScript? Он с каждым годом все лучше и лучше.
Проблема не в самом JS как таковом, а в том, как его теперь используют в силу своего широкого распространения. По делу и без. Прямо как было с php. Имхо, пост об этом.

Когда мне (случай из практики) звонят и говорят «Эй, %админнэйм%, мне кажется, что у нас с каналом что-то не то. Или с сервером. Главная сайта медленно грузится, посмотри, а.», а я через ff вижу 4,5 Мб только одних скриптов, грузящихся до конца за 47 секунд, то я не злюсь (мне-то всего открыть браузер и в ответ позвонить), но мне по настоящему жалко пользователя, которому выпала участь открывать такую страницу.

Кстати, из 4,5 Мб один скрипт весил почти 800 Кб, а всего-то отвечал за меню-аккордеон. Т.е. всё ради одной функции. Остальное — бесполезный груз.
Кстати, из 4,5 Мб один скрипт весил почти 800 Кб, а всего-то отвечал за меню-аккордеон. Т.е. всё ради одной функции. Остальное — бесполезный груз.

Зато не велосипед! И скопировать только одну функцию тоже нельзя — а вдруг библиотека обновится?
И написать код в 10 раз меньше тоже нельзя — это же дополнительные расходы на веб-программистов.

А чем большинство JavaScript-фреймвоков не велосипеды, которые загнутся через год-два? Нормальные фреймвоки обычно разбиты на модули.

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

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

Интересный подход, заставил задуматься, но использовать на практике, думаю, не стоит.


работа в браузерах с выключенным JavaScript (если в наше время кто-то таким пользуется)

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


Насчёт злоупотреблений — да, можно согласиться (видал, когда ради одной единственной функции на 3 строчки подключают тяжеленную библиотеку, особенно когда это в моб. версии).
Но в данном случае вышло злоупотребление HTML и CSS. Как минимум нарушена семантика (используются элементы форм, а форм нету). Хотя сам подход, повторюсь, интересен (в академических смысле), я и не думал, что так можно.


Насчёт фото и background затея не очень — возможно проседание по СЕО. Я не сеошник и может меня поправят, по крайней мере это логично, в img можно (нужно) alt прописать, напр., да и не только поэтому, опять же семантика.

1. validator.w3.org на чекбоксы без форм не ругается.
2. Интересно, что на сайте apple.com раскрытие меню в мобильной версии происходит тоже с помощью checkbox, label и css-стилей.
validator.w3.org — не показатель. Это не больше чем проверка орфографии в ворде. Если во фразе ни одно слово не подчёркнуто красным, это ещё не значит, что в ней есть смысл.

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

Валидатор и не должен ругаться. Может вы аяксом значения инпутов отправляете.
Но другой пример. Многие любят в тег p пихать то, что абзацем не является, чисто для упрощения вёрстки (чтобы class не писать). Это нарушение семантики или нет?
В html она и так не слишком богатая… html5 правда пытается это исправить...


Да, конечно интересно. И я в целом за то, что часть логики (отвечающей по сути за отображение), которая раньше была возможна лишь в js, переносится в html и сss: placeholder, transition и прочее. Я лишь против нарушения той минимальной, но семантики, что есть в html.

По поводу чекбоксов без форм: как вариант, можно создать форму, и привязать к ней все чекбоксы через атрибут form (html5).
НЛО прилетело и опубликовало эту надпись здесь

Спасибо. Буду знать. Файрвоксом почти не пользуюсь, просто как-то искал ради интереса галочку в настройках — не нашёл.
Насчёт моего "нельзя никак" Вы правы, погорячился ))

Это элементарно делается через селектор :target без всякого нарушения семантики элементов.

Примерно это я и имел ввиду, да.
Если меню и табы можно реализовать на чистом css, я как бы за (это же визуальное оформление).
Но не нарушать семантику. Так что поддерживаю.
Хотя лично я в тех же табах люблю урл без якорей (используя HTML5 History API). Правда без js тут уже не обойтись.
Но как рабочий вариант и без нарушения семантики :target мне кажется интересным. Нужно будет как-нибудь попробовать на досуге.

Великолепная демонстрация, спасибо. Имеющимися инструментами надо уметь пользоваться!
У меня Огнелис с отключенными скриптами — ни один из примеров не работает.
Ну как фан задача, или там скиллы потренить сойдет. Использовать в релизном проекте я бы не стал
Один из плюс таких реализаций — это работа в браузерах с выключенным JavaScript

Был клиент, который говорил: «Оно не работает, когда я отключаю поддержку JS». Видимо начитался в интернетах всяких статей «Как проверить качество работы верстальщика». Достаточно показать статистику из Яндекс.Метрики, где почти всегда 99% пользователей сидят с включенным JS и только 1% — неизвестно.
Круто, чо.
Я вот не понимаю споров о том, что все надо делать на JS, или не делать на JS. Делайте как хотите, браузеры Вам это позволяют. Здесь лишь пример того, как то же самое можно сделать по другому.

Все должно быть в одном языке (может html5 наведет порядок)
Это конечно прикольно, но не семантично
Стоит ли этот функционал лишних тегов и инпутов?
Делайте через селектор :target и всё будет семантично.

Все прекрасно, только по-моему вероятнее встретить пользователя без CSS3, нежели без JS'а. Поэтому в то время, как Babel позволяет транспилить и поддерживать хоть IE6 (прости господи), то для CSS'а я такого не знаю (CSS Next в CSS3 разве что). Когда речь идет о какой-нибудь анимации, то хрен бы с ней, пусть мгновенно без красивого перелистывания таб откроется, но когда основной функционал не работает (модальные окна не открываются, табы не переключаются и т.п.) то это финиш.

Да? Ну, вы, наверное, правы, у расширения NoScript всего каких-то 2.2 миллиона пользователей, а сколько у YesScript и прочих — вообще не считаем. Это, конечно же, гораздо меньше, чем количество пользователей IE6.
в мире больше трех миллиардов пользователей интернета, доля неподдерживающих браузеров согласно caniuse составляет 5%, и 5% от 3 млрд все же поболее будет, чем 2 миллиона. Так что да, гораздо меньше.
Интересно, но только в плане изучения CSS, а не как полноценная замена реализаций на JS. Впрочем, как сниппеты пригодится, спасибо!

P.S. Лет… цать назад, за присутствие JS на сайте «бил по рукам». Аргументы мои звучали примерно так «иди изучай HTML и CSS». 99 процентов случаев его лепили там, где он на самом деле не был нужен. Был уверен, что JS так всю жизнь и останется «маленьким помощником Санты» и в общем то ни для чего серьезного применяться никогда не будет, а все что необходимо будет сидеть в сетевых десктопных приложениях.

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

«Скоро ничего не будет, ни театра, ни кино, ни HTML, ни CSS сплошной флешь.» А JS? Не смешите меня!

Не угадал.

Состояние приложения, если таковое имеется, должно контролироваться в JS, а отображение этого состояния, по возможности, в CSS. Они прекрасно дополняют друг-друга и позволяют многое упростить (и даже ОЧЕНЬ упростить) при совместном использовании. Не вижу смысла отказываться от чего-то одного в пользу чего-то другого.

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

Поздравляю, вы только что переписали You Might Not Need JavaScript, причём переписали хуже. Сразу после его публикации поднялась дискуссия о том, стоит ли что-то писать на чистом CSS только потому, что можно. Чаще всего таки натужные решения недоступнее, неудобнее и хрупче аналогичных на JavaScript.

Примеры с этого сайта (слайдер, аккордеон) жестко привязаны к css и наименованию id…
Уберите элемент с #slide-4 в слайдере — и он будет изначально с пустым фоном.
Добавьте в аккордеон более 4х элементов, или просто с другими id — и она перестанет работать.
И надо лезть в css, что бы подстраиваться под id и кол-во элементов!

В моих же примерах лезть в css при изменении количества элементов на странице не надо! Добавьте Вы хоть 20 слайдов с любыми id — все будет работать! 1 раз настроил и все;)
Я смотрю, холивар нешуточный

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

Да и на сайтах-визитках всяких если что-то случится с js-файлом… Например, полу-юзверь (не все же тру программисты) создатель сменил расположение, а пути не поменял. В таком случае сайт хоть немного можно будет покрутить и посмотреть. Например. А на повсеместное использование эти методы и не претендуют
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории