Hacker News Digest

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

Автор делится личным опытом, включая примеры из своей работы, такие как дизайн экрана статистики для игры YOYOZO и планирование интерфейса для утилиты sfxr. Он подчеркивает, что электронные таблицы позволяют быстро организовывать контент и планировать макеты с точностью до пикселя, что особенно полезно при работе с сетками.

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

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

• Обсуждение вращается вокруг того, что визуальные прототипы (Figma, Balsamiq и т.д.) могут отвлекать от функциональности, в то время как таблицы и презентации позволяют сосредоточиться на логике и структуре интерфейса.
• Участники делятся опытом использования различных инструментов для создания макетов: от Excel и Google Sheets до Excalidraw, Figma, Balsamiq и OmniGraffle.
• Некоторые подчеркивают, что высоко-фидельные мокапы могут вводить в заблуждение разработчиков и отвлекать их от создания MVP.
• Обсуждается, что такие инструменты как Figma и Balsamiq могут быть полезны для визуального прототипирования, но стоит помнить, что они не заменяют собой обсуждение и планирование функциональности.

Проект Shamelectron отслеживает проблемы с производительностью GPU в Electron-приложениях на macOS Tahoe. Основная проблема связана с ошибкой в macOS 26, которая вызывает значительное падение производительности графического процессора. Решение уже найдено — необходимо обновить Electron до версий v38.2.0, v37.6.0 или v36.9.2.

Из 21 отслеживаемого приложения только шесть исправлены, а 15 всё ещё имеют проблемы. Среди популярных приложений с неисправленными версиями — 1Password, Discord, Figma, Notion и Obsidian. Пользователям предлагается напомнить разработчикам через Twitter о необходимости обновления, чтобы решить проблему с производительностью.

• Electron использовал приватный API Apple для косметических улучшений окон, что привело к проблемам производительности в macOS Tahoe.
• Проблема затрагивает не только Electron-приложения (например, Zoom), но и вызывает системные сбои в различных приложениях и интерфейсах.
• Баг уже исправлен в последних версиях Electron, но многим приложениям требуется обновление для устранения проблемы.
• Пользователи критикуют переход некоторых приложений (например, 1Password) с нативных технологий на Electron, отмечая ухудшение качества и высокое потребление ресурсов.
• Обсуждаются альтернативы Electron (например, Tauri) и предлагаются способы выявления проблемных приложений.

Большинство пользователей применяют лишь около 20% функций приложения, но у каждого — свой уникальный набор. Например, один копирует таблицы из Excel в Word, другой строит сводные таблицы, а третий вообще использует его для учёта расходов. Когда софт обрастает новыми возможностями, они часто мешают тем, кому важна конкретная узкая функциональность, — это создаёт пространство для нишевых продуктов.

Такие сервисы, как Kagi или Figma, успешно занимают эти лакуны, фокусируясь на идеальном решении задач определённой аудитории вместо погони за универсальностью. Стратегия Win — не пытаться угодить всем, а позволить пользователям через расширения и кастомизацию самим формировать свой идеальный 20%, как это делают VS Code или Slack. Ключ в гибкости, а не в нагромождении функций.

• Пользователи обычно используют лишь небольшую часть функционала приложения (около 20%), но у разных пользователей это разные 20%, что требует поддержки всего функционала.
• В корпоративном сегменте отсутствие даже редко используемых, но критичных для конкретного клиента функций (гигиенических фич) может привести к срыву сделки.
• Сложность удаления неиспользуемых функций обусловлена тем, что каждая функция может быть критически важна для узкой группы пользователей, и их удаление приведет к потере этих пользователей.
• Для борьбы с раздуванием функционала предлагаются различные стратегии: фокусировка на конкретной аудитории, модульность, соблюдение философии Unix (один инструмент — одна задача), сбор метрик использования.
• Разработчикам сложно предсказать, как именно будет использоваться продукт, поэтому важно сохранять гибкость и возможность кастомизации, особенно для технически подкованных пользователей.

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

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

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

Reshaped стал полностью открытым

Пять лет назад я создал Reshaped — библиотеку компонентов для React и Figma, чтобы покрыть 80% типовых задач и оставить 20% на кастомизацию. Сделал её платной, чтобы углубленно поддерживать небольшое сообщество.

Два года назад React-пакет стал бесплатным. Сегодня открываю исходники всего:
React и Figma теперь в открытом доступе.

Что дальше:

• Базовая библиотека будет расти; лицензиаты продолжат получать обновления.
• Планирую премиум-компоненты сложной логики поверх ядра.

Прыжок в open-source после 5 лет закрытой разработки — пора отдать сообществу.

• Пользователи хвалят Reshaped за чистый код и бесплатную библиотеку, но жалуются на подвисание вкладок документации и задержки при навигации.
• Автор (blvdmitry) признал проблемы со скоростью сайта: сервер рендерит статику ~500 мс, обещает перевести документацию на статический экспорт.
• Некоторые просят улучшить микро-анимации и accessibility; автор собирает примеры и уже работает над новыми компонентами.
• Библиотека стала полностью бесплатной и open-source после 5 лет продаж; ядро React и Figma останутся бесплатными, премиум-компоненты возможны позже.
• Упоминаются мелкие баги: backspace в автокомплите, ссылка «Getting started» вела в changelog — уже пофикшено или в процессе.

Как работает технология «мультиплеера» в Figma

Основная идея
Figma позволяет десяткам дизайнеров одновременно работать над одним файлом без конфликтов. Это достигается за счёт оперативной синхронизации изменений и разрешения конфликтов на лету.

Архитектура

• WebSocket-соединение — каждый клиент держит постоянное соединение с сервером.
• Операционные преобразования (OT) — любое действие (перемещение слоя, изменение текста) описывается как операция. Сервер применяет её и рассылает всем клиентам.
• Дельты и патчи — вместо полной передачи файла отправляются только изменения, что экономит трафик и ускоряет работу.

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

Производительность

• Дерево объектов хранится в памяти браузера и обновляется по мере поступления операций.
• Сжатие и батчинг — несколько операций объединяются в один пакет, чтобы снизить нагрузку на сеть.
• Кеширование — сервер хранит последние состояния файлов, чтобы быстро «догнать» клиента, который только подключился.

Безопасность и надёжность

• Все операции логируются и могут быть отменены (undo/redo).
• Данные шифруются при передаче и хранятся в зашифрованном виде.
• Регулярные снепшоты защищают от потери данных при сбоях.

Итог
Технология «мультиплеера» превращает Figma в «Google Docs для дизайна», где коллаборация происходит без конфликтов и задержек.

• Участники делятся ссылками на материалы Linear, Automerge, Croquet и другие решения для реал-тайм синхронизации.
• Обсуждают, насколько сложной остаётся задача и какие новые инструменты (Liveblocks, Electric SQL, Rocicorp Zero) делают её доступнее.
• Спорят о терминологии «multiplayer» и о том, насколько часто пользователи действительно одновременно редактируют дизайн.
• Отмечают, что Figma пошла на радикальные меры: собственный WebGL-рендерер и протокол, отказавшись от готовых библиотек.
• Шутят о случайном переключении сайта из тёмной в светлую тему при прокрутке и о «figma balls».

Notion — это универсальный инструмент для заметок, задач, баз знаний и совместной работы. Объединяет блоки текста, таблицы, календари, доски Kanban, базы данных и встраиваемые медиа в единое пространство. Поддерживает шаблоны, автоматизацию, API и интеграции (Slack, GitHub, Figma и др.). Работает в браузере, на macOS, Windows, iOS и Android. Бесплатный план для личного использования; платные тарифы для команд и расширенных функций.

• Участники спорят, почему диффузионные модели проигрывают авторегрессии: BarakWidawsky связывает это с меньшей способностью к запоминанию, а ckjellqv — с невозможностью KV-кеширования.
• Woadwarrior01 удивлён росту FLOPs при генерации длинных последовательностей (×16–4700) и отмечает нелинейную зависимость.
• Godelski критикует неясность терминов «in/out-of-distribution» без описания обучающих данных.
• Bicsi предлагает «закрыть» диффузионные модели, считая цепочку мыслей (CoT) быстрым и мощным заменителем; против выступают fancyfredbot и SalmoShalazar, призывая не отвергать подход преждевременно.

I think the Figma IPO proves Khan was right. $60B market cap today vs the $20B Adobe offered in 2023. There was some criticism about regulatory overreach when the deal got blocked. Now Figma employees are rich, the design tools market stays competitive, and we have another major