Hacker News Digest

Автор статьи рассматривает судьбу небольших open source библиотек на примере своего пакета blob-util, который уже 10 лет стабильно набирает более 5 миллионов загрузок в неделю. С ростом использования ИИ (около 80% разработчиков уже применяют его в работе), такие утилиты становятся менее востребованными, ведь LLM вроде Claude способны генерировать аналогичный код по запросу. Автор отмечает, что хотя сгенерированный код может быть даже более надёжным, исчезает образовательная составляющая — его библиотека включала не только функционал, но и обучающие материалы с забавными примерами, помогающие понять принципы работы с Blob в JavaScript.

По мнению автора, эра небольших низкозначимых библиотек подходит к концу, и ИИ становится последним гвоздём в гробу этого явления, хотя и до этого многие функции перешли в браузеры и Node.js. Это означает не только упрощение разработки, но и потерю возможности использовать такие библиотеки как трамплин для обучения разработчиков. Возможно, в будущем понимание механики работы таких утилит станет так же необязательным, как и умение разворачивать бинарное дерево, о чём многие разработчики уже давно спорят.

• Разработчики всё чаще полагаются на ИИ, что ставит под сомнение ценность мелких утилитарных библиотек и даже саму идею open-source как таковой.
• Сообщество уже не в состоянии оценить ценность мелких, но полезных вкладов, поскольку ИИ может их сгенерировать за секунды.
• Это ведёт к тому, что единственный способ остаться востребованным — это делать действительно сложные и полезные вещи, а не просто публиковать мелкие скрипты.
• Парадокс в том, что даже если кто-то и захочет внести вклад в open-source, то непонятно, как теперь оценить этот вклад.
• В конечном счёте, если мы хотим, чтобы open-source выжил, мы должны будем придумать, как оценивать вклад и признание заслуг — возможно, через систему репутации и/или сертификации.

Расширение tweeks предлагает пошаговый онбординг для подключения, включения скриптов и запуска первых модификаций веб-страниц. Процесс включает шесть этапов: установка расширения, закрепление для быстрого доступа, включение скриптов, запуск первого tweek, генерация первого скрипта и его модификация. Расширение позволяет создавать индивидуальные скрипты с помощью естественного языка и предоставляет готовые решения для распространенных задач.

Примеры возможностей включают режим фокуса для отвлекающих платформ вроде LinkedIn и YouTube, персонализацию лент в социальных сетях с фильтрацией по дате и количеству лайков, а также кастомизацию интерфейсов, например, превращение Google в командную строку 1970-х годов. Расширение работает на любом сайте и позволяет полностью переопределять DOM-структуру страниц, давая пользователям полный контроль над своим веб-опытом.

• Пользователи высоко оценивают идею "deshittify" веба через AI-генерацию кастомных скриптов для сайтов, называя её "крутой", "нужной" и "вдохновляющей".
• Поднимаются технические вопросы: глубина модификации страниц, тестирование модели, локальный запуск AI, детерминированность результатов и потенциальные риски утечки данных.
• Выражаются опасения по поводу бизнес-модели: риски судебных исков от соцсетей (Facebook, Reddit), монетизации, приватности данных и закрытости кода по сравнению с open-source альтернативами (Greasemonkey, uBlock Origin).
• Активно запрашивается поддержка Firefox, синхронизация настроек между устройствами и возможность совместного использования/поиска готовых скриптов.
• Критикуется отсутствие на сайте политики приватности и условий использования, а также сомнения в необходимости VC-финансирования для такого инструмента.

В статье утверждается, что JavaScript-библиотеки для выбора даты, такие как Pikaday, часто не нужны и могут приводить к ошибкам и брошенным формам. Вместо этого рекомендуется использовать нативные HTML-инпуты: date для дат, time для времени и datetime-local для их комбинации. Эти решения требуют всего одной строки кода, обеспечивают лучшую доступность, производительность и интернационализацию, работают без JavaScript и позволяют браузеру обрабатывать сложные детали.

В качестве альтернатив предлагаются раздельные инпуты для дня, месяца и года (особенно полезно для запоминающихся дат), селекты при ограниченном наборе вариантов и маскированные инпуты с плейсхолдерами. Для улучшения опыта можно использовать атрибуты: inputmode="numeric" для отображения цифровой клавиатуры, maxlength для ограничения ввода, pattern для валидации, autocomplete для автозаполнения и min/max для ограничений диапазона. Автор подчеркивает важность прогрессивного усиления и учета пользователей без JavaScript.

• Пользователи жалуются на нативные пикеры из-за необходимости тысяч кликов, чтобы выбрать дату рождения, и наоборот — кастомные пикеры не позволяют вводить дату текстом.
• Разработчики отвечают, что нативный <input type="date"> не поддерживает форматов вроде «MM/DD/YYYY» и не даёт контроля над UI, а кастомные пикеры не решают проблему с доступностью и не имеют единого UX.
• В итоге спор сводится к тому, что нативный пикер не решает проблему, а кастомный — не решает её лучше.
• Пользователи также жалуются на то, что нативный пикер не позволяет вводить дату текстом, а кастомный — не позволяет вводить дату текстом.
• В итоге, обсуждение сводится к тому, что нативный пикер не решает проблему, а кастомный — не решает её лучше.

Страница XSLT.RIP объявляет о смерти технологии XSLT, обвиняя в этом Google. На минимальной веб-странице всего три строки: заголовок "Если вы это читаете, XSLT был убит Google" и два коротких соболезнования. Это мемориальная страница, созданная в знак уважения к технологии, которая, по мнению автора, прекратила свое существование из-за действий Google.

Страница оформлена в виде простого XML-документа с XSLT-стилем, что создает ироничный контент. Несмотря на скудность информации, это явный протест против прекращения поддержки XSLT, технологии, которая долгое время использовалась для преобразования XML-документов. Фраза "Rest in peace" (Вечная память) подчеркивает, что автор рассматривает это как окончательную кончину технологии, а не просто изменение в политике поддержки.

• Google не «убивает» XSLT, а лишь прекращает поддержку в браузере, что вызывает споры о том, насколько это технически оправдано.
• Сайт xslt.rip использует нарочито ретро-дизайн, чтобы подчеркнуть иронию ситуации, но это вызывает споры о том, насколько это уместно.
• Обсуждение поднимает вопрос о том, что XSLT всё ещё используется в медицинских записях и других нишах, где XML по-прежнему важен.
• Некоторые участники считают, что Google просто не хочет вкладывать ресурсы в поддержку устаревших стандартов, в то время как другие считают, что это естественный процесс устаревания технологий.

Marko — это декларативный язык на основе HTML для создания динамических веб-интерфейсов, расширяющий стандартный HTML возможностями для современных приложений. Любой валидный HTML является корректным Marko, но язык добавляет декларативные конструкции для реактивности и интерактивности, позволяя встраивать JavaScript прямо в шаблоны. Ключевые особенности включают потоковую передачу контента для ускорения первого отрисовки, оптимизирующий компилятор и минимальный рантайм, что обеспечивает высокую производительность даже для высоконагруженных проектов вроде eBay.com.

Фреймворк предлагает гибкость синтаксиса — от привычного HTML до более лаконичных вариантов Concise и JS — и поддерживает TypeScript для строгой типизации. Marko обеспечивает разделение concerns, управляемые компоненты, вложенную реактивность и неизменяемое состояние, что упрощает разработку масштабируемых приложений. Интеграция с экосистемой включает file-based routing и возможность использования как простых шаблонов, так и мощных компонентов по мере роста проекта.

• Обсуждение вращается вокруг того, что веб-разработка циклически возвращается к идеям, похожим на ColdFusion и JSP, и это вызывает у участников разговора разные чувства от ностальгии до раздражения.
• Участники обсуждают, что такое "HTML-основнный" язык, и как он отличается от JSX и других подходов, и почему мы снова и снова возвращаемся к этой идее.
• Обсуждение затрагивает вопрос о том, что некоторые считают, что эволюция веб-технологий просто движется по спирали, где старые идеи периодически перерабатываются и выдаются как новые.
• Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.
• Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.

Cerebras привлек $1.1 млрд в раунде G по оценке $8.1 млрд, представив платформу для быстрой генерации кода на базе модели GLM-4.6. Эта модель обрабатывает более 1,000 токенов в секунду, занимая первое место в рейтинге вызова инструментов Berkeley Function Calling и демонстрируя производительность на уровне Sonnet 4.5 в веб-разработке. Платформа позволяет использовать GLM-4.6 с любым AI-дружелюбным редактором кода через API.

Компания предлагает три тарифных плана: бесплатный с ограниченным доступом, Pro за $50 в месяц (24 млн токенов в день) и Max за $200 (120 млн токенов). Эти варианты подходят как для небольших проектов, так и для полноценной разработки с интеграцией в IDE. Cerebras позиционирует свой сервис как решение для поддержания состояния потока программиста без ожидания генерации кода.

• Cerebras Code с GLM 4.6 демонстрирует высокую скорость генерации (до 1000 ток/с), что значительно ускоряет итерации, особенно для UI-разработки и рутинных задач.
• Пользователи разделились: одни видят в скорости революцию для продуктивности ("секретное оружие"), другие скептичны, считая модель уступающей конкурентам (Claude, GPT) и сомневаясь в отсутствии квантования.
• Практическая ценность зависит от задач: скорость критична для быстрой обратной связи в веб-разработке, но менее полезна для глубокого кодирования или нишевых областей (embedded), где важнее точность.
• Поднимаются вопросы о реальной производительности модели, обоснованности цены ($50/мес) и устойчивости бизнес-модели, особенно при высоких затратах на токены.
• Аппаратная реализация (гигантский чип Cerebras) объясняет скорость, но вызывает споры о влиянии на качество вывода и отсутствие независимой верификации.

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

Проблема может возникать из-за нескольких причин: использование браузерных расширений (блокировщиков рекламы), сетевые неполадки или настройки самого браузера. Для решения рекомендуется проверить интернет-соединение, временно отключить расширения, особенно блокировщики рекламы, или попробовать использовать другой браузер. Включение JavaScript позволит сайту корректно загрузить все необходимые элементы и обеспечить полноценную работу.

• Mozilla уволил волонтёров-переводчиков без предупреждения и предложил «быстро созвониться» вместо диалога; это вызвало волну возмущения в сообществе.
• Сообщество ответило, что открытое ПО и волонтёрство не должны быть взаимоисключающимися, и Mozilla должна была бы заранее обсудить изменения и уважительно относиться к вкладу волонтёров.
• В обсуждении также поднимается вопрос о том, что Mozilla в целом отошла от своих ценностей и миссии, и что это не первый случай подобного поведения.
• Участники обсуждения также отметили, что Mozilla в последнее время стала более закрытой и корпоративной, что вызывает тревогу.
• В конце концов, Mozilla сделала официальное извинение, но волонтёры заявили, что это слишком поздно и что Mozilla должна была бы лучше коммуницировать с сообществом и волонтёрами.

Layoutit Terra - это интерактивный генератор рельефа на CSS, позволяющий создавать разнообразные ландшафты с настраиваемыми параметрами. Инструмент предлагает выбор между типами рельефа (пампы, холмы, горы) и биомами (умеренный, арктический, пустынный), а также контроль над размером мира и покрытием суши. Пользователи могут детально настраивать камеру через параметры вращения, наклона и увеличения, добавляя анимацию к созданным ландшафтам.

Генератор поддерживает экспорт результатов в多种 форматы, включая CSS, высотные карты, VOX, TXT и PNG, что обеспечивает гибкость использования. Функции импорта, отмены/повтора действий, а возможность копировать код для встраивания или открывать его в Codepen упрощают интеграцию в другие проекты. Несмотря на раннюю версию (v0.0.1), Layoutit Terra уже предоставляет мощные возможности для создания детализированных CSS-ландшафтов с минимальными усилиями.

• Пользователи отмечают, что «CSS-only»-демо всё же использует JS для интерактивности, хотя рендеринг ландшафта действительно на 100 % CSS.
• Визуально демо напоминает RCT, SimCity 2000, Populous и другие изометрические «тайкун»-игры, вызывая ностальгию.
• Несколько человек сообщили о проблемах с производительностью: при включённом JS в Firefox 144 и Chrome 131 на Windows 10/11 рендеринг занимает 100-200 мс на обновление кадра, что приводит к просадкам фпс.
• Автор ответил, что в будущих версиях планируется добавить реки и водопады, а также улучшить производительность.

Автор обнаружил, что AI-скраперы запрашивают закомментированные JavaScript-файлы с его сайтов, вызывая ошибки 404. Эти запросы исходили как от явно вредоносных ботов (python-httpx, Go-http-client), так и от пользовательских агентов,伪装ившихся под обычные браузеры (Firefox, Chrome, Safari). Похоже, скраперы пытаются нелегально собирать контент для обучения больших языковых моделей.

Автор предлагает два возможных объяснения поведения: либо боты правильно парсят HTML-комментарии в поисках отключенных URL, либо используют примитивные методы сопоставления шаблонов. Он отмечает, что скраперы различаются по уровню сложности — одни используют актуальные строки user-agent, другие даже не меняют значения по умолчанию в HTTP-библиотеках.

В качестве контрмер автор предлагает алгоритмическое саботаже, начиная с публичного раскрытия этой уязвимости. Он классифицирует поведение ботов как фундаментальное (в отличие от случайных ошибок), так как для их работы необходимо запрашивать ресурсы, которые никогда не загружаются реальными пользователями. Автор уже внедрил меры по обнаружению таких запросов на своих сайтах и призывает других делать то же самое.

• Обсуждение вращается вокруг этики веб-скрейпинга, причем акцент сместился с «как мы можем защититься от скрейперов» на «почему мы вообще должны считать, что скрейпинг — это что-то плохое».
• Участники обсуждения поднимают вопросы: что считается «нелегальным» скрейпингом, кто должен нести ответственность за злоупотребление данными, и какие технические и правовые рамки должны регулировать эту сферу.
• Разговор также затрагивает практические аспекты: какие методы могут быть использованы для защиты от скрейперов, и какие последствия это может иметь для веб-разработчиков и владельцев сайтов.
• Некоторые участники поднимают вопросы о том, какие последствия это может иметь для разработчиков и владельцев сайтов, и какие практические шаги они могут предпринять для защиты своих ресурсов.
• В конце обсуждение сместилось к тому, что участники начали обсуждать, какие именно технические и правовые рамки должны быть установлены для регулирования веб-скрейпинга, и какие последствия это может иметь для всех участников процесса.

Статья напоминает о четырех важных HTML-тегах, которые стоит включать для корректной работы веб-страниц. Без <!doctype html> браузеры могут переключиться в quirks mode, имитируя устаревшее поведение. Указание языка через <html lang="en"> помогает поисковикам и скринридерам правильно интерпретировать контент. Тег <meta charset="utf-8"> гарантирует корректное отображение специальных символов, таких как кавычки, эмодзи и нелатинские символы. Наконец, <meta name="viewport"> необходим для адаптивного дизайна, предотвращая крошечный текст на мобильных устройствах.

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

• Обсуждение затронуло тему минимализма в веб-разработке: отсутствие бандлов, использование Lit Elements без TypeScript и отсутствие сборщиков.
• Участники обсуждали, что HTML5 позволяет опускать закрывающие теги и некоторые атрибуты, что может влиять на читаемость кода.
• Были упомянуты такие практики, как неиспользование сборщиков и бандлов, что может быть связано с философией "no-build".
• Обсуждались также такие темы, как использование сторонних библиотек и фреймворков вместо "ванильного" JavaScript и CSS, и как это влияет на производительность и размер страницы.
• Участники также затронули тему "легковесных" решений и их влияние на производительность и удобство использования.

Разработчик создал расширение FocusTube с целью борьбы с прокрастинацией на YouTube Shorts. Проект основан на идее, что человеческая жизнь слишком ценна, чтобы тратить её на бесконечный просмотр коротких видео. Расширение, вероятно, блокирует или ограничивает доступ к разделу Shorts на YouTube, помогая пользователям вернуть контроль над своим временем и вниманием.

Название проекта "FocusTube" прямо указывает на его цель - вернуть фокус при использовании YouTube. Разработчик подчеркивает важность осознанного использования времени, предлагая простой, но эффективный способ борьбы с одной из самых распространенных форм цифровой зависимости в современном мире.

• Обсуждение показало, что Shorts вызывают у пользователей чувство вины, тревоги и страха за будущее поколений, а также вызывает желание блокировать их всеми доступными средствами.
• Участники обменивались ссылками на расширения и фильтры, которые позволяют скрывать Shorts, и обсуждали, какие именно элементы интерфейса можно скрыть или отключить.
• Некоторые участники поделились личными историями о том, как Shorts влияют на их жизнь и продуктивность, и как они пытаются избежать их влияния.
• Обсуждались различные способы блокировки Shorts, включая использование расширений браузера, изменение настроек YouTube и использование альтернативных клиентов.
• Участники также обсудили, какие именно аспекты Shorts вызывают наибольшее беспокойство, включая их влияние на внимание, фокус и психическое здоровье, и как они могут быть уменьшены или устранены.

Предоставленный текст содержит только навигационную структуру сайта MDN, но не основное содержание статьи о методе setHTML(). В тексте отсутствует описание самого API, его синтаксиса, параметров, примеров использования и совместимости с браузерами. Для создания точного пересказа требуется полное содержание статьи, описывающее новый метод DOM API, который, вероятно, предоставляет альтернативу innerHTML с дополнительными возможностями или улучшенной безопасностью. Без доступа к фактическому описанию метода невозможно предоставить содержательный пересказ его функциональности и применения.

• Впервые за 25 лет в Firefox Nightly появилась возможность безопасно вставлять HTML через Element.setHTML(), что вызвало обсуждение: спор о том, почему так долго не хватало базовой возможности, и о том, что API-шный дизайн (включая именование setHTML/setHTMLUnsafe) не идеален.
• Участники обсуждения отметили, что новое API встроенной санитизации встроенной в браузер — это фактически встроенный DOMPurify, и что спор в основном ведется о том, что «безопасность по умолчанию» должна быть выбрана как поведение по умолчанию.
• Некоторые комментаторы выразили обеспокоенность тем, что спецификация пока не различает между контентом и вставляемым через setHTML() и innerHTML, и что это может влиять на производительность, если разработчики начнутт читать спецификацию как «естественное продолжение» innerHTML.
• Были также затронуты темы о том, что встроенная санитизация может влиять на разработчиков, которые полагаются на встроенную санитизацию, и о том, что это может влиять на разработчиков, которые полагаются на встроенную санитизацию.

В 2009 году команда YouTube, состоящая из инженеров, которые ранее не прошли собеседования в Google, тайно внедрила код на платформу. Этот код показывал пользователям IE6 сообщение о прекращении поддержки, надеясь, что это заставит их обновить браузер. Хотя это могло показаться рискованным, учитывая возможную негативную реакцию, команда считала, что польза от ускорения отказа от IE6 оправдывает средства. Этот шаг отражал их разочарование в поддержке устаревших технологий и их изобретательность в решении проблем, не привлекая внимания. Этот инцидент демонстрирует, как даже в крупных компаниях небольшие команды могут влиять на значительные изменения, используя свои уникальные позиции для решения давних проблем.

• YouTube, Google Docs и другие сервисы Google стали причиной, по сути, смерти IE6, но в итоге привели к тому, что Chrome стал доминирующим браузером.
• Microsoft, Mozilla и другие не смогли быстро реализовать новые веб-стандарты, что привело к тому, что Google смог использовать свои собственные веб-стандарты для продвижения Chrome.
• В то время как Chrome стал доминирующим браузером, это не привело к лучшему вебу, потому что Google не заинтересован в улучшении веб-стандартов.
• Веб-стандарты стали менее открытыми и менее ориентированы на пользователя, в то время как Chrome продолжает доминировать.
• Это привело к тому, что веб-разработчики вынуждены тестировать свои сайты в первую очередь в Chrome, что в свою очередь ведет к тому, что сайты лучше работают в Chrome, чем в других браузерах.

Разработчики представили Hyperflask — новый фреймворк для Python, который объединяет множество инструментов в единую экосистему для ускорения разработки веб-приложений. Основная идея в том, чтобы избавить разработчиков от необходимости самостоятельно подбирать и настраивать различные технологии, которые часто требуются в проектах.

Hyperflask включает в себя множество готовых решений: от серверной логики на Flask до фронтенд-компонентов, маршрутизации, работы с формами и данными, а также инструментов для развертывания. Все компоненты тщательно подобраны для бесшовной совместной работы. Например, вместо самостоятельной настройки Flask с десятками расширений, разработчики получают единую среду, где всё "просто работает".

Ключевые возможности включают:

• Единая структура проекта: стандартизированная организация кода, что ускоряет onboarding новых разработчиков и упрощает поддержку.
• Готовые решения для типовых задач: аутентификация, отправка email, обработка файлов, фоновые задачи — всё доступно "из коробки".
• Гибридный рендеринг: статические страницы генерируются на сервере для скорости, но при необходимости могут динамически обновляться через HTMX.
• Оптимизация под SEO: серверный рендеринг гарантирует, что контент индексируется поисковыми системами.

Разработчики подчеркивают, что Hyperflask не просто набор инструментов, а целостная экосистема, где все части глубоко интегрированы. Это позволяет избежать типичных проблем, когда отдельные библиотеки, будучи собранными вручную, конфликтуют друг с другом.

Проект пока находится в стадии бета-тестирования, но уже доступен для использования. Основная команда состоит из разработчиков, ранее стоявших за популярными проектами в экосистеме Python, что говорит о серьезности намерений.

Для сообщества это может быть значимым, поскольку экосистема Python долгое время не имела полноценного аналога популярным JavaScript-фреймворкам вроде Next.js. Hyperflask, хоть и молодой проект, показывает важный шаг в этом направлении.

• Обсуждение в основном вращается вокруг сравнения Flask/HTMX-стека с альтернативами (FastAPI, Django, Litestar, FastHTML), где критика касается производительности, архитектуры и "state of the art" в 2025 году.
• Участники спорят о целесообразности смешивания шаблонов и логики в одном файле, о том, насколько это упрощает или усложняет разработку, и о том, как это сказывается на тестируемости и сопровождении кода.
• Ряд комментаторов поднимает вопрос о том, что выбор Flask в 2025 году может быть устарел, особенно если учесть отсутствие встроенной поддержки async/await, и сравнивает его с FastAPI или Litestar.
• Некоторые участники высказывают мнение, что вместо того, чтобы изобретать еще один каркас, было бы лучше взять существующий и внедрить в него улучшенную документацию, инструменты и лучшие практики.

HTML-тег <output> почти не используют, но он решает две задачи: делает результат вычислений доступным для скринридеров и избавляет от необходимости вручную подключать ARIA live-регионы. Пример: калькулятор, слайдеры, индикаторы сложности пароля. Тег работает без JavaScript и ARIA-атрибутов, поддерживается всеми браузерами и скринридерами.

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

Минимальный CSS для приятного сайта включает базовые стили, улучшающие типографику и читаемость. Начните с ограничения ширины медиа-контента: img, svg, video { max-width: 100%; display: block; } предотвращает переполнение. Для типографики используйте system-ui как безопасный шрифт, увеличьте размер до 1.25rem и установите line-height в 1.5 для лучшей читаемости.

Добавьте поддержку тёмной темы через html { color-scheme: light dark; }, но учтите, что пользователям может потребоваться ручное переключение. Ограничьте ширину основного контента с помощью main { max-width: min(70ch, 100% - 4rem); margin-inline: auto; } для оптимальной длины строки в 45–90 символов. Этот подход избегает избыточного кода и обеспечивает адаптивность.

• Обсуждаются минималистичные подходы к CSS, включая сброс стилей, базовые настройки для типографики и ограничения ширины контента для улучшения читаемости.
• Поднимается вопрос о реализации темной темы, важности ручного переключения пользователем и проблемах с "миганием" при загрузке.
• Критикуются стандартные системные шрифты и обсуждаются потенциальные проблемы с их отображением в разных ОС и локалях.
• Упоминаются различные инструменты и философии (например, SSG, Tailwind, Every-Layout) для создания простых и эффективных сайтов.
• Высказывается мнение, что пользователь должен иметь максимальный контроль над стилизацией контента, а не сайт.

Социальная сеть X требует включённого JavaScript для работы и отображает сообщение об ошибке, если он отключён в браузере. Пользователю предлагается активировать JavaScript или перейти на поддерживаемый браузер из списка в Центре помощи.

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

• Впечатляющий прогресс независимого проекта Ladybird, достигнутый за короткое время, приближает его к практической пригодности.
• Прохождение 90% тестов WPT — это произвольный, но требуемый Apple метрический порог для рассмотрения в качестве альтернативного движка в iOS; сама метрика считается несовершенной.
• Реальная сложность заключается в поддержании темпа развития и реализации постоянно растущего количества новых веб-API, а не только в прохождении текущих тестов.
• Вызывают вопросы безопасность и наличие песочниц в быстро разработанном движке, а также его текущая производительность при повседневном использовании.
• Проект рассматривается как важная альтернатива доминирующим движкам, но до полной конкурентоспособности еще несколько лет работы.

loadmo.re — это кураторская галерея мобильных сайтов, созданная для вдохновения дизайнеров, работающих с нетривиальным вебом. Платформа подчёркивает, что современный интернет всё больше смещается в сторону смартфонов, хотя дизайнеры по привычке ищут референсы на десктопах, упуская из виду потенциал мобильных интерфейсов.

В архиве представлено 362 сайта с фильтрацией по тегам — от 3D-анимации и типографики до звукового дизайна и глитчей. Примеры вроде rude-captcha.xyz или slingshot.trudy.computer демонстрируют, как можно творчески использовать возможности телефона. Цель проекта — стимулировать сообщество к обсуждению и эксперименту в mobile-first дизайне.

• Пользователи обсуждают нестандартный веб-дизайн представленных сайтов, отмечая как их креативность и ностальгическую ценность, так и проблемы с юзабилити и доступностью.
• Критике подвергаются отдельные элементы, такие как изменение поведения ссылок при наведении и невозможность добраться до нижней части страницы из-за бесконечной подгрузки контента.
• Участники делятся воспоминаниями о легендарных сайтах прошлого (Kaliber 10000) и обмениваются ссылками на аналогичные ресурсы и агрегаторы необычных сайтов.
• Высказываются опасения, что подобный дизайн часто непрактичен для представления реального контента и создания призывов к действию, а также создает барьеры для доступности.
• Часть сообщества ценит представленные работы за их художественную ценность и вдохновляющий потенциал, призывая не зацикливаться на мелких недостатках.

Ишкур создал исчерпывающий интерактивный гид по электронной музыке, ставший культовым ресурсом для меломанов и продюсеров. Гид визуализирует связи между жанрами через интерактивную карту, охватывая всё от раннего синт-попа и техно до дрим-попа и джангла. Каждый жанр сопровождается описанием, ключевыми треками и историческим контекстом, что делает его одновременно образовательным и развлекательным.

Проект выделяется саркастичным тоном и глубоким знанием темы, подчёркивая эволюцию звука и культурные влияния. Ишкур также поддерживает присутствие в соцсетях и на платформах вроде SoundCloud и Mixcloud, делясь миксами и обновлениями. Гид стал незаменимым инструментом для понимания сложной паутины электронной музыки, сочетая юмор с академической строгостью.

• Пользователи выражают благодарность и ностальгию по сайту Ishkur's Guide to Electronic Music, отмечая его как ценный артефакт «старого интернета» и влияние на формирование их музыкального вкуса.
• Обсуждается содержание сайта: подробная классификация электронных жанров и поджанров с образцами звучания, саркастическими комментариями автора, но отмечается отсутствие современных жанров.
• Пользователи делятся дополнительными ресурсами: миксами от Ishkur на Mixcloud, альтернативными способами навигации по сайту и другими платформами для поиска нишевой музыки (Bandcamp, Soulseek, private trackers).
• Высказываются критические замечания: устаревший интерфейс, субъективность и историческая ориентированность контента, технические проблемы с воспроизведением samples.
• Поднимаются дискуссии о происхождении жанров, влиянии конкретной аппаратуры на звучание и корректности представленной на сайте временной линии.

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

Возродить такой подход можно через блоги и RSS-ленты. Не нужны централизованные платформы — достаточно подписываться на обновления через читалки вроде Feeder.co или NetNewsWire. Автор запускает собственный блог с открытым списком подписок, предлагая другим делиться контентом напрямую, как в эпоху веб-рингов. Ключевая идея: автономия и выбор, как взаимодействовать в сети, без вовлечения в дофаминовую машину соцмедиа.

• Ностальгия по "старой вебу" связана с GeoCities, Angelfire, веб-рингами, персонализацией и отсутствием алгоритмов, но критики отмечают, что в ней была реклама и платформы исчезали.
• Возрождение "старой веба" требует самостоятельного хостинга, независимости от платформ и отказа от отслеживания (например, через Google Fonts), а не использования чужих сервисов.
• Современные попытки воссоздать "старую веб" часто сводятся к эстетике, но не решают проблем сообщества, монетизации и устойчивости, которые были и тогда.
• Ключевые ценности "старой веба" — это собственность данных, низкий порог входа, гиперссылки, RSS и личные сайты, но ностальгия не должна затмевать практические решения.
• Социальные аспекты и взаимодействие в "старой вебе" (форумы, IRC) часто противопоставляются блогам и RSS как более живым формам общения, чем пассивное потребление контента.

Нетехнический основатель перестроил сайт стартапа с помощью ИИ-агента Claude Code за недели вместо месяцев изучения кода. Использовал стек: VS Code, CLI Claude, GitHub CLI и сервер Figma MCP для точного переноса дизайна из Figma в код на Remix. Качество ответов Claude варьировалось — иногда он менял не те части кода, что отнимало часы.

Рабочий процесс включал локальную разработку, пуши в ветку и создание пул-реквестов через Claude. Ключевой трюк: просить Claude выступать в роли CTO для ревью PR, что помогало находить упущенные оптимизации. Это позволило избежать шаблонных решений no-code платформ и точно реализовать кастомный дизайн.

• Рекомендуется активно управлять контекстом при работе с ИИ-ассистентами, очищая его между задачами для повышения фокуса и снижения смещения.
• Использование ИИ для генерации кода требует осторожности и постоянного контроля человека из-за риска ошибок, изменения не тех файлов и создания запутанного кода.
• Эффективные стратегии работы включают поэтапное планирование задач, сохранение промежуточных результатов и использование нескольких инструментов (Claude Code, Cursor, Figma MCP).
• Мнения разделились: одни видят в ИИ значительный прирост продуктивности, другие считают его использование избыточным или ведущим к потере времени.
• Ключевые проблемы: сложность поддержки сгенерированного кода, нарушение принципов проектирования и необходимость чётких промптов для качественного результата.

Почему PostHog стал похож на ОС
Мы устали от типичных сайтов: бесконтентные скроллы, одинаковые вкладки, пустое пространство. Новый PostHog.com работает как ОС в браузере: окна «прилипают», есть горячие клавиши, закладки, можно читать новости, смотреть демо и играть одновременно.

Что внутри

• Проводник Windows для магазина мерча
• Продуктовые страницы в стиле PowerPoint
• Редактор документов с возможностью правки
• Форумы как Outlook Express
• Плеер QuickTime, таблицы вместо дизайна, скринсейвер и обои
• 50+ горячих клавиш

Техника
Контент отделён от визуального слоя: продукты описаны в JSON, темы и цветовые схемы настраиваются, клиентские цитаты и логотипы хранятся в одном месте и подтягиваются автоматически. Всё собрано в прод-ветке на Tailwind + TypeScript.

• Сайт PostHog выглядит как десктоп ОС в браузере: окна, таски, «окна в окнах».
• Кому-то нравится визуальный стиль и ностальгия по 90-м, но почти все жалуются на тормоза, жрущий CPU JS и поломанные привычные хоткеи/кнопки.
• Пользователи теряются: непонятно, где контент, как начать читать и что вообще продаёт компания.
• Критика сводится к «изобретаю заново мой менеджер окон», «ломает SEO и accessibility», «не работает Back, не скроллится, на мобиле ужасно».
• Некоторые считают это крутым маркетинг-ходом и «growth-hack», но сомневаются, что кто-то будет реально пользоваться.

• Реклама в интернете — зло: тратит время и уродует сайты.
• Поддержи автора напрямую: 1 $ приносит больше пользы, чем тысячи показов баннеров.
• На сайте выводится тонкое сообщение: «Adblock не обнаружен. Поставь uBlock Origin — сэкономишь трафик и нервы».
• Блок скрывается кнопкой «Закрыть» и больше не появляется (cookie notice-shown).
• Техника:
  – в HTML встроен <div> с «адоподобными» классами и скрипт nativeads.js;
  – если div вырезан или скрипт заблокирован, сообщение не видно;
  – стили показывают блок только при ≥75 em ширины и ≥30 em высоты;
  – без JS сообщение не вставляется, без CSS просто не стилизуется.
• DNS-блокировку не отследить, поэтому банер маленький и некликабелен вне основного контента.

• Без блокировщиков рекламы веб выглядит как «лабиринт трекеров и баннеров»: большинство пользователей живут в этом каждый день.
• uBlock Origin называют едва ли не «лучшим антивирусом»; ФБР и CERN рекомендуют блокировщики как защиту от скама и малвари.
• Даже с адблоком сайты всё чаще «раскрывают» посетителей через identity-graph (IP, хэши устройств) и потом спамят e-mail.
• Часть участников считает блокировку «паразитизмом»: контент бесплатен только потому, что кто-то смотрит рекламу.
• Другие возражают: договор «контент ↔ реклама» давно нарушен — автозвук, трекинг, монополии Google/Meta, потребление трафика и батареи.
• Альтернатива — платить авторам напрямую, но пожертвования от 0,01 % читателей не покрывают хостинг, уж не говоря о зарплате.

Анимации не всегда нужны

Хорошая анимация делает интерфейс предсказуемым и живым, плохая — раздражает и снижает доверие.
Перед добавлением спроси себя: зачем она нужна?

• Объясняет (как на linear.app/ai) — ок.
• Подтверждает действие (кнопка слегка уменьшается) — ок.
• Просто «красиво» — допустимо, если пользователь видит это редко.

Частота использования
Если элемент открывают сотни раз в день (Raycast, список команд), анимации быть не должно — они только тормозят.
Клавиатурные переходы никогда не анимируются.

Скорость
Всё, что дольше 300 мс, воспринимается как лаг.
Спиннеры быстрее = кажется, что грузит быстрее.
Тултипу нужна задержка при первом появлении, но при наведении на соседние — мгновенно и без анимации.

Итог
Добавляй анимацию, если она:

1. решает задачу,
2. видна редко,
3. длится < 300 мс.
   Иначе — не добавляй.

• Большинство участников сходятся: анимация должна быть почти невидимой (<150 мс) или вовсе отключаться, иначе она превращается в тормоз.
• Главный критерий целесообразности — объясняет ли анимация изменение состояния; если пользователь ждёт её окончания, чтобы продолжить, значит, она лишняя.
• «Делайт» и «восторг» нужны в основном самим дизайнерам; обычные пользователи после третьего раза хотят выключить всё, что мешает работать.
• Частые повторяющиеся действия (разблокировка, чекаут, корпоративные формы) требуют минимума анимации; для единичных экранов-онбордингов допустима более заметная, но быстрая подсказка.
• Практически каждый советует добавлять системную настройку «отключить анимацию» и уважать prefers-reduced-motion.

В JavaScript "🤦🏼‍♂️".length == 7 — не ошибка, а результат подсчёта UTF-16 кодовых единиц.
Эмодзи состоит из 5 скалярных значений Unicode, но в UTF-16 они занимают 7 code units:

• 🤦 U+1F926 → 2
• 🏼 U+1F3FC → 2
• ZWJ U+200D → 1
• ♂ U+2642 → 1
• VAR-16 U+FE0F → 1

Итого 7 — именно это и возвращает .length.

Другие языки считают по-своему:

• Python 3 → len("🤦🏼‍♂️") == 5 (кодовые точки, но допускает суррогаты).
• Rust → "🤦🏼‍♂️".len() == 17 (байты UTF-8).
• Swift → "🤦🏼‍♂️".count == 1 (расширенный графем-кластер).

Каждый подход отвечает на свой вопрос: «сколько code units / bytes / графем». Ни один не универсален; выбор зависит от задачи.

• Обсуждение вокруг статьи показало, что «длина строки» не имеет единого определения: бывают байты, UTF-16/UTF-32 код-юниты, скалярные значения Unicode и расширенные графем-кластеры.
• Пользователи жалуются, что разные языки и API возвращают разные числа для одного и того же эмодзи, что ломает UI-ограничения, индексы БД и обработку текста.
• Часть участников считает, что нужно явно различать «длину для хранения», «длину для отображения» и «длину для человека»; другие мечтают вернуться к чистому ASCII.
• Примеры кода на Java, Python, Raku и JS показывают, как получить каждый из вариантов длины, но подчеркивают отсутствие общего стандарта.
• Итог: «length» — слишком расплывчатое слово; без контекста использования любое его значение может оказаться не тем, что действительно нужно.

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

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

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

Историческое дерево технологий
Интерактивная визуализация технологической истории от 3 млн лет до наших дней. Проект Этьена Фортье-Дюбуа, пока содержит 0 технологий и 0 связей.

Каменное орудие
3300 тыс. до н. э. — первая технология производства.

• Пользователи отмечают слепые зоны: недооценены металлургия, точная механика и «базовая наука», из-за чего газовые турбины возникают «из ниоткуда».
• Найдены мелкие ошибки: дата «обуви» указывает на сандалии, а не самые ранние туфли 7000–8000 г. до н. э.; точность дат винторезных токарных станков спорна.
• UI-критика: слишком много пустого пространства, неудобно на мобильных, не хватает зума, тысячных разделителей и «привязки» к следующему узлу.
• Замечена западная и англоязычная предвзятость: китайское письмо показано как терминус, а не как корень множества ветвей.
• Предложения по улучшению: вертикальный мобильный вид, поиск «самых важных потомков» технологии, агент для автоматического обогащения графа.