Comments 378
Хорошая статья и довольно неудачный заголовок.
Я перевел заголовок оригинала буквально. Думаете, лучше было бы подобрать более подходящий по смыслу, чем сохранить авторский замысел?
Вы неправильно перевели буквально «Electron and the Decline of Native Apps»
the decline of — это упадок, падение, сокращение
https://context.reverso.net/
the decline of — это упадок, падение, сокращение
https://context.reverso.net/
Это тоже верно, но мне кажется debug45 имел в виду не перевод конкретного слова, а то что Electron в названии статьи выглядит как кликбейт, потому что внутри статьи о нем совсем немного.
Возможно, но вряд ли
Ваш заголовок подразумевает типа конспирологию — кто-то решил отказаться от нативных приложений во вред пользователям. Злая воля.
Как заголовок по-английски — нативные приложения не выдерживают конкуренцию у разработчиков по сравнению с приложениями под VM. О чем, собственно, и статья.
Ваш заголовок подразумевает типа конспирологию — кто-то решил отказаться от нативных приложений во вред пользователям. Злая воля.
Как заголовок по-английски — нативные приложения не выдерживают конкуренцию у разработчиков по сравнению с приложениями под VM. О чем, собственно, и статья.
Заголовок — вообще аллюзия на классическую книгу «Decline and fall of the Roman Empire»: Упадок и падение Римской Империи.
Насколько далеко от 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 в этом плане до сей поры держался, но, видать, он тоже начинает капитулировать.
Мак всегда был в этом месте «сдвинутым»: платформа, пропитанная с ног до головы «хождением в ногу» рекламируется как избавитель от Большого Брата… притом что как раз там разработчиков заставили ходить строем.
Нет, я не говорю, что ситуация, когда в одном редакторе (скажем в Microsoft Word) Backspace удаляет символ, а в другом (скажем Turbo Pascal 1.0) не удаялет — прекрасна и удивительна… но это ведь максимально далеко от «колебания вместе с линией Партии», которая, как раз — фирменная фишка MacOs…
Далее, знаменитое: Think Different — ага «выберите цвет своего ноута из списка в один пункт и проихводителя видеокарты из списка такой же длины» очень, ну просто очень… different.
Хотя если вдуматься то вот эта вот странная идея: «выделиться из толпы путём покупки того же, что и все» — она ведь уже столетия модой движет… так что ничего нового тут нет… но всё равно дико…
Нет, я не говорю, что ситуация, когда в одном редакторе (скажем в Microsoft Word) Backspace удаляет символ, а в другом (скажем Turbo Pascal 1.0) не удаялет — прекрасна и удивительна… но это ведь максимально далеко от «колебания вместе с линией Партии», которая, как раз — фирменная фишка MacOs…
Далее, знаменитое: Think Different — ага «выберите цвет своего ноута из списка в один пункт и проихводителя видеокарты из списка такой же длины» очень, ну просто очень… different.
Хотя если вдуматься то вот эта вот странная идея: «выделиться из толпы путём покупки того же, что и все» — она ведь уже столетия модой движет… так что ничего нового тут нет… но всё равно дико…
UFO just landed and posted this here
Упомянуты по мне разные вещи, но вот с точки зрения пользовательского интерфейса
что как раз там разработчиков заставили ходить строем
на мой взгляд лучше, чем разгадывать очередной результат авангардного творчества в том смысле, как что в нём делается. Сам UIKit по мне пока что оставляет желать лучшего, но всё ж меняется в лучшую сторону.
Меня просто позабавили претензии на индувидуальность в системе, построенной вокруг «видения мира», условно, одним человеком — и жёсткого прессинга всех, кто не хочет быть счастливым «так же, как все».
Это не хорошо и не плохо, просто удивляет — примерно как когда жители Северной Кореи начинают рассуждать о том, что вот у них-то, дескать, настоящая свобода и отсутствие притеснений.
Это не хорошо и не плохо, просто удивляет — примерно как когда жители Северной Кореи начинают рассуждать о том, что вот у них-то, дескать, настоящая свобода и отсутствие притеснений.
То есть проблема электрона не в том, что он тормозной и жручий. Не в том, что я должен запускать 25 гуглохромов для 25 приложений. Это всё не проблема, проблема в том, что он не Mac-like. Это единственная проблема, которую надо решить. А в остальном всё ок, пускай чатик занимает полгига памяти.
Очень верно подмечено.
У маководов вообще в большинстве и мышление и оценки через другое место.
Сие не есть плохо или хорошо, просто надо принять это как данность и учитывать в принятии решений.
У маководов вообще в большинстве и мышление и оценки через другое место.
Сие не есть плохо или хорошо, просто надо принять это как данность и учитывать в принятии решений.
Ага, причем что такое mac-like никто сказать толком не может. Ощущения, понимаешь, не те.
UFO just landed and posted this here
Немного потерпим, а там WASM + OpenGL позволят снова писать быстрые приложения не жрущие много памяти, используя браузер как VM.
Помять можно продать — решение проблемы mac-like-style
Имхо… А лично мне после slack, google meat и VSCode кажется, что за этим будущее. Лично меня очень подкупает (в первых двух случаях) полное отсутствие необходимости что-то устанавливать на компьютер, кроме браузера. Да и с функциональностью там полный порядок. Вопрос с бесконечными экземплярами хром решить, и, кажется, все.
А накой тебе устанавливать браузер еще несколько раз, если он с вероятностью 95 % у тебя уже стоит?
МБ потому что «браузер» — это целый пласт программ, и у меня есть альтернатива?
И, если честно, не совсем понял, при чем тут это. Я лишь выразил мнение, что веб интерфейс дорос до такого уровня, что, при качественной реализации, им вполне безболезненно можно пользоваться вместо нативных решений. А иногда он дает и некоторые преимущества в виде отсутствия необходимости что-то дополнительно устанавливать, например.
И, если честно, не совсем понял, при чем тут это. Я лишь выразил мнение, что веб интерфейс дорос до такого уровня, что, при качественной реализации, им вполне безболезненно можно пользоваться вместо нативных решений. А иногда он дает и некоторые преимущества в виде отсутствия необходимости что-то дополнительно устанавливать, например.
Незачем:
Сейчас меня вместе с shm-vadim распнут, но мне тоже очень нравятся приложения на Electron. Может быть, дело в том, что у меня достаточно мощный компьютер, но они ощущаются как более быстрые в работе, чем нативные. Загружаются дольше, чем нативные (не все), но потом работают быстрее. Подозреваю, что это иллюзия, связанная с асинхронностью/анимациями. Но работать с ними приятнее.
Это первое, а второе — большинство Electron приложений, которые я пробовал в последнее время, имеют отличную функциональность по сравнению с нативными аналогами. VSCode, Slack, GitKraken. Может, совпадение, а может — время, сэкономленное наборьбе работе с UI, ушло на дополнительную функциональность.
Дублирование движка Electron в каждой программе становится значительной проблемой производительности. Вместо этого они хотят иметь один на всех экземпляр Electron вместе со своими дополнениями.
Сейчас меня вместе с shm-vadim распнут, но мне тоже очень нравятся приложения на Electron. Может быть, дело в том, что у меня достаточно мощный компьютер, но они ощущаются как более быстрые в работе, чем нативные. Загружаются дольше, чем нативные (не все), но потом работают быстрее. Подозреваю, что это иллюзия, связанная с асинхронностью/анимациями. Но работать с ними приятнее.
Это первое, а второе — большинство Electron приложений, которые я пробовал в последнее время, имеют отличную функциональность по сравнению с нативными аналогами. VSCode, Slack, GitKraken. Может, совпадение, а может — время, сэкономленное на
Еще замечу, что все указанные вами приложения – бесплатные. Разработка хорошего нативного приложения влетела бы в копеечку, и скорее всего, не отбила затраты.
Затраты бы отбились, просто прибыль была бы на целых 20 процентов меньше. Или на 10.
Если там такой запас по прибыли, это ж неосвоенный рынок — надо брать!
Вместо одного кросс-платформенного приложения вы будете писать два специализированных (или даже 3, если еще и Linux). Как это может увеличить затраты всего на 10%, если у вам понадобится содержать в 3 раза больше разработчиков?
UFO just landed and posted this here
На самом деле два:
- https://github.com/telegramdesktop/tdesktop — кросс-платформенная версия на QT
- https://github.com/overtake/TelegramSwift — версия на Swift.
Я пользовался обеими версиями, и вторая работает намного лучше.
1) Берём QT
2) Профит, ибо у нас нативное приложение на всех платформах.
2) Профит, ибо у нас нативное приложение на всех платформах.
Здесь разговор не про нативность с точки зрения бинарного кода, а с точки зрения удобства пользователей. Единообразные горячие клавиши, внешний вид диалогов и меню.
Для этого понадобится писать отдельный платформо-зависимый код, а для этого нужно больше разработчиков.
Для этого понадобится писать отдельный платформо-зависимый код, а для этого нужно больше разработчиков.
Здесь разговор не про нативность с точки зрения бинарного кода, а с точки зрения удобства пользователей. Единообразные горячие клавиши, внешний вид диалогов и меню.
Тут да, но можно настроить QT так, чтобы он выглядел довольно нативно. К тому же, если правильно писать код, то все горячие клавиши настраиваются, а диалоги используются системные.
Можно писать под GNUStep или Cocotron, а под Mac нативно. Лучше Mac-like на Win, чем Win-like на Mac. Яблочники довольны, а вендопользователям, а тем более линукс всё равно не привыкать. В среднем, всем хорошо.
И на каждом дистрибутиве линукса у него будет свой ворох уникальных ошибок при сборке, и на каждой версии 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. Не зря полнятся фрисофты и софтпорталы экзешниками.
На 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 в сегменте прикладного софта. А как делать — кроссплатформенно, или нативно — решать должен в первую очередь бизнес. Если есть бюджеты сопоставимые Дуровским то почему бы и не нанять вдвое больше разрабов и не сделать прям очень круто?
Вообще, как по мне, идея заменить кроссплатформенными решениями нативные очень странная. Electron и прочие — это не замена нативной разработке, это возможность избавиться от Java и Qt в сегменте прикладного софта. А как делать — кроссплатформенно, или нативно — решать должен в первую очередь бизнес. Если есть бюджеты сопоставимые Дуровским то почему бы и не нанять вдвое больше разрабов и не сделать прям очень круто?
Как раз таки из-за производительности я перешел на vsc и удалил sublime — vsc запускался быстрее, искал и заменял быстрее и лучше работал с большими файлами. Да и система дополнений там реализована удобнее имхо
а с vim глупо сравнивать, так как это все таки разные вещи.
а с 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 meat для windows ничего нет. Потому что это не нужно.
То же самое можно сказать про slack. Лично мне полностью хватает браузерного функционала. Так что нет никакого смысла скачивать клиент под windows. Тем более, что он все равно никаких дополнительных возможностей не предоставляет.
Поэтому я и считаю, что за полнофункциональными PWA будущее. Тем более, что для них отдельный экземпляр хрома не нужно будет тащить. Если приложение осуществляет работу исключительно с сетью — ок, пользуй, как веб страничку. Если нужен доступ к системе, как тому же VSCode — предложит в один клик установить локально, и будет запускаться как отдельное окно браузера. При этом все плюсы: кроссплатформенность, унификация, скорость, отзывчивость, расширяемость, доступность останутся. Мне это кажется, как минимум, перспективным.
«google meat» — намечается вкусное собеседование :)
Когда вам что-то нужно один раз и забыть — это один кейс. Когда нужно постоянно и регулярно — совершенно другой, столь же валидный кейс. У браузерных приложений лучше с первым но хуже со вторым, так что отметать все остальное кроме браузерок «не только рано но и никогда»(с)
Да никто, вроде, и не отметает. :) Как по мне, «новые» технологии (если они не совершенно революционные) очень редко убивают «старые». Максимум забирают у них часть рынка. И тут, как мне кажется, будет тоже самое. И в обозримой перспективе js-сингулярность нас точно не ожидает.
А вот по поводу того, что веб-решения плохо подходят для постоянного использования я уже не сильно согласен. Пару лет назад я бы без колебаний подписался под этим высказыванием. Но с тех пор мое мнение постепенно меняется.
А то что и в нативном мире все далеко не гладко, на мой взгляд, хорошо подтверждает то, что под десктопы существует очень мало клиентов популярных веб-проектов. Да и под мобилки они часто толстые, тупые и нефункциональные.
А вот по поводу того, что веб-решения плохо подходят для постоянного использования я уже не сильно согласен. Пару лет назад я бы без колебаний подписался под этим высказыванием. Но с тех пор мое мнение постепенно меняется.
А то что и в нативном мире все далеко не гладко, на мой взгляд, хорошо подтверждает то, что под десктопы существует очень мало клиентов популярных веб-проектов. Да и под мобилки они часто толстые, тупые и нефункциональные.
Ну вот есть у вас 5 постоянно нужных веб приложений и надо перезагрузить браузер. Все они вырубаются и потом сами не начинают работу, пока каждую вкладку отдельно не кликнешь. При этом браузер сжирает всю оперативку и уже начинает вылезать из компа, чтобы задушить вас. Короче неудобно все держать в браузере. А ещё электронные приложения любят ни с того, ни с сего выжирать ядро процессора.
Люди почему-то очень любят отдельные приложения. Вон даже у хабра есть мобильное приложение (у портала со статьями) и его все активно просили, а теперь просят его обновлять.
При этом объяснить зачем им отдельное приложение никто обычно не может. Есть какое-то полу-суеверное мнение что в браузере все «не стабильно», а в приложении как-то «надежнее».
При этом объяснить зачем им отдельное приложение никто обычно не может. Есть какое-то полу-суеверное мнение что в браузере все «не стабильно», а в приложении как-то «надежнее».
На смартфоне держу приложения онлайн банка, али, ибэй, youtube… Они работают быстрее, присылают оповещения, плавнее работает интерфейс. Да и заточены они под мобилку лучше, чем даже mobile версия сайта.
Я говорю про случаи когда есть полная альтернатива в форме веб приложения, особенно если это альтернатива для десктопа.
Банкинг и ютуб — тебуют наличия всяких нативных штук (хотя пока из ютуба не выпилили воспроизведение звука в бэкграунде — я пользовался веб версией)
Али нe пользовался, у ибэя действительно убогий сайт (и не только мобильный)
Фишка браузера в том — что это и есть унифицированный интерфейс для всех приложений. Везде можно нажать «назад», зумить, выделить текст, открыть ссылку в новой вкладке, поделиться url'ом, сохранить картинку и т.д.
Банкинг и ютуб — тебуют наличия всяких нативных штук (хотя пока из ютуба не выпилили воспроизведение звука в бэкграунде — я пользовался веб версией)
Али нe пользовался, у ибэя действительно убогий сайт (и не только мобильный)
Фишка браузера в том — что это и есть унифицированный интерфейс для всех приложений. Везде можно нажать «назад», зумить, выделить текст, открыть ссылку в новой вкладке, поделиться url'ом, сохранить картинку и т.д.
Если про десктоп, то клиент Telegram, к примеру, я всё-же предпочёл нативный. Меньше открытых вкладок в хроме, висит в трее и не мешает. YouTube предпочитаю смотреть через PotPlayer. Пробовал онлайн 3D редакторы. Лаги/мало функций. Музыка — через нативный плеер (хоткеи/функции). Да, я из тех, кто любит отдельные приложения. Ну серьёзно, они работают быстрее и функций в них больше.
Да, я из тех, кто любит отдельные приложения. Ну серьёзно, они работают быстрее и функций в них больше.Ну дык за это их и любят… но современная тенденция это «жрите что дают… хотели „нативного приложения“?.. мы вам браузер с нашим веб-сайтом изолентой смотаем и скажем, что это — нативное приложение...»
Ненавижу…
когда есть полная альтернатива в форме веб приложения
Простите, но это как опрос «пользуетесь ли вы интернетов» проводить через сайт.
унифицированный интерфейс для всех приложений
Проблема в ненормальном стремлении браузеров стать эдакими операционными системами — мы получаем слой абстракций на ровном месте.
Простите, но это как опрос «пользуетесь ли вы интернетов» проводить через сайт.
Не очень понял, почему?
Проблема в ненормальном стремлении браузеров стать эдакими операционными системами — мы получаем слой абстракций на ровном месте.
Не на ровном месте. «write once, run anywhere»
Ну так вы требуете «полную альтернативу в виде веб-приложения», а она не всегда есть, не всегда нужна, у всех разные приоритеты. Редко когда и сайт, и приложение выходят полноценными — кого-то да обделят функциями. Иногда до смешного: долго не мог понять, почему коллеги ругают приложение Банка Москвы. Оказалось, что в iOS версии перевод клиентам пары десятков банков был сделан вполне нормально, а вот на Android чтобы в сам банк Москвы отправить перевод, нужно было вводить БИК, КПП и корсчета заполнять.
Просят его написать. Когда я его последний раз запускал, оно могло «на главной» показывать статьи недельной давности и даже полная версия сайта на каком-нибудь GPRS загружалась быстрее. Как они так смогли — не понимаю.
у хабра есть мобильное приложение… просят обновлять
Просят его написать. Когда я его последний раз запускал, оно могло «на главной» показывать статьи недельной давности и даже полная версия сайта на каком-нибудь 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. Начинаешь пользоваться и сразу утыкаешься в то, что разработчик приложения не живёт в экосистеме мака и сделал клон потому что может. Основная беда — не работают привычные шорткаты, часто их даже нельзя задать, поскольку мало кто за пределами мака знает, например, про cmd+E. Пункты меню напиханы как захотелось разработчику — чтобы что-то найти, приходится искать, и хорошо, если есть поиск в хелпе. Контролы на окно набросаны «чтобы было», а не в соответствии с гайдлайнами — выглядит примерно как сайт из 90-х.
UFO just landed and posted this here
немного надумано
Вам, конечно, видней.
Если разработчику
насколько мне известно разработчик не решает задачи этого уровня, а бизнесу важно поставить галочку минимальными усилиями
Разве QT не позволяет написать нативный интерфейс OSX?
Можно, но, как уже было сказано выше, подавляющему числу кроссплатформенных проектов недостаёт понимания культуры платформы, проще говоря сделано по принципу «так сойдёт».
Не позволяет
UFO just landed and posted this here
Мне кажется, речь не только о Mac. Проблема более широкая, это же происходит и в Win и в мобилах. Разработчикам удобно написать один раз и потом запускать где угодно (такой почти Java лозунг). Microsoft, следуя известной мудрости, перестала бороться и решила возглавить. И это даже не смотря на то, что фактически это означает смерть для своих средств разработки (WinForm, WPF).
А что пользователи, почему они это терпят? Мне кажется, дело в массовом проникновении web. Во времена Word 6, html был настолько уродлив, что по интерфейсу он и близко не мог конкурировать с десктопом. Сейчас все изменилось, некоторые веб приложения функционально и особенно визуально стали не хуже нативных приложений. Этих приложений стало очень много, пользователи научились работать с разными приложениями и «нативность» и следование гайдам осталась нужна далеко не многим. В результате имеем то, что имеем. Сейчас это стало похоже на вывески и рекламу в провинциальном городе — каждый лепит, что хочет, да поярче. Упорядочить это будет сложно, т.к. приложение пишется под сильно разные целевые ОС.
А что пользователи, почему они это терпят? Мне кажется, дело в массовом проникновении web. Во времена Word 6, html был настолько уродлив, что по интерфейсу он и близко не мог конкурировать с десктопом. Сейчас все изменилось, некоторые веб приложения функционально и особенно визуально стали не хуже нативных приложений. Этих приложений стало очень много, пользователи научились работать с разными приложениями и «нативность» и следование гайдам осталась нужна далеко не многим. В результате имеем то, что имеем. Сейчас это стало похоже на вывески и рекламу в провинциальном городе — каждый лепит, что хочет, да поярче. Упорядочить это будет сложно, т.к. приложение пишется под сильно разные целевые ОС.
UFO just landed and posted this here
Во времена Word 6, html был настолько уродлив, что по интерфейсу он и близко не мог конкурировать с десктопом.Времена Word 6 — это, я извиняюсь, 1993й год, тогда про HTML только в CERN'е знали и с интерфейсом у него было чуть более, чем никак. Браузер был только один, второй появился плюc-минус тогда же и в нём только-только появился тег <img>…
В общем говорить об это как об интерфейсе приложений — было нельзя от слова «совсем».
Сейчас это стало похоже на вывески и рекламу в провинциальном городе — каждый лепит, что хочет, да поярче.То же самое было в 80е в мире MS-DOS и CP/M.
Однако появление MacOS и Windows всё изменило… осталось только понять — как и почему.
Так-то винформам давно пора на покой.
Я вообще непонимаю, почему пользователи не замечают еще проблему во всем, что основано на Chromium. Если у кого мощный компьютер, безусловно можно игнорировать большое потребление ресурсов, но как можно игнорировать эти уродливые размытые и бледные шрифты (по крайней мере на Windows)? При чем, чтобы сделать их не бледными, достаточно просто при сборке Skia (библиотека рендеринга, используемая Chromium) указать другую константу гамма-коррекции.
Я думал это только у меня с компом/монитором какой-то баг с этими шрифтами…
Насчет мощности.
Пересел как-то с 6-гигового ноута на 16-гиговый, проц тоже в пару раз помощней. Рабочее окружение такое же. Через пару недель выскакивает окошко: «Недостаточно памяти. Закройте то-то»
Офигевая лезу в диспетчер — да, почти вся память съелась тем же Хромом, немного остальным.
Это Винда. Она щедро распределяет все, что имеет, и ее не насытить. И определенная логика в этом есть.
Насчет мощности.
Пересел как-то с 6-гигового ноута на 16-гиговый, проц тоже в пару раз помощней. Рабочее окружение такое же. Через пару недель выскакивает окошко: «Недостаточно памяти. Закройте то-то»
Офигевая лезу в диспетчер — да, почти вся память съелась тем же Хромом, немного остальным.
Это Винда. Она щедро распределяет все, что имеет, и ее не насытить. И определенная логика в этом есть.
Не. Это не Винда. Это именно Хром. У меня на 4 гигах месяцами аптайм Win7 бывает, без всяких утечек памяти. Просто я не держу браузеры на хромиуме всё время открытыми…
Хром, но квотирует ему место Винда. Если бы он сам себя ограничил гигом — тогда да, но он грит: «мне чем больше, тем лучше». И это логично. Винда видит кучу памяти, и щедро раздает всем сестрам по серьгам. А Хром не в курсе, что у тебя там ИДЕ-шка твоя уже свопает. Ему дали, он жрет, чтобы более качественно отрисовать бледными шрифтами тебе какой-нить важный контент.
Вот так, я думаю, виндоуз ресурс скедьюлер работает.
Вот так, я думаю, виндоуз ресурс скедьюлер работает.
скорее всего винда, у меня ноутбук Linux mint, 16ГБ ОЗУ, постоянно хром запущен с 15-20 выкладками, ещё запущен vscode, бывает что запускаю на VMware workstation, виртуалки на CentOS, и ни разу никаких проблем. Так что дело видимо в виндах
Целых 16 гиг и всего 20 вкладок? Так у вас просто запросы скромные. Опера (старая, на престо) без проблем показыва 200 и при этом ела не больше гига. Почему-то ни один современный браузер на такое не способен. Зато стильно-модно-молодёжно.
Современные браузеры как минимум намного больше заботятся о безопасности и стабильности, что требует больше памяти. Процесс на вкладу это дорого, но необходимо.
Только почему-то на момент существования в опере было меньше уязвимости чем в любом другом (может конечно просто не искали — доля рынка маленькая), а по стабильности она была лучше чем все ныне существующие вместе взятые. Впрочем, это всё равно не имеет значения, уже похоронили. Простите мне моё брюзжание, мне стоило воздержаться от комментариев.
И не искали, и интернет другой был раньше. Сейчас совсем другие времена настали. Не от хорошей жизни все на webkit перелезли и бросили писать движки сами.
Да, не от хорошей жизни. Только от жадности и лени.
Скорее от понимания, что поспевать всем со своими движками за современным интернетом не получается. Интернет стал слишком сложным, а с ним и движки браузеров. Поэтому люди бросили эту затею и решили влиться в общее коммьюнити, чтобы сделать один движок хотя бы нормально.
Нет. Можно добится отсутствия уязвимостей высоким качеством кода, а можно переложить эти задачи на программу (читай — на мользовательский пк). Повысить касество кода — солжно и дорого, получить "безопасность" ценой увеличения нагрузки на пользочательский ПК — легко и дёшево. А люди жадные и ленивые. Результат немного предсказуем.
Да. Качество кода не гарантирует отсутствие уязвимостей, они неизбежно будут. Изоляция процессов это необходимая мера, чтобы минимизировать ущерб. Тоже самое касается банальных крашей и зависаний — они всегда могут всплыть на таких объемах кодовой базы, хоть как ты хорошо код пиши. Недеяться на свой программерский скилл и плевать на базовые меры безопасности — это уже будет наплевательское отношение к безопаности пользователей.
И много вы выдели программ, где добились отсутствия уязвимостей «высоким качеством кода»?
Я знаю один пример — но он очень показателен. Загрузчик Wii. 8K кода. Очень простого кода. Без GUI и многозадачности. Загрузить загрузчик второго уровня, проверить подпись и запустить. Всё.
На устранение всех ошибок ушло три года.
Как вы думаете — сколько времени уйдёт на устранение всех ошибок в программе размером с современный браузер? Если экстраполировать?
Я знаю один пример — но он очень показателен. Загрузчик 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.
Что, правда чтоли? https://habr.com/post/249537/
Да, правда что ли. По вашей ссылке код, который не имеет никакого отношения к heartbleed. Один глупость написал, другой не думая скопипастил. Суть heartbleed в чтении памяти за пределами массива из-за отсутствия проверки длины. То, что в Rust и любом другом современном безопасном языке сделать невозможно.
Обходиться можно и ассемблером.Грустный опыт разработчиков OS Menuet/Kolibri как бы показывает нам, что нельзя.
И, к слову, Windows 98 была довольно стабильна. Как минимум сней у меня было меньше проблем чем с NT 3 (или 3.5? я уже и не помню. четвёрка уже была гораздо лучше, хотя вроде та же архитектура).
Win9x:
жмешь «закрыть»… а оно опять… ещё раз… синий экран… нажмите любую кнопку… оо, работает
===
забыли уже?
Ваш коврик выполнил недопустимую операцию и был свернут
жмешь «закрыть»… а оно опять… ещё раз… синий экран… нажмите любую кнопку… оо, работает
===
забыли уже?
Не знаю о чём вы. Win98 стояла лет десять, за это время бсодов наверно штук десять было, и всегда это было связано с тем, что я проводил какие-то бесчеловечные опыты. Вот Win95 это была жесть, да.
тут такойже эффект как у владельцев БУ авто которые говорят что они не ломаются, просто сравнить не с чем
поставьте себе Win98 и посидите недельку ;) я пару лет назад тут на старый комп ставил 98… прям как в прошлое вернулся и «выполнило недопустимую операцию» и все все радости 9x
раньше это просто было настолько нормой что внимание не обращали
p.s. сидел на винде с 3.0 версии довольно долго, на каждой кроме me и nt 3
поставьте себе Win98 и посидите недельку ;) я пару лет назад тут на старый комп ставил 98… прям как в прошлое вернулся и «выполнило недопустимую операцию» и все все радости 9x
раньше это просто было настолько нормой что внимание не обращали
p.s. сидел на винде с 3.0 версии довольно долго, на каждой кроме me и nt 3
Браузер, по своей важности и степени внедрения ни капли не уступает ОСям. Соответсвенно, подходить к вопросу нужно ответсвенно. Процессы в системах существуют не для безопасности, а что-бы программы хостить.
Те, кто заботятся о безопасности, и те, кто пишут на C++, — это непересекающиеся множества.
К памяти можно было бы относиться более бережливо, если б были счётчики ссылок и слабые ссылки, и только на крайние случаи сборщики мусора. Но за столько лет в JavaScript так и не сделали слабые ссылки.
Плевать там все хотели и на безопасность, и на потребение памяти.
К памяти можно было бы относиться более бережливо, если б были счётчики ссылок и слабые ссылки, и только на крайние случаи сборщики мусора. Но за столько лет в JavaScript так и не сделали слабые ссылки.
Плевать там все хотели и на безопасность, и на потребение памяти.
Если бы было плевать, то не делили бы хром на кучу процессов и засовывали это все в песочницу. Это большие сложности, а цель у всего одна — изоляция вкладок и расширений, чтобы браузер был стабильнее и безопаснее.
Память это необходимый компромисс. Безопасность не дается бесплатно. Она так или иначе требует компромисса — или безопасно, или быстро. По-другому в нашем мире не бывает.
Память это необходимый компромисс. Безопасность не дается бесплатно. Она так или иначе требует компромисса — или безопасно, или быстро. По-другому в нашем мире не бывает.
Если б не было плевать, писали браузер на Аде. Что-то я такой реальной заботы о безопасности не наблюдаю. Больше похоже на симуляцию бурной деятельности.
Память там отъедается мощно трассирующей сборкой мусора. Про то, как надёжно запечатаны двери в светлое будущее, где счётчиками ссылок и слабыми ссылками сберегается память, я уже написал.
Память там отъедается мощно трассирующей сборкой мусора. Про то, как надёжно запечатаны двери в светлое будущее, где счётчиками ссылок и слабыми ссылками сберегается память, я уже написал.
Вы по существу может лучше напишете, а не демагогию будете разводить? Сделано это для безопасности и стабильности, это факт. Зачем пишут на плюсах — потому что на тот момент лучшей альтернативы на руках не было, webkit черт знает сколько лет уже. Сейчас появилась — Rust, мозила его специально даже для этого и делала. Правда не думаю, что это полностью исключит необходимость в изоляции вкладок процессами. Теже зависания все равно могут вылезти и уж лучше пусть повиснет один процесс с одной вкладкой.
По существу процессы отнюдь не такое дорогое удовольствие. Операционные системы умеют shmem и mmap, и даже при ASLR умеют кешировать версии с релокациями. А вот трассирующая сборка мусора висит камнем на шее. Чтобы имело смысл проводить трассирующую сборку мусора, мусорить нужно обильно, в 5 раз больше, чем реально используется памяти. И без слабых ссылок всё ещё хуже.
Альтернатива плюсам существует 23 года, ещё когда никакого Rust в проекте не было, и это Ада. Вообще, первый, кто задумался о безопасности в языках программирования, — это Никлаус Вирт. Это он первый придумал проверять границы и переполнения. И это был язык Паскаль. И естественным образом это унаследовано потомками Паскаля.
За слепошарых мозилловцев ничего не могу сказать. Ну, странные люди.
Альтернатива плюсам существует 23 года, ещё когда никакого Rust в проекте не было, и это Ада. Вообще, первый, кто задумался о безопасности в языках программирования, — это Никлаус Вирт. Это он первый придумал проверять границы и переполнения. И это был язык Паскаль. И естественным образом это унаследовано потомками Паскаля.
За слепошарых мозилловцев ничего не могу сказать. Ну, странные люди.
А теперь по-думайте по-лучше. Процессы дешевые сами по себе, а браузеру нужно эти процессы поддерживать как единое целое, да еще обеспечивать должную изоляцию. Это значит будет много дублированных данных в каждом процессе, а их у браузера может быть великое множество. Отсюда запросто повышенные требования к памяти.
Ну и давайте уже какие-то пруфы про трассирующую эту сборку. Ваши фантазии читать не особо интересно.
Что до Ады, беглый гуглинг говорит, что для данной задачи оно не подходит, т.к. безопасность уровня Rust не дает. Есть даже предложение внести что-то подобное Rust в аду, чтобы эту безопасность получить. Ну и, если бы webkit начали писать на этом языке, то можно было быть уверенным, что до наших дней он бы не дожил, т.к. его бы некому было писать. C++ был явно выбран, потому что на то время это был единственный высокоуровневый быстрый язык с большой популярностью. Судя по рейтингам, тогда он проигрывал в популярности только С.
Ну и давайте уже какие-то пруфы про трассирующую эту сборку. Ваши фантазии читать не особо интересно.
Что до Ады, беглый гуглинг говорит, что для данной задачи оно не подходит, т.к. безопасность уровня 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 или Эльбруса, то остаётся такой радикальный способ, как изолироваться от плюсовой лажи границами процесса. Там, в компостной яме изолированного процесса пусть всё протекает и гниёт как хочет, а граница процесса удерживает гниль от распространения. Но эти границы вроде бы тоже чего-то да стоят по памяти.
Например, CCured, CHERI и Эльбрус делают указатели разбухшими до четырёх раз, накачивая метаданными, но зато становится возможно проверить валидность. В автоматическом режиме, не переписывая на Аду, принудить код Си и C++ к корректности можно только так.
Возможность починить состояние: если лажу оперативно выявлять и пресекать, то и нечего чинить, а вот если крутится Си или C++, без CCured, CHERI или Эльбруса, то остаётся такой радикальный способ, как изолироваться от плюсовой лажи границами процесса. Там, в компостной яме изолированного процесса пусть всё протекает и гниёт как хочет, а граница процесса удерживает гниль от распространения. Но эти границы вроде бы тоже чего-то да стоят по памяти.
Это общее наблюдение, которое справедливо практически для всего. Бесплатно обычно ничего не дается. Если делаем безопасно, то чем-то приходится жертвовать в обмен. Как пример с изоляцией через процессы — это дает накладные расходы по памяти неизбежно. Песочница какая-нить — накладные расходы на перехват всех системных вызовов, дополнительные драйвера, процессы и чего еще там может быть. Шифрование — требует больше вычислительных ресурсов. Везде приходится идти на компромисс и жертвовать памятью или скоростью исполнения.
Но зачастую просадку в производительности можно (хотя бы теоретически) сделать маленькой.
Например, песочница для браузера, может быть выполнена (я не знаю, есть ли такая опция в современных ОС, но сделать ее точно можно) как процесс, которому запрещены все системные вызовы. Память выделается один раз, при старте. Сеть/файлы — через общую память с мастер-процессом. Получается довольно быстро (проблемы только с вводом выводом) и довольно безопасно(надо один раз подумать и качественно обрабатывать shared memory).
Шифрование — можно реализовать аппаратно, и оно начинает работать быстро.
Накладные расходы на процессы довольно невелики. (НЯП, там только стек, и несколько килобайт в ядре).
Кроме стоимости осязаемой стоит еще посчитать стоимость на написание этого всего дополнительного и его поддержку. Вон песочница самодельная в хроме периодически ломалась, т.к. они используются что-то недокументированное в винде. Межпроцессные взаимодействия штука всегда сложная и хрупкая, по себе знаю. Отлаживать это все очень неприятно.
Судя по хрому, накладные расходные на их процессы довольно велики. И я совсем отказываюсь верить, что там прям из рук вон плохо все сделано и можно было ужать каждый процесс в 10МБ. Даже если убрать их сборщик мусора.
Судя по хрому, накладные расходные на их процессы довольно велики. И я совсем отказываюсь верить, что там прям из рук вон плохо все сделано и можно было ужать каждый процесс в 10МБ. Даже если убрать их сборщик мусора.
Опера (старая, на престо) без проблем показыва 200 и при этом ела не больше гига.Тут ещё надо учесть, что те двести вкладок совсем другие были, интернет был совсем обезжиренным по нынешним меркам. Хотя хром и правда любит покушать, конечно.
UFO just landed and posted this here
Сравните текст в полях ввода Firefox сверху и Vivaldi снизу. То же самое происходит и со шрифтами на самих страницах. То, что в Firefox черное, в chrtomium-based браузерах и electron-приложениях темно серое.
Что-то не вижу я на винде таких шрифтов. Все четкое и контрастное. Тоже самое с vscode. Там читаемость шрифтов шикарная.
UFO just landed and posted this here
Может, вам просто нужно настроить ClearType? Мне в какой-то момент тоже шрифты в системе стали казаться стремными, потом потыкал в картинки в настройщике и все стало классно. Кроме того, не факт, что дело в рендеринге хрома или неправильной гамме — вполне вероятно, что в адресной строке банально задан не true black, а серый для шрифта.
Корпорация добра успешно двигается к мировому господству. Помимо новости о том что Microsoft больше не будет разрабатывать свой движек, стоит упомянуть успешное продвижение языков и технологий, например go, а теперь еще и flutter релизнулся.
Вспомните как работало ПО и игры на новеньких Pentium 166x 128MB RAM, HDD 40Gb!
Аналогичное ПО и игры теперь весят в 10-ки раз больше, виртуализируются по 10 раз подряд, до вывода на экран.
Аналогичное ПО и игры теперь весят в 10-ки раз больше, виртуализируются по 10 раз подряд, до вывода на экран.
Зато работают на 10 платформах, а не только на одной. Именно фрагментация — причина существования таких технологий, как Electron. Если когда-нибудь останется всего одна платформа, он загнётся даже быстрее, чем появился, потому как в нём больше не будет смысла.
Но программисты решили, что уж лучше терпеть Electron, чем монополию, а чего там хотят пользователи — то уже лет 15 как никому не интересно.
Но программисты решили, что уж лучше терпеть Electron, чем монополию, а чего там хотят пользователи — то уже лет 15 как никому не интересно.
То, что разработчикам не интересно мнение пользователей это понятно, главное написать красивый лендинг, продающий ПО, а как там уже реально он будет тупить — это уже решится апгрейдом компа клиента. Насчет мультиплатформенности, тут тоже все зависит от профессиональности разработчика, т.к. неоптимизированный код все равно будет по-разному работать на всех платформах.
При этом я не против elecrton-ов и аналогичных web-движков, просто все чаще их суют просто потому, что по-другому уже не умеют.
При этом я не против elecrton-ов и аналогичных web-движков, просто все чаще их суют просто потому, что по-другому уже не умеют.
UFO just landed and posted this here
Из немаркетинговых доводов, которые я видел, в браузере реализовано автоматическое открытие клавиатуры при навигации по полям с планшета типа Surface Pro, а на обычном GUI с osk.exe не смогли разобраться, или в чём-то таком проблема.
Но вообще проблема в том, что хочется всё и сразу, и веб, и не веб. И Электрон позволяет это, но тогда нужно прогнуться под правила веб. А нет такого решения, чтоб, наоборот, прогнуть веб, а на десктопе и сервере было всё хорошо, как обычно.
Что можно было брать QIP'ы и The Bat! ы, с многопоточностью на мониторах, а не на хоаровских сообщениях, и загонять в веб, каких бы костылей это ни стоило. Я пытаюсь сделать это темой своей магистерской работы.
Но вообще проблема в том, что хочется всё и сразу, и веб, и не веб. И Электрон позволяет это, но тогда нужно прогнуться под правила веб. А нет такого решения, чтоб, наоборот, прогнуть веб, а на десктопе и сервере было всё хорошо, как обычно.
Что можно было брать 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
У меня был Celeron 333, 64Mb RAM, 8Gb HDD. А Celeron вышел значительно позже Pentium 166x
А при чем тут максимальные конфигурации? При выпуске с333 p166 все еще были в продаже, соответственно, могли быть подмешаны накопителями побольше. Да и вообще, это не принципиально, писал по памяти. Если говорить про 1-8Гб HDD, то тем более, в то время этого хватало на все, кроме тяжелых игр и видео (это все запускалось прямо с CD). Сейчас же на 1.5 гига будет приложение, функционалом на 1.5 Мбайт, тянущее за собой кучу фреймворков, библиотек ресурсов (используемых на 1%), еще и интерфейс рисуется браузером. Это хорошо когда все оптимизировано, но ведь каждый второй программист считает что, действительно, достаточно сконцентрироваться на решении поставленной задачи, а если будет тормозить — пусть купят комп пошустрее.
UFO just landed and posted this here
Это и сейчас так есть. Вот пример создания 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 как родной набор команд? Вы в курсе для начала, что он стековый, а это как-то и раньше не прижилось.
Эмуляция 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-биткода.
Оно даже работает… но мало кого волнует…
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 приложения, хотя там запрос меньше.
Первый транслятор Wasm был конвертером из Asm.js
И люди, которые Wasm подняли, вроде те же, что и за Asm.js.
А PNaCl? Пока он только в одном браузере, это ни о чём было. Вот FlasCC — другое дело.
И я не видел, чтоб там QIP, The Bat!, Total Commander или ещё какое-то типичное десктопное приложение «спокойно» портировалось в веб с помощью одной из этих технологий. Даже под Linux с большим спокойствием портировали с Windows приложения, хотя там запрос меньше.
UFO just landed and posted this here
Каждый раз, как читаю про рак electron, убивающий desctop, всё никак не могу понять, это правда серьёзно? Если бы не было Электрона, то вместо «1000 тормозных поделий на JS» не было бы «1000 прекрасных программ на С++». Большей части из этих приложений не было бы вообще ни в каком виде.
Большей части из этих приложений не было бы вообще ни в каком виде.
*смотрит на Slack* Не уверен, что это такая уж проблема…
Пусть бы и дальше они оставались вкладками браузера, зачем это тащить и продвигать на десктопе? Особенно, на базе самого жрущего в мире браузера…
Большей части из этих приложений не было бы вообще ни в каком виде.А почему вы-таки считаете, что это было бы плохо?
Те 5 или 10 приложений, которые не являются заменой давно существующим приложениям для десктопа «с новыми перламутровыми пуговицами» — появились бы всё равно, а очередной ICQ, жрущий в 10 раз больше, чем и без того дико жрущий официальный клиент… он нам точно нужен?
Имхо: распространение такого типа приложений — это хорошо — все упрощается. Но вот не помешало бы что бы каждое приложение не тащило вместе с собой браузер. Имхо, достаточно было бы указать его в зависимостях, и если его нет в системе — поставить. 1 браузер на все приложения. И, так как сейчас тенденция в больших объемах JS — неплохо бы все же максимально заоптимизировать js машины, добиться максимальной производительности, и умеренного потребления ресурсов.
Имхо, не за горами день, когда весь софт на обычном устройстве (спецсофт не в счет) будет написан на JS. Это прекрасно — однообразие, достаточно простой вход. Не без другой стороны медали. А вот UI перестраивать под систему, под которой исполняется было бы не плохо, ибо, имхо, это не сврехзадача.
Имхо, не за горами день, когда весь софт на обычном устройстве (спецсофт не в счет) будет написан на JS. Это прекрасно — однообразие, достаточно простой вход. Не без другой стороны медали. А вот UI перестраивать под систему, под которой исполняется было бы не плохо, ибо, имхо, это не сврехзадача.
На тему единого движка на все приложения у Google уже есть экспериментальное решение: github.com/GoogleChromeLabs/carlo
Похожее на Electron API, только использует установленный в системе Chrome, а не несет свой на борту.
Похожее на 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 не популярны
Яблокам что-то навязать/доказать — что-то из разряда просто нереального
Майкрософт — тоже не реально.
Так что, что бы это случилось — не знаю что должно произойти.
Мелкие системы типа chrome os 0 не популярны
Всем этим вебоненавистникам немного не хватает понимания, что именно спрос рождает предложение, а не наоборот. Да и хейт немного странный. VSCode занимает на жестком диске почти гигабайт, да. Но не пофиг ли в век террабайтных жестких дисков и оптики в каждом доме? Я готов платить такую цену в обмен на апдейты два раза в месяц и постоянные улучшения.
Я готов платить такую цену в обмен на апдейты два раза в месяц и постоянные улучшения.
Зачем эти «постоянные улучшения», если есть уже максимально улучшенный emacs, в котором тысячи режимов, дополнений и настроек?
VSCode из коробки это дебаг приложений Node.js, умная подсветка в том числе TS, ESLint и Emmet. А еще Git и современный интерфейс. А сколько времени нужно потратить что бы это все заработало в Emacs?)
Около недели. Зато вы получаете быстрый, полноценный редактор, настроенный под ваши нужды, возможность работы с клавиатуры и очень высокую расширямость. Без Electron.
VSCode такой милый не из за электрона, а команды разработки, которая позаботилась о вас.
UFO just landed and posted this here
Что такое скорость и функционал, объясните недалекому? Быть может вим умеет сам верстать прямо из макета?) Вот слабо хоть пяток конкретных примеров привести?
UFO just landed and posted this here
Пока вы будете это две минуты делать — я в вскоде сделаю то жe самое мультикурсором не притрагиваясь к мышке за полминуты. И так далее…
То что ваш коллега не умеет пользоваться своим редактором — редактор никак нe характеризует.
То что ваш коллега не умеет пользоваться своим редактором — редактор никак нe характеризует.
UFO just landed and posted this here
Ну значит ни вы, ни ваш коллега мультикурсором пользоваться не умеете.
Вообще это дурацкое заблуждение вимеров, что все остальные мышью по экрану водят и через менюхи все делают. Шорткаты есть во всех редакторах. Я к мыши почти не притрагиваюсь во время работы.
Можно пример?
Вообще это дурацкое заблуждение вимеров, что все остальные мышью по экрану водят и через менюхи все делают. Шорткаты есть во всех редакторах. Я к мыши почти не притрагиваюсь во время работы.
Мультикурсор — это только небольшая часть того, что я делаю за 2 минуты
Можно пример?
То что я делаю за 2 минуты, коллега на студии код делает за 10 минут.
А почему коллега не пересаживается на emacs?
UFO just landed and posted this here
И он не готов отказаться от мыши, ради пятикратного увеличения скорости работы?
UFO just landed and posted this here
Да, конечно его, просто любопытно, как он для себя это формулирует.
Типа — да, я понимаю, что мог бы работать в 5 раз быстрее, но возможность использовать мышь для меня так важна, что я готов отказаться от этого?
Что должно быть в голове у человека, который добровольно отказывается от пятикратного увеличения производительности и, думаю, где-то двухкратного увеличения зарплаты?
И встроенный психолог, который спасёт после попытки запомнить это всё :-)
Зачем запоминать всё? Настраиваем под себя, мучаемся неделю, работаем, пока не надоест. Повтряем.
Но в чем смысл, если в vs code все работает сразу, хорошо и быстро?
Потому что быстрее и возможностей настроить под себя гораздо больше. И нативно.
А что быстрее? VSCode устанавливается за минуту, а вы же сами говорите на Emacs неделю только на настройку нужно.
А смысл от вашей нативности? Ну какой от нее смысл? Где ее преимущества в повседневных задачах? Я вот сколько не смотрю одни минусы вижу.
настроить под себя
Можете объяснить что вы под этим понимаете? Желательно примерами.
Хорошо. 1) У меня мои логины/пароли к гиту хранятся в SSHASKPASS. Когда я делаю git push в vscode, он не подхватывает AskPass и такой настройки я не нашёл. В emacs я просто ставлю magit и в связи с нативностью он правильно подхватывает мой Askpass и не спрашивает лишний раз пароль.
2) Подсветка синтаксиса и автодополнение сделаны по-человечески, расширямо. Плюс поддерживается гораздо больше языков (включая редкие), чем в VSCode.
3) Весь интерфейс изменяется, можно сделать всё что угодно от просто поля ввода даже без строки статуса до обвешанного разной информацией и украшательствами монстра.
4) Работает в текстовом режиме.
5) Умеет нормально открывать удалённые файлы
6) Конфигурация пишется не на ущербном JS, а на функциональном Lisp.
2) Подсветка синтаксиса и автодополнение сделаны по-человечески, расширямо. Плюс поддерживается гораздо больше языков (включая редкие), чем в VSCode.
3) Весь интерфейс изменяется, можно сделать всё что угодно от просто поля ввода даже без строки статуса до обвешанного разной информацией и украшательствами монстра.
4) Работает в текстовом режиме.
5) Умеет нормально открывать удалённые файлы
6) Конфигурация пишется не на ущербном JS, а на функциональном Lisp.
Это вы привели список фич, a не то как можно под себя настроить редактор.
Не знаю насчет этого случая, прокомментировать не могу.
Ни разу еще не встречал язык, который не поддерживается Кодом, даже всякие очень специализированные есть (вроде .peg)
В Коде автодополнение и подсветка тоже расширяемы. Можно добавлять свои / менять существующие. Или я чего-то не понимаю?
Согласен, в Коде меньше кастомизации структуры ui, но честно сказать — кому надо оставлять только строку ввода. В настройках в Коде можно отключать/добавлять разные панели.
Это не пример улучшения, а факт. Вы разрабатываете в текстовом режиме? (я так понимаю имеется в виду работа прямо в терминале)
ВСКод тоже.
В Коде конфигурация на json, плагины на js.
И я считаю использование распространенного языка для плагинов — плюсом, а не минусом, куча разработчиков и готовых решений. Лисп красивый язык, но писать на нем плагины — звучит не очень.
И опять же, примером того как редактор можно настроить под себя (ваш главный аргумент) — только пункт 3. Это все?
1) У меня мои логины/пароли к гиту хранятся в SSHASKPASС
Не знаю насчет этого случая, прокомментировать не могу.
2) Подсветка синтаксиса и автодополнение сделаны по-человечески, расширямо.
Плюс поддерживается гораздо больше языков (включая редкие), чем в VSCode.
Ни разу еще не встречал язык, который не поддерживается Кодом, даже всякие очень специализированные есть (вроде .peg)
В Коде автодополнение и подсветка тоже расширяемы. Можно добавлять свои / менять существующие. Или я чего-то не понимаю?
3) Весь интерфейс изменяется, можно сделать всё что угодно от просто поля ввода даже без строки статуса до обвешанного разной информацией и украшательствами монстра
Согласен, в Коде меньше кастомизации структуры ui, но честно сказать — кому надо оставлять только строку ввода. В настройках в Коде можно отключать/добавлять разные панели.
4) Работает в текстовом режиме.
Это не пример улучшения, а факт. Вы разрабатываете в текстовом режиме? (я так понимаю имеется в виду работа прямо в терминале)
5) Умеет нормально открывать удалённые файлы
ВСКод тоже.
6) Конфигурация пишется не на ущербном JS, а на функциональном Lisp.
В Коде конфигурация на json, плагины на js.
И я считаю использование распространенного языка для плагинов — плюсом, а не минусом, куча разработчиков и готовых решений. Лисп красивый язык, но писать на нем плагины — звучит не очень.
И опять же, примером того как редактор можно настроить под себя (ваш главный аргумент) — только пункт 3. Это все?
Всё это — настройка под себя, даже если оно работает из коробки. Такая возможность есть, я ей пользуюсь, значит настраиваю под себя.
По поводу ответов: да, вы в чём-то правы. Не соглашусь с
Я не так давно пользуюсь emacs, но уже работаю быстрее, чем раньше работал в vscode. Гораздо меньше возюкаю мышкой, гораздо больше интеграция в систему (например, вместо встроенного тайлинга можно использовать тайлинг от системного WM, в отличие от VSCode), гораздо больше расширений.
Вообще, тут вопрос наверное сводится к субъективному удобству — мне удобнее нативный, быстрый и интегрированный emacs, кому-то удобнее VSCode.
По поводу ответов: да, вы в чём-то правы. Не соглашусь с
Ни разу еще не встречал язык, который не поддерживается Кодом, даже всякие очень специализированные есть (вроде .peg). Банальный пример: в emacs поддерживается форматирование кода, автодополнение опций и функций, подсветка ошибок в nix, а в VSCode — только подсветка кода.
Я не так давно пользуюсь emacs, но уже работаю быстрее, чем раньше работал в vscode. Гораздо меньше возюкаю мышкой, гораздо больше интеграция в систему (например, вместо встроенного тайлинга можно использовать тайлинг от системного WM, в отличие от VSCode), гораздо больше расширений.
Вообще, тут вопрос наверное сводится к субъективному удобству — мне удобнее нативный, быстрый и интегрированный emacs, кому-то удобнее VSCode.
В VSCode есть и автодополнение и подсветка ошибок. Даже PHP скрипты при сохранении автоматически прогоняются через интерпретатор и отлавливаются и подсвечиваются ошибки.
Согласен, на текущий момент поддержка конкретно этого языка ограничивается подсветкой синтаксиса, но ничего не мешает добавить туда и автодополнение и подсветку ошибок.
Странно, вот сейчас поставил себе VSCode (Linux Mint) — deb пакет весит 42,7 метра — все зависимости удовлетворены, т.е. ничего не тянет сверху.
/usr/share/code весит 169 метров. бинарник code — 79 мегабайт. Я пока еще не разбирался с электрон, и как получается само приложение. Но посмотрев vscode — сходу видно что основное место занимают текстовые файлы (json, js). Т.е. если fs поддерживает сжатие, то места занимает не много.
А если была бы подобная технология (electron и иже с ним) внедрена в ОС, что бы не тянуть то что не является приложением — браузер, поддержку всего, то само приложение в сжатом виде занимало бы не много. Достаточно было бы среднего сжатия, что бы быстро распаковывалось при старте, и все, места занимало бы раза в 2 меньше.
Имхо, за подобными вещами будущее, и, остается лишь надеяться, что это правильно интегрируют, что бы устранить основные недостатки текущих приложений
/usr/share/code весит 169 метров. бинарник code — 79 мегабайт. Я пока еще не разбирался с электрон, и как получается само приложение. Но посмотрев vscode — сходу видно что основное место занимают текстовые файлы (json, js). Т.е. если fs поддерживает сжатие, то места занимает не много.
А если была бы подобная технология (electron и иже с ним) внедрена в ОС, что бы не тянуть то что не является приложением — браузер, поддержку всего, то само приложение в сжатом виде занимало бы не много. Достаточно было бы среднего сжатия, что бы быстро распаковывалось при старте, и все, места занимало бы раза в 2 меньше.
Имхо, за подобными вещами будущее, и, остается лишь надеяться, что это правильно интегрируют, что бы устранить основные недостатки текущих приложений
Да, ошибся, это Атом занимает 700 мегабайт из коробки.
Зато после запуска он съест несколько сотен мб. И каждое следующее electron приложение столько же.
Нужна система с расшариванинием Chromium между приложениями.
Согласен, а еще лучше, как я где-то писал, сделать сервис для подобного рода приложений, где по мимо 1 браузера на всех будет набор либ и всего что может понадобится, что бы сами приложения только собственный код и ресурсы несли, а остальное было одно на всех в системе
Будущее за PWA. Edge переходит на Chromium, Apple экспериментирует там тоже с всем этим. Через пару лет 99% устройств будут иметь адекватный и современный браузерный движок буквально вшитый в систему.
- Мгновенно возникает проблема с версией системного движка
- Разве PWA будут выпускаться за пределы песочницы?
1. Мы до сих пор умудряемся кое-где поддерживать IE9. Думаю пару месяцев не обновлявшийся Хром не такая уж и сложность :D
2. Думаю нужно реализовать механизм разрешений, что бы каждое PWA могло спросить разрешения, например, на доступ к файловой системе.
2. Думаю нужно реализовать механизм разрешений, что бы каждое PWA могло спросить разрешения, например, на доступ к файловой системе.
- С движком сейчас проблем нет – благодаря механизму автоматических обновлений, большинство пользователей получают обновление браузера в течение пары недель после его выхода. Один Microsoft со своим Windows Update всегда отстает, может с Chromium ситуация исправится.
- Для обращений за пределы песочницы есть API на все случаи жизни: WebAudio, Fullscreen API, Push API и другие. Для большинства задач этого набора хватит.
Как пример полезного PWA: https://squoosh.app – сжималка изображений. Не хуже многих декстопных программ и устанавливать ничего не надо, достаточно сохранить адрес в закладки.
Террабайтные 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 гига!!??? Доколе!!!
Заказчики тоже не подарок. Пишешь, что будешь писать на Аде, и начинается, ой, а что вообще написано на Аде, а зачем это надо.
Ага, потому что написанное еще и поддерживать надо, и если Вы ему сейчас напишите на Аде, а потом по каким-то причинам откажитесь от поддержки проекта или увеличите свой ценник в 10 раз, то что делать заказчику? Где искать спеца в редкой технологии? Или платить заново и переписывать все с нуля на распространенном языке?
Ну как минимум 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 — в премиуме.
Поэтому несколько экземпляров Электрона будут подниматься… сначала с ССД по ПСИ-е… потом с памяти до ЦП… меедлееееенннооооо…
Но ценник будет конский, явно только для премиум-сегмента.
Насчет 900Гб памяти — только доступ к ней будет на «стекляном потолке в 5ГГц», потому что количество каналов в бытовом секторе — традиционно 2, 4 — в премиуме.
Поэтому несколько экземпляров Электрона будут подниматься… сначала с ССД по ПСИ-е… потом с памяти до ЦП… меедлееееенннооооо…
3 нм — это как раз Самсунг разрабатывает (а точнее, уже разработала).
на «стекляном потолке в 5ГГц»— так ширина шины же тоже будет расти. Да и даже сейчас на 3200 МГц она выдаёт 25 ГБ/с и порядка 32 ГБ/с в dual-mode. Тип памяти тоже будет улучшаться. Вон, там с каждым поколением в 2 раза увеличивалась пропускная способность.
Поэтому несколько экземпляров Электрона будут подниматься медленноНесколько экземпляров Электрона отожрут до нескольких гигабайт, и ещё 897 ГБ останутся свободными.
Боюсь если будет доступно 900Гб, приложения найдут их как утилизировать. Ситуация будет лучше чем сейчас, но думаю не на порядок даже.
Если посмотреть как изменился объем потребляемой памяти софтом — то вывод один, имхо — сколько не дай — все мало.
В средней конфигурации.
Если посмотреть как изменился объем потребляемой памяти софтом — то вывод один, имхо — сколько не дай — все мало.
В средней конфигурации.
Потому что раньше всегда было, куда поиспользовать её. Даже сам факт написания кода на языках низкого уровня. +Очень жёсткая экономия памяти (вынужденность отказывать от вещей, которые ускорили бы программу или вообще сделали бы возможной её работу или часть её функционала).
А сейчас куда расходовать память, когда всё уже сделано? Ну линейный или чуть выше рост будет конечно.
А сейчас куда расходовать память, когда всё уже сделано? Ну линейный или чуть выше рост будет конечно.
Ширина не будет расти массово.
Один канал — это грубо говоря +1 слой платы и +300 выводов процессора.
Если посмотреть на Тридриппер, то там только корпус ЦП стоит под 50$, а сколько стоит соккет такого размера — я даже затрудняюсь.
Если массово переходить на 4 канала, то это 80-100$ к стоимости МП и 20 к стоимости любого ЦП.
Я не уверен, что рынок воспримет это позитивно.
Один канал — это грубо говоря +1 слой платы и +300 выводов процессора.
Если посмотреть на Тридриппер, то там только корпус ЦП стоит под 50$, а сколько стоит соккет такого размера — я даже затрудняюсь.
Если массово переходить на 4 канала, то это 80-100$ к стоимости МП и 20 к стоимости любого ЦП.
Я не уверен, что рынок воспримет это позитивно.
насчет 3 нМ у Самсунга — промышленное внедрение 2021 год.
У Интела формально 10нМ уже есть как пару лет- на одном мобильном огрызке I3.
Процесс — есть, выхода годных — нет.
Поживем — посмотрим.
У Интела формально 10нМ уже есть как пару лет- на одном мобильном огрызке I3.
Процесс — есть, выхода годных — нет.
Поживем — посмотрим.
Вряд-ли, сейчас 8 Гб стоят > 4500 р.
UFO just landed and posted this here
Это в России нет, из-за падения рубля. А также из-за картельного сговора. Всё это суммарно унесло 6 лет развития. Но сговор скоро будет разрушен (подтянутся другие производители), а падение рубля отразилось только на России, а не других странах. В остальном память дешевела экспоненциально и будет дешеветь далее.
Если бы все было так просто, насчет подтянутся -это ведь не чипсы выпекать.
Интел уже 3 года не может выкатить массовый 10нМ продукт, ГлобалФундри — отказалась от освоения 7нМ.
Полупроводниковых производителей памяти больше толком не будет. Все теже самые Микрон, Самсунг, Хуникс и всё.
Эльпида — и та банкрот с 2012 года и принадлежит Микрону.
Интел уже 3 года не может выкатить массовый 10нМ продукт, ГлобалФундри — отказалась от освоения 7нМ.
Полупроводниковых производителей памяти больше толком не будет. Все теже самые Микрон, Самсунг, Хуникс и всё.
Эльпида — и та банкрот с 2012 года и принадлежит Микрону.
Вообще-то, в Китае появляется сразу два производителя оперативной памяти. Я же не просто так говорю «подтянутся другие». Вы просто не следили за новостями.
Интел уже 3 года не может выкатить массовый 10нМ продукт, ГлобалФундри — отказалась от освоения 7нМ.И снова Вы не следите за новостями. Samsung уже завершила разработку 3 нм, и готовится к запуску в 2021 году.
Памяти вообще, или ап-ту-дейт для ПК?
Роутеры и прочие хлебопечки только массово начали переходить на ДДР2, премиум — на ДДР3.
Есть еще применений ДДР/СДР.
А ведь
128 GiB module based on 8 Gib DDR4 using 20 nm technology
Заводик со старта должен будет прыгнуть в высшую лигу нанометров.
Роутеры и прочие хлебопечки только массово начали переходить на ДДР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.
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 ГБ памяти :(
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 не нужно было бы…
А если бы был аккуратный учёт всех ресурсов — то сделали бы нормальную фоновую загрузку и никаких 32GB не нужно было бы…
Пропускная способность PCIe 3.0 x16 — 15 ГБ/с. Загрузить 1 ГБ в карту заняло бы 65 мс. Не думаю, что дело в этом.
Дело не в 15 Гб/с. Дело в необходимости учитывать вот это вот всё. Что данные нужно перегонять из оперативки в видеокарту и прочее.
То, кто этим занимаются — могуть сделать и так, чтобы на 3ГБ не тормозило, им 32ГБ не нужно. Те, кто не занимаются — те не занимаются и у них соотвествующего кода просто нет.
То, кто этим занимаются — могуть сделать и так, чтобы на 3ГБ не тормозило, им 32ГБ не нужно. Те, кто не занимаются — те не занимаются и у них соотвествующего кода просто нет.
мощный поиск понадобился не в виде исключения
Spotlight и его аналогич очень удобны на самом деле. Это как автодополнение кода — секунда-другая и ты уже запускаешь нужную программу или открываешь файл, а не тратишь полминуты на пробежку через четыре меню.
Но для этого тоже есть хорошие и не сильно затратные решения — есть SphinxSearch который даже на arm за десяток миллисекунд найдёт подходящие записи из полутора миллионов и сожрёт три сотни мегабайт памяти (из них пять метров на сам демон, остальное индекс). У обычного пользователя не полтора миллиона файлов, так что в эти три сотни метров можно даже поиск по содержимому файлов впихнуть.
Нажимаешь на вкладку и ждёшь 3 года… разработчик решил поэкономить память и не кэшировать скрин вкладки…
Нет, причина в том, что браузер пытается делать десятки тысяч операций записи и чтения в секунду. Естественно, кеш операционки от такого говнокода полностью не защищает и на hdd хромы еле шевелятся.
Даже нажатие на диалог создавало лаг. А вот если бы он пожрал память, то мог бы отобразить его мгновенно.
Что же такого прожорливого должен мессенджер покэшировать, чтобы работать быстро? Пару килобайт диалогов? Хмм, может, десяток мегабайт картинок из диалогов?
Нет разумной причины мессенджеру потреблять 300-700 МБ оперативы.
Один только экран в 4К занимает 32 МБ
Обычно эти мегабайты находятся на видеокарте и не идут в счёт.
я не хочу, чтобы программист экономил память и пытался уместиться в 30 МБ, из-за чего программа работает в несколько раз медленнее, а некоторые вещи тупо работают очень медленно.
Нет, в обычных программах никто не экономит память. Компромиссы есть в базовых алгоритмах, структурах данных, а в приложении пытаются кэшировать везде, где выгодно. Резко возросшее сегодня потребление памяти никак не связано со стремлением разработчиков сделать программу быстрой, причины здесь другие.
Или взять те же браузеры. Нажимаешь на вкладку и ждёшь 3 года.
У меня вкладки переключаются мгновенно. Люблю Firefox, столько лет жизни мне сэкономил.
Что же такого прожорливого должен мессенджер покэшировать, чтобы работать быстро? Пару килобайт диалогов? Хмм, может, десяток мегабайт картинок из диалогов?
Нет разумной причины мессенджеру потреблять 300-700 МБ оперативы.
Я не знаю что делает православный Телеграм написанный на qt, но если открыть диалог с кучей сообщений и начать активно скроллить — он может и гиг оперативы съесть легко.
У меня вкладки переключаются мгновенно. Люблю Firefox, столько лет жизни мне сэкономил.Как раз таки Firefox переключает вкладки очень медленно. Больше всего претензия было как раз к нему. А всё почему. Потому что ест меньше всех памяти. Те, кто позволяет закэшировать скрин, переключают мгновенно. Хотя есть и промежуточный вариант — отрисовывать заранее при наведении, заодно и страницу восстановить.
Нет, в обычных программах никто не экономит память.Да ладно, та же винда с диска 10 раз одно и то же перегружает. Игры выше я привёл. Да и я сам пишу программы, у меня раз 100 бывало, что за счёт памяти я могу значительно ускорить работу программы.
Как раз таки Firefox переключает вкладки очень медленно.
Если вкладка уже загружена, а оперативы достаточно, то переключение всегда будет мгновенным, лиса рендерит в 60 fps и сохраняет промежуточные данные. dom есть, стили рассчитаны, текст измерен, layout сделан, при нажатии на вкладку остаётся только всё взять и отдать видеокарте.
Если же вкладка просто висит незагруженная со старта браузера, то совершенно естественно, что при нажатии на неё произойдёт лаг. Загружать её при наведении мышки не выглядит адекватным решением, ведь далеко не обязательно за этим последует клик.
3. Один только экран в 4К занимает 32 МБ. Это уже больше 30 МБ :) А винда, скорее всего, кэширует этот экран. Вам уже придётся не на весь экран разворачивать скайп для экономии памяти XD.
Теперь я начинаю понимать как мыслят программисты, которые пишут монструозные приложения. Ну а че, открыл в скайпе 10 экранных форм — вот тебе и 300Мб, открыл 20 — вот и все 700Мб.
Для справки, приложения — это не игры и интерфейс строится на основе API, который предоставляет ОС.
А винда, скорее всего, кэширует этот экран.
Это ее, винды, трудности, как она работает с видеопамятью, окнами, z-буфером и т.д. На размер потребляемой ОЗУ это практически не влияет.
Взять тот же Everything.
Это просто разные подходы к функционалу. Everything сканит и делает индекс, в котором поиск идет быстро (примерно как в любой БД), потом его на лету перестраивает если есть файлы. Но первое сканирование быстрее не становится от того, что он ест больше памяти. Так что это теплое против мягкого. А вот со скайпом функционал не поменялся. Более того, настроек стало гораздо меньше, чем раньше!
Или взять те же браузеры. Нажимаешь на вкладку и ждёшь 3 года. Всё потому, что разработчик решил поэкономить память и не кэшировать скрин вкладки…
У меня такой проблемы нет, хотя вкладок очень много открыто, но допустим. Я пот не понял логики. Ок, браузер закешировал скрин вкладки, пользователь ее ооочень быстро открыл, хочет работать, дальше что? Тыкаем в скрин? Или ждем заново когда подгрузится обновленная страница?
Но первое сканирование быстрее не становится от того, что он ест больше памяти.Да мне как-то всё-равно на первое сканирование, главное, что дальше программа работает мгновенно. Это сканирование выполняется 1 раз в жизни при установке программы. Далее тупо отслеживается журнал изменений ФС.
Ок, браузер закэшировал скрин вкладки, пользователь ее ооочень быстро открыл, хочет работать, дальше что?За то время, когда мы подведём мышку, вкладка будет готова. Мы же не полностью рендерим вкладку с нуля. Быстрее, чем за 40 мс я кликнуть никуда не смогу. А вот лаг 40 мс будет жёстко бить по производительности. Лучше я эти 40 мс буду решать, куда кликнуть. Ну и можно для рендеринга же тоже закэшировать инфу, чтобы отрендерить быстрее.
Да, тут согласен. В этом плане мне очень нравится Telegram. Мессенджеры это действительно тот случай когда лучше писать нативно.
Я, правда, не застал Word6 на Маке, но неужели автор считает, что вот это «отдельное направление разработки», которое выпускало, например, Office 2008 for Mac, действительно делало Mac-Like приложения? Кажется, первым более или менее нативным Офисом на Маке стал 2011-й, что не мешает до сих пор в массе мест наталкиваться на страшноватые реликты.
UFO just landed and posted this here
Хоть на маке для меня лично жизнь закончилась где-то в районе версии 10.10, но, столкнувшись недавно в полный рост с феноменом такой «кросс-платформенности», кажется выяснил, почему закрыли винамп.
В офис Nullsoft просто пришли похвастаться разработчики спотифая и сказали, что для стриминга плейлиста им хватает всего лишь 850 мегабайт оперативки, весь Nullsoft умер от смеха и поддерживать винамп стало некому…
(а в Pale Moon на самом верху списка тем временем 7 вкладок амазона не самого лёгкого открыто, как ни странно :-)
В офис Nullsoft просто пришли похвастаться разработчики спотифая и сказали, что для стриминга плейлиста им хватает всего лишь 850 мегабайт оперативки, весь Nullsoft умер от смеха и поддерживать винамп стало некому…
(а в Pale Moon на самом верху списка тем временем 7 вкладок амазона не самого лёгкого открыто, как ни странно :-)
Долго пытался понять, как это вы на классической MacOS столько памяти смогли поставить (не говоря уже о других современных приложениях вроде телеграма), и только потом заметил процесс Xorg :)
Правильно прикрученные фонты и оформление а-ля нетскейп и прочий софт заставляло просить у меня инсталлер телеграма под Мак ОС 9 даже некоторых завсегдатаев яблочной техники :-)
А вообще в 2014 году я спокойно, особо не замечая, просидел полгода на PowerMac G5 с 2 гигами оперативки и 10.4, при том что до того пользовался 10.9.5 на i3. Так что веб и правда был малость полегче и попроще.
А вообще в 2014 году я спокойно, особо не замечая, просидел полгода на PowerMac G5 с 2 гигами оперативки и 10.4, при том что до того пользовался 10.9.5 на i3. Так что веб и правда был малость полегче и попроще.
То, что electron заполонит все приложения, могут говорить только те, кто на нем не писали.
Это ужасно злая вещь, которая может упасть и не сказать ничего в логах или краш-репорте.
Это вещь, которая вроде позволяет создавать многопоточность через web-workers, но в самих web-workers не позволяет подключать нативные модули ноды.
Это такая вещь, которая очень медленно развивается. Все, что можно увидеть в release-notes — это фиксы багов. Так и у другого софта часто, но там переход с первой версии на третью не дает почти никакого преимущества, кроме обновленного движка хромиума.
Эта такая штука, в релизе у которой, в новой мажорной версии, будет вот это:
PDF Viewer is not working in 3.0.0 but will be return soon
(и это с сентября, в гитхабе пишут, что некому взяться за эту работу)
т.е. в старых версиях если вы использовали просмотр pdf документов через окна или webview, то обновившись, при открытии вашего приложения, будет открываться окно сохранения pdf файла на диск.
При написании среднего/сложного приложения, неизбежно начинает не хватать возможностей электрона и ноды, и приходится писать нативные модули на С++.
В electron огромное количество багов, в этому количеству добавляется огромное количество багов хромиума.
Не смотря на эти проблемы, это дало направление подобного рода решениям. Сейчас оно все такое, непонятное, но пройдет год-два, и возможно либо вылечат, либо появятся нормально работающие альтернативы. Тот же carlo? Или, может, со стороны кажется, что оно подходит к этапу взросления
UFO just landed and posted this here
У меня получалось загрузить модуль только на один поток воркера. Загружать на несколько потоков один модуль не получалось, выходила ошибка:
Error: Module did not self-register.
Строго на вторую загрузку модуля, даже если грузить сначала в воркере а потом в главном потоке, будет такая ошибка.
К тому же, они сами пишут, что не рекомендуется импортить свои модули, и даже нодовские ( ибо они не работают с многопоточностью).
пруф https://github.com/electron/electron/blob/master/docs/tutorial/multithreading.md
UFO just landed and posted this here
Но вы же утверждали, что электрон не позволяет загружать нативные модули в воркеры? Теперь оказывается позволяет?
Где это позволяет? Разве что во втором потоке. Я ошибся в формулировке, в workerах можно подключать модули, но нельзя многопоточно это делать, т.е. одновременно в нескольких воркерах. То, что можно юзать только один дополнительный поток, это уже какая-та вшивая многопоточность.
Либо использованием вокреров ноды, а не хромиума, в качестве потоков.
Где можно про это почитать? Если все модули ноды однопоточны, то каким образом это будет работать? Разве что, локеры какие-нибудь ставить. Тут же опять, пропадает такая удобная штука, как transfer канва, т.е. работать с графикой многопоточно будет сложно, и потом эти данные нужно еще передавать в главный процесс. Так то можно и multiprocessing юзать.
Слишком много но.
Каждому инструменту свое применение. Писать все подряд на Electron глупо.
UFO just landed and posted this here
Да сейчас Linux с MATE больше похож на винду, чем современная винда.
> среду, в которой простой, может быть даже примитивный интерфейс, но единообразный для всех приложений
Такая штука давно есть. Называется «консоль». А с тех пор, как на linux far портировали, в ней вообще совсем хорошо стало.
> среду, в которой простой, может быть даже примитивный интерфейс, но единообразный для всех приложений
Такая штука давно есть. Называется «консоль». А с тех пор, как на linux far портировали, в ней вообще совсем хорошо стало.
Это не рак, это уже дерево на могилке выросло. И дело не в html/css/js, которые даже мой котик уже немножко знает, а, в первую очередь, в том, что в мире Еlectron, в отличие от винды, продвигаемые API и парадигмы программирования каждые несколько лет полностью не меняются. Потому что веб-стек и стандарты пилят хоть и под руководством корпораций, но, всё-таки, нескольких, всем миром, инкрементально и с обратной совместимостью, и даже гугл по велению левой пятки взять и перехреначить всё никак не сможет. А в мире MS — MFC, STL, COM+, .NET, WinForms, UWP… они уже сами не знают, на чём предлагать писать разработчикам. А разработчики де факто давно пишут на кроссплатформенных java, cpp/Qt, python и, собственно, электроне.
Вендекапец случился лет 5 назад, но его, как и следовало ожидать, никто особенно и не заметил.
Вот реально, что мне сейчас такого может дать винда, чего не может ни одна другая операционка, чтобы мне страсть как захотелось за эту самую винду заплатить? И это я ещё тяжелые десктопные приложения гоняю, а большинству пользователей давно уже наплевать, какая именно прокладка у них в компе между железом и браузером.
— человек, у которого и мама и тёща уже несколько лет как пользуются linux mint. и им норм.
Вендекапец случился лет 5 назад, но его, как и следовало ожидать, никто особенно и не заметил.
Вот реально, что мне сейчас такого может дать винда, чего не может ни одна другая операционка, чтобы мне страсть как захотелось за эту самую винду заплатить? И это я ещё тяжелые десктопные приложения гоняю, а большинству пользователей давно уже наплевать, какая именно прокладка у них в компе между железом и браузером.
— человек, у которого и мама и тёща уже несколько лет как пользуются linux mint. и им норм.
UFO just landed and posted this here
Маму-то за что?!
За Одноклассников, за что ж еще?
За «у меня снова вирусы, приезжай скорее чистить!».
Ну и мысль о том, чтобы не нарушать закон, пользуясь пираткой, мила её христианскому сердцу (сам атеист, но тоже не приветствую пиратку без крайней необходимости, ну и потом, мне не жалко сделать маме приятно, во что бы она ни верила), а платить за винду лишних денег нет.
Ну и мысль о том, чтобы не нарушать закон, пользуясь пираткой, мила её христианскому сердцу (сам атеист, но тоже не приветствую пиратку без крайней необходимости, ну и потом, мне не жалко сделать маме приятно, во что бы она ни верила), а платить за винду лишних денег нет.
А я вот родителям поставил Windows 7 (не пиратку, пиратки отказываюсь ставить, поэтому меня со словами «тыжпрограммист» беспокоят не чаще раза в 2 года) в 2014, но предусмотрительно не дал им пароль от учётки администратора (и конечно же настроил автообновление ОС и браузера)… Ни разу за 4 года не было проблем. Никаких вирусов =) Зато могут без танцев с бубном иногда поиграть в какие-то игрушки и использовать некоторый специфичный банковский софт.
и даже гугл по велению левой пятки взять и перехреначить всё никак не сможет
Еще как может
blog.js.cytoscape.org/2017/02/15/passive-listeners-chrome
Вот реально, что мне сейчас такого может дать винда, чего не может ни одна другая операционка, чтобы мне страсть как захотелось за эту самую винду заплатить?DirectX?
После того, как мобильные игры стали приносить больше дохода, чем PC и консоли вместе взятые?
Нет, DirectX больше не нужен.
Нет, DirectX больше не нужен.
Сам я не очень увлекаюсь, но, судя по новостям с фороникса, wine/proton его сейчас поверх вулкана чуть ли не лучше, чем винда, умеют, и с каждым коммитом от валв в слои совместимости и месу ситуация всё лучше и лучше.
что мне сейчас такого может дать винда, чего не может ни одна другая операционка
Ну вы же про сейчас спрашивали. Большинство игр сейчас разрабатывается под винду. Sad, but true.
Про «победу мобильных игр» и обсуждать глупо. Люди в принципе стали больше пользоваться мобильными девайсами, они на рынок «серьезных» игр почти никак не влияют.
. А в мире MS — MFC, STL, COM+, .NET, WinForms, UWP… они уже сами не знают, на чём предлагать писать разработчикам.
А на чем хотят, на том пусть и пишут. Дотнет теперь кроссплатформенный. Вы не знали?
Ага, только UI-библиотеки win only, а зачем мне dotnet, чтобы писать на qt/gnome, когда есть питон с выносом медленного на c/cpp, дающие на выходе ту же кроссплатформенность, но без вендор лок-ина?
Похоже, вы совсем не в теме. Microsoft уже давно бесплатно предлагает UI-библиотеки для разработки под популярные ОС Android и iOS с использованием .NET/C#, всё Open Source и под настоящими свободными лицензиями (MIT, то есть код можно использовать в абсолютно любых целях, даже для коммерческого закрытого ПО). Все самые популярные ОС (где обычно используется GUI) охватили. Для разработки GUI под Linux есть сторонние свободные библиотеки, может со временем и сама Microsoft что-то предложит (официальная поддержка iOS и Android тоже не сразу появилась). Недавно вон открыли код WinForms и WPF — по-моему, больше закрытых частей .NET не осталось, всё в свободном доступе.
Единственное плохо, что они слишком поздно занялись переводом всего что связано с .NET в разряд свободных технологий. Следовало бы заняться открытием всего этого лет 10+ назад, в идеале — вообще с первого дня существования .NET, но при тогдашнем руководстве Microsoft это было просто невозможно даже представить.
Единственное плохо, что они слишком поздно занялись переводом всего что связано с .NET в разряд свободных технологий. Следовало бы заняться открытием всего этого лет 10+ назад, в идеале — вообще с первого дня существования .NET, но при тогдашнем руководстве Microsoft это было просто невозможно даже представить.
Если к тому времени, как WinForms сделают юзабельными не только на винде, если это вообще когда-нибудь случится, ещё останутся желающие начинать новый проект на дотнете — с будущим экосистемы точно всё в порядке :) Впрочем, если WinForms будут везде — кому, опять же, и зачем будет нужна винда?
А, не, ну, мобильные игрушки, ок. Собственно, от MS должно остаться игровое подразделение и те, кто делают офис — вот реально две вещи, в которых MS действительно хороши.
А, не, ну, мобильные игрушки, ок. Собственно, от MS должно остаться игровое подразделение и те, кто делают офис — вот реально две вещи, в которых MS действительно хороши.
WinForms никогда не сделают юзабельным где-то кроме винды, просто потому что это (внезапно) WinForms, то есть обёртка над окнами из старого доброго Win32 API. Впрочем, в рамках проекта Mono была создана реализация WinForms под Linux, но там костыль на костыле и я не стал бы такое использовать. У каждой ОС свой подход к построению GUI, и я уверен, что для каждой ОС GUI должен писаться отдельно, иначе это ничем не лучше обсуждаемого Electron. И .NET/C# это позволяет делать — использовать общую внутреннюю логику для всех ОС сразу, а для GUI предлагаются разные библиотеки для разных ОС, чтобы для каждой ОС можно было задизайнить интерфейс, который будет родным для данной ОС, а не какой-то кошмар, который везде выглядит убого и чужеродно.
Должен-то он должен, только на практике это только у Эппла более-менее успешно выходит пока. И ничего, на винде и линуксе живут себе как-то люди с зоопарком UI/UX. Утомляет, да. Хорошо бы, чтоб как на Эппле, да. Но не смертельно. Судя по тому, что сейчас показывает рынок, страдания от vendor lock-in перевесели таки в среднем по больнице страдания от отсутствия единообразного интерфейса в пределах платформы. Ну а кому lock-in ок — давно ушли на Эппл, где единообразие действительно единообразное.
И да, уважаемые Microsoft, если вы теперь хорошие, где Microsoft Office for Linux? Вот, допустим, за офис я, может быть, ещё был бы готов заплатить (да, либра кое с чем, всё-таки, справляется на четвёрочку). Но вот покупать ради этого ещё и винду, чтобы гонять всё это дело в виртуалке — вряд ли стану.
Потому что веб-стек и стандарты пилят хоть и под руководством корпораций, но, всё-таки, нескольких, всем миром, инкрементально и с обратной совместимостью, и даже гугл по велению левой пятки взять и перехреначить всё никак не сможет. А в мире MS — MFC, STL, COM+, .NET, WinForms, UWP… они уже сами не знают, на чём предлагать писать разработчикам.Похоже, вы опять пишете, не понимая о чём речь. MFC — это тонкая C++-ная обёртка над обычным Win32 API. STL к GUI отношения не имеет, так как это стандартная библиотека C++. COM+ также из другой оперы. .NET — среда исполнения для байт-кода, в который собирается код на C#. WinForms — ну хоть что-то по теме, только вот это опять обёртка над Win32 API, просто более толстая, чем MFC, и для C# вместо C++. Вы почему-то не вспомнили про WPF, который тоже был бы по теме, но вспомнили про UWP. Так вот последнее — это действительно новая подсистема, впервые что-то новое, отличное от привычного Win32 API. Но при этом Win32 API отлично поддерживается и никто вроде как не собирается от него отказываться, по крайней мере в обозримом будущем. Уж чему-чему, а обратной совместимости у Microsoft можно только поучиться. UWP же проектируют заново, в стиле API современных ОС типа Android или iOS, где все приложения выполняются в песочницах с какими-то правами.
Про проигрыш битвы за API и постоянную смену парадигм это Джоэл Спольски писал, а ему всяко виднее, чем мне. Ссылка в исходном каменте.
UFO just landed and posted this here
Ну так в вебе фреймворки меняются гораздо чаще (в бородатые времена был популярен Prototype, потом королём был jQuery, потом была ещё куча разных фреймворков, потом React со всякими там Redux и компанией, сейчас набирают популярность и другие фреймворки и библиотеки). Да, они работают поверх обычного JS API браузера, но это же самое можно сказать и про MFC, WinForms и даже WPF (в меньшей степени, так как он рендерит всё сам, но запускается в той же подсистеме, где и всё остальное ПО), которые работают поверх Win32 API. Помимо того что предлагала Microsoft, есть и куча других библиотек и фреймворков. В былые времена был популярен VCL от Borland (Delphi и C++ Builder), например, который тоже был в основном просто красивой прослойкой к контролам из Win32 API (и в этом WinForms под .NET/C# очень похож на VCL). При этом вы можете взять программу из начала нулевых или конца 90-х, которая была собрана с использованием MFC или VCL, и в подавляющем большинстве случаев без проблем запустить её на современной Windows (если она была написана корректно). То же самое в вебе. jQuery сейчас не в моде, но сайты с его использованием работают без проблем и сегодня.
Упыри которым плевать на устоявшийся UX не только в Apple (где ломают единообразие переключения раскладки клавиатуры, внезапно «изобретя» клавишу «RUS/LAT» на месте Fn), но и Google в Chrome для Mac недавно отличился: «Удерживайте» — говорит — «CMD+Q чтобы выйти».
Это как на винде внезапно программа бы заявила: «всё, мне насрать на ваш этот ALT+F4, давайте вместо однократного нажатия удерживайте, а то вы, дебилы, поди случайно нажали».
К счастью, можно отключить.
Это как на винде внезапно программа бы заявила: «всё, мне насрать на ваш этот ALT+F4, давайте вместо однократного нажатия удерживайте, а то вы, дебилы, поди случайно нажали».
К счастью, можно отключить.
UFO just landed and posted this here
Чего стоит убиение перехода назад по BkSpace, вот кому он помешал…Если коротко, то… многим — и у них «подгорало» ничуть не меньше вашего… правда после того, как Backspace, наконец, убрали — туда пришли уже ваши союзники… и стали требовать опцию — но Chrome это не Firefox…
«всё, мне насрать на ваш этот ALT+F4, давайте вместо однократного нажатия удерживайте, а то вы, дебилы, поди случайно нажали».
На маке это актуальная проблема, т.к. cmd+W (закрыть вкладку) находится прямо рядом с cmd+Q (закрыть всю программу), и да — многие промахиваются и получается очень обидно.
Так что я лично очень рад что хром просит нажимать cmd+shift+Q (про удерживание не знал) — чтобы точно не промахнуться.
У них в багтрекере был тикет на это с кучей недовольных комментариев от пользователей нечаянно закрывающих свой браузер.
Вы так говорите, будто в других ОС и программах другие сочетания клавиш. Закрытие окна по CTRL+W, а программы по CTRL+Q — стандарт, и никто не жалуется.
В браузере закрывание вкладок гораздо более частый юзкейс, чем закрывание окон какой-то программы.
«RUS/LAT» на месте Fn
Это где такое?
Это где такое?
В iOS (iPad/iPhone) и с недавних пор в MacOSX тоже доступно, если ничего не путаю).
Теперь невозможно пользоваться RDP, попытаешься нажать F6 (то есть в некоторых клиентах Fn+F6) а у тебя язык переключится =(
Теперь невозможно пользоваться RDP, попытаешься нажать F6 (то есть в некоторых клиентах Fn+F6) а у тебя язык переключится =(
В iOS клавиши Fn и не было никогда. Возможно с внешними клавиатурами эта кнопка работает для переключения языка, т.к на родной клавиатуре для планшета там действительно располагается выбор локали.
В МакОС я с таким не сталкивался и все эти шорткаты настраиваются.
В МакОС я с таким не сталкивался и все эти шорткаты настраиваются.
В iOS клавиши Fn и не было никогда.
Речь про внешние физические клавиатуры, конечно. (Другие в контексте RDP бессмысленны =).
Раньше переключение было единообразным и в MacOS и в iOS (CMD+SPACE), и (с Win8) в windows (CMD/WIN+SPACE). А теперь по умолчанию в макоси ctrl+space (но перенастраивается на другие варианты), а в iOS вообще перенастроить с Fn никуда нельзя.
Короче, всё сломали и довольны =)
Спасибо, теперь понял. Видимо когда выпустили клавиатуры-чехлы для планшетов с выделенной кнопкой, то просто перемапили fn на смену языка, т.к она не используется в иос. Я думаю, эту ситуацию должны разруливать авторы софта для RDP — скажем дать пользователю выбор каких-то комбинаций клавиш, как например это сделано в виртуалках на макоси
Ну и по идее, F-кнопки внешних клавиатур на айпаде должны работать без модификаторов
Ну и по идее, F-кнопки внешних клавиатур на айпаде должны работать без модификаторов
Если оно там программно обрабатывается — то да, надо третировать MS и Nulana (Remotix с поддержкой Swiftpoint GT — лучшее, что происходило с моим iPad'ом =)
Надо посмотреть в keyboard API.
Надо посмотреть в keyboard API.
Это на физической клавиатуре iPad Pro, разделяю боль товарища.
А в macOS, кстати, можно Caps’ом переключать.
А в macOS, кстати, можно Caps’ом переключать.
Я привык довольно быстро. Привычный CMD+Space открывает спотлайт — также как и на маке сейчас. А так, не вижу разницы капслоком переключать или фн/выделенной кнопкой
Оно конечно привыклось, но переключение Caps’ом и на айпаде было бы гораздо логичнее.
Что может быть логичнее чем специальная кнопка?
Только «за», если специальная кнопка будет на месте Caps’а. Сделать это на внешних клавах для айпада полагаю проще, чем мучительно менять клавиатуры на маках.
Это уже проходили на советских клонах ZX Spectrum'а =)
Выделенная кнопка — может быть ок, если она больше ни для чего не используется. Но у Fn есть её основное назначение: переключать верхний ряд в
режим F1-F12.
И ещё: клавиши-модификаторы должны быть инертными (как в MacOS), Fn — становится внезапно вторым CAPS LOCK или как Win или Alt в Windows — кнопкой на которую становится опасно нажимать — так как ломается контекст (alt внезапно уносит тебя в меню, а win — в меню старт — и это очень плохо с точки зрения UX).
Выделенная кнопка — может быть ок, если она больше ни для чего не используется. Но у Fn есть её основное назначение: переключать верхний ряд в
режим F1-F12.
И ещё: клавиши-модификаторы должны быть инертными (как в MacOS), Fn — становится внезапно вторым CAPS LOCK или как Win или Alt в Windows — кнопкой на которую становится опасно нажимать — так как ломается контекст (alt внезапно уносит тебя в меню, а win — в меню старт — и это очень плохо с точки зрения UX).
Так если выяснили что эта кнопка работает так только на планшетах (где она ни для чего больше и не используется), то претензии выглядят не особо обосновано (не считая сценария с RDP сессиями). У меня родная клавиатура от айпада про и на ней на месте Fn кнопка с глобусом чтобы никого не смущать. Вот CMD+Space действительно выкидывает из контекста, когда открывается поиск на весь экран, по инерции туда печатается часть текста, а потом еще из-за мелких багов пропадает курсор в поле ввода в некоторых программах
Основная претензия (вне контекста RDP) — это, например, Mail, MS Office/iOffice:
Невозможно эффективно редактировать текст без Home/End и PgUp/PgDwn, а ведь Home — это же Fn+Left, а PgUp — это Fn+Up. Вот где основная боль -_-
Невозможно эффективно редактировать текст без Home/End и PgUp/PgDwn, а ведь Home — это же Fn+Left, а PgUp — это Fn+Up. Вот где основная боль -_-
Ответил в другой ветке, что эти сочетания работают через cmd + стрелки. Единственное, пока не нашел перемещение курсора на следующее слово — мне это сочетание обычно чаще требуется.
Для меня пока боль привыкнуть к другой пунктуации, т.к. на маке у меня ПК раскладка по привычке. С другой стороны вопросительный знак и слэш на том же месте, что и в латинской раскладке, это немного компенсирует положение запятой (точку пока нажимаю двойным пробелом)
Edit: перемещение на слово вперед/назад через Option + стрелки
Для меня пока боль привыкнуть к другой пунктуации, т.к. на маке у меня ПК раскладка по привычке. С другой стороны вопросительный знак и слэш на том же месте, что и в латинской раскладке, это немного компенсирует положение запятой (точку пока нажимаю двойным пробелом)
Edit: перемещение на слово вперед/назад через Option + стрелки
Очень рекомендую вот эту статью посмотреть — support.apple.com/en-us/HT201236
Спасибо, конечно, но она не имеет отношения к iOS.
Сценарий простой: подключать одну и ту же клавиатуру (Apple wireless keyboard) к Mac, к PC и к iPad.
И раньше всё работало одинаково хорошо. А теперь — нет.
Сценарий простой: подключать одну и ту же клавиатуру (Apple wireless keyboard) к Mac, к PC и к iPad.
И раньше всё работало одинаково хорошо. А теперь — нет.
Честно говоря, я возможно выскажу непопулярную точку зрения, но я думаю, что проблема потребления памяти или процессора зачастую кроется далеко не в платформе, на которой основано приложение. IntelliJ IDEA написана на яве (нашел с чем сравнивать правда), которой не нужно запускать целый браузер для работы, однако по ощущениям (хотя конечно ощущения не являются мерилом чего-либо) VS Code работает несколько быстрее, а также более оптимально расходует память.
Также следует упомянуть, что идея использовать html+css+js для интерфейсов нативных приложений абсолютно не нова, возьмите steam, к примеру. Просто раньше использовали иные движки для этого, а теперь появился electron, используют electron.
Также следует упомянуть, что идея использовать html+css+js для интерфейсов нативных приложений абсолютно не нова, возьмите steam, к примеру. Просто раньше использовали иные движки для этого, а теперь появился electron, используют electron.
В то, что браузерные движки JS могут работать быстрее JVM, поверить можно, но не равняться же на это.
У Steam там не UI на нём, а Store открывается (браузерный компонент можно запретить опцией и вся библиотека по-прежнему будет стартовать, вот только ничего нельзя будет купить).
У Steam там не UI на нём, а Store открывается (браузерный компонент можно запретить опцией и вся библиотека по-прежнему будет стартовать, вот только ничего нельзя будет купить).
Касательно стима, у них собственная нативная UI-библиотека, насколько мне известно, и поэтому они буквально недавно только смогли запилить поддержку HiDPI. До этого либо буквы для муравьев, либо размытие. Куча жалоб и обсуждений в сети, костыльные решения типа костыльных скинов, вольво сохраняла благородное молчание в течение многих лет. Тот случай, когда захотелось электрон вместо натива.
Какой мрак. При Джобсе такого не было.
Тенденция отхода от нативных приложений огорчает. Slack в итоге остался только в виде вкладки в браузере (жирной и противной вкладки) и приложения в айфоне, ибо выглядит криво, часто падает при активном использовании, про жор памяти говорить не приходится. Скайпом, к счастью, никто из контактов уже не пользуется.
Похоже электрон — это только первая ласточка, дальше сама Apple подсовывает свинью в виде прослойки для iOS приложений на мак вроде Stocks и диктофона.
Похоже электрон — это только первая ласточка, дальше сама Apple подсовывает свинью в виде прослойки для iOS приложений на мак вроде Stocks и диктофона.
Лично я себя поймал однажды на мысли. что больше не хочу «нативных» приложений. И теперь пользуюсь только электроном, если что то нужно новое, гуглю в первую очередь именно там. Ибо буду точно уверен, что на моем зоопарке, это дело будет работать и как надо. А оперативка и тд, можно железом закидать, nvme ssd + ddr4 (3200+) А вот красоту удобство и межплатформенность заменить сложно. Мне кажется что microsoft + google сообразят что можно сделать с этим, что бы «не наступить на горло разработчикам» при этом оптимизировать 100 браузеров.
Смотрите глубже. Я считаю, Microsoft пофиг на Electron, это тупиковая ветвь эволюции, которая сгинет через несколько лет. Но тем не менее, он показал что веб может тягаться с нативом на его территории. Microsoft хотят подмять под себя будущую нишу PWA, которая как раз и убьет нативные приложения, тем более на рынке браузеров не вышло. Переход Microsoft на Chromium позволит им контролировать экосистему веб-приложений, для которых не важен браузер, а только движок в котором они выполнятся.
Пример: открываете сайт в %вашем любимом браузере%, соглашаетесь на установку PWA, оно устанавливается и открывается как нативное приложение, но не через Chrome, а самой осью на движке Chromium (или тоже самое при установке из Microsoft Store).
И этим же путем скорее всего пойдет Apple, сохранив за собой полный контроль за экосистемой (это они любят), не допустив Google к возможности устанавливать и исполнять веб-приложения от своего имени. В противном случае они проиграют битву, т.к. дни нативных приложений с GUI сочтены, веб убьет их в любом случае. Тоже касается и мобильных нативных приложений, там это произойдет даже быстрее. Разумеется игры, утилиты и прочий софт, а также содержащий тяжелые вычисления останется нативным, на js/ts никто в здравом уме переписывать не будет А затем wasm и их добьет.
Пример: открываете сайт в %вашем любимом браузере%, соглашаетесь на установку PWA, оно устанавливается и открывается как нативное приложение, но не через Chrome, а самой осью на движке Chromium (или тоже самое при установке из Microsoft Store).
И этим же путем скорее всего пойдет Apple, сохранив за собой полный контроль за экосистемой (это они любят), не допустив Google к возможности устанавливать и исполнять веб-приложения от своего имени. В противном случае они проиграют битву, т.к. дни нативных приложений с GUI сочтены, веб убьет их в любом случае. Тоже касается и мобильных нативных приложений, там это произойдет даже быстрее. Разумеется игры, утилиты и прочий софт, а также содержащий тяжелые вычисления останется нативным, на js/ts никто в здравом уме переписывать не будет А затем wasm и их добьет.
Electron и упадок нативных приложений