== портировать на любую платформу, типа как PWA только с доступом к девайсу. а потом работать с девайсом на js. не хочется. Да портировать что - примитивный тормозной гуй на говнореактах? так его в 90х любой инвалид на дельфях мог сготовить левой рукой за два дня, то над чем современные гуру реакта бьются неделями

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

поэтому такие вещи как Electron и Cordova и существуют... легче написать web приложение а потом портировать его на десктоп и мобилки

соотв. в Qt это проще переписать чем портировать

оу... так вы через IPC?  ox....

через сокеты и именованные пайп-каналы - net.Conn

== портировать на любую платформу, типа как PWA только с доступом к девайсу. а потом работать с девайсом на js. не хочется. Да портировать что - примитивный тормозной гуй на говнореактах? так его в 90х любой инвалид на дельфях мог сготовить левой рукой за два дня, то над чем современные гуру реакта бьются неделями

примитивный и тормозной веб был в 2006, но никак не в 2018. React мы не используем, пишем на Vue. Относительно QML веб ещё долгое время будет более прожорлив и медленен, но с точки зрения пользователя в вебе уже можно сделать довольно неплохого качества приложение

JavaScript далеко уже не медленный на современных движках типа V8 или Chakra, Go конечно быстрее, но опять же, с точки зрения приложения для пользователя JS по производительности более чем достаточен, если руки у разработчика не из одного места

соотв. в Qt это проще переписать чем портировать

и потом содержать 2 кодовые базы, супер)

можно, но стоимость такой разработки будут выше чем в Qt - код будут сложнее, поскольку сам веб имхо ущербный. И на счёт того, что современный веб не тормозной - это вы погорячились. Достичь завестных 60fps на той же Qt ничего не стоит, а веб для этог оприходится изрядно извращаться. по поводу vue - писать что-то серьезное на нетипизированном языке — нельзя. Как следствие, все фреймворки с шаблонами на своём DSL, в котором строгой типизации нет, и как ее приделать непонятно. — сразу выкидываются в помойку, без попыток в них разобраться.

через сокеты и именованные пайп-каналы - net.Conn

т.е. ты запускаешь 2 процесса один на Qt Quick и другой на Go? и связываешь их по сокетам? звучит довольно костыльно, ведь C++ тебе всё равно придётся писать в таком случае

не более костыльно чем запускать веб сервер + SPA. С++ в этом случае простой, пишется без буста и прочих страшных зависимомстей

И ещё в этом случае хорошая практика разделения бизнеслогики и гуя, последний на первую не влияет

Всем привет. Мы тут подправили бота чутка, зацените?) @enqueue_bot

можно, но стоимость такой разработки будут выше чем в Qt - код будут сложнее, поскольку сам веб имхо ущербный. И на счёт того, что современный веб не тормозной - это вы погорячились. Достичь завестных 60fps на той же Qt ничего не стоит, а веб для этог оприходится изрядно извращаться. по поводу vue - писать что-то серьезное на нетипизированном языке — нельзя. Как следствие, все фреймворки с шаблонами на своём DSL, в котором строгой типизации нет, и как ее приделать непонятно. — сразу выкидываются в помойку, без попыток в них разобраться.

наоборот. Найти Qt Quick разработчиков сложнее и оно сами по себе дороже. Веб разработчиков как песка на море. Даже при учёте правила "90% всего - говно", в веб мире всё равно будет больше более дешёвых толковых людей чем на Qt. я с вами согласен что DOM'у пора в заслуженную отставку. Даже пишу статейку по этому поводу что вебу пора переходить на язык более похожий на QML с новым scene graph'ом на основе WASM. HTML/CSS и DOM изобретался для статичных документов, а не для динамичных современных приложений. однако не всё так плохо как люди говорят. можно вполне приемлемый UX получить на современных браузерах. Проблема тут в том, что если изначально приложение у вас в вебе, то переписывать его ещё и на Qt - гермоно и очень дорого. 2 кодовые базы содержать это нехорошо и неэффективно с точки зрения продуктивности. Да и существующие моб. / деск. приложения портировать в веб тоже будет гермоно. Поэтому мы пошли путём "web first" ибо web скоро станет ультимативной платформой и убьёт app store'ы, но это отдельная тема) В итоге тот факт, что придётся содержать 2 кодовые базы на 2 разных технологиях с 2 командами - перевешивает недостатки веб стэка. По крайней мере для нас

не более костыльно чем запускать веб сервер + SPA. С++ в этом случае простой, пишется без буста и прочих страшных зависимомстей

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

В том и дело, что один Qt разработчик может с успехом заменить целый цех знатаков css и хакеров на реакт. И код проще сопровождать и ревьюить. Чтобы тупо перенести вьюхи в десктоп и пользователя устраивает fps в электроне, то можно конечно и портировать - если приложение не работает с жлезом и не нужна многопоточность. Если нет сложной бизнеслогики - и т.д. Я с такими случаями не сталкивался в практике

И веб у меня если уж на то пощло написан в основном на elm-е, и переносить его в электрон возможности нет

использовать го для бизнес логики без дженериков ? вы точно этого хотите ?

использовать го для бизнес логики без дженериков ? вы точно этого хотите ?

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

точно пишут?

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

а как же java?

точно пишут?

https://www.youtube.com/watch?v=cFJkLfujOts

И веб у меня если уж на то пощло написан в основном на elm-е, и переносить его в электрон возможности нет

Насколько я помню, мелькали какие то статьи по дружбе Елм и Электрон

не, это всё фигня. там костыль на костыле и сплошь маргинальщина

не, это всё фигня. там костыль на костыле и сплошь маргинальщина

Добро пожаловать в мир веба ?

В том и дело, что один Qt разработчик может с успехом заменить целый цех знатаков css и хакеров на реакт. И код проще сопровождать и ревьюить. Чтобы тупо перенести вьюхи в десктоп и пользователя устраивает fps в электроне, то можно конечно и портировать - если приложение не работает с жлезом и не нужна многопоточность. Если нет сложной бизнеслогики - и т.д. Я с такими случаями не сталкивался в практике

А потом уйдёт этот гений из компании и всё, нет его, и работа стоит пока нового не найдёшь)) а новый так ещё и дороже предыдущего может оказаться)

https://www.youtube.com/watch?v=cFJkLfujOts

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

использовать го для бизнес логики без дженериков ? вы точно этого хотите ?

на C++ писать тяжко, я по своемы опыту знаю. Как я уже говорил: C++ и прекрасен и ужасен одновременно.

мне просто интересно, вот добавляют они новый вид карточки например. и че - все нормально ?

поменяли в одном месте и все взлетело с полпинка ?

на C++ писать тяжко, я по своемы опыту знаю. Как я уже говорил: C++ и прекрасен и ужасен одновременно.

c++ ненужен. есть java,

для бизнес логики

c++ ненужен. есть java,

да, поэтому давайте писать GUI на Java, best idea ever))

нет, пиши на чем хочешь gui

нет, пиши на чем хочешь gui

да.. давайте напишем GUI на C++, бизнес логику на Java, свяжем всё это через IPC...

А потом уйдёт этот гений из компании и всё, нет его, и работа стоит пока нового не найдёшь)) а новый так ещё и дороже предыдущего может оказаться)

э нет, тут такая логика не работает) Она работает в отношения скалы, хаскиля и тому подобной маргинальщины, которая для нормального человека не более чем абракадабра. Хороший код, написанный на Qt, легко читать и сопровождать. Уж куда проще чем css. Особенно когда в нём нет буста.

тогда уж и гиу писать на той же джаве)

э нет, тут такая логика не работает) Она работает в отношения скалы, хаскиля и тому подобной маргинальщины, которая для нормального человека не более чем абракадабра. Хороший код, написанный на Qt, легко читать и сопровождать. Уж куда проще чем css. Особенно когда в нём нет буста.

да, но людей в вебе на порядок больше чем в Qt

тогда уж и гиу писать на той же джаве)

лучше убейте меня, чем предлагать писать гуй на Java

да.. давайте напишем GUI на C++, бизнес логику на Java, свяжем всё это через IPC...

ну делайте еслли хотите

да, но людей в вебе на порядок больше чем в Qt

людей много - ртов много, а я один)

лучше убейте меня, чем предлагать писать гуй на Java

это на много лучше чем электрон имхо

гуй на яве это еще не самое плохое что бывает, но тебя никто не заставляет писать гуй на яве

да, но людей в вебе на порядок больше чем в Qt

Еще они дешевле, но по качеству швах. Ну и не надо думать, что синьер-реакт попросит меньше плюсиста.

э нет, тут такая логика не работает) Она работает в отношения скалы, хаскиля и тому подобной маргинальщины, которая для нормального человека не более чем абракадабра. Хороший код, написанный на Qt, легко читать и сопровождать. Уж куда проще чем css. Особенно когда в нём нет буста.

Есть куча современных навесок над css типа sass less, которые улучшают ситуацию до приемлимой

это на много лучше чем электрон имхо

Особенно зимой, ноутом ноги греть.

Еще они дешевле, но по качеству швах. Ну и не надо думать, что синьер-реакт попросит меньше плюсиста.

Qt так или иначе будет дороже..

это на много лучше чем электрон имхо

ох...

Qt так или иначе будет дороже..

Имхо так-же. Именно разработка гуи на QT не требует madskillz в плюсах.

Есть куча современных навесок над css типа sass less, которые улучшают ситуацию до приемлимой

у веба 2 проблемы: 1. DOM действительно убог и действительно много workaround'ов и костылей. HTML/CSS не для приложений изобретали 2. Веб развивается настолько быстро, что люди просто за ним не успевают. Большинство мифоф которыми пугают нынешних разработчиков были верны может быть в 2006, но не 2018, браузеры сильно улучшились, JS движки сильно улучшились, веб это самая большая платформа и она будет только расти

Еще они дешевле, но по качеству швах. Ну и не надо думать, что синьер-реакт попросит меньше плюсиста.

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

PostCSS + autoprefixer для Webpack всё уже давно решили в плане хаков и workaround'ов для CSS. Просто пишешь и всё само там автопрефиксится, а следовательно и работает нормально в 99% случаев.

https://blog.plan99.net/its-time-to-kill-the-web-974a9fe80c89

у веба 2 проблемы: 1. DOM действительно убог и действительно много workaround'ов и костылей. HTML/CSS не для приложений изобретали 2. Веб развивается настолько быстро, что люди просто за ним не успевают. Большинство мифоф которыми пугают нынешних разработчиков были верны может быть в 2006, но не 2018, браузеры сильно улучшились, JS движки сильно улучшились, веб это самая большая платформа и она будет только расти

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

PostCSS + autoprefixer для Webpack всё уже давно решили в плане хаков и workaround'ов для CSS. Просто пишешь и всё само там автопрефиксится, а следовательно и работает нормально в 99% случаев.

нет, не решили. CSS это cascading style sheets, акцент на cascading. Это нахер не надо в приложении, это нужно только в документах. В приложении нужна модульность и изоляция, а CSS зачастую нарушает изоляцию компонентов, стили протекают и ломают компоненты к тому же вы когда нибудь пробовали привязать свойства компонентов к стилям? Если да, то наверняка вы знаете насколько это костыльно и убого. Inline styles очень медленные и задачу не решают. QML это то как надо писать современные приложения. Там есть только объекты и свойства. Свойства могут являться чем угодно, стилями, параметрами и т.д. в web'е компоненты же пока-что на очень примитивном уровне

нет, не решили. CSS это cascading style sheets, акцент на cascading. Это нахер не надо в приложении, это нужно только в документах. В приложении нужна модульность и изоляция, а CSS зачастую нарушает изоляцию компонентов, стили протекают и ломают компоненты к тому же вы когда нибудь пробовали привязать свойства компонентов к стилям? Если да, то наверняка вы знаете насколько это костыльно и убого. Inline styles очень медленные и задачу не решают. QML это то как надо писать современные приложения. Там есть только объекты и свойства. Свойства могут являться чем угодно, стилями, параметрами и т.д. в web'е компоненты же пока-что на очень примитивном уровне

> В приложении нужна модульность и изоляция, а CSS зацастую нарушает изоляцию компонентов, стили протекают и ломают компоненты Не знаю как везде, но в случае с React'ом эта изоляция делается очень просто при помощи styled components

https://github.com/styled-components/styled-components

> В приложении нужна модульность и изоляция, а CSS зацастую нарушает изоляцию компонентов, стили протекают и ломают компоненты Не знаю как везде, но в случае с React'ом эта изоляция делается очень просто при помощи styled components

да, через inline стили, которые не позволяют добиться 60 fps и заставляют CPU жариться

У Vue тоже было нечто подобное. vue-loader разруливал.

Но я согласен, что Qt5 для десктопных приложений топ :)

да, через inline стили, которые не позволяют добиться 60 fps и заставляют CPU жариться

там не инлайн

Представляю насколько был бы убогим и тормозным KDE5 если бы был написан на Electron или JS :D

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

сложно объяснить человеку, который никогда не использовал QML, что есть что-то получше DOM'а... это настолько же сложно как объяснить на словах человеку, который всю жизнь слушал музыку на наушниках за 10 баксов, чем дорогие студийные наушники лучше... но я постараюсь вкратце: в QML есть объекты и свойства. Свойства эти по своей природе динамичны, можно привязать одно свойство к другому с помощью сигналов и слотов. Т.е. стили можно привязать к логике практически без потерь производительности и overhead'а. в DOM'е же всё иначе.. сам по себе DOM довольно статичен и динамичным его делает JavaScript. Стили ты не привяжешь к логике никак, ты лишь можешь повесить обработчик события и в нём манипулировать DOM... но это очень, ОЧЕНЬ затратно по ресурсах CPU и памяти. Следственно добиться true 60 fps очень сложно, если у тебя многое делается через JS в итоге то же приложение, которые на Qt работало бы на 60 фпс и 20% CPU, в вебе в лучшем случае как минимум 40% сожрёт и фпс будет просидать порой до 40,30

сложно объяснить человеку, который никогда не использовал QML, что есть что-то получше DOM'а... это настолько же сложно как объяснить на словах человеку, который всю жизнь слушал музыку на наушниках за 10 баксов, чем дорогие студийные наушники лучше... но я постараюсь вкратце: в QML есть объекты и свойства. Свойства эти по своей природе динамичны, можно привязать одно свойство к другому с помощью сигналов и слотов. Т.е. стили можно привязать к логике практически без потерь производительности и overhead'а. в DOM'е же всё иначе.. сам по себе DOM довольно статичен и динамичным его делает JavaScript. Стили ты не привяжешь к логике никак, ты лишь можешь повесить обработчик события и в нём манипулировать DOM... но это очень, ОЧЕНЬ затратно по ресурсах CPU и памяти. Следственно добиться true 60 fps очень сложно, если у тебя многое делается через JS в итоге то же приложение, которые на Qt работало бы на 60 фпс и 20% CPU, в вебе в лучшем случае как минимум 40% сожрёт и фпс будет просидать порой до 40,30

что является примитивным обьектом в qml?

да и к тому же у DOM'ма много ограничений... например в Qt я могу просто привязать одни свойства к свойству размера какого то контейнера и тем самым плавно отображать разные стили для разных размеров контейнера в HTML/CSS же есть только media queries, которые считаются от документа, а не от какого либо элемента, следственно стили модулей сделать практически невозможно. Есть такие хаки как element queries, которые на JavaScript реализуют выполнение callback'ов по изменению размеров отдельных элементов, но они жрут гораздо больше памяти и CPU чем property bindings в QML

ERROR: S client not available

что является примитивным обьектом в qml?

Object ?

Object ?

с точки зрения отрисовки интерфеса - это что? блок? канвас?

с точки зрения отрисовки интерфеса - это что? блок? канвас?

это ничто, это может быть визуальным элементом, это может быть router'ом, это может быть адаптером для какой то API.... Object это абстрактный объект есть Item, который наследует от Object, он уже обладает такими свойствами как width, height и т.д. потом есть Rectangle, которые наследует от Item, у которого уже есть color, border-radius и прочее, вот это уже аналов <div>'а

там не инлайн

а на чём же?)))

а на чём же?)))

обычные цсс классы

это ничто, это может быть визуальным элементом, это может быть router'ом, это может быть адаптером для какой то API.... Object это абстрактный объект есть Item, который наследует от Object, он уже обладает такими свойствами как width, height и т.д. потом есть Rectangle, которые наследует от Item, у которого уже есть color, border-radius и прочее, вот это уже аналов <div>'а

а, так ничего не мешает это реализовать в текущем DOM. в качестве экшена может бытьь JS функция, которая навешивает определенный класс, css уже автоматом при рендере навешивает изменения. это вопрос архитектуры

обычные цсс классы

можно где-нибудь почитать о том, как это работает под капотом?

а, так ничего не мешает это реализовать в текущем DOM. в качестве экшена может бытьь JS функция, которая навешивает определенный класс, css уже автоматом при рендере навешивает изменения. это вопрос архитектуры

вы не читали что я написал? в QML - проперти биндинги намного менее overhead'ны, чем обработчики на JS, которые манипулируют DOM

обычные цсс классы

https://youtu.be/2j9rSur_mnk?t=24m1s

пожалуйста, 24:00

стили инлайнятся и это гораздо более прожорливо чем property binding в Qt

ох, чёт мы уже далеко от Go ушли, думаю стоит беседу приостановить

не услышал там про инлайн

не услышал там про инлайн

поэтом я и спросил, где можно почитать про конкретную имплементацию под капотом, но тут однозначно говорится про performance overhead, и я не могу себе представить как они будут мутировать стили в рантайме без inline'а

вы не читали что я написал? в QML - проперти биндинги намного менее overhead'ны, чем обработчики на JS, которые манипулируют DOM

я тут, к сожалению, не смогу составить противоположную точку зрения точно, ибо не понимаю, как qml обрабатывает 1000 объектов. с css все просто, изменился класс - пробежались по зависимым элементам, поменяли свойства и отрисовали заново. это довольно быстро, если не городить ерунды в css + html. то что вы говорите про меньший оверхед без знаний qml в проекции на веб-интерфес сложно оценить без понимания

а если у объекта 10 возможных состояний, мне их все описывать?

я тут, к сожалению, не смогу составить противоположную точку зрения точно, ибо не понимаю, как qml обрабатывает 1000 объектов. с css все просто, изменился класс - пробежались по зависимым элементам, поменяли свойства и отрисовали заново. это довольно быстро, если не городить ерунды в css + html. то что вы говорите про меньший оверхед без знаний qml в проекции на веб-интерфес сложно оценить без понимания

а теперь представьте... у вас позиция элемента E по оси Y привязана к скролу контейнера C представим себе Safari, где у нас smooth scroll в 60 fps. Каждые 16 миллисекунд, изменение скрола будет вызывать обработчик onChanged, который будет манипулировать DOM, сначала удаляя предыдущий класс, а потом заново создовая новый с обновлёнными стилями... с точки зрения производительности лучше поставить inline style, это быстрее будет. Но даже этот подход в раз 100 наверное будет медленее property binding'ов в QML. в QML есть "optimized property bindings" которые выполняются прямо в движке рендера обходя JS движок, так сказать "не отходя от кассы" обновляется свойство e.y = c.scrollY, после чего это дело заново рендерится в новый фрейм. Это значительно экономнее и быстрее

Что такое ...?

насколько мне известно к "optimized" относятся даже более сложные биндинги как например: Circle { id: container radius: 5 Rectangle { id: inner anchors.centerIn: parent width: parent.radius / 2 } } т.е. вот этот биндинг: width: parent.radius / 2 выполнится не в JS, а в самом движке рендера, без лишнего overhead'а а вот если указать грубо говоря: width: parent.radius + http.get("parameter").body.someVal, вот тогда уже и будет вызываться JS в обработчике onChanged

А что такое ... в го?

Из builtins пример `func append(slice []Type, elems ...Type) []Type`

А что такое ... в го?

https://stackoverflow.com/questions/23669720/dot-dot-dot-in-golang-interface-with-empty-braces

а теперь представьте... у вас позиция элемента E по оси Y привязана к скролу контейнера C представим себе Safari, где у нас smooth scroll в 60 fps. Каждые 16 миллисекунд, изменение скрола будет вызывать обработчик onChanged, который будет манипулировать DOM, сначала удаляя предыдущий класс, а потом заново создовая новый с обновлёнными стилями... с точки зрения производительности лучше поставить inline style, это быстрее будет. Но даже этот подход в раз 100 наверное будет медленее property binding'ов в QML. в QML есть "optimized property bindings" которые выполняются прямо в движке рендера обходя JS движок, так сказать "не отходя от кассы" обновляется свойство e.y = c.scrollY, после чего это дело заново рендерится в новый фрейм. Это значительно экономнее и быстрее

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

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

transition это не о том совсем, это не биндинги а анимации. аргумент про "разнообразие" абсолютно не о чём, вот вам конкретный пример с inline стилями и манипуляцией DOM'а из JS.. Я там вот только что привёл конкретный real world пример, где DOM с JS и HTML/CSS просто позорище по сравнению с QML, и "пересмотреть" подход можно только так: н@хjй HTML/CSS, пилим новый Scene Graph на WASM и цепляем к нему новый язык похожий на QML.

transition это не о том совсем, это не биндинги а анимации. аргумент про "разнообразие" абсолютно не о чём, вот вам конкретный пример с inline стилями и манипуляцией DOM'а из JS.. Я там вот только что привёл конкретный real world пример, где DOM с JS и HTML/CSS просто позорище по сравнению с QML, и "пересмотреть" подход можно только так: н@хjй HTML/CSS, пилим новый Scene Graph на WASM и цепляем к нему новый язык похожий на QML.

Сложно представить десктоп приложение столь же богатое динамикой и графикой как и современные веб-приложения. Отсюда и мысль про сложность попытки сделать это все уложить в сложно переплетенные обьекты

Сложно представить десктоп приложение столь же богатое динамикой и графикой как и современные веб-приложения. Отсюда и мысль про сложность попытки сделать это все уложить в сложно переплетенные обьекты

честно говоря я не понимаю о чём вы

Кто знает как скомпилить под 32 битную ос из под 64 битной ос. https://github.com/SaturnsVoid/Chrome-Password-Recovery

А что такое ... в го?

spreading

Кто знает как скомпилить под 32 битную ос из под 64 битной ос. https://github.com/SaturnsVoid/Chrome-Password-Recovery

гугли go cross compilation

честно говоря я не понимаю о чём вы

В вебе часто изменение какого то класса цсс автоматом меняет сотни свойств вложенных и не только обьектов.

гугли go cross compilation

Из под винды 8.1 64 бит компилю выскакивает - 2018/04/29 17:14:55 Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub . Прежде поставив set GOARCH=386

Чувачки помогите затестить бота, буду премного благодарен) @enqueue_bot