Hacker News Digest

Firefox на Android — единственный мейнстрим-браузер, который поддерживает полноценные расширения. Это позволяет мобильному Firefox блокировать рекламу, трекеры и всплывающие окна, а также перенаправлять запросы к проприетарным сервисам вроде Medium к альтернативным фронтендам. В результате вы получаете настолько же чистый и быстрый опыт, как и на десктопе.

• Firefox на Android стал значительно лучше, но уступает Brave в производительности и времени автономной работы.
• На iOS все браузеры вынуждены использовать WebKit, что ограничивает их возможности.
• Brave предлагает встроенный блокировщик рекламы и отсутствие трекеров, что делает его привлекательным для пользователей.
• Firefox для Android поддерживает полноценные расширения, включая uBlock Origin, что является его ключевым преимуществом.
• Некоторые пользователи отмечают, что Firefox для Android может быть менее стабилен и медленнее, чем Brave.

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

Helium включает уникальные функции, такие как нативные !bangs (позволяют быстро переходить на сайты, например, !w для Википедии), разделённый просмотр страниц и поддержку всех Chromium-расширений с анонимизацией запросов к Chrome Web Store. Интерфейс минималистичен, не отвлекает и настраивается под пользователя. Все обновления безопасности выпускаются оперативно, а синхронизация данных через облако отсутствует для максимальной конфиденциальности.

• Скептицизм по поводу использования Chromium в качестве основы для приватного браузера, учитывая контроль Google над экосистемой и необходимость альтернативных движков (WebKit, Gecko).
• Озабоченность отсутствием информации о команде разработчиков, модели монетизации и долгосрочных планах поддержки, что важно для доверия к автоматическим обновлениям.
• Критика и сравнение с другими браузерами (Brave, Firefox, Orion, Zen), где отмечаются недостатки Helium: отсутствие вертикальных вкладок, синхронизации с мобильными устройствами и поддержки MV2-расширений.
• Запросы о технических деталях: механизм автообновлений, поддержка Linux и мобильных ОС, версия uBlock Origin (MV2 или Lite), безопасность расширений.
• Некоторые положительные отзывы о качестве браузера и удобстве использования, но в целом преобладает осторожное или негативное отношение из-за зависимости от Chromium.

У Apple есть приватное CSS-свойство для добавления эффектов Liquid Glass на веб-страницах. Оно называется -apple-visual-effect и позволяет использовать материалы вроде -apple-system-glass-material.

Однако это свойство не работает в обычном Safari — только внутри приложений через WKWebView с включённой приватной настройкой useSystemAppearance. Использование этой настройки приведёт к отклонению приложения в App Store.

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

• Участники обсуждают новую приватную CSS-функцию Apple (Liquid Glass), доступную только для системных приложений, что некоторые считают антиконкурентной практикой.
• Высказывается предположение, что сама Apple активно использует вебвью (WebViews) в своих приложениях (например, App Store, Настройки, Музыка), но делает это настолько незаметно, что пользователи их не распознают.
• Многие отмечают, что плохая репутация вебвью связана как раз с теми случаями, когда они реализованы плохо, в то время как хорошо интегрированные остаются незамеченными.
• Эстетическая ценность и utility-эффекта Liquid Glass оцениваются участниками неоднозначно: одни видят в нём возвращение личности системе, другие считают его бесполезным и уже устаревшим.
• Часть комментаторов сомневается, что данная функция даёт Apple реальное конкурентное преимущество, и считает обвинения в антиконкурентном поведении безосновательными или преувеличенными.

• Пользователи хвалят Bitrig за «волшебство» и качество SwiftUI-интерфейсов, но жалуются на вылеты, пропадание проектов и отсутствие входа через Apple.
• Основные запросы: экспорт кода в Xcode, локальная сборка без облака, поддержка WebKit, возможность донастройки после генерации и BYOK-доступ к LLM.
• Не-разработчики рады простоте, но переживают о лимите в 100 сообщений/мес и сборе данных.
• Команда подтверждает: интерпретатор вызывает реальные фреймворки iOS, а не их клоны.

Проблема: GitHub в Safari работает крайне медленно.
Описание: Страницы грузятся по 5–10 сек, анимации подвисают, прокрутка «рыхлая». В Chrome и Firefox всё нормально.

Версии:

• Safari 17.5 (macOS 14.5)
• Safari 16.6 (macOS 13.6) – та же картина

Что пробовали:

• Очистить кэш и куки
• Отключить все расширения
• Переключить DNS (Cloudflare, Google)
• Сменить сеть (домашний Wi-Fi, мобильный интернет)
• Включить/выключить «Разработка → Использовать WebKit Nightly»

Результат: ничего не помогло.

Симптомы:

• В Activity Monitor процесс «Safari Web Content» грузит CPU до 100 % при открытии любой страницы GitHub.
• В инструментах разработчика видно, что 80 % времени уходит на «Rendering».

Временное решение:

• Переключиться на Chrome/Firefox.

Просьба: Проверьте, не сломали ли вы что-то в CSS/JS для WebKit.

• GitHub стал критически медленным: Safari и Firefox тормозят даже на мощных М-системах, а большие PR (>1000 файлов) почти не открываются.
• Пользователи связывают падение производительности с переходом на React/SPA после покупки Microsoft и отказом от старого SSR.
• Предлагают мигрировать на Forgejo, Codeberg, SourceHut или возвращаться к простому HTML/CSS.
• Вопрошают, как в крупной компании могут пропустить такую регрессию и почему тесты не ловят разницу между Chrome и Safari.
• Ситуация повторяется и на других сайтах (Jira, Stripe, GCP), вызывая разговоры о «блоте» современных веб-приложений.

CSS random()
Новая функция random(min, max, step) генерирует случайные значения без JS. Все аргументы должны быть одного типа; step опционален и округляет результат.

Пример: звёздное поле

body{background:#000}
.star{
  position:fixed;
  top:random(0%,100%);
  left:random(0%,100%);
  width:random(2px,10px,1px);
  background:#fff;
  border-radius:50%;
}

Каждый .star получает случайные координаты и размер, создавая естественное распределение.

Дополнительные эффекты
Используйте CSS-переменные и слои box-shadow для свечения, а random() для прозрачности и цвета, усиливая атмосферу.

• Предложили «старую» технику «cicada principle» с фонами-простыми числами для предсказуемой «случайности».
• Обсудили, что «настоящая» случайность в графике выглядит плохо из-за скоплений и пустот; нужны low-discrepancy последовательности.
• Подняли вопрос воспроизводимости: хотят фиксированный seed при перезагрузке, но пока в спецификации нет такого механизма.
• Появились шутки о «безопасности в CSS» и предупреждения не использовать random() для криптографии.
• Ссылка на спецификацию: CSS Values 5; работает пока только Safari.

Я листал соцсети и наткнулся на toot Энди P с трюком:

width: calc(infinity * 1px); height: calc(infinity * 1px);

Подумал: отличный тест на пределы. Если отдать браузеру бесконечность через ключевое слово infinity, он всё равно зажмет до максимума — можно понять верхнюю планку.

Сделал див с width/height: calc(infinity * 1px), обнулил отступы, проверил в Safari, Chrome и Firefox (Nightly) на macOS — и началось странное.

• Safari: около 33,554,428 px по ширине/высоте
• Chrome: около 33,554,400 px
• Firefox: высота схлопывается до межстрочного (например, 19.2 px при normal, 16 px при line-height: 1), ширина — вычислено ~17,895,700, но в раскладке ~8,947,840 (ровно половина минус 10)

Safari/Chrome почти упираются в 2^25 - 1 (33,554,431), но чуть ниже. Почему именно так — загадка. Firefox же ведет себя особенно: высота с “бесконечностью” игнорируется и падает к строке, ширина делится пополам в layout.

Дальше я попробовал font-size: calc(infinity * 1px):

• Safari: 100,000 px
• Chrome: 10,000 px
• Firefox: вычислено 3.40282e38 (макс для 32-бит float), но в раскладке шрифт ~2,400 px при normal; при line-height: 1 высота блока вдруг раздувается до ~8.9 млн. То же при переносе стилей на body.

Вывод: у Safari/Chrome жесткие десятичные лимиты для font-size (100k и 10k). У Firefox — вычислительно “бесконечность” как float, но реально рендерится ограниченный размер и странная связь с line-height.

Проверил line-height: calc(infinity * 1px):

• Safari: ~33,554,428
• Chrome: ~33,554,400
• Firefox: вычислено ~17,895,700, в раскладке ~8,947,840

Итоговые наблюдения:

• Safari/Chrome для размеров элементов/line-height ограничивают около 2^25 - 1; для font-size — вручную заданные пороги (10k/100k).
• Firefox: несогласованность вычисленного и реального значения; высота может схлопываться к строке, ширины/line-height делятся пополам, сильная зависимость от line-height.

Если кто знает первопричины (история движков, типы хранилищ, квантизация, внутренние лимиты раскладки/скролла/композитинга) — расскажите в комментариях или постом с трекбеком.

• Firefox ограничивает высоту блока 17 895 697 px — это максимум для 32-битного signed-целого в единицах 1/60 px.
• Chrome/Safari держатся чуть выше, около 33 554 431 px, т.к. у WebKit/Blink единица 1/64 px и тот же 32-битный signed.
• «Бесконечные» таблицы/листы реализуются через огромный прокручиваемый div, но приходится рисовать свой скролл или канвас, когда нативный height перестаёт работать.
• CSS-значение infinity (новое 2–3 года) просто приводится к этому максимуму, а не даёт настоящую бесконечность.