Hacker News Digest

Чар простой текстовой страницы

Открывая страницу из одного текста, я чувствую облегчение: нет баннеров куки, рекламы, всплывающих подписок и автозапуска видео.
Только чистый, быстрый, читаемый текст.

Такой контент можно скопировать в письмо, отправить в ChatGPT, распечатать или сохранить на Kindle — он везде работает.
Ссылка открывается мгновенно без CDN и предзагрузок.
Хостинг стоит копейки, сайт живёт даже на Raspberry Pi.

Читая, легко переключаться между беглым просмотром и вдумчивым чтением, не чувствуя вины за «потерянное» время.

Спасибо всем, кто публикует текст без лишнего.
Вы жертвуете «вовлечённостью», но дарите интернету простоту и покой.
Мне это безумно нравится.

• Участники мечтают о браузере без JS, где только HTML и выбранная пользователем CSS-тема.
• Хвалят сайты вроде plaintextsports.com и berkshirehathaway.com за минимализм, читаемость и отсутствие трекеров.
• Спорят о шрифтах: кто-то любит моноширинные «под печатную машинку», кто-то просит sans-serif и контрастные цвета.
• Соглашаются, что картинки допустимы, если служат тексту, а главный враг — избыточный JS, баннеры и медленные фреймворки.
• Вспоминают лёгкие новостные «lite»-версии CNN/NPR и альтернативные протоколы вроде Gemini как примеры «текстового» интернета.

Горизонт в 41,60054° N, 93,60911° W

• Высота: ~300 м над уровнем моря
• Рельеф: пологие холмы, сельхозугодья, редкие деревья
• Видимость: 20–25 км, ограничена деревьями и постройками
• Точки рельефа:
  • Север: 1,5 км до реки Des Moines
  • Юго-запад: 2 км до лесополосы
• Освещение: ровное, без резких теней из-за низкого рельефа
• Цвета: зелёные поля, тёмно-серая дорога, голубое небо

• Проект показывает реальный цвет неба прямо сейчас, используя расчёты по научной статье и данные местоположения Cloudflare.
• Пользователи в восторге: «совпадает 100 %», «в точку», «прекрасный минимализм», но ночью/при облаках видно просто чёрный или тёмный фон.
• Автор Suncalc рад, что его библиотека пригодилась; другие предлагают добавить погоду, сделать обои для iOS/десктопа или встроить в smart-дэш.
• Кто-то путается, ждёт загрузки, пока не понимает, что ночь; кто-то ставит телефон к окну и зовёт жену «посмотри!».
• В коде нет JS/CSS, только цвет фона, генерируемый сервером — это вызывает удивление и восхищение.

flip-card
Проект Nicholas-L-Johnson на GitHub: публичный репозиторий, демонстрирующий карточку, переворачивающуюся при наведении.

• Технологии: HTML, CSS, возможно JavaScript.
• Функция: плавный 3D-переворот с лицевой стороны на обратную.
• Применение: карточки товаров, профили, интерактивные элементы UI.

Клонировать:

git clone https://github.com/Nicholas-L-Johnson/flip-card.git

• Проект — ультратонкая электронная визитка с симуляцией жидкости; вызывает восторг, но кажется дорогой для раздачи.
• Ключевые плюсы: реалистичное движение «воды», простая и дешевая конструкция, легко отлаживать.
• Минусы: можно намочить одежду, толщина USB-C + ПКБ выглядит «толстой» для визитки, шрифт на обороте раздражает многих.
• Отмечены изюминки: USB-C на краю платы без дополнительных деталей, прошивка на Rust с плавающей точкой, аккумулятор почти кредитной толщины.
• Люди хотят больше деталей о сборке, просят sans-serif шрифт и чуть более игривый дизайн.

Я листал соцсети и наткнулся на 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 года) просто приводится к этому максимуму, а не даёт настоящую бесконечность.

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

Я люблю делиться: пишу блог, веду цифровой сад заметок и выкладываю почти весь код на GitHub. И обожаю читать чужие dotfiles, учиться у них.

Но свои публиковать некомфортно: мои алиасы, кастомизации и решения кажутся слишком личными. Почему — точно не знаю.

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.

Переосмысление DOM с нуля

Браузеры в странном положении: WebAssembly выстрелил, даже на сервере, а клиентская часть ощущается почти как 10 лет назад. Доступ к веб-API из WASM решают тонким JS-клеем — но зачем вообще лезть в DOM? Просто других опций нет. Пора отправить DOM и его API «на ферму», и вот почему.

Никто уже не знает браузеры целиком — и это часть проблемы.

Модель «документа»

Мало кто осознает, насколько DOM раздут. У document.body в Chrome 350+ ключей, а в document.body.style — около 660 свойств. Граница между свойствами и методами размыта, геттеры могут триггерить релэйаут, висят легаси-штучки вроде onevent. DOM толстеет; страничникам это почти не видно, а приложениям — боль.

Большинство избегают прямой работы с DOM; деклартивности мало и она несовременна. Способов сделать одно и то же много, ни один не приятен.

connectedCallback() {
  const shadow = this.attachShadow({ mode: 'closed' });
  const template = document.getElementById('hello-world').content.cloneNode(true);
  const hwMsg = `Hello ${ this.name }`;
  Array.from(template.querySelectorAll('.hw-text')).forEach(n => n.textContent = hwMsg);
  shadow.append(template);
}

Веб-компоненты пришли поздно, непопулярны: API громоздкий, Shadow DOM плодит уровни вложенности и области видимости. Главная беда — строковая наследственность SGML/XML: состояние хранить в документе плохо; React-подобные это избегают, их «XML» — лишь синтаксис.

HTML почти не менялся 10–15 лет. ARIA стала заплаткой тому, что не дала «семантика HTML». Цели так и не достигли: нет <thread> или <comment>, правила странные. WHATWG (то есть вендоры) добавляет лишь заплатки по краям; даже CSS оброс выражениями — любая шаблонка хочет стать языком программирования.

Редактируемость HTML через contentEditable — теоретически есть, практически — темная магия; у команд Docs/Notion наверняка кошмары. Догмы про «прогрессивное улучшение» и разделение разметки/стилей в мире приложений мало кто исповедует.

Сегодня приложения склеивают HTML/CSS/SVG до «достаточно красиво», ценой огромных оверхедов — это анти-UI тулкит.

Подпись: Ввод Slack

Подпись: Оффскрин-хаки для буфера обмена

Списки и таблицы приходится виртуализировать вручную, перехватывая лайаут, ресайз, драги и т. п. «Прилипший вниз» скролл в чате — вечный TODO. Чем больше виртуализируешь, тем больше заново пишешь «поиск на странице», контекстные меню и пр. Веб стер грань между UI и «текучим контентом» — когда-то это было ново, теперь UI устарел, контент унифицировался.

CSS вывернут наизнанку

CSS не имеет стройной…

• Участники признают, что веб-платформа сложна и разрослась из-за обратной совместимости, множества требований и долгой эволюции; переписывание «с нуля» в реальности лишь добавляет новые слои сложности.
• Многие защищают DOM/HTML/CSS: они кроссплатформенны, поддерживают доступность, приватность, IME/спеллчек и текстовые сценарии, с которыми канвас/кастомные рендеры часто не справляются.
• Критика фокусируется на перегруженности API, «текучих» абстракциях и смешении ролей (CSS как и стиль, и лейаут), предлагаются идеи модульности API, хранение состояния в документе, и дисциплинированное использование Web Components.
• Аргумент «выбросить и заменить» упирается в стоимость миграции и необходимость покрыть весь исторический функционал; успех веба объясняют именно гибкостью, хаками, позже закреплёнными стандартами, и жёсткой обратной совместимостью.
• Проводят параллели с нативными UI-стеками: многие считают веб-технологии более удачными; обсуждают Flutter/WASM/WebGPU как путь к «приложенческому» вебу без ломания существующего.
• Идеи разделения «документы vs приложения» всплывают часто (вплоть до «DOCTYPE app»), но консенсус: нужно сосуществование обоих подходов, а не замена.
• Скепсис к «HTML на Canvas» и «перезапуску браузера» высок: полезнее усиливать существующие примитивы (дешёвый доступ WASM к DOM, лучше продуманные формы/контролы, богатые стандартные виджеты), чем плодить новые параллельные стеки.