Я по горло сыт стандартно выглядящими приложениями. Сегодня все десктопные приложения Windows выглядят одинаково, да и внутри устроены одинаково: их создают на основе дурацких браузерных обёрток React, Electron, electronbun и Tauri, имитирующих реальные десктопные приложения. Они медленно работают и занимают кучу памяти — по сути, это bloatware. Блокнот — это, блин, приложение для простых ЗАМЕТОК, а не замена Word, калькулятор — это калькулятор, а не планировщик лунной миссии НАСА. На каком-то этапе Microsoft сбилась с курса, как будто сдалась и передала бразды правления куче веб-разработчиков, незнакомых с концепцией оптимизации.
Чёртов Блокнот занимает в памяти почти 50 МБ, хотя эквивалентное приложение, написанное на чистом Win32 C, занимает 1,8 МБ. Вроде бы, по современным меркам 50 МБ — это не так много, но в том-то и смысл: эти мегабайты постепенно накапливаются. Недавно я купил новый Intel Ultra 9 285 с 32 ГБ ОЗУ, но при запуске Windows 11 память уже была заполнена на 77%.
Программирование на Win32 API — утерянное ныне искусство; я с ностальгией вспоминаю, как когда-то программировали приложения для Windows. Процесс был запутанным, но обеспечивал полный контроль.
Программирование современных UI чаще всего пытается спрятать от нас операционную систему. Мы привязаны к прямоугольной коробке, хотя в эпоху Windows XP был период, когда крутыми считались нестандартные окна приложений, такое было даже у Windows Media Player.
Не все окна обязаны быть скучными скруглёнными прямоугольниками с боковой панелью, шестерёнкой настроек и спрятанным под ними веб-стеком. Когда-то приложениям Windows дозволялось быть странными. Проигрыватели мультимедиа выглядели как приборы. По рабочему столу гуляли животные. Вспомогательные панели походили на пульты управления, игрушки, радиоприёмники или маленькие инопланетные интерфейсы. Окно не должно было обязательно иметь прямоугольную форму только потому, что таким было окно операционной системы.
Обычно смысл этого заключался не в удобстве пользования, а в индивидуальности.
В современных десктопных UI её практически не осталось. Не потому, что в Windows она больше невозможна, а потому, что большинство разработчиков теперь не программирует на том уровне, где они могут управлять самим окном.
Репозиторий GitHub к этому посту — небольшое напоминание о том, что Win32 по-прежнему позволяет нам это делать. Один пример из него делает окно овальным. Другой создаёт окно по форме растрового изображения, Третий превращает окно в анимированное животное, живущее на рабочем столе. Ни для одного из них не требуется огромный фреймворк, они просто работают с Windows напрямую.
Первое, что сбивает с толку людей, имеющих опыт в играх, браузерных приложениях и современных фреймворках UI — это то, что в центре внимания Win32 не находится цикл обновления, которым управляет разработчик. В нём всё зависит от сообщений. Приложение работает, а Windows постоянно обрабатывает его события:
while (GetMessage(&msg, NULL, 0, 0) > 0) { TranslateMessage(&msg); DispatchMessage(&msg); }
Этот цикл становится контрактом. Windows сообщает, что произошло какое-то событие, а процедура окна решает, что оно значит. «WM_CREATE» означает, что создаётся окно. «WM_PAINT» означает, что его нужно перерисовать. «WM_SIZE» означает, что изменилась клиентская область. «WM_DESTROY» означает, что работа завершена. Вот так по-настоящему выглядит программирование Win32: разработчик строит поведение из отдельных сообщений.
И как только понимаешь это, окна странной формы перестают быть загадкой.
Обычное окно верхнего уровня имеет прямоугольную форму, но у Windows также есть понятие объекта области (HRGN). Если при помощи SetWindowRgn присвоить окну область, то окном будет считаться только эта часть. Всё остальное исчезает: и визуально, и с точки зрения интерактивности. В этом и заключается хитрость.
Простейшая версия подобного находится в basic/main.c. Этот код создаёт окно без границ, а затем выполняет следующее:
region = CreateEllipticRgn(0, 0, rc.right, rc.bottom); SetWindowRgn(hwnd, region, TRUE);
Этого достаточно, чтобы превратить окно в овал. Не в поддельный овал, нарисованный внутри прямоугольной рамки, а в настоящий овальный HWND. В примере также обрабатывается одна практическая мелочь, о которой часто забывают: после удаления панели заголовка система больше не будет перетаскивать окно за нас. Поэтому при «WM_LBUTTONDOWN» код имитирует перетаскивание панели заголовка, передавая «WM_NCLBUTTONDOWN» с «HTCAPTION».
Эта маленькая деталь — миниатюрная версия всей истории с произвольными окнами. Создать форму просто. Настоящая работа заключается в том, чтобы заменить всё то, что обычное окно делало автоматически.
В следующем примере всё становится интереснее. drivenbyimage/main.c определяет форму не математически, а получает её из данных растрового изображения. Программа загружает shape.bmp, считывает пиксели при помощи GetDIBits, а затем построчно сканирует изображение. Каждый горизонтальный интервал непрозрачных пикселей становится небольшой прямоугольной областью, и эти интервалы объединяются в одну область окна.
#define TRANSPARENT_COLOR RGB(255, 0, 255)
Маджента обозначает пустое пространство, всё остальное становится частью окна.
Это значит, что растровое изображение одновременно выполняет две задачи. Во-первых, это то, что мы отрисовываем в «WM_PAINT». Во-вторых, это форма самого окна. Именно так работали старые приложения с возможностью смены скинов. Разработчики не были ограничены кругами, скруглёнными углами и красивой векторной геометрией. Окно могло принять форму изображения, на котором нарисована собака, космический корабль, магнитофон или мультяшное лицо.
Отчасти благодаря этому старое десктопное ПО было таким интересным. Прямоугольник окна переставал быть законом природы и становился лишь одним из вариантов.
Однако области, создаваемые на основе растровых изображений, всё равно имели резкую границу. Пиксель или был, или его не было. Это отлично подходит для силуэтов или вырезанных UI, но если вам нужны плавные границы, просвечивающие пиксели или анимация, то приходилось переходить к многослойным окнам.
Именно эту задачу решает пример Animated/. Я нашёл на itch.io красивый лист спрайтов с анимированной 8-битной собакой авторства художника inmenus, который передал свою работу в Creative Commons. Спасибо ему за это.
Вместо того, чтобы вырезать окно из области, пример создаёт всплывающее окно «WS_EX_LAYERED» и при помощи UpdateLayeredWindow загружает в него 32-битное изображение с альфа-каналом. В примере используется лист спрайтов, кадры которого меняются по таймеру, выполняется отрисовка в битовую карту памяти при помощи GDI+, а затем результат передаётся на рабочий стол. Мы уже не говорим «окно будет эллипсом» или «окно соответствует этой маске», а сообщаем «окно будет тем, что представляют из себя эти пиксели».
Для анимации больше подходит многослойное окно (layered window), потому что благодаря нему мы получаем попиксельный альфа-канал, более плавные края, настоящую полупрозрачность и возможность менять видимую фигуру в каждом кадре.
Однако есть одна проблема с программированием Win32 API: при работе с произвольными окнами нужно всё делать самостоятельно, контролируя каждое сообщение Windows, а такая система ненадёжна.
Неприятности начинаются, когда мы решаем отказаться от обычного окна. Нам придётся реализовывать собственное перетаскивание, изменение размеров, поведение при закрытии, проверку нажатий мыши, обработку ввода с клавиатуры, правильность перерисовки, обработку DPI и все раздражающие маленькие пограничные случаи, которые для стандартного окна были решены десятки лет назад. Именно поэтому окна странной формы легко прототипировать и сложно доводить до ума.
Если в результате не получается что-то поистине выдающееся, пользователи обычно не ценят усилий.
Культура десктопного UI перестала считать крутыми безумные скины, она хочет, чтобы окна надёжно работали и не мешали процессу. Странные окна стали ассоциироваться с уловками, рекламным ПО, панелями инструментов и раздутыми утилитами, нежели с серьёзным ПО. И это печально.
Но мне всё равно нравится, что они существуют. Это напоминает мне о том, что когда-то Windows была платформой, на которой ПО могло иметь физическую идентичность, а не просто структуру страницы внутри замаскированной под приложение вкладки браузера. Чаще всего правильным выбором будет обычное прямоугольное окно, но полезно помнить, что это лишь один из вариантов, а не непреложный закон.
В Win32 здорово то, что он не пытается отговорить нас от этого. Он просто даёт нам сообщения, дескрипторы, API отрисовки и достаточно возможностей для создания чего-нибудь интересного.
Код к посту можно найти в репозитории GitHub.
Комментарии (286)
Pascal1990
20.04.2026 05:20Программирование на Win32 API — утерянное ныне искусство
Ну лично мне такое искусство нафиг не нужно. Пишу на javafx кроссплатформенно под винду, мак и линукс и живу хорошо. Памяти много не ест. Единственный минус - приходится тащить с собой jvm полностью, но 40 мегабайт в нынешнее время это уже приемлемо. Столько весит обычное мобильное приложение.
Хотя вцелом согласен, что electron и прочие web-gui это зло.
На win32 api сейчас писать не вариант просто потому что одну и ту-же программу в нынешнее время приходится выпускать сразу для целой кучи платформ: винда, мак, линукс, андройд, айфон.
Goron_Dekar
20.04.2026 05:20На win32 api сейчас писать не вариант просто потому что одну и ту-же программу в нынешнее время приходится выпускать сразу для целой кучи платформ: винда, мак, линукс, андройд, айфон.
Уже давно нет. Если вам надо пускать одну и ту же программу на разных платформах - вы делаете сайт. А сейчас на разных платформах запускаются разные программы, реализующие функционал одной платформы. Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами. Вы разделяете UX - что-то ваши пользователи получают в телефон, а что-то - на ПК.
13werwolf13
20.04.2026 05:20Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами
kirigami хочет с вами поспорить, к сожалению фреймворку безгодунеделя от роду, и примеров софта мало, я знаю пожалуй только neochat и tokodon, и они прекрастны в своей универсальности, и на android и на десктопе использую, удобный ui для обоих вариантов
d3d14
20.04.2026 05:20Два чая этому господину.
Как уже задолбали эти велосипеды с браузером внутри EXE. Некоторые еще создают кучу дочерних процессов. Эти дочерние процессы были придуманы в браузерных движках, их смысл - при открытии вкладки не тратить время на создание процесса для нее, а передавать ее в заранее созданный и ожидающий процесс. Но криворукие лентяи перенося браузерный движок в EXE приложение, не удосужились оключить многопроцессность. И в итоге, приложение, в котором нет никаких вкладок, единственная "вкладка" - его корявый интерфейс - зато имеет несколько висящих без надобности дочерних процессов. Нуачо, железо же позволяет....
MonkAlex
20.04.2026 05:20Дочерние процессы то вам чем не угодили?
Не знаю конкретно про электрон, но посмотрел на запущенные программы на моем пк. Thunderbird - два подпроцесса, с разными целями. Стим - пяток подпроцессов, из которых только парочка с типом renderer (что можно наверно привязать к "вкладкам"), дискорд - пяток подпроцессов, каждый для своих целей и не создаются новые на "вкладки".
И даже firefox, который действительно создает много подпроцессов не создает их для каждой вкладки, что легко проверяется - можно закрывать в диспетчере случайный подпроцесс и смотреть что отваливается\перезапускается в этом случае. Некоторые подпроцессы критичны и ломают всё целиком, а некоторые просто потребуют перезагрузить вкладку.
d3d14
20.04.2026 05:20Их внедрение даже в браузерных движках было спорным решением, а уж в standalone приложениях, они подавно не нужны.
некоторые просто потребуют перезагрузить вкладку.
Это и есть процессы для вкладок.
MonkAlex
20.04.2026 05:20Проблема то в чём? В памяти? Так память жрать они все жрут, вне зависимости от количества процессов. Процессы, отмечу, для разных целей, т.е. общего кода там скорее всего не то чтобы много.
В стиме можно уронить интерфейс и подпроцессы его перезапустят. Это удобно с пользовательской точки зрения.
Мне тоже неприятно видеть большое количество процессов, но это чисто вкусовщина в моём случае, т.к. пока оно работает стабильно и не жрёт лишней памяти - проблем я не вижу. Да, это всё потребляет уже не 512мб оперативы как когда-то на винХР, но и цены давно другие, софта разного и с разными функциями стало больше. Всё ещё можно пользоваться софтом с ВинХР, если сильно важна память и много-процессность.
ПС: прекрасно помню времена, когда зависание какой-нибудь вкладки в лисе завешивало весь браузер. Спорное решение исправило эту проблему by design, что на мой взгляд прекрасно. Напомню, что в те времена даже код аддонов выполнялся в едином процессе, что делало всё очень грустно и сложно для пользователей.
HemulGM
20.04.2026 05:20Каждый процесс внутри поднимает отдельный рантайм, который нужен для его работы. Который и так поднят в хостовом процессе.
Без множества процессов создаваемых браузером, вообще и нет понятия "упал UI".
MonkAlex
20.04.2026 05:20В стиме эти цифры на уровне пары мегабайт. Т.е. на ~6 процессов это порядка целых 12мб! Вот это накладные так накладные, как они смеют.
В дискорде 5-10мб минимальное потребление процессов, т.е. на 5 процессов - до 50мб. Это та самая программа, которая не стесняется съедать пару гигабайт на кеши всяких фоточек и прочего, т.е. опять накладные смешные в общем объеме.
У лисы не знаю сколько. Даже если 10мб (грубо и по верхней границе), то на 6-12 процессов выйдет 120мб. Лиса у меня сейчас основной инструмент, в котором открыто по 30-50 вкладок, общее потребление может улетать за 4-6гб. Т.е. накладные конкретно на процессы - не то чтобы заметны.
Да, я понимаю, что это накладные. Но у процессов есть и плюсы, которые почему то игнорируются.
HemulGM
20.04.2026 05:20Нет там никаких плюсов, кроме изоляции. Не должно быть нормальным явлением падение рендер-процесса, чтобы записать как преимущество то, что он перезапустится просто.
MonkAlex
20.04.2026 05:20Сайты нынче очень тяжелые. И когда листаешь бесконечную ленту, внезапно выясняется, что тормозит только конкретный пул вкладок, а остальные себя хорошо чувствуют. Приятно! Раньше если утек какой то сайт, перезапускать приходилось весь браузер (или надеяться что переоткрытие вкладки поможет).
Когда какой-нибудь плагин\сайт роняют вкладку, теперь они делают это локально, не роняя всю лису. Раньше лиса чаще падала. Я понимаю, что можно сказать "говнокодеры, пишите код хорошо и не нужно будет выделять процессы под костыли", но я лично не умею писать программы таких масштабов, как лиса, поэтому я считаю что решение рабочее, а уже потому лучше чем без него.
boulder
20.04.2026 05:20Не соглашусь, что 12Mb — это мало. Это много. Тем более, 50.
MonkAlex
20.04.2026 05:20Контекст важен. Если 12мб памяти много, то стим пора закрывать, он в фоне висящий потребляет почти 1гб памяти. Если 50мб много, то дискорд в сумме потребляющий 1гб это совсем плохо.
И вот я сижу, памяти у меня теперь аж 2гб дополнительных, только программы почему то нужные закрыты. Что мне с памятью делать то? Не стесняется никто сейчас кушать память, даже телеграм в фоне 500мб съел и ему хорошо, а это пример программы с хорошей оптимизацией.
MonkAlex
20.04.2026 05:20Отдельно отмечу, что это примерно та же история, что монолит vs микросервисы. У обоих есть свои плюсы, золотую середину каждый ищет для себя сам.
qvvah
20.04.2026 05:20Спорным решением? Емнип, это было сделано для безопасности и изоляции, чтобы одна вкладка, в случае успешного использования уязвимостей, не получила доступ к содержимому всех остальных вкладок и к основному движку браузера (ФС, сеть, куки, пароли). Хотя может быть вы правы и нужно изобретать какую-то новую схему разграничения памяти, чтобы не плодить кучу процессов - что-то вроде подпроцессов, изолированных друг от друга и от процесса-родителя, но при этом разделяющих часть ресурсов.
d3d14
20.04.2026 05:20Вообще, в случае использования RCE уязвимости как бы не важно, в какой она вкладке сработала - доступ к выполнению кода получен.
Так что это велосипед (некоторые это называют компромиссом) - при нормальной разработке никакие вкладки падать не должны.
Persik1
20.04.2026 05:20Люди часто путают причину и следствие. Chromium порождает процессы не потому, что ему не жалко памяти, а чтобы изолировать GPU-рендеринг, сетевой стек и плагины. Да, в standalone-приложении это выглядит избыточно, но такова цена переиспользования браузерного ядра
vShadow
20.04.2026 05:20зато имеет несколько висящих без надобности дочерних процессов
Так и Win API не гарантирует и не обязывает “запихивать” всю логику в один процесс/поток. Более того, на примере того же Блокнота, идеальным решением будут вообще три потока:
Отвечает за GUI
Отвечает за работу с I/O (условно - работа с файловой системой)
Отвечает за логику самого приложения (управляет всеми потоками, проверяет данные и пр.)
В таком исполнении Блокнот не будет “виснуть” на время файловых операций, а также позволит, например, прерывать операцию открытия больших файлов “на пол пути” и добавить поддержку медленных источников данных (тот же FTP).d3d14
20.04.2026 05:20на примере того же Блокнота, идеальным решением будут вообще три потока:
Конечно, нет ))
Виснет при работе с большими файлами потому что использует контрол EDIT, предназначенный для маленьких обьемов - такая специализация у блокнота. Для больших обьемов есть контрол RichEdit. Плюс, для больших файлов, желательна другая логика работы - открытие файла в режиме маппинга и перемещение маппингового "окна" по контенту. Такими вещами занимаются специализированные редакторы (EmEditor, Notepad++).
FoxWMulder
20.04.2026 05:20++ попытка использовать один и тот же UI на разных платформах провальна изначальна. т.е. не то чтобы она провальна, но это компромисы между универсальностью и удобством. например иногда забывают что телефон и ПК это два устройства с разными физическими параметрами экрана, с разными перефирийными устройствами и с сильно разными сценариями использования.
HemulGM
20.04.2026 05:20Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами
Можете
Один и тот же проект с одним и тем же UI
Win11 
Android/iOS 
nerudo
20.04.2026 05:20Сверху мы видим огромный экран, не эффективно занятый разреженным текстом. Снизу мы видим узенький экранчик, в который код никак не вмещается. Не взирая на это, окно с кодом все равно сделано не во всю ширину, а занято серым фоном. Ну да, и правда подходы весьма совпадающие. Просто плохие.
HemulGM
20.04.2026 05:20Это проблема дизайна, а не общего UI между десктопом и мобильной платформой. Я делал в точности так, как это показывалось на сайте OpenAI на десктопе и на мобилке (в году, когда только появился ChatGPT)
Если вы видите проблему, то её корни растут именно из Веба.
zapimir
20.04.2026 05:20Это ещё что, меня "впечатлил" дизайн Pomerium. Постоянно возникало желание масштаб меньше сделать :)
При вроде не большом количестве полей, они не влезают на экран
Goron_Dekar
20.04.2026 05:20Нет, не надо так делать. Никогда.
И вот почему. HemulGM
20.04.2026 05:20Эм, что? Здесь код специально без авто переноса. Он прокручивается. Не нравится - изменить это можно одной галочкой. Это не проблема общего UI
Goron_Dekar
20.04.2026 05:20Ты просто не можешь показывать код на экране мобильного телефона. Вообще. С переносами, или без переносов - это нечитаемо.
vvzvlad
20.04.2026 05:20Мне не надо его читать. Мне надо посмотреть на него в плане то/не то и скопировать.
Goron_Dekar
20.04.2026 05:20Вы как на код посмотреть собираетесь, не читая? Вот это я понимаю - волшебство!
vvzvlad
20.04.2026 05:20Ага, значит как говорить про то что код не помещается — так вы нормально используете слово "нечитаемо" в смысле "очень неудобно читать". А как мне возразить, так сразу оказалось что на код посмотреть уже нельзя не читая его.
HemulGM
20.04.2026 05:20Ну так а при чем тут проблема общего интерфейса?
Goron_Dekar
20.04.2026 05:20Да не при чём. Общий интерфейс невозможен, вот и проблем нет.
artptr86
20.04.2026 05:20Но в примере же интерфейс адаптируется под разные экраны. Если бы мобильное приложение было написано отдельно, оно могло выглядеть в целом похоже.
Goron_Dekar
20.04.2026 05:20В принципе - не адаптируется. Некоторые, очень редкие, интерфейсы можно натянуть, но даже они или очень плохо работают на большом экране, или очень плохо на маленьком.
RulenBagdasis
20.04.2026 05:20Сверху огромные пустые пространства, снизу ничего не влезло. Отличный пример, плохо получилось везде.
HemulGM
20.04.2026 05:20Это пример сделанный по аналогии, как это сделано было на сайте OpenAI. Всё отступы и поведение.
Эти отступы и поведение в целом сделать можно как угодно.
Вы это не в состоянии понять? Или вы думаете, что я не могу убрать отступы? Я не понимаю эту глупую претензию.
RulenBagdasis
20.04.2026 05:20Вы процитировали вот это утверждение:
Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами
И в качестве контраргумента привели пример. Плохой пример. Чем подтвердили то, что процитировали. Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами, потому что подучится какаха как у вас на скринах. И на сайте такая же какаха, мотому что там тоже пытаются сделать один интенфейс для нескольких разных устройств. Я не понимаю эту глупую претензию. С чем вы спорите?
Эти отступы и поведение в целом сделать можно как угодно.
Ага, тогда получится использование разных UI для разных устройств.
HemulGM
20.04.2026 05:20И зачем тут разное UI? Один и тот же тут UI, который адаптируется под размер окна, в том числе и на десктопе. Ровно так же, как и на мобильных экранах. Главное, думать об этом заранее. Да, достаточно уменьшить отступы относительно размера окна. И это будет одинаково работать и на десктопе и на мобильных экранах. Это не будет мешать использованию на десктопе, потому что маленький размер окна на десктопе тоже важен.
Никто в здравом уме, никогда не будет писать софт под десктоп, считая, что его программа всегда будет развернута на весь экран. Так почему же я не должен адаптировать UI, под минимальное окно на десктопе, ровно так же, как и для использования оного на мобильных экранах?
RulenBagdasis
20.04.2026 05:20И зачем тут разное UI?
Затем, что одинаковый неудобен.
И это будет одинаково работать и на десктопе и на мобильных экранах.
Не будет. Потому что на десктопе используется нормальная клавиатура, например. ChatGPT (и не только он) имеет просто отвратительный UI/UX для использования с десктопа. Entrer отправляет сообщение вместо переноса строки и раньше, по крайней мере, это поведение поменять нельзя было. Вобюще, вводить многострочный промпт это боль. Хоткеев тоже нет. А на мобильнике это не надо, в большинстве случаев, там вообще голосовой ввод предпочтительнее.
Но ваш пример как раз показывает, что всем настолько наплевать на пользователя, что даже на отступы забивают.
HemulGM
20.04.2026 05:20Вы точно софт разрабатывали? То, о чем вы пишите - проблемы веба, а не адаптивного UI.
RulenBagdasis
20.04.2026 05:20Ааа, я понял, это ваша нетленка, поэтому критика воспринимается так негативно, с агрессией в ответ. Надо было сразу в профиль зайти. Вы точно прочитали и поняли то, что я вам написал?
Т.е. это вы тот самый погроммист, который понаделал неудобных интерфейсов. Смешно.
RulenBagdasis
20.04.2026 05:20Самое смешное, что фразой “UI взят с веба” вы пытаетесь оправдаться и оспорить утверждение, что нельзя про взять и бездумно вкорячить один и тот же UI на разные устройства. Не надо было повторять, надо было сделать нормально, о том и речь, если повторять, будет какаха, что вы с блеском продемонстрировали.
Спасибо за дискуссию, прикопаю ссылку на тред, буду давать её когда нужно будет показать, как делать не надо. Всего хорошего ))
HemulGM
20.04.2026 05:20Подумайте ещё раз. Вы критикуете скрины за отступы, которые являются именно дизайном (взятым из конкретного источника). Они не являются необходимостью, уступками или проблемой. В другом дизайне не будет отступов, и всё "проблема" уйдет или что? Нет не уйдет, потому что этой проблемы вообще не существует. Приложение имеет такой вид, потому что я специально создавал точь в точь вид.
Я не буду с вами спорить, что конкретно этот дизайн не удобный, только это никак не говорит о том, что нельзя создавать общий UI под десктоп и мобильные экраны.Вы это в состоянии понять?
unreal_undead2
20.04.2026 05:20Никто в здравом уме, никогда не будет писать софт под десктоп, считая, что его программа всегда будет развернута на весь экран.
Это почему? Для каких нибудь CADов, видеоредакторов и прочего профессионального софта место на экране лишним не будет.
HemulGM
20.04.2026 05:20Исключения есть всегда
unreal_undead2
20.04.2026 05:20Исключение - это скорее калькуляторы, мессенджеры и прочая мелочь. Главное - тот софт, за которым весь день сидишь на работе.
И, кстати, те же видеоредакторы есть и для телефонов, и для профессиональных студий - но интерфейс несколько отличается.
HemulGM
20.04.2026 05:20Такой софт никогда не делают для мобильных телефонов.
Само-собой речь именно о таком софте, который должен быть и на десктопе и на мобильных телефонах.
unreal_undead2
20.04.2026 05:20Я уже дал пример - редактор видео.
Да можно и банальный почтовый клиент взять - десктопный Outlook, особенно со сложными кастомными вьюшками, часто удобно открыть на весь большой монитор. В телефонных клиентах другой интерфейс с другим функционалом.
Nikita22007
20.04.2026 05:20Если я напишу
if (width < 500) then renderSlim() else renderFat(), будет ли это считаться одним UI, или это будут 2 UI, из которых динамически происходит выбор? Лично я склоняюсь ко второму варианту.HemulGM
20.04.2026 05:20Так ведь это будет работать и с обычным окном на винде и с окном на мобилке. Почему вдруг это должно считаться двумя UI?
Но, если у вас renderSlim полностью иначе рисует всё, и приходится отдельно оба метода переписывать при внесении изменений, то да, это два UI. Но у меня такого нет. Если и есть такие условия, то они меняют состояние, а не способ отрисовки.
artptr86
20.04.2026 05:20Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами. Вы разделяете UX - что-то ваши пользователи получают в телефон, а что-то - на ПК.
Тем не менее, сейчас есть 3 десктопных платформы и 2 мобильных. В любом ли случае нужно 5 приложений? И если да, то на чём тогда писать GUI под линукс?
Goron_Dekar
20.04.2026 05:20Нужно 5 приложений. 5. Совершенно. Разных. Приложений.
artptr86
20.04.2026 05:20Так а под Linux на чём его писать? На Qt?
Goron_Dekar
20.04.2026 05:20Как удобнее. Я предпочитаю Qt, мне нравятся плюсы. Но биндинги в питон там глюкавые.
artptr86
20.04.2026 05:20Но тогда бизнес скажет: у нас уже есть приложение на Qt, которое можно собрать под Windows и Mac. Зачем нам тратить лишние деньги и время на разработку нативных приложений?
Wesha
20.04.2026 05:20Зачем нам тратить лишние деньги и время на разработку нативных приложений?
Ну, например, чтобы не выглядеть криворукими дебилами?
artptr86
20.04.2026 05:20А бизнесу не всё ли равно, если 0,01% аудитории их таковыми посчитает?
Goron_Dekar
20.04.2026 05:20А вот эти цифры, про 0.01%, они откуда, если не секрет? Я бы сказал, что к чужеродному интерфейсу в системе чувствительны минимум процентов 40. А первый взгляд на проект - это важный элемент продаж, раз люди тратятся на дизайн. Так что нет, не всё равно.
ts347
20.04.2026 05:20Чужеродный же не обязательно плохой. У Google Chrome не было заголовка окна — всем понравилось. Стало стандартом.
Windows Modern UI вообще полностью чужероден классическому интерфейсу Windows. По сути, в Windows начиная с 8 версии половина системы чужеродна другой половине. Ничего, пользуемся.
Goron_Dekar
20.04.2026 05:20Ну не только чтобы не выглядить.
Я знаю несколько отличных приложенек для винды на кутях. Другое дело, что это приложеньки для винды, а не пересобранные линуховые.
Такое, чтобы прямо вот пересобраноое и нормально работает знаю только одно - QtCreator :) Ну настолько, наскольно оно вообще нормальное.
SpiderEkb
20.04.2026 05:20или на gtk.
Некоторые даже на wxWidgets пишут...
pvvv
20.04.2026 05:20только FLTK, только хардкор!
unreal_undead2
20.04.2026 05:20Хардкор - это работа с X11 через сокеты.
pvvv
20.04.2026 05:20, под Windows.
unreal_undead2
20.04.2026 05:20Когда то пользовался cygwin'овским X сервером, чтобы ходить на удалённые линуксовые машинки с графикой, можно и для локальных приложений приспособить.
RigelGL
20.04.2026 05:20На Java fx / Java swing, заработает и под линуксом, и под виндой, и под маком. В свинге на выбор либо java стиль, либо системный. Если очень нужно нативности, решается через JNI / JNA.
13werwolf13
20.04.2026 05:20На win32 api сейчас писать не вариант просто потому что одну и ту-же программу в нынешнее время приходится выпускать сразу для целой кучи платформ: винда, мак, линукс, андройд, айфон.
qt насколько я знаю вполне себе позволяет писать софт под все платформы и при этом не тащить за собой тяжеленный рантайм как java
Nagdiel
20.04.2026 05:20Qt тоже не бесплатен по размеру, т.к. требует библиотек, которые должны быть на целевой платформе или распостраняться вместе с приложением. Другое дело, что можно линковать только те библиотеки, которые реально нужны для работы приложения. Но все равно это могут быть десятки или сотни мегабайт зависимостей.
13werwolf13
20.04.2026 05:20Другое дело, что можно линковать только те библиотеки, которые реально нужны для работы приложения. Но все равно это могут быть десятки или сотни мегабайт зависимостей.
Ну я в общем-то это и имел ввиду. На десктопе половина либ и так будут стоять в системе, их тащить с сабой не прийдётся. А на мобильной платформе взять только необходимые, ещё и пожать/порезать))
unreal_undead2
20.04.2026 05:20И откуда на обычном десктопе с виндой библиотеки Qt (да ещё и той версии, которая нужна приложению)? Да и под линуксом (если распространяется единый бинарный пакет, который должен бегать на разных дистрибутивах) расчитывать на бинарную совместимость с установленными в системе библиотеками может быть оптимистично. По опыту даже libstdc++ лучше таскать с собой.
13werwolf13
20.04.2026 05:20Делать единый пакет под разные дистрибутивы уже само по себе ошибка, а вы придумываете проблему там где её нет.
unreal_undead2
20.04.2026 05:20Задача вполне решаемая - скажем, интеловские тулы (компилятор, vtune и т.д.) можно скачать в виде self-extracting архива общего для разных систем. Сборка разных пакетов для зоопарка разных систем требует отдельных ресурсов.
13werwolf13
20.04.2026 05:20задача решаемая кто бы спорил, но это всё равно будет неправильным подходом, фу таким быть..
сборка под десяток дистрибутивов родного для них пакета с родными для них зависимостями это задача решаемая за несколько минут под кофе с сигареткой, и работать это будет годами без серьёзных изменений.
а если ваш софт достаточно хорош (под этим в том числе подразумевается и открытая лицензия) и станет популярным то эту задачу за вас решат мейнтейнеры дистрибутива сами (хотя никто не запрещает им в этом помочь).unreal_undead2
20.04.2026 05:20сборка под десяток дистрибутивов родного для них пакета с родными для них зависимостями это задача решаемая за несколько минут под кофе с сигареткой, и работать это будет годами без серьёзных изменений.
Вопрос ещё в разных версиях - скажем, нужно поддерживать разные версии Redhat за последние лет десять. И какого то нужного функционала в версиях библиотек на старых системах может не быть.
под этим в том числе подразумевается и открытая лицензия
Я скорее проприетарщину с грузом легаси имел в виду.
13werwolf13
20.04.2026 05:20Вопрос ещё в разных версиях - скажем, нужно поддерживать разные версии Redhat за последние лет десять. И какого то нужного функционала в версиях библиотек на старых системах может не быть.
снова несуществующая проблема, умные дяди уже давно всё порешали и на этот счёт в гайдлайнах есть ответ что делать
Я скорее проприетарщину с грузом легаси имел в виду.
мазохизм - дело добровольное, если кому-то больше нравится самому заниматься дистрибьюцией это их выбор, но это не отменяет всего вышесказанного
JerryI
20.04.2026 05:20electron не зло, если знать, как его готовить. Просто большинство не знает и пихает туда свой веб сайт
прим. Fusion360, VSCode (до появления Copilot)
13werwolf13
20.04.2026 05:20прим. Fusion360, VSCode
плохие примеры, если пользователь готов мириться с рядом недостатков ради некого кол-ва преимуществ это нисколько не отменяет наличия недостатков.
ris58h
20.04.2026 05:20Так расскажите про эти недостатки. Не держите в себе.
Goron_Dekar
20.04.2026 05:20больше 20мс реакция на события. Особенно - меню. Меню vsCode - худшее, что я кога-либо видел на десктопе.
Фузией не пользовался, ничего не скажу.
JerryI
20.04.2026 05:20Не знаю почему, но MS игнорирует апи к нативному меню.
Хотя раньше было лучше.Это камень в огород, тык они эмулируют его списками с hover аттрибутом, который всегда имеет задержку
Фузи это Autocad, тяжеленный комплекс, но работает шустро. Все расчеты вынесены на модули Си, а электрон там только для UI и 3D рендера
RulenBagdasis
20.04.2026 05:20больше 20мс реакция на события. Особенно - меню. Меню vsCode - худшее, что я кога-либо видел на десктопе.
Я вообще меню крайне редко пользуюсь, но сейчас пошёл потыкал. Субъективно, меню открывается мгновенно, вашей проблемы я не понимаю.
RulenBagdasis
20.04.2026 05:20С чем не согласны минусующие? Вам не нравится, что я использую хоткеи вместо меню или что у меня меню субъективно не тормозит? Расскажите, как вы замеряли эти миллисекунды, я у себя померяю.
Spiritschaser
20.04.2026 05:20VSCode странное поделие. Реально в нём какое-то удобство только в расширениях Microsoft.
JerryI
20.04.2026 05:20Расширения и есть наверное главная фича. Это по сути песочница, если делать что то подобное на qt, то примерно электрон и получится.
Другой хороший пример когда люди «правильно» используют электрон - это Obsidian
Spiritschaser
20.04.2026 05:20Так я о том, что все расширения не от MS, какие-то убогие и легче не использовать VSCode. Я использую для блокнотов Jupyther и разработке под PostgreSQL - оба от MS. Ну ещё агента ГигаЧата.
Для разработки под Flutter мне проще оказалось поставить и настроить Android Studio, для разработки на python/sql - Eclipse. Возможно, сам погружусь в разработку расширений Eclipse...
Вохможно, в итоге приду к emacs, но IMHO концептуально он сильно отстал.unreal_undead2
20.04.2026 05:20Вохможно, в итоге приду к emacs
Можете ещё на acme посмотреть для просветления (тут пример использования).
JerryI
20.04.2026 05:20В целом, зачем винить технологию, если используют ее криворукие и жадные.
Опять переносят ответственность с бизнеса на библиотеку. Надо кидаться палками в ms, meta и др
alliumnsk
20.04.2026 05:20Это же так, что JVM какое-то фиксированное количество памяти съела и всё, сама программа будет больше потреблять раза в три из-за использования сборщика мусора плюс ещё то, что JVM затрудняет написание программ, эффективно использующих память
JerryI
20.04.2026 05:20Так можно всегда вынести критические куски в модули на Си, разве нет?
alliumnsk
20.04.2026 05:20Про JNA наполовину шутят, что он такой неудобный, чтобы доступ к Си не использовали вовсе. В c# это как-то удобнее сделано. Ну и не всегда получается выделить у приложения более жрущую память часть.
Ilirium
20.04.2026 05:20На самом деле Win32 API приложения благодаря Wine вполне себе работают и на других платформах. Даже где-то был полушуточный пост, что вот дескать Win32 API это единственный стабильный GUI API для Linux :)
Вот на телефонах и планшетах да, я так понимаю Wine не будет работать. Либо, если мы даже и запустим, то пользоваться на сенсорных экранах таким приложением будет неудобно.unreal_undead2
20.04.2026 05:20Даже где-то был полушуточный пост, что вот дескать Win32 API это единственный стабильный GUI API для Linux :)
При этом и линуксовые сисколлы для каких то специфических задач никто не мешает использовать.
А когда то и конопочные телефоны с Win32 были - понятно, что раскладку контролов по экрану надо было подгонять под размеры, но API был практически тот же.
LAutour
20.04.2026 05:20На самом деле Win32 API приложения благодаря Wine вполне себе работают и на других платформах.
Большинству разработчиков (на ПК) в отличие от требования доустановки фреймворков ставить wine "религия не позволяет"
SergeiPod
20.04.2026 05:20Я несколько лет назад сформулировал мысль, что Win32-приложение, скомпилированное под Windows XP - самый кроссплатформенный вариант. Даже более кроссплатформенный, чем т.н. web-приложение. По крайней мере, такое приложение не требует определённого браузера определённой версии :-)
randomsimplenumber
20.04.2026 05:20Окон (обьектов которые обрабатываят сообщения) в одной небольшой программе легко может набраться больше 100. Удачи рулить ими через winapi.
unreal_undead2
20.04.2026 05:20Контролы обычно завёрнуты в свои API и руками их сообщения обрабатывать не надо.
По теме статьи - по мне так проблема скорее в обратном, большая часть приложений использовала стандартные контролы, внешний вид которых можно было настроить под себя в одном месте (стандартная настройка свойств экрана), да и в целом всё выглядело строго и единообразно. Сейчас даже заголовок активного/неактивного окна расцвечивается у всех по своему.
ts347
20.04.2026 05:20Если вообще расцвечивается. В том же VS Code это разница между «серое на сером» и «серое на сером но чуть почетче». А, например, в программах от компании Яндекс разницы между активным и неактивным окном нет вообще, совсем, никакой.
unreal_undead2
20.04.2026 05:20Во и я к тому - что как раз таки сейчас единообразия нет. Раньше программы типа Winamp были исключением - практически весь софт использовал в элементах управления одни и те же размеры/цвета/шрифты, настроенные в стандартном системном диалоге.
d3d14
20.04.2026 05:20Окна стандартных контролов сами обрабатывают свои сообщения.
Krey
20.04.2026 05:20В юникс концепция "все есть файл. В winapi “все есть окно”. Даже то что по смыслу к графике не имеет никакого отношения, тем не менее ей является
HemulGM
20.04.2026 05:20То что к графике не имеет отношения - это просто хендл. Окно - тогда окно, когда ты его создашь через CreateWindow.
Krey
20.04.2026 05:20Ага. Обработчик системных событий это про окно. Вот и создавали кучу невидимый окон, даже когда они не нужны были. При этом их можно было отобразить и увидеть этот позор на десктопе, иногда даже с интересными данными. Я делал такую утилиту для прикола.
Arhammon
20.04.2026 05:209 285 с 32 ГБ ОЗУ, но при запуске Windows 11 память уже была заполнена на 77%.
Вроде как радоваться надо что память на которую немало потрачено занимается чем-то полезным, а не простаивает. Помниться во времена Висты/7ки, Виста с жестким и большим объемом памяти была отзывчивее 7ки - просто за счет агрессивного префетча использовавшего все 8гб, в то время как 7ка помня провал ноутбуков 256Мб+Виста, отдавала на пред загрузку всего пару гигабайт.
ArtFrost
20.04.2026 05:20А если бы память заполнялась на 100% то уровень радости вырастал бы на дополнительные 23% что вся память используется ?)
clicky
20.04.2026 05:20А зачем кривляться если вам человек верно сказал что "заполненная" память это на самом деле кеш и суперфетч и это сделано нарочно? Чистится при востребованности другим приложением она моментально, но чаще предзагруженные данные как раз понадобятся и будут использованы, что делает видимую отзывчивость системы в разы выше.
mayorovp
20.04.2026 05:20Если бы этот кеш и правда чистился моментально, так ведь нет - мой домашний компьютер долгое время готов был в своп скидывать страницы данных лишь бы файловый кеш в памяти удержать. Приходилось держать rammap -et на горячей клавише. Потом я догадался выключить этот superfetch нафиг, и проблема ушла.
ArtFrost
20.04.2026 05:20Кривляться ? Отнюдь. Если голая система при загрузке жрет 77% от 32 ГБ тут не радоваться, а плакать надо. Это чего же надо было так с годами наоптимизировать чтобы одна только система столько сжирала. Я не думаю что со времен XP/7/10 винды было добавлено так много революционного кода улучшающего производительность. Сразу в памяти всплывают статьи на habr когда "оптимизированное" меню пуск жрало сотни мегабайт потому что его переписали на электрон или что-то подобное. Сегодня просто запущенный калькулятор и просто открытый 20КБ JPG файл жрут столько сколько хватало всей операционной системе в начале нулевых, хотя в математике за это время ничего не изменилось, да и формат JPG с 1992 года особо не трогали.
P.S. Total Commander вон и сегодня жрет в простое и переходам по папкам в пределах 8 мегабайт. Не знают ребята как кешировать надо.
HemulGM
20.04.2026 05:20Система не сжирает целиком всю эту память, а резервирует для пользовательских приложений.
И статья про Пуск тоже мало что имела общего с реальностью. Пуск не был написан на Электрон (а в статье вообще написано про Реакт), Пуск внутри себя имеет WebView окно для показа результатов поиска и всего. Сам Пуск написан на WinUI.
MonkAlex
20.04.2026 05:20Вот бы скриншот загрузки по процессам, чтобы прикинуть что это могло быть.
Потому что моя вин11 не перезапускаемая месяцами потребляет 10гб (из 32) с учётом запущенных браузера и десятка программ. Да, на систему спокойно может выйти порядка 4-6гб (что по меркам винХР очень много), но эта память доступна и мне не мешает. В случае запуска игр, потребляющих оперативку, система обычно ужимается в расходах и проблем тоже не испытывал.
clicky
20.04.2026 05:20Так вы продолжаете отвечать не читая на что отвечаете. Зачем?
Думаете, 5 раз повторенная ложь про "система жрёт" сработает лучше чем 1 раз? Система не жрёт, а резервирует. И linux-based системы делают то же самое под данные, об этом знает любой кто как минимум видел htop.
ArtFrost
20.04.2026 05:20Думаете, 5 раз повторенная ложь про "система жрёт" сработает лучше чем 1 раз? Система не жрёт, а резервирует.
Да можете называть это как угодно, пусть будет резервирует, это ничего не меняет потому что эти 73% остаются недоступны пользователю пока система их не освободит. Их менеджер памяти банально не отдаст другому ПО пока система эту память не освободит.
P.S. Да да, чистится и переадресовывается она моментально, но 20+ гигов в оперативе которые "скорее всего" понадобятся для ОС это такое себе.
DarthVictor
20.04.2026 05:20Да можете называть это как угодно, пусть будет резервирует, это ничего не меняет потому что эти 73% остаются недоступны пользователю пока система их не освободит. Их менеджер памяти банально не отдаст другому ПО пока система эту память не освободит.
С чего вы взяли, что свободные 27% система отдаст сильно быстрее?
MountainGoat
20.04.2026 05:20когда "оптимизированное" меню пуск жрало сотни мегабайт
И панель задач сотню мегабайт. И курсор мыши. И часы в трее.
Но есть один нюанс - речь про одну и ту же сотню мегабайт.
dky
20.04.2026 05:20Все 77% от 32гб на чистой винде и новом пк это кеш? И почему кеш помечается как занятая память, это нововведение w11? У меня на w10 из 64гб в данный момент занято 24гб, при этом размер кеша 34гб, очевидно что занятая память не включает в себя кеш. И вообще в заметке же речь шла о программах, которые распухают как на дрожжах, а не про кеш.
Krey
20.04.2026 05:20Откройте для себя монитор ресурсов системы или как он там сейчас называется. Окажется что у различных выделений памяти есть назначение и все это можно графически в разных цветах узреть, а не рассказывать тут мифы и выдумки А ещё в диспетчере задач можно столбцы добавлять
dky
20.04.2026 05:20В диспетчере задач на вкладке Performance есть конкретные цифры "In use" и "Cached". В чем заключаются мифы и выдумки?
hw_store
20.04.2026 05:20Это же старая как мир парадигма Wintel: софт требователен к железу -> создаёт рынок для нового железа -> делаем софт ещё более ресурсоёмким -> делаем более лучшее железо -> загружаем его ещё более ресурсоёмким софтом...бесконечный цикл. Не удивлюсь, если когда-нибудь выяснится, что MS, AMD и Intel управляются с одной и той же Нибиру
Astroscope
20.04.2026 05:20Не удивлюсь, если когда-нибудь выяснится, что MS, AMD и Intel управляются с одной и той же Нибиру
Это уже сейчас известно, что именно так и есть. /s
Persik1
20.04.2026 05:20Это называется "сговор Уинтел" (Wintel)
Никакой конспирологии, просто выгодный симбиоз: майки делают софт тяжелее, чтобы стимулировать продажи железа интел, а интел спонсирует оптимизации под свои новые инструкции в виндовс
alliumnsk
20.04.2026 05:20Пользователь может память купил, для того, чтобы запускать опредленные тяжелые приложения, а не для того, чтобы просто ее занять.
Nikita22007
20.04.2026 05:20Память, содержащая кешированные данные и код, не используемые в данные момент, называется "Зарезервированная", является отдельной метрикой и не учитывается в процентном показателе занятой памяти. В процентном показателе занятой памяти используется только показатель "Используется (Сжатая)".
Скриншот
nidalee
20.04.2026 05:20Да, но не совсем. "Используемая" Windows память тоже по большей части кеши разной степени необходимости - это я узнал, когда месяцами гонял тесты памяти на рабочей системе. Можете попробовать запустить какой-нибудь karhu или аналог с крутилкой ГБ и начать там накручивать выделенную ему память, начните с X - 4ГБ и ужимайте дальше, винда продолжит работать (с адскими лагами) и уступать память примерно по последнего гигабайта-двух.
Nikita22007
20.04.2026 05:20Вы уверены, что это именно кеш, а не нужные системе данные, которые ей пришлось отправить в своп (файл подкачки)? Был ли включен файл подкачки во время тестов?
nidalee
20.04.2026 05:20Вы уверены, что это именно кеш, а не нужные системе данные, которые ей пришлось отправить в своп
Смотрите, раз работает без них в оперативке - значит не такие уж и нужные. Значит уступают место реально нужным пользователю.
Был ли включен файл подкачки во время тестов?
Был, отключать файл подкачки всегда плохая идея, на любой системе и конфигурации железа.
MountainGoat
20.04.2026 05:20Я на веб-технологиях могу написать блокнот, который будет весить 2 мегабайта. Может, всё таки, рукожопы? Да не, АПИ плохой...
d3d14
20.04.2026 05:20Кстати, вот есть класс браузера, встроенный в ОС (IWebBrowser). ЕХЕ, использующее его, имеющее интерфейс на HTML/CSS/JS и проброс HTML/JS-обработчиков в нативный код весит ~100kB (вместе с HTML/CSS). Но все равно тащат этот мерзкий электрон с хромиумом.
zapimir
20.04.2026 05:20Да проблема не в рукожопах, а в том что за оптимизацию по сути не платят. Нужно сделать быстро и получать деньги. Сам конечно офигеваю, с теми же ИИ-шками. Пишу нужна таблица для админки, где будет 1 максимум 3 юзера - ИИ-шки: Мы тебя поняли, без BIGINT для id юзера не обойтись. А ведь так почти все пишут, зачем думать просто берём самый большой тип. А как CSS используют вообще мрак, когда видишь элемент и в нём пара десятков классов прописано. И так практически у каждого элемента, какая там каскадность CSS.
tenzink
20.04.2026 05:20В случае с id пользователя ИИ всё правильно делает. В случае 3х пользователей вы, вероятно, не сможете измерить разницу в потрблении ресурсов.
zapimir
20.04.2026 05:20Ну, да использовать в 8 раз больше памяти, чем нужно, это правильно. А потом такие упс, а чего это страничка WP генерируется 2 секунды на пустом сайте, а страничка в браузере занимает несколько сотен мегабайт. Да если бы эти 8 байт были только в одной маленькой таблице куда не шло, но есть куча других таблиц, где этот userid используется и там уже далеко не 3 записи, плюс по ним строятся индексы, а иногда и составные индексы. Так и набегает...
mayorovp
20.04.2026 05:20У BIGINT та же самая разрядность, что и у самого обычного указателя на современной платформе. И эти 64 разряда в указателе точно так же избыточны, но указатели используются намного чаще, чем ваш идентификатор пользователя, в том числе и в браузерах. Заботиться о длине идентификатора пользователя, но игнорировать указатели довольно странно, не находите ли?
Кстати, тот же Javascript имеет вообще ровно 1 числовой тип данных (под капотом иногда используется два разных), а потому размер страницы в браузере вообще никак не зависит от разрядности идентификатора пользователя.
zapimir
20.04.2026 05:20Причём тут указатели, если речь шла о базе данных? Да и указатель может указывать на структуру данных, а не на одну переменную.
В том же JS свои приколы, например, я делал свой data grid. ИИ-шки поголовно пытаются для каждой ячейки ставить кучу классов, на каждую ячейку вешать обработчики событий (а не использовать один общий). Начинают для каждой ячейки добавлять свой ID, не пытаются переиспользовать DOM при обновлении и т.п.. Да если их тыкать везде носом, то сделают.MountainGoat
20.04.2026 05:20Речь шла о том, что вы экономите ровно 3 байта памяти, рискуя ради этого реальными багами на конвертации типов и ещё такой же крошечной, но потерей производительности. При этом в этом же коде компилятор впустую потратит миллион этих байт.
zapimir
20.04.2026 05:20Ещё раз, вы что всерьез думаете, что кому-то нужна БД в которой просто одна табличка в которой 3 юзера? Про то что могут быть другие таблицы в которых есть столбец с userid, в которых могут быть сотни тысяч или миллионы записей, мы как то упускаем?
Это если не углубляться в детали, и то что есть ещё куча преобразований этих цифр. Они в одном виде хранятся, в другом передаются, в третьем преобразовываются в драйвере БД, в четвертом используются. Для того же JS если он работает с полем BigInt нужно дополнительно следить не выходит ли значение за пределы MAX_SAFE_INTEGER. Зачем думать - бесплатно же.
Для примера, делал логгер на Bun, который в несколько раз быстрее pino. Так там просто замена Math.floor(us) на us | 0 в горячем пути, дала общую прибавку к скорости записи логов на 15%.
randomsimplenumber
20.04.2026 05:20Про то что могут быть другие таблицы в которых есть столбец с userid, в которых могут быть сотни тысяч или миллионы записей, мы как то упускаем?
Таблица рано или поздно загрузится в память, и там окажется что невыровненные данные все равно нужно выравнивать.
playermet
20.04.2026 05:20а чего это страничка WP генерируется 2 секунды на пустом сайте, а страничка в браузере занимает несколько сотен мегабайт
Совсем не потому, что в таблице с тремя записями используется BIGINT для id. Это экономия на длине древка спички в рамках единственного требуемого коробка.
zapimir
20.04.2026 05:20Ну да я связанные таблицы в которых сотни тысяч записей, и в которых есть столбец userid и по нему есть индекс такой: ну да, ну да, пошел я...
Я не говорю что WP тормозит исключительно из-за BIGINT для userid. Это просто пример проектирования, когда в месте, где тебе точно известны ограничения используется оверсайз. Проблема только в том, что такой оверсайз не ограничивается userid. Потом мы имеет сайты у которых грузится мегабайт CSS, пару мегабайт JS, из которых 99,8% кода не используется.Wesha
20.04.2026 05:20есть столбец userid и по нему есть индекс такой: ну да, ну да, пошел я...
Индекс, у которого Cardinality 3?.. Мдя...
tenzink
20.04.2026 05:20Не набегает. Набегает за счёт использования неоптимальной архитектуры, неправильных алгоритмов и неудачного выбора структур данных. У решения с BIGINT по-умолчанию есть много достоинств:
у него нулевая когнитивная нагрузка на команду, поддерживающую код
оно не требует решения "проблемы 2000-го года" при неожиданном росте данных
оно почти всегда "бесплатно"
НО, если у сценарий, что использования BIGINT может оказать заметное влияние на производительность, то, уверен, вы это сами знаете, и являетесь достаточно квалифицированным специалистом (иначе вас просто не допустили бы делать такой выбор), чтобы это осознавать и добавить в prompt "используй для хранения user_id INT или что-там-ещё . Я знаю, что делаю"
А потом такие упс, а чего это страничка WP генерируется 2 секунды на пустом сайте, а страничка в браузере занимает несколько сотен мегабайт
Не нужно натягивать сову на глобус. Замена BIGINT на INT никак не уменьшит размер страницы в браузере и никак не повлияет на эти 2 секунды
zapimir
20.04.2026 05:20Замена BIGINT на INT никак не уменьшит размер страницы в браузере и никак не повлияет на эти 2 секунды
Причём тут размер страницы в браузере, если речь шла о БД? Каким боком генерация страницы WP к тому что происходит в браузере? Вы читаете на что отвечаете
оно почти всегда "бесплатно"
Так же говорят те кто делают приложения на Electron с кучей фреймворков. Ну подумаешь, простое приложение занимает 500+ МБ, зато быстро и на любой системе запускается. Ну подумаешь приложение занимает 1 ГБ памяти, это ж почти бесплатно (до подорожания памяти).
tenzink
20.04.2026 05:20Так я же ваш комментарий цитирую в контексте обсуждения BIGINT для user_id: https://habr.com/ru/articles/1025204/comments/#comment_29854816
Ну, да использовать в 8 раз больше памяти, чем нужно, это правильно. А потом такие упс, а чего это страничка WP генерируется 2 секунды на пустом сайте, а страничка в браузере занимает несколько сотен мегабайт
cpud47
20.04.2026 05:20Ну, да использовать в 8 раз больше памяти, чем нужно, это правильно
Ну и в целом, оптимизация выглядит не так. Умозрительная оптимизация хоть и весьма проста, однако часто не имеет существенного эффекта (а в ряде случаев имеет и вовсе отрицательный эффект).
Чтобы говорить о нормальной оптимизации нужно подтверждать подобные численные эффекты оптимизации. Иначе это просто усложнение на пустом месте.
k4ir05
20.04.2026 05:20В случае с id пользователя ИИ всё правильно делает. В случае 3х пользователей вы, вероятно, не сможете измерить разницу в потрблении ресурсов.
Смотря сколько будет внешних ключей на эту таблицу.
pvvv
20.04.2026 05:20речь объём используемой памяти.
то что на веб технологиях можно сделать блоктнот весом 2МБ с функциональностью вот этого дата uri аж на 40 байт, это здорово конечно.
data:text/html, <html contenteditable>на винапи можно в несколько кБ .exe упихать, и он при исполнении загрузит в память лишь user32.dll размером те самые 1.8МБ, а браузер(электрон), с единственной такой вкладкой сожрёт пару сотен МБ, не говоря про то сколько сам весит.
aitras
И хорошо, что теперь не так, ИМХО.
Goron_Dekar
Как раз очень плохо, что всё ещё так. Не хватает унификации в вебе. Все эти тошнотные плоские кнопки, менню-неменю и прочий треш, потихоньку лезущий через electron в обычные приложения, угнетает мой больной ум.
achekalin
Это обычно подается как "минималистический интерфейс", на деле же переводится как "разработчик не умеет в UI-удобство".
И это даже нормально - не все умеют.
Tippy-Tip
Это становится ненормальным, когда фирма, имеющая многомиллионные (многомиллиардные) обороты, скупится на наем тех, кто все же "умеет в UI-удобство".
BSOZ
Иногда это необходимость: взять тот же стандартный select: с одной стороны его вид слабо влияет на возможность выбора элементов из списка пользователем. Однако и тут приходится городить огород, чтобы поддержка имела представление о том, как этот список выглядит на пользовательском устройстве (т.е. должно быть не более 2-3 видов этого самого списка), т.е. уже не штатный системный. А что вызовет сложности у пользователей? Обязательно найдётся смартфон, на котором какая-нибудь кастомизированная производителем версия Android, на котором какие-нибудь пункты уедут куда-нибудь за границы ViewPort из-за выбора размера системного “шрифта” нестандартного размера (и нигде в другом месте это не проявит себя никак т.к. практически никто не использует штатный функционал). Или не будет способа закрыть этот список без выбора. Если бы он не был настолько часто глючным, то без проблем можно было бы его и использовать. Притом внутри он будет, но костыльно скрытым, чисто для скринридеров и “доступности”. Плюс: каждый раз, когда что-то начинает казаться более-менее завершённым и логичным, найдётся какой-нибудь Apple, который решит просто переосмыслить единицу измерения px т.к. она не учитывает плотность пикселей и понеслось. Вместо того, чтобы просто предложить перейти на em / rem и не трогать px, который в современное время вообще использовать не стоит из-за них. И обилие таких костылей становится нормой в вебе. К тому же, вроде бы, избавились от IE наконец-то уже окончательно, но теперь Edge изрядно досаждает, который теоретически не должен вообще никак отличаться от Chrome. А он отличается местами. И со временем будет огромная избыточность от всяких легаси примочек: скоро снова расчехлим полифилы.
SystemOutPrintln
Ага, стало ещё хуже. Тонны визуальных красивостей, которые отжирают кучу ресурсов и которые порой хрен отключишь.
Отчаянное стремление каждого разработчика сделать UX "лишь бы не так, как у всех".
"У ребят в мессенджере N просмотр реакций делается по ПКМ по сообщению? А мы сделаем так, что надо на сами реакции тыкать, пусть юзер помучается, гадая, как это сделать!"
А ещё моднявый повсеместный плоский интерфейс с кислотными, не сочетающимися друг с другом цветами — как будто нынешние UI/UX-дизайнеры даже не слышали о теории цвета и прочих темах. Так ещё и в этом плоском интерфейсе порой хрен отличишь, где декоративный элемент, а где контрол.
Во времена Windows XP и популярной классической темы (серенькой) я думал, что вот, наконец-то все поняли, что приглушённые нейтральные цвета интерфейса — это то, что лучше всего подходит для UI. Потому что такие цвета не раздражают глаз и не отвлекают от контента. Но нет же, потом снова появились эти кислотные плоские темы, ставшие почти повсеместными, что для меня выглядит не иначе, как некий откат в развитии.
BSOZ
Windows 2000 по интерфейсу была в целом более однородной и уж точно менее пёстрой. В XP Pro SP3 сразу после установки могу 3 места показать, где ввод числового значения выглядит по-разному при одинаковой сути.
hqqddy
Ну ка
SergeiPod
Хуже нестандартных окон только дурацкие нестандартные контролы, имитирующие органы управления физических устройств со всеми их ограничениями и недостатками.
А самый дурацкий контрол - это замена галки стилизацией тумблера, который при переключении не перекидывает клюв, а едва заметно меняет цвет. То есть уже даже не просто имитация, а имитация имитации. Которая не даёт пользователю ничего, кроме неудобства.