Comments 82
сайты могут быть быстрыми, красивыми и интерактивными даже без JS
"Даже"?
представляю себе недоумение последнего поколение разрабов, убежденных что веб и ReactJs это одно и то же
Ничего, скоро в CSS и JSX завезут.
Это какие-то слишком старые разрабы, отнюдь не "последнее поколение". Совсем молодые дальше строки промта условного chatGPT могут и не уйти. Сейчас немало конструкторов где между промтом и деплоем нет промежутка. Написал промт, получил результат, нажал деплой - получил ссылку на развёрнутый апп, готово!
А ещё раньше был Front page 2002 года с попыткой в технологию WYSIWYG, что вижу то и отображается. Потом ушли в сторону написания в ручную стилей, далее уход в JavaScript потом в typescript, затем в React и сейчас снова пытаются уйти в CSS, в стили похожи на псевдо язык с переходами, циклами и переменными. Все что есть в обычном языке программирования только над стилями. Сейчас в переменных содержатся куски стилей ага очень просто) сарказм. Хотя фронтендерам может и нормально, я не фронтендер
Хватит бухтеть. В моём детстве это было $() и люди не могли отличить JS от JQuery.
Представляю их ещё большее недоумение, если сайты откажутся от реакта и вернутся в старый стиль. Когда у формы action="/" и при ошибке все поля сбрасываются, и нормально перезагрузить страницу нельзя, потому что всплывает окно об отправке формы. PhpBB - я тебя помню, сволочь, и все так же сильно ненавижу
Было бы неплохо ещё увидеть примеры хоть сколько-нибудь полезных сайтов вообще без JS. Ну то есть что-то посложнее лендинга с набором статичных фреймов и формы "Напишите нам" с валидацией адреса электропочты, на который мы вам "обязательно ответим".
Тем более, что дефолтная браузерная валидация не корректная:
Корректная регулярка выглядела бы куда как сложнее:
/^(?:((?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}(?:\.(?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}){0,})|("(?:((?:(?:([\u{1}-\u{8}\u{b}\u{c}\u{e}-\u{1f}\u{21}\u{23}-\u{5b}\u{5d}-\u{7f}])|(\\[\u{1}-\u{9}\u{b}\u{c}\u{e}-\u{7f}]))){0,}))"))@(?:((?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}(?:\.(?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}){0,}))$/gsu
Примерно любой сайт до ~2010-го — в те древние времена ещё считалось хорошим тоном обеспечивать работоспособность сайта без JS
Можно глянуть какие-нибудь выжившие старые форумы на «классических» движках вроде PhpBB или MyBB — без JS отвалится какая-нибудь мелочь вроде кнопочек форматирования в редакторе, но вся основная функциональность останется рабочей
Жаль, что нынешнее поколение веб-разработчиков разучилось так делать, вон комментатор ниже даже не представляет как можно жить без API
phpBB - плохой пример. Берём случайный коммит за 2010 год и смотрим тамошний core.js
Куча кода: ajax, jquery, попапы, дропдауны, рекапча, аплоад файлов, и т.д. Я не думаю что без всего этого оно будет работать нормально.
Но вашу идею я понял.
Можно отметить, что этот файл появился в 2012-м, а раньше как-то жили и без него)
Да было время )). В конце 90 мы писали на perl, делали чаты, форумы, сделали свою смс систему для онлайн магазинов, сделали прицеп для 1С. Практически все страницы были сгенерированы, там где динамика использовали SSI + httaccess. В итоге все это свистело даже на самых слабых хостингах.
А с чего жалость то? UX возможности приложений написанных на JS гораздо выше чем у многостраничных сайтов. Кроме того такой подход позволил разделить компетенции разработчиков на frontend и backend части и разработку их отдельно друг от друга. Работа с бэком через api это наиболее вменяемый путь развития, потому как фронты могут быть web, mobile, smart tv и прочее, а api при этом один и тот же.
Опять эта пачка заезженных мифов)
чем у многостраничных сайтов
На многостраничных сайтах тоже никто не запрещает использовать JS и сделать богатый UX, это не взаимоисключающие вещи
такой подход позволил разделить компетенции разработчиков на frontend и backend части и разработку их отдельно друг от друга
И ничего хорошего в этом нет, по множеству разных причин это лишь приводит к ухудшению качества сайтов
фронты могут быть web, mobile, smart tv и прочее
Иронично, что в реальности всё происходит наоборот — все всё запихивают в веб, и многие «нативные» приложения являются всего лишь обёртками над webview
Но независимо от этого — ничто не мешает использовать один и тот же api для многостраничного сайта и для нативного приложения, лишь бы было желание нормально организовать структуру бэкенда
И ничего хорошего в этом нет, по множеству разных причин это лишь приводит к ухудшению качества сайтов
Например?
Много букв
Если мы рассматриваем ситуацию, когда бэк только отдаёт API, а фронт это SPA, самое очевидное — сайт перестаёт работать без JS, пользователь вынужден разрешать на своём устройстве remote code execution и подвергать себя в худшем случае риску безопасности (дыры в песочницах и сторонние каналы никто не отменял), в лучшем случае майнингу бетховенов (утрирую, но суть вы поняли)
Так как бэк вряд ли станет делать эндпоинт, который отдаст всю нужную странице информацию за раз — фронт вслед за хотелками фронтендеров станет отправлять стопицот ajax-запросов на каждый чих: тот же Хабр при открытии комментов отправляет 7 ajax-запросов, хотя теоретически ничего не мешало бы уложиться в один запрос и сэкономить время (и трафик, потому что всё вместе наверняка сожмётся лучше). И нет, отмазки наподобие «можно сперва быстро загрузить и показать основной контент страницы, а уже потом подгружать менее важные части» здесь не прокатят: во-первых, загрузка и запуск JS сами по себе потратят сколько-то времени, а во-вторых, браузеры умеют показывать страницу ещё в процессе загрузки, так что пользователь может сразу начать читать основной контент вообще без использования JS и даже не дожидаясь окончания загрузки этого основного контента — это ВСЕГДА будет быстрее чем рендеринг контента через JS
Если бэк не озаботится чем-то вроде GraphQL — он будет отдавать в том числе ненужную информацию и впустую тратить трафик: тот же Хабр при открытии комментов зачем-то отдаёт полные тексты постов, которые при этом никогда не отображаются
Браузер начинает выполнять двойную работу: сперва он тратит энергию на парсинг json, а потом на преобразование этого json в DOM по замудрёным алгоритмам — это ж какой углеродный след получается, куда только экоактивисты смотрят? А парсинг html никуда не девается, потому что регидратация и потому что на том же Хабре тексты постов всё равно приходят в html (и при этом завёрнутые в json, ага). А устройства у пользователей далеко не новые, и всё это дело успешно тормозит. Всё это можно было бы не только быстро сделать на высокопроизводительном бэке (особенно если взять столь же высокопроизводительный язык, но Rust это же экономически невыгодно ага), но и закэшировать на том же бэке (хотя бы для отдельных частных случаев) и не тратить миллионы часов и ватт пользовательских устройств на бессмысленное повторение одних и тех же действий
А уж как бесит криво сделанная гидратация на некоторых сайтах: сперва за несколько секунд подгружается обычный html, я начинаю его читать, а потом он ВНЕЗАПНО пропадает и заменяется на экран загрузки, чтобы потратить ещё несколько секунд и процентов заряда батареи на преобразование json в тот же самый html! Хочется бить ногами за такое
Ну и ещё не совсем про техническую часть, а скорее про дисциплину — часто фронт оказывается избалован одностраничностью и начинает плевать на семантику. Так как ничего не заставляет использовать родные браузерные механизмы — разработчики фронта начинают велосипедить свои собственные механизмы, которые работают хуже чем родные браузерные и приводят к появлению проблем, которых изначально не появилось бы, если бы фронт не выпендривался. Зачем делать нормальную форму с нормальной кнопкой отправки, если можно просто повесить onclick на div? Пофиг, что форма перестала отправляться по энтеру, будет много жалоб — добавим onkeypress. Зачем делать ссылки через тег <a>, если можно просто повесить onclick на подчёркнутый span? Ну и что, что Ctrl+клик перестал открывать псевдоссылку в новой вкладке, этим пользуются всего 0.00001% пользователей, добавлять обработку event.ctrlKey экономически невыгодно, использовать нормальный <a> ещё более невыгодно
Вот вам контр пример: https://page.hyoo.ru/#!=u4oxgj_q8dpwd
Приложение мгновенно поднимается из офлайна.
Если уже был на станице - статья сразу показывается из кеша.
В фоне грузится новая версия, если есть изменения, и тут же показывается.
Рендерится не вся статья, а лишь то, что попадает в видимую область.
Парсится статья тоже лениво.
Если сервер по любой причине не отвечает - приложение не ломается.
А вот, что видят поисковики: https://page.hyoo.ru/?_escaped_fragment_=%3Du4oxgj_q8dpwd
Приложение мгновенно поднимается из офлайна.
Во-первых, это плохо, потому что всё ещё требует JS. Во-вторых, в оффлайне картинки отвалились — ну и какой смысл в таком оффлайне? Лучше бы я увидел обычную ошибку подключения к интернету
Если уже был на станице - статья сразу показывается из кеша.
Возможно, это работает хорошо при автоподгрузке изменений, но на обычном сайте это будет плохо, потому что я рискую увидеть устаревшую версию
В фоне грузится новая версия, если есть изменения, и тут же показывается.
Если прям совсем сразу же показывается новая версия, то это плохо, потому что нарушается консистентность: первую половину я прочитаю старую, вторую половину прочитаю новую и запутаюсь. Лучше просто уведомление вида «Есть изменение, обновить страницу?» Но такое уведомление можно сделать и на классическом многостраничном сайте
Рендерится не вся статья, а лишь то, что попадает в видимую область.
И это ОЧЕНЬ плохо: я хочу заранее загрузить весь контент целиком и потом спокойно его читать без раздражающих подгрузок, а то вон в оффлайне у меня уже картинки отвалились
Парсится статья тоже лениво.
Аналогично предыдущему пункту. Кстати, на моём телефоне прокрутка подтупливает — подозреваю, что поэтому
Если сервер по любой причине не отвечает - приложение не ломается.
А лучше бы ломалось. Я всё в том же оффлайне тыкнул в рандомную статью и получил вечную загрузку — а нельзя мне было сказать «Включи интернет, придурок»?
В общем неудачный пример по (почти) всем параметрам
Версия для поисковиков гораздо приятнее в пользовании: и грузится быстрее, и прокрутка не лагает, и загружается сразу всё целиком, так что можно спокойно читать в оффлайне с картинками
в оффлайне картинки отвалились
Это, разумеется, не так. Все загруженные картинки остаются в кеше. Вы до них просто не долистали.
на обычном сайте это будет плохо, потому что я рискую увидеть устаревшую версию
Вот как раз на обычном сайте увидеть устаревшую версию предпочтительнее, чем не увидеть ничего. А на необычных сайтах отображается статус актуальности, обновляющийся в реальном времени.
первую половину я прочитаю старую, вторую половину прочитаю новую и запутаюсь
За пол секунды вы ничего не прочитаете. Вы не супергерой.
я хочу заранее загрузить весь контент целиком и потом спокойно его читать
А я не хочу тратить трафик на загрузку всех картинок, если прочитав пару параграфов, пойму, что написана чушь. Вы тут не один.
тыкнул в рандомную статью и получил вечную загрузку
И у вас всё ещё есть возможность тыкнуть на другую рандомную статью и получить её из кеша. Вы даже не поняли, о чём вам говорят.
лучше бы ломалось
Проспитесь перед следующим ответом.
Вы до них просто не долистали.
Именно! Они должны были догрузиться сами, без долистывания
А на необычных сайтах отображается статус актуальности, обновляющийся в реальном времени.
Если ограничить задачу просто отображением статуса актуальности, то это и на обычных сайтах легко делается (на том же Stack Overflow я такое вижу постоянно)
За пол секунды
А почему вы так уверены, что изменение прилетит именно в первые полсекунды чтения, а не в любой другой момент времени?
Я не знаю, как работает конкретно ваш сайт (но видеть вебсокет в девтулзах как-то страшно), но из жалости к пользователям предположим, что подгрузка изменений выполняется один раз в момент открытия страницы и потом больше ничего не подгружается — но даже в этом случае, учитывая глючность мобильных интернетов, сама подгрузка контента может занять сильно дольше чем полсекунды, а читаю я быстро
А я не хочу тратить трафик на загрузку всех картинок, если прочитав пару параграфов, пойму, что написана чушь.
А решив, что там не чушь, вы уже не сможете нормально прочитать статью, потому что картинки-то не прогрузились, а вы уже ушли в оффлайн и не можете их прогрузить. Ну или не ушли, но беситесь от каждой прогрузки — интернет-то не обещал быть быстрым
И у вас всё ещё есть возможность тыкнуть на другую рандомную статью и получить
ничего, потому что в моём кэше оказалась всего одна статья
Вы даже не поняли, о чём вам говорят.
Прекрасно понял
Проспитесь перед следующим ответом.
Проспитесь перед демонстрацией откровенно сломанного сайта в качестве контрпримера 🙃
Сайт для поисковиков действительно приятнее. Но там скорее проблема в дизайне и в том что лейзи лоад картинок сделан не очень правильно. Для них желательно сделать плейсхолдер. Но вообще, сайтов без js больше уже не будет, не очень понятно о чем вы спорите.
Они должны
Не стоит выдавать свои привычки за единственно верный компромисс.
Я не знаю, как работает конкретно ваш сайт
И если чего-то не знаете - можете спросить у автора, чтобы он вас просветил, прежде чем бросаться громкими выводами.
Прекрасно понял
Вы зря не последовали моему совету и напороли ещё больше чуши.
Ужасно неприятно дёргается скроллбар. Технология ради технологии, а юзеру в итоге неудобно.
Как вы думаете, почему технологию дёргающегося скроллбара внедрили к прошлому году все браузеры?
Этот сайт на Next js?
Спасибо за пояснения!
Давно подозревал, что на Хабре каменты сделаны, мягко говоря, через одно место. Частенько читаю здесь статьи на планшете, довольно древненьком. Статьи открываются нормально. Но если начать читать многочисленные каменты, то через ~20 каментов все подвисает наглухо. Легче закрыть.
Кстати, так было не всегда, и с какого момента началось, не помню. Пару лет точно. Может, и больше.
Скажут, что планшет надо обновить. Но так ведут каменты далеко не на всех сайтах.
Иронично, что в реальности всё происходит наоборот — все всё запихивают в веб, и многие «нативные» приложения являются всего лишь обёртками над webview
Многие это сколько в процентном соотношении? Не то чтобы я такие не видел, но большинство из тех что я использую это нативные приложения.
На многостраничных сайтах тоже никто не запрещает использовать JS и сделать богатый UX, это не взаимоисключающие вещи
Конечно никто не запрещает, вот только это ограничено пределами одной страницы. Либо будет загружаться и собираться каждый раз с нуля.
И ничего хорошего в этом нет, по множеству разных причин это лишь приводит к ухудшению качества сайтов
Очень смелое заявление, а можно услышать хоть какие-то пруфы? Я изначально был фулстеком, потом перешёл чисто во фронты, потом вернулся в фулстеки и не вижу никакой проблемы с тем чтобы каждый занимался тем что ему интересно и в чем он имеет наибольшую компетенцию.
Я согласен, что для информационных сайтов концепция многостраничности подходит больше чем SPA. Но нередко их такими делают даже сейчас. А уж когда условный сайт набирает в себя функционал приложения, то тут многостраничности начинает играть уже против него. Хочешь сделать его удобным? Клиент будет на каждой странице загружать и интерпретировать эти удобства. У меня тоже есть знакомый-старовер. Даже плагин написал для сборки фронта на Gradle. Но вот вопрос, зачем все это делать если индустрия пошла другим путем и как то коллективный разум не запнулся, обо все эти аргументы? Наверное если бы все что Вы написали было бы такой большой проблемой, то индустрия откатилась бы хотя бы частично. Но нет, пропускная способность растет, вычислительные способности устройств тоже значительно выше чем в 10-х и современные подходы не создают тех "больших" проблем значение которых Вы преувеличиваете.
Многие это сколько в процентном соотношении? Не то чтобы я такие не видел, но большинство из тех что я использую это нативные приложения.
Надо бы кому-нибудь посчитать точную статистику, а то у нас обоих нерепрезентативные выборки возможно
Конечно никто не запрещает, вот только это ограничено пределами одной страницы. Либо будет загружаться и собираться каждый раз с нуля.
Можно использовать htmx или аналоги для превращения многостраничного сайта в типа-одностраничный и объединения их преимуществ (впрочем, и некоторых недостатков тоже), в качестве широко известного примера такого сайта можно взять ВК, у которого с 2011 года музыка «магическим образом» не прерывается при переходам по страницам
Очень смелое заявление, а можно услышать хоть какие-то пруфы?
В соседней ветке выше расписал во всех подробностях
Клиент будет на каждой странице загружать и интерпретировать эти удобства.
Всё ещё htmx, если настолько критично
пропускная способность растет
В последние три года наоборот падает до уровня диалапа 🙃
современные подходы не создают тех "больших" проблем значение которых Вы преувеличиваете.
В соседней ветке выше мне в качестве контрпримера кинули сайт, на котором уже у двух человек прокрутка лагает блин, ничего я не преувеличиваю
что нынешнее поколение веб-разработчиков разучилось так делать
Ну вот у меня например сайт практически без JS. Там только светлая/тёмная тема и раскраска кода призмой и собсна, всё. Без первого как-то показывать будет, а второе вообще можно через SSR сделать.
Есть правда один нюанс. Я не веб-разработчик.
"Русскоязычное JavaScript сообщество" подготовило статью что JavaScript больше не нужен 😀
из статьи стало понятно, что для анимации, Next.js больше не нужен.
А как при помощи HTML и CSS запросы к API делать?
Чисто в теории, хотя я и понимаю что это ужасно неудобно, но: не использовать апи? Например северный рендеринг с полными переходами? Применимость ограничена, но когда выбор между шашечками и ехать... Хотя опять же, я с трудом представляю где в наше время может встать такой выбор.
Бизнес-логика на js или на бэкэнде, гуй на html+css – вроде логично...
Ну, что "не нужен" вместо "нужен меньше" - это автор явно для красного словца, а что его взгляд, по определению капиталистический, которым он и хочет поделиться, не видит того, что CSS действует не сам по себе, а через свойство style которое JavaScript может изменить, соответственно требуя немедленного рассмотрения шансов столкнуться с парадоксом Джевонса - это странно...
Хотелось бы и в SVG нововведения, чтобы приблизить к возможностям drawio, yEd и т.п. Например, соединения фигур через target \ source, перенос слов (по размеру фигуры) и др.
«Но CSS же отстой»
«Но писать же на CSS больно»
Кто все эти люди?
Я что-то пропустил или HTML и CSS научились запрос к серверу делать и без перезагрузки страницы?
Ну url() вполне работает с переменными, которые могут например анимироваться через keyframes.
Так-то я видел калькулятор, написанный полностью на CSS (ну, дивы с кнопками цифр на HTML разумеется)
ну это не совсем то. Именно обработчику как доставить данные, получить и разместить на странице? Увы только <form> с перезагрузкой.
"Так-то я видел калькулятор, написанный полностью на CSS (ну, дивы с кнопками цифр на HTML разумеется)"
интересно было бы взглянуть - наверное действия пользователя можно анимацией css, но вычисления, даже простейшие, это мне совсем не ясно.
&>div {
Я вот за годы практики так и не понял: эта вложенность - благо, или же зло.
Потому что потом пытаться понять, откуда чёрт возьми прилетает этот стиль, который по ctrl + f в коде не ищется - та ещё задача. Особенно когда ещё и стили перекомпилятся из нормальных названий в какой-нибудь random hex.
для компонентов - добро, удобно окинуть взглядом все разом. Для проект - зло.
Основной стиль, например таблицы, будет ниразу не простым и он долежн быть очень хорошо читаемым, чтобы не превратиться в помойку. И стили компонентво общего назначения тоже, я считаю, прочесть одной строчкой
table.datagrid > thead > tr.filters > td
Куда легче чем то что получится в sass файле.
Но... всем же плевать. Сейчас мало кто реально пишет стили от контейнера, так чтобы содержимое знать не знало где оно находится. Сейчас нахреначить костылей прямо в элемент - норма.
Это не работает в нормальных больших продуктах – лишняя вложенность DOM, сложные селекторы, сильно вложенные селекторы – в большом продукте это приводит к значительным тормозам UI.
И вот еще бонусом, почему это не работает:
Адаптация под мобилку – мобилки сильно слабее десктопов, и новые модные решения без контроля приводят к рефлоу такой длительности, что приложение начинает нещадно тормозить на мобилке (рефлоу занимает секунды)
Поддержка браузеров – большие продукты поддерживают довольно старые браузеры, иногда 4-6+ лет давности, и многие фишки перестают работать
Иногда работает не стабильно – возьмите даже старую штуковину вроде clip-path, и в разных браузерах она может себя вести по разному
Хотите стабильное решение – пишите минимальную разметку, пишите минимум CSS, никакого OOCSS, минимум вложенности, минимум влияния элементов друг на друга, и получите нормальные быстрые решения.
Именно поэтому все не слазят с простой верстки дивами без модных фишек, через BEM-нейминг, и с разработкой на JS – это работает быстро и стабильно (про кривые решения на JS не говорим, это отдельная тема).
повеяло прохладными историями из нулевых, когда яндексоиды пиарили свой бэм:)
мобилки сильно слабее десктопов
Мобилки из-за разных сроков жизни с десктопами часто быстрее десктопов. Мобил младше 2020 уже нет в живых. Десктопы из 2016 вполне себе встречаются.
Поддержка браузеров – большие продукты поддерживают довольно старые браузеры, иногда 4-6+ лет давности, и многие фишки перестают работать
Тут каждый сам решает, один мой продакт сказал, пусть такие клиенты идут к конкурентам, и они с ними еб...тся.
И не будет ни театров, ни книг, ни кино. Одно сплошное CSS (С)
Да JS порой переизбыток, но совсем от него отказаться низзя.
В некоторых случаях всё же можно. Но даже в них с большой долей вероятности дешевле использовать js. Я, например, ноль в реакте, мои познания в js застряли ещё во временах когда jquery был чем то актуальным, и даже тогда я предпочитал чистый js. И в проекте над которым я сейчас тружусь я легко себе представляю как сделать всё без js вообще с потерей очень-очень небольшой части юзабилити, а если всё же добавить строк 500-1000 "чистого" js для динамического обновления того что обновлять всё же надо-и вовсе вышло бы без потери юзабилити. Но. Это бы значило огромную гору дополнительной работы специалиста который очень хорошо понимает что делает, и самоограничений. А поскольку фронт всё же сделан не минималистично, а через react с кучей сопутствующих штук-можно просто нанять трейни-фронтендера из Индии, который будет за мало денег рисовать свои стандартные элементы, и работать так как оно у них там в реакте заведено(что в конечном итоге и произошло). И хоть по итогу фронтенд проекта сжирает в, наверное, десятки раз больше вычислительных ресурсов конечных пользователей, это всё равно более разумный подход с точки зрения бизнеса. Ведь сопровождаемость и расширяемость такого решения куда лучше.
Это что, теперь еще и на CSS бизнес-логику потащат, а потом еще и какой-нибудь TCSS со строгой типизацией? :)
«фрагменты» изображения — чтобы вырезать нужный кусочек из большого (как в spritesheets). … Да, мы уже можем делать и fallback, и спрайты через разные свойства background
Нормально смапить фрагмент на элемент через background — это жопа. Так что, очень полезная фича.
Ну и рассосётся, наконец, вечная путаница, когда для n кадров надо 100% делить на n - 1. Пишут, что… “The spacial dimension definition in the media specification indicates that percentages will be supported as well”.
Пишу на JS без говно_фреймворков, потому что в JS и PHP куча встроенных функций на любой случай
Я могу вытворять чудеса и на ваниле и люблю чистый CSS но броузероделатели вместе с W3C сами текущую ситуацию создали. Вон новость что пару лет назад popover стал production-ready, ну слава богу, мне всего то пришлось подождать 25 лет.
Что нам надо было? Глубоко кастомизируемые modal/popover а лучше полной управление над семантическими alert/confirm. И все, мы были бы счастливы, страницы были бы в разы проще, броузер не жрал бы как не в себя. Но нет, они занимались какой то херней, дождались пока мы напишем все что только можно, дождались shadow dom (где то тут мимо пробегают бесполезные семантические теги), дождались пока научились строить монстров на data-аттрибутах (в лучшем случае) и таки начали делать то что сделать нужно было изначально.
Но при этом продолжают какой то мурней параллельно заниматься. Ну например, сделали поповер, уже неплохо, а можно теперь броузерный менеджер модальных окон? Нет? жаль... а вот всякие datepicker которые пока не догнали по удобству все что люди руками сделали еще году эдак в 2008, это пожалуйста...
можно теперь броузерный менеджер модальных окон?
А мне вот наоборот нравится, что (иногда) HTML/CSS/JS движется в сторону универсальности, а не частных решений. Зачем такие вещи как внутриброузерный менеджер модальных окон (или, скажем, движок шаблонов), когда их можно в три строки написать?
Другое дело, полноценные модальные окна на основе CSS (в т.ч. opacity), понятно, что самому это не эмулировать. Я такие использовал в одном специализированном браузерном движке. Но в браузерах общего назначения их по понятным причинам не будет никогда.
Зачем
Сейчас? уже незачем. Изанчально затем чтобы не превращать броузер в банальный интерпретатор кода, чем он сейчас и явлется. А вы видели что люди на канве вытворяют? Да даже и без нее я видел дочерта кода с определением координат под курсором и сам не раз писал хитрые функции универсального позиционирования.
А вы видели что люди на канве вытворяют?
Видел, конечно. Как разработчики по привычке собирают пулемёт. Не понимая, что объектная модель это лучшее, что есть в HTML.
Но я рад, что и раньше не сделали этот менеджер. Сегодня была бы ещё одна легаси-фича, которую надо было бы таскать. Да и поповеры, честно говоря, тоже сомнительное нововведение. Я не говорю — плохое или ненужное, просто особой радости оно не вызывает (в отличие от image() с фрагментами, например). Опять же, есть функционал, который никак не сэмулировать — вот ему я бы порадовался. Например, выход всплывашки за границы окна при соблюдении требований безопасности ОС (допустим, ограничения на типы элементов или на размер). В IE, кстати, такое было. Соблюдай лимиты в 300 точек по ширине и минимум оформления (курсив, полужирный, над- и подстрочность), и вперёд. Очень удобно было, когда встраиваешь окно браузера в приложение. Можно было тултипы показывать по-человечески.
Я не говорю — плохое или ненужное, просто особой радости оно не вызывает
Почему? на JS нет всеохватывающей реализации poppup/popover. Я спокойно за 30 секунд нахожу глюк в почти любой из них.
пять же, есть функционал, который никак не сэмулировать — вот ему я бы порадовался.
Бесспорно, но я в это не верю.
PS а чего там про image() ?
Шли годы...
Safari сейчас некорректно обрабатывает единицы измерения cqw/cqh, поэтому демо выше может работать неправильно. Если это произошло, попробуйте открыть его в Firefox или Chrome
Например, вложенность полностью поддерживается во всех браузерах с декабря 2023 года и станет «широко доступной» в июне 2026-го.
Второй вариант пока работает только в браузерах на Chromium и требует одной строки JavaScript:
И хорошие новости — похоже, это мы действительно скоро получим!
Функция image() существует, но её пока не реализовал ни один браузер.
"Java- and TypeScript" из оригинала статьи превратилась у переводчика в "Java и TypeScript". Казалось бы - один маленький дефис, но...
Современный CSS крут. Как и современный JS. Но нужно ли пытаться принижать один, чтобы показать достоинства второго?
Автор говорит про то что всё поменялось с тех пор как CSS был ненавистен. Но в то же время размышляет о том что у пользователей может быть отключён JS. Действительно, может они выбрали VBScript?) Когда то и я отключал js, но это было лет 15 назад. Сейчас какого то смысла в этом я не вижу - браузеры научились делать "песочницы" для приватных страниц. А, если вас не устраивает производительность JS на каком то конкретном сайте, то поверьте без JS вы его вообще не увидите.
Рассуждения про скорость CSS относительно JS во всех сферах кроме анимации мне тоже кажутся надуманными. Автор похоже сравнивает reactjs и создание аккордиона на css. Если нужно просто переключать состояния, то разницы между JS и CSS вы не заметите. А, если вам нужно сложное приложение с авторизацией, историей, сложной логикой, то тут CSS вам ничем не поможет и не должен. HTML, CSS, JS хорошо дополняют друг друга.
Но я не отрицаю что существует миграция каких то стандартных решений из JS в CSS. JS, благодаря своей гибкости, когда то позволил закрыть недостатки CSS. Сейчас CSS развивается и часть этих задач теперь удобнее решать на нём. И для этого необязательно отказываться от JS.
Верните адоб флеш на сайты
Вам больше не нужен JavaScript