Comments 261
Оптимизация — это далеко не всегда оптимизация по быстродействию. То, что у нас будет универсальный ui под всё — это хорошо и правильно. Тут радоваться надо, а не расстраиваться. Конечно, скорость важна и над эти надо работать, но, будем честны, быстродействие — далеко не самое важное в ui софте.
Это хорошая история. Очень хорошая. Но не стоит путать тяжёлое с мягким. Не потому ли друг Джон допустил ошибку, что пытался написать оптимальный по быстродействию код вместо того, чтобы следовать чуть менее быстрым, но безопасным схемам? Инженерное искусство не сводится к единому параметру. Машина не должна быть быстрой. Она должна ездить и вести себя предсказуемо
Это просто, чтобы вспомнить классику. И таки нет, не так много софта пишут безопасный и медленный код по той простой причине что того кода обычно заметно больше, что прямо пропорционально количеству ошибок и потенциальных уязвимостей. Естественно контекст тоже имеет значение. Болид формулы 1 таки должен быть быстрым.
Болид тоже должен быть управляемым, надёжным, безопасным. Только веса приоритетов другие. Полностью упор на скорость делается в автомобилях для рекордов скорости. Их разгоняют один раз по самой безопасной трассе в мире, регистрируют рекорд скорости, после чего навсегда убирают в музей. Потому что пользоваться ими безумно опасно.
То, что у нас будет универсальный ui под всё — это хорошо и правильно.
Это не так. Поясню почему.
У каждой платформы есть свои особенности поведения, традиции и нюансы. А также, свой аутентичный визуальный стиль. Например, нативный UI для Mac заметно отличается от такогово для Win и вместе они отличаются от тем gtk/qt/etc. для Linux.
Когда человек выбирает для себя систему, он, в том числе, выбирает и пользовательский опыт, характерный именно для данной системы. И, что важно, привыкает в нему.
С этой точки зрения, десктопное приложение обязано как раз-таки интегрироваться в ОС и вести себя органично. Потому что иначе нарушается принцип наименьшего удивления и людям это кажется неудобным.
Например, выбирая Linux, я выбираю не просто ОС, но и набор подходов к решению своих повседневных проблем. И мне очень не нравится, когда у меня в системе оказывается какое-то поделие, которое навязывает мне некое "среднее по больнице" поведение и вычурный ни на что не похожий UI. И ломает мне все мои привычки.
Я уже молчу о том, что на вебе (при всех его плюсах) практически невозможно написать хорошо работающее приложение. Такое, у которого не едет верстка, отсутствуют тормоза и лютый бешеный аппетит по части оперативки.
"А как же богические Slack и VSCode?" - спросите вы. А так, что из всего неимоверного зоопарка electron-приложений вот только эти два и работают более-менее прилично. Да и то, Slack у меня на рабочем Win-компе отжирал до полутора гигов оперативки. Как по мне, многовато для мессенджера.
Так что, когда нужен одинаковый интерефейс - нужно делать обычный сайт и не выпендриваться. Если нужен desktop, то уж делать надо по-человечески. Чтобы у людей потом глаз не дергался от гениальных универсальных юаев.
Эта идея не работает. Системы прут друг у друга решения и вообще отличаются значительно меньше, чем предполагалось.
Между вашими утверждениями отсутствует логическая связь.
Из того, что "системы прут друг у друга решения" никак не следует, что "эта идея не работает".
Как минимум визуально, интерфейсы Mac, Win и Linux-десктопов отличаются очень сильно. И любой "универсальный" UI не вписывается ни в одну из ОС. Я уже молчу про разного рода OS-specific прибамбасы вроде dock, statusbar и боковые виджеты на макоси, systray и меню "Пуск" в винде и зоопарк DE для Linux.
Я прикрепил первые попавшиеся под руку скрины настроек, которые нагуглил. Как минимум, визуально они отличаются очень сильно. Даже самый лучший "универсальный" UI везде будет смотреться чужеродно.
Скажите, Вы когда на какой-то сайт заходите, тоже ожидаете, что он будет выглядеть "нативно"? Вряд ли. Почему к приложению такие требования? Где грань? Есть многие приложения, которые "выглядят" и имеют "пользовательский опыт", отличный от принятого в системе, но продуманные и сделанные так хорошо, что от этого только выигрывают.
Вы когда на какой-то сайт заходите, тоже ожидаете, что он будет выглядеть "нативно"?
Нет, веб до сих пор сильно отделен от десктопа по принципам и ограничениям своей работы, несмотря даже на то, что за последние годы был предпринят ряд титанических шагов по их сближению. Это до сих пор "окно в интернет", а не часть системы. Возможно когда-нибудь мы действительно придем к реальности, в которой сайт=приложение, а десктоп вообще отпадет за ненадобностью, но пока еще до этого далеко. Да и в этой реальности ожидания будут уже совсем другими.
Почему к приложению такие требования?
Вопрос в стиле "почему брюки одевают на ноги". Потому, что так удобно. Можно вполне надеть и на руки, но получается не очень. То, что какие-то брюки вдруг удобно сидят на руках, ничего, по факту, не меняет.
Сайт, по-простому говоря, это документ внутри приложения-браузера. Веб-приложение - это интерактивный документ внутри приложения-браузера.
Традиционно люди не ждут от документов какого-то единообразного внешнего вида и поведения. Если же посмотреть внимательнее, то на уровне больших и средних организаций, даже на оформление и структуру документов есть стандарты.
Основная идея здесь заключается в том, чтобы поместить человека в знакомую заранее изученную на других примерах среду: внешний вид, структура и основные механики взаимодействия с интерфейсом. Это очень сильно экономит время и "мыслетопливо", так как человеку нужно понять только предметную область и не нужно тратить время на изучение уникальных интерфейсных изобретений авторов приложения.
А тот факт, что кому-то иногда удается с помощью нехитрых приспособлений превратить буханку белого (или черного) хлеба в троллейбус, не говорит о том, что теперь всем нужно поступать так же.
Дополню свой предущий комментарий.
Человек "нанимает" ваше приложение, чтобы решить какую-то свою проблему. Ваше приложение для человека - это инвестиция. Оно должно сэкономить время, деньги, какой-то другой ресурс или каким-то иным образом сделать жизнь лучше.
С точки зрения пользователя, у вашего приложения должно быть ROI, то есть отношение пользы к затратам на освоение и использование. Каждый человек стремится этот ROI максимизировать.
Как максимизировать этот показатель? Правильно: увеличить количество наносимой пользы и сократить затраты (издержки) на освоение. Первое делается с помощью грамотного управления продуктом. Например, решать реальную проблему реального человека, решать ее быстро и хорошо. Второе - с помощью стандартизации интерфейса и удаления из приложения функций, не имеющих отношения к решаемой проблеме.
Замените "приложение" на "сайт". Но... нет.
Заменяем "приложение" на "сайт". Полностью с вами согласен. Сайтам (особенно, если речь не про лендосы и простенькие статические портфолио) тоже не повредила бы некоторая стандартизация :)
У каждого юзера свои приоритеты, что важнее - уникальные красивые плюшки в интерфейсе или стандартизация. Но если в случае с приложениями в принципе могут параллельно существовать несколько разных программ с разным подходом к ui (правда, это в основном верно только для небольших относительно простых приложений), то с сайтом такое не прокатит. Особенно с лендингом. Ведь сама суть лендинга - привлекать внимание и быть запоминающимся.
что важнее - уникальные красивые плюшки в интерфейсе или стандартизация
Выглядит так, будто бы вы спорите со мной, приводя мне мои же аргументы :)
Ведь сама суть лендинга - привлекать внимание и быть запоминающимся.
Это не так. Задача лендинга - рассказать про продукт и продать его. И не важно, насколько лендос привлекает внимание и/или запоминается. Его задача - продать.
И обратите внимание, что именно лендинги как раз-таки максимально стандартизированы. Куда бы вы ни пришли, среднестатистический лендос будет имень очень даже предсказуемую структуру, как на картинке ниже:
Hidden text
Не забудьте отметить, что Skype на электроне работает не то что отвратительно, а почти не юзабельно.
Для этого существуют темы
Удачи вам накатить системную тему на веб приложение.
Собственно, в этом и смысл нативных контролов, что системная тема применяется сразу одновременно ко всем нативным приложениям. Будь то цвета, шрифты, рамки, кнопки управления окном и тд...
Ну ютуб, например, умеет накатывать системную тему. Вы же не хотите сказать, что в 2023 существует что-то кроме светлой и тёмной темы??!!!
какая чушь
вот у меня есть система, в ней все приложения выглядят одинаково так как используют одну тему, и qt и gtk выглядят родными, но потом открывается (если вообще открывается, а то и это не всегда) какое нибудь электроногавно и выглядит чужеродно или выжигает глаза всратыми кислотными цветами, а заодно ещё и плюёт на то что система ему говорит "хей братан, у нас тут принято тёмную тему юзать", неет, электронософт хочет чтобы ты пошёл и руками ему тему поставил (часто платно).
нет, на самом деле есть только одна причина почему стало так много софта на электроне - разработчики вымирают а макак после инфоцыганских курсов становится всё больше.
а пробовали ли вы когда нибудь взять и опкетить этот хлам под пару тройку дистрибутивов? ад и пепел, разрабы электрона слишком занятые чтобы загуглить что такое вендоринг и зачем он нужен а главное как он должен быть реализован, они слишком заняты, они выбирают как заставить пользователя страдать а мейнтейнера плакать.
и да, оптимизация не всегда про быстродействие, но электрон это вообще НЕ про оптимизацию, в нём нет ничего хорошего, одни минусы (и нет, пониженный порог вхождения это не плюс когда речь идёт не про товар из сексшопа а про фреймворк для разработки софта).
В мире, где одна копия программного продукта стоит по цене мусора, инвесторы будут стараться достичь максимальной целевой аудитории любой ценой. Остальное просто невыгодно. Кто будет оплачивать разработчикам большинства продуктов время на оптимизацию производительности или UX - вопрос риторический. Соответственно, де-факто на рынке чаще (не больше, а именно чаще) ценятся скиллы "быстрее зафигачь готовое для продакшена", чем многолетний опыт филигранной оптимизации UX или производительности. А вот про умирание разрабов я пока не особо верю, эта история циклична.
Лучше бы все почаще вспоминали важность работы кнопок Tab/Shift+Tab, адекватность ввода из буфера в поле с масками, адекватные цветовые схемы для выделения поле ввода и т.п., все то, что мы потеряли c windows 8.
Вообще веб технологии на десктопе это предмет бурных споров. Но проблема ли это? Веб технологии кроме своей прожорливости еще и дают то, что не может дать ни одна альтернативная платформа: высокая скорость разработки действительно красивого интерфейса.
Можно упираться и плеваться, но для конечного пользователя важно, чтобы было в первую очередь красиво, а уже во вторую - быстро. Пользователь, как его иногда представляют, слегка наивен, ведом, импульсивен. На это и делается ставка: пользователю дают красивый интерфейс с удобными кнопочками, а самое главное - с фирменным дизайном.
Даже скорость работы понятие относительное. Веб технологии развивались всю свою осознанную часть жизни в сторону повышения скорости обработки контента. Это, кстати, объясняет почему пухнет интернет: браузер начал быстрее обрабатывать скрипты, значит сайты можно делать тяжелее. Сейчас даже сайты-то делать не модно, сейчас делают SPA на жирненьком фронтовом фреймворке с блекджеком и прочими прелестями. Почему? Потому что могут, потому что технологии позволяют. Давайте будем честны: не всем приложениям нужна скорость, тем более, что node дает в некоторых ситуациях производительность сравнимую с компилируемыми языками из-за jit-компиляции.
Кстати, очень забавляют приведенные здесь примеры с консольными приложениями: если подумать, то и консоль сама по себе, и популярность её использования как GUI для своего приложения, ну уж очень напоминает пресловутый Electron, причем как по простоте создания интерфейса, так и возможностях кастомизации (ну почти).
К чему я это все: Electron это просто инструмент, который позволяет писать красивые кроссплатформенные десктопные приложения. Оптимально ли они работают? Нет. Обладает ли бандл приложения достаточно маленьким размером? Нет, вместе с кодом идет, считай полноценный браузер. А нужно ли все это пользователю: чтобы все синтетические тесты работали на 30нс быстрее, чтобы написано было не на богомерзком JS, чтобы интерфейсы были все сплошь нативные? Тоже нет. Софт нужен для того, чтобы им пользовались люди, а не чтобы тестики гонять кто кого быстрей, главное это не забывать.
Почему это фреймворк для SPA обязательно "жирненький"?
Грамотный сайт-SPA намного легче обычного и работает быстрей и приятней чем мобильный аналог на нативном языке
Electron это просто инструмент, который позволяет писать красивые кроссплатформенные десктопные приложения.
Не ради спора , а чисто из спрортивного интереса. Сущесвуют ли в природе не тупящие приложения на Electron?
Vs Code. Работает шустрее чем другие IDEA.
VS Code это не IDE, поэтому и сравнивать его надо не с IDEA, а с каким-нибудь Sublime например
Почему VS Code не IDE? Дайте критерий IDE, которому не соответствует VS Code?
Конечно, Sublime попроще - там много чего нет, что есть в современных IDE, но на мой взгялд, если сравнивать Sublime IDE 30-40 летней давности, то тут уже скорее Sublime будет в лидерах - да IDE 30-40 летней давности это по сути текстовые редакторы с продвинутой подсветкой синтаксиса и привязкой хоткеев к внешнему компилятору и линкеру, и даже с интонацией с отладчиком. Но по сути даже нынешний IDE - это и есть таков вот редактор - просто обвешанный дополнительными инструментами а-ка плагинами - и по сути та де Visual Studio отличается от VS Code отличается от Sublime или Notepad++ просто количеством этих плагинов, ну и может, наворотами внутреннего API взаимодействия этих плагинов друг с другом и интеграцией в редактор кода. Все они не просто работают с кодовой базой, взаимодействуют с хранилищами версий (через внешний тулз), компилируют её (через внешний тулз) и обеспечивают процесс её отладки (через внешний тулз), но имеют (или могут подключить) кучу плагинов по анализу и конверсии этого кода, или обеспечить внедрение в конвейер сборки. То что у кого-то этот ассортимент тулзов меньше - это лишь факт меньшей популярности данного редактора кода.
Приведу ещё один пример - IDE Eclipse (может кто-то кажет, зачем ворошить труп - но это всё-таки ещё не труп, и не стоит возражать, что это не IDE - всегда таковой была) - вот чем эта IDE принципиально отличается от VS Code? А чем принципиально (кроме количества обвеса инструментов) от Visual Studio или от IDEA?
Я не даю никаких критериев, я просто беру определение с официального сайта, на котором VS Code называется редактором, а не IDE
Почему вы считаете, что Sublime попроще? Какие возможности есть в VS Code, которых нет в Sublime и которые невозможно добавить с помощью плагинов?
Мне вот сильно понравился плагин GitHub Actions который позволяет запускать actions workflow прямо из vs code
Намного удобней и быстрей чем через сайт GitHub
У Sublime такое есть?
Я отвечу. Пользуюсь двумя редакторами - Sublime и VS Code.
Sublime - основной, но более простой. Он действительно быстрее запускается. Он проще, легче. Он, как бы это сказать... визуально приятнее, интуитивно понятнее.
VS Code - приходится(!) использовать. Когда надо работать с каким-то тяжеловесным проектом. В нём многое есть уже из коробки.
В Sublime надо надо "танцевать с бубном" - искать плагины (там частенько из описания - только название пакета), устанавливать их (порой через консоль), чем больше пакетов - тем сильнее он тупит при запуске, есть далеко не все нужные плагины (ну нет там, например, линтеров нормальных, которые ещё и файловую систему проекта "наблюдают"), порой плагины просто "отваливаются". При переустановке слетают все настройки - приходится лазить по установочным пакетам, распаковывать их, руками что-то править... Бррр...
Если надо элементарный html/js/css - открою Sublime (он у меня вообще системный текстовый редактор по умолчанию). Если тяжелый реактивный фреймворк (чтобы подсветка синтаксиса корректная, глубокая интеграция в проект, линтеры и т.п.) - VS Code.
Чего именно не хватает VS code что бы быть IDE? Или из за того что без установленных плагинов это редактор текста?
Я говорю конечно же о VS code в котором установлены все плагины под нужное окружение и работает это все так же быстро.
Я не даю никаких критериев, я просто беру определение с официального сайта, на котором VS Code называется редактором, а не IDE
В Sublime тоже можно установить пачку плагинов, превращающих его фактически в IDE
И что будет тогда? Sublime будет быстрее? Какое это отношение имеет к моему изначальному комментарию.
Я сравниваю инструмент А и инструмент Б, полностью аналогичный по функциям. Если компания Б решила назвать свой продукт IDE и сделать его медленным это ее выбор, я выберу инструмент А.
Ладно бы говорили не сравнивайте совершенно разные продукты, но нет, продукты и использование одинаковое.
Sublime будет быстрее?
Вот надо сравнить и посмотреть что будет) Оба официально называются редакторами, оба расширяются плагинами, сравнение вполне валидное. Когда вы выбираете между инструментом А и инструментом Б, не забывайте, что существует ещё инструмент В, который потенциально может оказаться лучше их обоих по каким-то критериям
У инструмента В нет нужных плагинов для работы (хотя бы для примера Playwright), поэтому лично для меня сравнение будет бесполезным.
Поэтому когда пишете комментарии не забывайте что человек уже мог проверить и инструмент С, который ему не подошел по функционалу.
Не забываю, но и заранее угадать, чего людям не хватает, я тоже не могу, я ж не телепат всё-таки. У разных людей разные потребности: так сложилось, что лично мне в моей работе не нужны ни Playwright, ни GitHub Actions, поэтому я сижу на Sublime и никогда не использовал ни VS Code, ни IDEA ¯\_(ツ)_/¯
Вообще, в контексте данного топика обсуждать наличие или отсутствие плагинов по-моему нет смысла: недостающие плагины всегда можно написать. Довольно логично, что люди будут выбирать тот редактор, в котором есть нужные им плагины. Поэтому здесь более интересный вопрос — почему люди пишут плагины для VS Code, а не для Sublime? Люди обожают JavaScript? Люди ненавидят Python? В Sublime слишком ограниченный API плагинов? Слишком удачный пиар от Microsoft? Слишком проприетарный Sublime (если да, тогда почему не CudaText какой-нибудь)?
Является ли успех VS Code заслугой Electron, или, как предполагают ниже, «это не благодаря, а вопреки»?
Быть может, если портировать самые «важные» плагины из VS Code в Sublime, то электроноподелие проиграет по всем оставшимся параметрам?
Мне кажется основой такой популярности VS code как раз является то что это не простой текстовый редактор, даже у только что установленной VS code есть куча функций. Например там сразу есть IntelliSense, task runner, git, debugger (TS/JS), по сути изначальная установка это аналог WebStorm(IDEA) . Посмотрите так же как реализованы настройки, с поиском и описанием, хотя внутри это такой же json файл как и в Sublime.
Так что я бы рассматривал это как IDE под JS/TS, которое ты можешь настроить под другие окружения.
Sublime это текстовый редактор в котором тебе придется устанавливать вообще все (debug например, либо task runner). Я не уверен что это будет работать так же быстро как VS.
Поэтому здесь более интересный вопрос — почему люди пишут плагины для VS Code, а не для Sublime? Люди обожают JavaScript? Люди ненавидят Python? В Sublime слишком ограниченный API плагинов? Слишком удачный пиар от Microsoft? Слишком проприетарный Sublime (если да, тогда почему не CudaText какой-нибудь)?
Это же как вопрос курицы и яица, люди пишут плагины для VS потому что больше людей используют VS, и все больше людей используют VS потому что все больше плагинов.
Я думаю тут причины все сразу и поддержка/пиар Microsoft, и хорошая команда разработчиков, и выбранная платформа, по скорости обновлений не видно что у них есть какие либо проблемы. Насчет плагинов, не смотрел, но уверен что так же все продумано ) Как минимум с установкой и настройкой никогда не было проблем.
Я думаю этот спрос бессмысленен - предлагаю сойтись на том, что любой редактор кода начиная с определённого уровня обвеса плагинами превращается в IDE. А если эти плагины являются его базовой составной частью минимальной поставки - то изначально это не редактор а IDE. А вообще - IDE - Интегрированная среда разработки - согласно вики у текстовых редакторов программного кода в комплекте нет только компиляторов/трансляторов, чтобы считать их IDE - так что это всё очень условно (лично я бы не стал включать их наличие в базе как ключевое требование? но кто-то скажет, что это важно), кто как называет свой редактор, не столь уж важно
Если немного навесить всякого на vim, то он тоже будет IDE. Но по-умолчанию это всё же редактор.
удачи там resharer поставить, профайлер, анализатор памяти к нему подрубить, отслеживание потоков и ещё визуализаторы для удобного отображения объектов, а про убогую отладку C++ кода на vscode по сравнению с VS я вообще промолчу, я уж лучше потерплю тормоза и куплю себе железо топовое чем заниматься этой пародией на отладку в vscode. vscode отличный редактор для всяких скриптовых языков вообще ноль вопросов, но по части компилируемых это треш и садомия.
VsCode — пример хорошего нетупящего приложения на electron. Но, есть мнение, что это не благодаря, а вопреки
Похоже, что исключение только подтверждает правило )
Obsidian
Joplin,
вроде и новый evernote
и у всех — проблема как сделать нормальную синхронизацию на мобилках в фоне
Я обожаю Joplin и мечтаю, чтобы он вышел в виде нативных приложений :)
новый evernote
тоже жрет память как не в себя. На одной и той же базе в 10к заметок,
новый evernote жрет 1200 mb
legacy evernote скромно кушает 155 mb.
Можно конечно сказать, что у них не идентичная функциональность. Но не настолько.
Ну… Факт остаётся фактом. Сделать хорошую программу на электроне возможно
HTTP Toolkit (штука достаточно специфичная, скажем так аналог Fiddler'а)
Там клиент — на Electron но GUI вообще грузится с сайта (что мне было совсем не очевидно пока не пришлось глубоко в кишки лезть).
Это кстати еще и пример приложения с платной подпиской которое при этом под AGPLv3.0 (включая вещи вроде системы оплаты(!))
Да, не IDE
>>Веб технологии кроме своей прожорливости еще и дают то, что не может дать ни одна альтернативная платформа: высокая скорость разработки действительно красивого интерфейса.
Простите, но дальше будет грубо.
Как вы уже достали со своими красивыми интерфейсами. Один закрывает окно жестом вверх, другой кнопкой внизу слева. Подозреваю, что скоро кнопку закрытия на жопу пользователя проецировать - во всяком случае мысли такие часто реализуются у нынешних "программистов".
Пользователю глубоко плевать как выглядит ваша программа, если это не условный vi. То что вы наворотили в ней "красивый" интерфейс вида "ужас нерожденного" - это ваша хотелка. Пользователь хочет СТАНДАРТНЫЙ интерфейс, чтобы ему не приходилось каждый раз выяснять, куда "ЭТИ ДЕБИЛЫ" засунули в очередной раз одну из стандартных функций программы. Стандартный, с#ка, где каждый жест, каждый шаг, вид интерфейса - стандартен, одинаков и логичен для всех программ, позволяет работать на автоматизме, а не разбираться с очередным высером на джаваскрипте с нескучными эффектами и transition- переходами между шагами.
Совершенно точно. Можно было и не смягчать. Эти дизайнерские закидоны нужны только самим дизайнерам для повышения личного эго. За плоский дизайн в повседневных утилитах и инструментах иногда хочется просто убивать. Долбаная идея hide action уже поперёк горла стоит. Родные API как-то меньше оставляют свободы выражения этим "художникам", может поэтому и интерфейсы получаются приличнее?
Как вы уже достали со своими красивыми интерфейсами. Один закрывает окно жестом вверх, другой кнопкой внизу слева. Подозреваю, что скоро кнопку закрытия на жопу пользователя проецировать - во всяком случае мысли такие часто реализуются у нынешних "программистов".
да, интерфейсный карго-культ это дело такое, но если подходить к строительству интерфейсов грамотно - то есть делать его эргономичным и с аксессебилити - это опять же будет проще сделать на браузерных технологиях ибо в вебе это также отработано гораздо лучше и давно
не разбираться с очередным высером на джаваскрипте с нескучными эффектами и transition- переходами между шагами
Плавные переходы могут иметь логичную природу. Например чтобы изменения в интерактивном интерфейсе, казались пользователю последовательными и обратимыми. Также плавные переходы позволяют маскировать различные вычисления, например клиент-серверные взаимодействия, чтобы интерфейс не казался зависающим и прыгающим.
Пользователь хочет СТАНДАРТНЫЙ интерфейс
Можно попробовать даунгрейднуться на перфокарты или что еще примитивнее, уверен что там было меньшее количество ключевых различий интерфейса, чем в куче современных гайдлайнов различных GUI. А если серьезно, то мне не очень понятно что в Вашем понимание означает стандартный интерфейс, и кто или что обеспечивает эту самую стандартизацию. Возможно дело просто в определенных привычках, а не в отсутствии следования тем или иным стандартам. Но выработанная привычка не означает привязку к чему-то стандартному или даже просто хорошему, и подходящему для всех. Особенно учитывая как сильно изменились цифровые устройства и способы взаимодействия с ними за относительно небольшой промежуток времени. То есть элементарно: различные поколения, уже взрослых людей, могут иметь совершенно разные представления о том, что для них является преимущественно стандартным интерфейсом и почему.
Впрочем я могу согласиться, что во многих программах могут быть не самые лучшие графические интерфейсы. Но у меня не вызывает это столько эмоций и раздражения в адрес проектировщиков, я скорее с этим не согласен.
Плавные переходы могут иметь логичную природу.
Да. И это вовсе не означает, что все переходы (всмысле, любая анимация) точно имеют логичную природу. По моему опыту, анимацию пихают где надо и где не надо просто потому что можно. А главный агрумент - "чтобы было нескучно". И вот это уже клиника.
не очень понятно что в Вашем понимание означает стандартный интерфейс, и кто или что обеспечивает эту самую стандартизацию.
Внезапно, у каждой крупной ОС есть User Interface Guidelines. Внезапно же, у каждой крупной ОС есть GUI фреймворк/либа, основные контролы в которых уже реализованы с учетом этих гайдлайнов. Это и есть стандарт.
Очевидно, что гайды не покрывают всех хитровыделанных случаев и степень следования им в нестандартных ситуациях - это вопрос дискуссионный. Однако, они хотя бы избавляют от необходимости в 100500-й раз рисовать и программировать yet another neskuchnaya button. А пользователям не приходится каждый раз заново разбираться, что это за фигня такая тут торчит.
На протяжении многих лет наблюдаю, как много людей остаются недовольными изменениями в интерфейсе Windows. Или на днях обновил операционку на маке, после того как несколько месяцев не включал его, и обнаружил что там полностью поменяли приложение настроек. Думаю это тоже вызвало недовольство многих пользователей. Хотя как по мне - стало лучше.
В общем, гайдлайны той или иной ОС меняются довольно часто. И их авторам приходится учитывать паттерны, к которым привыкают люди на других платформах, адаптироваться к новым технологиям, исследованиям и всё прочее. То есть внезапно оказывается, что гайдлайны являются стандартом только в рамках определенной версии ОС, и могут меняться раз в несколько лет даже в рамках одной операционной системы на одной платформе. В итоге далеко не для всех, гайдлайны ОС могут быть удобным ориентиром, по разным причинам. В том числе и по причине возникающих в них изменений, которые необходимо поддерживать и согласовывать в разных окружениях. И по этому yet another neskuchnaya button, может оказаться не хитрой выдумкой дизайнера или проектировщика, а вполне себе требование бизнеса, вычисляемое в деньгах.
Это про Андроид. Есть программы, которыми я пользуюсь годами, и всё равно то и дело открываю не то или, чаще, закрываю что не хотел. Яндекс Музыка в список, Discord, ещё много чего. Некоторые из этих кривозавров - полностью нативные, и это им никак не помогло.
А можно выяснит, какой пользователь?
К примеру, моим родителям, очень сложно разобраться в совсем стандартном ui. Есть еще категории, которые требуют отдельного вывода интерфейса. Или стоит еще и для прогерров с их "стандартный" интерфейсом завести спецификацию?Что значит стандартный? Стандартный для чего? Браузер? Ос. Графическая оболочка? То, что браузеры договорились более/менее между собой, это ни о чем не говорит.
Красивый софт можно делать и на компилируемых языках. В некоторых языках и инструментах даже быстрее и эффективнее (т.е. работает UI быстрее и плавнее) чем HTML/CSS/JS
Пример
на вид чистый web
А как оно себя чуствует с RTL/emoji и прочим? Прикрутятся ли к этому формулы без килобайтов кода? Что насчёт интерактивных инлайн элементов а ля бот-меню как в телеграме?
Вот, я делал ВК клиент
Всё на стандартных контролах и штатные инструменты стилизации. Инструменты стилизации тоже визуальные. Т.е. не css, qss или qml подобный, а снова дизайнер, который позволяет создавать представление контрола
Мобильная тестовая версия. Без адаптации интерфейса. Свежей на руках нет
высокая скорость разработки действительно красивого интерфейса.
То есть, если по-простому: дешево нагомнокодить любые безумные фантазии очередного безумного "гения"
Можно упираться и плеваться, но для конечного пользователя важно, чтобы было в первую очередь красиво, а уже во вторую — быстро.
Серьезно?
Проведите простой, но очень (максимально) наглядный эксперимент. Возьмите старенький нетбук с Atom N455 и 2gb ddr2 RAM (MSI Wind U135 например).
В одном из вариантов отсавьте идущую в комплекте WinXP и офис 2003. Во втором варианте накатите Win7 + Office 2019.
Дайте пользователям открыть большой перегруженный doc-файл. И узнайте, что им понравится больше — старая XP с древним дубовым 2003 офисом, который стартанет там примерно за 2-3с и еще за 10 прогрузит весь документ, или красивая Win7 с загрузкой в 8 минут, открытием 2019 офиса (стильно-модно молодежного) еще в почти минуту и парой минут на загрузку документа.
Что-то мне подсказывает, что выбор будет отнюдь не в пользу блестящих свисто-перделок, а в пользу страшного но нормально работающего.
У меня так провайдер A1 родителям на древнем выдаваемом им TV-боксе (который и без того был древней дохлой тормозной дичью) нобновил 2 раза андроид и накатил вместо старого ПО своё новое, и задержа в переключении пунктов меню сменилась с терпимых 1-3с до 12-40с (почти до минуты! переключение пунктов в меню чтоб фильм найти!!). Зато красиво, да...
браузеры, стандарты и экосистема HTML/CSS/JS слишком быстро изменяются (гораздо быстрее, чем это нужно для коммерческих приложений);
Так ведь и операционки не стоят на месте, тоже меняются. и оказывается что под каждую новую нужно адаптировать.
Долгое время я серьёзно заблуждался, считая, что десктопные приложения могут быть быстрыми, только если они написаны на native api. Яркий пример конктретных тормозов электрона - MS Teams.
Но с выходом MS Teams Work preview убедился, что это не совсем так. Летает, память не жрёт как не в себя. А он, внезапно, тоже на web!
На сегодня, скорее всего, скорость работы больше зависит от прямых рук кодеров. Хотя про платформу Элекрон, у меня, как у пользователя, до сих пор очень плохое мнение.
Пруф про новый Teams:
Только ни фига не понятно что там делают 7 инстансов броузера... Это точно про эффективное использование ресурсов машины юзера?
Не знаю внутреннее устройство, возможно, это отдельные потоки для асинхронной обработки чатиков и каналов. Но он реально летает! И это не браузер, это рендер, если я правильно интерпретировал Edge WebView2
В предыдущей версии тоже были такиее потоки, но страшно жирные и медленные.
Эти вопросы актуальны лет 30, с момента появления винды, и всегда решались перспективой появления более мощного / дешёвого железа в перспективе в несколько лет. В таких условиях тупо нет экономического смысла сильно упираться в оптимизации. 32 гига памяти нынче стоят от 50 баксов, один кулёк продуктов в супермаркете.
Пол гига оперативы для копроративного чатика на стероидах? Вы точно правильно понимаете смысл фразы "не жрёт как не в себя".
Но с выходом MS Teams Work preview убедился, что это не совсем так. Летает, память не жрёт как не в себя. А он, внезапно, тоже на web!
На сегодня, скорее всего, скорость работы больше зависит от прямых рук кодеров.
Да. Вот только разница в том, что та производительность, которая в Electron будет достигаться болью и страданием ради оптимизаций на каждом шагу, в условных Delphi/C++/Net.core будет из коробки. Т.е прям сразу. На нормальных компилируемых языках для десктопа можно писать лютый говнокод, который по потреблению ресурсов будет ± таким же как насмерть заоптимизированный JS. А представьте, что будет если этот говнокод еще и оптимизировать?)
как то поздно вспомнили. вот как только зарождался електрон было стремно - сейчас никакой боли не создает
сейчас никакой боли не создает
Писателям. Как пользователь я его просто ненавижу.
Из относительно свежего - у него (были?) проблемы с выведением системных уведомлений со звуком (уведомление было, звука не было, наступил в мессенджере Keybase), и довольно регулярные проблемы с hardened настройками ядра линуха - из-за них вечно встроенный хром то не запускается вообще, то ругается на невозможность использовать sandbox, то требует странных опций командной строки чтобы что-то там отключить (наступал в ряде приложений, включая Slack). Боль как минимум была в том, что сложно понять кто виноват и где/как чинить - потому что тут комбинация особенностей пользовательского окружения (которое электрон вроде как должен был абстрагировать), своего приложения, самого электрона и лежащего под ним хрома. А даже когда удавалось выявить где проблема - сложно репортить такие баги в электрон, потому что для воспроизведения требуются недюжинные усилия, сторонние приложения и специфические настройки пользовательского окружения… из-за чего такие баги даже отрепоченные имеют тенденцию висеть годами открытыми.
Люди смирились и просто смотрят, как одна за другим нативные программы переходят на Electron со всеми вытекающими последствиями.
Я не смирился. Я, видимо, не человек :)
Лучший консольный софт
Какой-то очень рандомный список софта. Не то чтобы плохой - сам, наверное процентов 70-80% пробовал и 25-30% использую. Но какой-то уж очень случайный и бессистемный.
Ну и да, "консольные" приложения тут смешаны двух видов: "консольные труъ" и "консольные с текстовым ui". И те и те нужны, но обычно "труъ" удобно использовать в автоматизации и для сложных команд, а "с ui" обычно обёртки над "труъ", но удобные для человека. В списке в основном с "ui" или даже вообще не совсем консольные.
Не электроном единым. Есть еще PWA и Tauri.
А PWA на чем работает?
На винде на встроенном Chromium Edge
Так мы сравниваем виртуальные машины или сами приложения?
Имел ввиду что Electron не единственный способ запуска веб приложений на десктопе и есть более легкие решения.
Решил отойти от мейнстрима и потыкать что нибудь легковесное вместо Electron'a
Было интересно потыкать связку $mol + tauri = результат понравился: шустрое приложение, много не кушает (< 100мб оперативки):
С молом проблем особо не возникло, благо отзывчивое в последнее время комьюнити занимается документацией и сейчас ситуация лучше, чем полгода/год назад
С таури возникла заминка с установкой rust'a - c++ билд тулзы через установщик не ставились без впн, зато хот релоад завелся без проблем, что, несомненно, плюс
Сбилженное приложение весило ~8 мегабайт:
Рантайм с собой не тащит, использует системные webview
Вопрос буде ли оно адекватно работать на разных версиях ОС.
11, куча 10, 8, 7..Есть информация по этому поводу?
Вот. А если приложению хватает браузерных апи (на десктопе уже давно доступна работа с файловой системой например), то можно вообще обойтись без обертки и сделать PWA. Использоваться также будет системный webview, вес будет равен весу веб-приложения, и обновлять можно в фоне без посторонних сервисов.
несовместимость разных версий фреймворков (приходится частично переписывать код);
А как там с десктопным нативным фреймоворком GTK 3 дела обстоят? Все уже перешли?
браузеры, стандарты и экосистема HTML/CSS/JS слишком быстро изменяются (гораздо быстрее, чем это нужно для коммерческих приложений);
Почему это представляет проблему? HTML/CSS/JS славятся обратной совместимостью.
трудности в поддержке.
Простота написания кода не всегда коррелирует с простотой починки багов. Однако быстрый цикл разработки помогает оперативно реагировать на проблемы и требования.
Однако быстрый цикл разработки помогает оперативно реагировать на проблемы и требования.
Этот самый быстрый цикл разработки как раз и стимулирует писать "на отвали". Аджайл придумали чтобы было на что сваливать вечные баги. Всегда есть что исправлять. Безработица не грозит, вечная загрузка и вечный технический долг )))
В настоящее время нативный GUI в Windows 11 не факт, что будет работать лучше/быстрее приложений на Electron.
В эпоху Win32api все нативное работало более менее быстро. Сейчас же даже нативный Taskbar в Windows 11 порой тупит сильнее, чем Chrome с 150 вкладками и кучей установленных плагинов. Даже вызов Task Manager происходит с нормальной такой задержкой отрисовки интерфейса.
Мне особенно "нравится" как диспетчер задач Win11 подтормаживает при прокрутке списка процессов и это на rtx3080, i7 10700k. Куда-то прогресс в IT пошел не туда
edit1. Даже если просто выбрать вкладку процессы то она открывается где-то около 1 секунды. Для процессора 1 секунда это как для человека 1 млн лет
Вы не поверите, но это такое же Win32 приложение, как раньше. Да и на планшете с Celeron, с которого я сейчас пишу этот коммент оно почему-то не лагает. Специально проверил.
Хмм... не особо в этом разбираюсь, но мне казалось, что там уже какой-нибудь UWP (Universal Windows Platform) с каким-нибудь WinUI 2 или даже WinUI 3...
Вообще у винды проблема с унификацией своих интерфейсов, все никак не могут перейти в свой плиточный интерфейс и избавиться от Control Panel и других рудиментов, в итоге часть настроек у нас в Settings, часть в Control Panel. На хабре была неплохая статья на эту тему: https://habr.com/ru/articles/541356/
Проблема не в самих приложениях, а в Хромиуме лежащим в Электороне. Когда убивали прожорливый Флэш большинство не верило что HTML 5 станет ещё большим монстром. Производители ОС не хотят договариваться об общем АПИ, в итоге рождаются Электрон, Вайн, Параллелс, в итоге они ещё на дольше откладывают решение вопроса и заставляют пользоваться костылями.
Производители ОС не хотят договариваться об общем АПИ, в итоге рождаются Электрон, Вайн, Параллелс
Даже некоммерческие разработчики графических библиотек в экосистеме линукса не имеют общих API. Одним нравятся GTK, другим Qt, третьи вообще пилят своё, четвёртые ваяют на голых иксах. Видимо существование зоопарка оконных библиотек имеет под собой более фундаментальные причины, чем просто "не хотят договариваться".
Да, есть такое. Разрабатывал и под Электрон, и под Кордову. Смущает меня этот Хромиум, запакованный вместе с приложением. А ну как отвалятся какие сертификаты безопасности? Всё, приложение неюзабельно?
Ну и плюс он не даёт полную кросс-платформенность. Я как-то делал скринсейвер для Андроида на разных платформах - сравнить скорость отрисовки. В итоге CSS порвал всех в клочья)) Только проблема в том, что 50мегабайтный запакованный проект Электрона никак не установить в качестве скринсейвера - для этого надо юзать нативные java-методы. Ткнуть пальцем и запустить - пожалуйста! После 30 секундного бездействия - извините...
Уберите, пожалуйста, MS Teams из списка. Мелкомягкие его переписали на "Microsoft’s Edge Webview2" в новой версии. Это ещё Web, но уже не Electron.
Думаю, что ещё рано убирать.
Части жизненно необходимых функций в новой реально классной версии ещё нет, статус Work Preview справедлив. Чтобы не положить Help Desk, я новую версию пока только самым хардкорным пользователям политикой разрешил к установке. Которые могут к примеру сами тот же Outlook Teams Meeting add-in вернуть к жизни, внеся ключики в пользовательский реестр:
teamsmeetingAddInRestore.reg
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Outlook\Addins\TeamsAddin.FastConnect]
"Description"="Microsoft Teams Meeting Add-in for Microsoft Office"
"FriendlyName"="Microsoft Teams Meeting Add-in for Microsoft Office"
"LoadBehavior"=dword:00000003Что в этом списке саклесс программ сплошное засилье программ для *nix систем - а там испокон веков GUI не в почёте был - а в почёте была боль и мощь posix api взаимодействия ПО
Как получилось, что современный десктопный GUI по умолчанию использует платформу HTML/CSS/JavaScript, которая изначально не предназначена для нативной работы на десктопе?
Причин очень много:
Возможности HTML/CSS по описанию интерфейса скорее всего обгоняют все десктопные GUI библиотеки вместе взятые
Переносимость кода на все возможные платформы и разрешения экрана (собственно везде, где работает браузер)
Практически бесплатная веб-версия приложения
Огромное коммьюнити (разработчики, библиотеки, обучающие материалы, ...)
Собственно, вопрос нужно задавать обратный - какая есть причина НЕ использовать веб стэк на десктопе? Чтобы сэкономить лишние 200Мб оперативной памяти?
200?
Joplin и Thunderbird занимают так мало только потому что они скрыты и у них забрали память верхние "вебки"
200?
А что, Вы думаете вся эта память занята электроном? Я могу вам показать скриншот с IntelliJ IDEA, которая занимает 10 гигов. Только это не показывает ничего, кроме того, что открыты проекты определенного размера.
У меня например VSC занимает 400Мб оперативы с открытым небольшим проектом на C#
Как бы то ни было большую часть памяти компа даже без разработки сейчас сжирают приложения на js движках
с другой стороны, оператива сейчас недорогая. Ну не то время живем, когда зарплату считали в "сколько плашек оперативы смогу купить"
Только, если у вас стационарный ПК.
Если у вас ноутбук, хуже того, ноутбук определенной компании (не будем показывать пальцем), то там только распаянная ОЗУ, и каждые следующие 8 (восемь) гигабайт сверх базы в 8 гигов обходятся в лишние 300 баксов или евро.
ну так, ноутбуки никогда не считались устройствами которые подходят всем. Это всегда компромисс между габаритами, тепловыделением, шумом системы охлаждения
и виндовые ноуты (привет хуавей) бывают с распаянной памятью. А сколько вариантов игровых ноутов с 3060 например? есть подешевле, где тдп рассчитано на 80 ватт, а бывают подороже - где 130 ватт
Также и с памятью, если нужны задачи, требующие памяти, конечно надо обращать внимание на возможности покупаемого железа.
А так. ноут это сильно проще компа в плане использования. Ноут это как микроволновка, купил, проработал лет 5 (хорошо если 10), затем новый купил
декстоп это хренова туча познаний, от которых в целом ни холодно ни жарко. Знать топовые термопопасты, знать как ее наносить, знать хорошие кулеры, корпуса , хорошие вентиляторы, хорошие видеокарты (и где их достать недорого), модели оперативки (и ее возможности разгона), модели блока питания (вы еще не устали) хренова туча проводов, которые мешаются постоянно. если системник на полу, то он отлично собирает пыль (а то и шерсть, если нет пылевых фильтров). Системник это такая штука, которой надо жить :) другое дело ноут, купил, ну память добавил, к монитору подключил и живешь и радуешься. А у кого хорошее зрение, тот и на 15-шке с фуллхд работает нормально
Слушайте, не нужно холивара десктоп вс ноут. У меня есть и десктопы, и сервера и ноут.
Но прямо сейчас, если мне просто нужен сносный ноут в 12-14", куда я смогу поставить 32 гигабайта ОЗУ за 50 баксов, а не отдать за кусок пластика и металла свою зарплату целиком. И вижу фигу.
Все же утверждают - ОЗУ дешевая. А я утверждаю, что это утверждение далеко не всегда истинно. И никаких принципиальных ограничений, чтобы воткнуть 32 гига в ноут, кроме ошалелой жадности производителей, нет.
Это же не 4090 с 600 ваттами запихивать в килограммое устройство :)
У меня 2 декстопа, 2 ноута и еще арендованный сервер :)
"Сносность" ноута Вы же сами определяете. Я купил недоигровой леново идеяпэд с 3050ти (экран не 100% ргб, но я на нем не дизайнить буду) с доставкой от арабов (микролес) обошелся в 50к. Плюс докупил 32 гб оперативы (не космические деньги)
также есть делл востро 13-шка, поставил туды 16. Посколько не игровой совсем
Чем леновки несноные? есть такие же модельки, но с лучшим экраном. Да с другой стороны, какая разница сколько там процентов RGB, для дизайна надо все равно от 24х дюймов хороший монитор (а лучше 4к и 27-32)
>Все же утверждают - ОЗУ дешевая. А я утверждаю, что это утверждение далеко не всегда истинно.
нет, Вы пишите, что макбуки дорогие с 32гб оперативы. Но макбуки это сейчас пиковые устройства по технологичности. Там революционные процы, хорошие экраны и тд. Ось в конце концов, которая нравится многим разрабам и саентистам
Хорошо, расскажите, почему я не могу просто добавить воды ОЗУ в Apple Macbook? Сносный ноутбук, но если хочется чуть больше ОЗУ - получается несносная цена.
И ладно бы он одил такой был, сейчас очень многие предлагают хорошо если хотя бы 1 слот.
К примеру, у Dell XPS слотов 0. Причем "старшая" модель тупо не имеет опции в 32 ГБ. "Младшая" модель имеет, и разница между 32 гигабайтами ОЗУ и 8 стоит пользователю в божеские (по сравнению с Яблоком) 250 баксов.
А причем тут возможности добавления.
Ноут это как микроволновка. А мы обсуждаем стоимость стеклянной подставки в него. Вот в одни микроволновки можно поставить другой диаметр, а в другие нет. Но это не имеет отношения к цене стеклянной подставки
Или автомобили, мы можем обсуждать цену дисков, но возможность их установки в какой-то конкретный авто - это другой вопрос и другая проблематика. В матиз можно поставить 13, 14, но нельзя поставить 15 (ну можно конечно и 17, ток очень тонкая резина будет). но это не связано с ценой дисков на 15
Если модель младшая имеет возможности, то какая разница за сколько продают модель с 32гб. Просто разбираете и ставите сколько влезет. Может даже 64гб (зависит от проца, не является офертой)
Знать топовые термопопасты, знать как ее наносить, знать хорошие кулеры, корпуса , хорошие вентиляторы, хорошие видеокарты (и где их достать недорого), модели оперативки (и ее возможности разгона), модели блока питания (вы еще не устали) хренова туча проводов, которые мешаются постоянно. если системник на полу, то он отлично собирает пыль (а то и шерсть, если нет пылевых фильтров).
Пугалка какая-то неадекватная. А что будет, если я не топовую термопасту возьму, а обычную? Если не собираюсь ничего гнать? Если возьму любой массовый бренд? Что надо знать такого секретного по БП, кроме его мощности, разъёмов, формфактора, и что производитель не совсем полный китай? То же по памяти, знать что у памяти есть объём, тайминги и формфактор это прямо запредельно сложно?
Я года 4 назад собрал игровой ПК на базе китайской материнки Kllisre. Всё купил на Aliexpress. Никогда не разбирался особо в железе, просто погуглил гайды по китайскому железу. Вышел прекрасный бюджетный игровой комп, никаких нареканий.
а что такое обычная термопаста? что будет? разница допустим может 5 градусов быть. - выше температура, больше шума. А если еще с кулером не угадать, то возможен неприятный секас с установкой (несколько раз пальцы резал, пока ставил дипкулы на защелках), ну и соответственно плохой кулер - плохое охлаждение.
кулеры еще бывают 2 видов по типу контакта (не считая вариаций башен и топфлоу)
Что надо знать про БП? ну например мемы про КСАС знаете? А БП отличаются стандартами (говно, бронза, серебро, золото). Плюс надо понимать какой мощности брать, разъемы нужны в нужном кол-ве, лучше брать модульный, а для новых видюх возможно нужно специальны. А тут еще новый стандарт на горизонте
О, сударь, Вы еще про тайминги знаете. Какой процент людей вообще про тайминги знает? из тех, кто не завсегдай железячных сайтов? Как там, вторичные настраивали или остановились на первичных? Лично я адепт "включил профиль и хрен с ним"
Китайская материнка это вот вообще та еще лотеря, чтоб в нее ввязываться... ну тоже надо чуток разбираться
прекрасный бюджетный комп на китайской мамке не может быть по определению. Ну как бы бюджет и "китайщина" несовместимы с понятием "прекрасный" вообще. А еще и игровой....
Итого, если человек хочет вместо ноута купить декстоп, то ему придется разбираться в хренову тучу вещей. Про которые спустя годы думаешь "нахрена я это знаю, нахрена я на это тратил часы жизни". Вот Вы знаете какой 120-й вентилятор сейчас топ по цене/эффективность. Я вот знаю и думаю, вокруг меня живут люди, которым это нафиг не надо. Ну заплатят они чуток больше, но зато у них голова свободна для других более интересных (или даже более денежных) вещей
А сколько дома лежит всяких запасных частей? вентиляторы, кабеля (не все ж пригодилсь от БП), коробки от мамки (а вдруг нести в гарантийку), несколько видов термпух (часть с кулером, но обычно с кулером не самые лучшие) - но тоже лежат, какие-то железки от корпусов, которые сейчас не нужны, но выкинуть жалко, потому что "вдруг пригодится или вдруг решу продать корпус". Коробка от кулера, потому что у меня АМД, а есть еще крепления под интел. не выкидывать же, мало ли сменю платформу, и тд тп. Десктоп это такая штука, что мало того, что он сам по себе "вещь в себе", так еще и отрастает значительным кол-вом запасных частей, примерно как гараж у обладателя отечественного автомобиля в СССР
Ну я купил китайский MSI Trident десктоп ультракомпактный после 10 лет использования ноутов и гейминга на иксбоксе. Доволен как слон, игры играются в 4к, внутрь не залезал и не собираюсь.
видел такой на обзорах, там свои есть тонкости. Типа шума, потому что иначе никак
а что касается 4к, там не та видеокарта, чтоб 4 к тянула. Уж даже 4090 не все тянет в 4к
Да и Trident существует не один вариант, а несколько. Поэтому "я купил MSI Trident" звучит как "я купил машину". у Трайдент как минимум 3 поколения процессоров устанавливались (10, 11, 12)
AS11TC
Да, шумит, потому что иначе никак) Assassin Creed Valhalla в 4к точно тянет. Atomic Heart не помню, вроде тоже.
Но в целом посыл был, что можно не сидеть с отвёрткой, а купить десктоп в сборе. У меня была хотелка, чтоб компактно, а так-то и дешевле можно существенно.
Вы удивитесь, но AS11TC тоже несколько видов (пара моделей с первой страницы яндекса)
AS 11TC-2238XRU
AS 11TC-2481XRU
AS 11TC-2435XRU
Проще написать конфиг, проц такой, видеокарта такая-то, память такая-то. Чаще всего видимо ставится 3060 - карта среднего уровня
4к может реализовываться с помощью DLSS, например. Без этих "ухищрений", 4к в Вальхалле 3060 выдает порядка 30 фпс, что вряд-ли можно назвать комфортным геймингом
Но что касается посыла, эта серия у MSI довольно неплохая. А бывают сборки от магазинов, где формально вроде нормально, но шумный кулер, дешевый БП, оператива с плохими частотами и тд. Зато пломба на корпусе...
Спорное утверждение. Но даже если и так, то что? Лучше, чтобы этих приложений не было?
Нет, не лучше. Но ускорение/упрощение разработки с помощью веб-технологий необходимо для выживания приложения только тогда, когда быстро меняются требования со стороны заказчиков или самих пользователей. Или когда финансирование очень ограничено. Если требования к приложению стабильны, конкуренты не обгоняют, уже готового сайта (функционал которого просто нужно 1 в 1 перенести на десктоп) нет, и с бюджетом проблем нет (проект OpenSource или принадлежит богатой компании), то весь этот веб на десктопе совершенно лишний для юзера. Он бы получил примерно то же самое с нативным приложением (ну или кроссплатформенным десктоп-приложением на чём-то типа Qt), только возможно релиз был бы на несколько месяцев позже. Для многих программ с большим сроком жизни это не критично, на мой взгляд. Т.е. я не считаю Electron злом. Есть примеры, где он был очень полезен (тот же draw.io), или просто не помешал. Просто многие выбирают его для тех проектов, где он совсем не нужен.
Поясните, пожалуйста, почему вы считаете, что на скриншоте что-то плохо? Память на вашем устройстве не закончилась, своп не задействован. Зачем ещё вам память, как не для ускорения работы ваших приложений?
Я купил недавно миникомпьютер, чтобы установить туда часть приложений, которые раньше были локально на ноуте - вебсервер, MySQL и другое
Для того чтобы разгрузить рабочее место для более комфортной работы
Памяти в моем ноуте до предела уже - 20 Гб
90% по памяти я достигал часто
Сейчас полегче
Браузеры умеют выгружать из памяти вкладки, которые не используются прямо сейчас. Этот механизм должен работать и в Brave, и в VSCode. Когда переключаетесь на давно открытую вкладку в VSCode и она моргает так же, как впервые открываемый файл - это вот оно.
Веб-технологии, безусловно, дают какой-то оверхед. Просто мерять его потреблением памяти в ненагруженной системе некорректно, это переупрощение. Я не говорю, что у вас не было проблем или они были незначительны, но, возможно, дело не только в веб-технологиях, но и, например, в том, как ОС выделяет память.
Скажем, когда я запускаю на JVM сервер майнкрафта, он сразу занимает выделенные ему 4гб, крешится, если при запуске система их не предоставила и никому не даёт этой памятью пользоваться, даже если сам потребляет только 400мб в моменте. Эгоистично, но никакие другие приложения ему точно не помешают.
Это просто особенность реализации на JVM.
С тем же успехом, для БД на C вы можете использовать HugePages с таким же подходом.
Да, разумеется. Я говорю только о том, что приложение может запросить необходимое и гарантированное количество памяти, такая стратегия тоже существует, а может запрашивать необязательную память условно "на кеши". И когда свободная память кончается, какой-то механизм должен её высвободить и решить, кому кеши нужнее. Если у вас что-то тормозит из-за нехватки памяти, и при этом браузер занял 3гб и не отдаёт - вероятно, этот механизм работает неидеально, потому что вообще-то браузер это делать умеет.
и никому не даёт этой памятью пользоваться, даже если сам потребляет только 400мб в моменте.
Да, дефолтное поведение JVM довольно эгоистично, жрём всё что есть, и никому потом не отдаём. Как фиксить первое все в курсе, -Xmx. А вот про второе инфы меньше, но оно тоже фиксится :)
-XX:MaxHeapFreeRatio=10
-XX:MinHeapFreeRatio=2С этими флагами JVM будет поддерживать объем незадействованной кучи в пределах от 2 до 10%. Когда станет слишком много — вернёт системе
P.S. да, эти флаги я раскопала для тюнинга сервера майнкрафта. Оптимизаторы под Fabric сократили потребность в раме до 400-500 метров, но только во время нормальной работы, старт же требовал больше. И меня жаба (*badum-tss*) душила отдавать память (которой на VPS и так было не сильно много) тупо простаивать
Зависит от проекта. У меня в средней VS Code занимает 400 МБ ОЗУ. Тот же PhpStorm не открывая проект уже 560 МБ занимает.
Возможности HTML/CSS по описанию интерфейса скорее всего обгоняют все десктопные GUI библиотеки вместе взятые
Не согласен. Это не так.
какая есть причина НЕ использовать веб стэк на десктопе?
Я, например, пока не видел вменяемого софта с Web-GUI который хотя бы фукциональность оснастки ADUC для mmc повторил, например.
Видимо, есть ограничения у web-gui по сложности и удобству получаемого результата?
Я не думаю, что у web-gui есть ограничения. Возможно просто у создателей софта не было желания/резона заморачиваться?
Ограничения, наверное, всё же есть. Набор стандартный базовых элементов и их стандартное поведение.
Стандартный tree view с предсказуемым взаимодействием с пользователем имеется или каждый раз надо искать стороннюю реализацию или писать самому?
у создателей софта не было желания/резона заморачиваться?
Итого: творить простую дизайнерскую дичь есть желание, а сложный, но строгий и функциональный интерсейс - нет.
Иногда конечно получаются хорошие продукты на такой платформе. Тот же VSCode. Хотя и там местами неприятно попахивает веб-подходом.
Не согласен. Это не так.
Это так! Многие, даже фронтенд-разработчики, не представляют насколько мощным инструментом проектирования интерфейсов является современный CSS. И используют JS там, где спокойно (и проще, и быстрее) справится CSS.
Да что там... Одни медиа-запросы чего стоят! Пока десктопные GUI используют фиксированные размеры интерфейса, CSS давным-давно, с помощью нескольких строк кода превращает всё это в автоматом адаптированный под любой размер экрана, интерфейс.
Web-GUI который хотя бы фукциональность оснастки ADUC для mmc
Я не думаю что когда-либо увидите ибо проприетарщина и всякие inerb касательно безопасности всплывут.
Возможности HTML/CSS по описанию интерфейса скорее всего обгоняют все десктопные GUI библиотеки вместе взятые
Это просто физически невозможно, так как броузер является десктопным приложением и может только то, что ему позволяют десктопные GUI.
Переносимость кода на все возможные платформы и разрешения экрана
Велика гора Фудзи, но и она покажется лишь жалким холмиком по сравнению с горой обещаний о свободной переносимости кода на все возможные платформы.
Практически бесплатная веб-версия приложения
Только в случае если приложение задумано для работы в интернете (чатики, соцсети и им подобное).
Чтобы сэкономить лишние 200Мб оперативной памяти?
Вот емакс и хромиум ниже. В емаксе открыто 500+ (более пятисот) файлов. В Хромиуме открыт один ms teams. В колонке VIRT указана запрошенная приложением виртуальная память в Кб: емакс выделил чуть меньше 900 метров, тогда как хромиум запросил 1,1 Гб.
Предлагаю эксперимент, запустите vs code, откройте там 500 файлов и посмотрим какая будет экономия.
Это просто физически невозможно, так как броузер является десктопным приложением и может только то, что ему позволяют десктопные GUI.
Весь рендер непосредственно html страницы осуществяются специализированными движками (например Webkit), как правило с аппаратным ускорением видеокарты. К обсуждаемым десктопным GUI это не имеет никакого отношения. По вашей логике браузер (а значит и электрон) является десктопным GUI, а значит и проблемы, описанной в статье нет
Вот емакс и хромиум ниже
Давайте еще сравним игру на UnrealEngine и стандартный виндовый блокнот. Вы хоть для сравнения выбирайте программы одного класса
Весь рендер непосредственно html страницы осуществяются специализированными движками (например Webkit), как правило с аппаратным ускорением видеокарты. К обсуждаемым десктопным GUI это не имеет никакого отношения.
Любое другое десктопное (допустим wayland) приложение точно так же может отрисовывать используя ускорение видеокарты. И нарисовать может тоже самое. Некоторые (как минимум, GTK) даже используют CSS.
По вашей логике браузер (а значит и электрон) является десктопным GUI, а значит и проблемы, описанной в статье нет
Нет, не так. По моей логике, всё что можно нарисовать броузером, можно нарисовать и не броузером. По-этому проблема поднятая автором лежит в экономической плоскости, а не в технической.
Вы хоть для сравнения выбирайте программы одного класса
Я предлагаю сравнить с vscode. Мой хромиум просто случайно вместе оказался. Откройте 500 файликов и поделитесь результатом.
емакс и хромиум
игру на UnrealEngine и виндовый блокнот
Мне очень нравится, как эти две строчки сопоставляются. Куда уж там хромиуму до вершины софтостроения :D
К виртуальной памяти относятся в том числе смапленые файловые страницы, которые в случае чего как были на диске, так туда и вернутся. Обычно реальное понятие о жоре дает столбец RES(ident), и там у вас разница вообще в два раза))
Я кстати могу показать скриншот хтопа, как мелкая программка на хаскелле имеет терабайт (дада, 1024 гигабайта) в виртуальной памяти, и при этом реально заняты считанные мегабайты. На сервере, где терабайтом нигде и никогда не пахло)
Так вы откройте видеопоток в емаксе и сравните, чо уж там.
У меня vs code из-под WSL запушен, так что там есть серверный процесс и клиентский. Думаю можно их вместе считать. За время открытия файлов память не существенно выросла, открыл около 500. Итого чуть больше 800 мб
Ну, не знаю, что у вас за магия. Я специально поставил даже VS code и открыл 80 файлов примерно. Плюс он сам нашёл гит и сам предложил поставить расширения для С/С++. Расход резидента уехал за 2 гига
Расход резидента в емаксе всё ещё 350 метров. Экономия 1,7 Гб.
Я знаю что у меня в vscode линтер притекает, и в какой-то момент он может отжирать вообще всю свободную память, после чего приходится перезапускать сервер eslint. Возможно и другие плагины могут себя похожим образом вести. Короче проблемы есть. На скрине же я просто открывал файлы, без работы с ними, и каких-то просадок по общему потреблению памяти не увидел. Да и даже то что на скрине, могло легко гулять +/-50 мб, в результате каких-то внутренних изменений.
Отключил расширения:
И перезапустил
Стало лучше, но не сильно. Третий снизу процесс сначала занял чуть-чуть памяти, но усиленно работал 4 минуты и дожрался до гига.
Правда, в данном случае винить Electron в жоре смысла нет - потому что language server'ы написаны не на Electron/JS, а на нативном коде,
Во-первых, сами авторы рассказывают о языковых серверах с использованием Node. Во-вторых, по опыту, нерациональное использование памяти как раз более характерно для систем со сборкой мусора. По-этому если есть часть на нативном коде (кроме golang) и часть на java/js/python/и т.д., то перерасход памяти будет чаще во второй части
Важно не сколько приложение отжирает в конкретный момент времени, а сколько оно может вернуть системе обратно при необходимости
Это всё конечно очень специфично для конкретной системы, ситуации и приложения. Но в целом, для обычного пользователя, важно не то сколько приложение использует памяти и как именно, а то, на сколько быстро работает приложение. Если приложение должно постоянно мотаться по разным концам памяти, то оно будет работать медленно. Если оно должно периодически остановливаться, чтобы собрать мустор, пользователь не будет счастлив. Потому что придётся постоянно перегружать кэши процессора непредсказуемым образом. Загрузка одной страницы кэша это, пожалуй самая дорогая операция, которая есть в процессоре. Если памяти занято много, то у процессора не будет возможности предсказать, какую страницу загрузить дальше.
Не совсем понял, причем тут кеш-линии и компактность в виртуальном адресном пространстве. На первый взгляд, эти две вещи не связанные.
Я ниже уже приводил пример, как благодаря жору памяти браузеры могут ускорять многие операции в сотни раз
Никто и не спорит, что есть ситуации, когда большое потребление по делу. Кэширование страниц — одна из таких ситуаций.
Опять же, сборка мусора в этом плане имеет два существенных преимущества. Во-первых оно позволяет отсрочить высобождение памяти (с запуском всех необходимых финализаторов/деструкторов), и делать это не тогда когда юзеру необходима максимальная отзывчивость от приложения
Такое поведение требует довольно тонкой настройки сборщика мусора. Я такого вживую не видел
Во-вторых, рантаймы со сборщиками мусора обычно могут во время сборки мусора осуществлять дефрагментацию памяти
Мне, как и комментатору ниже не вполне ясно, в чём ценность дефрагментации памяти. Ну кроме очевидного небольшого улучшения работы кучи.
Ещё сюда можно добавить развёртывание VSCode на сервере и удаленная работа хоть с планшета. Мощный сервер компилит проекты. И не надо на все свои железки кучу софта ставить. А ещё наверное можно прямо в контроллеры с линуксом его встраивать и делать удалённую отладку и компиляцию прям в устройстве. Я сам не пробовал но сборка для арм/разбери есть.
В целом, идея хорошая, на HTML/CSS/JavaScript писать GUI действительно проще и быстрее. Но всё портит движок Хрома — это просто монстр, в которого напихали поддержку 100500 "стандартов", и продолжают это делать, утяжеляя и усложняя его работу.
Или использовать другой движок, как это сделали в MS Teams Work Preview ?
Поправьте, если я что-то не так понял. Но насколько я знаю, дело не в V8.
V8 - это, грубо говоря, интерпретатор JS. Он быстрый. Даже очень.
Дело в DOM. DOM - фундаментально медленный. Стилизация DOM требует CSS, который тоже фундаментально медленный. И всё это великолепие требует наличия в роли GUI-библиотеки целого браузера, который тоже отнюдь не легковесный ибо тащит в себе огромное количество разных (порой вообще не нужных вашему приложению) штук.
Это ещё про WebAssembly ни слова не сказано.
Есть мнение, что пользователям не нужен быстрый софт, потому что они якобы «ленивы и туповаты». Мол, пипл «схавает» всё, что дадут.
Тут есть три аспекта:
нормальные обычные люди не хотят разбираться с каким-то там софтом. Пользуются тем к чему привыкли если это не стоит слишком много
низкое быстродействие софта со временем компенсируется увеличившимся быстродействием железа. Пока железо будет ускоряться, ситуация не улучшится
в корпоративной среде, люде не пользуются тем, что им нравится. За них решает кто-то другой. А тот кто решает, может не пользоваться этим сам. Через это производителям выгоднее "укреплять бренд", а не улучшать быстродействие. Улучшенное быстродействие дорого стоит и плохо продаётся
Как раз сегодня читал на хабре про MUMPS (англ. Massachusetts General Hospital Utility Multi-Programming System). Интересная система по быстродействию и требованиям к ресурсам, но никому не нужна.
они использовали Xcode
кто бы сам Xcode попрофилировал. sucks since 2003
Забавно, что комьюнити объявило Delphi устаревшей и пошло по пути нагромождения немыслимого бесполезного кода. Зато теперь, что бы открыть 3 приложения на пк, 16 Гб оперативки уже не хватает...
Приложения на fmx тоже достаточно компактные, если не использовать штатные, растровые стили, а использовать или делать векторные. Иначе получается, что в ресурсах по умолчанию хранится как минимум по 3 битмапа с разными размерами по несколько мегабайт под каждую версию платформы. Например, для вин7, 8 и 10. А если делать на векторе, то их можно убрать.
По прожерливости опять же зависит от растровых стилей и, конечно же, от количества всяческих картинок и прочего, что преобразуется в текстуры. В остальном, потребление скромное.
Чем больше ОЗУ в системе доступно, тем больше программа будет использовать
Программа будет использовать столько ОЗУ, сколько она требует для работы. А именно, зависит напрямую от того, какие и сколько переменных в программе и подключаемых динамических библиотеках. Программа, требующая 100мб будет требовать 100мб как на компе с 4гб, так и на компе 32гб.
А то, о чем вы говорите - называется своп и регулируется самой ОС
потом на каком-нибудь другом сайте понадобится тот же самый Angular или React или еще какая-нибудь либа той же версии с того же CDN, и все уже будет готово заранее.
Подобное поведение кэша не так давно изменилось. Теперь каждый сайт должен тянуть сам все ресурсы с CDN независимо от того использовались ли ранее эти ресурсы на других сайтах.
https://www.stefanjudis.com/notes/say-goodbye-to-resource-caching-across-sites-and-domains/
https://developer.chrome.com/blog/http-cache-partitioning/#how-will-cache-partitioning-affect-chromes-http-cache
Если это так, то и нет смысла держать в памяти скомпилированный и оптимизированный код.
И вы описали именно "то самое" исключение, когда в программе специально заложено такое поведение. А ещё, мы можем в программе сделать AllocMem все свободной памяти и это тоже будет "противоречить" моим словам, потому как: "чем больше памяти, тем больше она потребляет". Но это не отменяет того факта, что сама по себе программа, внезапно, без ведома программиста занимает памяти больше тем, чем больше её свободно.
Другими словами, если ты сам это не сделаешь - этого не будет.
"Устаревший делфи" позволяет набросать софтину для решения широкого спектра задач на коленке любому еникейщику, раздать ее коллегам, и она будет работать у всех и сразу. Веся при этом несколько килобайт и не заставляя устанавливать какой-нибудь net framework паровозом ради программы в пару строк. Питон в туже степь
"Буллшит. VCL-приложение даже с одной пустой формой без компонентов весит сотни килобайт, а современные ", - да вы правы - 400 кб в среднем для делфи. По современным меркам вообще ни о чем.
Мало того, этот бинарник можно было обработать чем-то вроде UPX, и тогда размер сокращался ещё раза в три.
Вам правда настолько важен размер приложения? Я понимаю, когда разница существенна и приложение занимает значительный процент от места на диске.
Но начиная с некоторого момента разница в потреблении на порядки перестает быть важной. Допустим, какая разница между программой размером в 40Кб и в 4Мб? В 40Мб?
Аналогично и с потребляемыми ресурсами. Предположим, мне надо написать простенький скрипт. Код на условном питоне напишется за час, будет отжирать 20Мб памяти и тащить с собой рантайм.
Код на условных С++ будет отжирать 2Мб памяти.
На машине даже с 8Гб памяти, что уже мало в наши дни, разница околонулевая.
Даже сотни килобайт против сотни мегабайт (ожидаемый размер почти любого электро-бейзед приложения) -- это тысячекратная разница.
В качестве примеров "правильного" софта автор привел множество консольных утилит зачем-то и еще чуть-чуть гиковских программуль, у которых три пользователя на весь мир. Как бы не мечталось поклонникам минимализма, успешно продавать массовому пользователю "редактор от Роба Пайка, написанный под вдохновением от ed" или какой-нибудь dwm не получится, это никому не нужно, как бы то не представлялось ужасным любителям меряться мегабайтами, воскрешать найденый на помойке 286-й IBM и гордиться до деспамятсва своим хакерскими талантами, "непотреблядсвом" и отвращением к "свистоперделкам". Давайте взглянем правде в глаза и честно признаем, что классические тулкиты типа Qt, GTK или какого-нибудь Tcl/Tk не могут обеспечить годного по мнению широкого пользователя look-and-feel. Браузер побеждает не потому, что JS проще разрабатывать или быстрее или универсальнее с точки зрения управления проектами, глупости это всё. Браузерные приложения просто интереснее выглядят для пользователя. Можно ли делать подобное, на Qt? Можно, только вы изобретёте еще один браузер. Современный Qt это QML + CSS + JavaScript. Чем это лучше связки HTML + CSS + JavaScript? Да ничем, все попытки сделать по-другому только лучше приводят к изобретению припроетарной тройки Язык Разметки + Язык Стилей + Скриптовый ЯП. Микрософт со своим WPF/SilverLight изобрели XAML (который просто XML на стероидах, который ничем не лучше HTML5) и прикрутили сбоку С# по ходу лишив его преимуществ статической типизации, джависты наизобретали всяких мало работоспособных фреймворков типа Swing, и по итогу рендерят всё в веб и не парятся, GTK весь обмазан CSS, Qt превратился просто в JavaScript даже не претворяется. Такова реальность - любой графический тулкит превращается в браузер, и нафига он нужон если браузер уже есть.
Автор статьи как и большинство комментаторов, похоже, застряли где-то в начале 2000-х. В 2023 же планки оперативной памяти на 64ГБ стоят $150-200.
Многие из перечисленных приложений необходимы в основном для работы. И если у кого-то (или его работодателя) нет вышеозначенной суммы на апгрейд, то пожалуйста пользуйтесь suckless альтернативами или настройте Emacs с плагинами.
Индустрия не будет делать крюк на бог знает сколько тысяч человеко-часов и поддерживать зоопарк различных версий Windows, MacOS, GTK и Qt чтобы некоторые труъ (на словах) программеры могли "пограчевать" на своих "жигах" еще лет 10.
Если вам так больно - портируйте сами, в свободное от работы время, и продавайте - озолотитесь, но это не точно.
А станут, эти планки?
Есть среднестатистический аппарат у которого предел, ну пусть в 12 гиг.
Он вполне себе справляется с рабочими задачами, какого -нибудь контенщика, администратора ИМ, сеошника, ПМа. Нужное подчеркнуть
Тут выкатывают очередное обновление какого-нибудь утилитарного софта, где менеджеры, которым надо оправдывать свое существование на рабочем месте, напихали красивых кнопочек, потому что это круто, а разрабы запилили это на электроне, потому что это быстро.
"Планки ж на 64 гига стоят 200 баксов!!!", - говорили они....
Только теперь всем надо бежать в ближайший магазин искать куда бы воткнуть эти планки(((
среднестатистический аппарат у которого предел, ну пусть в 12 гиг.
Среднестатистический - это 16. Нормальный - 32.
Какие 12 гиг когда только браузер с 20 вкладками может и 10 отъесть на сегодняшний день?
Он вполне себе справляется с рабочими задачами
Значит не справляется раз не тянет популярный во всем мире, а значит более чем юзабельный на среднем железе, корпоративный чатик, отъедающий где-то около гига.
где менеджеры, которым надо оправдывать свое существование на рабочем месте, напихали красивых кнопочек, потому что это круто
Пользуюсь VSCode и Slack и не заметил ни в одном каких-то лишних кнопочек.
а разрабы запилили это на электроне, потому что это быстро
Покажите класс - запилите на чистом С (или что вы считаете эталоном) хотя бы под одну платформу. В одиночку или командой на зарплате.
Только теперь всем надо бежать в ближайший магазин искать куда бы воткнуть эти планки(((
Не всем, а только тем, кто считает, что аппарат с пределом 12 гиг - среднестатистический.
Снова-таки, бедность - не порок, настраивайте и пользуйесь альтернативами.
"Какие 12 гиг когда только браузер с 20 вкладками может и 10 отъесть на сегодняшний день? ", - ну если "менеджеры" и "разрабы" добрались и туда, то может)))
"Среднестатистический - это 16. Нормальный - 32. ", а лучше 64.
Каждому контенщику по ноуту с 64 гигами аперативы!!!! так говорит директор в вашей конторе?
"Пользуюсь VSCode и Slack и не заметил ни в одном каких-то лишних кнопочек. ", - я бы рекомендовал взять выборку более чем из одного человека одной отрасли))
"Не всем, а только тем, кто считает, что аппарат с пределом 12 гиг - среднестатистический. ", - так все считают, что гиг за корпоративный чатик это перебор))
Каждому контенщику по ноуту с 64 гигами аперативы!!!!
Acer TravelMate P2 ноут на 32 гига стоит 1200 евро целиком, десктоп аналогичной конфигурации скорее всего и того дешевле.
Пруф:
Это какая-то запредельная сумма?
Какой смысл злиться на абстрактных менеджеров, продолжая кушать кактус, когда вопрос можно решить сравнительно небольшими деньгами?
так говорит директор в вашей конторе?
Директор в моей конторе говорит, что дешевле раз в три года купить такой ноут, чем тупить и срывать сроки или держать команду настройщиков suckless утилит.
Проблема в том, что похоже слишком многие контентщики под ноутами понимают исключительно эпплобуки и не воспринимают ничего другого. А потом вдруг оказывается, что апгрейдиться что-то до хрена дорого.
Проблема, в том, что вы изначально ведете расчеты в единственном числе. У нас, например, контенщиков человек пять. Есть еще всякие сеошники, пмы, и прочие протиратели штанов. Ну пусть будет итого 10 человек. Вы предлагает потратить 12 тыс евро только потому, что корпоративный чатик стало модно писать на электроне?
Да хоть на 1000 человек. 1200/36 это 33 евро в месяц на человека. Неужели сотрудник не отбивает эти деньги?
Корпоративная лицензия слака стоит 11.75 евро на пользователя в месяц. Если слак возьмется писать нативные клиенты под все платформы, то, грубо говоря, это будет 11.75хN, где N - количество платформ, которых как минимум три. Вот и считайте.
Это при том, что вышеозначенные приложения на электроне - далеко не лидеры по потреблению памяти на компьютере сотрудника.
Индустрия не будет делать крюк на бог знает сколько тысяч человеко-часов и поддерживать зоопарк различных версий Windows, MacOS, GTK и Qt чтобы некоторые труъ (на словах) программеры могли "пограчевать" на своих "жигах" еще лет 10.
В результате, мы имеем постоянное отмирание всё новых и новых технологий. Когда выбрасываются в утиль мегабайты программного кода.
Между прочим, если бы разработчики озаботились бы настоящей поддержкой разного рода ОС, то они довольно скоро пришли бы к необходимости создавать не отдельные конкурирующие друг с другом ОС, а ОС различного назначения (а, значит, и архитектуры).
Строго говоря, ОС должна создаваться под задачу. Тут можно провести аналогию с 1С: ОС — это аналог конфигурации, где имеются свои справочники, документы, регистры и регламентные задачи. А для этого нужна технологическая платформа. Вот, за всеми достижениями последних тридцати лет как-то здорово затушевалась необходимость создавать такую платформу. По сути, развитие информационных технологий проихсодило куда-то вбок, а изначальный вектор был утерян.
Если вам так больно - портируйте сами, в свободное от работы время, и продавайте - озолотитесь, но это не точно.
Честно говоря, звучит немного грубовато.
Прошу прощения за грубость. Просто статьи о том как приложения разрастаются и тормозят, а индустрия катится в тартарары уже набили оскомину.
Текущее положение дел в индустрии обусловлено объективными экономическими причинами, которые следуют из фундаментальных законов мироздания.
Да, приложения жрут памяти больше, чем раньше (но и умеют больше). Что же делать? Варианты ответа:
А: Долго и пафосно рассуждать о том, что кто-то другой должен чем-то озаботиться и сделать этот мир лучше
B: Потратить немного денег на апгрейд
C: Перестать пользоваться приложениями
D: Создать свое идеальное приложение
Т.е вашими словами, мне для выполнения своей работы нужно:
Ось для 1с
Ось для веб дев
Ось для медиа
Ост для поиграть
3d modelling and render
Так?
Helloworld на Tauri весит 6Мб и потребляет 60Мб памяти. По мере усложнения интерфейса сильно не растёт, если не пытаться втащить туда Вуй какой-нибудь ( а втаскивают). Правда, на винде требует WebView2 который предустановлен только на виндоусах, обновлённых за последние 3 года, и выкинут в разных говносборках. Отдельный пакет с WebView2 весит 140Мб.
Если говорить принципиально, то нужно говорить о подходах (как таковых) и об архитектуре.
Понятное дело, что, если что-то активно развивается (WEB), то по многим вопросам можно достигнуть довольно приличных результатов. Но это развитие происходит (во многом) за счёт недоразвития настольных приложений. Просто, в своё время, WEB оказался точкой для простого входа (на рынок) и быстрого развития технологий. Но... всё же могло быть по другому...
Лично мне было бы гораздо удобнее иметь (например!) одно настольное приложение для работы со всеми интернет-магазинами. Спрашивается, почему такое невозможно? Ведь, никто не создаёт такое приложение. И никогда не будет. Хотя... что мешает это сделать? Для этого нужно представить каждый магазин как набор сервисов и API. Мне нужен набор типовых форм для работы с магазинами, а вместо этого, я получаю ворох различных сайтов, на каждом из которых реализуется какой-то один подход. Потом, ещё эти подходы меняются. Поскольку каждый магазин всегда хочет идти навстречу потребителю и в ногу со временем. Если бы на компьютере было бы настольное приложение, я мог бы выбирать магазин, выбирать способ работы с этим магазином, мог бы сохранять свои действия/покупки/замечания в локальной базе данных и, кстати, иметь возможность предъявить полный и точных лог, на случай каких-либо инцидентов. Настольному приложению нужны только порты, сокеты, удалённый вызов процедуры и удалённые сервера, организованные по единой спецификации и выдающие результаты, как СУБД. Здесь нужен только оператор магазина, поскольку, все вопросы, связанные с пользовательским интерфейсом решаются в операционной системе.
С архитектурной точки зрения, WEB передал те задачи, которые должны были бы решаться в ОС, сторонним разработчикам. Отсюда и проблемы. Сейчас, конечно, никто не будет загонять обратно в тюбик. Но, возможно, однажды, проблема будет осознанна, и решение будет предложено.
собственно одно настольное приложение и есть - браузер называется
а что мешает так сделать? наверно то, что апи надо как-то получить от каждого магазина. И вот это "апи" и есть наш интернет
Совсем не так. Настольное приложение — это приложение, которое построено при помощи компонентов, реализованных в самой операционной системе. Браузер поддерживает некоторую объектную модель документа (ОМД) и обменивается с сервером, по сути, текстовыми сообщениями, которые браузером специальным образом интерпретируются/порождаются (на основании принятой ОМД). В своё время, это казалось очень продуктивным, иметь некий открытый стандарт и единую программу (браузер), которая следует этому стандарту. Не спорю. Это привело к бурному развитию и распространению информационных технологий. Но у всего есть оборотная сторона. Об этом я и толкую.
Настольное приложение имело бы (как это раньше и делалось и, наверняка ещё где-то делается) некий канал (или порт), по которому распространялись бы байты всевозможных данных. В обычной ситуации, когда используются файл-серверная или клиент-серверная архитектуры, приложение при помощи специализированных компонентов посылает запрос к СУБД, которая умеет выполнять эти запросы и возвращать наборы данных требуемого вида. Затем, эти наборы отображаются теми же специализированными компонентами. Что мешает использовать эту же схему в интернете? Вот в чём главный вопрос.
API — это набор спецификаций, согласно которым каждый магазин (библиотека, кинотеатр, площадка для проведения конференций и т.д. и т.п.) реализует некоторый типовой набор функций, открывает определённые порты (для обмена данными/метаданными/командами) и поддерживает определённый стандартизованный протокол обмена. Архитектура общих (для всех участников рынка) интерфейсов. Внутри магазина должен "крутиться" сервер, способный поддерживать специфицированный (и сертифицированный) интерфейс. И говорить нужно именно в плане архитектуры базы данных: вот такая архитектура БД позволяет то-то и то-то, а для чего-то большего нужна другая архитектура. Выбранная архитектура могла бы гарантировать определённую функциональность, что исключило бы всякую "отсебятину" при построении баз данных.
А уже пользовательский интерфейс должен быть под полным управлением самого пользователя. Это относится и различным способам отображения одной и той же информации, и к различным способам осуществления одних и тех же действий. (Впрочем, всё это нужно раскрывать на практических примерах, на что, я надеюсь, дойдут однажды руки.)
Настольное приложение имело бы (как это раньше и делалось и, наверняка ещё где-то делается) некий канал (или порт), по которому распространялись бы байты всевозможных данных.
я совсем не разработчик десктопных систем, но браузер делает ровно тоже самое, получает и отправляет байты, реализует типовые функции
Ещё раз. Браузер занимается интерпретацией (по своей сути) текстовых данных. Плюс всякие обёртки, вроде JSON, которые, опять же, по своей сути, пытаются впихнуть в WEB, то, что могло быть гораздо проще, прозрачнее и безопаснее реализовано старыми подходами. Например, CORBA (Common Object Request Broker Architecture).
я мог бы выбирать магазин,
Вот и ответ на ваш вопрос. Ни одному магазину это совершенно не нужно
Что же Вы хотите сказать своим "ответом"? Что магазину нужно, чтобы Вы пользовались только им? Но, так, это совершенно другой вопрос! Или, всё-таки, этот? Встречают-то, ведь, по одёжке! А сайт — это и есть одёжка.
Есть, однако, другая сторона вопроса: зачем мне (и Вам) сайт магазина? Можно ли обойтись без сайта магазина?
И ещё один (дополнительный) вопрос: что мне делать, если я нашёл очень хороший сайт магазина и хочу использовать его для работ с другими магазинами? Почему я не могу применить удачный дизайн в другом месте, где есть более нужные для меня товары, но, скажем так, не очень удачная навигация?
Не будет ли проще иметь возможность самому выбирать дизайн сайта, так сказать, на стороне ОС (то есть — на своей стороне)?
Вы спрашивали, почему не делают. Я вам назвал причину. То, что вам при этом неудобно к делу не относится. Вам и должно быть неудобно пользоваться многими магазинами и удобно одним конкретным. Конечно, каждый магазин считает, что этим конкретным должен быть он.
Можете попробовать сделать сами. Но данные вам вряд ли просто так кто-то даст за спасибо, а ведь именно за ними вы и идете на сайт магазина. И кому же это понравится, если информацию (на сбор и каталогизацию которой потрачены усилия) вы будите брать в одном магазине, а покупать — в другом? Тот другой просекет фишку и будет давать вам Ид. товара — цена, а что это такое ищите сами, вон, добрые самараитяне из соседней вкладки уже вам все сделали.
Если дело только в дизайне, то браузеры позволяют навесить на любой сайт собственный. Но "не очень удачная навигация" — это скорее всего не только дизайн
Язык это просто инструмент. Если один язык позволяет эффективно решать задачи для разных платформ, это отлично. Никто не говорит про Юнити что игры собираются под N-платформ включая ВЕБ.
Все проблемы с производительностью идут от архитектуры. Или ошибки кодирования по части эффективности алгоритмов. Этим ошибка подвержены все языки, но на вебе это заметнее поскольку язык не компилируемый.
Так вот, вместо того чтобы говорить "Электрон-электрон", вероятно, надо развивать культуру программирования, поднимать подготовку кадров, и тогда и софт нормальный будет.
В JS программистов очень много, думаю что сильно больше чем в остальных ЯП, и порог входа крайне низкий, типизации мало (TypeScript вещь, но до того же C# далеко, насколько я понимаю), свободы в реализации решений очень много, вот на выходе и получаем море ошибок.
Вобщем, надо просто поднимать уровень кадров и инструментов, вот и всё.
Ну с примерами вы конечно из крайности в крайность. Консольный музыкальный проигрыватель и торрент-клиент - демон — это, конечно, быстро, но крайне неудобно. Я бы такое как домашний пользователь использовать не стал: разве что на сервер для чего-нибудь повесить и забыть.
С одной стороны да, нативные приложения в основном быстрее, удобнее и лучше интегрируются с системой. С другой стороны, когда web-приложение разрабатывает for-profit компания и я не являюсь её ЦА, у меня есть шанс запустить её на своей платформе, которую они официально не поддерживают. Например, тот же MS Office хоть и кастрированный в web'е, но благодаря ему я могу иметь Линукс на корпоративном устройстве и это не сильно сказывается на моей работе. Понятно, что в идеале должы быть альтернативы получше, открытые API и так далее, но в ситуации, когда ты обязан использовать софт, а разработчикам на тебя плевать, то web-приложения становятся преимуществом.
Когда начинаешь размышлять на эту тему, то становится совершенно не понятным, почему всё необходимое не реализуется на уровне самой операционной системы? Почему нельзя сразу достать "из коробки" готовую к полноценному использованию систему, автоматизирующую все требуемые операции?
Понятно, что в идеале должы быть альтернативы получше, открытые API и так далее, но в ситуации, когда ты обязан использовать софт, а разработчикам на тебя плевать, то web-приложения становятся преимуществом.
Web-приложения становятся единственным вариантом.
Тут, ведь, вопрос в чём. Нужна общая для всех шина данных, инфраструктура. А её никто не хочет строить. Она никому не нужна. Она идёт поперёк всех бизнес-моделей. Вы, например, представьте, что будет сделан единый стандарт оформления электронной документации. В этом случае, можно будет скачивать готовые спецификации и домашних условиях и при помощи простых алгоритмов реализовывать документооборот. Пишете статью? Просто "скармливаете" её своей системе и посылаете в редакцию, где, опять же своя система, которая автоматически разбирает статью на части и формрует весь требуемый набор данных для последующей публикации. Меняется законодательство? Скачивается новая версия спецификации, и алгоритм отрабатывает...
ОС могла бы уже "из коробки" быть чем-то вроде MS Office и 1C в одном флаконе. А в интернете были бы только данные и доступ к этим данным. Вместо этого, имеем кучи разношёрстных сервисов, сайтов, технологий, языков и прочих многоэтажных конструкций.
"Почему десктопные приложения работают на веб-платформе?" - очевидно жеж.
- Первое и самое главное - можно сделать красиво, навешать анимаций, реализовать любые дизайнерские идеи без танцев с бубном
- Веб разработчиков достаточно много
- Научиться заворачивать свои наработки по сайту в Electron намного проще, чем научиться создавать десктопные приложения другими способами
- Дешево
Так что свернули мы как раз туда.
Нет времени читать все комменты. Надеюсь, что стариковское брюзжание выслушают. Я учился работать в прикладных программах под MacOS Classic (начало 90-х). Сравнительное управление компом под Win 3.1 показало, что идеология Apple была очень правильной. На Винде (возможно даже уже 98-й, не помню) я даже купленную звуковуху тогда не смог установить без помощи более опытных товарищей. Общий объём требуемых знаний для таких операций под Windows был в разы выше, чем под Classic (о Юникс-подобных в этом случае лучше ничего не сказать). Эппловская система позволяла простейшему юзеру вручную бороться с вирусами. Если что-то втыкал в комп, оно определялось и работало "с колёс" в большинстве случаев, вся сложность с доп оборудованием часто заканчивалась напрочь после нажатия кнопки "Install" из комплектного софта.
Собственно я о товарищах врачах, писателях, юристах, менеджерах и всяких там учителях начальных классов, да дизайнеров и архитекторов, имя которым легион. Им комп нужен как штука, которая ПОНЯТНА, требует МИНИМУМ сил для освоения и при этом работоспособна и относительно безопасна. Точка. У них своих дел - дай Бог, чтобы хватало 24 часов в сутки. И знаний, тонкостей своей профессии - вагон с тележкой. И комп нужен сейчас и здесь: лечить, учить, проектировать, разрабатывать, планировать...
Думаю, что ЛЮБАЯ система, позволяющая интуитивно добиться быстро нужного результата в СВОЕЙ работе, будет востребована. И всем названным спецам будет глубоко до фени - по какому-либо разработческому фэн-шую оно написано или нет. А система не интуитивная,и/или не работающая нормально - будет проклята за убитое на неё время.
ИМХО это важно для проектирования. (робко) Ведь разрабы работают для того, чтобы в итоге этим пользовались другие люди?
Не совсем согласен с тем что написано про эти две ОС и совсем не согласен с тем, что ниже.
Да, пусть пользователи, которые не имеют достаточно знаний, чтоб сделать всё правильно и эффективно, делают "как могут", Но! Разве речь о них? Разве здесь не обсуждается инструмент для разработчиков, а не для домохозяек или врачей?
И нет, разработка десктоп-приложения средствами того же электрона - это не удобнее, чем многие другие средства. Его появление следствие огромного кол-ва людей, которые хоть как-то знали JS и не хотят изучать подходящие инструменты и языки.
По моей практике (в основном полиграфический дизайн) существует широкий ряд задач, которые не могут оправдать доскональное изучение сложных инструментов. В теории много знать и уметь - правильно и хорошо. На практике - либо вы берёте и делаете в разумный срок КАК МОЖЕТЕ что-то работающее, либо это сделают другие.
Да, конечно, человек имеющий хорошую школу и большой опыт решит задачу правильнее и лучше. Кто спорит? Но когда обратились с небольшой задачей к новичку или середнячку, ему надо просто получить рабочий результат.
Ещё один момент - опытный зубрррр берёт допустим 1000 в час (мегачасы на освоение технологий, опыт, качество изготовления надо окупить, имя своё...), а середнячок - 200 в час (работу бы получить в руки). Для многих заказчиков важно "скока за ведро".
Подозреваю, что в среде разрабов проблемы примерно те же.
Т.е. задачу нужно решать теми инструментами которые ты знаешь, а не теми, которые предназначены специально для решения этой задачи?
У нас четко разделены две области. Веб и Десктоп. И мы понимаем, чем они отличаются.
В первой мы используем возможности конкретной программы - браузера, его API, как в 1С.
Во второй, мы можем использовать нативный код, без посредников. Мы можем использовать нативный интерфейс ОС (не обязательно). И всё это позволяет создавать очень быстрые приложения. Выжимать максимум производительности компьютера.
Мы ведь не будем просить человека, который знает только плюсы сделать простой сайт, только по тому что он берет за эту работу не 1000 в час, а 200, верно? Тогда с чего, мы должны просить веб-разработчика сделать софт на десктоп, хотя он не умеет делать софт на десктоп? И вот он не умеет делать софт на десктоп, но кто-то взял и сделал так, чтоб можно было кое-как но делать софт на десктоп средствами веб разработки.
В итоге мы получаем увеличенный размер приложения в десятки раз, снижение производительности в несколько раз, не нативный интерфейс, чрезмерное потребление памяти. И всё это только потому, что для каждого такого приложения мы запускаем ещё один свой отдельный браузер.
Не обязательно досконально изучать инструмент, чтобы на нём писать. Но не все инструменты одинаково хороши для разных задач.
Почему десктопные приложения работают на веб-платформе?