У меня очень странная проблема с браузером. Скрипты на некоторых страницах просто не работают, пока не пройдёт около 20 секунд.
Что бы вы ни собирались предложить — да, я уже думала об этом, и нет, не помогло. Я рассказываю об этом не в надежде, что кто-то подскажет с отладкой, а потому что этот случай заставил меня остро осознать некоторые, как бы сказать… причуды… разработки на фронте.
(В самом деле, даже не пытайтесь диагностировать проблему по одному предложению, не надо, я слышала и перепробовала почти всё, что вы можете себе представить).
Статья написана в марте 2016 года, некоторые примеры устарели — прим. пер.
Смотрите, вот скриншот твита. В нём красным цветом выделены те части, которые не работают без JavaScript. Я это знаю, потому что по-прежнему 20 секунд гляжу на страницу, на которой ещё не сработала большая часть кода.
Кое-что я могу понять. Например, кнопка «Ответить» разворачивает текстовое поле внизу и переводит на него фокус. Этого никак не сделать без некоторых скриптов. Кнопка
С другой стороны…
Эта кнопка ? в правом верхнем углу и все пустое окружающее пространство? Их единственная функция — отправить вас в мой профиль, который виден за твитом. С таким же успехом они могли быть обычными ссылками, как стрелки влево и вправо для навигации. Но это сделано иначе, поэтому не работает без JavaScript.
Или маленькая кнопка с графиками, для аналитики? Её единственная функция — загрузить другую страницу в искусственном всплывающем окне со встроенным фреймом. Здесь могла быть обычная ссылка, которая превращается во всплывающее окно с помощью скрипта. Но это сделано иначе, поэтому не работает без JavaScript.
Текстовое поле? Конечно, это просто текстовое поле. Но если нажать на него до запуска JavaScript, в поле останется неуклюжая надпись
То же самое происходит на странице поиска Twitter, что очень странно, потому что в поле поиска нет текста! Если вы начнёте печатать до окончания работы скриптов, они просто сотрут всё, что вы набрали. Даже не для того, чтобы вставить свой текст-заполнитель или применить пользовательский стиль. Без всякой видимой причины, просто так.
Поскольку у меня работает NoScript, я частенько замечаю странные дизайнерские решения на сайтах, которые посещаю впервые. Конечно, пустые белые страницы — обычное дело. Довольно долго статьи на сайте Time отлично загружались без скрипта, но только не прокручивались — для страницы применялось свойство
Для этого нет никаких веских причин. Это не передовые интерактивные приложения, это просто страницы с текстом. Мы раньше их печатали на бумаге, но как только перешли на информационные технологии, стало невозможно поместить слова на экран, не запустив на исполнение несколько мегабайт мусора?
Я прямо слышу, как меня называют луддиткой, потому что я не согласна окружать пять абзацев статического текста тысячами строк скриптов. Ну, позвольте заранее ответить: идите в баню. Я думаю, что веб и интерактивные страницы — это здорово, я вижу отличный прогресс в последнее десятилетие. Просто супер, что веб изначально поддерживал пользовательские настройки, а я могу заранее настроить для каждого сайта разрешения, что он может запускать на моём компьютере, а что нет.
А вот что не очень здорово, так это группа высокооплачиваемых и высококвалифицированных специалистов, у каждого из которых установлен Chrome на последней модели Mac Pro, которые работают в офисе на расстоянии не больше километра от каждого сервера, на который они заходят. И вот эти ребята работают, а потом поворачиваются и хихикают над всеми остальными, у кого нет такой конфигурации. Учтите, что любое из следующих условий помешает работе вашего JavaScript:
Я не говорю, что следует стереть с лица Земли интерактивные веб-приложения, такие как Google Maps, хотя даже для Google Maps много лет был запасной вариант без скриптов, до текущей версии WebGL! Я говорю, что мы свернули куда-то не туда, когда базовые функции обычного HTML вдруг перестали работать без JavaScript. А именно, без 40 мегабайт JavaScript, согласно
Вам действительно нужно постараться, чтобы добиться такого плачевного результата. Я имею в виду, если вам нужна ссылка, вы просто пишете
Нет! Вы получите лишь бледную, дрянную имитацию ссылки. Рассмотрим все функции нативных ссылок:
Общая нить здесь заключается в том, что тег
Вот что люди имеют в виду, когда говорят о «семантике» — что есть полезная информация, которую нужно собрать. Если вы начинаете изобретать подобие ссылок, то анализ этого синтетического конструкта потребует либо спекулятивного выполнения большого количества произвольного кода, либо написания чрезвычайно умного статического анализатора, либо просто обучения программиста-человека. Декларирование намерений — гораздо более мощный и гибкий метод, чем просто выполнение работы, потому что в первом случае универсальные инструменты делают полезные вещи почти тривиально.
Еще один хороший пример — выпадающие формы
Самодельное текстовое поле Twitter — это вовсе не текстовое поле, а
Вы знаете, что на некоторых сайтах работают горячие клавиши? Мило, правда? Но на самом деле
Тут вспомнилось, что каждая страница Twitter молча поглощает любые события клавиатуры и нажатия мыши, пока не отработают все скрипты. Это означает, что я не могу даже сменить вкладку, пока не подожду эти 20 секунд загрузки страницы: ctrl-t, ctrl-w, ctrl-tab, ctrl-pgup и ctrl-pgdn — все события клавиатуры полностью поглощаются. Так работает механизм под названием «очередь быстрых действий» (swift action queue). Звучит так, будто эта очередь должна воспроизводить события по окончании загрузки страницы, но (а) вы не можете воспользоваться горячими клавишами в браузере; (б) похоже, она всё равно не работает. Чтобы это исправить, мне пришлось написать пользовательский скрипт, чтобы заблокировать тег скрипта с определённым идентификатором.
Я не думаю, что очень привередничаю. Это базовые функции браузера, и вы их нарушаете, часто без уважительной причины. Я не ожидаю, что вы заставите Google Docs работать без JavaScript. Я просто надеюсь, что вы не сломаете мою чёртову клавиатуру.
Примите тот факт, что иногда для некоторых людей ваш JavaScript не будет работать. Подумайте, что это значит. Когда есть выбор, всегда выбирайте существующие HTML-механизмы. Может, раз в год ваша команда разработчиков отключит JavaScript и попытается использовать сайт. Начинай плакать.
Если вы собираетесь переопределить или переосмыслить то, что уже существует, сначала изучите это. Вы не можете создать хорошую замену без понимания оригинала. Поспрашивайте вокруг. Чёрт, просто попробуйте нажать
Помните, что при всей власти, которую даёт вам интернет, в конечном счёте контроль всё равно находится в руках пользователя. Интернет — это не игровая приставка, действуйте соответственно. Создавайте модули. Заранее учитывайте вероятные или распространённые настройки. Может, что-нибудь немного уменьшить, когда достигнете 40 мегабайт скриптов на странице.
Спасибо.
Что бы вы ни собирались предложить — да, я уже думала об этом, и нет, не помогло. Я рассказываю об этом не в надежде, что кто-то подскажет с отладкой, а потому что этот случай заставил меня остро осознать некоторые, как бы сказать… причуды… разработки на фронте.
(В самом деле, даже не пытайтесь диагностировать проблему по одному предложению, не надо, я слышала и перепробовала почти всё, что вы можете себе представить).
Статья написана в марте 2016 года, некоторые примеры устарели — прим. пер.
Бесполезные страницы
Смотрите, вот скриншот твита. В нём красным цветом выделены те части, которые не работают без JavaScript. Я это знаю, потому что по-прежнему 20 секунд гляжу на страницу, на которой ещё не сработала большая часть кода.
Кое-что я могу понять. Например, кнопка «Ответить» разворачивает текстовое поле внизу и переводит на него фокус. Этого никак не сделать без некоторых скриптов. Кнопка
...
открывает всплывающее меню, что сомнительно, так как вы можете воспроизвести его и с помощью CSS. Аналогично, кнопка с сердечком выполняет действие в фоновом режиме, что тоже является сомнительным, поскольку его можно воспроизвести с полной загрузкой страницы. Но это нетривиальные изменения, которые будут работать совершенно по-разному со скриптами и без.С другой стороны…
Эта кнопка ? в правом верхнем углу и все пустое окружающее пространство? Их единственная функция — отправить вас в мой профиль, который виден за твитом. С таким же успехом они могли быть обычными ссылками, как стрелки влево и вправо для навигации. Но это сделано иначе, поэтому не работает без JavaScript.
Или маленькая кнопка с графиками, для аналитики? Её единственная функция — загрузить другую страницу в искусственном всплывающем окне со встроенным фреймом. Здесь могла быть обычная ссылка, которая превращается во всплывающее окно с помощью скрипта. Но это сделано иначе, поэтому не работает без JavaScript.
Текстовое поле? Конечно, это просто текстовое поле. Но если нажать на него до запуска JavaScript, в поле останется неуклюжая надпись
Reply to @eevee
. А когда скрипт всё-таки запускается, он стирает всё, что вы набрали, и снова вставляет Reply to @eevee
, только теперь @eevee
написано синенькими буквами, а не серенькими.То же самое происходит на странице поиска Twitter, что очень странно, потому что в поле поиска нет текста! Если вы начнёте печатать до окончания работы скриптов, они просто сотрут всё, что вы набрали. Даже не для того, чтобы вставить свой текст-заполнитель или применить пользовательский стиль. Без всякой видимой причины, просто так.
Поскольку у меня работает NoScript, я частенько замечаю странные дизайнерские решения на сайтах, которые посещаю впервые. Конечно, пустые белые страницы — обычное дело. Довольно долго статьи на сайте Time отлично загружались без скрипта, но только не прокручивались — для страницы применялось свойство
overflow: hidden;
по причинам, которые я не могу понять. Статьи Vox также загружаются нормально, за исключением того, что перед каждым изображением выводится пустое пространство на всю высоту экрана. Некоторые особенно плохие корпоративные сайты представляют собой месиво перекрывающихся блоков текста. Думаю, что они отказались от CSS и написали макет на JavaScript.Для этого нет никаких веских причин. Это не передовые интерактивные приложения, это просто страницы с текстом. Мы раньше их печатали на бумаге, но как только перешли на информационные технологии, стало невозможно поместить слова на экран, не запустив на исполнение несколько мегабайт мусора?
Я прямо слышу, как меня называют луддиткой, потому что я не согласна окружать пять абзацев статического текста тысячами строк скриптов. Ну, позвольте заранее ответить: идите в баню. Я думаю, что веб и интерактивные страницы — это здорово, я вижу отличный прогресс в последнее десятилетие. Просто супер, что веб изначально поддерживал пользовательские настройки, а я могу заранее настроить для каждого сайта разрешения, что он может запускать на моём компьютере, а что нет.
А вот что не очень здорово, так это группа высокооплачиваемых и высококвалифицированных специалистов, у каждого из которых установлен Chrome на последней модели Mac Pro, которые работают в офисе на расстоянии не больше километра от каждого сервера, на который они заходят. И вот эти ребята работают, а потом поворачиваются и хихикают над всеми остальными, у кого нет такой конфигурации. Учтите, что любое из следующих условий помешает работе вашего JavaScript:
- Кто-то на медленном компьютере.
- Кто-то на медленном соединении.
- Кто-то на телефоне, то есть на медленном компьютере с медленным соединением.
- Кто-то застрял со старым браузером на компьютере, который он не контролирует — на работе, в школе, в библиотеке и т. д.
- Кто-то пытается написать небольшую программу, которая взаимодействует с вашим сайтом, у которого нет API.
- Кто-то пытается загрузить копию вашего сайта, чтобы почитать в офлайне.
- Кто-то — это кэш Google или Архив Интернета.
- Кто-то сломал графическое окружение в Linux и пытается выяснить, как его починить, загружая статьи с вашего сайта через браузер командной строки Elinks.
- Кто-то внёс изменения в ваш сайт с помощью пользовательского скрипта, и это мешает вашему собственному коду.
- Кто-то использует NoScript и видит на вашем сайте только пустой экран. Он настолько раздражён, что просто уходит, а не вносит ваш сайт в белый список.
- Кто-то использует NoScript и вносит в белый список вас, но ни один из десятков трекеров, которые вы используете. Позже вы случайно ставите скрипт в зависимость от трекера, и он таинственным образом больше не работает для таких пользователей.
- Вы даёте критически важному скрипту название, связанное с рекламой, и он не загружается у десятков миллионов пользователей с блокировщиками рекламы.
- Ваш CDN упал.
- У вашего CDN есть адрес IPv6, но на самом деле он не работает (да, я видела такое и у компаний стоимостью в миллиард долларов, и у федерального правительства). Заходит кто-то по IPv6, страница загружается, но JS вылетает по таймауту.
- Ваш деплой идёт немного неудачно, и JavaScript повреждается.
- Вы случайно использовали новую функцию, которая не работает в предыдущей версии самого популярного браузера. Выводится синтаксическая ошибка, и ни один из ваших сценариев не запускается.
- Вы прямо вводите синтаксическую ошибку, и никто не замечает, пока она не попадает в продакшн.
Я не говорю, что следует стереть с лица Земли интерактивные веб-приложения, такие как Google Maps, хотя даже для Google Maps много лет был запасной вариант без скриптов, до текущей версии WebGL! Я говорю, что мы свернули куда-то не туда, когда базовые функции обычного HTML вдруг перестали работать без JavaScript. А именно, без 40 мегабайт JavaScript, согласно
about:memory
— это данные в памяти, а не размер загрузки. Это может показаться не очень много (для страницы, которая выводит на экран 140 символов?), но в моём браузере часто накапливается десяток открытых вкладок Twitter, то есть полгигабайта памяти, выделенных максимум на 6 КБ текста.Изобретение квадратного колеса
Вам действительно нужно постараться, чтобы добиться такого плачевного результата. Я имею в виду, если вам нужна ссылка, вы просто пишете
<a href="somewhere">label</a>
, и готово. Но если вы начнёте изобретать это с помощью JavaScript, то нужен обработчик кликов, и он должен работать в нужное время, чтобы вы знали, что ссылка действительно существует, и, возможно, вам придётся сделать некоторую работу, чтобы добавить обработчики кликов к фальшивым ссылкам, которые добавляет Ajax. Так ведь?Нет! Вы получите лишь бледную, дрянную имитацию ссылки. Рассмотрим все функции нативных ссылок:
- Я могу перейти по ссылке.
- Я могу открыть ссылку в новой вкладке или окне с помощью комбинации клавиш ctrl, shift и колёсика (средней кнопки) мыши.
- Я могу скопировать адрес ссылки и вставить его куда-нибудь или открыть в другом браузере, или ещё что-нибудь.
- Я могу использовать
'
в Firefox для поиска только ссылок.
- В некоторых браузерах — Opera, Konqueror, uzbl, Firefox с vimperator? — есть горячая клавиша, которая показывает цифру или букву рядом с каждой ссылкой на странице, так что вы можете очень быстро «щёлкнуть» ссылку визуально, даже не касаясь мыши.
- Я считаю, что скринридеры обрабатывают ссылки специальным образом.
- Простые краулеры составляют по ссылкам карту сайта.
- Браузеры начинают экспериментировать с предварительной загрузкой видных ссылок, так что если пользователь действительно нажимает на неё, то страница открывается мгновенно.
Общая нить здесь заключается в том, что тег
<a href=...>
нечто значит. Он говорит: «Это путь, по которому можно пройти». Тонны инструментов полагаются на эту информацию. Если заменить его на <div onclick>
, то да, нажатие на div что-то сделает, но весь смысл полностью потерян. И наоборот, если использовать <a href="javascript:void(0);">
, то вы фактически лжёте этим инструментам; вы вызываете смысл, но отдаёте бессмысленную информацию.Вот что люди имеют в виду, когда говорят о «семантике» — что есть полезная информация, которую нужно собрать. Если вы начинаете изобретать подобие ссылок, то анализ этого синтетического конструкта потребует либо спекулятивного выполнения большого количества произвольного кода, либо написания чрезвычайно умного статического анализатора, либо просто обучения программиста-человека. Декларирование намерений — гораздо более мощный и гибкий метод, чем просто выполнение работы, потому что в первом случае универсальные инструменты делают полезные вещи почти тривиально.
Еще один хороший пример — выпадающие формы
<select>
. Некоторые разработчики иногда полностью с нуля создают свою замену из неродных виджетов. Наверное, чтобы сделать их красивее? Благородная цель. Но знаете ли вы, что в нативных выпадающих формах при начале набора текста автоматически выбирается первая подходящая позиция? Очевидно, в большинстве альтернативных реализаций это не поддерживается. Визуально они выглядят лучше (или просто иначе), но функционально намного хуже для длинных списков.Самодельное текстовое поле Twitter — это вовсе не текстовое поле, а
contenteditable
<div>
. Здесь contenteditable
означает, что большинство нативных элементов управления работают довольно хорошо, но всё равно этот объект время от времени демонстрирует некое странное поведение, например, перемещает курсор в начало текста, когда я переключаюсь между вкладками. Или иногда у скрипта возникают какие-то проблемы с моей скоростью набора и он начинает з а м е т н о о т с т а в а т ь. Единственная причина, зачем вообще ставить его вместо обычного <textarea>, кажется, это чтобы подкрасить @handles
и ссылки синим цветом? Самодельное текстовое поле не сокращает ссылки и не заменяет твиттеровские эмодзи, поэтому на самом деле это не предварительный просмотр того, как будет выглядеть ваш твит.Вы знаете, что на некоторых сайтах работают горячие клавиши? Мило, правда? Но на самом деле
/
— это встроенная в Firefox горячая клавиша, которая открывает панель быстрого поиска. Очевидно, никто в Twitter или GitHub, или BitBucket, или Tumblr, или в десятке других мест не знает об этом, потому что все они назначили этой клавише перемещение фокуса на собственную панель поиска по сайту. Что полностью отличается от поиска на текущей странице (к чести GitHub, они это исправили, когда я пожаловалась в твиттере). В течение длительного времени Google+ отключал пробел для прокрутки вниз. Почему никто в этих огромных компаниях не остановился и не сказал: «Эй, подождите, это ведь рабочая функция в браузере, а мы её ломаем»? Веб-разработчики сами вообще пользуются браузерами?Тут вспомнилось, что каждая страница Twitter молча поглощает любые события клавиатуры и нажатия мыши, пока не отработают все скрипты. Это означает, что я не могу даже сменить вкладку, пока не подожду эти 20 секунд загрузки страницы: ctrl-t, ctrl-w, ctrl-tab, ctrl-pgup и ctrl-pgdn — все события клавиатуры полностью поглощаются. Так работает механизм под названием «очередь быстрых действий» (swift action queue). Звучит так, будто эта очередь должна воспроизводить события по окончании загрузки страницы, но (а) вы не можете воспользоваться горячими клавишами в браузере; (б) похоже, она всё равно не работает. Чтобы это исправить, мне пришлось написать пользовательский скрипт, чтобы заблокировать тег скрипта с определённым идентификатором.
Я не думаю, что очень привередничаю. Это базовые функции браузера, и вы их нарушаете, часто без уважительной причины. Я не ожидаю, что вы заставите Google Docs работать без JavaScript. Я просто надеюсь, что вы не сломаете мою чёртову клавиатуру.
Позвольте дать совет
Примите тот факт, что иногда для некоторых людей ваш JavaScript не будет работать. Подумайте, что это значит. Когда есть выбор, всегда выбирайте существующие HTML-механизмы. Может, раз в год ваша команда разработчиков отключит JavaScript и попытается использовать сайт. Начинай плакать.
Если вы собираетесь переопределить или переосмыслить то, что уже существует, сначала изучите это. Вы не можете создать хорошую замену без понимания оригинала. Поспрашивайте вокруг. Чёрт, просто попробуйте нажать
/
в браузере, прежде чем делать это горячей клавишей на своём сайте.Помните, что при всей власти, которую даёт вам интернет, в конечном счёте контроль всё равно находится в руках пользователя. Интернет — это не игровая приставка, действуйте соответственно. Создавайте модули. Заранее учитывайте вероятные или распространённые настройки. Может, что-нибудь немного уменьшить, когда достигнете 40 мегабайт скриптов на странице.
Спасибо.
EvilGenius18
Может, нам слегка успокоиться с С++? А то я написал тяжелое синхронной вычисление, и программа зависла, жду уже 20 секунд. Но это не моя вина, это вина C++, честно-честно.
Я начинающий разработчик и даже у меня все веб проекты загружаются быстро только потому что я использую lazy-loading технику для всего — от картинок до скриптов. Большинство нормальных разработчиков это знают и применяют.
Только вот разработчики Хабра этого почему то не знают — все картинки страницы загружаются сразу при загрузке страницы. Позор.
Но вообще, я тоже могу замедлить свое соединение до 50 Кб/с и жаловаться что у меня страницы долго загружаются. Где все эти выдуманные страницы, которые загружаются по 20 секунд на нормальном соединении (1+ Мб/с)? Можно хоть один пример хоть сколько-нибудь популярного сайта с такой проблемой?
justhabrauser
Легко.
Вот прям сейчас (macOS, Safari, машинка довольно старенькая (MacBook Pro mid 2012, 4GB RAM) и перегружена сейчас):
— yandex.ru — 12"
— ya.ru — 45".
Сорок Пять Секунд, Карл!
Одна строка ввода, один батон и две ссылки!
На канале 100 честных мегабит, на минуточку.
Я не знаю, какую оно нефть качает по дороге, в отладчике написано среди прочего «Refused to execute a script because трамтарамтарам» и еще куча ашыпак.
Safari таки показало то, что нужно (и как смогло), но сильно обижается.
VMichael
Вот прямо сейчас ya.ru — 1 сек.
Машина ноутбук Dell Core i5 не топовый, 3-й год работает.
Я.Браузер.
justhabrauser
В то, что Я.Браузер быстро открывает Я.Ру — верю.
Мне, что ли, подбирать браузер под каждый сайт?
Как правильно — "ваш браузер несовместим с нашим сайтом" или "наш сайт не совместим с вашим браузером"?
Но вообще речь шла об излишнем увлечении JS.
Страница ya.ru занимает 30KB почти чистокровного JS с небольшим включением HTML.
Вопрос — нафейхоа оно мне, как потребителю?
Что эти навороты делают для меня такого, без чего вот тресни невозможно обойтись?
И из-за чего я должен мучительно ждать загрузку этой простенькой странички.
VMichael
Ну, думаю браузер тут ни при чем. Просто я им пользуюсь, потому его привел.
Понятно, про что статья, вы привели цифры, я их проверил у себя.
Отличия очень большие, потому, предполагаю, какая то проблема у вас, кроме организации страницы. И раз так делают, предполагаю, вы входите в тот малый процент, которым пренебрегают разработчики. Увы, ориентируются в первую очередь на большинство, плюс еще на платежеспособные группы. Альтруистов, работающих ради блага других как то мало в этом мире (в относительных цифрах).
Поэтому вы должны мучительно долго ждать загрузку. Впрочем никто не заставляет ждать, это ваш выбор или попробуйте найти другую быструю для вас страничку, или займитесь чем то другим.
justhabrauser
Я думаю разработчики пренебрегают не процентом посетителей, а стандартами:
[Error] Refused to execute a script because its hash, its nonce, or 'unsafe-inline' does not appear in the script-src directive of the Content Security Policy. (ya.ru, line 0)
Оно даже валидатор не проходит нормально.
То есть мы имеем излишнюю увлеченность полезной, в общем-то, технологией в комплекте с неряшливой реализацией.
mickvav
А вам оператор связи (привет, Ростелеком) случайно не пытается свой треккинг воткнуть вместо яндексовского?
justhabrauser
Может и пытается (от Ростелекома "спс"), но https же.
Да и другие браузеры (лиса) открывают шустрее.
Может потому, что просто похеривают кривости уеб-страниц.
vyatkh1
Фронтэндеры — тоже люди. И у них есть дети.
AndreyHenneberg
Которые в будущем их проклянут за то, во что их родители превратили Интернет.
d-stream
Студия, которая визуал — на второй-третьей минуте ребилда большого проекта становится слышно работу вентиляторов ноутбука, через полминуты после окончания — вентиляторы затихают…
Сейчас — 4 вкладки хабра — вентиляторы уже полчаса не умолкают…
nikolayv81
А на ff мобильном "комментарии" вообще может повесить страницу(с сообщением о неотвечающем скрипте) и не отображаются если больше пары сотен… :)
Мобильный хабр только под хром!
p.s. нет никаких резалок/vpn/ плагинов и т.п.
d-stream
Может и опаздывать за набором на несколько секунд… иногда и минут)
Впрочем я скорее об аппетитах нынешних сайтов. Если раньше народ веселило «мне бы попроще и подешевле компьютер для игрушек», то сейчас уже реально подкрадывается момент когда «этот суперкомпьютер сможет открывать даже интернет-сайты»)))
AndreyHenneberg
Вот ровно об это я и споткнулся: в конце 2011 купил нетбук, то есть компьютер, предназначенный для работы в сети. Причём, по тем временам это была довольно мощная машина — Atom N570 (1,66ГГц, 2 ядра, 4 потока), максимальные для этой железки 2 Гб. Покупал для разработки, которая на нём и велась до тех пор, как я три года назад случайно купил старый, но бодрый дэсктоп. Так вот, на компьютере, на котором отлично шла разработка и как-то даже бегал Eclipse, браузер работал с таким скрипом, что было очень тоскливо. При этом, пустой браузер машину не особо нагружал, но вот некоторые сайты просто доводили аппарат до заморозки. А некоторым удавалось вызывать падение браузера.
kbaa
у меня последние примерно полгода на телефоне вообще комментарии на хабре не подгружаются
wladyspb
Вот прямо сейчас, ya.ru — 5.77 сек.
Машинка хорошая, i7, 8 гб, ssd.
Основное отличие — браузер chromium.
Объективно — львиную долю времени съел 302 редирект с днс лукапом. Но даже после перезагрузки, зная куда идти — страница загружается за 1.4 секунды, что, на мой взгляд, многовато для одной строки поиска.
А главная страница яндекса загружается за 2.8 секунды, и продолжает что-то подгружать ещё секунд 15. Первый заход на страницу инициировал загрузку шести мегабайт материалов. 208 запросов.
victoriously
yandex.ru продолжает что-то грузить уже после отрисовки страницы. И, полагаю, будет делать это бесконечно, подгружая свежие курсы валют, погоду, etc.
tandzan
Вот hh.ru, скрипты на текстовой страничке десяток секунд что-то молотят, зачем-то долбятся в локалхост и т.п.
justhabrauser
Потому что у вас в локалхосте должен быть апач, отдающий данные.
У девелов, по крайней мере, так и есть и всё нормально работает.
Так что нечего тут…
Я вот медка хлебнул — и не жужжу ©
tandzan
А может снимается отпечаток пользователя и простукиваются возможные запущенные сервисы, я ж не разбирался.
tmin10
А разве CORS даст так просто подключаться ко всему подряд?
sleirsgoevy
Так просто не даст, но по side effect'ам иногда можно понять, есть там что-то или нет. Кроме того, у сайта может быть субдомен, который резолвится в локалхост, и тогда никакой CORS не поможет.
3263927
а разве на субдомене не отдельная политика?
Zetway
Извините, что такое апач в локалхосте? И почему он прямо должен там быть?
justhabrauser
Веб-сервер такой.
Почему должен там быть — вопрос к разработчикам hh.ru.
sumanai
А почему не Nginx или любой другой из десятков?
t_kanstantsin
Может, потому что это пример?
ds99
что-то хотят
nikolayv81
Как им на корпоративных виртуалках под инет тяжко наверное...
justhabrauser
Как-то немало хотят, однако.
А что, так можно было?
vladkorotnev
Типичный фингерпринтинг при помощи списка открытых портов.
Megavolv
Не подскажете, есть ли способ ограничить взаимодействие сайтов с localhost? Надо признаться, я и не думал, что с этой стороны может быть подобная неприятность.
DistortNeo
А разве в современных браузерах он не запрещён по умолчанию?
AndreyHenneberg
Этот сайт умудрялся даже ронять Firefox. Так что Вы ещё легко отделались.
ivtst1
Вот что что, а с хабром проблем не было.
lunх вам в помощ
Acuna
Это костыль, ибо саму проблему по сути не решает
kocherman
А что такое lunx? Ничего не могу нагуглить.
Может быть, вы имели в виду lynx?
Так есть более продвинутый — links.
И для тех, кто любит версию ncurse, как в BorlandC и Turbo Pascal, — elinks.
Kwisatz
Это вот сейчас серьезно было?
Сходите попробуйте потыкать пост с 1000 комментов.
У меня Ubuntu 18.04 (Firefox), Win 10 Firefox и в этом году:
— две недели страдал из-за страшных тормозов textarea
— неделю не кликались ссылки практически нигде, кроме самых основных
— три недели не кликались ссылки во всех разделах профиля
— постоянно проблемы с постами, при наличии 1000 комментариев
— две недели жутких проблем со скроллом
— неделя проблем со скроллом попроще
И это только то что я вспомнил
kocherman
Выключите лишние расширения, сбросьте конфиг about:config. Всё в порядке и с textarea и ссылками и со скроллом на постах с 1000 комментов. Проверено на ArchLinux 64бит, Celeron 2.6Ghz, 2Gb DDR3 (см. спойлер)
Ни единого фриза. Что ж у вас за компьютеры такие, что web тормозит? Или вы что-то настроили не так?!
Kwisatz
«У вас нога болит? Странно, у меня такая же нога и не болит»
Найдите пожалуйста страницу с 1000 комментами и замерьте время ее загрузки а лучше по ссылке на коммент.
Кроме того вы как то элегантно обошли остальные пункты (подтвержденные администрацией и исправленные).
kocherman
Ну смотрите. Я нашел страницу, перехожу к определенному комменту. Какое-то время подгружаются картинки и прочая медиа из статьи и комментов, причем только та, что не закешировалась браузером. Из-за заранее незивестных размеров картинок страница немного уходит вниз по мере загрузки этих изображений. Ну а так, в целом, после загрузки, всё приблизительно также как и на других страницах Хабра.
Ах, если бы все изображения в комментариях постили под спойлер, страница бы не опускалась во время загрузки этих изображений! Мысли вслух.
u_235
Размеры картинок можно указывать в тегах img, но похоже, это уже из области утерянных знаний.
kocherman
А вы когда пишете комментарий с картинкой, указываете размер картинки в теге?
u_235
Нет конечно, это задача для разработчиков сайта. Но дизайнерам Хабра такое не под силу. А уж от том, что бы сделать превьюшки и только при нажатии грузить фоточки размером 2850?1983 можно только мечтать.
kocherman
Ну, подождите, а откуда разработчикам сайта известна информация о контенте пользователя? Разве за этим должен следить разработчик?
То есть, вы предлагаете загружать на серверы Хабры всю информацию, на которую, вы даёте ссылки в комментариях?
P.S. Мой вопрос не с позиции Роскомнадзора. Само собой, за соблюдением правил сайта может следить и само сообщество Хабры!
khim
На многих форумах действуют именно такие правила и меня бесят те, которые этого не требуют. Потому что открываешь ты какую-нибудь интересную публикацию 10-летней давности… а там картинок-то больше и нету! Были, но… все кончилось.
P.S. Объекты, которые в страницу Хабра не встраиваются, а просто показываются при открытии другой страницы, разумеется могут быть где угодно…
DistortNeo
Вообще-то на Хабре сделано гораздо лучше: через некоторое время после публикации картинки автоматически загружаются на habrastorage. Что мешает при этом прописать размеры изображения — не знаю. Наверное, у разработчиков даже мысли такой не было.
VolCh
Можно при обработке комментария, делать запросы к серверам с картинками, даже не грузить её полностью, а только заголовок, и проставлять размеры.
vladkorotnev
Это вот как раз из-за таких приколистов, когда трафик кончается на телефоне, грузятся только белые страницы с квадратами вместо картинок и пустотой вместо текста, на которой ничего нельзя кликнуть до кучи.
JustDont
Я автора как энтузиастку раннего веба и вообще человека, делающего крутые и забавные вещи — очень уважаю, но.
Уже подумали. Мало того, уже посчитали — и сочли, что проблемы этих некоторых людей не стоят найма программистов и проведения оптимизаций. Проще говоря, пока людей, у которых по некоторым фундаментальным причинам не работает яваскрипт (т.е. им нельзя просто сказать «а ну включили обратно») — мало (а их очень, очень мало) — их проблемы никого не волнуют.
aleksandros
В статье вполне обоснованное доказывается, что некоторые вещи (как минимум), в частности, ссылки, на голом HTML сделать проще и надёжнее. Я даже не говорю про отключение горячих клавиш.
JustDont
Конечно проще. Только нафиг никому не сдалось.
Вот и не делают.
aleksandros
А зачем же отключение клавиш «сделали»?)
VolCh
Не отключение, а сделали свою, не обращая внимания или не зная, что она используется в одном из популярных браузеров. Я вот не знал (скорее не помнил) и если спросили как сделать поиск для гиков, то сказал бы "/" как в vim и ко
Kanut
Сейчас «проще и надёжнее» далеко не всегда в приоритете. Часто в приоритете «быстрее и дешевле». И опять же часто быстрее и дешевле взять какой-нибудь готовый плагин или готовую библиотеку и использовать их.
Особенно если учитывать что «уровень входа» в веб относительно низок, то иногда люди по другому просто и не умеют. Потому что им как на курсах показали, так они и делают…
aleksandros
Может быть. Но Твиттер явно писался с нуля (или почти с нуля), а не с помощью кучи каких-то библиотек, имеющих миллион побочных эффектов, доставшихся «в нагрузку».
Kanut
Я как бы не знаю как оно там конкретно выглядит внутри разработки твиттера, но на мой взгляд даже если они вообще не использовали сторонние библиотеки/фреймворки, то в какой-то момент они сами для себя сделали что-то подобное.
Ну вот просто не верю я что они все эти годы смогли/захотели без этого обходится.
weirded
Бутстрап вроде твиттер и сделал, если не путаю.
vladkorotnev
Бутстрап в роли набора стилей и системы вёрстки как раз вполне может и без скриптов жить, а та жесть, которую наворотили в твиттере — по ощущениям, мало чего общего с ним уже имеет.
Ilusha
Я бы не сказал, что «уровень входа» в современный веб — низок.
Результат фронт-разработки виден сразу и всем.
А какое говно в на беке или в мобильном приложении — не видишь.
Kanut
Гораздо ниже чем он был 10-15-20 лет назад. И ниже чем в каком-нибудь эмбеддед.
Вот-вот :)
MrRitm
В конце 90х надо было знать основы HTML+CSS, как пользовать таблицы и вставлять картинки. Потом стало модно DIV вместо таблиц. А вот сейчас то как раз порог входа ой как вырос. Тут тебе и тонны собственного JS (согласен с автором — далеко не всегда нужным) и всякие фреймворки и severside js появился, надо уметь прекомпилятор настроить чтобы все эти тонны JS и CSS минифицировать. Как по мне — намного сложнее стало.
Помнится экономил время и трафик во времена Dial-UP\GPRS и пользовался ya.ru именно потому, что русскоязычную инфу хорошо искал и быстро. Сейчас специально открыл ya.ru в свежем хроме без расширений\дополнений. Честные 50 мегабит, Core i5, 8 гигов памяти. 1,9 секунд.
Kanut
Это не «порог вхождения», это уже более продвинутый уровень. Я лично знаю людей которые «лепят веб» и в вами перечисленных вещах в общем-то не разбираются. Их научили библиотечные контроли копипастить и они копипастят.
Shugich
Сейчас веб-приложения — это не голый HTML. И то что кажется простым, если смотреть на страницу просто, как на .HTML не всегда таким является на самом деле.
nikolayv81
Да оно генерит это страницу через кучу прокладок давая работу сразу трём-четырём узким специалистам :) и это выгодно касте ИТ в сумме… но в частном это как-то ...
khim
Нельзя.
Дизайнер нарисовал красивую картинку… и ему пофигу, что для реализации его замысла потребутся 100 мегабайт памяти на страницу. На тестовой системе память несколько гигов, одна вкладка и всё отлично.
UX-специалист забацал видео с интересной идей… и ему пофиг, что для её реализации потребуется мегабайт скриптов и страница будет томозить. Начальство довольно и даже выписало премию — а больше ничего не надо. Опять-таки на тестовом стенде с одной вкладкой ничего не тормозит.
И так далее.
А разработчик… ну многие из них понимают что творят, но какая у них альтернатива? Выполнить задумки дизайнеров и получить бонус и премию или «встать в позу» и потерять работу?
P.S. Поищите старую-старую репризу Райкина «кто сшил костюм?»… Вот это вот — современный веб.
P.P.S. В маленьких компаниях всё ещё хуже. Даже если там один «программист» он всё равно общается с дизайнераим и UX-специалистами… только он с ними уже совсем ничего сделать не может. Потому что непосредственно сам браузер не даёт (без CSS) породит не «базовую страницу, с которой приятно работать», а то, что называется «вырвиглаз»…
zahmTOD
Я вот дизайнер. Я спроектировал интерфейс, подготовил все материалы в svg, кучу описаний. Все продумано и легко.
А пришли разработчики, нарезали все в пнг, забили на уменьшение картинок, подключили пару бесплатных плагинов, ибо лень написать простую вещь… И страница открывается дофига времени, гугл чекер всеь красный, а виноват опять диз. Ага.
Это я так, взляд с другой стороны ;)
khim
Вы либо плохо прочитали что я написал, либо не так поняли.
Проблема не в том, что дизайнеры плохие или разработчики плохие. Проблема в том, что подобные вот вещи больше невозможны.
Мощности компьютеров таковы, что вот то дерьмо, которое в результате получилось — всех устраивает.
Недовольны только пользователи, но так как они ничего не платят, то, в соотвествии с известной поговоркой — они не закачик, а товар.
alliumnsk
Как невозможны? Дефолтный интерфейс андроида (по крайней мере, 7.0) не позволяет отобразить секунды на экране блокировки, не задать время вручную с точностью до секунды. На чем-то экономят и продолжают экономить.
Конкретно вин95 по вашей ссылке работала с зоопарком векторных шрифтов (содержащих внутри тьюринг-полную машину), и это при типичном разрешении экрана того времени 640х480 или 800х600, когда от векторных был один вред.
khim
И снова мы наблюдаем пресловутый ГСМ в действии.
Я-то надеялся, что всем будет понятно, что речь в этой истории идёт не о невозможности показа секунд, а о том, что четверь века назад, если оказывалось что можно существенно сократить потребление ресусоров всего лишь чуть изменив дизайн — то так и делалось (за это, собственно ратуют в статье).
Сегодня же подход "я принёс тут кучу SVG, а они всё испортили" более распространён — никому не интересно делать быстрые и маложрущие сайты, хотя поспорить и том, кто именно виноват в том, что мы, на выходе, имеем, извиняюсь, дерьмо — это всегда пожалуйста.
Собственно сегодня как раз отказ от показа секунд говорит совсем о другом — уж четыре-то мегабайта под эти секунды на телефоне с 4 гигиабайтами памяти нашлись бы… просто в результате подхода, когда о конечном результате думает мало кто даже тех гигабайт и гигагерц, которые у современных разработчков имеются не хватает для этого!
alliumnsk
Я так и предчувствовал, что вы про печать напишете. Я примерно в то время печатал в основном из доса, используя LaTeX, а через Windows использовал для интернета. Нечего этим шрифтам для печати в ядре системы делать.
если оказывалось что можно существенно сократить потребление ресусоров всего лишь чуть изменив дизайн
Иногда делалось. Чаще--нет, не делалось. В этой же самой вин95 был анимированный диалог копирования файлов. Вы забыли его? Забыли аватар-скрепку и волшебника в мантии?
А еще в windows 3.1 для конверсии уплотнения дисков (drivespace) был режим mini-windows. В котором тоже использовались векторные шрифты. Я бы наверное как-нибудь пережил бы если File Manager и Program Manager отображались бы моноширинным растровым шрифтом, это же не для печати.
khim
А вот это уже как раз дизайнеры. Шрифт там, кстати, использовался как раз растровый… но пропорциональный. И это преподносилось как достоинство. Более того, так же точно делала GEOS на компьютере, я извиняюсь, с 64 КБ памяти и процессором на один мегагерц (не гигагерц, карл, мегагерц). Она, правда, не особо летала… но мы тут говорим о системе, которая на четыре порядка медленнее современных ПК!
Так что забота об эффективности дизайну не мешает… уж хороший он или плохой — другой вопрос, но мы сейчас не об этом.
alliumnsk
Так вы ссылались на Раймонда Чена, что таки мешает, и в угоду программированию поменяли дизайн, выпилив секунды в таймере.
А буде секунды в таймере оставлены, вы точно так же могли бы написать что функция "отлично работала", точно как и перелетающий листик в диалоге копирования. Там же конкретная цифра насколько это замедляло работу, не указано. Ваши примеры выше как пропорциональные шрифты использовались в слабых по аппаратной части системах — что они доказывают? Что можно сделать? Можно. Только вот они не доказывают, что эти рюшечки НЕ ухудшали производительность на этих системах. Можно даже сказать, что примеры выше доказывают, что даже в системах с 1 мгц процессором большинство людей хочет видеть замедляющие работу больше, чем секунды в таймере.
Только почему-то оказывается, что рюшечка которая ВАМ нравится, всегда "отлично работает".
Чем анимированный диалог копирования в вин-95 отилчается от «нам надо красить ники в набираемом твите синим цветом» в твиттере?
khim
Я имел в виду, что стремление эффективно использовать ресурсы вовсе не обозначает, что программы должнны получаться ужасно выглядящими и неудобными в работе. То есть не всякий хорошо выглядящий дизайн требует умопомрачительных ресурсов для своей реализации.
Однако некоторые дизайнерские изыскания, тем не менее, явно требуют совершенно несоразмерных ресурсов для своей реализации.
Совершенно верно — люди, в большинстве своём, хотят видеть пропорциональные шрифты. Но не все. Я это видел воочью у нас в школе. На компьютерах из прошлого века. Древних как гавно мамонта. Pentium II 300MHz, 12MB памяти, вот это вот всё. Там можно было работать в Turbo Pascal в DOS (причём DOS грузился по сети) или в Delphi (загружаемой с локального диска, но всё равно тормозившей). И, в общем, выбиравших тот или иной вариант было… сравнимое число.
Ошибаетесь. Я как раз эти летающие окошки ненавижу и предпочитаю FAR. Но при этом — я понимаю, что если у вас процедура двигает с одного места на другое мегабайты, то уж на прорисовку окошка с листиком ресурсы найдутся.
Тем, что анимированный диалог копирования тратит ресурсы только тогда, когда вы чего-то копируете, а функция раскраски ников (как и показ секунд в Windows 95) тратит ресурсы всегда — даже когда вы ничего не делаете.
Но я даже скорее не по поводу синих ников как таковых, а по поводу того, как это сделано. Скажем на хабре ведь тоже ники выделяются синим цветом — но при этом это не мешает Хабру иметь стандартный редактор текста.
Druu
Почему дерьмо-то? Как вы это определили, по каким критериям?
justboris
Как подготовленные svg помогут сверстать интерфейс без Javascript? Правильно было бы:
И много таких дизайнеров будет на свете?
justhabrauser
> Как подготовленные svg помогут сверстать интерфейс без Javascript?
Может человек уже сдавал дизайн как все нормальные люди в пайнте.
И потом ужаснулся от реализации.
В следующий раз плюнул, нарисовал так, как оно должно быть, пришел к девелам:
— Вот вам
унитаз и жеппа — дайте мне рулон туалетной бумаги!готовый SVG — просто добавь воды!— Оукееей… (сказали суровые разработчики, привычно разворачивая canvas).
zahmTOD
Поясню про svg — одну какую-нибудь иконку можно сделать 2-килобайтным файлом, экспортом из иллюстратора. Потом ее оптимизировать допустим до 500 байт. И прописать все стили внутри, чтобы вид иконки менялся программно легко.
В итоге клиенту прилетает 500 байт и несколько строк в стилях, а не грузится 10 пнг с альфаканалом и размером 4@ для мобилы, потом на яваскрипт определятся какую показывать.
В современных инструментах, таких как Figma, трудно нарисовать что-то, не реализуемое css. Но это уже проф качество диза.
sumanai
Замечу, что на рендеринг SVG уходит больше ресурсов, чем на отображение растра. Так что оптимизируя передачу по сети, вполне можно проиграть по загрузке на процессор. Хотя конечно обычно такой нагрузкой можно пренебречь.
vladkorotnev
Большая часть веба сейчас мобильная. И вот мобильники, которые не могли прожевать сколь-либо большой SVG мне последний раз попадались ладно если в 2011, а трафик, кончающийся в самый неподходящий момент и роняющий скорость до 56 кбит/с — встречается по сей день.
Apxuej
Вопрос от человека который совершенно не разбирается: если мы хотим сделать самый быстрый сайт на свете для всех возможных устройств, нельзя ли сделать две версии: растровую и векторную и спрашивать браузер пользователя, какая из них была бы предпочтительнее, пересылая краткую информацию по возможной нагрузке на канал связи и процессор? А пользователь бы мог, если нужно, настроить политику браузера: экономим трафик или быстро загружаем страницу. Возможно это слишком сложно (невозможно) реализовать и/или не будет выигрыша во времени?
Ilusha
Возможно.
Увеличится стоимость и скорость разработки продукта, его поддержки.
А разницы вы не заметите.
PNG vs SVG на практике — экономия на спичках.
AndreyHenneberg
Кроме описанного, надо будет грузить пустую страницу с кусочком JS, который будет что-то там определять и загружать нужную страницу. А если JS не запускается, то будет срабатывать перенаправление через сколько-то секунд. То есть имеем одну лишнюю загрузку и сколько-то секунд на работу скрипта или ожидание таймаута.
AndreyHenneberg
Это где такая халява с трафиком? У меня просто рубит наглухо, а дальше — либо доплачивать за продление, либо помегабайтно, что совсем грустно.
vladkorotnev
SoftBank — 7 гигов месяц, потом скорость грохается так, что от силы текстовые сайты грузить можно.
VolCh
Смотря что называть "проверил". Одно дело реализовать самому, а совсем другое прежде чем отдавать дизайн в задачу фронтендера, спросить у этого фронтендера "нормально будет или может что-то изменить?".
Dissarion
Всё очень просто. За отстойную реализацию продукта виновата вся команда, а не кто-то один.
zahmTOD
Если есть команда. А не контора, нанимающая фрилансеров. Я свою работу выполнил качественно, оплату получил, материалы передал. И в мои обязанности не входит контролировать фронт. А потом жуткий результат видишь, через пару месяцев. Но никто ничего не будет исправлять, так как клиент доволен, все акты подписаны.
Kwisatz
Звучит как мечта, а можно с вами поработать?)
zahmTOD
А как мне иногда хочется поработать напрямую с фронтом, а не ПМ или ПО. :)
Kwisatz
А я тимлид нынче. Ну или просто разработчик со своими интересами)
FlameStorm
Может вам и ещё один разработчик нужен 10+ стажа, который любит лёгкий и быстрый софт? Могу не только на пыхе с мускулом и жысом, но и на щах с асмом. ;)
Kwisatz
Может, но не сейчас, да и в штат очно все таки.
zahmTOD
Тимлид — понятие растяжимое). Поработать можно конечно, если задачи интересные
Kwisatz
Я много лет занимаюсь всевозможными ERP решениями: реестры оплат, кассы, продажные интерфейсы и прочее. Итеративно подбираю самый эффективный и быстрый вариант. Вот только шаблонов в этой сфере нет и дизайнеры все пасуют.
Сейчас занимаюсь созданием универсальных компонентов на vue.js, поскольку тех что есть в свободном доступе просто не хватает. Один из этих компонентов — DataGrid, таблица с агрегацией, фильтрацией, контекст меню, поиск, пагинация, тулбар итд и тп. Вот этому делу + шаблон страницы требуют дизайна.
Есть более сложная и емкая задача но под нее пока нет компонентов: идея в том что каждый интерфейс предполагающий заполнение справочников, позволяет это делать через селекты, не заходя в сами справочники, что жутко экономит время, но красивого решения я пока не нашел.
Если интересно и готовы оценить/попробовать то чирканите в личку.
AndreyHenneberg
И почему мне все пытаются подсунуть гигантские файлы в формате PhotoShop и Illustrator, которые мне и открыть-то нечем, потому что я, блин, не фронтэндер даже, а чистый бэкэндер и у меня даже винды нет. Эх, кто бы мне давал картинки в готовом виде, да ещё в SVG… Мечты, мечты.
zahmTOD
Сочувствую. Я сейчас в основном в Figma работаю, это почти рай. Но есть всякие черти, кто до сих пор в фотошопе рисуют. Им давно пора в продавцы, но блин…
zhovner
Но в таком случае при закрытии этого окна страница будет полностью перезагружаться, а сейчас окно просто закрывается и можно скроллить дальше.
sumanai
Нет ни одной проблемы навешивать закрытие попапа на JS и сохранение функциональности перехода в профиль без него.
khim
Есть только одна проблема — это никак не отразится на вашей зарплате. И даже премию вам не дадут.
sumanai
Да и пофигу. Лишь бы не ругались.
khim
Ну это вам может быть пофигу. А большинству разработчиков web-сайтов как раз не пофигу: они этим занимаются, чтобы денег заработать, а не потому что фанатеют от натягивания формочек…
VolCh
Большинству разработчиков пофигу в этом плане навешивать или нет, пока их не увольняют за первое или второе, они на окладе
nikolayv81
Мне вот даже интересно стало, сколько должно быть не вставших релизов (породивших проблем) чтобы всю руководящую ветвь отвечающих за продукт "отпустили на свободу".
p.s. меня иногда удивляют расстроенные результатом люди, которые сетуют на "людей не опытных и постоянно косячащих в ИТ", при этом рассказывающих что деньги это не мотивация :)
VolCh
Хорошие руководители чувствуют этот предел шестым чувством и уходят заранее с победной строчкой резюме
XXXXPro
А как одно связано с другим? Чтобы не косячить, нужно две составляющих: а) достаточный уровень компетентности, чтобы понимать как сделать не криво, б) жесткие внутренние критерии качества, в частности, установка «graceful degradation и экономия ресурсов компьютера важнее всяких украшательств».
Если этого нет, то никакая мотивация деньгами не поможет.
Ilusha
Нельзя же сказать «вот этот попап мы сделаем работоспособным без JS». Нужно или делать все, или не делать. А если делать, то нужно и тестировать без JS.
Есть конкретные политики:
— поддерживаем ли мы мы работоспособность сайта без JS;
— используем ли инструменты для людей с ограниченными возможностями;
— оптимизируемся по производительности;
— оптимизируемся по скорости загрузки;
— закладываем ли возможность переводов на разные языки;
— закладываем ли адаптивность под мобильные устройства;
— и т.д.и т.п.
Зачем делать то, на что компании пофигу?
nikolayv81
Проще да но люди делают копипаст… Учатся на копипастах, используют копипасты из вопросов на so которые не совсем в те у о своих фреймворках… :)
atbuhw
PS Дико поддерживаю статью и… плюсовать не могу, к сожалению, но хотел бы.
JustDont
Именно так. Потому что руками это мало кто пишет (хорошо, если один раз на контору, а то и вообще ноль, потому что берутся чьи-нибудь чужие компоненты).
Поэтому именно что намного дешевле. А уж искать на работу «реакт-программистов» а не «фронтэнд разработчиков с глубоким пониманием принципов вёрстки» — и вообще радикально дешевле.
atbuhw
И много вы видели сайтов, на которых используется точно такое же эмулированное текстовое поле, как в вышеупомянутом твиттере?
И даже если так, даже если такие текстовые поля повторно используются, не будете же вы утверждать, что (a) в принципах их (повторного) использования проще разобраться, чем в принципах использования textarea и (б) код, который нужно написать для использования этого текстового поля на конкретном сайте и на конкретной странице, проще, чем textarea с параметрами?
PS Есть известная фраза: «не всегда стоит объяснять злым умыслом то, что можно объяснить глупостью». Её можно перефразировать: «не всегда стоит объяснять желанием сэкономить то, что можно объяснить глупостью (а то и злым умыслом)».
JustDont
Да порядочно. Везде, где нельзя просто взять кондовый textarea, а нужно чего-то слегка доработать напильником — начинаются такие интересные метания, что решение твиттера даже на самом деле не таким уж и хреновым выглядит. А уж протестировать, как эта доработка напильником будет работать с недогрузившимся JS — лул. И вообще скажите спасибо, что твит таки можно написать без JS. У многих и этого великого «завоевания» нет.
atbuhw
JustDont
Возьмите любой сайт с раскраской текста, от WYSIWYG-редакторов до семантической раскраски кода, и за этим всем всегда будет стоять довольно-таки адовая эмуляция поведения обычного textarea. С исходным кодом — за этим всем будет частенько стоять codemirror (jsfiddle, codepen, и многие другие), а у кого не codemirror — у того редактор от VS Code.
atbuhw
И что, twitter тоже что-то из этого использует? Причём без изменений (или с изменениями, которые проще, чем вставить textarea?)
JustDont
Нет, в твиттере придумали свою эмуляцию, когда программистам поставили задачу «нам надо красить ники в набираемом твите синим цветом».
atbuhw
Вот и я про то же. Причём из статьи складывается впечатление, что их решение не было оптимально по трудозатратам программистов, которые это писали.
JustDont
Если вы из статьи поняли, что можно как-то иначе — вы поняли неправильно. Нет, нельзя иначе. Или раскраска, или textarea. И причем второе у вас честно будет, если вы отключите JS. Вот только переход от такого состояния до обычного — никто особо не проверял (что совсем-совсем не удивляет).
atbuhw
Нет, конкретно в этом случае я имел в виду (а) всякие мелочи вроде написания текста два раза, (б) написания цветного текстового поля (как вы говорите) с нуля, причём очень тормозного (как говорит автор), вместо использования (как опять же как вы говорите) готового с поддержкой раскраски, пусть и js-based, (в) другие мутные места, вроде скриптовой строки поиска, вполне себе одноцветной.
JustDont
А кто вам сказал, что оно тормозное? Автор? У неё вообще там какой-то цирк с 20-секундными задержками скриптов, так что я бы относился к любым её оценками производительности сильно с прохладой.
Это даже не говоря уж о том, что сам браузер тоже может тормозить, и тогда у вас и кондовый textarea начнёт вести себя очень так себе.
Я о том, что вы делаете далеко идущие выводы без надлежащих оснований. Может ли быть, что у твиттера какой-то особо тормозной код? Конечно может быть. Может ли быть, что нет, вполне себе обычный? Конечно может быть.
atbuhw
ok, проверил на своём компе, у меня 7 секунд на отображение страницы, что тоже не дико быстро (сколько времени занимает открытие формы ответа, проверить не могу, т. к. меня нет в твиттере). И главный мой point был в любом случае не в скорости работы, а в вероятных трудозатратах на разработку.
khim
Всё это — банальные (и легко просчитываемые) следствия эффекта айберга… Получите, распишитесь…
atbuhw
XXXXPro
Проблема в том, что в большинстве случаев решения в духе «красить ники в синий цвет» принимает какой-нибудь менеджер/маркетолог, далекий от Web-разработки вообще и не понимающий, к какому утяжелению сайта приведет замена стандартного компонента на нестандартный. И не находится никого, кто ему возразил бы.
atbuhw
С этим я и не спорю, «непродуманность решений» — вполне реалистичное объяснение, почему проблема возникает, на мой взгляд. Я спорю лишь с утверждением, что наоборот, «всё давно уже посчитали и поняли, что именно таким способом, с кучей скриптов, можно минимизировать расходы на разработку».
arheops
Ну например приличная часть SELECT элементов с другим видом(ну там с закруглениями и другими рюшками) написана с использованием DIV, а сам элемент спрятан
Kanut
Возьмите например какой-нибудь Kendo UI или что-то в этом роде. Как на нём «формочки лепить» на мой взгляд любой школьник разберётся. Это почти как детский конструктор по сложности.
atbuhw
А с textarea школьник не разберётся? Как использовать textarea (в простейшем случае, понятно, что поверх него тоже можно тонны скриптов накрутить) можно объяснить в одном абзаце, что автор и делает. А можно ли в одном абзаце объяснить, как использовать Kendo UI?
В любом случае, я (и статья, как я понимаю) не совсем о том случае, когда используются готовые фреймворки. Я скорее о написании монструозных велосипедов с нуля (или переделывая имеющийся код для полной неузнаваемости) для решения задач, которые можно решить намного проще.
Kanut
Проблема в том что просто textarea не особо часто и нужно. Нужно как минимум в определённом месте, опрределённого цвета и чтобы содержание было к чему-то прикручено. И там ещё всякие кнопочки-иконочки и всякая подобная мишура. И вот как такое самому сделать это уже не так и просто разобраться.
А в кендо такое идёт «из коробки». И элементарно кастомизируется в определённых рамках. И там не только textarea, но и куча других контролей.
У них всякие модные вебинары и видео на ютюбе. И страничка с примерами откуда можно великолепно копипастить даже не задумываясь что ты вообще делаешь.
А это уже следующий шаг. То есть когда внезапно выясняется что функциональности фреймворка не хватает, то его начинают «кастомизировать». Причём часто прямо «по живому», то есть лезут в сам фреймворки начинают в нём ковыряться.
П.С. Поймите меня правильно я не пытаюсь уговорить вас что так правильно делать. Я просто на такое достаточно часто натыкался и у меня вполне себе сложилось впечатление что исключением такой подход не является…
atbuhw
Kanut
А это можно сказать «кумулятивный эффект». То есть поначалу начальству кажется хорошей идеей взять какой-нибудь подобный фреймворк, но зато сэкономить на квалификации программистов и их зарплате. И это вполне себя может работать достаточно долгое время.
И если дело вдруг доходит до «кастомизировать» то уже часто имеется более-менее работающий и приносящий деньги проект. И в такой ситуации начинать с нуля уже тоже никто не хочет.
atbuhw
Возможно. Но во-первых, в статье полно примеров, когда с самого начала вместо фреймворка можно было использовать тупой html, что требует и меньших трудозатрат, и меньшей квалификации.
А во-вторых, согласитесь, что «начальство, которое не думает вперёд и в итоге всё с большим трудом разгребает проблемы» — это совсем не то же самое, что «начальство, которое (успешно) минимизирует расходы».
Kanut
Ну грубо говоря даже если сначала и берётся «простой html», то в какой-то момент нужно выбирать «дальше простой хтмл и дорогие программисты» или «переходим на фреймворки остаёмся с дешёвыми программистами».
И как раз таки если не особо хорошо разбираешься именно в ИТ, то вполне себе может показаться что второй вариант выгоднее. И часто он действительно выгоднее поскольку до «кастомизации» дело так и не доходит.
atbuhw
XXXXPro
Проблема в том, что для этого нужно уметь отказываться от второстепенных фич типа тех же «синих ников» (я такие вещи называю «украшательствами»). Но почему-то на это никто не идет.
khim
Если компания маленькая — так тем более, про 10 лет никто не будет думать, так как компания может закрыться через год.
Так что «начальство, которое (успешно) минимизирует расходы» — может существовать только в некоммерческих проектах. Wikipedia какая-нибудь. Archive.org. Подобные штуки.
atbuhw
khim
«За хорошую работу» мееджмент получает, обычно, не акции, а так называемые «опционы»: возможность купить, через год, акции по сегодняшней цене. Ну а продать их можно по той цене, которая будет через год.
Понятно что если ваша компания «нормально себя чувствует» и акции «стоят на месте» — то вы лох. Вам гораздо выгоднее сделать так, чтобы акции за год выросли и вы бы на них заработали. А если, в результате вашей деятельности, через 10 лет компания обанкротится — это уже не ваши проблемы.
Или даже хуже — если цена акций через год рухнет, но вы как-то сможете «спасти» вашу компанию — то через два года вы будете «в шоколаде».
Видно, что вы никогда даже не пытались управлять своим бизнесом. Понимаете в чём проблема: если вы — малый бизнес, то «запас прочности» у вас — от силы год. Если вы «влетели в убытки» и за год не придумали где получить прибыль… то через два — вы закроетесь. Потому у вас нет возможности выбирать планы, которые будут выгодны на интервале в 5, 10, 20 лет… если они не могут вернуть вашу компанию к прибыльности на следующий год — вам это всё не нужно.
Как это не наблюдаем? Вы в какой-то другой вселенной живёте. Компании разоряются постоянно. Просто круным на это требуется лет 10-20, но мелким — гораздо меньше.
Просто попробуйте найти фотку гипермаркета рядом с вашим домом и сравнить список арендаторов в 2015м и 2020м… думаю вы будете удивлены.
Kanut
Опционы часто бывают привязаны к определённым условиям. Особенно у менеджмента и начальства. Поэтому описанная вами «схема» работает далеко не всегда.
khim
Так это ещё хуже: после этого у руководство появляется очень серьёзный повод сделать так, чтобы эти деньги заработать, даже если сама компания, после этого, перестанет существовать…
Kanut
Ну во первых если у всех сотрудников есть опционы, то для кого конкретно это «хуже»? Особенно если учитывать что куча стартапов и создаётся именно для того чтобы их кому-то подороже продать в будущем.
А во вторых я как раз наоборот о ситуациях когда опционы либо растянуты по времени(то есть скажем в первый год получаешь 10%, во второй ещё 10% и так далее), либо нужно сначала отработать какой-то минимальный срок, либо привязаны к каким-то финансовым показателям которых фирма должна достичь.
khim
Ну да — и вы не видите тут проблем?
Ни разу такого не видел. Максимум — 4-5 лет. Что вот ни разу не способствует тому, чтобы что-то планировать на 10-летний срок.
Как мы помним Nokia оных показателей успешно достигла, да. Да и Microsoft — тоже.
Kanut
Ну если бы у стартапов не было возможности «продаться за большие деньги», то кучи стартапов бы просто и не было и пользователям вообще бы нечем было пользоваться.
Нет. Пусть лучше создаются с такой целью чем не создаются вообще.
А вы прямо эксперт по опционам и прямо вот много их видели? :)
Ну да, Nokia проблемы получила только из-за опционов. А уж какие у Майкрософта сейчас огромные проблемы…
khim
Ну было бы вместо 100 стратапов, пытающихся продвигать видеозвонки 1 или 2. Стало бы пользователям от этого хуже? Я так не думаю.
Зачем? Кому от этого хорошо?
Не эксперт, но некое понятие имею. Благо условия для топ-менеджеров часто публикуются в отчётах.
Ну если не считать того, что Microsoft вместо «первого без равных» (заработанную под руководством человека, работавшего явно не за опционы) откатился на позицию «даже не совсем и первый» под рукодством человека, работавшего как раз «на биржевые показатели»… то да… всё прекрасно.
Kanut
А это то здесь причём? Я о том что если бы отдельные создатели стартапов не имели бы перспективы продать свои стартапы кому-то за большие деньги, то они бы просто не стали их делать или бы не нашли под это дело инвесторов.
И кстати «железо» оно тоже не из воздуха взялось. Его тоже кто-то придумывал. В том числе и всякие «инженерные стартапы». И как минимум в тех же США подобная практика существует уже лет двести точно.
То есть уже в 19-м веке какие-то «изобретатели» что-то там придумывали и потом продавали своё дело целиком кому-то другому кто его раскручивал.
Как насчёт того что эти «один или два» появились бы на пару десятков лет позже? То есть естественно всё бы это когда-нибудь бы и появилось, но например с опозданием на 10-20 лет.
Мне например.
atbuhw
khim
Пока «основатели» у руля (то есть не формально владеют акциями, а реально руководят компанией) это работает. После — нет. Можно смотрть куда угодно: Apple, Google, HP, Microsoft и многие другие. Пока владельцы-основатели у руля — это инновации, взгряд на 20 лет вперёд и всё такое прочее. Как они уходят и «эффективные манагеры» побеждают… ну что чего такого прорывного сделал Apple с тех пор, как Стив Джобс перестал им руководить? Или Google?
Знаете — вы тут рассуждаете как блондинка, которая считала, что через месяц радиоактивный йод должен весь исчезнуть. Период полураспада же 8 суток, так что за первые 8 суток распадётся одна половина, за вторые 8 суток — вторая…
atbuhw
В любом случае, я хочу сказать, что если бы компании вообще не следили за расходами и не пытались их минимизировать в хоть каких-то частях своей деятельности, то они разорялись бы очень быстро, как показывает пример тех компаний, которые всё же разоряются.
khim
Да, конечно, какой-то конроль над расходами, несомненно, нужен. Но можно десятилетиями жить за счёт того, что вешать на уши лапшу инвесторам. И тут как раз борная деятельность на Web-сайте — только в плюс: неважно, что там, на самом деле, происходит… инвесторы видят «движуху» — и отслюнявливают денежке. Классно же.
atbuhw
VolCh
Ложное утверждение. Компании могут максимизировать доходы, спуская кучу денег в
трубувенчурные инвестиции, и жить гораздо лучше чем те, кто минимизирует расходы. Более того, некоторые компании вообще не интересует операционный баланс, а заботит только рост капитализации.khim
Угу — только вот эта технология уже была протестирована в СССР.
Если неэффективные компании и предприятия не закрывать, а тупо «заливать деньгами», то лет через 20-30 накрывается медным тазом вся система. В СССР этим начали заниматься в 50е, после смерти Сталина, к концу 80х система сгнила.
В США этим начали заниматься примерно в районе 2000го (когда «залили деньгами» кризис докомов) и, в общем, результат уже чуствуется…
atbuhw
Я имел в виду, что компании (обычно) всё же вынуждены следить за своими расходами и стремиться из снизить хоть в какой-то части своих действий. Компанию, которой абсолютно плевать, сколько она потратит в каждой операции, требующей расходов, я как-то слабо себе представляю.
VolCh
Я, конечно, не про то, что вообще плевать, а про то, что "режем косты" необязательно значимая часть политики любой компании. Например, компания может стратегически платить разработчикам выше рынка и при этом прекрасно себя чувствовать по финансовым метрикам. Могут платить меньше — могут. Как это отразится на финансовых метриках? Неизвестно. Но пока инвесторы не жалуются, лучше стратегию не менять.
atbuhw
С этим я не спорю, вполне возможно делать расходы маленькими, но не минимально возможными. Но в таком случае уж точно написание всё новых и новых js-скриптов этими программистами (о чём, собственно, статья) нельзя назвать «экономией денег компании».
VolCh
Оно может быть обусловлено попытками экономить время и деньги, а получается как всегда. Или оно реально сэкономило в краткосрочной перспективе, но дальше вышло боком.
atbuhw
Я уже ответил на это соображение в другом комментарии: habr.com/ru/post/490412/#comment_21336370 Коротко: я не спорю с тем, что текущая ситуация местами может быть следствием глупости и недальновидности руководства. Я спорю только с тем, что они реально экономят деньги таким образом.
VolCh
Ваше "реально" не однозначно. За месяц сэкономили на ЗП 300%, наняв джуна, а не сеньора при одинаковом функциональном результате — это реальная экономия? А то, что эта экономия на отрезке в 5 лет привела к росту расходов в десять раз значимый факт или нет?
atbuhw
Я имел в виду все (предвидимые) последствия. Так что если через 5 лет потратили в 10 раз больше, то я не называю это «реальная экономия».
VolCh
А если за эти 5 лет заработали в 100 раз больше, чем могли бы? :)
atbuhw
В таком случае компании сильно повезло, она получила хорошую работу за маленькие деньги (а программисту наоборот не повезло, он получил мало за хорошую работу). К чему этот пример? Как он относится к моему утверждению, что перегрузка страницы скриптами — это (часто) что угодно, только не экономия денег компании?
VolCh
За месяц собрали соляну из реакт-компонентов и зарабатывали деньги, по на соседнем проекте суперпрофи делал всё на CSS
atbuhw
А потом что? (Я имею в виду, когда профи доделал своё решение.) Продолжили тратить всё большие усилия на поддержку тяп-ляп решения (с решениями, которые пишутся непонятно как, обычно так и бывает)? Или всё же перешли на продуманное решение?
Кроме того, в случаях, описанных в исходной статье, не нужно быть суперпрофи, чтобы написать простое и надёжное решение, часто даже без CSS.
nikolayv81
"Поэтому именно что намного дешевле."
Из личного опыта:
Levitanus
Хабру в последние недели — особенно. С мобильника читать — боль. И не говорите про приложение, функционал до браузера не дотягивает
JustDont
Хабр даже прокрутить страницу к нужному комменту не может, когда этих комментов за 500 переваливает, а вы говорите.
Это даже не говоря о том, что сколько бы комментов не было — грузятся они прям все сразу, 500 ли, 1000 ли, живите с этим.
Levitanus
Ну еще пару месяцев назад я не боялся открывать обсуждения на 200+ комментариев. А теперь у меня и 100+ не грузятся никак. Еще и плашка постоянно вылезает про «обновите страницу».
Лента стала фризиться при выходе из браузера, показывает ленту 2-3х дневной давности. Что-то с последними обновлениями прямо ощутимо ухудшилось
ilyapirogov
Да ладно комменты. Иногда даже некоторые большие статьи прочитать невозможно. Статья просто постоянно рефрешиться и скролл сбрасывается в самое начало.
tester12
Ну, допустим, что среднестатистический комментарий занимает 500 байт.
Страница на 1000 комментариев — это 500 Кб. Или пусть будет 1 Мб (с учётом сопутствующих расходов).
1 Мб — это, в общем-то, не много.
JustDont
Тормозит-то рендер (поскольку каждый коммент — это основательный кусок html, да еще и собранный в древовидную структуру зачем-то), а не сама загрузка. На медленном интернете наоборот не видно будет, а на быстром — страница грузится, потом очень ощутимо тупит, потом еще грузится (что там у них еще подгружается после DOMReady).
gxcreator
И это прекрасно. Можно быстро Ctrl+F по всем комментам, можно загрузить и спуститься в метро(не мск) читать.
JustDont
Не сразу, а когда их таки уже отрисует браузер. Что на мобилке может быть еще более не сразу. Ну и «загрузить» и «показать» не обязательно должны идти в паре.
Впрочем, если не ошибаюсь, мобильная версия хабра таки не грузит комментарии в дерево, а показывает простым плоским списком. Что быстрее.
gxcreator
Тут имеется в виду пагинатор против загрузки всего сразу. Имхо, для дерева комментов лучше когда оно сразу подгружается, это какие-то десятки килобайт, что мелочь по современным меркам.
Ну а медленый рендер это видимо поблемы каких-то уж совсем старых телефонов.
Levitanus
Нинаю, у меня ZTE blade 2019г с 1ГБ RAM и 32ГБ ROM, вполне так себе средний сегмент. Хабр, как было подмечено ниже, вешает FF напрочь, даже в случае закрытия вкладки (надо ждать секунд 10 пока JS упадет)
gxcreator
Это было норм в 2014, сейчас разумный минимум 3Гб имхо.
К сожалению у них какие-то проблемы с лагами. У меня проскакивают лаги на snap855/8Gb RAM. Приходится использовать ungoogled Chrome форк в виде Bromite.
alliumnsk
Ну на хабре может, а на других сайтах Ctrl+F не ищет по загруженному, но скрытому с помощью CSS контенту.
nikolayv81
Не работает до полной отрисовки
khim
На слабых (или запусоренных) системах (типа как у автора статьи) страница может грузиться секунд 20 — но альтернатива ещё хуже: либо ты ждёшь 20 секунд и получаешь нормальную, отзывчивую страницу, либо 2-3 секунды — и получаешь слупока, где потом любое действие типа нажатия на клвишу PgDn отрабатывается по 3-5 секунд.
JustDont
Нет, есть вещи гораздо хуже. Например, возможность грузить сколько угодно всего без малейшей попытки смасштабировать, из-за чего начиная с какого-то момента это всё просто перестаёт работать на практике. И это я даже не про хабр, а про одну b2b систему, в которой «типовой» случай грузил табличку килобайт на 200 итогового html, а вот нетиповой мог и на 20Мб жахнуть, и это всё радостно вешало браузер (простой голый html едва ли висел бы — но разумеется, он был далеко не простой, а очень даже отягощённый кодом, который в огромном DOM тормозил).
Вот и с хабром точно так же — мне в общем-то плевать, сколько времени там комменты отрисовываются, потому что я этого даже и с тормозами не увижу, даже когда их очень много. Но вот кнопочка перехода к непрочитанному комменту — начинает переходить куда угодно, только не к непрочитанному комменту, если вдруг портянка на 500+ комментов еще не прошла все стадии готовности, которые она должна была пройти.
khim
JustDont
Видимо нет. Я даже не готов утверждать, что дело тут именно в производительности, мало ли что там еще может ломаться. Сам факт — когда комментариев много, первый непрочитанный я никогда не вижу, у меня просто скроллит не к нему, а куда попало. Когда совсем-совсем много (впрочем, портянки в 1000+ комментов на хабре редкость) — то и второй не вижу. С какого-то момента — работает нормально. Или если делать очень-очень ощутимую паузу после открытия страницы, тогда тоже нормально.
ghost404
Еще интересная штука. Без интернета на телефонах не работают все спойлеры. Не знаю как это может быть связано, но факт в том, что для открытия спойлера в статье на странице без интернета необходимо включить интернет и обновить страницу.
DistortNeo
Чем меня бесит в этом плане Хабр — новые комментарии получают статус прочитанных в момент запроса страницы, а не в момент окончания их загрузки. Не загрузилась страница до конца, обновил — всё, новых комментариев нет, страдай.
sumanai
Ага. А ещё свёрнутые ветки грузятся развёрнутыми (и вообще грузятся), сворачиваются скриптами и страница скачет. Плюс если в свёрнутой ветке куча комментариев, то приходится их все прощёлкивать. Очень не удобно.
khim
Ну вы же понимаете, что нет там никакого «статуса прочитанных». Там есть время последней загрузки страницы. И его проще всего обновить когда начал загружать страницу, а не когда закончил.
Можно было бы и по окончании загрузки конечно… но важнее же рюшечек добавить… и вообще — почему бэкэндер должен думать о проблемах фронта?
Всё тот же «костюм», как бы…
DistortNeo
Его проще всего обновить по отдельному запросу по завершении загрузки страницы.
khim
«Разумнее» — может быть. «Проще» — нет. Что может быть проще, чем обновить статус в той же процедуре, которая его запрашивает? Не нужно отслеживать что там происходит, если страницу грузят с двух разных устройство, всё в одной транзкции и вообще кода меньше и он проще.
А что пользователь страдает — так то такое. У нас «на бэке» всё хорошо, а что там «у них на фронте» — это не наши проблемы.
Пользователь же всё равно страдать будет — только теперь уже в тех случаях, когда страница никак не может загрузиться до конца (ну, допустим, попали на какой-то рекламный сайт, который отдаёт картинку, но потом не закрывает соединение и, в результате, страница считается «не до конца загруженной» часами).
4ITEP
Не знаю, чего они там в новых комментариях накодили, но у меня Firefox иногда полностью зависает. Данный эффект был замечен только на Хабре
MKMatriX
Грустно, но и будущий путь известен. Повторит игровую индустрию, где сначала более-менее все шло у всех, а потом нужно лучше железо. И даже причины понятны, в мире где люди готовы раз пару лет обновлять телефоны, а пк остаются для геймеров, да и вообще производится очень большое количество чипов за единицу времени, сложно заботить о ресурсах.
Boroda1
Полностью солидарен с автором статьи.
У меня ещё жива машина с Pentium 4, на которой можно было играть в Crysis.
А вот открыть сейчас в браузере сервис почты или погоды для него — ох как тяжко.
Ресурс явно расходуется куда-то не туда. Вернее на огромное количество упомянутых «квадратных колёс».
Жаль только, что бизнесу на это наплевать.
JustDont
Бизнесу на это наплевать по очень понятным причинам: потому что вы и так хаваете.
Вон, даже на хабре ситуация ухудшается. И что, вы перестали на хабр заходить? Ну-ну.
tester12
Если нет хлеба, приходится есть жмых и лебеду.
JustDont
Именно так. Особенно когда вы ни за жмых ничего не платите, ни за хлеб не собираетесь ничего платить, даже если вам вдруг его кто-то предложит.
tester12
Если предложат хлеб — я его готов купить за разумную плату.
JustDont
Даладно? То есть, если вам кто-нибудь выкатит, скажем, твиттер на голом html и оптимизированных скриптах (где без них точно никак) — вы реально пойдете платить за него ежемесячную подписку?
И как вы думаете, по вашей оценке, сколько в % от общей аудитории твиттера будет таких как вы?
XXXXPro
Что любопытно, аналоги Twitterа, причем бесплатные и с легким и быстрым интерфейсом, уже есть. Например, Mastodon. Но тут уже сказываются социальные факторы: мало кто захочет переходить туда, где почти никого нет, пусть даже там и лучше с технической точки зрения.
khim
Про это я уже писал: превращение продукта в дерьмо — как это ни удивительно выигрышная стратегия. Не на догосрочном интервале, конечно, на промежутке в 10-30 лет (именно поэтому у нас на телефонах ядро Linux, а не Windows NT), но коммерческие компании просто не выживают так долго, чтобы что-то другое смогло выиграть…
Areso
Чтение корпоративных блогов на Хабре и есть оплата, которую предлагает большинство посетителей Хабра.
Спускаем по воронке ниже — зарегистрированные пользователи пишут комментарии. Когда полезные, когда бесполезные, когда холиварные (которые, несмотря на свою бесполезность, увеличивают обсуждение статьи и повторные заходы на сайт).
Еще ниже в воронке люди, которые статьи пишут.
u_235
nobodysu
youmightnotneedjs.com
x-tea
забавно. от
ОЙJQuery к ванильному JS, от JS к HTML/CSS… которые тоже, если подумать не везде нужныSolant
Хороший набор хитрых хаков, но не самый лучший выбор для чего-то чем будут пользоваться люди
Каждый пример имеет какое-то ограничение: не работает на старых браузерах, отсутствие интерактивности, хардкод размеров элементов, хардкод id самих элементов в css, ограничения с навигацией и с доступностью, сильно урезанный функционал.
Вот и получается что необходимо выбрать 2 пункта из 3 возможных:
— отсутствие JavaScript
— поддержка
— функционал
a1ex322
А что если этот гигантский архитектурный провал сделан намеренно? Почему бы не подавлять новации в своей сфере, ведь они могут привести к переделу рынка.
Spaceoddity
Больно всё это наблюдать. Когда-то я мог потратить пол дня, чтобы найти решение для «дизайнерских изысков» на чистом html/css, вместо того чтобы за пару минут, условно говоря, через js получить размеры вьюпорта. Да, не слишком продуктивно, но «железобетонно». И главное, мой внутренний перфекционизм не страдал. Любая задача по вёрстке сложного лэйаута, действительно превращалась в Задачу. Приходилось некоторое время просто обдумывать варианты реализации.
Сейчас же к таким «вызовам» прибегаю всё реже и реже.
Во-первых, по причинам озвученным автором — «а чего сидеть-пыхтеть с css, если сейчас все и так обмазались скриптами по самое немогу».
Ну а во-вторых, это крайне редко кому надо. Твои «мозговые штурмы» все равно никто не оценит. Код мало кто смотрит — «лишь бы выглядело прилично».
Так что сам постепенно скатываюсь в подобную «халтуру»…
VolCh
А CSS-in-JS ещё больше провоцирует…
tester12
А если зайти с другой стороны? Почему анимация твиттерных кнопок и простенький «красивый» редактор текста отжирают десятки и сотни мегабайт? Почему они останавливают страницу на несколько (а порой десятки) секунд?
Может быть, дело не в самом JS, а в неумении им пользоваться, в спешке, в бездумном использовании тяжёлых библиотек («готовая библиотека ускорит разработку»).
khim
Дело в сочетании: «пипл хавает», «деньги есть» и «надо что-то делать, а то премию не дадут».
Всё это опирается на Закон Меткалфа.
Все эти ухудшения и прочий ужас, как ни странно банально выгодны. Потому что за счёт закона Меткалфа люди, которые у вас уже есть — никуда не убегут. Альтернатива в 2-3 менее популярная будет в 10 раз менее привлекательной. А все эти синенькие стикеры и прочее позволяют вам привлекать людей, которые, в противном случае оказались бы не у вас.
Всё это, внезапно, ломается когда вы достигаете планетарного масштаба: новых людей больше привлекать неоткуда, так что ценность вашго сайта перестаёт расти — а альтернативные решения всё равно лекче и удобнее.
И тогда Facebook приходит на смену MySpace, а Google Docs вытесняют MS Office.
Но цикл занимает десятилетия. И за это время вы увидите десятки умерших конкурентов, пытавшихся сделать что-то «маленькое и простое». Так что всё равно выгодно.
nikolayv81
Сейчас google и Facebook решают эту проблему (передела) скупкой всего того что хоть на 1% в потенциале будет угрожать, и что-то я не вижу у них желания (реального выливающегося в какие-то действия) по конкуренции друг с другом..
khim
А зачем им конкурировать друг с другом? Конкурент появится на новом поле, как Google повился в Web, который, в своё время, «упустила» Microsoft. После XP были планы сделать «великую OS всех времён и народов» с WinFS и разными другими чудесами, потому Microsoft на развитие Web-технологий «забил»… они должны были умереть… Google и Facebook этим воспользовались…
Что, и, главное, когда, «упустят» Google и Microsoft — мы не знаем…
DoubleW
Увы мы пришли к тому состоянию что быстрее! отрендерить картинку крутой игры и передать ее по сети, декодировать и показать этот поток, собрать юзер инпут и передать назад, чем локально открыть страничку гмейла или ютуба.
Надеюсь через год два в Stadia/Geforce now/Apple Arcade будет приложение 'браузер который не особо лагает' — и хоть таким путем интернетом будет пользоваться удобно.
Smartfon
Уже даже есть первые проекты: http://mightyapp.com/
Akuma
Гораздо интереснее сделать веб-сервер, который будет рендерить тсраницу и отдавать поток в браузер. Т.е. такая Stadia на своих серверах :)
nick758
По идеологии это получается даже не ранний web, когда HTML полностью генерился на стороне сервера, а что-то типа telnet-доступа, который был ещё раньше :)
Akuma
Тонкий клиент для браузера. Ух, до чего докатились :)
iproger
Единственный выход, как и всегда, стараться находиться максимально далеко от устройств которыми пользуются обычные юзеры. Если все сейчас сидят на пеньках то надо i5-i7, если на i5 то i7-i9. Вот и весь рецепт.
XXXXPro
Предложение в духе «лучше быть здоровым и богатым, чем бедным и горбатым». Вроде и все правильно, но совершенно бесполезно. Не говоря уж о том, что идти покупать новый компьютер вместо того, чтобы писать feedbacks в духе «ваш сайт отстой, потому что тормозит на моем компьютере» — это поощрять и дальнейшее сохранение подобной ситуации.
Гораздо лучше было бы наоборот, сделать нормой, что разработчики (а в идеале и не только сами разработчики, но и те, кто принимает решение делать ненужные украшательства типа тех же «синих ников») должны тестировать свои продукты на компьютерах десятилетей давности и неустойчивом 3G-соединении. Вот тогда бы все быстро оптимизировали как надо или просто поотключали все лишнее. Жаль только, что непонятно, как такое сделать…
iproger
Инструмент должен быть хорошим, это не роскошь. Хотя я бы согласился чтобы некоторые разработчики работала на слабых машинах, но многие и так на ноутах работают.
Фидбек ничего не исправит потому что остальным 95% и так норм. Вилять можно только самому стараясь оптимизировать где получается и не косячить.
Я люблю пользоваться встроенными виновыми программами по типу Photos. Так вот, мою библиотеку из 50к фоток и видео приложение индексировало несколько часов на 9900k. Даже после индексации на hdd фотографии показывались с задержкой в несколько секунд, особенно если быстро скроллить. И только после переноса всей библиотеки на ssd этим стало можно пользоваться. При этом загрузка процессора спокойно скачет до 100%.
Вот такое делать не надо, ложить болт на оптимизацию.
khim
iproger
Ну это сугубо с точки зрения моментальной прибыли. Но в перспективе это плохо.
onum
HTML механизмы отлично подходят для (полу)статических страниц. Делать на них приложения, сравнимые по UX с нативными, огромная боль. История написана в 2016, и возможно твиттер тогда был ужасным веб приложением, но с тех пор они стали использовать еще больше JS технологий и стало лучше — теперь это PWA c кешированием кода в воркерах, пуш нотификациями, отложенной загрузкой, обновлениями в реальном времени. И все работает на слабых смартфонах с плохим интернетом.
Так, что дело не в том, что разработчики усложняют веб, а в том, что требования к сайтам выросли и нужно делать из
говна и палокHTML+CSS+JS что-то сравнимое с нативными приложениями. И призывать нужно к ускорению JS, а не к его устранению.sumanai
Я вот всё это поотключал. Никакого контроля над воркерами нет вообще, очень странно в списке установленных фоновых воркеров видеть десятки сайтов, на многих из которых я не был или был один раз. А уж как нотификации задрали, не описать.
?
DIITHiTech
Такие нынче тренды. Тяжелые all-in-one фрейморки очень понизили входной уровень, а 99% бизнесов важны в первую очередь стоимость и скорость, при чем скорость на первом месте. Большинство не готовы платить за найм более дорогих узких специалистов, тех же джабаскрипт инженеров для фронта, если производительность/качество решения не на первом месте у продукта, а таких мизер.
Digitalio
Это не только JavaScript касается, проблема намного глобальнее. Например, в одной компании где я работал, было одно приложение, вся функциональность которого сводилась к одной задаче — периодически вызывать заранее заданный HTTP endpoint и если вызов завершается с ошибкой — звонить тревогу. В приложении было больше 100 классов, неимоверное количество паттернов и использовалось более 20 внешних библиотек.
Просто есть такой сорт людей, которые думают, что чем сложнее решение задачи — тем лучше.
khim
puyol_dev2
Решать задачу просто — ведь не интересно )
hewlett-pacific
Ну а теперь прикинем в уме, какой стек стоит за фейсбуками и твиттерами:
1) PHP. Да, в 2020-м все еще используется. И специфика такая, что это не голый слоник, а с неким фреймворком, экслюзивным для корпорации. На этом уровне готовится только базовая разметка блоков и коммутируются запросы к более глубоким слоям(которые с плюсами, распределением нагрузки и прочими страшными для фронтендщиков вещами)
2) Фронтенд-фреймворк. React, Angular и еще 200 миллионов подобных библиотек. Но скорее всего и это велосипед от команды условного фейсбука. Эта часть — основная. Из-за нее "в памяти браузера на 140 символов крутится 40 мегабайт". Тут и xhr, и украшательства в виде сложных анимаций, и стейты блоков, и сборка самих блоков в страницу. Этот слой в современном мире — критичен, поскольку является полным клиентским приложением. Возникает вопрос: почему так? Ответ не так очевиден: это не лень разработчиков реализовывать принципы Progressive Enchancement, такой дизайн диктует сложность их системы. Приведу пример: есть у нас лендинг с пятью секциями, шапкой, подвалом. На нем красивое слайдшоу, пара графиков и промо-коллаж с эффектом параллакс. Сверстать такое с добрыми, разумными, вечными идеями Progressive Enchancement сложно, но можно.
А теперь контрпример: есть у нас веб-приложение с независимыми блоками, сотнями состояний, диаграммами переходов, фоновой динамической подгрузкой функций из api, веб-сокетами, банерами, умными сетками фото… Реализация перфекционистких идей изрядно нагрузит команду разработки и нет никаких гарантий, что система не развалится на экзотической сборке Konqueror в "билде линупса от Васяна". Поэтому ЦА — 80-95% пользователей не с тапка. А на тапке есть отдельное приложение.
Сейчас есть более перспективное направление — service workers, но далеко не все браузеры это поддерживают, да и такие "сознательные" пользователи, как автор поста будут категорически против, поскольку сидят с тапка через браузер и не хотят "выкачивать эти ужасные корпоративные малвари себе в ПЗУ".
В итоге имеем старый как мир конфликт: свистоперделки vs байтое… во.
iproger
Зачем вы принижаете PHP? За последние 5 лет он ускорился на сотни процентов, принял много новых стандартов написания кода и много новых фишек.
VolCh
React — велосипед от реального Фейсбука, Angular — от реального Гугла :)
KaiAndry
Нельзя просто взять и решить все задачи с помощью нативных инструментов.
Пример с кастомизацией скролбара. Если в вебкит еще есть возможность сносной кастомизации, то в FF такую возможность добавили совсем недавно, про ie и edge не знаю. В macos скролбар вообще не отображается у контейнера.
Есть множество велосипедов которые решают эту проблему полностью эмулируя прокрутку через js. Вот тут я предпочел быть путь автора, оставив нативное поведение и события скрола, просто рисуя бары через js. В таком случае без js пользователь будет видеть то же что в macos — контейнер без скролбаров, но скролящийся.
Что касается select. Его кастомизация тоже сильно ограничена. Нельзя например использовать html разметку в тегах option. Эмодзи в ff в списке выбора не отображаются. Css свойства применяемые к options могут работать, а могут и не работать, в зависимости от браузера (ios safari).
Есть вариант сделать свой select с сохранением всего нативного функционала используя веб компоненты. Но опять же, без использования js не обойтись.
Вообще как и автор я противник больших бандлов и кривых велосипедов. Но видно что автор смотрит только с точки зрения пользователя и ударяется в крайности.
sumanai
Не нужно кастомизировать скроллбар.
Не нужно кастомизировать селект.
Kanut
Вы вот так вот взяли и за всех сразу решили что «не нужно»? Вам может и не нужно, а у кого-то может быть целевая аудитория фетишисты кастомизированных селектов и скроллбаров :)
Spaceoddity
Ну если так пойти — и дизайн тогда уж не нужен. А следовательно и css.
sumanai
Дизайн ради дизайна действительно не нужен. А вот UX при помощи грамотного оформления прокачать стоит.
XXXXPro
Жаль, что не могу поставить вам плюс. Согласен целиком и полностью. Кастомизировать что-то нужно только тогда, когда это критично важно для основных функций сайта/приложения. В остальное время следует обходиться стандартными элементами.
MinGW
Кастомизировать скроллбар можно. Но…
Во-первых, на это нужны конкретные причины, а не «просто так», «шоб было», «у других оно в крапинку».
Во-вторых, это нужно делать не убивая нафик полностью нативный скролл.
А селект-то нафига кастомизировать? Просто не могу представить где это действительно необходимо.
Ну и если вдруг окажется что надо — думаю можно сделать и через CSS без скриптов.
XXXXPro
Продублирую свой комментарий: проблема обычно в том, что решения кастомизировать select/scrollbar или еще что-то принимают люди, которые не понимают, насколько это утяжелит код и какие проблемы это может создать.
TuzSeRik
Все перечисленные категории людей составят дай боже чтоб один процент от аудитории среднего сайта и дай боже чтобы приносили прибыли на зарплату одного программиста. А уж про то, чтобы переписать законченное комплексное приложение наподобие твиттера и фейсбука для повышения скорости работы при помощи каких-то хаков, нужен далекооо не один программист… Вы сами за это все заплатите?
karp
Так точно. Минуту ждал загрузки комментов к этой записи.
https://ustyugov.net/tmp/img/hbr_cmt.jpg
askunash
Флеш верните же
antoinedze
Итак, давайте конструктивно.
yandex.ru за 45 секунд — это сильно. Ради этого стоит зарегаться на хабре и ответить.
Я ни разу такого не встречал, поэтому сразу вопрос. 45 секунд window.load или domcontentload? Не приплюсовали время асинхронной загрузки?
Если нет, то стоит задуматься о провайдере. Нет серьезно. На канале не может быть 100 честных мегабит. Или как говорится 100 мегабит 100 мегабитам рознь. Я лично вообще не смотрю на эту цифру. К черту — я даже на пинг не смотрю. Я просто открываю страницу, и если прелоадер на вкладке крутится неприлично долго без видимых причин — у меня начинается ломка и рези. В таких случаях я даже не пытаюсь звонить в поддержку. Далее следует просто смена провайдера.
Я наблюдал недавно один случай. Клиент просто горел от того что у него все медленно работает. Я лично подключился к нему через TeamViewer и убедился в том, что железо у него нормальное, среднее. Но скорость соединения — раза в 3 все медленнее на глаз. 1 секунда превращается в 3. 10 секунд превращается в 30. Это действительно раздражает.
Но вы ведь знаете — чудес не бывает. Мне остаётся гадать как вы умудрились прожить столько, сталкиваясь с подобной проблемой, и не сойти с ума.
Lexicon
Справедливости ради, автор (видимо ради громкого заголовка) как бы пишет о JS.
Но, в реальности, огромная часть всего этого проблемы сетей и браузеров.
Будь в браузерах Java ничего бы не изменилось.
Остается необходимость подгружать скрипты, на каждом прыжке tracert с вас все еще пытаются собрать всю информацию, удостовериться, что на вас висит правильный рекламный маркер и на всякий случай дать вам уникальную возможность зарезолвиться в CDN вне своего региона… просто так.
Гугл отличный пример абсолютного бессилия перед безумием контент-сервисов.
Pagespeed порой абсолютно непонятным образом загружает свои собственные шрифты с google.fonts целую вечность, рекомендуя на хранение их локально. (а в реальности, перенос их с CDN, где они давно закешированы почти у всех на собственный сервис — безумие).
nikolayv81
Вам никогда не приходилось использовать сервисы одной страны в другой стране через 3g с неидеальной связью? Или сайты только для городов и тех кому повезло?
sentyaev
Ну так давайте клеймить провайдеров за их медленный 3g и то что они не тянут оптику в деревню. Причем тут JS?
Areso
Потому что в эпоху медленного интернета, сайты, злоупотреблявшие рекламой (в виде картиной или gif-ок, чуть позже — swf), загружались хоть и медленно, но всё равно работали.
А сейчас — автообрыв соединения через 30 секунд, мегабайты JS кода, синхронные вызовы счетчиков/соцкнопочек, и так далее.
Раньше просто было. Настраиваешь: картинки — загружать не загружать, SWF загружать по клику, у анимаций — только первый кадр, и так далее.
Но даже пока ты ждешь картинку радиосхемы (в отдельном окне, как правило, потому что в саму страницу вставляли превью), весь остальной текст уже скачался и доступен для прочтения. Осталось лишь дождаться схемы в полный размер во втором окне…
sumanai
Эх, сейчас бы так. А то расширение для анимирования гифов по наведению умерло с отказом от XUL, с тех пор всё.
justhabrauser
По секундомеру.
От нажатия Enter в адресной строке до исчезновения полоски индикатора загрузки и появления всей странички, когда ней уже можно пользоваться.
Меня, как пользователя, не интересует windows.load или domcontentload.
Мне надо доехать из точки А до точки Б за минимальное время.
PS. и, кстати, с отключенным JS эта же страничка грузится 1 секунду. По секундомеру.
antoinedze
То что вы говорите это domcontentload, или document ready на jquery.
Я понимаю, что как пользователя вас это не интересует. Пользователям вообще на все наплевать. Но я говорю с вами не как с пользователем, а как с разработчиком, коли уж вы так подробно все расписали.
В общем мой вердикт таков. О подобных проблемах я слышу очень редко. Следовательно в относительной картине мира у всех все ок. Значит проблема носит частный характер и не стоит ее так глобализировать. Попробуйте поработать в иных условиях, уверен экспириенс будет другим
x-tea
Продажи должны расти, каждый год. А телефоны, компьютеры (машины, холодильники и т.п.) так медленно стареют, если ничего не предпринимать.
Max8k
Проблема не нова, увы. Напомнило статью из 2012-го про молотки
praeivis
Так эта статья тоже написана в 2016 году. То есть 4 года назад. Это только перевод свежий.
puyol_dev2
js — это возможность верстальщику почувствовать себя программистом ) Зачем лишать этой возможности )
novice2001
Очень правильная статья. И защитники дендрофекального подхода упорно не видят того, что весь этот js зачем-то массово используется на страницах, которым интерактивность вовсе не нужна.
nikolayv81
Так у нас же (из заявлений Big fourв т.ч.) data-driven (или как там правильно) экономика, вот пустая страничка и делает свой вклад собирая "цифровой отпечаток"
1c80
Как перестанут за него баксовать, так и успокоимся сразу же.
Haarz
Авторка злая. Пытается лишить хлеба всех ява-бомжей, пригревшихся у труб всемироной паутины. Если они перестанут иметь «работу», то пойдут грабить, ибо на стройках все места разнорабочих заняты таджиками.
Digger747
Подобное WEB-кодирование — полное неуважение к пользователям.
Создающие подобные сайты «вебмастера» скорее всего не видели, или забыли, времена загрузки сайтов через обычные телефонные модемы, и 386, 486 компьютеры, с памятью 2-16MB.
К интернет имели доступ в основном инженеры и руководители компаний, очень много было сайтов с интересной и полезной информацией, т.к. люди делились своими разработками и документацией.
Сейчас же интернет превратился в засилие рекламы, — мало того что стало практически невозможно найти полезную информацию, так ещё и компьютеры «дымят» от скриптов.
Дошло уже до откровенного вебмастерского хамства — некоторые сайты попросту не открываются если у тебя «неподходящий браузер» под «сверхтехнологии».
Совсем разучились писать сайты руками, лепят их на всевозможных движках, навешивают огромное количество модулей, скриптов, рекламы, и всё это с перекрёстными ссылками…
Таким «вебмастерам» и вправду нужно работать через обычные телефонные модемы на компьютерах не мощнее первого пентиума.
VolCh
Я вот собственно на те времена и ориентируюсь. Я ждал минутами загрузки/рендеринга/реакции на 18кбит, и они подождут столько же на 1 гбит. Злая шутка, если что
MinGW
Всё так. Полностью поддерживаю.
И подобное творится не только в Web.
kocherman
Я ненавижу неумелое использование динамического HTML. Я не против JavaScript. Мне не трудно дотянуться курсором до правого верхнего угла либо открыть это же меню комбинацией клавиш.
Мою точку зрения можно рассматривать как мнение веб-мастера с браузером, у которого на всех сайтах по-умолчанию JavaScript выключен и, работает только локальный JS сайта, и также JS, который хостится на CDN-доменах, входящих в белый список, который пополнялся семь с лишним лет, и всё также как и тогда содержит 0 доменов.
Нет, нет, я не использую NoScript. Мой джентельменский набор расширений на каждый день куда более скуден (под спойлером).
DistortNeo
Конкретно на Хабре у меня ещё есть следующее блокирующее правило фильтра:
Просто мне так удобнее. А скрипты — да, не мешают.
sumanai
Ха, строчка. У меня 61. А есть люди, которые полностью перекраивают стиль, включая перекраску в чёрный цвет.
1c80
ublock убил майл ру, а там у меня файлопомойка есть, а umatrix уложил vimeo, самое нормальное что я видел это были списки в ИЕ, рекламы почти нету, а все сайты работают
stargrave2
С месяц назад писал более детально чем же мне так не нравится JavaScript blog.stargrave.org/russian/9ecf9331987a62db1d012bef94c39406a1d6af60. Но там в основном вопрос безопасности. Юзабельность хорошо описана в этой статье.
datacase
Когда я узнал году в 2015-м, что в JS нельзя просто так получить текущую дату и время в нормальном формате, я понял, что у JS незавидное будущее.
bgnx
И какой же по вашему нормальный формат даты и времени? В js unix time можно было получить всегда. А для других форматов получаем слишком много нюансов — https://habr.com/ru/post/146109 и https://habr.com/ru/post/313274/
datacase
«Что может быть проще времени» (с) Клиффорд Саймак
Что-то типа var current = Date.now(«d.m.Y H:i»)
И на выходе «03.03.2020 08:53»
Alexus819
хоткей не подскажете?
jetexe
Пользуюсь плагином Vimium в Firefox. Для него эта клавиша "F"
ghost404
Не понимаю всей этой шумихи с
<textarea>
. Все WYSIWYG редакторы текста или кода, которые мне когда-либо попадались, начинаются с textarea. То есть, в вёрстке добавляется элемент ввода textarea и после загрузки страницы он переколбашывается js-ом в полноценный WYSIWYG. То есть, по у молчанию у всех WYSIWYG редактором есть совместимость с NoScript. Аналогично с кастомизацией select, input[type=file] и т. д.Зачем Twitter решил использовать WYSIWYG для сообщений уже другой вопрос.
Первое, что пришло в голову — для оптимизации создания твитта и уменьшения вероятности внесения правок в него после публикации или полный запрет изменения твитта после публикации.
Поясню. Оптимизация показа твитта во всех лентах может привести к удорожанию процедуры публикации твитта и внесение правок в твитт приводит фактически к повторению процедуры публикации твитта только ещё сложнее из-за необходимости найти твитт в других лентах. Цена внесения правок в твитт может измеряться во вполне реальных долларах (лет 8 назад разрабатывал аналог стены ВК для одной соцсети и я имею некоторое представление о вопросе). Поэтому, вполне логичным шагом может быть подключение WYSIWYG с целью оптимизации пользовательского интерфейса и уменьшения собственных расходов.
Медленная загрузка страницы из-за обилия JS это конечно проблема и её надо решать. Во времена IE6 шел разговор о внедрении jQuery в браузеры. С появлением ES6, популяризацией движка Chromium и отказом от старых браузеров необходимость в jQuery резко сократилась. Но появилась новая проблема — фреймворки. Частично проблему решает SPA, и я не думаю, что белый экран у пользователей с NoScript повод отказываться от него.
sumanai
Как будто SPA нельзя совместить с серверным пререндерингом.