Hacker News Digest

• Основная критика .NET MAUI для веба — отсутствие поддержки стандартных веб-функций (Ctrl+F, выделение текста, копирование ссылок), что делает его нечувствительным к привычным взаимодействиям.
• Выражается скепсис в отношении будущего MAUI из-за багов, слабой документации, отсутствия поддержки в продуктах Microsoft и исторической практики Microsoft не использовать свои же фреймворки.
• Для веб-приложений на .NET предлагается использовать Blazor, а для кроссплатформенных десктопных решений — альтернативы вроде Avalonia или Kotlin Compose Multiplatform.
• Указывается на производительность (долгая загрузка) и проблемы с доступностью (несовместимость с скринридерами) при использовании MAUI в веб-окружении.
• Обсуждается целесообразность .NET для веб-разработки: часть участников считает веб-технологии более подходящими, а часть видит потенциал в .NET при условии решения текущих ограничений.

Snapchat представил Valdi — кроссплатформенный UI-фреймворк, который обеспечивает нативную производительность без потери скорости разработки. Решение ориентировано на создание высокопроизводительных интерфейсов для мобильных и десктопных приложений, используя единый кодовый баз.

Ключевая особенность Valdi — способность достигать производительности, сопоставимой с нативными решениями, при этом сохраняя преимущества кроссплатформенности. Фреймворк призван решить проблему компромиссов между производительностью и эффективностью разработки, с которой сталкиваются команды при создании сложных UI. Snapchat позиционирует Valdi как инструмент для ускорения цикла разработки без ущерба для качества пользовательского опыта.

• Разочарование в существующих кроссплатформенных решениях (React Native, WebView) и надежды на Valdi как альтернативу с нативной производительностью.
• Критика Valdi: сложность, отсутствие поддержки Linux/Windows, сомнения в качестве кода Snapchat и его Android-приложения.
• Альтернативные подходы: нативная разработка, Kotlin Multiplatform, PWA, а также сомнения в необходимости кроссплатформенности при наличии AI.
• Технические вопросы: отсутствие поддержки Swift, сложность нативной интеграции, сравнение с другими фреймворками (Boden, Lynx.js).
• Философский спор: стоит ли жертвовать нативным UX ради кроссплатформенности или писать UI отдельно для каждой платформы.

Библиотека Rust GUI компонентов для создания кроссплатформенных десктопных приложений с использованием фреймворка GPUI. Проект предлагает готовые интерфейсные элементы, упрощающие разработку визуальных приложений на Rust. Компоненты обеспечивают единый пользовательский опыт на разных платформах, включая Windows, macOS и Linux.

Библиотека является частью экосистемы GPUI, который позиционируется как современный подход к созданию GUI на Rust с акцентом на производительность и гибкость. Разработчики могут использовать готовые компоненты или создавать собственные, наследуя базовые функциональности. Проект активно поддерживается сообществом и постоянно пополняется новыми элементами интерфейса.

• Сообщество обсуждает, что "native" может означать как отсутствие web-технологий, так и просто нативный виджет ввода текста, и это влияет на выбор инструментов.
• Участники отмечают, что многие open-source проекты спонсируются криптокомпаниями, что вызывает смешанные чувства, но при этом признаётся вклад этих компаний в OSS.
• Обсуждается нехватка готовых компонентов в экосистеме Rust, несмотря на обилие GUI-фреймворков, и сравнивается с другими языками, где такие коллекции есть.
• Поднимается вопрос о размере бинарника (около 10 МБ), который вызывает у людей вопросы о встроенных данных ICU и прочих ресурсах.
• Участники делятся мнением, что хотя фреймворки быстро развиваются, но они всё ещё не покрывают все потребности, и это тормозит более широкое принятие.

Swift.org анонсировали выпуск Swift SDK для Android, открывая новые возможности для кроссплатформенной разработки. Этот релиз стал результатом многолетних усилий сообщества и работы Android workgroup, которая расширяет возможности Swift за пределы традиционных платформ. SDK доступен в виде nightly preview релизов и может быть получен вместе с установщиком Windows или скачан отдельно для Linux и macOS.

Уже опубликовано руководство по началу работы и примеры приложений, демонстрирующие end-to-end рабочие процессы. Проект swift-java обеспечивает взаимодействие между Java и Swift, автоматически генерируя безопасные и производительные привязки. Интересно, что более 25% пакетов в Swift Package Index уже поддерживают Android, что упрощает перенос существующих проектов на новую платформу. Команда также работает над документом видения для будущих разработок Swift на Android и отслеживает прогресс через проект board.

• Обсуждение в основном вращается вокруг трёх тем: «кроссплатформенный» Swift теперь позволяет писать Android-приложения на Swift, но не решает проблему UI-фреймворков, а также не затрагивает вопросы лицензирования и тулинга.
• Участники обсуждения отмечают, что даже если Swift теперь работает на Android, это не делает его «флаттером» — он не предоставляет нативный UI, и разработчики всё ещё должны решать, как реализовать UI, что делает его менее привлекательным, чем Flutter или React Native.
• Некоторые участники высказывают мнение, что вместо того, чтобы пытаться сделать Swift кроссплатформенным, было бы лучше, если бы Apple открыла Xcode и позволила бы использовать его на других платформах.
• Обсуждение также затрагивает вопрос о том, что влияние на разработчиков окажет то, что Apple не предоставляет никаких инструментов для разработки под Android, в то время как Google предоставляет такие инструменты для iOS.
• Участники также обсуждают, что влияние на разработчиков окажет то, что Apple не предоставляет никаких инструментов для разработки под Android, в то время как Google предоставляет такие инструменты для iOS.

Google выпустила инструменты для синхронизации и потоковой передачи файлов между Windows и Linux. Основная цель — упростить работу разработчиков, которым нужно быстро и эффективно перемещать данные между этими операционными системами, особенно в гибридных средах. Решение оптимизировано для производительности и поддерживает как инкрементальные обновления, так и потоковую передачу в реальном времени.

Инструменты включают утилиты командной строки и API, что делает их гибкими для интеграции в автоматизированные процессы или скрипты. Это особенно полезно для DevOps-инженеров и системных администраторов, работающих с кросс-платформенными развертываниями. Проект открыт под лицензией Apache 2.0, что способствует его адаптации и улучшению сообществом.

• Обсуждение алгоритма CDC (Content Defined Chunking) и его преимуществ перед rsync, включая скорость до 30 раз выше и эффективную обработку вставок и удалений в файлах.
• Вопросы о совместимости и внедрении: поддержка только Windows-to-Linux, отсутствие Linux-to-Linux, сложности сборки с Bazel и предложения интегрировать улучшения в стандартный rsync.
• Сравнение с другими инструментами и технологиями: IBM Aspera, Steam, borg backup, git, а также упоминания о монодиальном хешировании и методе lookahead для улучшения FastCDC.
• Сожаления о закрытии Stadia и обсуждение невозможности её самохоста из-за DRM и кастомного железа, а также альтернатив для стриминга игр (Moonlight/Sunshine).
• Критика выбора названия "CDC" из-за его неоднозначности (путаница с USB CDC и Control Data Corporation).

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

Приложение полностью приватное — аудио не отправляется в облако, всё обрабатывается на устройстве. Handy позиционируется как доступный инструмент, свободный от подписок, с возможностью кастомизации и поддержкой сообщества через спонсоров like Wordcab и Epicenter. Проект приглашает к участию в разработке и финансировании.

• Пользователи обсуждают высокое потребление ресурсов современных десктопных приложений, приводя примеры, где даже простые действия занимают значительный объем памяти (~120MB).
• Представлены альтернативные и похожие инструменты для преобразования речи в текст (STT), такие как Whispy (Linux), hns (CLI), Gnome расширение и VoiceInk, с акцентом на локальность и минимализм.
• Обсуждаются технические детали проектов: использование моделей Whisper и Parakeet, поддержка GPU/CPU, кроссплатформенность, языки разработки (TypeScript, Rust, Go) и вопросы шумоподавления.
• Участники сравнивают качество и удобство локальных решений с облачными сервисами (например, Groq) и встроенными функциями ОС (macOS dictation, iPhone STT).
• Затрагиваются темы приватности, производительности на слабом железе, удобства использования для программирования и запросы на аналогичные инструменты для преобразования текста в речь (TTS).

Приложения на Electron вызывают серьёзные задержки в работе всей системы на macOS 26. Пользователи сообщают о замедлении интерфейса, лагах при вводе текста и проблемах с отзывчивостью даже при минимальной нагрузке. Это связано с тем, что фреймворк использует общие ресурсы системы неэффективно, особенно в многозадачных сценариях.

Проблема проявляется при одновременной работе нескольких Electron-приложений, таких как Slack, Discord или VS Code. Система начинает проседать по производительности, что негативно сказывается на пользовательском опыте. Разработчики Electron признают проблему и изучают её, но пока не предложили конкретного решения.

• Проблема с производительностью в macOS 26 вызвана использованием приложениями (включая Electron) приватных API Apple, что приводит к утечкам ресурсов и лагам.
• Некоторые пользователи не сталкиваются с проблемами, возможно, из-за высокой производительности железа (например, чипов M4), которое маскирует недочеты.
• Обсуждается, кто виноват: разработчики приложений за использование приватных методов или Apple за отсутствие регрессионного тестирования и обратной совместимости.
• Для части приложений (Chrome/Chromium) уже выпущен фикс, а также известны временные решения через терминал.
• Спектр мнений варьируется от критики Electron до защиты его как кросс-платформенного решения с хорошим DX.

• Пользователи жалуются на избыточность и ненужность новых эмодзи, особенно гендерных и расовых вариантов, считая их личным и неуместным в рабочей переписке.
• Некоторые предлагают отказаться от фиксированного списка эмодзи в пользу AI-генерации или полной кастомизации.
• Критикуется приоритет Unicode: вместо полезных символов (например, математических или исторических) добавляются «детские стикеры» и «мусор».
• Поднимаются проблемы отображения: разные платформы рисуют эмодзи по-разному, что искажает смысл.
• Есть ирония по поводу того, как технический стандарт превратился в поле культурных и поколенческих споров.

Red — язык нового поколения, вдохновлённый Rebol. Компилирует в нативный код, охватывает от системного программирования до высокоуровневых скриптов и кроссплатформенных GUI. Поддерживает современные примитивы параллелизма, не требует установки и настройки: всё умещается в один файл ≈ 1 МБ.

• Проект Red вызывает ностальгию, но разработка фактически стоит: 32-битные бинарники, проблемы на macOS, отсутствие 64-битной версии.
• Пользователи ищут «простой кроссплатформенный язык + GUI» и обсуждают альтернативы: LiveCode, Tcl/Tk, Dart/Flutter, Iced (Rust), Nushell.
• Сообщество жалуется на «срыв» после ухода в блокчейн/ICO и низкий bus-factor.
• Некоторые считают REBOL/Red «функционально-императивным» и homoiconic, но интерес к языку снизился из-за барьеров запуска.

lue — терминальный ридер ePub с TTS.

• Основное: читает ePub, воспроизводит речью, работает в консоли.
• Управление: клавиши Vim-стиля, навигация по главам, закладки.
• Настройка: темы, голоса, скорость, горячие клавиши.
• Установка: cargo install lue или brew install lue.
• Системы: Linux, macOS, Windows.
• Лицензия: MIT.

• Пользователи тестируют новый инструмент lue для чтения/озвучки epub в терминале: TTS-часть ценят за «просто закинул и слушай», но чтение в моноширинном шрифте вызывает сомнения.
• Основная боль — внешние зависимости (espeak, antiword) и требование Python ≥ 3.10; автор уже пообещал поднять минимальную версию.
• Прогресс и состояние озвучки сохраняются в системных логах; серверный запуск позволит синхронизировать закладки.
• Сноски, колонтитулы и служебные символы вырезаются, чтобы не мешать TTS; возможно появится опция оставлять их для обычного чтения.
• Автор собрал адаптеры для Kitten TTS, Gemini и др., но пока не опубликовал их, размышляя о выделении отдельного репозитория.
• Вопросы о запуске из Termux/Android и безопасности кода пока без ответа; автор приветствует аудит и обратную связь.