Pull to refresh

Comments 114

Да, забавная история. В принципе, многое в нашей истории сделано какими-то выскочками.

Но если подумать о "современном вебе" сразу в мыслях появляется Electron, который так часто используют "разработчики", и так сильно ненавидят пользователи. А в его появлении виновато распространение техники Эппл за пределами США. Ведь если бы не появилась мода на маки в последнее десятилетие, никто бы и не думал о кроссплатформенных приложениях. Линукс на десктопах ведь не влияет так сильно, рост аудитории с 1% до 2% уж точно.

Я, как пользователь, не вижу в электроне ничего плохого.

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

В чем проблема-то?

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

Постоянно запущено 5-6 приложений, подобного не наблюдаю. Чяднт?

Видимо вы не эклектрон-приложения запускаете 5-6 штук. Может быть еще и памяти >16Гб?

Памяти небось 16 гигов, а то и 32, да?

В мире полно техники, у которой по 2-4 гига памяти. И там работает win10, и огромное количество нативного софта, но стоит запустить что-нибудь "электронное" сразу начинает тупняк. А о шести таких приложениях страшно подумать.

Ребят, у вас логика сыпется.

Я отвечал конкретно на "ненавидят пользователи". Я - пользователь. Я - не ненавижу. Но мне начинают доказывать, что у меня тормозит и все плохо. Ок, ВАМ, конечно же, виднее.

Памяти 16Гб. И что с того? Утверждение было однозначное, а не "пользователи с 16гб и выше не ненавидят". Подумайте, на что именно вы отвечаете.

Те же "нативные" браузеры жрут поболее.

Да, тимз, бывает выжирает 1-1,5 гб если долго запущен. Так он и "нативный" в винде столько жрет, разве нет?

Посчитал, запущено 7: 2*teams + edge + outlook + tutanota-desktop + XMind2020 + trilium

2056MB	brave
1549MB	teams-insiders
1353MB	teams
1310MB	msedge
711MB	prospect-mail
640MB	trilium
631MB	electron
590MB	tutanota-deskto
392MB	telegram-deskto
326MB	alacritty

Свободно 4гб, еще 6гб файловый кэш. Как бы вообще не страшно, честно.

2-4 гига памяти, на винде 10? серьезно, часто таким пользуетесь?

наверное это работает, если не открывать в браузере больше 3 вкладок, особенно фейсбук и какой-нибудь ютуб. Только не пойму, зачем вам на винде електрон с тормозами, если все нативное?

Может, не стоит натягивать сову на глобус? И если что-то лично вам не нравится - это ваше право - но не самоочевидное правило для всех случаев?

Да, тимз, бывает выжирает 1-1,5 гб если долго запущен. Так он и "нативный" в винде столько жрет, разве нет?

Нативный тоже на электроне же.

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

С другой стороны имеем Teams, в котором переключение куда угодно (напр. вкладки Activity или Teams) очень вязкое, будто всё загружается заново.

Меня Teams выбешивает тем, что им нельзя полноценно пользоваться из браузера. И он тормозит, адово тормозит по сравнению с Google Docs/Meet, и UI у него просто отвратный.

А еще веб доступен не в пример лучше многих нативных платформ.


Вот прям сейчас пишу свой gui велосипед для git на react + nest + ts. Потому что из всего богатства выбора все либо недоступно, либо не подходит под мои сценарии пользования. А js экосистема в этом плане очень демократична. Я если честно от нее пока просто в восторге.

Я пользуюсь Teams на работе. Из последнего:

  1. Порой тупо не показывает окно. Сидит в трее, при попытке его оттуда поднять ничего не делает. Помогает перезагрузка программы через трей.

  2. Адово тормозит на большом количестве чатов/команд. Задержки интерфейса видны невооруженным глазом.

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

  4. В целом интерфейс работает с существенными задержками - он не кажется отзывчивым.

Глядя на тот же vscode, полагаю, что все эти проблемы можно преодолеть. Но зачем? Пипл же и так съест.

То что тимз - адово тормознутое приложение - я и не спорил, заметьте.

Да, он тормозит. К счастью, меня это не сильно напрягает.

И я более чем уверен, что дело в самой архитектуре, а не в електроне - во вкладке браузера он тормозит не меньше.

Я ещё добавлю, что пока он сидит в трее, он жрёт CPU, примерно 3-5%, причём чем именно занимается, не особо понятно.

Логика? Ненавидят пользователи <> ненавидят все пользователи!

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

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

Вообще, мне кажется, тут законодательство хромает. Если производитель электроники техники производит неэффективную бытовую технику, ей снижают рейтинги и, потенциально, не пускают на часть рынков. Если очередной стартап создаёт неэффективный мессенджер и умудряется попасть в аудиторию, то он начинает греть воздух на миллионах устройств (косвенно ускоряя выход из строя батареи, если говорить о смартфонах, а это в конечном счёте оставит свой след в экологии) и никто этого не замечает, кроми кучки народу, ноющей о том, что этот софт - говно. Зато факндеры экономят на оптимизации. И всё это потому, что нет никаких норм для ПО.

В мире полно техники, у которой по 2-4 гига памяти. И там работает win10

На <4 гигах? Зачем?
помню, был нищим студентом в общаге, но очень хотел быть программистом. Мне сосед-одногруппник дал в пользование свой мааленький нетбук, в котором 2гб оперативы и десятая винда. В целом, работало относительно! неплохо. Я юзал редактор brackets и первый заказ на фрилансе сделал именно на нем.
Но это не ответ на ваш вопрос, просто история из жизни)

Какие-то чудеса. У меня ноут lenovo c 8Гб ОЗУ, и мне однажды пришёл заказ на несколько уроков по программированию. Я не смог их сделать (осуществить запись с экрана), т.к. WebStorm + 3 вкладки в хроме сожрали всю память и винда начала прибивать приложения. И избавиться от запуска системы по 40 минут удалось только увеличением ОЗУ до 20 Гб.

Затем, что у вас (как и у почти всех программистов, впрочем) произошла профдеформация на этот счёт. Я понимаю вас, новый ноут с цп < i5/ryzen5 последнего поколения и озу < 16gb страшно брать, так как "да что на них вообще может идти?".

Но для обычных людей, которые не интересуются техникой, нет разницы, 4gb 8gb или 16gb, это лишь циферки в описании. Ну и учтите, что сейчас для многих людей (+- для половины) 30к - это минимум месячная зарплата (а часто и 2-3 месяца), и это без учёта любых трат, с учётом трат это вообще минимум полгода копить. А дешевле 30к сложно найти ноут с 8+gb оперативки, там обычно железо очень слабое. И это уж не говоря уж о том, что существуют такие уникумы, которые кто-то покупает.

кажись, эти уникумы официально не совместимы с 10кой по объёму диска.

Как ни странно, но `Up to 20 GB available hard disk space`. Хотя я имел дело с win10 на 32гб, и это было ужасно даже для "развернуть небольшое приложение для показать заказчику", не представляю, как этим пользоваться как домашним компом.

вроде-бы в прошлом году была новость, что мелкомягкие после какого-то обновления, ломающего систему из-за окончания свободного места, подняли минимальные системные требования по объёму диска в два раза

Вы так удивляетесь, как будто не в этом мире живёте) На рынке полно ноутбуков с 4 Гб с предустановленной Win 10. Раз они продаются — значит спрос есть.

В принципе, людей можно понять. Мне вот 16 Гб мало. Но мне надо много вкладок, пару виртуалок, да ещё и САПР при работе отъест. А зачем покупать комп с большим количеством памяти для серфинга по инету? Винда отъёст 1-1,5 Гб, пользователю останется 2,5-3 Гб. Неужели этого мало? Может хоть нынешний дефицит чипов, если он никуда не исчезнет, заставит отрасль заняться оптимизацией не на словах, а на деле.

/me вспоминает как Win95 достала BSoD'ами при работе в Delphi.
Пришлось ставить WinNT Workstation. При том что установщик активно сопротивлялся установке на компьютер с 8 Mb RAM. Но получилось.

8Гб, а Слэк выдаёт дичайшие тормоза. Приходится юзать вжб-версию ибо так быстрее

Давно пробовали? Со временем становится всё лучше.

RipCord в качестве клиента к Slack не тормозит.

С одной стороны да, а с другой, у вас есть альтернативы? На чем ещё я могу написать кроссплатформенный (да даже и фиг с ней, с кроссплатформенностью) десктоп апп, желательно на языке высокого уровня и не прибегая к нелюбимому мной c++?

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

Но сравните это скажем с gtk, тут недавно были статьи о том, что банальный hello world с офф сайта у них без приседаний не компилируется :D

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

Может, jetbrains с их jetpack compose +kotlin native в итоге победят, буду рад.

Free Pascal. У некоторых получаются очень качественные проги. Тот же Total Commander (вроде на Дельфи), сейчас Transmission Remote GUI отлично работает и ест 10МБ ОЗУ сейчас.

Да, технология старая, но будет работать и на древнем железе.

Ну это уже экзотика, делфи как язык всё же скорее мёртв, чем жив.

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

UFO landed and left these words here

Актуальность языка прекрасно выражена в вебинарах от MVP и разработчиков Embarcadero. Новые фичи, информация по новым библиотекам, поддержка Apple M1, поддержка Cocoa, разработка новых фреймворков, выход новых книг, обучающих ресурсов и т.д. Рекомендую ознакомиться с последними новостями, например в блоге на оф. сайте.

UFO landed and left these words here

Активность проявляется не только самой компанией, но и сторонними компаниями, пока не так активно, как хочется и в основном не в России. Однако много разработчиков из России являются MVP, участвуют как в международных вебинарах, так и проводят вебинары для России. Выпускают уроки, обзоры, демонстрации. Открываются сайты для обучения современному Делфи. Выпущена Community Edition версия среды для бесплатного использования. Многие крупные проекты для Делфи (в контексте пакетов и инструментов) частично или полностью становятся бесплатными для использования.

Помимо этого есть открытая площадка для заявок, как репортов так и хотелок. Несколько из моих репортов были приняты и исправлены в том числе и хотелки для фреймворков.

Расширяется охват аудитории, внедрением новых платформ или технологий. Например, взят под крыло компании проект Python4Delphi, который позволяет тесно интегрировать питон в язык позволяя вызывать функции из языка Делфи или получать прямой доступ к классам, например для управления формой, что позволяет использовать Делфи как фреймворк для питона или использовать все преимущества питона напрямую в Делфи.

На слайдах очередной презентации то и дело появляются шильдики новых партнёров.

Так что на самом деле здесь нет ничего грустного, если действительно знать изнутри положение дел. Например, в последнем роадмапе появился рисёрч компиляции под WebAssembler.

Так что грустить нет смысла. Среда пилится, язык меняется. Новые технологии поддерживаются.

Так что говорить о смерти Delphi сейчас - это показывать свою не компетентность в этом вопросе и не более.

Если писать как хобби для себя, то еще приемлемо. Но отсутствие библиотек на любые случаи жизни, зрелой экосистемы и опытных разработчиков делают этот стек малопригодным для большинства проектов. Хотя не скрою, было очень приятно, когда около 80 юнит тестов компилируются за секунду (киллер фича Pascal), а выполяются в сумме за какие-то миллисекунды.

А вы точно в курсе текущего положения дел Delphi/FreePascal?

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

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

Вот с чем несколько лет назад были трудности. Все под FP, под Delphi может чуть полегче.

Инструментарий:

  • линтер фактически отсутсвует

  • централизованное управление зависимостями тоже

  • для unit тестов есть решения, но настолько топорные, что трудно бороться с желанием написать свое с нуля

  • как бы хорош не был Lazarus как IDE, до уровня продуктов от JetBrains или чего-то подобного очень далеко в плане рефакторинга и автокомплита. Картину немного сгладил I-Pascal, но он развивается очень медленно. Автору тяжело тянуть продукт такого уровня в одного.

Библиотеки:

  • так и не нашел жизнеспособного клиента MongoDB. Сейчас вроде добавили клиент в mORMot.

  • Банально HTTP сервер. Из всего зоопарка в mORMot самое вменяемое решение. Но при специфических хотелках могут быть к проблемы. Например, в mORMot был баг с HTTP 1.0, из-за малой восстребованости баг репорт остался без ответа.

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

Инструментарий RAD и Lazarus сильно разнятся. В RAD на порядок больше инструментов как рефакторинга, так и форматирования, помощника кода и т.д.

Управление зависимостями:
Нужно отличать простые библиотеки, представляющие собой в большинстве языков - набор файлов (модулей), для работы с которыми достаточно иметь путь до них и библиотеки - пакеты (именно пакеты для Делфи), где пакет представляет собой проект внедряющийся непосредственно в среду разработки. Имеющий возможность менять саму среду добавляя визуальные компоненты, мастеры, редакторы свойств и просмотра и т.д.

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

Юнит тесты плохо ложатся на десктоп проект. Тестируются отдельные его части, для чего стандартного решения достаточно, если разобраться как он работает.

Делфи имеет штатный клиент для работы с MongoDB - пакет FireDAC (где поддерживаются десятки провайдеров). Всё корректно работает.

По поводу сервера. В Делфи есть несколько как штатных решений, так и сторонних (тот же mORMot). Например, есть официальное решение с REST сервером (в стиле Делфи, без лишнего кода).

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

Очень много библиотек для Делфи располагается на GitHub и через обычный поиск в гугле их сложно найти. А вот если подписаться на людей и следить за их подписками через ленту, то можно найти не мало интересных решений. Например, Keras4Delphi или Vulkan4Delphi, CUDA, TensorFlow, новую обертку для OpenCV, либы для блокчейнов и т.д.

Я исключительно про FP писал, с современным состоянием Delphi слабо знаком.

UFO landed and left these words here

Да, речь про UI, а главное про отсутствие посредников/прослоек между UI и данными в стандартном подходе в проектах на Делфи.

UFO landed and left these words here

Речь о стандартном подходе. И по сути там MVC. Но ни кто не мешает сделать MVVM и даже MVP. Или систему основанную на сообщениях (сигналах) и т.д.

Не нужно накладывать устоявшиеся "вебовские" приёмы в десктоп приложения. Действия UI легко управляются напрямую, а данные без проблем обновляются по удобной модели: колбэки, сообщения, события, да хоть по таймеру, после выполнения в тасках.

А система LiveBindings вообще позволяет обходиться без кода обновляя данные UI лишь указав визуально в дизайнере связи.

И не обязательно помимо контроллеров создавать "модель", которая будет управлять UI, если всё и так работает асинхронно. Обновляет данные в режиме реального времени без задержек и прослоек.

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

UFO landed and left these words here

А ещё, FL Studio, AIMP, KMPlayer, Game Maker Studio, Auslogics, HeidiSQL, Toad for Oracle, ...

FL Studio, HiediSQL, Toad тормозят так же, как и SQL Managment Stuido от MS, который фактически обрезанная MS Visual Studio стал.

FL Studio прекрасно работает и имеет не малую популярность, а HeidiSQL тоже не был замечен (мною) в тормозах. Toad - соглашусь, временами доставал. Однако, мой список лишь демонстрация того, что проектов не мало в том числе и свежих.

И существуют и другие проекты, о которых я не упомянул, например CudaText, Greenfish Icon Editor, RadioBOSS, Inno Setup, Guitar Pro, Heaventools, ESET Nod, Tunngle

UFO landed and left these words here
UFO landed and left these words here
Вот и получаем кучу скриптомакак, в нативный код не хочу и не умею, буду делать какашку на электроне, я у мамы программист 300к/нс. Что не так, холоп? Лагает моя программулька? Так ты поди ещё пару плашек озу прикупи по 128гб.

Альтернатива какая?

Альтернативой я вижу system-wide движок исполнения JavaScript на уровне ОС. Сейчас ситуация такова, что каждое Electron-приложение тащит с собой браузер, и потому ресурсы многократно прожираются для одного и того же функционала. Так вот, такого быть не должно.

То есть, во всех ОС должна быть однотипно реализована как минимум отрисовка?

Вопрос не в том как вы видите.

А в том, что реально есть и применимо + сравнимо по сложности с тем же електроном.

И как, есть такое?

То есть, во всех ОС должна быть однотипно реализована как минимум отрисовка?

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


И как, есть такое?

Что-то похожее представляет из себя ChromeOS (на самом деле нет, но очень бы хотелось).

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

Внезапно, да, просто вы этого не видите, как пользователь.
Вот пример того, какие ужасы от глаз пользователя тщательно скрывают, чтобы у него «всё работало»: habr.com/company/infopulse/blog/424369

А при чем тут веб сайты, если речь о кросплатформенных приложениях?

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

Delphi поддерживает кроссплатформенность (FMX: Win, Linux, Android, iOS, MacOS, Raspberry)

C# поддерживает кроссплатформенность (Avalonia: Win, Linux, Android, ...)

С++ поддерживает кроссплатформенность (Qt: Win, Linux, Android, ...)

Java поддерживает кроссплатформенность (JavaFX: Win, Linux)

"сравнимо по сложности с тем же електроном" - вы, видимо, не увидели :)

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

лично мне все равно, на чем будут писать софт, если он у меня запускается и работает без проблем.

Сделать калькулятор для винды - это, конечно, мило.

Но, увы, не вижу как это иллюстрирует кроссплатформенность.

Может покажете тимз для линукса на делфи, который занимает в 10 раз меньше памяти? Или хоть что нибудь более-менее популярное?

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

Здесь проиллюстрирован способ создания простого приложения на нескольких языках. Скорость разработки на электрон не выше и тем более не в разы.

Давайте вы будете здраво размышлять.

Давайте! После вас :)
Вы упорно игнорируете тот факт, что мне не интересны преимущества делфи, или любого другого языка.

Я - не разработчик. Есть набор приложений, которые я использую. Они работают с достаточной для меня скоростью.

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

Если кто-нибудь захочет переписать условный тимз с электрона на делфи, и он начнет жрать не 1,5гб, а 300Мб - отлично, я только за.
Но пока этого нет - преимущества того чего нет перед тем, что есть - вы мне не продадите )

Т.е. вы просите показать альтернативы, а после ещё "сравнения по сложности с тем же электроном", и теперь это вам не интересно? Что с вами не так?

Извиняюсь, конечно, но предложенные вами варианты, очевидно, не сравнимы по сложности. Иначе бы они были чуточку популярнее, и из 7 приложений на электроне, которые я запускаю, хотя бы 1-2 были бы на чем-то из предложенного вами.

Занятно, вместо попытки уточнить, что я имел в виду - вы утверждаете, что со мной что-то не так.

Ок, пусть будет со мной. Давайте уже не продолжать эту бессмысленную переписку )

Какова вероятность пропихнуть этот движок во все ОС?

У Microsoft он уже есть и встроен в систему — разумеется, на базе Edge. Но Apple ни за что не станет встраивать его в macOS. А Microsoft не станет встраивать решение от Apple. А где-то на заднем плане сейчас хор линуксоидов кричит о том, что они лучше умрут, чем поставят в систему хоть один байт от этих корпораций и вообще вы продались, раз предлагаете втыкать анальные зонды (ну, примерно такую риторику я постоянно вижу на том же Opennet). При этом, по условиям задачи вам нужно осчастливить и таких пользователей.

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

Пишут с этими словами манифест, после чего печатают его на принтере :)

Как же неадекватны обобщения.

У меня вагон и тележка приложений от майкрософт на линуксе - и не кричу почему-то. Ничего, даже нравится. Майкрософту больше, чем гуглу доверяю.

Да и по опеннету судить - моветон. Еще бы лор упомянули.

Наивный код! Язык с кроссплатформенными фреймворками. Таких языков не мало. И создавать приложения с нативным исполнением не так сложно. Вдобавок ко всему, многие фреймворки имеют дизайнеры интерфейса, что очень помогает в разработке.

А почему вы называете нас скриптомакаками? Мне вот не нравится с++ по целой куче причин, начиная от абсолютно нездоровой истории с UB и заканчивая дичайшей разнородностью экосистемы.

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

Тот же электрон скорее всего жрёт так много из-за того, что там под капотом прям браузер, с кучей каких-то ненужных приложению свистелок. Ну или это говнокод уже конкретных разработчиков, потому что сам v8 работает довольно эффективно.

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

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

>это прямое следствие ужасного дизайна с++ и долгого отсутствия альтернатив для натива.

Кстати, да. Rust и Go прекрасно показали, что компилируемые языки тоже могут быть модными и молодёжными.

А почему вы называете нас скриптомакаками?
Т — токсичность. А когда их называешь плюсодрочерами и дельфиё**ми в ответ, они обычно обижаются.

заканчивая дичайшей разнородностью экосистемы

Чего ну уж точно по веб ведь не скажешь...

QML с биндингами к любому языку который вам нравится

У Qt все прекрасно, кроме условий лицензирования.

что там такого ужасного в условиях по сравнению с другими инструментами?

Стоимость коммерческой лицензии, без которой на современном Qt почти нереально написать приложение, так как все новые компоненты под GPLv3, если мне не изменяет память. То есть там двойное лицензирование коммерческая + разные варианты (L)GPL для разных моделей. Раньше была возможность использовать LGPLv2 и просто размещать библиотеки Qt рядом со своим бинарником, а теперь либо open source, либо плати. Где-то пол года назад смотрел, на одно разработчика а год было около 75-80к р., причем лицензию по их условиям нужно оплатить до начала разработки. В общем для каких-то личных проектов с туманной перспективой монетизации предложение не выглядит привлекательно, как и для небольших команд в стартапах. Да и lts-патчи теперь только по платной подписке. В общем, они решили сосредоточиться на крупных клиентах и забить на сообщество (мое личное мнение).

Откуда эти нелепые слухи? Все также под LGPL как и раньше.

Например, отсюда.

Старые модули остались под LGPL, может, и какие-то новые тоже под LGPL, но есть и масса тех, что под GPL, что я и сказал в предыдущем комментарии. Если хотите знать точные имена - можете самостоятельно поизучать документацию или исходники. В основном, это касалось QtQuick-компонентов, но то было несколько лет назад, как сейчас ситуация обстоит - надо уточнять. Но факт есть факт: без коммерческой лицензии нельзя полностью использовать Qt в закрытых проектах.

Но факт есть факт: без коммерческой лицензии нельзя полностью использовать Qt в закрытых проектах.

Какой факт? Все модули QtCore, QtGui, QtQuick, QtControls, QtSvg, QtConnectivity и т.д. они все под LGPL. То есть по сути все что лежит в основном репозитории Qt это LGPL. В marketplace есть модули под GPL, но там могут быть модули под любой лицензией.

Так что же мешает использовать Qt, если все модули под LGPL?

Как вариант можно UI делать на Rust'овом druid. Оно конечно ещё очень сырое, но какие-то поделки делать уже можно, особенно если брать прямо `master` ветку, а не последний доступный релиз `0.7.0` ). Виджеты есть, события есть, данные отдельно. Из плохого — отсутствие документации, хотя это немножко компенсируется хорошими примерами прямо в репозитории. Как пример использования этого «toolkit»а рекламируют Spotify-клиент Psst

Но естественно это будет посложнее чем на электроне стряпать, особенно вначале. И для production оно очевидно (пока что) не подходит.

Есть еще iced-rs
Наверное, еще более сырое, но рабочее и кроссплатформенное, а еще там elm-architecture для ценителей /s

Вообще, достаточно приятные впечатления от раста как языка для гуи (да и вообще)

Пишите на .net с использованием Авалонии или OneUI.

Снять все же ограничение про C++ и использовать Qt?
Там все было сильно лучше чем с Gtk.

Под виндовс на чем писать?

На винапи — многим неприятно.

WPF (или как там его) — медленнее электрона.

Вот и получается, что электрон — норм.

Delphi - FMX. Как под Win, так и под Linux, Android, MacOS собирай. Отрисовка на GPU, эффекты, аниматоры из коробки. Мощный дизайнер в стиле Delphi.

Никто никогда не вернется в 2007 (и в программирование на Delphi)

При чем здесь 2007? Питон младше Делфи всего на 5 лет, однако что-то я не вижу, чтоб от питона внезапно все отказались, потому что ему уже 30 лет.

Вместо того, чтобы шутить и "минусовать" лучше бы полезной информации поделились, например аргументацией своей позиции.

"Нативные проги" предполагают написание на С/С++ ?

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

К сожалению, экосистема с/с++ все еще слишком молода и до сих пор не написаны средства сборки.

Зачем C/C++? Сейчас к вашим услугами имеются Rust и Go.

В Расте всё плохо с GUI, про Го не знаю.

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

Экосистема раста все еще не готова к гуям: https://www.areweguiyet.com/

Сам пользуюсь egui на расте, очень неплохая библиотека, легко делать свои виджеты и отлично кросс-компиляется даже в браузер, рекомендую. Со сборкой и зависимостями ноль проблем, npm-like experience.

Но массовому разработчику все равно сложно на расте писать, плюс асинхронщина на TS (очень важно для быстрых интерфейсов) значительно проще.

выглядит так же как в винде

фиговый аргумент "за"

вот тебе хороший аргумент "против": выглядит НЕ как остальная система

а если хочешь на самом деле получить ответ на вопрос "чем плох электрон" спроси у мейнтейнеров какого нибудь тырпрайзного дистрибутива (например suse).

Может, не нужно свою вкусовщину уже так откровенно навязывать?

Мне ваш аргумент "против" вообще не аргумент, окошко и окошко, одно из. Выглядит "не как остальная система" - осторожно, экстрасенсы в треде...

Мы с вами на "ты" не переходили. Мне до лампочки, почему лично вам или кому-то еще электрон плох. Я утверждаю, что для меня он - не плох. Чувствуете разницу?

Я, как пользователь, не вижу в электроне ничего плохого.

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

В чем проблема-то?

А я вот вижу проблему. Мы отказались от Скайпа полностью. Который работает отвратительно в том числе и 'благодаря' электрону, хотя до этого использовали его более десяти лет. Мы все перешли в нативную 'телегу' чем невероятно довольны. И на десктопе и на телефоне. Пока скайп работал не Делфе, всё было замечательно. Однако Майкрософт видимо скорее удавится, чем будет Делфю использовать. Перешли на электрон и в том числе и поэтому загубили отличный проект. Сейчас мой скайп с двумя сотнями контактов выглядит так же сиротливо как когда-то аська. За месяц ни одного сообщения. Боюсь, что его ждет судьба аськи.

Ведь если бы не появилась мода на маки в последнее десятилетие, никто бы и не думал о кроссплатформенных приложениях

Дело не только в кроссплатформенных приложениях. Электрон (да и браузер) просто очень сильно повышают уровень абстракций. Поэтому писать приложения на электроне просто, а цена разработчиков низкая. А рынок интересуют дешёвые технологии, а не правильные.

А вы думаете все до сих пор в компилируемых языках начинают с определения собственных строк? В С++ может быть, но в других языках уже давно не так. Уже очень давно разработка почти сразу начинается с разработки логики и подключение к БД, бэку или другим вещам. Например, описание сущностей и их атрибут для ОРМ. Дизайн и шаблоны тоже могут применяться отдельно и из других проектов.

Так что ваше представление о том, что "на Электроне быстрее" очевидно не отражает действительность.

ваше представление о том, что "на Электроне быстрее" очевидно не отражает действительность.

Чем ещё, в таком случае, объяснить такую любовь к написанию приложений, работающих именно через эту ОС внутри ОС, если не дешевизной?

Тем, что "разработчиков" пишущих на JS сейчас хоть задницей жуй. И они не хотят изучать другие языки. Вместо этого у нас Node.js, react и прочие поделки.

Так что да, с какой-то стороны это дешево.

Какая разница, что кто-то не хочет учить ничего, кроме JS — ради них нет смысла специально начинать новые проекты на нём, и уж тем более нет смысла на JS переводить существующие проекты, как нынче всё чаще делают.
Вешаем вакансию с требованиями по технологиям, которыми сами пользуемся, а не по тем, которых на рынке проще найти. Такой подход как раз создаст вакуум нужного рода, который смотивирует больше людей учить что-то помимо Node.js, а потакание минимальному общему деноминатору только подтолкнёт планку ещё ниже ко дну.

Да, забавная история. В принципе, многое в нашей истории сделано какими-то выскочками.

Многое в нашей истории сделано людьми. :-)

Разница между KHTML и Webkit громаднейшая. Поэтому не стоит забывать и о бесчисленных часах труда инженеров Apple и Google. Да, база - это KDE, но начальный росток, и конечный продукт это две большие разницы. Каждый, кто что-то делал, знает, как это сложно - завершить, довести до отполированного вида.

Чуваки сделали KHTML, их наработки взяла Apple и долго-долго работала над Safari, потом гугл взял их наработки, долго работал над JS-движком, сделал новый браузер и потратил кучу средств на его пиар. Но спасибо конечно говорить надо KDE.

Т.е. вы долго учились, потом десять лет работали, и наконец получили нобелевскую премию и наслаждаетесь успехом. В своей речи при получении премии вы говорите огромное спасибо своему отцу, который оплачивал вашу учебу и поддерживал вас, когда вы уже были готовы разочароваться в науке. Благодарите вы и своего деда, который брал вас с собой на кафедру в детстве и тем самым заинтересовал наукой.
И тут репортеры берут интервью у вашего прадеда, который заявляет, что прорыва в науке не было бы, если бы он не трахнул вашу прабабку на сеновале после сбора урожая. И это попадает в газеты с заголовком «Нобелевский лауреат всем обязан пьяному сексу». Вот примерно так я вижу эту статью.

Чуваки сделали KHTML, потом пришла Apple и они долго вместе работали над WebKit, потом пришёл Google и долго работал над WebKit вместе с ними, потом он решил форкнуться, выкинули KDE из списка авторов и впилили свой WebCore.
KDE продолжает поддерживать WebKit, Safari всё ещё на нём а не на Chromium, WebKit используется во многих встраиваемых приложениях типа телевизоров.

А почему это всё произошло? Потому что у KHTML была хорошая архитектура и удобная лицензия. Так что конечно современный веб не сделан в одно лицо командой KDE (да и команда ли это?) но вклад тут явно больше любви на сеновале.

«Я, конечно, не получил нобелевскую премию сам, это сделал мой правнук, но вы же не будете отрицать, что я серьезно вложился в премию: и своей генетикой, и генетикой выбранной мной девушки, и тем, что я смазливый и ей понравился, и нужным моментом..»
Тут ведь вопрос в чем. Вот есть такой чувак, Винтон Серф, который приложил руку, по сути, к созданию стандарта TCP/IP. На TCP/IP работает существующий веб. Можно ли сказать, что он родоначальник веба? Да едва ли. Не было бы HTTP over TCP over IP, был бы Gopher over NCP. Изменился бы сам веб? Стал бы он текстовым, без картинок и видео? Без JS? Да нет, вряд ли: картинки, JS и видео — это не последствия выбора протокола, это то, что возникает в головах одних людей на запросы других людей в тот момент, когда это становится возможным для реализации. Люди хотели быстро выполнять код, не запрашивая сервер, клиенты стали достаточно мощными, и вот, появился JS. Люди хотят картинки, которые мало весят, и появился JPEG. Не появился бы JPEG, жили бы с TIFF+ZIP, но картинки в вебе остались бы.
В становлении веба TCP где-то участвовал, конечно, им продиктованы некоторые вещи в вебе, например, упаковка спрайтов в одну картинку, но он не определял веб в целом. Если бы у протокола появились ограничения, не дающие передавать видео, к нему бы быстро написали новую версию, потому что люди хотят смотреть видео в интернете, протоколы без видео не выживут в эволюции.
Т.е. можно говорить о том, что Серф стоял у истоков современных сетей связи, но к ютубу он уже имеет опосредованное отношение, ютуб и видео-хостинги это сущность-над-сетями: люди хотели делиться видео, поэтому это стало реализовано. Можно говорить о том, что гугл стоял у истоков ютуба и видео-хостинга в целом, потому что именно его управление определило то, как ютуб сейчас выглядит и работает, а рабочие механики утаскивают на другие хостинги.

С браузерами так же. Можно говорить о том, что разработчики KHTML, как и Серф, заложили хороший фундамент в виде хорошей архитектуры, но если бы не KHTML, вряд ли Apple решили бы не писать браузер вообще. Ну, выбрали бы что-то другое. И гугл выбрал бы что-то другое. У них было достаточно денег и ресурсов, чтобы написать свою реализацию или лицензировать движок у оперы. Или взять фаерфоксовый. Повлияло бы это на текущую ситуацию кардинально? Да что-то мне не верится: у гугла была задача сделать свой легковесный быстрый браузер для обычных пользователей, были ресурсы для продвижения и люди, которые могут это сделать, и они бы добились такого плюс-минус эффекта на любом движке.

Ну, или другой пример: человек пишет на питоне алгоритм для автономных машин, и он получается настолько хорошим, что через пять лет 70% машин ездят под управлением этого алгоритма. Можно ли говорить о том, что за автономно-автомобильное будущее надо благодарить питон? Библиотеки питона, которые он использовал? Библиотеку openCV? Да нет, он писал алгоритм, и пусть реализация сильно зависела от ЯП, он бы написал его плюс-минус с той же успешностью на другом языке. А вот без этого человека уже все развалится.

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

Ну, вы хотели привлечь внимание, вы его привлекли.

Вы так много знаете! Может подскажете, как пропатчить KDE под FreeBSD?

Прошу прощения, случайно на телефоне на минус пальцем нажал, так что в качестве компенсации от меня плюс в карму.

Only those users with full accounts are able to leave comments. Log in, please.