Почему мы выбрали Electron

    Предыстория


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

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

    Почему десктоп


    В последние 10-15 лет web пережил взрывной рост и продолжает активно развиваться. Постоянно появляются все новые и новые инструменты для создания все более функциональных и сложных web-приложений. Создаются даже целые языки программирования, заточенные для написания web-приложений и практически не имеющие готовых решений вне этой области. Да и в нашей повседневной жизни мы уже частично заменили microsoft office и thunderbird на google docs и интерфейс gmail-а.

    Однако веб не может пока полностью вытеснить десктопные приложения, и вот по каким причинам:

    • Недостаточная отзывчивость web-приложений. Где-то всему виной клиент-серверная синхронизация и медленный интернет, где-то однопоточная природа javascript-а, а где-то и просто прожорливость браузера на вашей не очень мощной машине. Стоит заметить, что решение вышеперечисленных проблем лишь вопрос времени. В частности, web worker-ы уже поддерживаются всеми современными браузерами, что частично решает проблему отсутствия многопоточности, а возможности типа SharedArrayBuffer позволяют уменьшить накладные расходы на копирование памяти между основным потоком и воркерами.
    • Доступ к локальным ресурсам системы. Есть целые классы приложений (файловые менеджеры, tweaker-ы, демоны и сервисы) которые не могут быть реализованы как web-приложения (по крайней мере на данном этапе развития).
    • Ограничения возможностей самого браузера. К примеру, сетевое взаимодействие ограничивается только отправкой http запроса и соединения по web-socket-ам. Более низкоуровневые вещи (tcp, upd сокеты), увы, недоступны.
    • Искусственные ограничения браузеров в целях безопасности. CORS, работа с cookies, ограничения на отсылаемые заголовки.
    • Ограниченный набор языков и подходов. В отличие от web-приложений, где единственным языком для написания приложений остается javascript, десктопные приложения позволяют использовать любые языки программирования вплоть до ассемблеров, эффективно использовать ресурсы системы, применяя многопоточное программирование и низкоуровневые инструкции. Стоит отметить, что по данному вопросу ситуация улучшается — появляются транспилеры из некоторых языков в javascript. Более того, компиляция в webassembly позволяет перенести наработки из других языков (C++, C#, rust и т.д.), зачастую получая неплохой прирост производительности.

    Рассматривая причины, перечисленные выше, мы можем прийти к выводу, что TestMace должен быть типичным десктопным приложением:

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

    Выбор технологии


    Мы определились, что наше приложение будет десктопным, однако, пока не определились с языком и технологиями, на которых будем это реализовывать. Что касается языков программирования, то к ним нами предъявляются следующие требования:

    1. Это должен быть язык со статической типизацией.
    2. Язык должен иметь большую и зрелую инфраструктуру — должны быть как проверенные библиотеки так и поддержка со стороны IDE и других инструментов.
    3. Язык должен быть знаком большинству членов команды.

    Последний пункт также немаловажен. Мы как стартап заинтересованы в скорейшем (в течении полугода) выводе продукта на рынок, максимально используя внутренние ресурсы команды. Изучение нового языка и инфраструктуры уменьшает предсказуемость планирования и чревато ошибками в принятии тех или иных решений.

    Как бы то ни было, список требований не кажется уж слишком жестким, и ему удовлетворяют такие языки как C#, TypeScript, Go. Дальнейший выбор технологий будем проводить с учетом наличия реализаций необходимых компонентов для данных языков.

    Гораздо более интересно обстоят дела с выбором решений для разработки пользовательского интерфейса. Требования к ним следующие:

    1. Кроссплатформенность (Windows, Linux, MacOS)
    2. Богатый набор как встроенных так и сторонних компонентов
    3. Кастомизируемость компонентов
    4. Наличие языка разметки для описания интерфейса
    5. Хорошая поддержка

    Рассмотрим, какие решения подходят под данные требования.

    Qt (Qml)


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

    Основным языком программирования в Qt является C++ (в QML можно использовать javascript). Однако для Qt и QML есть биндинги для других языков программирования (вот например для C#). Однако официально поддерживается только интеграция с питоном. Все остальное — сторонние реализации. Согласитесь, не хотелось бы доверять самую базовую часть приложения библиотеке, которую разрабатывает как хобби небольшая группа энтузиастов.

    Еще есть проект Brig. Это NodeJS биндинги для QML. Отличительной особенностью данного проекта является впечатляющая демка. Однако, как оно часто бывает в open source проектах, авторы не уделяют должного внимания проекту и поэтому он также сходит с дистанции.

    GTK


    Библиотека для построения пользовательского интерфейса, которая начиналась как часть проекта GIMP и впоследствии была выделена в отдельный проект. Имеется инструмент Glade для быстрой разработки пользовательского интерфейса. Основным языком для разработки GTK является C, однако есть биндинги для многих популярных языков программирования. Более того, с использованием C# биндингов создавалась MonoDevelop — одна из самых мощных IDE для разработки под C#. Однако после более внимательного изучения мы понимаем, что проект GTK# находится в полузаброшенном состоянии — последний коммит был в феврале 2018, следующий в январе 2017 и далее 2016. По коммиту в год. Негусто, учитывая, что основной репозиторий gtk активно развивается. А счастье было так близко…

    Electron


    В последнее время очень много шума связано с данным фреймворком. Кто-то хвалит его за возможность перенести наработки веб-приложений на десктоп, кто-то ненавидит за чрезмерную прожорливость. И тех и других можно понять. Electron под капотом использует node.js и библиотеку рендеринга из Chromium. По сути создается обычное web-приложение и заворачивается в исполняемый файл. Причем каждое приложение поставляется с собственной версией Node.js и Chrome.

    Минус по сути только один, но достаточно серьезный — это большое (по сравнению с другими технологиями) потребление памяти: пустой проект занимает в памяти 100-200 мегабайт. Для некоторых это причина отказаться от использования таких приложений (привет, Skype). Однако давайте проанализируем ситуацию на рынке. На данный момент многие популярные приложения написаны на Electron (Slack, Skype, Discord, VSCode, Atom, Postman, Insomnia и т.д.). Многие из них являются стандартами в своей сфере или стремительно завоевывают сердца пользователей (как, например, те же VSCode и Insomnia). Люди просто используют инструменты, которые хорошо решают их повседневные задачи, невзирая на некоторые побочные эффекты. С другой стороны, компьютеры становятся все мощнее (как минимум, рост RAM не прекратился), и все меньше приходится слышать отзывы недовольных клиентов, что «ваш хром съел всю мою память». Резюмируя, мы считаем, что повышенное потребление оперативной памяти не будет играть большой роли в случае, если продукт будет действительно хорош в своей сфере.

    Плюсы же данной технологии очевидны:

    1. Возможность использования наработок из web.
    2. Проще найти специалистов в данной сфере.
    3. Отработанный воркфлоу «дизайнер» — «верстальщик» — «программист», изобилующий удобными инструментами на каждом этапе.

    Также к плюсу мы относим тот факт, что команда имеет большой опыт создания front-end приложений.

    В итоге, мы остановились на Electron как на основном инструменте для разработки нашего проекта. Автоматически, в качестве языка для разработки приложения мы выбрали TypeScript.

    Заключение


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

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

      0
      Ваше приложение это аналог Postman?
        +1
        Мы пересекаемся по функционалу с постманом. Однако, у нас есть ключевые отличия:
        1) Возможность создавать сценарии запросов (создать сущность -> получить сущность чтобы проверить, что она существует -> удалить сущность)
        2) Создания тестов без программирования. Мы имеем конструктор assertion-ов, который позволяет создавать их из UI. В случае сложных тестов вы так же можете написать скриптовый assertion на javascript.
        3) Человекочитаемый формат проектов (базирующийся на yaml). Это позволяет синхронизировать проект через системы контроля версий с возможностью code-review и т.д.
        4) Автокомплит переменных, заголовков, протоколов и т.д.
          0
          По поводу 3 пункта. Если это будет действительно удобно, хотя на примере Postman не совсем представляю себе как это возможно, то это будет наверное основной киллер-фичей.
          Жду от вас статью уже для тестировщиков, где вы наверное расскажите про этот пункт и п.1 подробнее.
      –1

      А вы не рассматривали WPF или WinForms для .Net Core? Они кроссплатформенные, едят намного меньше ресурсов. Плюс у них есть честная многопоточность, немало библиотек и т.д.

        +3
        Судя по github.com/dotnet/wpf/issues/48#issuecomment-444198305 оно не очень кроссплатформенное и вроде даже не собирается. Насчет остального тоже, многопоточность вполне честная, пусть и не такая удобная как в C#, да и коммьюнити у js достаточно мощное и готовых решений хватает
          0

          Перепроверил — вы правы. Тогда — только AvaloniaUI.

            +3

            Оно очень сырое ещё по UX.

          +4
          С каких пор они стали кроссплатформенными?
            0
            Когда говорят о кроссплатформенности на .NET всегда упомянают AvaloniaUI, однако она в бете
            +1
            Было бы интересно прочитать продолжение статьи через 6-8 месяцев активной разработки, когда будут уже сформированные процессы, возможно какие-то метрики и относительно большой опыт командной разработки. Тогда можно было подробно написать про объективные плюсы и муинусы.
              0
              Прелесть Electron состоит в том, что можно перенести наработки (как функциональные, так и с точки зрения бизнес-процессов) из web почти без изменений. Поэтому я думаю, что electron в этом плане нам палки в колеса вставлять не будет.
                0
                Хотя кажется что все что работает в браузере(Chrome), будет работать и в electron — это не совсем так.
                Например window.open работает с другим API, и даже если сделать nativeWindowOpen он не будет полноценно работать
                В случае использования авторизации через фейсбук, у открываемого окна не будет доступен window.opener, что ставит крест на возможности авторизации(хотя для electron@2 есть воркэраунд)

                Других значимых отличий по части браузерной работы я за полгода пока не нашел
                  +4
                  Прелесть Electron состоит в том, что проблемы разработчика перекладываются на плечи конечного потребителя (пользователя). Для меня, как воспитанника ещё старой инженерной школы, профессиональным кредо являются слова: «потребителю задача упрощается, инженеру — усложняется».
                  А Electron, позволяя разработчику «перенести наработки из web почти без изменений», непомерно и неоправданно жрёт ресурсы конечного потребителя. Именно из-за таких парадигм мы и не имеем в конечной производительности информационных систем того экспоненциального роста, который демонстрируют формальные показатели (а-ля закон Мура)!
                +8
                На данный момент многие популярные приложения написаны на Electron

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


                Давно мечтаю о нативном аналоге Postman.

                  0
                  Отчасти согласен, что самой большой претензией является сравнительно большое потребление памяти. Но. Смею заметить, что та же insomnia или постман потребляют в районе 500 МБ оперативной памяти. Для людей, который активно используют подобного рода инструменты подобные показатели — копейки. Зато функционал с лихвой перекрывает данный недостаток. Возможно в вашем случае этот функционал не критичен и вам достаточно того же curl
                    +8
                    Тем не менее 500 МБ для приложений подобного рода — это очень дофига.
                      +6
                      такое потребление это фейл. Определённые приложения могут возложить МПХ на своих пользователей в силу своей уникальности, что конечно же не делает им чести. Как правило это либо приложения, ставшие популярными в веб-версии, и выпустившие _такой_ клиент в качестве бонуса, либо приложения, уже имеющие огромную аудиторию, и перешедшие на электрон при очередном обновлении. Люди в силу инертности, привычки и базы контактов будут терпеть.
                      Для стартапа это на мой взгляд непозволительно.
                        –1
                        Тут я с вами не согласен. Ну начнем про стартап. Electron очень хорошо подходит для быстрого старта (большое количество специалистов, компонентов, текущие компетенции команды) — самое то для стартапа. Во-вторых, про то, что пользователи «терпят» — опыт атома, vs code, git kraken говорят об обратном, сообщества растут и развиваются. Да и найдите приложение, которое сфейлилось исключительно от большого потребления памяти? Что-то не припомню. Гораздо важнее, чтобы инструмент решал повседневные задачи пользователей. И, по моему скромному мнению, если инструмент успешно справляется с поставленными задачами по сравнению с конкурентами, то некоторую прожорливость (некатастрофическую) ему простят. Вы же не променяете IDE от Jetbrains на Notepad++ только из-за памяти, правда?
                          +2
                          IDE от Jetbrains, это совершенно другой весовой категории приложения.
                          И, к счастью, их на electron ещё не переписали, и надеюсь, не станут никогда.
                          Они сравнимы вполне по потреблению ресурсов с разными Nеtbeans и Eclipse которые их конкуренты потенциальные.

                          А вот Atom или VSCode уже можно посравнивать с нативными редакторами, и они явно проигрываеют им по потреблению ресурсов. И пользуются, как раз, в этой нише, не только ими, и даже не в основном ими в итоге хоть они и довольно популярны…
                            –6
                            А почему бы не сравнить тот же VSCode с Eclipse или Netbeans? У VSCode есть все фишки IDE.
                              0

                              Если все плагины поставить?

                                +1

                                VSCode, увы, не является IDE. "Integrated" из аббревиатуры не хватает. Все расширения живут своей жизнью и общаются с вскодом по LSP. В такой ситуации сделать расширение, которому, скажем, нужна из OmniSharp информация о проектах в солюшене, просто напросто невозможно. Это, кстати, одна из причин, по которым у Avalonia до сих пор нет расширения под вскод, нужно самостоятельно парсить солюшен, самостоятельно пинать мсбилд, итп.

                            +3
                            В итоге как всегда tl;dr: мы выбрали электрон, потому что так тупо дешевле.
                          0
                          Если на мак — paw.cloud
                            0
                            Попробуйте SoapUI. Не совсем нативное (java), но по сравнению с postman'ом он гибче и имеет намного больше возможностей.
                              +1
                              Тут один товарищ пишет аналог Postman на джаве и выглядит оно очень не плохо, правда функционала не хватает пока. Нужны контрибьюторы.
                              Нет сомнения в том, что и по памяти и по перформансу в целом оно уделает любые электрон монстры.

                              Everest
                            +15
                            При том, что вы очень быстро оказываетесь на рынке, вы получаете колоссальный техдолг. Этот техдолг — ужасающее непредсказуемое урчащее. Как только ваше приложение начнёт использоваться по назначению (т.е. в работе), окажется, что оно:
                            а) имеет latency до нескольких сотен (тысяч?) милисекунд в те моменты, когда этого хочется v8
                            б) ест память так, как будто оно запущено на тьюринг-машине с бесконечной лентой
                            в) заедает процессором.

                            Чем больше пользователи будут его использовать, тем более негативным будет их опыт. При этом пути назад почти не будет, потому что в разработку вложено много сил.
                              0
                              Ну уж вы сгустили краски). Тот же vs code — одна из самых популярных IDE на сегодняшний день — вполне себе шустро работает. Но то есть задержек нет даже когда я активно набираю и «требую» немедленного автокомплита) По поводу потребления процессора — тоже не вижу однозначной связи с electron. JS достаточно шустр. По поводу памяти нашу позицию я разъяснил в статье
                                +9
                                задержек нет даже когда я активно набираю

                                Другие пользователи с вами почему-то не согласны https://github.com/Microsoft/vscode/issues/27378


                                По поводу потребления процессора

                                А помните, когда-то давно мигающий курсор в VS Code кушал 13% процессора просто так?

                                  +2
                                  А помните, когда-то давно мигающий курсор в VS Code кушал 13% процессора просто так?

                                  Пробежался по статье. В конце нашел следующее

                                  Но в конце концов разработчики из Microsoft всё-таки решили вернуться на старый добрый JS-метод setInterval для мерцания курсора — и потребление CPU сразу снизилось в несколько раз.

                                  Ну то есть кривая реализация. Что поделать, всякое бывает, и не только на js.
                                  Другие пользователи с вами почему-то не согласны github.com/Microsoft/vscode/issues/27378

                                  Опять таки, исходя из этого всех собак надо повесить только на electron?) Замечу, что фризы возникают и в Visual Studio и в Jetbrains и в VS Code с примерно одинаковой частотой. Технологии диаметрально противополжные — проблема одна.
                                    +5
                                    Ну то есть кривая реализация.

                                    Нативные CSS-анимации — кривая, а setInterval — не кривая? Весело.


                                    Замечу, что фризы возникают и в Visual Studio и в Jetbrains и в VS Code с примерно одинаковой частотой.

                                    Поэтому я сижу на Sublime ;)

                                      –1
                                      Поэтому я сижу на Sublime ;)

                                      Возможно это выход, но явно не для каждого :)
                                        –2
                                        Нативные CSS-анимации — кривая, а setInterval — не кривая? Весело

                                        Ну и вы считаете, что на основе одного некритичного для многих и в конечном итоге решаемого бага вы делаете вывод о платформе в целом?) Не менее весело)
                                    +7
                                    Не очень сгустили. Пока Скайп был на Делфи, он нравился почти всем. Переписали на Электрон и он окончательно скатился в УГ (к моему большому сожалению, мне Скайп всегда нравился). У меня постоянные лаги и глюки на довольно хорошей машине (i7+gtx 960, 16 gb). На Андроиде Скайп работает просто отвратительно.
                                      0
                                      По поводу скайпа я с вами полностью согласен, совсем не радует во всех смыслах. Ну так и на скайпе мир клином не сошелся) В комментах упомянуты более интересные приложения на electron-е.
                                        +1
                                        Однако же плохих приложений на электроне на много больше чем хороших. Сразу вспоминается Viber и пресловутая Слака. Да vscode изрядно фризится на механических винтах, не многим меньше jetbrains (если меньше).

                                        Ну и надо признать, что веб технологии с реактами, редаксами, npm-ами, css-ом вот этим всем выглядят просто чудовищно уродливо в сравнении с популярными нативными фреймворками для десктопных gui приложений
                                  +11

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

                                    –1
                                    Это вопрос интересный. У electron хорошая поддержка в лице web-инфраструктуры. Как следствие, большое разнообразие интерфейсных решений, отработанные процессы, потенциально большее количество специалистов, да и про кроссплатформенность не стоит забывать. Однако electron конечно не самоцель: если удобнее на Delphi — пишите на Delphi
                                      +5
                                      Обезьянки, выучившие пару глав учебника по JS это не специалисты. И то что из под них выходит использовать не хочется ну вот прям совсем. На данный момент вообще не использую приложения на электроне, т.к. не хочу менять компьютер, только потому что на нем условный текстовый редактор тормозит. И вашим приложением тоже не буду пользоваться. Благо пока нативных приложений хватает.

                                      Обертка для веб-сайтов имеет свою узкую нишу применения. Не надо его использовать везде. Да тот же скайп как пример. Нативное приложение ресурсы не ело и было отзывчивым и удобным. Как только запихнули в электрон, так пользоваться стало жутко неудобно. Пришлось отказаться.
                                    +5
                                    200 мегабайт… когда-то я работал на машине, которая имела 0.5 Мб памяти… она обслуживала 50 рабочих мест онлайн, рассчитывала зарплату для предприятия со штатом около 5000 человек. Там была кадровая база и много чего. А жило все это на двух жестких дисках по 20 Мб каждый. Технический прогресс, однако…
                                      +2
                                      Вспоминается знаменитая история с диалогом о БЭСМ-6:
                                      — Представляешь, когда-то у каждого человека дома будет стоять ЭВМ, сравнимая по производительности с БЭСМ-6.
                                      — Неужели в будущем все будут настолько умными, что каждому нужна будет дома БЭСМ-6?
                                        +2
                                        Неужели в будущем все разработчики будут настолько глупыми и ленивыми, что каждому нужен будет для элементарных задач процессор с вычислительной мощностью в сотню-две гигафлопсов и вдобавок пара десятков гигабайт оперативной памяти?
                                        Ой… Как-то не заметили, а будущее уже наступило.
                                      +1
                                      Не рассматривали вынос «бэкенда» приложения на Rust, например. Вот тут один разработчик делился таким подходом. Жалко нет данных, насколько это может повлиять на потребление памяти. Если Electron будет отвечать чисто за отрисовку UI, и при этом отъедать не больше чем обычная браузерная вкладка, то возможно есть смысл заморочиться.

                                      Недавно, ради интереса, попробовал написать небольшое приложение с OpenJFX11 + сборка его же в виде runtime image. Потребление RAM 150Mb+, со старым ParallelGC — 120Mb+. Т.е. оно примерно в той же весовой категории, что и Electron, ну только что Java как бэкенд более производителен.
                                        0
                                        Пока не рассматривали такой вариант. На данный момент «бэкенд» приложения достаточно прост, думаю будем присматриваться к подобным решениям в случае возникновения проблем с производительностью в конкретных местах.
                                        +9
                                        Все похожие статьи можно существенно сократить:

                                        Почему мы выбрали электрон?
                                        Здравствуйте.
                                        Дешевле.
                                        Спасибо за внимание.

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

                                        Как-то обсуждали электрон и сошлись во мнении что: «За деньги я вам напишу что угодно и на чем угодно, но сам использовать не буду».

                                        Так, мысли вслух.
                                          +2
                                          Только не «дешевле», а «большую часть оплатят пользователи», ежедневно, каждый. А нам-то да, выйдет дешевле.
                                            0
                                            Стоимость разработки нативных кросплатформенных приложений может быть настолько дороже (как минимум в нашем случае), что разработку лучше не начинать вообще. Вы считаете, что отсутствующее приложение лучше, чем приложение, которые покрывает кейсы, не побоюсь этого слова, большей части пользователей?
                                              +2
                                              Не нужно сказок. Delphi/Лазарус существенно дешевле разработки на JS, по собственному опыту, используем и то и другое у себя в компании довольно давно (Delphi — 15 лет, JS — 10). Delphi/Лазарь сейчас работает практически на всех платформах, от утюгов (Лазарь, распбери — запросто) до Веба (есть пяток решений, от транспилляторов pas > js до ExtJS обёрток). Работает практически с одним кодом. Мы пишем в продакшне, Винда, Линукс, Веб (частично — 'чистый' JS, частично — UniGUI).
                                              Всё нативное, само собой.
                                              Лазарус, если что, полностью бесплатный. Delphi бесплатный с ограничениями по доходам.
                                                0
                                                Ну как ты вы лихо все приложения под одну гребенку подвели. Ну как минимум, нам нужен редактор для работы с подсветкой синтаксиса, автодополнением, статическим анализатором js кода, наличием встроенных подсветок синтаксиса. Плюс должна быть поддержка запуска скриптов на одном из популярных язков (jvm-based или js). Нас не устраивает как выглядят нативные компоненты, поэтому нам бы хотелось выбрать что-то стороннее.
                                                Ну и в завершении по поводу дешевизны разработки на Delphi/Lazarus. Зашел на сервис зарплат в моем круге (лучше, извините, ничего не придумал) чтобы оценить во сколько раз отличается количество delphi и js разработчиков. Delphi — 24 разработчика, js — 9147 разработчика. Разница просто колоссальная и она в целом отражает ситуацию на рынке — на js найти разработчика проще, чем на delphi, я думаю вы спорить не будете. Ну а между проще и девешле фактически можно ставить знак равенства.
                                                В общем не понятно, на основании чего сделан вывод о дешевизне разработки на delphi.
                                                  +1
                                                  В общем не понятно, на основании чего сделан вывод о дешевизне разработки на delphi.
                                                  По собственному опыту. Выхлоп отличного Delphi программиста против выхлопа отличного JS. Зарплата получается примерно одинаковая, но отдача не сопоставима, увы.
                                                  Людей найти можно и тех и других.
                                                  Большинство из того, что вы перечислили скорее всего есть в виде готовых Delphi компонент. Собственно — сама Delphi (IDE) написана на Delphi.
                                          +9

                                          Каждое приложение на electron потребляет какое-то совершенно невероятное количество ресурсов: оперативной памяти и процессорного времени, что никак не коррелирует со сложностью и функциональностью приложения. Каждое приложение на электроне тормозит и фризится даже на мощных рабочих станциях. Даже хвалёный тут и везде vscode. Одно, второе, третье приложение на электроне и вот уже мощная рабочая станция превращается в тыкву… гори в аду, electron!

                                            +8
                                            десктопные приложения позволяют использовать любые языки программирования вплоть до ассемблеров, эффективно использовать ресурсы системы, применяя многопоточное программирование и низкоуровневые инструкции.

                                            В итоге, мы остановились на Electron

                                            Вам не кажется, что тут взаимоисключающие параграфы?

                                              –2
                                              Ну во-первых здесь не сказано, что имеено сейчас нам это нужно, достаточно самой потенциальной возможности. Во-вторых, к Electron-у можно писать нативные расширения, что позволит ускорить конкретные места. Поэтому нет, не взаимоисключающие
                                              +11
                                              Читаю комментарии и прямо радуюсь что все таки не один я такой. Если вижу что приложение имеет в своей основе электрон, react native и подобные технологии быстрого приготовления — удаляю, оставляю только если нет альтернатив или приложение не вот прям обязательно по каким то причинам.
                                                +1
                                                Надеюсь, разум всё таки победит. Динозавры же вымерли? Есть надежда, что и текущее состояние дел не на всегда.
                                                  –5

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


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

                                                    +2
                                                    Да, PWA это отдельный ужас и боль. Если серьезно — то альтернативы web based фреймворкам и технологиям надеюсь в скором времени появятся. За Microsoft не слежу, хотя из долетавших до меня слухов он в этом направлении двигается, но например под мобилки от google вполне годный по архитектурной задумке flutter выходит. Да, пока только вышел, но в целом на мой взгляд перспективы есть у технологии как в плане быстрой и дешевой разработки, так и в плане производительности и расширяемости, тем более что можно подключать вполне написанные на других языках вещи. Также любопытно куда kotlin двинется. Ну а то что я стараюсь не пользоваться по возможности электрон/реакт нейтив приложениями — тут конечно не всегда меня такие продукты не устраивают по своим потребительским качествам (не зря себе комп собирал за 3 зп), но таким образом я кладу очередную песчинку на чашу нативных и компилируемых технологий против веба.
                                                      0
                                                      И чем же PWA — ужас и боль?

                                                      Flutter, имхо, хорошая вещь, но под desktop платформы официальной поддержкой не пахнет. Да и странно, что React Native вам не нравится, а Flutter, внезапно, нравится.
                                                        0
                                                        React Native в итоге все же исполняет js, да еще и с мостом к нативу, в отличие от флаттера который по примеру всяких фреймворков для игр рендерит все сам, не имеет никаких мостов, да и код даже сейчас уже практически в натив под железо компилируется (хотя там вроде есть отдельные но) если не в дебаг сборке. Насчет флаттера под десктоп — есть вероятность что появится (учитывая то что для веба он вполне оффициально пилится и есть репа с flutter-desktop, пусть судя по всему просто эксперимент)
                                                        А PWA это все те же js+html+css.
                                                          0
                                                          От того что Flutter рендерит все сам есть и плюсы, и минусы. Как минимум UI из-за этого медленнее, чем у React Native. Кто вам сказал такую глупость, что у Flutter'а нет «мостов»? Все также, как и с React Native в этом плане.

                                                          Все ещё не вижу ответа на вопрос, почему PWA — ужас и боль?
                                                            0
                                                            Почему медленнее? Как раз из за того что нет моста он и получится быстрее. Есть мосты к вещам вроде геолокации и подобным, но между кодом и UI мостов как раз нет вообще (хотя из того что я понимаю есть деление что рендерингом skia занимается, а код исполняется тот что скомпилирован из дарта — но по факту там нет накладных расходов практически, ибо это все равно что из C какую нибудь либу дергать).
                                                            «PWA это все те же js+html+css» — что означает все те же проблемы что и с вебом в виде зависимости от js (ибо даже при транспиляции именно js будет в итоге), тормозов (несмотря на jit'ы)
                                                              0
                                                              Быстрее, ага. Особенно webview или google maps. И мостов совсем нет, ага. /0 Хотя бы почитали бы отзывы в Google Play на Flutter Gallery. Куча проблем с производительностью.

                                                              На вопрос про PWA аргументированного ответа я так и не получил.
                                                          –1
                                                          И чем же PWA — ужас и боль?
                                                          Яндекс.Избач (дополнение для Яндекс.Метрики) — не только мониторит действия пользователей на сайте, но и вероломно шарится в их компьютерах. Ура! (надеюсь шутка).
                                                            0
                                                            Эм, PWA не дает доступа к FS. А если и будет, то будет просить соответствующее разрешение. К тому же, метрика сейчас везде есть и не зависит от технологий, так что к чему это вообще?
                                                    –3
                                                    А я тут посчитал, у меня на ноуте прямо сейчас пять приложений на Electron работают и ничего не тормозит, ОЗУ больше половины свободно. Что тут все обсуждают не понятно)
                                                      +2
                                                      Дайте угадаю, стоимость вашего железа 50к+?
                                                        +1
                                                        При нынешнем курсе с таким предположением трудно промахнуться :)
                                                          0
                                                          Вот и у меня 70+. Правда есть проблема что например иногда хочется что то поделать на ноуте за 16к (в деревню беру, или на прогулки). Да и в целом в провинции немало людей у кого ЗП немногим больше чем те самые 16 гигов памяти.
                                                        +9
                                                        Это до тех пор, пока вы не начнёте в этих приложениях работать. У меня рабочее окружение — Slack, Skype, Postman и VSCode. Примерно через 7 часов после запуска эта братия начинает дружно подвисать и тормозить различными способами. Это на 9700К и 16 гигах оперативки! Причём самое странное то, что по монитору ещё есть пару гигов свободной памяти и процессор не нагружен. Есть подозрение, что вся эта электронная муть своим жеесом под конец дня дико фрагментирует оперативку, отчего и фризы возникают. Перезапуск лечит ещё на 2-3 часа, дальше приходится перезагружаться. Это мне теперь нужно ещё 16 гигов докупать, чтобы гонять 4 электрона без проблем хотя бы часов 10?
                                                          0
                                                          Ну я, конечно, немного масла в огонь подлил, проблема мне в общем понятна, но меня самого всерьез никогда не беспокоила. Таких проблем как у вас у меня не возникает точно, на вашем месте я бы все проклял :). Из всех Electron приложений, включая Skype, притормаживал только Gitkraken и то на данный момент все уже исправили. Система перезапускается только в момент обновлений, когда без этого никак, все остальное время спит. То есть неделями все работает без перезапусков. ОЗУ 16 гб, если б было 8, наверное, все было бы грустнее.
                                                            0
                                                            Я как-бы точно не диагностировал виновника, но большую часть сьедает Slack (там 2 организации по 50+ чатов) и, естественно, VSCode (легаси проект на NodeJS с файлами по 8 тысяч строк кода). Но то, что виновник — электрон, я уверен на 100%. Если сидеть в телеграмме и XCode, то даже с утечками памяти в икскоде (когда приходится убивать SourceKit, сожравший 13+ гигабайт) можно более-менее спокойно работать весь день.
                                                        +2
                                                        C#, TypeScript, Go

                                                        Могу я узнать, почему вы не смотрели в сторону jvm?

                                                          –3
                                                          Не сильно знакомы с данной экосистемой
                                                            +3
                                                            Рискну показаться категоричным, но на сегодняшний день действительно сильными кроссплатформенными десктоп инструментами (с поправкой в том числе и на количество доступных специалистов на рынке) являются Qt (C++) и OpenJFX (Java и со.). Все остальные либо сырые, либо немного устарели, либо просто «модные».
                                                            image

                                                              0
                                                              … на сегодняшний день… (с поправкой в том числе и на количество доступных специалистов на рынке)… и OpenJFX ..

                                                              Я, конечно, практически не изучал данный вопрос, но разве по FX есть достаточное количество вакансий\проектов\специалистов? Да даже хотя бы обширное коммьюнити с достаточным количеством мануалов и гайдов?
                                                              Чисто по внешнему впечатлению, развитие этого продукта остановилось, им никто не интересуется, статьи о нём не пишутся на тот же хабр. Не слышал о нём за последние два года ни разу, вот от вас только, хотя постоянно слежу за общим фоном Java-мира.

                                                              Пробовал изучать FX и просто по удобству использования использования и удобству разработки сравнивал с шарповыми WinForm\WPF, которые под mono спокойно запускались на линуксах в том числе. Сравнивал чисто в пользовательском смысле.

                                                              И, FX безумно проигрывал по скорости разработки и удобству. Безумное количество лишних действий, которые не удобны в том числе из SceneBuilder. И сам SceneBuilder тормознутое, топорное и чудное… было пару лет назад.

                                                              Я, разумеется, его не правильно готовил, с этим спорить не приходится, тем не менее — общее состояние дел как-то изменилась за эти два года или всё примерно на том же уровне? Использовал FX-8
                                                                +2
                                                                Хайпа давно никакого нет, потому как сейчас десктоп инструменты не провоцируют хайпы в принципе. Столица плавно переместилась в Веб. Опять же — инструменту уже 8 лет, он вполне зрелый, чего тут хайпать? Недавно, правда, был один хайпец. Начинаяя с версии Java 11, JavaFX больше не часть JDK. Она стала отдельным модулем, называется OpenJFX и перешла в поддержку компании Gluon и OpenJDK комьюнити. Доступна из maven репозитория и версионно с JDK больше не связана. Если действительно следите за общим фоном Java-мира, то в конце прошлого году точно должны были слышать. Штаб находится тут. На Амазоне вы легко найдёте более сотни разных книг/учебников.

                                                                Мне сложно понять, какой конкретно острый угол фреймворка вызывает у вас такое яростное неприятие, поскольку инструмент с большего крайне удобен, интуитивно понятен, да и вообще хорошо и быстро работает. Изъяны есть. Как и везде. SceneBuilder я не использовал. Сейчас вообще десктоп инструменты используются значительно реже. Я также использую данный фреймворк лишь эпизодически. Хотя и давно. Как он может безумно (!) проигрывать хоть чему-то, мне не понять. Обычно так эмоционально выражаются апологеты другой платформы (скажем .NET), знакомые с Java инструментами крайне поверхностно, но изначально идеологически настроенные против.

                                                                Из своего опыта, могу сказать, что некоторое отчуждение испытывали люди, которые впервые сталкивались с более новой концепцией построения GUI. JavaFX использует некий базовый контейнер-подмосток, на котором может быть выстроена одна иди несколько сцен, состоящих из любых графических элементов. Каждую сцену, вместе со всем её содержимым, можно как угодно трансформировать (масштабировать, скручивать, поворачивать...), анимировать, менять цвета и яркости. И даже источники света размещать. Некая форма с кнопками это всего лишь частный случай сцены. А в целом получается очень гибкая графическая конструкция (и 3D). Идея не нова, таким же образом построены Qt и WPF. Но люди пришедшие из WinForms, Swing, Delphi и ожидающие увидеть доску на которую накидываются контролы, порой, с мороза, чувствуют себя неуютно. Им всё кажется излишне сложным и избыточным. К чему такая мощь для кнопочек? Ну только лишь для кнопочек может и ни к чему.

                                                                Ещё одна не всем привычная и пугающая новичков фишка — реактивность свойств. Любое свойство графического объекта может быть «сцеплено» с другим свойством другого объекта. То, в свою очередь, с неким свойством третьего и так далее. Меняя одно свойство, автоматически меняются связанные. Примерно как пересчитываются связанные клетки в Excel. Ну и сцена обновляется. Идея не нова, она положена в основу реактивного программирования, но если вы не имеете навыков такого рода построения интерфейса, то… вы опять же сразу не оцените всю мощь и гибкость такого подхода. И будете по привычке искать какие-нибудь события для того, что бы их «как обычно» обработать.

                                                                Есть ещё одна особенность, которую некоторое количество людей люто, патологически ненавидят. JavaFX — фреймворк класса 'lightweight'. Другими словами — все свои контролы он рисует сам и не использует родные контролы операционной среды. Ну и стало быть интерфейс может выглядеть не как родной, нейтивный. Также устроен и Qt. И старенький Swing.
                                                                  0
                                                                  Ох, благодарю за развёрнутый ответ.

                                                                  Мне сложно понять, какой конкретно острый угол фреймворка вызывает у вас такое яростное неприятие, поскольку инструмент с большего крайне удобен, интуитивно понятен, да и вообще хорошо и быстро работает. Изъяны есть.

                                                                  Но люди пришедшие из WinForms, Swing, Delphi и ожидающие увидеть доску на которую накидываются контролы, порой, с мороза, чувствуют себя неуютно. Им всё кажется излишне сложным и избыточным

                                                                  Вот примерно с этого угла и вызывает неприятие. Все свои UI я конструировал в конструкторах, по-типу Delphi, VisualStudio. В последнем, сот-но winforms и WPF. Да, в впф появилось больше возможностей, но в нём всё ещё было комфортно конструировать «по старому», набросал на доску, пара кликов и все ивенты нужные созданы, все элементы с доски доступны в твоём скоупе, никаких проблем, даблклик и счастье наяву.
                                                                  Простые инструменты для входа с сокрытием сложности и автогенерацией кода. Если не выходить за рамки обычного десктопа, простых игрушек, то всё элементарно и вызывает лишь радость.

                                                                  Перейдя на Java я просто запомнил, что на ней такого уровня конструкторов нет и особо не интересовался UI, перейдя в сторону бекенда. И, когда узнал про javaFX и про SceneBuilder — решил попробовать и начал пытаться делать всё по старому.
                                                                  Но… автогенерации кода тут нет, всё ручками-ручками, лишь IDE помогает, но суммарно каждое изменение формы через SceneBuilder вызывало отторжение. Изменил там, сохранил, перешел в текстовое описание интерфейса, протыкал по всем созданным элементам, создал их в контроллере с помощью IDE. И так каждый раз. И, на самом деле, это было неприятным, но не критическим фактором. Добивающим фактором для меня стала просто отвратительная работа самого конструктора. Топорный, элементы располагаются с трудом, постоянно сползают при переносе и регулярные зависания самой программы. Особенно, если пытаешься использовать встроенный SceneBuilder через Idea.

                                                                  Собственно, я прекрасно понимаю, что просто использовал инструмент не так, как полагается и поэтому к самому JavaFX у меня нет никаких негативных эмоций. Но я всё жду, когда кто-нибудь про неё напишет занимательный цикл статей с посылом «Хэй, JavaFx жив и удобен в наше время! Он реально классный!».) Мечты-мечты.
                                                                    0
                                                                    В JavaFX, как и в Swing, при прочих равных, стараются избегать абсолютного позиционирования (разные платформы, разные шрифты, разное разрешение...), а предпочитают использовать специальные layout managers. Это контейнеры, которые расставляют расположенные на них визуальные объекты по определённому закону. В виде сетки, разбивая на некие группы, поддерживая нужные расстояния между ними, меняя их размер с изменением размера охватывающего контейнера ну и прочее. Есть несколько стандартных, есть написанные сторонними людьми. Ну и свой можете написать. SceneBuilder также предлагает класть их как подложку, что некоторых может озадачить, если раньше не сталкивались с таким подходом.

                                                                    По поводу цикла статей. Есть проект на гитхабе, где человек собирает ссылки на материалы, касающиеся JavaFX. Сторонние библиотеки/фреймворки, книги (их уже много, потому неактуально), статьи, блоги etc. Сейчас, когда материалов уже много, это менее актуально, но тем не менее. Опять же JavaFX работает для всех языков программирования доступных на Java машине (Clojure, Groovy, Kotlin, Scala, Ceylon, JRuby, Jython, Nashorn (это вариант javascript)).
                                                                      +1
                                                                      Перейдя на Java я просто запомнил, что на ней такого уровня конструкторов нет

                                                                      Для Swing неплохой визуальный редактор есть в NetBeans.

                                                                      0
                                                                      Далеко не все так радужно как вы описываете:
                                                                      * OpenJFX версионно не связана с OpenJDK, это так, но при этом они придерживаются одного графика выпуска релизов.
                                                                      * После того как JavaFX выкинули из JDK она естественным образом также стала platform dependent. При этом, если, например, вы еще можете найти 32-битную сборку OpenJDK для Windows, то для OpenJFX нет.
                                                                      * OpenJFX не развивается годами. По сути, все что было сделано в промежутке от JavaFX 8 до OpenJFX 11, это выпиливание JavaFX и подержка JPMS. Я не говорю про новые фичи (хотя очень хотелось бы), но ведь даже от таких позорных багов не избавились за 7+ лет.
                                                                      * Заявлять что JavaFX порреживает HTML5 и минимальный веб-стэк конечно можно, но с оговорками. А именно то, что компонент WebView, который построен на Webkit нереально жирный. От 300-400 метров памяти он съет как нечего делать, плюс добавит немаленький лаг при начальном запуске, так что я лично на него просто забил.
                                                                      * JavaFX точно не относится к классу легковесных решений. Какой-нибудь Hello World еще будет компактным, а вот приложение с относительно сложными формами уже нет. Вы платите ресурсами за каждый компонент, и платите больше чем в native (и больше чем в Electron).

                                                                        0
                                                                        Да ну какое там радужно. После того, как на рынок вышли мобилы, и там три ключевых разработчика ОС не смогли найти общего языка, и javascript оказался единственным кроссплатформенным «клеем»…
                                                                        Qt пошла по рукам. JavaFX стагнирует. Javascript возомнил себя победителем, и теперь все новые проекты это чисто Франкенштейны типа Электрона. Цивилизация куда-то не туда свернула, пытается выкарабкаться всякими там TypeScript…

                                                                        Оно может и неплохо, что FX ушла в Open мир. :)
                                                                +2
                                                                И Delphi
                                                                  –1
                                                                  Зря передергиваете. В соседней ветке спор по теме на чем дешевле разрабатывать так и не был разрешен.
                                                                    0
                                                                    sciter не смотрели для вью? в связке хоть с чем для бизнес-модели (c++, c#, delphi и т. д.). Вроде интересное решение.
                                                                      0
                                                                      Как-то пытался сделать простое pet-приложение на нем. В итоге столкнулся с тем, что Sciter достаточно сырой под Linux, и вокруг него все равно приходится городить огород из кусков WinAPI/GTK+. Ну и в минусы: закрытые исходники, один разработчик (который, впрочем, достаточно оперативно фиксит баги и пилит фичи по запросу), статическая линковка и доступ к исходниками за деньги. В общем, для некоммерческого хобби я бы его взял, для разработки коммерческого приложения, с которого собираюсь получать доход — нет.
                                                                +10
                                                                Потому что у вас нет совести. (Но это нормально — совесть бизнесу обычно мешает.) Всё остальное (написанное в статье) — вторично.
                                                                  0
                                                                  Эх, чем больше приходится сталкиваться с постманом и подобными поделками, тем больше жалею, что забросил в далёком 2009 писать GUI для libcurl аж на RealBASIC. Функциональности было столько же, летало как нативное, только вот со временем проще стало запоминать команды, чем поддерживать эту жесть. Но как минимум оно умещалось в пару мегабайт оперативки, чего для её задачи в принципе-то всё ещё слишком много.
                                                                    +1
                                                                    Имхо нативные приложения для десктопа на чём бы то ни было приятнее и использовать, и разрабатывать, и распространять.

                                                                    По поводу электрона — разработка под веб значительно сложнее, чем под десктоп, будь то даже Qt на С++. И инструменты под веб относительно не очень. Потому годится электрон только для таких кейсов как у Вас, когда в команде большой экспириенс в js, и мало в других языках.
                                                                      0
                                                                      В представленных примерах приложение на электроне либо опенсорсное, либо бесплатное (иногда есть отдельные платные фичи завязанные на внешний сервис). Ни слова о том, как у Electron обстоят дела с обфускацией кода и защитой от отладки, что весьма интересно для приложения на котором хочется делать бизнес.
                                                                        0
                                                                        Ну вот Skype и VS code open source же, да? ;)
                                                                          0
                                                                          VSCode — опенсорс под MIT.
                                                                          У шкайпа обфускация + бинарные проприетарные костыли.
                                                                        +3
                                                                        Основная проблема приложений на Electron — это не только невероятное количество потребляемых ресурсов, но и отзывчивость интерфейса. И вот это уже ставит крест на вашем приложении.
                                                                        Потому что многие разработчики критичны к этому параметру, и не будут в качестве рабочего инструмента использовать что-то тормозящее.

                                                                        Я так и не понял, чем вас не устроила связка Qt/C++. Почему упор на C#?

                                                                        Electron обычно используется по причине дешевизны разработки — потому что высокая степень унификации между веб-версией и десктоп-версией в плане кода. Но у вас такой проблемы не стояло — и выбор от этого «браузера в окне десктопного приложения» выглядит ещё более странным.

                                                                        Потому спасибо, но нет.
                                                                          0

                                                                          Почему вы выбрали electron?
                                                                          Потому что ничего не знали про wx, например.
                                                                          Wxnode, если хотите JavaScript.
                                                                          Его, кажется, только под c# кросс-платформенный нет. Технологии (платформе?) более 20 лет, и она поддерживается и развивается. Думаю, даже когда JavaScript станет многопоточным и в нём запретят 1+'1' и подобное, wx будет развиваться.

                                                                            0
                                                                            Самая первая фраза в readme репозитория
                                                                            Feel free to use this module but, I am no longer supporting it in favor of AppJs
                                                                            Ну и последний коммит 7 лет назад.
                                                                              0
                                                                              c# кросс-платформенный


                                                                              Нет. Mono как был обрубком, так и остается.
                                                                              www.mono-project.com/docs/about-mono/compatibility

                                                                              Слово «кроссплатформенный» нельзя применять к различиям между Windows 7 и Windows 10, как делает Microsoft в своих рекламных материалах.
                                                                                0
                                                                                Ой.
                                                                                А мой код из нескольких проектов написаный на С# работает на Linux, MacOs, iOs и Android.
                                                                                Что я делаю не так?
                                                                                  0

                                                                                  А какой тулкит использовали, если не секрет?

                                                                                    0
                                                                                    Для webAPI и console app использую .NET Core.
                                                                                    Причем вне зависимости винда или линукс — мне .NET Core симпатичнее, чем виндовый .NET Framework, потому что работает быстрее, опенсорсный и многие штуки там сделаны уже проще чем в старом .NET.
                                                                                    На MacOS он тоже будет работать.
                                                                                    iOS и Android — на Xamarin. Его же можно использовать для UWP-приложений и запускать в винде, но я не делал такого.
                                                                                    Разработка при работе на винде — VS 2017, на маках — VS 2017 for MAC, разок надо было под убунтой девелопить — тут VS Code использовал. VS 2017 можно использовать Community edition — она для индивидуального разработчика дает фактически все тоже самое что и платные версии.
                                                                                      0

                                                                                      Так получается, что у вас всё равно разные технологии для UI на разных платформах, а для линукса и мака вы десктопные приложения в принципе не пишете?

                                                                                        0
                                                                                        я писал ответ на
                                                                                        "
                                                                                        «c# кросс-платформенный»
                                                                                        Слово «кроссплатформенный» нельзя применять к различиям между Windows 7 и Windows 10, как делает Microsoft в своих рекламных материалах."

                                                                                        На языке C# я могу писать под разные OS и оно будет работать, но да — пока нельзя писать десктоп под Линукс и Мак.
                                                                                        Будем ждать WPF — она пока перебирается на .NET Core и может уже потом под нее сделают движки для Linux и Mac. После перевода на .NET Core и открытия всего кода это будет уже значительно проще
                                                                                          0

                                                                                          Просто вопрос о кроссплатформенности UI в контексте статьи и ссылки на Mono Compatibility как раз очевиден.

                                                                                            –1
                                                                                            «WPF перебирается на .NET Core » — это не правда, ничего подобного и близко нет. Загуглите что означает буква W в аббревиатуре WPF. Посмотрите как она устроена внутри. Посмотрите, когда вышел последний релиз. Эту библиотеку закапывать пора, а не портировать на линукс.
                                                                                    0
                                                                                    Скорее всего, имелся ввиду .NET core, а не mono.
                                                                                  0
                                                                                  Не для полемики, а из любопытства: а Xamarin + Xamarin.Mac чем не устроили?

                                                                                  Я почему спрашиваю… Я бы такую задачу решал на Delphi, но это чисто личный выбор. У меня команда вся на Delphi пишет, куча отлаженного кода и нужных классов, большой опыт разработки на Delphi для Win и Mac. Но если бы я был не я, а какой-нибудь более молодой человек, без «наследства», который может выбрать любой инструмент чтобы начать проект с чистого листа? Я никогда не пользовался Xamarin + Xamarin.Mac, но из того, что я слышал, вроде бы это то что надо, и не нужен никакой Electron с большим RAM usage и противненьким ненативным рендерингом шрифтов? Или я что-то упускаю?
                                                                                    0
                                                                                    Ну во-первых его нет для linux. И он бы нас не устроил уж очень малым набором готовых компонентов. К примеру, тот же самой редактор с подсветкой синтаксиса самим писать не хотелось.
                                                                                      0
                                                                                      Ок, спасибо. Не знал про малый выбор компонентов.
                                                                                        0
                                                                                        Думаю, что Lazarus в этом смысле был бы лучше. Умеет в том числе в Линукс, Мак, Малину. Редактор с подсветкой синтаксиса точно есть. Собственно — сам Лазарус, который полностью в сырцах. Там же можно посмотреть как и что сделано. Подсветка, дополнение кода и прочее. Бесплатный, без жуткого оверхида по памяти и скорости. Всё нативное:
                                                                                        image
                                                                                        image
                                                                                        image
                                                                                          0

                                                                                          Кстати а почему в Лазарусе и Делфи компоненты доступа к данным нужно бросать на форму? Это же нарушение SRP. По идее же, если уж делать визуально, то их следует бросать на некий сервисный слой, не принадлежащий форме, откуда они будут доступны с помощью DI.


                                                                                          И ещё в глаза бросилось, что в последнем примере автор не знает про anchors. Типичная болезнь делфистов никуда не делась. Уж лучше бы, наверное, в Лазарусе были layouts.

                                                                                            0
                                                                                            нужно бросать на форму
                                                                                            Не обязательно. Существуют специальные дата модули (TDataModule). На них кидать удобнее.
                                                                                              0
                                                                                              И ещё в глаза бросилось, что в последнем примере автор не знает про anchors. Типичная болезнь делфистов никуда не делась. Уж лучше бы, наверное, в Лазарусе были layouts.
                                                                                              Всё это есть. Просто не поставлено. Есть разные сборки, как на первых скринах, так и как на последнем. Некоторые сборки идут сразу со связанными окнами в рабочий стол, некоторые — как на последнем скрине. Но можно доставить пакет из списка доступных в несколько кликов, будет выглядеть связанным. Lazarus/FPC, в отличие от Делфи, полностью оупенсорсный и его коробочных сборок существует штук 5. Можно выбрать более удобную.
                                                                                                0

                                                                                                Вы не так поняли. Я про вот это:



                                                                                                Видно, что грид не будет менять размер при изменении размеров формы, потому что программист не проставил anchors. В других тулкитах, например, Qt, GTK, Swing, WPF, Android UI, вёрстка формы идёт с помощью layouts, которые сами гибко контролируют размеры дочерних элементов.

                                                                                                  0
                                                                                                  А, ну это же тестовая наброска :) По умолчанию там Align = alNone, поставите, например, alBottom и будет как хочется. Среда сама за программера не додумывает, как ему удобнее якоря сделать. Layouts мне не нравится отсутствием wysiwyg. Не сразу ясно, что получим на выходе, запускать приходится. Ну или мне такие layouts попались.
                                                                                              –1

                                                                                              Пробежался — не нашел компонентов-редактров для подсветки синтаксиса с автодоподнением и поддержкой подсветки js, json, xml, yaml и возможно ещё чего нибудь. Ну вот не нашел я компонентов уровня ace editor или code mirror. Нативные компоненты 1) мне не нравятся, 2) выглядят по разному на разных ос, что усложняет поддержку. Кастомизация интерфейса очень неудобная по сравнению со связкой HTML и css.

                                                                                                0
                                                                                                Можете посмотреть 'коробочный' TSynEdit:

                                                                                                Снимок
                                                                                                Нативные компоненты 1) мне не нравятся, 2) выглядят по разному на разных ос, что усложняет поддержку
                                                                                                Подавляющему большинству (мне в том числе) нравятся нативные компоненты. По поводу поддержки уже сказали. Что не стоит проблемы разработчиков перекладывать на плечи пользователей.
                                                                                                  0
                                                                                                  Вот пара примеров TSynEdit'а:
                                                                                                  image
                                                                                                  image
                                                                                                  image
                                                                                                  image
                                                                                                  Поискал, нашел такой проект (Delphi):
                                                                                                  www.windows8downloads.com/win8-dev-php-pujtiyff/screenshot.html
                                                                                                  Исходники:
                                                                                                  devphp.sourceforge.net
                                                                                            +1
                                                                                            Одной рукой ругаем скайп (с точки зрения пользователя), а с другой пишем сами на электроне потому что *куча_причин_почему_электрон_лучше*.

                                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                            Самое читаемое