Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!
Вопрос для frontend спецов. Какой вариант будет работать быстрее?
1. Поведением окон и фильтров на странице управляет CSS (логика, завязанная на чекбоксы/радиобаттоны и атрибут :checked)
2. Поведением управляет JavaScript (.onclick и т.п.)
Ну и с точки зрения «внутрицеховых норм», логика на чекбоксиках допустима?
Коментар порушує правила спільноти і видалений модераторами.
Для начала, подробнее про проджект и его масштабы.
Для мелкого проета, ИМХО все равно, что и на чем писать, никто разницу не заметит, а вот для крупного — JS одноначно. Ну, ну можно еще флешь предложить, с его внутренним кодом, но это тот еще геморой)
Так-то понятно, что в своём личном маленьком проекте я могу хоть goto использовать, лишь бы работало :)
Просто хотелось бы делать так, что-бы потом не стыдно было показать понимающим людям.
Вопрос был скорее теоретический, есть ли в таком способе смысл (я его себе видел в скорости) и является ли такое построение логики допустимым с точки зрения «общественных норм».
На сколько я понял, однозначного ответа нет.
Мне пока нравится то, что такая логика будет работать даже если JS вообще выключен (хотя сейчас, наверное, такого уже не бывает) и, как выяснилось, скорость таки выше.
Не до конца понимаю, что может быть сложного в поддержке такой конструкции но это, скорее всего, из за того, что я с большими проектами не работал.
А так, представление я уже себе составил, спасибо :)
Не до конца понимаю, что может быть сложного в поддержке такой конструкции но это, скорее всего, из за того, что я с большими проектами не работал.Ну вот надо другому программисту (или вам через год) что-то поменять в поведении. Зная что попап / скрытый див открывается при отметке чекбокса — я бы стал искать обработчики, навешанные на него. Упс, а их нет. Я не знаю как быстро я бы догадался, что это сделано на css.
смотрите, какие стили применяются к попапу. если display: block привязан к простому селектору типа класса — очевидно, что этот класс кто-то ставит(JS). а если там что-то типа #flag:checked ~ .popup то очевидно, что дело в CSS
Теперь, зная что кто-то может так сделать — это кажется простым. Не зная я не уверен что быстро бы нашел.
это просто самый быстрый подход.
Зная что попап / скрытый див открывается при отметке чекбокса — я бы стал искать обработчики, навешанные на него. Упс, а их нетможет быть из-за делегирования, например.
Ну, по первому пункту мне сложно что-то сказать. Я то как раз первым делом полезу смотреть в CSS, благо правило очевидное, а с другими да, оставлю, наверное, комментарий в начале файла, на всякий случай.
А по второму кейсу я совсем не понял — зачем мне нужно сделать то-же самое не трогая чекбокс? В смысле, кейс, лично для меня, выглядит очень теоретически. Хотя, спорить не буду, может в больших проектах такая необходимость зачем-то может возникнуть. Кто их, эти большие проекты, знает :)
Ты недооцениваешь извращения конечного пользователя))
каюсь, не врахував такий фактор як «замовник»))))))
использовать чекбоксы и радиокнопки не по назначению — это полная фигня, плюс еще такую фигню и поддерживать сложно будет.
логика завязанная на чекбоксы и атрибут :checked- полная ерунда, делайте нормлальные обработчики
имхо если там
нет «бизнес логики» (где-то контроллер устанавливает у кого-то класс, через селекторы где-то в другом месте что-то меняется..),
не предполагается рефакторинг по причине «щас тут быстро починю, потом дома скотчем примотаю» этого участка
и css без «хаков с хабра», то суйте все в css.
А точно вопрос в скорости? Вы уверены, что пользователь сможет увидеть разницу? Если нет претензий к производетельности, то лучшее решение — самое простое. А если есть, то Вы уверены, что все, что показываете пользователю так уж необходимо? Большой объем информации просто не воспримется.
Звучит круто от жс-синьора, лол. А можно пояснить? Серьезно, интересно.
Потому что все что можно сделать на css без js стоит делать так. Ибо в общем случае будет быстрее.
Но менюшки с помощью :hover все же не рекомендуют писать.
это почему? Они самые растространенные, вообще-то. И самые User Friendly
Знаешь выражение — На каждые 10 строк кода есть 1 баг. Так вот, практика показывает что если на 10 строк всего 1 бага, то это очень хороший показатель.
Так вот, если можно решить проблему не меняя код — это твое решение.
Пф, CSS тоже код
с таким успехом русский язык (как и любой другой) тоже код.
но CSS несравнимо проще, не является языком программирования, и сам по себе является декларативным
погоджуюся, в самих вимогах існують баги.
тільки звідки інфа що декларативні мови приводять до меншої кількості багів?
Во первых декларативные языки более очевидны, что с субъективной точки зрения упрощает колво багов.
Во вторых, чем меньше вариаций реализации, тем объективно сложнее допустить баг, ибо есть только один путь (но тут тоже есть нюансы)
Ну и в третьих( не про баги), людям проще осваивать декларативные языки, что приводит нас к большому колву специалистов, а это выгодно бизнесу
Конечно есть кейсы когда декларативщины можно столько нахерачить что решение становится неподдержуемым. Тогда это плохое решение :)
Во первых декларативные языки более очевидны, что с субъективной точки зрения упрощает колво багов.ээээ, не согласен.
делкаративщина убирает большое количество однотипного кода.
уменьшает возможности велосипедостроения.
но при этом урезает возможности, усложняет дебаг и оптимизацию.
SQL против навигационного подхода, Regexp и Angular, например
Ну я в конце это и имел ввиду, когда написал что декларативным кодом можно нахерачить хрень.
И про урезания возможностей я тоже писал.
Ну я в конце это тоже писал
я тоже писал.я не пытаюсь отобрать авторство.
Как раз в общем случае декларативный стиль уменьшает колво багов, но реальность и злоупотребления этот общий случай не кисло меняют.
возьмите конкретный кусок, отобразите FPS и протестируйте.
в общем случае(если получается достичь идентичного поведения) CSS-вариант будет быстрее, намного проще прикрутить анимацию(которая тоже будет быстрее, плюс может использовать видеокарту для просчета).
в общем случае лично мне не понятно, что понимается под «поведением окон, завязанном на чекбоксы и :checked»
Ну как, кнопки, это label, невидимые чекбоксы расположены так, что когда чекбокс становится checked — срабатывает правило, типа #chbx1:checked+.popup {display: block}
И всё в таком духе.
С помощью radio и селектора ~ я фильтры (выбор, что показывать) сделал, но меня смущает тот факт, что я CSS использую для «поведения», в то время, как меня учили, что html для структуры, scc для оформления, JavaScript для поведения.
Поэтому хочу разобраться, есть ли в таком способе организации простейшей логики смысл, и с точки зрения «негласных соглашений» не вызовет ли это нареканий у специалистов.
Как-то так :)
изначально вас интересовала скорость
теперь уже звучит «а есть ли смысл?» и «а вдруг, потсоныспециалисты не поймут?»
читаемость, скорость, расширяемость, управляемость, простота отладки.
выберите пару, а не все сразу.
да, так делают
да, кто-то против таких приемов
да, оно может привести к проблемам
да, оно может решить проблемы
по сути, любые селекторы с «+» определяют поведение. по идее, любой селектор с :checked/:hover/:empty можно заменить на JS код.
в то время, как меня учили, что html для структуры, scc для оформления, JavaScript для поведенияугу.
Изначально меня оба вопроса интересовали (всё таки, полным лаптем выглядеть не хочется) :)
Скорость интересовала именно потому, что я хочу понять, имеет ли смысл так делать.
В моём случае проблем с читаемостью и расширяемостью/управляемостью/скоростью нет.
Но на будущее хотелось понять.
Спасибо за пояснения.
невидимые чекбоксы расположены так, что когда чекбокс становится checked — срабатывает правило, типа #chbx1:checked+.popup {display: block}Нет, так делать нельзя — это неочевидно в случае доработки другим программистом и очень хрупко.
ну, как неочевидно — открываешь developer tools, смотришь применяемые правила
и очень хрупко
только js код тоже может сломаться, если полагается на селекторы, которые уже не валидны. и шо делать?Тоже верно
плюс, в случае CSS можно реализовать разное поведение в зависимости от размера экрана. для мобильных, например, выезжающая сбоку панелька, для обычных мониторов — попап, для огромных — постоянно показывать панель фильтрацииОбработчик на JS может навешивать на контейнер css-класс, а дальше уже всё выше перечисленное. В-принципе, всё равно приходится в той или иной степени смешивать CSS и JS
всё равно приходится в той или иной степени смешивать CSS и JSда, но в «чисто CSS» варианте не надо навешивашь еще хендлеры на onresize, например
и очень хрупко.эта проблема всего фронтенда, очень много чего хрупкого
это неочевидно в случае доработки другим программистома это проблема любого программного продукта, ибо то что кажется очевидным для вас, не факт что очевидно для других
Коментар порушує правила спільноти і видалений модераторами.
Robota Job
Gennady Dogaev
Євген Козлов
Тарас З
Oleg Sobko
Vladyslav Derkach
Dmytro Shchurov
Dmitriy Iashin
Artem Perchyk
Ivan Matvieiev
Чеширский Кот
Stanislav Mykhailenko
Анатолій Обіцький
Євген Козлов
37 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів