Как стать автором
Обновить

Комментарии 378

Хорошая статья и довольно неудачный заголовок.
Я перевел заголовок оригинала буквально. Думаете, лучше было бы подобрать более подходящий по смыслу, чем сохранить авторский замысел?
Вы неправильно перевели буквально «Electron and the Decline of Native Apps»
the decline of — это упадок, падение, сокращение
https://context.reverso.net/
Это тоже верно, но мне кажется debug45 имел в виду не перевод конкретного слова, а то что Electron в названии статьи выглядит как кликбейт, потому что внутри статьи о нем совсем немного.
Возможно, но вряд ли
Ваш заголовок подразумевает типа конспирологию — кто-то решил отказаться от нативных приложений во вред пользователям. Злая воля.
Как заголовок по-английски — нативные приложения не выдерживают конкуренцию у разработчиков по сравнению с приложениями под VM. О чем, собственно, и статья.
Убедили. Обновил заголовок.
Заголовок — вообще аллюзия на классическую книгу «Decline and fall of the Roman Empire»: Упадок и падение Римской Империи.
Точно нет.
Electron and the Decline of Native Apps
Decline and fall of the Roman Empire

У них из общего — только слово «decline», если бы было «Decline and fall of native apps» — то я бы с вами согласился.
Ну так статья о том, что все кончится плохо, но пока есть надежда. Так что до Fall еще не дошло. А «Decline and Fall» — это распространенное клише.
Да и да. Но все-равно никак не связано с «Decline and fall of the Roman Empirе»
Насколько далеко от Mac-like был Word 6, но даже он был ближе, чем нынешние Google Docs, открытые в браузере Chrome. Google Docs это анти-Mac текстовый редактор запущенный внутри еще более анти-Mac веб-браузера. То, что Mac-пользователи решительно отвергли как анти-Mac в 1996 году, было лучше, чем то, что пользователи Mac счастливо терпят сегодня. Программам больше не требуется выглядеть нативно под Mac, чтобы достичь на нем успеха сегодня. Это является трагедией.

Шовинизм и разжигание межплатформенной розни. Мак-Мукс-Клан какой-то.
Как сказать, по мне классический desktop с главным меню часто удобнее, хотя б тем, что не требуется разгадывать, в какой из 1001 вкладок заспрятана кнопка с нужной функцией, в главном меню искать нужную функцию обычно несравнимо проще. Этим мне не нравится Ribbon в Windows, причём, в отличие от MacOS, в оном функции поиска по UI почти никогда нет. А про типичный Web-интерфейс мне вообще сложно что-то сказать цензурными словами, разве что само слово Web помогает делать эпитеты чуть менее явными. MacOS в этом плане до сей поры держался, но, видать, он тоже начинает капитулировать.
Само слово «web» уже становится эпитетом :(
Мак всегда был в этом месте «сдвинутым»: платформа, пропитанная с ног до головы «хождением в ногу» рекламируется как избавитель от Большого Брата… притом что как раз там разработчиков заставили ходить строем.

Нет, я не говорю, что ситуация, когда в одном редакторе (скажем в Microsoft Word) Backspace удаляет символ, а в другом (скажем Turbo Pascal 1.0) не удаялет — прекрасна и удивительна… но это ведь максимально далеко от «колебания вместе с линией Партии», которая, как раз — фирменная фишка MacOs…

Далее, знаменитое: Think Different — ага «выберите цвет своего ноута из списка в один пункт и проихводителя видеокарты из списка такой же длины» очень, ну просто очень… different.

Хотя если вдуматься то вот эта вот странная идея: «выделиться из толпы путём покупки того же, что и все» — она ведь уже столетия модой движет… так что ничего нового тут нет… но всё равно дико…
НЛО прилетело и опубликовало эту надпись здесь

Упомянуты по мне разные вещи, но вот с точки зрения пользовательского интерфейса


что как раз там разработчиков заставили ходить строем

на мой взгляд лучше, чем разгадывать очередной результат авангардного творчества в том смысле, как что в нём делается. Сам UIKit по мне пока что оставляет желать лучшего, но всё ж меняется в лучшую сторону.

Меня просто позабавили претензии на индувидуальность в системе, построенной вокруг «видения мира», условно, одним человеком — и жёсткого прессинга всех, кто не хочет быть счастливым «так же, как все».

Это не хорошо и не плохо, просто удивляет — примерно как когда жители Северной Кореи начинают рассуждать о том, что вот у них-то, дескать, настоящая свобода и отсутствие притеснений.
То есть проблема электрона не в том, что он тормозной и жручий. Не в том, что я должен запускать 25 гуглохромов для 25 приложений. Это всё не проблема, проблема в том, что он не Mac-like. Это единственная проблема, которую надо решить. А в остальном всё ок, пускай чатик занимает полгига памяти.
Очень верно подмечено.
У маководов вообще в большинстве и мышление и оценки через другое место.
Сие не есть плохо или хорошо, просто надо принять это как данность и учитывать в принятии решений.
Think different в действии.
Ага, причем что такое mac-like никто сказать толком не может. Ощущения, понимаешь, не те.
Я могу одно сказать. Если Finder — это маклайк, то ну его к чёрту, такой маклайк.
НЛО прилетело и опубликовало эту надпись здесь
Это пока таких приложений одно-два им всё равно. Когда их куча и они отправляют систему глубоко в своп — становится совсем даже не «всё равно»…
Немного потерпим, а там WASM + OpenGL позволят снова писать быстрые приложения не жрущие много памяти, используя браузер как VM.
Уходим от низкого уровня чтобы писать быстро медленно работающий код, но так как он работает медленно — возвращаемся обратно, только дополнительный слой между системой и ПО имеем…
Помять можно продать — решение проблемы mac-like-style
Имхо… А лично мне после slack, google meat и VSCode кажется, что за этим будущее. Лично меня очень подкупает (в первых двух случаях) полное отсутствие необходимости что-то устанавливать на компьютер, кроме браузера. Да и с функциональностью там полный порядок. Вопрос с бесконечными экземплярами хром решить, и, кажется, все.
А накой тебе устанавливать браузер еще несколько раз, если он с вероятностью 95 % у тебя уже стоит?
МБ потому что «браузер» — это целый пласт программ, и у меня есть альтернатива?
И, если честно, не совсем понял, при чем тут это. Я лишь выразил мнение, что веб интерфейс дорос до такого уровня, что, при качественной реализации, им вполне безболезненно можно пользоваться вместо нативных решений. А иногда он дает и некоторые преимущества в виде отсутствия необходимости что-то дополнительно устанавливать, например.
Зачем его устанавливать, если в можно просто написать 127.0.0.1:9999 и откроется твое приложение. Только все равно эти приложения какие то тормозные получаются.
Незачем:
Дублирование движка Electron в каждой программе становится значительной проблемой производительности. Вместо этого они хотят иметь один на всех экземпляр Electron вместе со своими дополнениями.

Сейчас меня вместе с shm-vadim распнут, но мне тоже очень нравятся приложения на Electron. Может быть, дело в том, что у меня достаточно мощный компьютер, но они ощущаются как более быстрые в работе, чем нативные. Загружаются дольше, чем нативные (не все), но потом работают быстрее. Подозреваю, что это иллюзия, связанная с асинхронностью/анимациями. Но работать с ними приятнее.

Это первое, а второе — большинство Electron приложений, которые я пробовал в последнее время, имеют отличную функциональность по сравнению с нативными аналогами. VSCode, Slack, GitKraken. Может, совпадение, а может — время, сэкономленное на борьбе работе с UI, ушло на дополнительную функциональность.
Еще замечу, что все указанные вами приложения – бесплатные. Разработка хорошего нативного приложения влетела бы в копеечку, и скорее всего, не отбила затраты.

Затраты бы отбились, просто прибыль была бы на целых 20 процентов меньше. Или на 10.

Если там такой запас по прибыли, это ж неосвоенный рынок — надо брать!
Вместо одного кросс-платформенного приложения вы будете писать два специализированных (или даже 3, если еще и Linux). Как это может увеличить затраты всего на 10%, если у вам понадобится содержать в 3 раза больше разработчиков?
НЛО прилетело и опубликовало эту надпись здесь

На самом деле два:



Я пользовался обеими версиями, и вторая работает намного лучше.

НЛО прилетело и опубликовало эту надпись здесь
Что толку что он запускается, если он убогий?

Я три года писал во все трекеры Tg и QT, что бы они добавили поддержку тачбара. Только недавно дело сдвинулось с мёртвой точки. 3 года(!) понадобилось команде QT что бы добавить десяток биндингов в свой фреймворк.
1) Берём QT
2) Профит, ибо у нас нативное приложение на всех платформах.
Здесь разговор не про нативность с точки зрения бинарного кода, а с точки зрения удобства пользователей. Единообразные горячие клавиши, внешний вид диалогов и меню.

Для этого понадобится писать отдельный платформо-зависимый код, а для этого нужно больше разработчиков.
Здесь разговор не про нативность с точки зрения бинарного кода, а с точки зрения удобства пользователей. Единообразные горячие клавиши, внешний вид диалогов и меню.

Тут да, но можно настроить QT так, чтобы он выглядел довольно нативно. К тому же, если правильно писать код, то все горячие клавиши настраиваются, а диалоги используются системные.
Можно писать под GNUStep или Cocotron, а под Mac нативно. Лучше Mac-like на Win, чем Win-like на Mac. Яблочники довольны, а вендопользователям, а тем более линукс всё равно не привыкать. В среднем, всем хорошо.
Нет, программы, написанные в mac-style, под виндой бесят. А таких, к сожалению, всё больше
Линуксоиды разные бывают. Меня например дико бесят «Mac-like» гномоприложения и прочие Brackets, ибо ну не вписывается оно в линуксовую экосистему нативности и текстовости.
И на каждом дистрибутиве линукса у него будет свой ворох уникальных ошибок при сборке, и на каждой версии windows, и на каждой macOS.

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

nix. Под один-единственный не-Unix-Like Шиндовс можно и превозмочь разобраться с ошибками.
вы обрекаете пользователя на превозмогание, если его окружение чуть-чуть отличается от вашего.

Можно сделать так, чтобы окружение у всех совпадало с точки зрения программы. Тогда гимора меньше.
Под Windows проще всего собирать. Под Windows компоновщики не лезут в system32 убедиться, что там в DLL есть нужные входы. Под Windows это вообще, не их, компоновщиков, собачье дело, а существует ли вообще DLL в природе.

На macOS ты попробуй только не дай ld пощупать каждый dylib, и каждую зависимость каждого dylib. Всё, не хочу, не буду компоновать.

На Linux в бинарники зашивается rpath. На macOS в каждый dylib зашивается, «где меня искать», и когда ld щупает все dylib, он копирует это в те файлы, которые компонует. Они теперь будут искать по тому адресу, который увидели в dyld.

Таблица импорта в Windows и macOS двухэтажная, то есть, понятно, какой символ из какой библиотеки, на Linux одноэтажная.

Гораздо проще с Windows. Не зря полнятся фрисофты и софтпорталы экзешниками.
На Linux в бинарники зашивается rpath.

Не вводите в заблуждение. «Зашивается» только при наличии параметра линковки -rpath, при -rpath-link путь к библиотекам используется для линковки без «зашивки». По умолчанию оба параметра не используются, линковщик использует пути определенные в LD_RUN_PATH (man ld).
Гораздо проще с Windows. Не зря полнятся фрисофты и софтпорталы экзешниками.

Correlation dose not mean causation. У винды 90% рынка десктопов, поэтому под нее куча софта, а не потому что под нее собирать бинарники проще.

Nix — это хорошая штука, но пока имеет два (три) недостатка:
1) Наркоманский синтаксис пакетов
2) Все можно ставить только в \nix, установка в другие места (например в хомяк) требует дополнительных телодвижений (если вообще возможна?)
3) Он пока не распространен

1) Наркоманский синтаксис пакетов

Это да, но пока GuixSD не научился грузится на нормальных машинах ит пакетов в нём кот наплакал, альтернатив нет.
2) Все можно ставить только в \nix, установка в другие места (например в хомяк) требует дополнительных телодвижений (если вообще возможна?)
Сейчас можно сделать nix store где угодно, хоть в хомяке, хоть на удалённой NFS-шаре.
3) Он пока не распространен

Ну смотря с чем сравнивать.
Можно начинать смотреть на x86 как уже байткод, только плохо поддержанный в этой роли.
Вместо одного кросс-платформенного приложения вы будете писать два специализированных (или даже 3, если еще и Linux).

Будет одно кросс-платформенное приложние, просто не на электроне, а например на Qt.


Как это может увеличить затраты всего на 10%, если у вам понадобится содержать в 3 раза больше разработчиков?

Затраты увеличатся больше, чем на 10%, но чем популярнее приложение, тем меньшую долю в общих расходах составляют зарплаты разработчиков.

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

Очень странная фигня — vscode для меня был просто открытием, сейчас я не представляю свою работу без него. И по производительности не уступает никому. А вот слак показался жутко тормозным, а сейчас думаю — я к нему привык или слак все таки сделали быстрее?

Привыкли. Причём в обоих случаях. В производительности не уступает никому — это я уж не знаю с чем вы сравнивали. Разве что с монстрами на C# или Java. Так-то что что Emacs, что Sublime, что пресловутый VIM — работают гораздо быстрее,
Слак работает куда медленнее Телеграмма, даже скорость запуска ниже. Постоянные тормоза при открытии другого диалога, а поиск по сообщениям эпизодически крашит вообще всю работу. Ну и нужно отдельно отметить мак версию телеграмма, которую недавно переписали на Swift — работает просто божественно со всякими вкусняшками вроде стикеров на тачбаре. Тот случай когда превосходство нативных приложений сложно оспорить.
Вообще, как по мне, идея заменить кроссплатформенными решениями нативные очень странная. Electron и прочие — это не замена нативной разработке, это возможность избавиться от Java и Qt в сегменте прикладного софта. А как делать — кроссплатформенно, или нативно — решать должен в первую очередь бизнес. Если есть бюджеты сопоставимые Дуровским то почему бы и не нанять вдвое больше разрабов и не сделать прям очень круто?
Слак работает куда медленнее Телеграмма

Не могу понять нафига все качают для слака приложение. Чем веб версия не устраивает? В ней хром дополнительный запускать не надо.
Как раз таки из-за производительности я перешел на vsc и удалил sublime — vsc запускался быстрее, искал и заменял быстрее и лучше работал с большими файлами. Да и система дополнений там реализована удобнее имхо
а с vim глупо сравнивать, так как это все таки разные вещи.
а с vim глупо сравнивать, так как это все таки разные вещи

vim и vscode разные вещи? А vscode и sublime не разные?

поясните вашу мысль

Ну вы считаете, что глупо сравнивать vscode с vim, потому что это разные вещи, а c sublime vscode сравниваете. Видимо, вы считаете, что sublime и vscode — не разные вещи. И тут совершенно непонятно в чём отличие между парой sublime — vsсode и парой vim — vscode. Почему элементы из одной пары сравнивать можно, а из другой — нельзя?

В моём случае sublime работает и запускается сильно быстрее vsc. У vsc отзывчивость интерфейса вообще ужас (на моей слабой машине). Лаги, особенно при выделении текста. Удалил его.
отсутствие необходимости что-то устанавливать на компьютер
Существует концепция portable-версий ПО, которая несомненно должна спасти отца русской демократии.

А с Electron'ом каждый раз по новой устанавливается аж целый браузер.
Ок, опишу конкретный юзкейс, который имел ввиду.
Компания взглянула на мое резюме и предложила провести собеседование + техническое интервью. На мой вопрос в каком из мессенджеров, ответили, что для таких целей используют google meat и прислали ссылку на созданное по этому поводу собрание. При этом мне было достаточно открыть ее в браузере, разрешить доступ к камере и микрофону и нажать кнопку «Присоединиться к собранию».
Вот зачем мне при этом ваши эффективные, органично вписывающиеся в систему нативные приложения? Хоть даже и портабельные. Все равно их надо скачивать с сайта производителя и разархивировать, а потом удалять, в случае ненадобности. Именно поэтому у того же google meat для windows ничего нет. Потому что это не нужно.
То же самое можно сказать про slack. Лично мне полностью хватает браузерного функционала. Так что нет никакого смысла скачивать клиент под windows. Тем более, что он все равно никаких дополнительных возможностей не предоставляет.
Поэтому я и считаю, что за полнофункциональными PWA будущее. Тем более, что для них отдельный экземпляр хрома не нужно будет тащить. Если приложение осуществляет работу исключительно с сетью — ок, пользуй, как веб страничку. Если нужен доступ к системе, как тому же VSCode — предложит в один клик установить локально, и будет запускаться как отдельное окно браузера. При этом все плюсы: кроссплатформенность, унификация, скорость, отзывчивость, расширяемость, доступность останутся. Мне это кажется, как минимум, перспективным.
«google meat» — намечается вкусное собеседование :)
Кейсы — они такие. В «относительно настоящем» времени пишутся. :) А так это пример из более-менее недавней практики.
Google Meet
«to meet» — встречаться
«meat» — мясо
Да, действительно. Прошу прощения за невнимательность. :)

Был уверен что это шутка.

НЛО прилетело и опубликовало эту надпись здесь
Когда вам что-то нужно один раз и забыть — это один кейс. Когда нужно постоянно и регулярно — совершенно другой, столь же валидный кейс. У браузерных приложений лучше с первым но хуже со вторым, так что отметать все остальное кроме браузерок «не только рано но и никогда»(с)
Да никто, вроде, и не отметает. :) Как по мне, «новые» технологии (если они не совершенно революционные) очень редко убивают «старые». Максимум забирают у них часть рынка. И тут, как мне кажется, будет тоже самое. И в обозримой перспективе js-сингулярность нас точно не ожидает.
А вот по поводу того, что веб-решения плохо подходят для постоянного использования я уже не сильно согласен. Пару лет назад я бы без колебаний подписался под этим высказыванием. Но с тех пор мое мнение постепенно меняется.
А то что и в нативном мире все далеко не гладко, на мой взгляд, хорошо подтверждает то, что под десктопы существует очень мало клиентов популярных веб-проектов. Да и под мобилки они часто толстые, тупые и нефункциональные.

Ну вот есть у вас 5 постоянно нужных веб приложений и надо перезагрузить браузер. Все они вырубаются и потом сами не начинают работу, пока каждую вкладку отдельно не кликнешь. При этом браузер сжирает всю оперативку и уже начинает вылезать из компа, чтобы задушить вас. Короче неудобно все держать в браузере. А ещё электронные приложения любят ни с того, ни с сего выжирать ядро процессора.

В Firefox уже очень давно есть «Pinned Tabs», которые показывают только свою иконку, закрепляются слева от всех вкладок и всегда видны, и всегда загружаются браузером при старте. Включить: просто правой кнопкой по вкладке и «прикрепить».
Отлично подходит для чатов и т.п.
А потом оказывается, что сработал какой-нибудь Lazy Load и закреплённые вкладки не прогрузились (на примере Chrome). Или мы достигли предела памяти и браузер просто молча погасил вкладку. И не поменял ей иконку.
Люди почему-то очень любят отдельные приложения. Вон даже у хабра есть мобильное приложение (у портала со статьями) и его все активно просили, а теперь просят его обновлять.
При этом объяснить зачем им отдельное приложение никто обычно не может. Есть какое-то полу-суеверное мнение что в браузере все «не стабильно», а в приложении как-то «надежнее».
На смартфоне держу приложения онлайн банка, али, ибэй, youtube… Они работают быстрее, присылают оповещения, плавнее работает интерфейс. Да и заточены они под мобилку лучше, чем даже mobile версия сайта.
Я говорю про случаи когда есть полная альтернатива в форме веб приложения, особенно если это альтернатива для десктопа.
Банкинг и ютуб — тебуют наличия всяких нативных штук (хотя пока из ютуба не выпилили воспроизведение звука в бэкграунде — я пользовался веб версией)
Али нe пользовался, у ибэя действительно убогий сайт (и не только мобильный)
Фишка браузера в том — что это и есть унифицированный интерфейс для всех приложений. Везде можно нажать «назад», зумить, выделить текст, открыть ссылку в новой вкладке, поделиться url'ом, сохранить картинку и т.д.
Если про десктоп, то клиент Telegram, к примеру, я всё-же предпочёл нативный. Меньше открытых вкладок в хроме, висит в трее и не мешает. YouTube предпочитаю смотреть через PotPlayer. Пробовал онлайн 3D редакторы. Лаги/мало функций. Музыка — через нативный плеер (хоткеи/функции). Да, я из тех, кто любит отдельные приложения. Ну серьёзно, они работают быстрее и функций в них больше.
Да, я из тех, кто любит отдельные приложения. Ну серьёзно, они работают быстрее и функций в них больше.
Ну дык за это их и любят… но современная тенденция это «жрите что дают… хотели „нативного приложения“?.. мы вам браузер с нашим веб-сайтом изолентой смотаем и скажем, что это — нативное приложение...»

Ненавижу…
когда есть полная альтернатива в форме веб приложения

Простите, но это как опрос «пользуетесь ли вы интернетов» проводить через сайт.
унифицированный интерфейс для всех приложений

Проблема в ненормальном стремлении браузеров стать эдакими операционными системами — мы получаем слой абстракций на ровном месте.
Простите, но это как опрос «пользуетесь ли вы интернетов» проводить через сайт.

Не очень понял, почему?

Проблема в ненормальном стремлении браузеров стать эдакими операционными системами — мы получаем слой абстракций на ровном месте.

Не на ровном месте. «write once, run anywhere»
Ну так вы требуете «полную альтернативу в виде веб-приложения», а она не всегда есть, не всегда нужна, у всех разные приоритеты. Редко когда и сайт, и приложение выходят полноценными — кого-то да обделят функциями. Иногда до смешного: долго не мог понять, почему коллеги ругают приложение Банка Москвы. Оказалось, что в iOS версии перевод клиентам пары десятков банков был сделан вполне нормально, а вот на Android чтобы в сам банк Москвы отправить перевод, нужно было вводить БИК, КПП и корсчета заполнять.

у хабра есть мобильное приложение… просят обновлять

Просят его написать. Когда я его последний раз запускал, оно могло «на главной» показывать статьи недельной давности и даже полная версия сайта на каком-нибудь GPRS загружалась быстрее. Как они так смогли — не понимаю.
прислали ссылку на созданное по этому поводу собрание. При этом мне было достаточно открыть ее в браузере, разрешить доступ к камере и микрофону и нажать кнопку «Присоединиться к собранию».
Для таких случаев оно и нужно. Может имярек пройдёт собеседование, а может и нет — глупо просить соискателя ставить конкретный клиент и ещё давать ему гостевую учётку корпоративного сервера видеоконференций.
Вот зачем мне при этом ваши эффективные, органично вписывающиеся в систему нативные приложения?
И это спрашивает человек с Хабра :( На секунду показалось, что я ixbt.com просматриваю.
Все равно их надо скачивать с сайта производителя и разархивировать, а потом удалять, в случае ненадобности.
Ну, да, существуют такие мальчики-летуны, которые обладают приятным голосом и ясным взлядом, умудряются проходить почти любые собеседования в мелких и не очень конторах, но нигде не задерживаются больше месяца-полутора. Очень редкая, но неприятная категория. Для таких, наверное, это проблема — каждый раз на новой работе под требования текущей конторы что-то новое устанавливать.
Поэтому я и считаю, что за полнофункциональными PWA будущее.
Лет 10 назад то же самое говорили про Microsoft .NET.
При этом все плюсы: кроссплатформенность, унификация, скорость, отзывчивость, расширяемость, доступность останутся.
«Надежды юношей питают, отраду старцам подают...»(с)Ломоносов

Нужны ли нативные приложения или достаточно будет веб-сервиса/веб-морды — всё зависит от того, является ли комп основным рабочим инструментом. Если требуется комфортно работать, чтобы ни мессенджер, ни что другое не мешало основной рабочей среде — да нужны. Если необходимо только формировать отчёты и связываться с коллегами — нет, не нужны.

Увы, мак вырос и под него пришли писать приложения компании которым плевать на культуру мак, им плевать на пользовательский опыт, мак для них — ещё одна проблема которую надо решить минимальными затратами. Аутлук, ворд-ексель, слак, телеграм и куча более невежественных кроссплатформенность Qt-поделок, или, того хуже Java SE кошмаров. К ним добавился Электрон, а теперь и сам Эппл игнорирует свой же UX.
Бабло побеждает всё )

А что вы имеете против Qt? В отличие от электрона эта технология максимально близка к процессору, никаких виртуальных сред исполнения и скриптов в браузерах.

И в Qt'e есть большой пласт кода под общим названием look & feel, который как раз нацелен на то, чтобы пользовательский опыт не был неожиданностью на платформе.

К сожалению, у них не получилось. Или плохо старались.

Ну это не совсем так. В qml можно почти весь фронт написать на js, который станет исполняться на V8. При этом нативные модели представления могут быть очень тонкими и их можно не брать в расчет.

Там давно уже нет v8

rpg18 справедливо заметил, что там сейчас другой движок, QV4. Да, внутри JS движок, но все же это не будет то же самое, что HTML, потому что QML гораздо современнее, изначально создавался для динамичного и гибкого построения GUI, а не для статики. Там многопоточность адекватная работает, есть сигналы и слоты с чисто C++ реализацией, стилей всяких кривых как правило нет, а просто изображения рендерятся.

Проблема не в близости к процессору, проблема — в UX. Джава там, джава-скрипт или плюсы — не так принципиально, как уважение к пользователю.
Когда запускаешь приложение, то, обычно, сразу видно, что это Qt. Начинаешь пользоваться и сразу утыкаешься в то, что разработчик приложения не живёт в экосистеме мака и сделал клон потому что может. Основная беда — не работают привычные шорткаты, часто их даже нельзя задать, поскольку мало кто за пределами мака знает, например, про cmd+E. Пункты меню напиханы как захотелось разработчику — чтобы что-то найти, приходится искать, и хорошо, если есть поиск в хелпе. Контролы на окно набросаны «чтобы было», а не в соответствии с гайдлайнами — выглядит примерно как сайт из 90-х.
НЛО прилетело и опубликовало эту надпись здесь
немного надумано
Вам, конечно, видней.

Если разработчику
насколько мне известно разработчик не решает задачи этого уровня, а бизнесу важно поставить галочку минимальными усилиями

Разве QT не позволяет написать нативный интерфейс OSX?
Можно, но, как уже было сказано выше, подавляющему числу кроссплатформенных проектов недостаёт понимания культуры платформы, проще говоря сделано по принципу «так сойдёт».
Не позволяет
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется, речь не только о Mac. Проблема более широкая, это же происходит и в Win и в мобилах. Разработчикам удобно написать один раз и потом запускать где угодно (такой почти Java лозунг). Microsoft, следуя известной мудрости, перестала бороться и решила возглавить. И это даже не смотря на то, что фактически это означает смерть для своих средств разработки (WinForm, WPF).
А что пользователи, почему они это терпят? Мне кажется, дело в массовом проникновении web. Во времена Word 6, html был настолько уродлив, что по интерфейсу он и близко не мог конкурировать с десктопом. Сейчас все изменилось, некоторые веб приложения функционально и особенно визуально стали не хуже нативных приложений. Этих приложений стало очень много, пользователи научились работать с разными приложениями и «нативность» и следование гайдам осталась нужна далеко не многим. В результате имеем то, что имеем. Сейчас это стало похоже на вывески и рекламу в провинциальном городе — каждый лепит, что хочет, да поярче. Упорядочить это будет сложно, т.к. приложение пишется под сильно разные целевые ОС.
НЛО прилетело и опубликовало эту надпись здесь
Xamarin не умеет в Linux.

Xamarin.Forms для GTK развивается, скоро будет всё ок...

Во времена Word 6, html был настолько уродлив, что по интерфейсу он и близко не мог конкурировать с десктопом.
Времена Word 6 — это, я извиняюсь, 1993й год, тогда про HTML только в CERN'е знали и с интерфейсом у него было чуть более, чем никак. Браузер был только один, второй появился плюc-минус тогда же и в нём только-только появился тег <img>…

В общем говорить об это как об интерфейсе приложений — было нельзя от слова «совсем».

Сейчас это стало похоже на вывески и рекламу в провинциальном городе — каждый лепит, что хочет, да поярче.
То же самое было в 80е в мире MS-DOS и CP/M.

Однако появление MacOS и Windows всё изменило… осталось только понять — как и почему.

Так-то винформам давно пора на покой.

Я вообще непонимаю, почему пользователи не замечают еще проблему во всем, что основано на Chromium. Если у кого мощный компьютер, безусловно можно игнорировать большое потребление ресурсов, но как можно игнорировать эти уродливые размытые и бледные шрифты (по крайней мере на Windows)? При чем, чтобы сделать их не бледными, достаточно просто при сборке Skia (библиотека рендеринга, используемая Chromium) указать другую константу гамма-коррекции.
Я думал это только у меня с компом/монитором какой-то баг с этими шрифтами…

Насчет мощности.
Пересел как-то с 6-гигового ноута на 16-гиговый, проц тоже в пару раз помощней. Рабочее окружение такое же. Через пару недель выскакивает окошко: «Недостаточно памяти. Закройте то-то»
Офигевая лезу в диспетчер — да, почти вся память съелась тем же Хромом, немного остальным.
Это Винда. Она щедро распределяет все, что имеет, и ее не насытить. И определенная логика в этом есть.
Не. Это не Винда. Это именно Хром. У меня на 4 гигах месяцами аптайм Win7 бывает, без всяких утечек памяти. Просто я не держу браузеры на хромиуме всё время открытыми…
Хром, но квотирует ему место Винда. Если бы он сам себя ограничил гигом — тогда да, но он грит: «мне чем больше, тем лучше». И это логично. Винда видит кучу памяти, и щедро раздает всем сестрам по серьгам. А Хром не в курсе, что у тебя там ИДЕ-шка твоя уже свопает. Ему дали, он жрет, чтобы более качественно отрисовать бледными шрифтами тебе какой-нить важный контент.
Вот так, я думаю, виндоуз ресурс скедьюлер работает.
Винда раздаёт столько, сколько её просят. Как и любая операционная система. Не её вина, что для ваших приложений у вас не хватает оперативки.
Я вроде о том же и написал, не?
Просто вы такой упор делаете на винду, как будто в других ОС иначе.
Вам показалось. Просто я с другими ОС не знаком.
скорее всего винда, у меня ноутбук Linux mint, 16ГБ ОЗУ, постоянно хром запущен с 15-20 выкладками, ещё запущен vscode, бывает что запускаю на VMware workstation, виртуалки на CentOS, и ни разу никаких проблем. Так что дело видимо в виндах

Целых 16 гиг и всего 20 вкладок? Так у вас просто запросы скромные. Опера (старая, на престо) без проблем показыва 200 и при этом ела не больше гига. Почему-то ни один современный браузер на такое не способен. Зато стильно-модно-молодёжно.

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

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

И не искали, и интернет другой был раньше. Сейчас совсем другие времена настали. Не от хорошей жизни все на webkit перелезли и бросили писать движки сами.

Да, не от хорошей жизни. Только от жадности и лени.

Скорее от понимания, что поспевать всем со своими движками за современным интернетом не получается. Интернет стал слишком сложным, а с ним и движки браузеров. Поэтому люди бросили эту затею и решили влиться в общее коммьюнити, чтобы сделать один движок хотя бы нормально.

Нет. Можно добится отсутствия уязвимостей высоким качеством кода, а можно переложить эти задачи на программу (читай — на мользовательский пк). Повысить касество кода — солжно и дорого, получить "безопасность" ценой увеличения нагрузки на пользочательский ПК — легко и дёшево. А люди жадные и ленивые. Результат немного предсказуем.

Да. Качество кода не гарантирует отсутствие уязвимостей, они неизбежно будут. Изоляция процессов это необходимая мера, чтобы минимизировать ущерб. Тоже самое касается банальных крашей и зависаний — они всегда могут всплыть на таких объемах кодовой базы, хоть как ты хорошо код пиши. Недеяться на свой программерский скилл и плевать на базовые меры безопасности — это уже будет наплевательское отношение к безопаности пользователей.
И много вы выдели программ, где добились отсутствия уязвимостей «высоким качеством кода»?

Я знаю один пример — но он очень показателен. Загрузчик Wii. 8K кода. Очень простого кода. Без GUI и многозадачности. Загрузить загрузчик второго уровня, проверить подпись и запустить. Всё.

На устранение всех ошибок ушло три года.

Как вы думаете — сколько времени уйдёт на устранение всех ошибок в программе размером с современный браузер? Если экстраполировать?

А много ли вы знаете проектов где отсутствия уязвимостей и стабильности добились с помощью особенностей языка? Я так например ни одого не знаю. Зато проектов которые не избавившись от недостатков получили ещё и прожорливость — множество.

Великое множество таких, устанешь называть. Любой проект на C#/Java и прочем контролируемом — в них просто невозможны уязвимости из-за работы с памятью. Со стабильностью тоже самое — любой язык со сборщиком мусора исключает целый ворох проблем с памятью, контролируемые среды дают намного больше гарантий в многопотоке, Go какой-нить своими примитивами делает написание многопотока намного проще и яснее, erlang тоже самое, только еще более радикально к этому подходит, Rust сюда же с его гарантиями. В общем, примеров и того, и другого великое множество.

Вы занимаетесь демагогией. Я вам про отсутствие уязвимостей — вы мне отсутствие проблем работы с памятью. Мне, как пользователю, наплевать, связана уязвимость с работой памяти или нет. А значит все эти языки не рещают проблем пользователя (зато решают проблемы программиста с кривыми руками), но при этом создают проблемы тому же пользователю из-за прожорливости.Никакой пользы окромя вреда.

Прочитайте еще разик мой комментарий, а потом обзываться лезте. Невежество ваше меня не волнует, я вам написал то, что просили.
А много ли вы знаете проектов где отсутствия уязвимостей и стабильности добились с помощью особенностей языка?
А причём тут «особенности языка»? Архитектура к языку не сводится.

Если хотите порассуждать о стабильности — попробуйте добиться от классической Windows (хоть 1.0/2.0/3.x, хоть Windows 9x) стабильности, сравнимой с Windows NT (и потомками Windows NT) или даже Linux (там похожие идеи использованы).

Да, вирусы от перехода на XP/Windows 7/Windows 10 не исчезли, да, вместо вирусов, прописывающих себя в MBR мы получили криптолокеры и прочее… но говорить, что между ними нет никакой разницы может только идиот, не понимающий, что «отсустстие уязвимостей» и «стабильность» — не бинарные понятия.

При статье они. Как-то линейку windows nt смогли написать более стабильной без Rust'a и Go. А в статье пишут, что дескать нельзя по определению.

Как-то линейку windows nt смогли написать более стабильной без Rust'a и Go.
Всё в этом мире относительно. Несколько лет назад было исследование — сколько времени живёт выставленная в Internet Windows 2000 без сервис-паков. Оказалось что скачать их с сайта Microsoft она не успевает.

А ваш роутер, который отсекает все эти попытки взлома — это как раз классический дополнительный уровень безопасности и есть.

И внезано, ПО этого роутера тоже как-то обходится без Rust, Go, и прочих Java. Кагжетаг?

Обходиться можно и ассемблером. Это не значит, что этого достаточно и ничего лучше не нужно. Демагогию вы тут разводите. Вы не то что не понимаете, а даже не хотите понимать, в чем преимущества этих языков, и чем объективно они лучше С/С++ в плане стабильности и предотвращении уязвимостей вроде heartbleed.
Да, правда что ли. По вашей ссылке код, который не имеет никакого отношения к heartbleed. Один глупость написал, другой не думая скопипастил. Суть heartbleed в чтении памяти за пределами массива из-за отсутствия проверки длины. То, что в Rust и любом другом современном безопасном языке сделать невозможно.

Ну действительно, на что я надеялся в дискуссии с вами.

Вы прикалываетесь уже что ли? Вы сами то код читали? Он никаким местом к heartbleed не относится. Да, не стоит ожидать в дискуссии со мной, что я буду невнимательным и просто проглочу вброс какой-то.
Обходиться можно и ассемблером.
Грустный опыт разработчиков OS Menuet/Kolibri как бы показывает нам, что нельзя.

А что там грустного случилось? Я специально за проектом не слежу, поэтому не в курсе.

И, к слову, Windows 98 была довольно стабильна. Как минимум сней у меня было меньше проблем чем с NT 3 (или 3.5? я уже и не помню. четвёрка уже была гораздо лучше, хотя вроде та же архитектура).

Win9x:
Ваш коврик выполнил недопустимую операцию и был свернут

жмешь «закрыть»… а оно опять… ещё раз… синий экран… нажмите любую кнопку… оо, работает
===
забыли уже?

Не знаю о чём вы. Win98 стояла лет десять, за это время бсодов наверно штук десять было, и всегда это было связано с тем, что я проводил какие-то бесчеловечные опыты. Вот Win95 это была жесть, да.

тут такойже эффект как у владельцев БУ авто которые говорят что они не ломаются, просто сравнить не с чем

поставьте себе Win98 и посидите недельку ;) я пару лет назад тут на старый комп ставил 98… прям как в прошлое вернулся и «выполнило недопустимую операцию» и все все радости 9x
раньше это просто было настолько нормой что внимание не обращали
p.s. сидел на винде с 3.0 версии довольно долго, на каждой кроме me и nt 3

Да где же я драйвера возьму под 9x! Да и софт современный не запустится. А без драйверов и софт не очень понятно что там вообще делать, в косынку играть? так при таком использовании будет годами работать без сбоев)))

НЛО прилетело и опубликовало эту надпись здесь
«вспомнить молодость»
и Win9x работает быстрее убунты на старом железе, чтобы там ни говорили адепты линукса (не, ну в консоли то она конечно не тормозит, или в DE в котором все урезано кроме окошек и указателя мышки)

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

Процессы в системах существуют не для безопасности

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

К памяти можно было бы относиться более бережливо, если б были счётчики ссылок и слабые ссылки, и только на крайние случаи сборщики мусора. Но за столько лет в JavaScript так и не сделали слабые ссылки.

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

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

Память там отъедается мощно трассирующей сборкой мусора. Про то, как надёжно запечатаны двери в светлое будущее, где счётчиками ссылок и слабыми ссылками сберегается память, я уже написал.
Вы по существу может лучше напишете, а не демагогию будете разводить? Сделано это для безопасности и стабильности, это факт. Зачем пишут на плюсах — потому что на тот момент лучшей альтернативы на руках не было, webkit черт знает сколько лет уже. Сейчас появилась — Rust, мозила его специально даже для этого и делала. Правда не думаю, что это полностью исключит необходимость в изоляции вкладок процессами. Теже зависания все равно могут вылезти и уж лучше пусть повиснет один процесс с одной вкладкой.
По существу процессы отнюдь не такое дорогое удовольствие. Операционные системы умеют shmem и mmap, и даже при ASLR умеют кешировать версии с релокациями. А вот трассирующая сборка мусора висит камнем на шее. Чтобы имело смысл проводить трассирующую сборку мусора, мусорить нужно обильно, в 5 раз больше, чем реально используется памяти. И без слабых ссылок всё ещё хуже.

Альтернатива плюсам существует 23 года, ещё когда никакого Rust в проекте не было, и это Ада. Вообще, первый, кто задумался о безопасности в языках программирования, — это Никлаус Вирт. Это он первый придумал проверять границы и переполнения. И это был язык Паскаль. И естественным образом это унаследовано потомками Паскаля.

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

Ну и давайте уже какие-то пруфы про трассирующую эту сборку. Ваши фантазии читать не особо интересно.

Что до Ады, беглый гуглинг говорит, что для данной задачи оно не подходит, т.к. безопасность уровня Rust не дает. Есть даже предложение внести что-то подобное Rust в аду, чтобы эту безопасность получить. Ну и, если бы webkit начали писать на этом языке, то можно было быть уверенным, что до наших дней он бы не дожил, т.к. его бы некому было писать. C++ был явно выбран, потому что на то время это был единственный высокоуровневый быстрый язык с большой популярностью. Судя по рейтингам, тогда он проигрывал в популярности только С.
Ну и давайте уже какие-то пруфы про трассирующую эту сборку. Ваши фантазии читать не особо интересно.
Там не «пруфы». Классика — это, вроде бы, вот это статья. Там хорошо видно, что при использовании GC либо вы имеете небольшой overhead по памяти — и дикое замедление, либо небольшое замедление — и потребляете в 4x-5x больше памяти.

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

И что там поддерживать? HWND для отрисовки поделиться? Кукисы заброадкастить?

И какие данные там дублировать? Основное, что раздувает память, это DOM, JavaScript объекты и 400% мусора от них, а они не дублируются. К сожалению, отсутствие слабых ссылок усложняет задачу избавления от мусора, так что в JavaScript по принципу и так сойдёт остаётся даже больше мусора (формально достижимого), чем в других системах с TGC, но где слабые ссылки есть.

Кеш? Ну, может быть. shmem для кеша нетривиален. Могли недостаточно хорошо сделать.

Но мне кажется, они там не за безопасность думали, а как прикрыть свой зад. Я когда Safari пользовался, когда он ещё второй версии был, он падал, потому что не на Аде был написан. OmniWeb ещё пользовался, и он тоже был не на Аде написан, и поэтому падал, но ещё чаще. Падал сразу весь, с текстами недописанными в каких-то вкладках, и это мегафейл. Не считая переписывания на Аде и последующего прозрения, от чего ж там на самом деле падает, и исправления найденных косяков, запилить это в отдельные процессы, похоже было единственной альтернативой. Не решить проблему, а замести под ковёр.

Mozilla тут проще, у них нейтральный к языку XPCOM, разные компоненты по отдельности можно апгрейдить на Аду. В WebKit нет XPCOM, но есть Objective-C runtime, тоже потенциально многоязыковой движок.

Ну и давайте уже какие-то пруфы про трассирующую эту сборку. Ваши фантазии читать не особо интересно.


Почему веб-приложения на мобильных платформах работают медленно

Что до Ады, беглый гуглинг говорит, что для данной задачи оно не подходит, т.к. безопасность уровня Rust не дает.


Сколько на ней пишу, даёт. И ещё даёт ООП внятное, сопоставимое с подмножеством, используемым в C++ и Delphi. Не такая эзотерика с типажами, как в Rust, под которую нужно всё через колено ломать. И исключения вменяемые. Растовские паники (а переполнения чисел и выходы за границы массивов производят именно их) — это почти как апокалипсис. Перехват паники — нештатная операция, и даже, если перехватить, то ещё штатный обработчик успеет нагадить в консоль своё бесполезное сообщение, и его тоже тогда надо перехватывать, чтоб не гадил. Я такую обработку ошибок последний раз в Turbo Pascal видел. Там галочки проверять диапазоны и переполнения были в настройках, но если их включить, происходили такие же апокалипсисы. В Delphi версии этак с четвёртой человеческие исключения возбуждаются, в языке Ада изначально по-человечески.

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


Да те же, кто пишут браузеры, и писали бы их на Аде. Чтоб спецы могли запрогать рендеринг не заточенного под это CSS в слои OpenGL, а с одного языка с RAII, шаблонами и ООП не могли перейти на другой язык с RAII, шаблонами и ООП, — да ну, бред какой-то. Кто бы стал там держать принципиально необучаемых. Всё они могут.
Оу, т.е. вы сами пишете код на Аде и выдаете перлы вроде
Я когда Safari пользовался, когда он ещё второй версии был, он падал, потому что не на Аде был написан. OmniWeb ещё пользовался, и он тоже был не на Аде написан, и поэтому падал, но ещё чаще.


Получается что все что не написано на Аде — говно.
Толстый троллинг.
простите, а как безопасность и стабильность требуют больше памяти?
Ну типа небезопасно и нестабильно — это когда корректное состояние сменяется другим корректным «по индукции». А если к индукционному переходу доверия нет, то нужны а) перекрёстные проверки, б) в случае, если выявлена лажа, по возможности починить состояние.

Например, CCured, CHERI и Эльбрус делают указатели разбухшими до четырёх раз, накачивая метаданными, но зато становится возможно проверить валидность. В автоматическом режиме, не переписывая на Аду, принудить код Си и C++ к корректности можно только так.

Возможность починить состояние: если лажу оперативно выявлять и пресекать, то и нечего чинить, а вот если крутится Си или C++, без CCured, CHERI или Эльбруса, то остаётся такой радикальный способ, как изолироваться от плюсовой лажи границами процесса. Там, в компостной яме изолированного процесса пусть всё протекает и гниёт как хочет, а граница процесса удерживает гниль от распространения. Но эти границы вроде бы тоже чего-то да стоят по памяти.
Это общее наблюдение, которое справедливо практически для всего. Бесплатно обычно ничего не дается. Если делаем безопасно, то чем-то приходится жертвовать в обмен. Как пример с изоляцией через процессы — это дает накладные расходы по памяти неизбежно. Песочница какая-нить — накладные расходы на перехват всех системных вызовов, дополнительные драйвера, процессы и чего еще там может быть. Шифрование — требует больше вычислительных ресурсов. Везде приходится идти на компромисс и жертвовать памятью или скоростью исполнения.

Но зачастую просадку в производительности можно (хотя бы теоретически) сделать маленькой.
Например, песочница для браузера, может быть выполнена (я не знаю, есть ли такая опция в современных ОС, но сделать ее точно можно) как процесс, которому запрещены все системные вызовы. Память выделается один раз, при старте. Сеть/файлы — через общую память с мастер-процессом. Получается довольно быстро (проблемы только с вводом выводом) и довольно безопасно(надо один раз подумать и качественно обрабатывать shared memory).
Шифрование — можно реализовать аппаратно, и оно начинает работать быстро.
Накладные расходы на процессы довольно невелики. (НЯП, там только стек, и несколько килобайт в ядре).

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

Судя по хрому, накладные расходные на их процессы довольно велики. И я совсем отказываюсь верить, что там прям из рук вон плохо все сделано и можно было ужать каждый процесс в 10МБ. Даже если убрать их сборщик мусора.
Опера (старая, на престо) без проблем показыва 200 и при этом ела не больше гига.
Тут ещё надо учесть, что те двести вкладок совсем другие были, интернет был совсем обезжиренным по нынешним меркам. Хотя хром и правда любит покушать, конечно.

Неа. Хром и в то время тоже жрал на порядок больше памяти, так что не надо всё списывать на ожиревшие страницы (которые, конечно, тоже имеют место)

Так я не спорю, он всегда голодным был. Firefox, особенно до выхода четвёртой версии, имел куда более скромный аппетит.
НЛО прилетело и опубликовало эту надпись здесь
Сравните текст в полях ввода Firefox сверху и Vivaldi снизу. То же самое происходит и со шрифтами на самих страницах. То, что в Firefox черное, в chrtomium-based браузерах и electron-приложениях темно серое.
image
Что-то не вижу я на винде таких шрифтов. Все четкое и контрастное. Тоже самое с vscode. Там читаемость шрифтов шикарная.
НЛО прилетело и опубликовало эту надпись здесь
Может, вам просто нужно настроить ClearType? Мне в какой-то момент тоже шрифты в системе стали казаться стремными, потом потыкал в картинки в настройщике и все стало классно. Кроме того, не факт, что дело в рендеринге хрома или неправильной гамме — вполне вероятно, что в адресной строке банально задан не true black, а серый для шрифта.
Корпорация добра успешно двигается к мировому господству. Помимо новости о том что Microsoft больше не будет разрабатывать свой движек, стоит упомянуть успешное продвижение языков и технологий, например go, а теперь еще и flutter релизнулся.
Вспомните как работало ПО и игры на новеньких Pentium 166x 128MB RAM, HDD 40Gb!
Аналогичное ПО и игры теперь весят в 10-ки раз больше, виртуализируются по 10 раз подряд, до вывода на экран.
Зато работают на 10 платформах, а не только на одной. Именно фрагментация — причина существования таких технологий, как Electron. Если когда-нибудь останется всего одна платформа, он загнётся даже быстрее, чем появился, потому как в нём больше не будет смысла.
Но программисты решили, что уж лучше терпеть Electron, чем монополию, а чего там хотят пользователи — то уже лет 15 как никому не интересно.
То, что разработчикам не интересно мнение пользователей это понятно, главное написать красивый лендинг, продающий ПО, а как там уже реально он будет тупить — это уже решится апгрейдом компа клиента. Насчет мультиплатформенности, тут тоже все зависит от профессиональности разработчика, т.к. неоптимизированный код все равно будет по-разному работать на всех платформах.
При этом я не против elecrton-ов и аналогичных web-движков, просто все чаще их суют просто потому, что по-другому уже не умеют.
НЛО прилетело и опубликовало эту надпись здесь
Из немаркетинговых доводов, которые я видел, в браузере реализовано автоматическое открытие клавиатуры при навигации по полям с планшета типа Surface Pro, а на обычном GUI с osk.exe не смогли разобраться, или в чём-то таком проблема.

Но вообще проблема в том, что хочется всё и сразу, и веб, и не веб. И Электрон позволяет это, но тогда нужно прогнуться под правила веб. А нет такого решения, чтоб, наоборот, прогнуть веб, а на десктопе и сервере было всё хорошо, как обычно.

Что можно было брать QIP'ы и The Bat! ы, с многопоточностью на мониторах, а не на хоаровских сообщениях, и загонять в веб, каких бы костылей это ни стоило. Я пытаюсь сделать это темой своей магистерской работы.
Зато работают на 10 платформах, а не только на одной
Ой ли? Возьмите «тот самый» DOOM, который летал на этом новеньком Pentium. Но поддерживал, при этом, MS-DOS (x86), Sega 32X (2 процессора SH2), Atari Jaguar (68000 и два проприетарных RISC'а), SNES (Super FX 2), Playstation (MIPS и ещё один проприетарный сопроцессор), 3DO (ARM60), Sega Saturn (те же 2 SH2, что и ранее, но другой API), Acorn Archimedes (тоже ARM, но другая OS), GBA (ещё одна OS на ARM). Ну а неофициально — и на осцилографе.

Именно фрагментация — причина существования таких технологий, как Electron.
Извините, но по сравнению с 90ми и, особенно, 80мы сегодняшная «фрагментация» — это смех.

Нет, причина существования Electron — банальнее и проще. Просто разработчиков на JS — на рынке много и они готовы работать «за миску риса» — а Electron позволяет их утилизировать. И всё.

Но программисты решили, что уж лучше терпеть Electron, чем монополию, а чего там хотят пользователи — то уже лет 15 как никому не интересно.
А вот с этим, боюсь, придётся согласиться. Поскольку пользователи нонче за ПО не платят обычно, то они — таки товар. А кто будет обращать внимание на жалобы и желания товара?
Ой ли? Возьмите «тот самый» DOOM, который летал на этом новеньком Pentium. Но поддерживал, при этом, MS-DOS (x86), Sega 32X (2 процессора SH2), Atari Jaguar (68000 и два проприетарных RISC'а), SNES (Super FX 2), Playstation (MIPS и ещё один проприетарный сопроцессор), 3DO (ARM60), Sega Saturn (те же 2 SH2, что и ранее, но другой API), Acorn Archimedes (тоже ARM, но другая OS), GBA (ещё одна OS на ARM).

Справедливости ради, для всех этих платформ надо было переписывать код (не весь конечно), часто даже нанимали стороннюю компанию для портирования под определенную платформу.
Да, но в результате на все платформы требовалось меньше разработчиков, чем сейчас на одну, универсальную — вот ведь в чём парадокс.
Когда P166 были новенькими, типичный объем памяти был 16-32, а диска 1-4. А ваш конфиг это скорее максимальный апгрейд старой машины 3-4 года спустя, уже в эпоху P-II и целеронов.
+1.
У меня был Celeron 333, 64Mb RAM, 8Gb HDD. А Celeron вышел значительно позже Pentium 166x
А при чем тут максимальные конфигурации? При выпуске с333 p166 все еще были в продаже, соответственно, могли быть подмешаны накопителями побольше. Да и вообще, это не принципиально, писал по памяти. Если говорить про 1-8Гб HDD, то тем более, в то время этого хватало на все, кроме тяжелых игр и видео (это все запускалось прямо с CD). Сейчас же на 1.5 гига будет приложение, функционалом на 1.5 Мбайт, тянущее за собой кучу фреймворков, библиотек ресурсов (используемых на 1%), еще и интерфейс рисуется браузером. Это хорошо когда все оптимизировано, но ведь каждый второй программист считает что, действительно, достаточно сконцентрироваться на решении поставленной задачи, а если будет тормозить — пусть купят комп пошустрее.
НЛО прилетело и опубликовало эту надпись здесь

Это и сейчас так есть. Вот пример создания js-приложения под Windows 10 в официальной документации. В этом и есть один из моментов перехода на Chromium. Раньше все эти псевдо-нативные приложения открывались в Edge, а теперь это будет Chromium.

То, что не смогла сделать Java, сделает Javascript
Простота разработки победила производительность.
Если методика станет массовой, то и производительность подтянется. В перспективе там явно будет кроме JS еще и WebAssembly. А в еще дальней — WA станет родным набором команд для процессоров, а перегруженный x86 будет наконец отправлен на свалку.
Производительность уже 15 лет как подтягивается, а большинство десктопных приложений тормозит так же, как и 15 лет назад
На примере Эльбрус:

Эмуляция x86 появилась гораздо раньше нативной Джавы
Когда в Унипро делали нативную Джаву, им долго не удавалось получить производительность выше, чем у Джавы в x86 эмуляторе
Оптимизированный JavaScript в Унипро сделали только после Java
А WebAssembly ещё не сделали

На примере Windows для ARM:

5 лет назад, Windows RT: да зачем эмуляция x86 на ARM? это убивает всю идею энергоэффективности
сейчас, Windows 10 для ARM, Always Connected PC: после того, как что-то не пошли продажи, и эмулятор сразу сделался, и кеширование транслированных цепочек на диске, и нативные срезы библиотечных функций, в общем, почти образцовая эмуляция x86 сделана (чтоб идеально, надо ещё кое-что)

Мне кажется, x86 исчезнет как родная архитектура процессоров, но останется как универсальный байткод. Objective PE, во всяком случае, имеет такую идеологию, хотя поддержка WebAssembly не исключена.

В том состоянии, как сейчас, WebAssembly требует довольно много костылей, и как пойдёт развитие, не понятно. Скажем, в Wasm все остановы (trap) полностью срывают стек. Значит, чтобы это обойти, нельзя пользоваться стеком Wasm, нужно размещать искусственный стек в памяти, чтоб можно было возвращаться, где остановились.

WA как родной набор команд? Вы в курсе для начала, что он стековый, а это как-то и раньше не прижилось.
Пока одни хотят костыли в wasm, другие спокойно пользуются
Wasm эволюционировал из костыля Asm.js. И пока он это делал, кто-то «спокойно» пользовался JavaScript, производя убогий код из онтопика
Из asm.js или PNaCl?
Скорее из asm.js

PNaCl был попыткой сделать переносимый байткод из LLVM-биткода.

Оно даже работает… но мало кого волнует…
Обратимся к истории. Google проиграл Mozilla в борьбе asm.js vs PNaCL, и стала делать еще один «стандарт». Первая демка wasm запускалась в Сhromium.
WebAssembly — это не разработка Google. Над ним трудятся инженеры из разных компаний. Я посмотрел людей что коммитят в репозиторий со спецификацией — мне попались сотрудники Apple, Mozilla, Google и Microsoft. То есть, буквально им занимаются все производители браузеров. Поддержка WebAssembly в Firefox и Chrome появилась почти одновременно: 7 марта 2017 в Firefox 52, 9 марта 2017 в Chrome 57.
EmScripten = Asm.js и Wasm
Первый транслятор Wasm был конвертером из Asm.js
И люди, которые Wasm подняли, вроде те же, что и за Asm.js.

А PNaCl? Пока он только в одном браузере, это ни о чём было. Вот FlasCC — другое дело.

И я не видел, чтоб там QIP, The Bat!, Total Commander или ещё какое-то типичное десктопное приложение «спокойно» портировалось в веб с помощью одной из этих технологий. Даже под Linux с большим спокойствием портировали с Windows приложения, хотя там запрос меньше.
Asm.js это технология от Mozilla, а первая демка появилась в браузере от Google. А emscripten просто тулчейн, вот Golang без него обходится.
НЛО прилетело и опубликовало эту надпись здесь
Каждый раз, как читаю про рак electron, убивающий desctop, всё никак не могу понять, это правда серьёзно? Если бы не было Электрона, то вместо «1000 тормозных поделий на JS» не было бы «1000 прекрасных программ на С++». Большей части из этих приложений не было бы вообще ни в каком виде.
Большей части из этих приложений не было бы вообще ни в каком виде.

*смотрит на Slack* Не уверен, что это такая уж проблема…
Пусть бы и дальше они оставались вкладками браузера, зачем это тащить и продвигать на десктопе? Особенно, на базе самого жрущего в мире браузера…
Потому что того требовал потребитель. Людям нравятся эти приложения, но они хотят видеть знакомый десктопный опыт хотя бы в виде отдельной иконки и окна приложения, а не браузера какого-то непонятного. Никого не волнует, что внутри этот тот же самый вэб клиент.
Так есть PWA же, зачем тащить второй инстанс хромиума в виде электрона?
Большей части из этих приложений не было бы вообще ни в каком виде.
А почему вы-таки считаете, что это было бы плохо?

Те 5 или 10 приложений, которые не являются заменой давно существующим приложениям для десктопа «с новыми перламутровыми пуговицами» — появились бы всё равно, а очередной ICQ, жрущий в 10 раз больше, чем и без того дико жрущий официальный клиент… он нам точно нужен?
Имхо: распространение такого типа приложений — это хорошо — все упрощается. Но вот не помешало бы что бы каждое приложение не тащило вместе с собой браузер. Имхо, достаточно было бы указать его в зависимостях, и если его нет в системе — поставить. 1 браузер на все приложения. И, так как сейчас тенденция в больших объемах JS — неплохо бы все же максимально заоптимизировать js машины, добиться максимальной производительности, и умеренного потребления ресурсов.

Имхо, не за горами день, когда весь софт на обычном устройстве (спецсофт не в счет) будет написан на JS. Это прекрасно — однообразие, достаточно простой вход. Не без другой стороны медали. А вот UI перестраивать под систему, под которой исполняется было бы не плохо, ибо, имхо, это не сврехзадача.
На тему единого движка на все приложения у Google уже есть экспериментальное решение: github.com/GoogleChromeLabs/carlo

Похожее на Electron API, только использует установленный в системе Chrome, а не несет свой на борту.
Хм, интересное. Только я пока еще не зашел в тему. В этом смущает только то, что это для Chrome. Имхо, у Chromium может был бы и лучше, без жесткой привязки к продуктам Google. Пусть Chrome установлен на подавляющем большинстве компьютеров, все же привязка немного смущает. Хотя, может, это всего лишь бурно реагирующая паранойя
А вот UI перестраивать под систему, под которой исполняется было бы не плохо, ибо, имхо, это не сврехзадача.
Намного логичней и удобней было бы прийти к единому унифицированному UI на всех платформах. Понятно что UI для мобильных должен отличаться в силу особенностей устройства, но зачем на десктопе на каждой системе свой сильно отличающийся UI?
Есть же уже унифицированный веб, почему нельзя по этому же пути унифицировать и UI десктопного ПО, тем более, что и сейчас отличия не такие уж прям принципиально не совместимые.
Не думаю, что просто так получится унифицировать UI. Mac os один подход, винда — другой, у linux — еще зависит от DE. Вероятно проще будет, утрировано, подключать что-то а-ля macos.css, windows.css, linux.css
Как вариант, если большая часть ПО будет использовать унифицированный веб-подобный UI на всех ОС, то и пользователи будут хотеть такой же UI и в интерфейсе самой ОС, что вынудит разработчиков ОС отказаться от своих подходов и поддерживать UI софта.
Что-то не верится в это. Linux — некого душить, некоммерческая система (а где коммерческая разработка, там все равно не туда), а еще одна DE — сомнительно, ибо взлетит если только как Убунту кто-нибудь профинансирует и распиарит, что все же сомнительно, имхо.
Яблокам что-то навязать/доказать — что-то из разряда просто нереального
Майкрософт — тоже не реально.
Так что, что бы это случилось — не знаю что должно произойти.
Мелкие системы типа chrome os 0 не популярны
Всем этим вебоненавистникам немного не хватает понимания, что именно спрос рождает предложение, а не наоборот. Да и хейт немного странный. VSCode занимает на жестком диске почти гигабайт, да. Но не пофиг ли в век террабайтных жестких дисков и оптики в каждом доме? Я готов платить такую цену в обмен на апдейты два раза в месяц и постоянные улучшения.
Я готов платить такую цену в обмен на апдейты два раза в месяц и постоянные улучшения.

Зачем эти «постоянные улучшения», если есть уже максимально улучшенный emacs, в котором тысячи режимов, дополнений и настроек?
VSCode из коробки это дебаг приложений Node.js, умная подсветка в том числе TS, ESLint и Emmet. А еще Git и современный интерфейс. А сколько времени нужно потратить что бы это все заработало в Emacs?)
Около недели. Зато вы получаете быстрый, полноценный редактор, настроенный под ваши нужды, возможность работы с клавиатуры и очень высокую расширямость. Без Electron.

То есть vs code, но без electron. Ну такое себе преимущество

VSCode такой милый не из за электрона, а команды разработки, которая позаботилась о вас.

Если бы не было электрона то на разработку такого же милого редактора нужно было бы вдвое больше ресурсов. И знаете, у нас уже был один такой популярный редактор — Sublime Text :)
НЛО прилетело и опубликовало эту надпись здесь
Что такое скорость и функционал, объясните недалекому? Быть может вим умеет сам верстать прямо из макета?) Вот слабо хоть пяток конкретных примеров привести?
НЛО прилетело и опубликовало эту надпись здесь
Пока вы будете это две минуты делать — я в вскоде сделаю то жe самое мультикурсором не притрагиваясь к мышке за полминуты. И так далее…

То что ваш коллега не умеет пользоваться своим редактором — редактор никак нe характеризует.
НЛО прилетело и опубликовало эту надпись здесь
Ну значит ни вы, ни ваш коллега мультикурсором пользоваться не умеете.
Вообще это дурацкое заблуждение вимеров, что все остальные мышью по экрану водят и через менюхи все делают. Шорткаты есть во всех редакторах. Я к мыши почти не притрагиваюсь во время работы.

Мультикурсор — это только небольшая часть того, что я делаю за 2 минуты

Можно пример?
НЛО прилетело и опубликовало эту надпись здесь
Я на личности не перехожу и задеть вас не хочу. Просто констатирую факт.
Примера не будет, насколько я понял?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я ж говорю — вы пользоваться не умеете.
НЛО прилетело и опубликовало эту надпись здесь
Вы заблуждаетесь.
То что я делаю за 2 минуты, коллега на студии код делает за 10 минут.

А почему коллега не пересаживается на emacs?

НЛО прилетело и опубликовало эту надпись здесь

И он не готов отказаться от мыши, ради пятикратного увеличения скорости работы?

НЛО прилетело и опубликовало эту надпись здесь

Да, конечно его, просто любопытно, как он для себя это формулирует.


Типа — да, я понимаю, что мог бы работать в 5 раз быстрее, но возможность использовать мышь для меня так важна, что я готов отказаться от этого?


Что должно быть в голове у человека, который добровольно отказывается от пятикратного увеличения производительности и, думаю, где-то двухкратного увеличения зарплаты?

НЛО прилетело и опубликовало эту надпись здесь
И встроенный психолог, который спасёт после попытки запомнить это всё :-)
Зачем запоминать всё? Настраиваем под себя, мучаемся неделю, работаем, пока не надоест. Повтряем.

Но в чем смысл, если в vs code все работает сразу, хорошо и быстро?

Потому что быстрее и возможностей настроить под себя гораздо больше. И нативно.
А что быстрее? VSCode устанавливается за минуту, а вы же сами говорите на Emacs неделю только на настройку нужно.
Быстрее работа в связи с возможностью настроить под себя. Неделя настройки по сравнению с годами использования — фигня.
А смысл от вашей нативности? Ну какой от нее смысл? Где ее преимущества в повседневных задачах? Я вот сколько не смотрю одни минусы вижу.
настроить под себя

Можете объяснить что вы под этим понимаете? Желательно примерами.
Хорошо. 1) У меня мои логины/пароли к гиту хранятся в SSHASKPASS. Когда я делаю git push в vscode, он не подхватывает AskPass и такой настройки я не нашёл. В emacs я просто ставлю magit и в связи с нативностью он правильно подхватывает мой Askpass и не спрашивает лишний раз пароль.
2) Подсветка синтаксиса и автодополнение сделаны по-человечески, расширямо. Плюс поддерживается гораздо больше языков (включая редкие), чем в VSCode.
3) Весь интерфейс изменяется, можно сделать всё что угодно от просто поля ввода даже без строки статуса до обвешанного разной информацией и украшательствами монстра.
4) Работает в текстовом режиме.
5) Умеет нормально открывать удалённые файлы
6) Конфигурация пишется не на ущербном JS, а на функциональном Lisp.
Это вы привели список фич, a не то как можно под себя настроить редактор.

1) У меня мои логины/пароли к гиту хранятся в SSHASKPASС

Не знаю насчет этого случая, прокомментировать не могу.

2) Подсветка синтаксиса и автодополнение сделаны по-человечески, расширямо.
Плюс поддерживается гораздо больше языков (включая редкие), чем в VSCode.

Ни разу еще не встречал язык, который не поддерживается Кодом, даже всякие очень специализированные есть (вроде .peg)
В Коде автодополнение и подсветка тоже расширяемы. Можно добавлять свои / менять существующие. Или я чего-то не понимаю?

3) Весь интерфейс изменяется, можно сделать всё что угодно от просто поля ввода даже без строки статуса до обвешанного разной информацией и украшательствами монстра

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

4) Работает в текстовом режиме.

Это не пример улучшения, а факт. Вы разрабатываете в текстовом режиме? (я так понимаю имеется в виду работа прямо в терминале)

5) Умеет нормально открывать удалённые файлы

ВСКод тоже.

6) Конфигурация пишется не на ущербном JS, а на функциональном Lisp.

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

И опять же, примером того как редактор можно настроить под себя (ваш главный аргумент) — только пункт 3. Это все?
Всё это — настройка под себя, даже если оно работает из коробки. Такая возможность есть, я ей пользуюсь, значит настраиваю под себя.
По поводу ответов: да, вы в чём-то правы. Не соглашусь с
Ни разу еще не встречал язык, который не поддерживается Кодом, даже всякие очень специализированные есть (вроде .peg)
. Банальный пример: в emacs поддерживается форматирование кода, автодополнение опций и функций, подсветка ошибок в nix, а в VSCode — только подсветка кода.
Я не так давно пользуюсь emacs, но уже работаю быстрее, чем раньше работал в vscode. Гораздо меньше возюкаю мышкой, гораздо больше интеграция в систему (например, вместо встроенного тайлинга можно использовать тайлинг от системного WM, в отличие от VSCode), гораздо больше расширений.
Вообще, тут вопрос наверное сводится к субъективному удобству — мне удобнее нативный, быстрый и интегрированный emacs, кому-то удобнее VSCode.
В VSCode есть и автодополнение и подсветка ошибок. Даже PHP скрипты при сохранении автоматически прогоняются через интерпретатор и отлавливаются и подсвечиваются ошибки.
nix

PHP

Всё-таки разные языки. Меня интересует конкретно поддержка nix.
Согласен, на текущий момент поддержка конкретно этого языка ограничивается подсветкой синтаксиса, но ничего не мешает добавить туда и автодополнение и подсветку ошибок.
Странно, вот сейчас поставил себе VSCode (Linux Mint) — deb пакет весит 42,7 метра — все зависимости удовлетворены, т.е. ничего не тянет сверху.
/usr/share/code весит 169 метров. бинарник code — 79 мегабайт. Я пока еще не разбирался с электрон, и как получается само приложение. Но посмотрев vscode — сходу видно что основное место занимают текстовые файлы (json, js). Т.е. если fs поддерживает сжатие, то места занимает не много.
А если была бы подобная технология (electron и иже с ним) внедрена в ОС, что бы не тянуть то что не является приложением — браузер, поддержку всего, то само приложение в сжатом виде занимало бы не много. Достаточно было бы среднего сжатия, что бы быстро распаковывалось при старте, и все, места занимало бы раза в 2 меньше.
Имхо, за подобными вещами будущее, и, остается лишь надеяться, что это правильно интегрируют, что бы устранить основные недостатки текущих приложений
Да, ошибся, это Атом занимает 700 мегабайт из коробки.

Зато после запуска он съест несколько сотен мб. И каждое следующее electron приложение столько же.
Нужна система с расшариванинием Chromium между приложениями.

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

DLL Hell 2.0. Из-за стремления избежать этого приложения и стали весить по гигу и тянуть с собой все либы. И винда, кстати, тоже, см. WinSxS.
Будущее за PWA. Edge переходит на Chromium, Apple экспериментирует там тоже с всем этим. Через пару лет 99% устройств будут иметь адекватный и современный браузерный движок буквально вшитый в систему.
  1. Мгновенно возникает проблема с версией системного движка
  2. Разве PWA будут выпускаться за пределы песочницы?
1. Мы до сих пор умудряемся кое-где поддерживать IE9. Думаю пару месяцев не обновлявшийся Хром не такая уж и сложность :D
2. Думаю нужно реализовать механизм разрешений, что бы каждое PWA могло спросить разрешения, например, на доступ к файловой системе.
  1. С движком сейчас проблем нет – благодаря механизму автоматических обновлений, большинство пользователей получают обновление браузера в течение пары недель после его выхода. Один Microsoft со своим Windows Update всегда отстает, может с Chromium ситуация исправится.
  2. Для обращений за пределы песочницы есть API на все случаи жизни: WebAudio, Fullscreen API, Push API и другие. Для большинства задач этого набора хватит.

Как пример полезного PWA: https://squoosh.app – сжималка изображений. Не хуже многих декстопных программ и устанавливать ничего не надо, достаточно сохранить адрес в закладки.

Как пример полезного PWA

Единственный его недостаток по сравнению с десктопным приложением: сайт не открывается.
У меня открывается. Может это блокировки роскомнадзора?
Может быть. А может и не быть. Вот в этом и минус веб-приложений.

Террабайтные SSD все ещё стоят довольно дорого. М я не понимаю, зачем хранить на диске 7 копий Хрома? С таким подходом вообще никакого хранилища не хватит.

Уверен, что эта проблема будет решена в течении пары лет. Гугл уже экспериментирует с единым движком для «сложных» приложений — github.com/GoogleChromeLabs/carlo, а те что попроще уже сейчас на некоторых платформах могут и без движка «устанавливаться», например твиттер на андроид.
С таким подходом вообще никакого хранилища не хватит.
Ёмкость накопителей и оперативной памяти растёт экспоненциально. Поэтому, если количество используемых Вами программ не будет расти также экспоненциально, то очевидно, что рано или поздно наступит момент, когда Вы сможете установить все эти приложения практически бесплатно. И долго ждать этого момента не придётся.

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

Но конечно Electron'у самое время было бы года через два, потому что сейчас ему ещё рановато. Поставил Spotify — он выжрал 1 ГБ из 32. По идее норм, но это на мощных 32 ГБ памяти, а на слабых — 16 ГБ. +Предполагается, что он будет работать в фоне. Вот года через 3, когда у людей будет 32/64 ГБ…
Стоимость освоения новых литографических процессов
Ёмкость накопителей и оперативной памяти растёт экспоненциально.

Я немного поправил ваше сообщение, можете плюсик не ставить.
Интел, вон так и не смогла в массовый 10нм.

А вообще софторазработчики странные.
Сначала всегда
— Если у них тормозит мое приложение, то пусть купят более мощный ПК.
Через пару дней- мой любимый момент.
— Да вендоры вообще оструели — видеокарта 2500$, ЦП да еще и с ошибками- 1000$, память — 300$ за 32 гига!!??? Доколе!!!

Заказчики тоже не подарок. Пишешь, что будешь писать на Аде, и начинается, ой, а что вообще написано на Аде, а зачем это надо.
Ага, потому что написанное еще и поддерживать надо, и если Вы ему сейчас напишите на Аде, а потом по каким-то причинам откажитесь от поддержки проекта или увеличите свой ценник в 10 раз, то что делать заказчику? Где искать спеца в редкой технологии? Или платить заново и переписывать все с нуля на распространенном языке?
Либо так, либо наслаждаться божественными ценами
видеокарта 2500$, ЦП да еще и с ошибками- 1000$, память — 300$ за 32 гига

за глючную тормозную программу.

Ну и, может, как-то заказчикам консолидироваться, чтоб для Ады рынок надёжного и быстрого ПО был, тогда будет не редкой технологией.
Ну как минимум 3 нм, вроде, разрабатывается, значит настанут времена, когда в комп можно будет поставить 900 ГБ памяти. Electron потянет.

Видеокарта 2500$
Б/у 1080 Ti стоит 500$.

ЦП да еще и с ошибками- 1000$
Норм ЦП стоит 200$ (причём со встроенной видюхой).

Память — 300$ за 32 гига
А вот тут да, фейл. Она ведь до этого стоила 150$ за 32 гига. А стала 300$ (хотя сейчас наконец упала). И это при том, что прошло 2 года, а ведь в среднем память всю жизнь дешевела примерно в 2 раза за 3 года, а тут вместо этого подорожала… По факту сейчас 32 ГБ могли бы стоить около 4000 р, если бы не падение рубля и картельный сговор. Ну конечно 4000 р — тоже много, но для слабого компа 16 ГБ стоили бы 2000 р — вполне можно потянуть.
3нМ — не знаю; помню, что Самсунг выкатывал тестовые 5нМ.
Но ценник будет конский, явно только для премиум-сегмента.

Насчет 900Гб памяти — только доступ к ней будет на «стекляном потолке в 5ГГц», потому что количество каналов в бытовом секторе — традиционно 2, 4 — в премиуме.
Поэтому несколько экземпляров Электрона будут подниматься… сначала с ССД по ПСИ-е… потом с памяти до ЦП… меедлееееенннооооо…
3 нм — это как раз Самсунг разрабатывает (а точнее, уже разработала).

на «стекляном потолке в 5ГГц»
— так ширина шины же тоже будет расти. Да и даже сейчас на 3200 МГц она выдаёт 25 ГБ/с и порядка 32 ГБ/с в dual-mode. Тип памяти тоже будет улучшаться. Вон, там с каждым поколением в 2 раза увеличивалась пропускная способность.

Поэтому несколько экземпляров Электрона будут подниматься медленно
Несколько экземпляров Электрона отожрут до нескольких гигабайт, и ещё 897 ГБ останутся свободными.
Боюсь если будет доступно 900Гб, приложения найдут их как утилизировать. Ситуация будет лучше чем сейчас, но думаю не на порядок даже.
Если посмотреть как изменился объем потребляемой памяти софтом — то вывод один, имхо — сколько не дай — все мало.
В средней конфигурации.
Потому что раньше всегда было, куда поиспользовать её. Даже сам факт написания кода на языках низкого уровня. +Очень жёсткая экономия памяти (вынужденность отказывать от вещей, которые ускорили бы программу или вообще сделали бы возможной её работу или часть её функционала).

А сейчас куда расходовать память, когда всё уже сделано? Ну линейный или чуть выше рост будет конечно.
Ширина не будет расти массово.
Один канал — это грубо говоря +1 слой платы и +300 выводов процессора.
Если посмотреть на Тридриппер, то там только корпус ЦП стоит под 50$, а сколько стоит соккет такого размера — я даже затрудняюсь.

Если массово переходить на 4 канала, то это 80-100$ к стоимости МП и 20 к стоимости любого ЦП.
Я не уверен, что рынок воспримет это позитивно.
насчет 3 нМ у Самсунга — промышленное внедрение 2021 год.
У Интела формально 10нМ уже есть как пару лет- на одном мобильном огрызке I3.
Процесс — есть, выхода годных — нет.
Поживем — посмотрим.
Ну я и не говорил, что внедрение сейчас. Имелось ввиду в течение 6 лет, т. е. в 2021 году (что, кстати, даже очень рано — на 3 года раньше).

Вряд-ли, сейчас 8 Гб стоят > 4500 р.

НЛО прилетело и опубликовало эту надпись здесь
Это в России нет, из-за падения рубля. А также из-за картельного сговора. Всё это суммарно унесло 6 лет развития. Но сговор скоро будет разрушен (подтянутся другие производители), а падение рубля отразилось только на России, а не других странах. В остальном память дешевела экспоненциально и будет дешеветь далее.
Если бы все было так просто, насчет подтянутся -это ведь не чипсы выпекать.
Интел уже 3 года не может выкатить массовый 10нМ продукт, ГлобалФундри — отказалась от освоения 7нМ.

Полупроводниковых производителей памяти больше толком не будет. Все теже самые Микрон, Самсунг, Хуникс и всё.
Эльпида — и та банкрот с 2012 года и принадлежит Микрону.
Вообще-то, в Китае появляется сразу два производителя оперативной памяти. Я же не просто так говорю «подтянутся другие». Вы просто не следили за новостями.

Интел уже 3 года не может выкатить массовый 10нМ продукт, ГлобалФундри — отказалась от освоения 7нМ.
И снова Вы не следите за новостями. Samsung уже завершила разработку 3 нм, и готовится к запуску в 2021 году.
Памяти вообще, или ап-ту-дейт для ПК?
Роутеры и прочие хлебопечки только массово начали переходить на ДДР2, премиум — на ДДР3.
Есть еще применений ДДР/СДР.

А ведь
128 GiB module based on 8 Gib DDR4 using 20 nm technology

Заводик со старта должен будет прыгнуть в высшую лигу нанометров.
Да, планируется полноценный конкурент Samsung, Micron и Hynix. Память будет DDR4. Массовый выпуск назначен на 2019 год. К 2021 году планируется завершить разработку 17 нм. Сейчас по какому будут производить, не видел, но понятно, что не по очень большому. Для сравнения, Самсунг только сейчас начала производить по 17-нм техпроцессу.

PS. Готовящиеся производители — Innotron Memory и JHICC.
Да и хейт немного странный. VSCode занимает на жестком диске почти гигабайт, да.

По моим наблюдениям, бомбит обычно от объема сжираемой памяти при работе. Простой пример. Старая версия Skype использовала примерно 30Мб оперативы. Благодаря добрым людям из Microsoft, я вынужденно обновился (к слову, зря) и теперь у меня новый Skype легко кушает не меньше 300Мб. Причем, у коллег легко может отжирать и 700Мб, с чем связано сложно сказать. Так вот, для мессенджера даже 300Мб — это сильно дофига.
А вот я бы, наоборот, предпочёл, чтобы он ел не меньше 300 мб, но зато работал быстро. У меня 32 ГБ памяти, и я купил её как раз для того, чтобы программы её использовали и работали быстрее.
Т.е. вариант есть 30Мб и работать быстро не рассматривается в принципе? К слову, у меня старый скайп так и работал.
1. Не всегда это возможно.
2. Скорее всего, какие-то функции работали быстро, а какие-то глючили. А вообще я не припомню, чтобы скайп когда-то быстро работал. Даже нажатие на диалог создавало лаг. А вот если бы он пожрал память, то мог бы отобразить его мгновенно.
3. Один только экран в 4К занимает 32 МБ. Это уже больше 30 МБ :) А винда, скорее всего, кэширует этот экран. Вам уже придётся не на весь экран разворачивать скайп для экономии памяти XD.
4. В программах обычно всегда компромисс между потреблением памяти и скоростью работы. Конечно, не во всех частях программы, но во многих. Так вот, обладая 32 ГБ я не хочу, чтобы программист экономил память и пытался уместиться в 30 МБ, из-за чего программа работает в несколько раз медленнее, а некоторые вещи тупо работают очень медленно. Взять тот же Everything. Тратим пару сотен мегабайт, взамен получаем мгновенный и очень мощный поиск по всем файлам в системе. У меня 32 ГБ памяти. Ну зачем мне на каждый поиск тратить около часа? Да я зачастую за час только 30 таких поисков могу сделать.

Или взять те же браузеры. Нажимаешь на вкладку и ждёшь 3 года. Всё потому, что разработчик решил поэкономить память и не кэшировать скрин вкладки…

Ну или взять некоторые игры. Заходишь на локацию, уходишь с неё, она полностью выгружается из памяти. Потом заходишь снова, и ждёшь 20 секунд. Всё ради того, чтобы игра не занимала больше 3 ГБ памяти :(
Вам уже придётся не на весь экран разворачивать скайп для экономии памяти XD.
И никогда не нужно было. Приложение всегда могло отрисовать свой экран.

Так вот, обладая 32 ГБ я не хочу, чтобы программист экономил память и пытался уместиться в 30 МБ, из-за чего программа работает в несколько раз медленнее, а некоторые вещи тупо работают очень медленно.
Вот только почему-то на тех самых 32 ГБ тот самый MS Office 2000, который пытался вписаться в 30 МБ просто летает. Все операции, вот абсолютно все операции, которые мне от него нужны отрабатывают куда быстрее, чем «жутко оптимизированный и потому жрущий памяти» MS Office 2016.

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

Ну зачем мне на каждый поиск тратить около часа?
Вы бы сначала объяснили как вы дошли до жизни такой, что вам, вдруг, мощный поиск понадобился не в виде исключения, раз в месяц, а регулярно — аж то такой степени, что вы специальную программу для него водрузили…

Заходишь на локацию, уходишь с неё, она полностью выгружается из памяти. Потом заходишь снова, и ждёшь 20 секунд. Всё ради того, чтобы игра не занимала больше 3 ГБ памяти :(
Нет — это ради того, чтобы разработчик мог особо не думать о том, как игру оптимизировать. Crash Bandicoot и Final Fantasy VII как-то умудрялись подгружать все ресурсы так, что это незаметно было на системе с односкоростным CD (300кб/сек) и 2Мб памяти, не надо мне рассказывать про то, что современные игры SSD не могут обеспечить тот же фокус на системе с в 1000 раз более быстрым накопителем и в 1000 раз большим объёмом памяти.
Понятное дело, что в играх можно сделать без подгрузки, потому что примеров этому масса. Но конкретно в данном случае разработчик мог бы тупо не выгружать уже загруженную локацию, и при её повтором посещении она должна была загрузиться быстро.
«Тупо» — не мог бы. Ибо изрядное количество ресурсов нужно загружать не в память компьютера, а в память видеокарты. А там — свободного места куда меньше и оперировать с ним — сложнее.

А если бы был аккуратный учёт всех ресурсов — то сделали бы нормальную фоновую загрузку и никаких 32GB не нужно было бы…
Пропускная способность PCIe 3.0 x16 — 15 ГБ/с. Загрузить 1 ГБ в карту заняло бы 65 мс. Не думаю, что дело в этом.
Дело не в 15 Гб/с. Дело в необходимости учитывать вот это вот всё. Что данные нужно перегонять из оперативки в видеокарту и прочее.

То, кто этим занимаются — могуть сделать и так, чтобы на 3ГБ не тормозило, им 32ГБ не нужно. Те, кто не занимаются — те не занимаются и у них соотвествующего кода просто нет.
мощный поиск понадобился не в виде исключения

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

Но для этого тоже есть хорошие и не сильно затратные решения — есть SphinxSearch который даже на arm за десяток миллисекунд найдёт подходящие записи из полутора миллионов и сожрёт три сотни мегабайт памяти (из них пять метров на сам демон, остальное индекс). У обычного пользователя не полтора миллиона файлов, так что в эти три сотни метров можно даже поиск по содержимому файлов впихнуть.

Нажимаешь на вкладку и ждёшь 3 года… разработчик решил поэкономить память и не кэшировать скрин вкладки…

Нет, причина в том, что браузер пытается делать десятки тысяч операций записи и чтения в секунду. Естественно, кеш операционки от такого говнокода полностью не защищает и на hdd хромы еле шевелятся.
Даже нажатие на диалог создавало лаг. А вот если бы он пожрал память, то мог бы отобразить его мгновенно.

Что же такого прожорливого должен мессенджер покэшировать, чтобы работать быстро? Пару килобайт диалогов? Хмм, может, десяток мегабайт картинок из диалогов?
Нет разумной причины мессенджеру потреблять 300-700 МБ оперативы.

Один только экран в 4К занимает 32 МБ

Обычно эти мегабайты находятся на видеокарте и не идут в счёт.

я не хочу, чтобы программист экономил память и пытался уместиться в 30 МБ, из-за чего программа работает в несколько раз медленнее, а некоторые вещи тупо работают очень медленно.

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

Или взять те же браузеры. Нажимаешь на вкладку и ждёшь 3 года.

У меня вкладки переключаются мгновенно. Люблю Firefox, столько лет жизни мне сэкономил.