LINUX.ORG.RU
ФорумTalks

Фреймворк/Тулкит для старта нового приложения

 , , ,


1

8

Здраствуй дорогой колектив.
Назрела давеча необходимость начать новый проект, который, к тому же, должен обладать адекватным интерфейсом так как софт сам по себе имеет графический пользовательский интерфейс.
В былые времена, вопрос особо не стоял:
* Если GNU/Linux онли - то С/C++/Go/Perl/Python + GTK
* Если кроссплатформенность - то C/C++/QML + Qt

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

Cобственно вопрос - что выбрать?

★★★★★

Последнее исправление: Jetty (всего исправлений: 1)
Ответ на: комментарий от Reset

в 99.99% случаев браузер это единственное приложение

Притянуто за уши.

современное железо как-то позволяет бороться с «тормозами» этого «говна»

Современное — в том числе слабое современное. Ну и Web давно упёрся в CPU, которые развиваются крайне медленно, даже топовые; лису вон потихоньку пытаюся переводить на GPU, но всё вынести не получится, разумеется, JS — так и вовсе. Ждём, когда WebAssembly на видеокартах запускать можно будет, вот тогда толк какой-то будет.

mertvoprog
()
Ответ на: комментарий от Nervous

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

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

byko3y ★★★★
()
Ответ на: комментарий от mertvoprog

В 2$21-м из нетормозных непрожорливых браузерных движков разве что Ultralight и Sciter остались. Но уж лучше с платным Qt связываться, чем с этой дрянью. Под что веб писать-то?

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

Подождём лучше, пока React Native или Flutter для десктопа допилят

А ты не хочешь для начала подождать, пока это для мобилок допилят?

Ибо даже Qt на мобилках поныне так себе

К сожалению, Qt вынуждены тянуть совместимость. И у них тупо мало ресурсов: достаточно, например, чтобы сделать IDE, но недостаточно для того, чтобы она хорошо работала и выглядела, пусть даже она и лучше васяноподелок.

byko3y ★★★★
()
Ответ на: комментарий от mertvoprog

Ждём, когда WebAssembly на видеокартах запускать можно будет, вот тогда толк какой-то будет

Это вообще не та задача для запуска на видеокартах. WAsm так-то уже сейчас может дергать WebGL, но и браузер это может. А вот перестать тормозить и жрать ресурсы не может.

byko3y ★★★★
()
Ответ на: комментарий от Lordwind

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

Ты опять не закусывал?

SSE уже много лет есть

Да и websockets уже давно актуален.

grim ★★☆☆
()
Ответ на: комментарий от byko3y

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

Мы, по крайней мере, пытались.

Nervous ★★★★★
()
Ответ на: комментарий от Jetty

Вооооот и тут вопрос… 5.15 или 6.0 ?

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

wolph ★★
()

Если хватит фич, то wx. Если не хватит, то electron.

Shadow ★★★★★
()
Ответ на: комментарий от redvicka

а все остальное в сервис воркерах

Много лет сообщество тр...сь, запиливало разного рода треды, потом училось их правильно готовить, и тут х..к, пришёл веб и теперь форка хватит всем!

Shadow ★★★★★
()
Ответ на: комментарий от byko3y

Я б добавил, что если под десктоп не использовать веб, а нормальные тулкиты, то и вёрска поактически не нужна.

Shadow ★★★★★
()
Ответ на: комментарий от byko3y

Проблема не в реализации, а в стандартах веба

И то верно, веб чересчур стандартизирован, во времена расцвета IE такого не было!

и потреблению памяти

Будто жрут её жепьскрипты в основном.

совсем уж чистый лист

Да это ещё с ES6 началось, не умеющие его браузеры тупо выплёвывают Syntax error. Такой наглости давно не было, предыдущей вехой, пожалуй, был лишь ассуминг выполнения JS в принципе. Хотя где-то ещё между этим был ассуминг наличия плагинов, благополучно скончавшийся…

А ты не хочешь для начала подождать, пока это для мобилок допилят?

А что там ждать? Уж React Native как минимум в продакшне используется вовсю, не один год.

Qt вынуждены тянуть совместимость

Что-то по запихиванию QML/JS не особо заметно. Ну старый, конечно, параллельно есть, но развитию это не мешает же.

mertvoprog
()
Ответ на: комментарий от Shadow

Ну кагбэ DOM тоже можно генерировать программно. Олды вообще срали document.write’м голый HTML прямо по ходу загрузки и выполнения страницы ;) Но зачем?

mertvoprog
()
Ответ на: комментарий от mertvoprog

Ты о чём? Я про то, что проблемы расположения элементов красиво и удобно решены давным-давно, и только в веб нужно обновить браузер для новых фич css (на минуточку, стайл - это не про координаты! Но это веб...)

Shadow ★★★★★
()

потыкай tk, может тебе сойдёт

InterVi ★★★★★
()
Ответ на: комментарий от mertvoprog

И то верно, веб чересчур стандартизирован, во времена расцвета IE такого не было

Знаешь, так бывает, что вещь стандартизуется, но полученный стандарт получается бесполезным мусором. Это было много раз. MS шел в правильном направлении, но слишком ударился в монополизацию своего положения. Flash много лет был лучшим решением для динамичного веба, и он бы мог таким до сих пор оставаться, если бы не Эффективные Менеджеры™, которые решили, что хорошей идеей будет сократить расходы по разработке клиента до абсолютного минимума. В итоге, как ни странно, «Flash» в виде WAsm+WebGL является будущим, а никак не переусложненный HTML5.

Будто жрут её жепьскрипты в основном

JS+CSS+DOM.

А что там ждать? Уж React Native как минимум в продакшне используется вовсю, не один год

Его ломают постоянно — он нестабилен. Напишешь под 0.56, будет потом переписывать под 0.64. Используют React Native просто потому, что серьезных альтернатив тупо нет, а не потому, что он так хорош.

Что-то по запихиванию QML/JS не особо заметно. Ну старый, конечно, параллельно есть, но развитию это не мешает же

Ну вот они и попытались сделать что-то с нуля. Я бы не сказал, что оно взлетело. Но примерно по той же причине, по которой GTK до сих пор жив и Qt не занял целиком всю нишу опенсорсного GUI — потому что тролли хотят денек.

byko3y ★★★★
()
Ответ на: комментарий от Lordwind

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

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

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

Ну ты же не почитал даже про Worker-ы. Вот ещё. Когда вкладка загрузилась, поток может и всего один, да. Но после загрузки каждая вкладка, из основного потока JS, может спавнить ещё потоки (воркеры) и запускать в них какой-либо фоновый процесс. WASM вроде как ещё и позволяет шарить память между воркерами, вместо использования каналов с сообщениями. Так что это уже «настоящая» многопоточность и криптомайнеры с одной страницы теперь могут насиловать все твои ядра, а не только одно.

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

Не совсем понял, к чему это.

Ты говоришь, что приложение бесполезно, когда время использования < время пердолинга. Но это не так. Это скорее про «некачественное» приложение. А бесполезное - это когда время пердолинга + время использования < время на осуществление той же цели без приложения - т.е. когда приложение понижает твою эффективность.

anonymous-angler ★☆
()

Если кроссплатформенность принципиальна - Qt пока ещё лучший в этом деле. На GTK в Windows например, тебя будет ждать очень много боли… Пусть оно и теоретически возможно.

Я уже растекался мыслью по древу по этому поводу.

P.S. А веб ты зря вот так на корню обрываешь. Учитывая, как WASM набирает обороты, если твоё приложение не будет требовать расширенный доступ к клиентской системе, то почему бы не изучить что-то новое? К тому же, таким образом можно добится «истинной кроссплатформенности». В любом хромиуме твоя программа откроется.

FixingGunsInAir
()
Последнее исправление: FixingGunsInAir (всего исправлений: 2)
Ответ на: комментарий от anonymous-angler

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

Переформулирую то же, что вы пишете, но более явно: JS/браузеры решают одни проблемы, но создают новые, при этом не решая проблемы кривых рук. В конечном итоге все равно придется писать какие-то родные для платформы фичи, и чем более родным должно быть приложение, тем меньше оно будет похоже на вебсайт. Даже сам фейсбук имеет две версии клиента: веб и React Native. Я вот решительно не представляю, как лох пользователь разрабатываемого мной последний год приложения-вебсайта будет пользоваться им на игрофоне, если сайт даже на десктопе заметно подтормаживает. Facebook чисто теоретически мог бы разработать эффективный чисто веб клиент, но для этого нужно было бы уволить половину штата сотрудников и нанять компетентных людей вместо них. Руководство фейсбука почесало репу, и прагматично решило, что намного дешевле, быстрее, и гарантированее будет накидать простенький интерфейс родных компонентов к тому же JS, вместо безмерно переусложненного HTML5.

byko3y ★★★★
()
Ответ на: комментарий от grim

Раз не можешь развернуто возразить, то читай комменты выше

SSE уже много лет есть

Да, он давно появился на свет. А в вебе как давно? Теперь ждем CUDA.

Lordwind ★★★★★
()
Ответ на: комментарий от anonymous-angler

Сам JS то наверно не течёт

Насколько я помню, именно в JS очень неэффективная разбивка страниц памяти, приводящая практически к дублированию объема за счет указателей на x86_64. И сборка мусора худшая из всех виденных мной, даже JVM работает идеально по сравнению с любым браузером. А началось все с хрома, который в угоду скорости начал раздувать потребление памяти. Правда говнокод это не спасло, а вот оптимизации похоронило.

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

А в вебе как давно?

в WASM нет никакого SIMD, так что ещё не появился.

Есть лишь предложение хз когда оно будет рассмотрено: https://github.com/WebAssembly/simd

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)

Фреймворк/Тулкит для старта нового приложения

fork exec /thread

filosofia
()
Последнее исправление: filosofia (всего исправлений: 1)
Ответ на: комментарий от Lordwind

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

Когда я последний раз проверял JVM vs Node, потребление памяти у них было примерно одинаковое на той же задаче. Что удивительно, если учесть, что JS — интерпретируемый язык. Lua и JS могут крайне эффективно использовать память, и раздувание потребления ради скорости в них значит только «доганть жаву», но не более того.

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

byko3y ★★★★
()
Ответ на: комментарий от fsb4000

в WASM нет никакого SIMD, так что ещё не появился

Вообще-то речь шла про Server-sent events.

Есть лишь предложение хз когда оно будет рассмотрено: https://github.com/WebAssembly/simd

Эталонное непортируемое Ненужно. SIMD в его классическом интелевом варианте — это ASIC-подобный рак, под который нужно переписывать приложения, и в том числе компиляторы.

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от Shadow

Я б добавил, что если под десктоп не использовать веб, а нормальные тулкиты, то и вёрска поактически не нужна.

Скажите ещё, что и верстальщики не нужны. Wait... Oh shi~ И куда прикажете столько фронтенд-инженегров устраивать? На велфер? Метлу им никто не доверит.

bread
()
Ответ на: комментарий от bread

Скажите ещё, что и верстальщики не нужны. Wait... Oh shi~ И куда прикажете столько фронтенд-инженегров устраивать? На велфер? Метлу им никто не доверит

Люди во фронтенд с завода прихоядт и обратно на завод уходят. Яндекс, вон, курьеров учит писать сайты.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Я вот тут Альтернативные Java VM предложил обсудить опыт OpenJ9 - знающие люди подсказали, что мне не показалось, и на десктопе, и на облаке JAVA может отлично работать с в разы меньшим потреблением памяти.

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от Reset

современное железо как-то позволяет бороться с «тормозами» этого «говна»

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

Lordwind ★★★★★
()
Ответ на: комментарий от Nervous

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

И темы пользователей накрываются медным тазом.

Psilocybe ★★★★
()
Ответ на: комментарий от Nervous

И темы пользователей накрываются медным тазом.

Проблема решаемая, в общем-то

Решаемая реализацией заново алгоритмов рисования родных контролов, но в неродной среде. Что в итоге нас приводит к вопросу «не проще ли было делать всё на родных контролах, а логику сделать общую, например, на C++?». В веб-приложениях не выёживаются и просто создают свой уникальный интерфейс. Посмотри на Office 365 — он намного меньше похож на MS Office, чем Google Docs. Зато трудоемкость реализации на порядок ниже и тормозит меньше. В MS работают боги жавоскрипта, учись у них. Я так-то как первый раз запустил VS Code — сразу понял, что такое настоящее веб-приложение, а не эти ваши тормознутые атомы, гуглдоки, или, боже упаси, фейсбук с ютьюбом.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Решаемая реализацией заново алгоритмов рисования родных контролов, но в неродной среде.

Я так понимаю, нужен некий механизм чтения браузером (сферической в вакууме) системной темы и преобразования ее в вебоугодную форму (CSS). Тогда веб-приложения теоретически смогут использовать системную тему.

В MS работают боги жавоскрипта, учись у них. Я так-то как первый раз запустил VS Code — сразу понял, что такое настоящее веб-приложение

Не спорю, VSCode охренителен. Но системные темы вроде еще не поддерживает.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от Nervous

Не спорю, VSCode охренителен. Но системные темы вроде еще не поддерживает

Вот именно. И не будет.

byko3y ★★★★
()
Ответ на: комментарий от Lordwind

Я хз, попробовал 11-й OpenJ9, мне понравилось.
До этого стандартным 8-м Oracle OpenJDK пользовался.

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от Lordwind

SSE

Это Sever Side Events.

Они в вэбе уже много лет.

grim ★★☆☆
()
Ответ на: комментарий от Shadow

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

Они ещё до этого решены CSS-фреймворками.

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

mertvoprog
()
Ответ на: комментарий от byko3y

MS шел в правильном направлении, но слишком ударился в монополизацию своего положения

Ничто не мешало сделать свободные аналоги технологий от M$. Собственно, частично так и сделали (см. XHR и favicon). Opera чуть дальше продвинулась. Но потом конкуренты упёрлись рогом, объединились, запилили WHATWG и начали пилить велосипедные стандарты для того, что в осле уже лет 10 как было и отлично работало, лишь бы не как в осле. И обставили всё так, будто это IE злой монополист и ретроградство, хотя на мобилках, например, он никогда не доминировал: WM был для мажоров, а WP вообще не взлетел вместе с ослом.

«Flash» в виде WAsm+WebGL является будущим

Только будущее это нафиг никому не нужно ввиду наличия тонны легаси-кода на JS+DOM, ага. По той же причине альтернативы похапэ-CMS на более приличных языках продвигаются крайне вяло.

JS+CSS+DOM

Забыли жирные картинки и видосики (особенно самопроигрывающийся FullHD на фоне страницы, и всплывающие в уголке новости, убиват за такое); забыли web-шрифты; забыли кэш в оперативке; забыли издержки на изоляцию и многопроцессность. На фоне всего этого издержки на те части веба, которые за 20 лет особо не поменялись — пшик; они скорее даже меньше жрать стали, ибо байтодрочеры, разрабатывающие браузерные движки, эти места вылизали до предела. А вот с жирным контентом ничего не поделать, надо скачать, отрендерить и показать, куда оно денется-то?

Его ломают постоянно

А кого не ломают-то из нативной кроссплатформы?

что серьезных альтернатив тупо нет, а не потому, что он так хорош

Bдеалист? ;) Мобильная разработка изначально трешем была, зажрались Вы.

тролли хотят денек

Будем надеяться, что их кто-то купит. Тот случай, когда поглощение мелких корпораций во благо.

mertvoprog
()
Ответ на: комментарий от byko3y

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

А куда он денется?

mertvoprog
()
Ответ на: комментарий от Nervous

Но системные темы вроде еще не поддерживает

А что, есть намёки, что будет?

Опять Нашу идею раньше Нас реализуют и напрягаться не придётся? ;)

mertvoprog
()
Ответ на: комментарий от mertvoprog

А что, есть намёки, что будет?

Я пока ни о чем таком не слышал. Так что пилите, Шура, пилите %)

Nervous ★★★★★
()
Ответ на: комментарий от mertvoprog

Они ещё до этого решены CSS-фреймворками

Фреймворки могут ровно то, что им разрешит браузер. А те же IE 10/11 имеют люто глючную поддержку flexbox-ов, так что под них придется отдельно дорабатывать верстку, с фреймворками или без. А зачем всё это, если с 2014 года все браузеры поголовно имеют хорошую поддержку flexbox? В том числе версии хрома и лисы для XP.

byko3y ★★★★
()
Ответ на: комментарий от mertvoprog

Только будущее это нафиг никому не нужно ввиду наличия тонны легаси-кода на JS+DOM, ага. По той же причине альтернативы похапэ-CMS на более приличных языках продвигаются крайне вяло

IT вообще является инертной индустрией, которая медленно впитывает нововедения — ты так пишешь, будто где-то там это не так, и только здесь остались ретрограды.

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

Например, снимок JIT-оптимизаций hello world на электроне весит 30 Мб. Примерно это и останавливает от тотальной оптимизации вообще всего JS — помимо времени проца будет жраться оператива на бесконечные варианты инлайна с разными типами. Потому движки JS стали работать быстрее, но и памяти жрут они больше.

А кого не ломают-то из нативной кроссплатформы?

Qt.

Мобильная разработка изначально трешем была, зажрались Вы

Сорян, у меня так-то последжний игрофон был 12 лет назад, и был он на Maemo с GNOME/GTK, и были на нем Doom, Duke Nukem, Quake, Battle for Wesnoth — сейчас вот лежит на полке и мне остается только восхищаться, как он был хорош по сравнению с современным неюзабельным массовым калом для детей дошкольного возраста с играми уровня «tap to win» или «pay to win». Как на этой параше можно делать серьезные приложения для взрослых прокрастинаторов — в упор не понимаю. Даеж Facebook не понимает, потому сделал отдельный фреймворк специально для игрофонов.

Будем надеяться, что их кто-то купит. Тот случай, когда поглощение мелких корпораций во благо

Так два раза уже. А чо толку? Эффективные менджеры™ из Digia ведут Qt к верной смерти, перед которой они постараются подоить тридцатилетнее наследие.

byko3y ★★★★
()
Ответ на: комментарий от mertvoprog

Параллелить всё, что параллелится. Закон Амдала, конечно, неумолим, но просторы для роста есть

Что из «всего» ты собрался параллелить? По крайней мере из того, что еще на запараллелено в хроме.

byko3y ★★★★
()
Ответ на: комментарий от FixingGunsInAir

Некрофилы не нужны

Ага, и невиндузятники не нужны, PC===Windows, маки для <оффтопик-лист, п.19> ;)

Вы там не охренели — решать, что нужно, а что не нужно? Если уж решать, то по проценту от статистики. Хотя и тут depends, надо с отделом маркетинга (если он, конечно, есть ;)) согласовывать, кто больше бабла заносит и ради кого надо страдать.

mertvoprog
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.