Comments 119
Пожалуйста, не надо, хватит нам чатиков на электроне которые по 6гб озу жрут за 2 дня аптайма (слак)
Кроме этого они ещё и тормозят и выглядят обычно как дерьмо. Так что, присоединяюсь — не надо!!!
Это у Вас еще в щадящем режиме как-то.
Можно подумать, на сях нельзя написать так, чтобы приложение выжрало хоть 10 Гб памяти, хоть за 5 минут. Любым инструментом можно пользоваться по-разному.
И потом, у меня слак запущен уже несколько дней, выжрал за это время целых 60 Мб! Значит, можно при желании написать нормально? При этом скорость и стоимость разработки несравнимы.
Просто на фреймворках js (даже не ванильном уже) для того чтобы выстрелить себе в колено усилий не надо совершать никаких — взять хотя бы реализацию ng-for из первого ангуляра, когда простой массив на пару сотен элементов превращается в бенчмарк процессора и оперативки.
На самом деле приведённый пример в статье хорош, но вероятность того что сделают очередной краш тест очень высокая, к примеру steam тоже на электроне, но его ни разу не замечал в топе процессов.
На самом деле приведённый пример в статье хорош, но вероятность того что сделают очередной краш тест очень высокая, к примеру steam тоже на электроне, но его ни разу не замечал в топе процессов.
UFO just landed and posted this here
Вы пробовали десктопную версию WhatsApp? Она тоже на electron, только написана без утечек памяти.
Я поддержу вот этот комментарий с минусами:
Я вот раз в неделю перезапускаю Chrome, потому что память подтекает (тот же Gmail стабильно толстеет). Дело в хроме?
Я поддержу вот этот комментарий с минусами:
Можно подумать, на сях нельзя написать так, чтобы приложение выжрало хоть 10 Гб памяти, хоть за 5 минут. Любым инструментом можно пользоваться по-разному.Дело не в инструменте, а в том, кто его использует.
Я вот раз в неделю перезапускаю Chrome, потому что память подтекает (тот же Gmail стабильно толстеет). Дело в хроме?
Именно, как же заколебало уже это вечное нытье про ноду и память. Можно подумать, та же джава вся из себя такая суперлегкая.
У меня хром, edge — открываешь facebook — всё, начинается тупёж — пытаешься открыть в вкладке фейсбука чатик — указатель мышки в колесико — секунд на 30. Ну, тоесть виджет чатика может открываться 30 секунд. Веб приложение телеграмма мне каждое утро надо открывать заново — умирает напрочь.
Да, я считаю reactjs отличным фреймворком — мне на нём писать сложное веб-приложение — морду к панели управления хостингом в удовольствие, но при этом сайт фейсбука превращается в УГ.
Нок инженер говорит, что вкладки с документацией у Джунипера могут отожрать пару гигов памяти за сутки.
Могу сказать одно, разный контекст это ужасно как неудобно. Только ради этого, стоит отказаться от electron и выбрать вообще что-то другое, nw.js или вообще другую платформу и язык для этого.
Да, это прикольно, писать кросс-платформенные приложения на вебе. Но… как только представляешь, сколько десятков и сотен мегабайт абстракций оживляет ваш код в десяток команд и пару форм, становится страшно.
Назовите адекватную причину, зачем, может понадобиться использовать стек веб-технологий для создания standalone приложений?
Вместе с единственным сомнительным бонусом — единообразие кода и технологий в проекте, сочетающим в себе веб и десктоп (все равно не представляю таких задач) вы получаете кучу проблем, о которых собственно написана эта статья и еще пару десяток в придачу.
Вместе с единственным сомнительным бонусом — единообразие кода и технологий в проекте, сочетающим в себе веб и десктоп (все равно не представляю таких задач) вы получаете кучу проблем, о которых собственно написана эта статья и еще пару десяток в придачу.
Экономия времени и денег при разработке. можно взять часть кода от веб приложения и адаптировать его под десктоп.
Например, в случае, когда нужно сделать десктоп и мобильное приложения, логика взаимодействия с сервером в которых совершенно одинаковая — в таком случае, удобно один раз написать эту логику на JavaScript и использовать как в nw.js / Electron, так и в React Native.
А мы пишем на C++ и получаем кроссплатформенное приложение под Windows, Linux, Mac, Web(через emscripten).
видел я такие приложения с месивом платформенных дефайнов и макросов. UI у вас тоже кросс-платформенный? QML? OpenGL?
дефайнов и макросов.
Это признак кривой архитектуры.
По историческим причинам свой фреймворк на OpenGL. Под Windows пока через Angle, но в планах использовать DirectX
(я где-то сломал хабр и он продублировал предыдущий коммент)
"V8 — потому что клапана расположены буквой V и их 8 (клапанов). Двигатель V8 уже давным-давно используется."
Не клапана, а цилиндры.
Вот скажите, фронтендеры — я заметил, что только в вашей тематике следующая фишка.
Вы минусуете статью, если вам не нравится подход, в ней описанный. Например, вы фанат другого движка, тогда вы минусуете статью про другие движки.
Почему так? Я серьёзно спрашиваю, ни в серверной разработке, ни в администрировании такого нет :)
Вы минусуете статью, если вам не нравится подход, в ней описанный. Например, вы фанат другого движка, тогда вы минусуете статью про другие движки.
Почему так? Я серьёзно спрашиваю, ни в серверной разработке, ни в администрировании такого нет :)
А может наоборот: разработчики других языков минусуют за то, что Javascript используется в несвойственном ему месте
Ну и что?
Статья же не заставляет никого делать ничего ему не приятное, это просто обсуждение идеи. Ну не согласны в с идеей, за что минус то?
Статья же не заставляет никого делать ничего ему не приятное, это просто обсуждение идеи. Ну не согласны в с идеей, за что минус то?
Думаю, что основная цель минусов в том, чтобы те, кто только думает, какой стек выбрать для разработки кросплатформенного по, не ошиблись с выбором. Например я, не пишу десктопное по, но ради фана готов набросать софтину в свободное время и потому из интереса читаю статью. Вот так статью прочитаешь, и скажешь, нах мне там эти си, всё на js сделаю, круто же, работает. Но это не так. Что-то не так в головах. Причем повсюду. Вот только сегодня на тостере читаю ответ уважаемого разработчика, занимающего первое место в знаниях вордпресса на апворке о том, что никакие фреймворки не нужны, и для всех задач хватает вордпресса. Как говорится — «всяк кулик свое болото хвалит». Как оно там работать будет, вы не задумываетесь? Сколько памяти жрать? Почему всем на это стало насрать. Память дешевая или что? Только сегодня ночью правки вносил после одного нашего разработчика, который для того, чтобы получить список ФИО из таблицы в 100к записей получал все данные (а это 40 с лишним полей), загонял их в ActiveRecord и уже потом в цикле делал выборку ФИО и потом еще вызывал array_unique для полученного массива. ActiveRecord головного мозга. То, что страница из-за такой выборки открывается 17 секунд (да ну и какое кеширование конечно же, зачем) нас ведь уже не волнует, да? И ведь это уверенный middle. По сути дела, вот именно из несогласия с вашей идеей и для того чтобы уберечь новичков от неправильного выбора, те кто занимаются десктопом профессионально и лепят минуса.
те кто занимаются десктопом профессионально и лепят минусаЧто-то я не понял, вы хотите сказать, что выборки из 100к записей жрут ресурсы только на «неправильных» технологиях? По рукам, простите, бить надо на всех стэках, хоть это js, хоть си.
А вот от чего минусуют, так от того, что в их «уютный профессиональный декстопный мир» лезут «с этими своими браузерами и сайтиками на коленке». Как же так, к нам полез фронтенд, они же только формочки верстать умеют. Известное дело.
Уверенный мидл — это хорошо, но оптимизацией запросов к базе данных тоже надо отдельно заниматься. Некоторые вещи, в которых я не разбираюсь, я просто беру и уточняю у более сведущих людей.
А почему вы думаете, что этот разработчик, имея на руках только SQL написал бы правильную выборку? AR не заставляет разработчиков писать неоптимизированные запросы.
Думаю, эту конкретную статью минусуют за порочность самой идеи — писать десктопные приложения на базе веб-технологий, которые тянут за собой достаточно жирный браузер… Особенно, если учесть, что примеры таких разработок уже есть в широком доступе, и многие видели сами, что в итоге получилось.
Мой минус потому, что статья не выдержала моих ожиданий — рассказанное на уровне первых страниц туториалов. А как сделать действительно сложное десктопное приложение ни сказано было ничего.
Берём Qt+QML получаем то же самое, только быстрее, а так же возможность линковаться с библиотеками, нормальный язык для построения UI а не HTML, более лёгкий и быстрый рендер ну и при желании/необходимости весь Qt.
Плюсую. Если выбор стоит между «Огромный опыт в кроссплатформенности, отличный декларативный QML и Qt в принципе» VS «Тренд и веб-стек технологий на десктоп (что?)», то выбор очевиден.
Возможно, я не знаю чего-то существенного про Qt и QML. Но, если немножечко абстрагироваться от вашей поправки «огромный опыт в кроссплатформенности» — которая мне кажется, скорее, частным случаем, чем неким «общим местом» в современной индустрии разработки ПО, то выбор не так уж и очевиден — в первую очередь, с точки зрения стоимости разработки и доступности человеческих ресурсов.
C++ — отличный язык. Но, кроме того, что порог входа в C++ высокий сам по себе, в случае Qt добавляется необходимость хорошо понимать философию и принципы построения этого фреймворка. Быстро ли вы сможете нанять «с улицы» человека, который действительно является высококлассным спецом в C++ (а этот язык, как мы знаем, ошибок не прощает), и ещё и владеет Qt на должном уровне? И какую зарплату захочет специалист такого уровня? :)
А вот людей, знающих JavaScript и работу с браузерным DOM — на рынке гораздо больше, ибо фронтенд — это «стильно, модно, молодёжно». Осилить азы NodeJS и специфичные для nw.js / Electron API — для фронт-ендера раз плюнуть. «Выстрелить себе в ногу» в JS тоже, конечно, можно, но уже гораздо сложнее, чем в C++. В итоге, имеем гораздо бОльший «фактор автобуса» и более дешёвую стоимость разработки. Profit.
P.S. Да, я прекрасно понимаю, что есть ниши сложных и требовательных десктоп-приложений, в которых даже и думать не стоит о чём-то подобном nw.js или Electron. Поэтому, если вы пишете «убийцу Photoshop» или ПО для нелинейного видеомонтажа — тут, без сомнения, C++ и Qt будут правильным (и, наверное, единственным) выбором. С другой стороны, есть множество ниш гораздо менее требовательных — те же мессенджеры, казуальные игры, агрегаторы новостей — где написать быстро и дешёво, с точки зрения бизнеса, гораздо важнее, чем идеально вылизывать производительность и потребление памяти. И вот здесь подобные технологии «заходят» очень хорошо.
C++ — отличный язык. Но, кроме того, что порог входа в C++ высокий сам по себе, в случае Qt добавляется необходимость хорошо понимать философию и принципы построения этого фреймворка. Быстро ли вы сможете нанять «с улицы» человека, который действительно является высококлассным спецом в C++ (а этот язык, как мы знаем, ошибок не прощает), и ещё и владеет Qt на должном уровне? И какую зарплату захочет специалист такого уровня? :)
А вот людей, знающих JavaScript и работу с браузерным DOM — на рынке гораздо больше, ибо фронтенд — это «стильно, модно, молодёжно». Осилить азы NodeJS и специфичные для nw.js / Electron API — для фронт-ендера раз плюнуть. «Выстрелить себе в ногу» в JS тоже, конечно, можно, но уже гораздо сложнее, чем в C++. В итоге, имеем гораздо бОльший «фактор автобуса» и более дешёвую стоимость разработки. Profit.
P.S. Да, я прекрасно понимаю, что есть ниши сложных и требовательных десктоп-приложений, в которых даже и думать не стоит о чём-то подобном nw.js или Electron. Поэтому, если вы пишете «убийцу Photoshop» или ПО для нелинейного видеомонтажа — тут, без сомнения, C++ и Qt будут правильным (и, наверное, единственным) выбором. С другой стороны, есть множество ниш гораздо менее требовательных — те же мессенджеры, казуальные игры, агрегаторы новостей — где написать быстро и дешёво, с точки зрения бизнеса, гораздо важнее, чем идеально вылизывать производительность и потребление памяти. И вот здесь подобные технологии «заходят» очень хорошо.
А вот людей, знающих JavaScript и работу с браузерным DOM
По факту, на рынке масс факиров, знающих несколько приёмов магии с фреймворками и плохо представляющих, как сильно они шатают DOM.
Пускай C++ ошибок не прощает, но, следя за выделением памяти, на него легко переложить синхронные алгоритмы, которые встречаются в большинстве задач, в отличие от.
хорошо понимать философию и принципы построения
А в случае того же React не надо?
в случае Qt добавляется необходимость хорошо понимать философию и принципы построения этого фреймворка
философию и принципы построения нужно понимать в любом фреймворке. Это ведь касается не только Qt.
Вообще, позиция «знающих html, css, js больше, поэтому давайте писать на этом всем десктоп приложения» мне непонятна. Оставьте вы это все в покое в браузере)
Нет, я понимаю, что QML сам по себе схож на css и js и предыдущее предложение кажется странным. Но, все же, это отдельно разработанный язык не для веба, в котором ты используешь всю мощь кроссплатформенного Qt (обернул функционал в плагин и используй себе в QML). А Qt, погодите-ка на минуточку, развивается не первый год, в отличии от новомодных Electron и nw.js.
Мнение веб разработчика, только мельком коснувшимся разработки на Qt
знающих html, css, js больше, поэтому давайте писать на этом всем десктоп приложенияПозиция не в том, что их больше или меньше, а в том, что затраты на разработку и поддержку на этом стэке меньше.
обернул функционал в плагин и используй себе в QMLПрактически все современные ui-библиотеки и движки в вебе построены вокруг инскапсуляции логики в компоненты и дальнейшем ее переиспользовании. Еще есть web components.
А Qt, погодите-ка на минуточку, развивается не первый год, в отличии от новомодных Electron и nw.js.Electron и nw.js не имеют отношения к ui, это просто контейнеры для браузерного движка со связью с нодой.
затраты на разработку и поддержку на этом стэке меньше.
Почему вы так считаете? Вы часто встречали верстальщиков интерфейсов для десктопных приложений? А в веб-сфере иметь специального человека для этой задачи — норма.
Вы часто встречали верстальщиков интерфейсов для десктопных приложений?Они себя гордо именуют «ui developers». Хотя, если взять какой-нибудь WPF, там та же верстка, только в профиль. Опять же, html/css/js — это не только унылая верстка формочек.
А в веб-сфере иметь специального человека для этой задачи — норма.Для более-менее крупных десктопных проектов — это тоже норма. Только вот стоят они на порядок дороже.
Я, кстати, был удивлен, но позиция верстальщика встречается только в странах СНГ. В Европе\США этим занимаются либо дизайнеры, либо фронтендеры.
А Qt, погодите-ка на минуточку, развивается не первый год
Ровно ту же фразу можно сказать и про nw.js, первый релиз которого был в 2012 году
А если выбор между "огромный опыт в веб технологиях" и "учить что то объективно правильное с нуля", а?
Если у нас есть доярка, а нам нужен тракторист. Зачем нам ее переучивать, может просто вместо рычагов поставим силиконовое вымя?
Просто не нужно веб-фронтов нагружать работой, которую они заведомо выполнять не умеют.
Просто не нужно веб-фронтов нагружать работой, которую они заведомо выполнять не умеют.
Тут скорее другая аналогия: если у вас есть тракторист и трактор и вам нужно доехать в соседнее село, нужно ли нанимать отдельно водителя автомобиля и покупать авто?
нужно доехать в соседнее село
Да, действительно, эта аналогия лучше. Согласен, что если нужно быстро на коленке что-то склепать с имеющимися кадрами — это идеальный вариант. Но если нам нужно регулярно «мотаться в соседнее село», то лучше таки «купить авто», в долгосрочной перспективе это оправдано.
То-то полно бэкендщиков с подходом «да че там, щас на жквери нафигачу скриптину, и збс» или «я же бог пхп эксперт, зачем мне фреймворки», и, как следствие, полно продуктов соответствующего качества, сидишь потом и разгребаешь. Им же не скажешь, мол, «не лезь к работе, которую заведомо выполнять не умеешь».
Ситуация зеркальная, и разрешить ее невозможно, так как невозможно заставить всех заниматься своим делом и не лезть. Так что единственным выходом является адаптация технологий и сглаживание граней.
Ситуация зеркальная, и разрешить ее невозможно, так как невозможно заставить всех заниматься своим делом и не лезть. Так что единственным выходом является адаптация технологий и сглаживание граней.
Беда в том, что современный веб — это месиво технологий. Нигде больше такого нет.
Одно же дело бэкенд, который связан с веб и человек просто выполняет работу другого на том же стеке, совсем другое дело — десктоп, куда пытаются притянуть чужеродные, лишние абстракции в систему лишь для удобства программиста. Страдания десктопщиков здесь посвящены тому, что UI на десктопе сейчас намного проще делается, чем в вебе (на что я намекал меньшим количеством должностей), что решение притащить веб-стек выглядит вообще антилогичным.
Им же не скажешь, мол, «не лезь к работе, которую заведомо выполнять не умеешь».
Одно же дело бэкенд, который связан с веб и человек просто выполняет работу другого на том же стеке, совсем другое дело — десктоп, куда пытаются притянуть чужеродные, лишние абстракции в систему лишь для удобства программиста. Страдания десктопщиков здесь посвящены тому, что UI на десктопе сейчас намного проще делается, чем в вебе (на что я намекал меньшим количеством должностей), что решение притащить веб-стек выглядит вообще антилогичным.
В идеале надо просто реализовать QML-верстку на веб технологиях, и нэйтив код на JS.
Тогда 100% кроссплатформа была бы.
Тогда 100% кроссплатформа была бы.
UFO just landed and posted this here
Во-во, и в создание веб-сайтов пусть не лезут.
Думаю тут виноваты не фронты, а манагеры которые прочитав статьи подобной этой задумываются а зачем нанимать десков, тратить время и деньги на разработку с нуля когда уже есть 80% функционала на сайте и его нужно просто адаптировать.
При разработке небольшого приложения для специфичной области с небольшим кругом пользователей, данный подход намного целесообразней чем супер оптимизированная разработка под деск за $$$$$$$ денег.
При разработке небольшого приложения для специфичной области с небольшим кругом пользователей, данный подход намного целесообразней чем супер оптимизированная разработка под деск за $$$$$$$ денег.
Как сделать кроссплатформенное десктопное приложение на базе веб-технологий? Да очень просто: не надо делать десктопные приложения на этой базе; для этого есть куда более подходящие средства.
(Эти ваши технологии собственно сам веб уже превратили черт знает во что, не трогайте хотя бы десктоп.)
(Эти ваши технологии собственно сам веб уже превратили черт знает во что, не трогайте хотя бы десктоп.)
Когда Хромиум можно будет в линуксе выносить в зависимость пакета?
А давайте теперь внедрим скрипты на С++ или там C# прямо в браузер? Прикольно ж будет.
Есть ИМ, backend и frontend написаны раздельно, работают через API. Срочно нужна программа для склада, работающая через это API. Пишется за 4 дня на электроне, все довольны. Итого: поставлена задача — быстро решена — все довольны. Что в этом плохого? И сколько бы это писалось с помощью других инструментов?
работают через API
И сколько бы это писалось с помощью других инструментов?
Стесняюсь спросить… Вы Delphi видели? И родственников? Есть такой термин — rapid application development, и вот представленные web-технологии до си пор находятся на противоположном полюсе (хотоя связанные .NET, java/clojure почти Ok).
Хотя сам я для подобного использую кросс-платформенный wxPython, к которому быстро накидываю формы-интерфейсы в BoaConstructor (а чтоб был отзывчивым — использую threads)
Delphi и ему подобные это конечно хорошо, но с точки зрения технического руководителя — у вас есть 2-3 веб разработчика и не слишком высокие требование по продукту (не игра, не видео редактор, просто оболочка). Вы бы пошли нанимать разработчика на делфи\etc или бы взяли электрон?
Ну вот для Python есть куча библиотек wxPython, PyQt, Kivy, etc… Можно выбрать на любой вкус и потребности при этом скорость разработки на них будет не особо ниже
и не слишком высокие требование по продукту… просто оболочка
Такое впечатление, что вы таки Delphi не видели. Это был хит среди не умеющих программировать школьников. Т.е. даже веб-разработчику IMHO простооболочку быстрее сделать на незнакомом Delphi, а не из г… и палочек, найденных в npm.
Да, вы правы, я давно не видел делфи, года с 2008го наверное. Тогда было не просто клиент-серверую архитектуру там запилить, не знаю как сейчас ситуация. Кстати, вы в курсе что делфи стоит от 2К евро на юзера? В самой простой комплектации и 4.8К в чуть более продвинутой? + это все еще другой язык, не жс, если что-то пойдет не так, или надо будет развивать продукт — разработка начнет происходить значительно медленее, нужно будет искать специально обученных людей, или выращивать их. На мой взгляд это неоправданный риск.
это все еще другой языкПри чем не самый удобный. А удобство разработчика превыше всего :)
Кстати, вы в курсе что делфи стоит от 2К евро на юзера? В самой простой комплектации и 4.8К в чуть более продвинутой?
Бред какой. Откуда вы это всё берёте? Хоть бы немного темой поинтересоваться. Делфи никогда от двух килоевро не стоил. Мы Professional покупали чуть дороже тысячи долларов. Лазарь вообще бесплатный. И для всякой мелочи типа склада его должно хватать за глаза. Под кучу платформ сразу.
Тогда было не просто клиент-серверую архитектуру там запилить
Клиент-серверную как раз там запилить можно играючись.
Кстати, вы в курсе что делфи стоит от 2К евро на юзера?
От $1200 на юзера, если быть точнее. В принципе, для коммерческой разработки ерунда. Для некоммерческой явно не тот инструмент.
Из своего опыта могу сказать, что в сфере клиент-серверных и многозвённых бизнес-приложений с толстыми клиентами у старичка Delphi, несмотря на все древние косяки, несмотря на многословный паскалевый язык, по продуктивности разработки конкурентов до сих пор нет. Просто потому, что все эти гриды и формы, которые на других платформах надо долго и мучительно верстать, обвешивать UI-логикой, в Delphi есть практически «из коробки» (ну, точнее, скачиваются и/или докупаются за понятные деньги), а практически любые пожелания клиентов в плане визуализации данных решаются в пару кликов.
Но за пределами этой ниши Delphi, конечно же, отстаёт от других платформ.
по продуктивности разработки
Тссс!!! Этого не может быть, так как web-стек фронтенда это ТАК просто!
Возможно я что-то путаю, но на сайте производителя Делфи стоит вот такая цена:
New User
Total: €1,955.36
New User
Total: €1,955.36
Это всё хорошо, но! Какой бы ни был хороший язык delphi — его нужно сначала выучить/ознакомиться, чтобы не написать костыль, об который потом будут спотыкаться все. Это — излишние траты времени. Если не учить — то искать специалиста, который это реализует. Лишние затраты как средств, так и времени, опять же. А так — в штате имеются специалисты, которые это все подняли своими силами, и, при необходимости, будут поддерживать и дальше. В целом — задача решена, бизнес идет, деньги капают. Если будет расширение и нужны новые возможности — можно смотреть уже и на delphi, и на qt, и на другие инструменты. Но сходу кидаться в крайности — это перебор.
Общеизвестно, что порог вхождения Делфи низкий. Делфи обычно 'учится' за месяц.
Страшно представить, что получается на выходе после «учится за месяц».
Ничего особо страшного не получается. По крайней мере, если человек в принципе до этого имел опыт работы программистом на какой-либо другой платформе.
Пересадить человека с JS писать на дэлфи… Это жестоко
если человек в принципе до этого имел опыт работы программистом на какой-либо другой платформе
Очень важное условие. По своему опыту наблюдений могу сказать, что опытные программисты с других платформ берутся за Delphi крайне неохотно, а если кого и можно привлечь, то как раз любителей-энтузиастов, что заканчивается написанием бизнес-логики прямо в коллбеках кнопок.
А есть какие-то НЕ open source, т.е. обычные коммерческие приложения в качестве примера?
если вы про standalone web based — то большинство 'запускаторов' игр mmrpg или просто не самых крупных дестрибьюторов (2-10 игр) делают свое приложение для загрузки и запуска игр на основе браузера chromium
Spotify, выше говорят про Steam
Как я понимаю, это все онлайн. Или даже web-приложения? Т.е. ничего, что требуется защищать там нет, все на сервере?
Что вы понимаете под защитой? Если нужно защищать проприетарный код, то да, жс, возможно, не лучшее для этого решение. Но даже в этой ситуации можно вынести критичные части приложения в отдельные бинарные модули, нода поддерживает их поддерживает. В целом же, бизнесы идут больше к сервисному подходу, чем к программной дистрибуции (к примеру Adobe, JetBrains). Так что софт без сервиса будет бесполезен
Если говорить о нескольких приложениях что я видел, это standalone приложения (логика реализована локально) с загрузкой элементов интерфейса (статика) с онлайн, таким образом решается проблема гибкого изменения внешнего вида приложения без его обновления.
Ни о какой защите речи не идет, если я верно понимаю, логика разработчиков таких 'монстров' проста, интерфейс должен быть продолжением дизайна вебсайта, и на разработчике можно будет сэкономить…
Правда потом оказывается что локальная логика десктопного приложения не простая, банальное обновление игры при условии наличии защит от модификаций в них (например шифрование файлов ресурсов) превращается в кошмар (покрайней мере я видел ситуацию когда патчили и перешифровавали файлы).
Все молодые 'запускаторы' (это имя ввела иннова — aion, мне кажется подходит идеально для всех таких приложений) так или иначе глючили на обновлениях так что приходилось делать полное удаление и новую загрузку всей игры, отлично показывает какие программисты брались за логику.
Ни о какой защите речи не идет, если я верно понимаю, логика разработчиков таких 'монстров' проста, интерфейс должен быть продолжением дизайна вебсайта, и на разработчике можно будет сэкономить…
Правда потом оказывается что локальная логика десктопного приложения не простая, банальное обновление игры при условии наличии защит от модификаций в них (например шифрование файлов ресурсов) превращается в кошмар (покрайней мере я видел ситуацию когда патчили и перешифровавали файлы).
Все молодые 'запускаторы' (это имя ввела иннова — aion, мне кажется подходит идеально для всех таких приложений) так или иначе глючили на обновлениях так что приходилось делать полное удаление и новую загрузку всей игры, отлично показывает какие программисты брались за логику.
кроме электрона, где чистый веб, можно так же посмотреть на react-native for desktop для macOS и для windows а с повсеместной имплементацией WASM можно будет писать на js и ресурсоемкие приложения типа обработки фото и видео. Ниша нативной интерфейсной разработки будет сокращаться, не везде бизнесу нужны супербыстрые сложные интерфейсы.
Так как перед нами расшифровка одного из выступлений на конференции FrontendConf, и так как конференция эта проводится летом в начале июня (по крайней мере, так пишут на сайте про нынешний год), то изложенные в выступлении свéдения нуждаются в некотором осовременивании (может быть, на полгода, а может быть, и на полтора года; что-то я нигде не увидел даты этого выступления, честно говоря) для того, чтобы соответствовать положению дел января 2017 года.
Движок NW.js больше не использует движок io.js в качестве средства для поддержки Node API; после того, как io.js влился обратно в Node.js, последующие версии NW.js также возвратились на Node.js.Так, например, стабильная версия NW.js v0.19.5 использует Node.js v7.4.0, и вышедшая сегодня (19 января) предрелизная версия NW.js v0.20.0-rc1 также использует Node.js v7.4.0.
Движок NW.js больше не использует простой нодовский вызов«require(…)», который в браузероподобном контексте создавал пусть и преодолимые, но всё же досадные проблемы совместимости с RequireJS. Теперь используется вызов «nw.require(…)», вынесенный в отдельное пространство имён «nw».
В то же пространство имён вынесены те элементы API NW.js, которые ранее были доступны через вызов«require('nw.gui')»; таким образом, например, вместо «require('nw.gui').Window» теперь пишется попросту «nw.Window», а вместо «require('nw.gui').Shell» теперь пишется попросту «nw.Shell», и так далее.
(В качестве примера изменений, к которым это приводит, можно посмотреть вон те правки, внесённые 26 октября 2015 года в один из моих проектов на Гитхабе.)
Внутрь package.json теперь нет необходимости вписывать«"toolbar": false» для отключения навигационной панели, потому что теперь её нет. Соответственно, нет и шестерёнки на ней, а отладка вызывается по F12, как в Chrome. (Вызывается в SDK-содержащей версии движка NW.js. Сборка приложений для конечных пользователей, как правило, делается без средств отладки.)
Степень того единства контекста Node и контекста окна, о пользе и вреде которого чуть выше рассуждали читатели, теперь можно изменять по мере необходимости (кому нужно, тот использует смешанный контекст).
В остальном вышеизложенное выступление вполне справедливо. Веботехнологическая и притом кросс-платформенная разработка — это залог довольно быстрого создания сайтоподобныхGUI-приложений. Как показывал AndyGrom, такие приложения могут иметь и вебсерверную часть на основе Express.js.
Движок NW.js больше не использует движок io.js в качестве средства для поддержки Node API; после того, как io.js влился обратно в Node.js, последующие версии NW.js также возвратились на Node.js.
Движок NW.js больше не использует простой нодовский вызов
В то же пространство имён вынесены те элементы API NW.js, которые ранее были доступны через вызов
(В качестве примера изменений, к которым это приводит, можно посмотреть вон те правки, внесённые 26 октября 2015 года в один из моих проектов на Гитхабе.)
Внутрь package.json теперь нет необходимости вписывать
Степень того единства контекста Node и контекста окна, о пользе и вреде которого чуть выше рассуждали читатели, теперь можно изменять по мере необходимости (кому нужно, тот использует смешанный контекст).
В остальном вышеизложенное выступление вполне справедливо. Веботехнологическая и притом кросс-платформенная разработка — это залог довольно быстрого создания сайтоподобных
Забавно, столько презрения к несчастным фронтэндерам и веб-технологиям на десктопе… а вот я сейчас пишу код в VS Code и все его близкие альтернативы (Brackets, Atom) — ему подобны (внутри браузер). Все похожие нативно-дескотопные редакторы если и были, то как-то давно загнили и не удовлетворяют современным требованиям. К чему бы это? Может дело в размере и мотивированности сообществ? Где все эти супер-пупер нативно-десктопные разработчики, которые тут самодовольно доминируют в комментариях над убогими "веб-макаками"? Где их нативные супер-пупер продукты?
Да, я знаю о том, что задачи решаются лучше теми инструментами, которые для их решения подходят (это основа инженерного подхода), но веб-стек имеет пару существенных отличий и плюсов: он наиболее универсален и близок к САМОЙ эффективной, на текущий момент, среде дистрибуции — вебу. Это и перевешивает чашу весов.
Все похожие нативно-дескотопные редакторы если и были, то как-то давно загнили и не удовлетворяют современным требованиям.
Эм...SublimeText?
но веб-стек имеет пару существенных отличий и плюсов
… которые перестают что-либо значить в десктопном варианте.
SublimeText
В первую очередь. Когда-то он был крут, да. Давно это было.
перестают что-либо значить
Факты нам говорят об обратном. Я привел примеры.
Когда-то он был крут, да. Давно это было.
Окститесь, многие
Объективно при прочих равных нативные редакторы работают быстрее и ресурсов расходуют меньше, чем веб-комбайны, это очевидно.
SublimeText 3 у меня на машине стартует меньше, чем за секунду, а VS Code — около трёх. Одиночные файлики из-за таких тормозов редактировать некомфортно, а с проектами удобнее работать с полноценной VIsual Studio. Так и висит он у меня установленный, но не юзанный почти.
Факты нам говорят об обратном. Я привел примеры.
Вы говорите, что привели пару плюсов, хотя он был один — дистрибьюция веб-приложений. Так мы уже говорим не о веб-приложениях, потому и он не в кассу. Поправьте, если я что-то упустил.
В сухом остатке: сомнительный javascript, который не отличается ни удобством разработки (как язык), ни производительностью (как платформа) и таскаем за собой браузер.
P.S. Коненчо, стоит принять во внимание, что для создания простых приложений, на которых можно легко переучить фронтов — это идеальное решение. Но, полагаю, в сфере десктопного ПО эта сфера достаточно узкая. Ибо зачем оно нужно, если есть тот же самый веб?..
Мне абсолютно не важно то, что Саблайм стартует быстрее VS Code, по одной простой и банальной причине: он просто не делает того, что мне нужно. А VS Code — делает. И я не стану утверждать, что в VS Code нет недостатков, но он является моим основным инструментом и нахожу его приемлемым, в отличие от. Только не нужно мне рассказывать о том, что Саблайм можно настроить как угодно, я им сам пользовался ранее. И много чем еще. Про производительность JS — не смешите мои тапки, она вполне на уровне, как и удобство, при современном подходе, когда знаешь как его "готовить". Хейтспич можно легко про любую платформу выдать, а уж про Java c Qt — и подавно. Но в сухом остатке мы имеем довольно простой принцип: взвешиваем все "за" и "против", и выбираем стек исходя из конкретных предпосылок. Для меня их вполне достаточно для выбора веб-стека во многих случаях.
Мне абсолютно не важно то, что Саблайм стартует быстрее VS Code
Про производительность JS — не смешите мои тапки, она вполне на уровне
"Купи себе стеклянные глаза
И делай вид, как негодяй-политик,
Что видишь то, чего не видишь ты." (с)
Хейтспич можно легко про любую платформу выдать, а уж про Java c Qt
Не нужно абсолютных лозунгов. Очевидно, что никаких плюсов, кроме дешевой раб.силы это веяние не несет. Никаких технически обоснованных аргументов я от вас не добился.
P.S.
Ибо зачем оно нужно
Доступ к FS? Как самый банальнейший вариант.
UFO just landed and posted this here
Как то странно и смешно видеть комменты аля «не лезьте со своим убогим стеком веба к нам десктопщикам». От таких вскукареков ощущение, что вы(тут стоит обратить внимание, что «вы» — это не вся прослойка десктопостроителей, а лишь «избранные» ее жители) и кодите — распальцовкой тыкая по клавишам. К вам никто не лезет, никто вам ничего не навязывает, зачем тут сидеть и разводить дебаты? Есть спрос — появилось и предложение: адаптировать веб технологии под десктопную версию с минимальными трудо- и времязатратами. Нормальный десктопщик по моему сидит сейчас и ухмыляется, глядя на подобные «тренды», понимая, что от его услуг еще нескоро откажутся. А полуджуны-полумиддлы уже забили тревогу и упорно кидаются вилами в паровоз.
Берем Delphi, получаем всё то же самое, с единым кодом, удобной отладкой, удобной средой быстрой разработки, без особых танцев с бубном, списанных технологий (flash). Хотите Opengl, хотите куду, хотите буфер обмена, хотите еще гору железа — что угодно и сразу. Независимое от кучи особенностей браузеров.
Опять же — если так свербит именно веб, то хотя бы так:
http://www.unigui.com/
думаю, лучше, чем так:
http://www.unigui.com/
думаю, лучше, чем так:
Sign up to leave a comment.
Как сделать кроссплатформенное десктопное приложение на базе веб-технологий