Здравствуйте, alex_public, Вы писали:

_>Для начала проясню один момент, который ты в очередной раз себе нафантазировал. Похоже у тебя почему-то создалось впечатление, что у мы там играемся с треугольниками на шейдерах ради показа кнопки. Да, глубоко внутри соответствующей библиотеки оно на самом деле так и происходит, но мы этого всего не видим, т.к. пользуемся исключительно высокоуровневым API классической GUI библиотеки. И да, она естественно написана не нами. Т.е. мы просто перешли с Qt (которая не нужна, если ты не пытаешься писать кроссплатофермнное приложение, выглядящее нативно на каждой из платформ) на другую библиотеку со своей оригинальной прорисовкой (всё равно в браузере нет никаких своих платформенных стандартов и каждый рисует как хочет).

Сначала ты утверждаешь, что де canvas это классный инструмент для UI, и приводишь целый пример с 3д тенями.
После этого выясняется, что на самом деле вы используете какую то 3d party библиотеку о которой ты не сказал ни слова.
Может тебе поработать над аргументацией?

I>>Чтото навроде пилят люди на курсах "фронтенд за 21 урок", где канвасу посвящается целых 1 или даже 2 занятия.

_> Ты похоже сильно путаешь просто canvas и webgl.

Трудно понть о чем ты пишешь, если у тебя canvas и 3д тени как основной аргумент.
Ну вебгл, и что с того?
Само по себе это низкоуровневый движок рендеринга, без высокоуровневой либы ничего интересного не происходит.

Тут есть большая разница
Скажем, от канваса требуется максимальный перформанс.
От либы UI требуется максимальная продуктивность специализированного разработчика. React тот же вполне себе справляется с этой задачей и не требует многих лет втыкания в QT, с++ и webql

_>Ты вот сам то знаешь что такое полигональная сетка (mesh), как её сформировать из иерархии контролов и потом прорисовать на шейдерах с наложением текстур? )))

Я ведь обычный человек, а не какой нибудь vdimas, который, с его слов, всё знает лучше всех. Я опираюсь на твои слова — ты сказал, что де у фронтов есть супер-пупер-мега-классный инструмент — канвас, а они пользуются HTMl/CSS/DOM.
Странно, что вашим супер-пупер-мега-классным инструментом пользуется ничтожное количество людей.
Парадокс! И конечно же у тебя объяснение в том, что фронтенды они того, недалёкие, не знают своего щастя!

I>>Я напомню — MFC, Winforms, WPF и многие другие вобщем слились, хотя обладали очень крутыми возможностями. То есть, не в крутости дело.
_>Угу, они все слились в пользу Qt, которая точно такая же, только кроссплатформенная. )))

Смешной аргумент. Сейчас 90% UI это бразерный на HTML/CSS/JS, а остальное примерно поравну делится межжу
1. джава
2. дотнет
3. всякие иос и макос придумки
и где то на грани статистической погрешности будут всякие QT

_>И ты не путай сайтики (причём оно останется сайтиком, даже если у него за спиной будет крутейший сервер типа яндекса или гугла) и приложения.

Ну да, надо только исключить неудобные для тебя факты.

I>> Ты сделал поддержку стилей? Ну что бы по десять раз на неделе сотни мелких фиксов в стилях делать не пересобирая вообще все и не ломая то тут, то там?

_>Да, вся прорисовка библиотеке полностью управляется стилями — можешь в один клик сделать всем окнам прозрачный фон или розовый и него зелёные кнопки с жёлтым жирным текстом курсивом. Однако у нас за всё время использования ни разу не возникло желания заниматься подобным — дефолтный стиль от разработчиков библиотеки полностью устраивает. Ну и да, стили естественно настраиваются не каким-то мутным текстовым DSL'ем, а нормальной такой жёстко типизированной структуркой.

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

I>> А сколько времени надо, что бы новому кастомеру вообще все стили переделать?
_>В теории мгновенно.

Это или понты, или ложь — ну не бывает мгновенного набора текста. Вам присылают желаемую картинку, а вы должны вписать все шрифты, цвета, отступы, итд и тд.

>А на практике такого никогда не будет — мы не на аутсорсе и менять что-то по прихоти отдельного клиента не собираемся в принципе.

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

_>Лично у нас был большой опыт написания приложений (на Qt), работающих под любой экран, так что тут вышло всё хорошо.

Звучит так, как будто вы художника сделали маляром

I>> А можно ли твой компонент встроить как отдельный элемент UI другого приложения, да так, что бы то, другое, могло подменить все стили, лайоут, итд твоего?

_>Какой ещё компонент? ))) У нас приложение! Ты вот можешь встроить AutoCAD в Photoshop? )))

Для веба, например, цельное приложение можно показывать из под другого сайта. Безо всяких COM, ActiveX и прочих чудес.
И выглядит гладко, что не видна граница.

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

_>Все контролы естественно размещаются автоматически и динамически. Т.е. я поверну телефон на 90 градусов и все они тут же автоматически перестроятся под оптимальный размер и позицию. Причём мне для этого ничего делать не надо. всё само. Вообще такие вещи являются нормой в GUI библиотеках уже десяток лет (в Qt всё было тоже самое) и только в мире веб-фронтенда такие простейшие и очевидные вещи до сих пор вызывают вопросы.

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

Судя по ответам выше, вам дизайнер или ничего не присылает, или его хотелки весьма пространные. Ну или UI тривиальный. Ну много строчек в списке, и что? А сложность то в чем заключается ? Ты молчишь, как партизан, рассказываешь только какие то странные подробности
— 3д тени
— красивости
— 10000 элементов в списке
— вебгл
— крутая либа
— огого
— агага
— у нас много опыта в QT и С++

Вобщем, это всё ни о чем.

_>Конечно это высосанный тобой из пальца пример, но почему бы не порассуждать и о таком.

Это пример из реального проекта. Забавно, что обыденные хотелки заказчика для тебя "высосанные из пальца "

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

Как все сложно то. А всех делов — описать xml-подобным языком элементы карточки и прописать стили. А вот дальше нужно смотреть ,как это хранить, т.к. взаимодействие с этой карточкой может иметь массу вариантов, в зависимости от придумки дизайнера. Нет взаимодействия — храним в обычном JSON в плоском виде. Отсюда ясно, что серилизация, десерилизация перед нами вообще не стоит — это тривиальная часть задачи, которую даже упоминать не стоит.

_>Всё оно отлично прижилось (я естественно про WebGL, а не какие-то там DOM поделки, типа голой canvas). ) Просто доля настоящих приложений (но при этом работающих в браузере) пока что ничтожна по сравнению с бесчисленными сайтиками.

"доля ничтожна" означает "не прижился"
А вот html/css/dom именно что прижился, т.к. его сейчас по скромной оценке процентов 90. На него переводят даже САПР, офис, итд. И даже в Микрософте. Вот так!

Здравствуйте, alex_public, Вы писали:

_>Для начала проясню один момент, который ты в очередной раз себе нафантазировал. Похоже у тебя почему-то создалось впечатление, что у мы там играемся с треугольниками на шейдерах ради показа кнопки. Да, глубоко внутри соответствующей библиотеки оно на самом деле так и происходит, но мы этого всего не видим, т.к. пользуемся исключительно высокоуровневым API классической GUI библиотеки. И да, она естественно написана не нами. Т.е. мы просто перешли с Qt (которая не нужна, если ты не пытаешься писать кроссплатофермнное приложение, выглядящее нативно на каждой из платформ) на другую библиотеку со своей оригинальной прорисовкой (всё равно в браузере нет никаких своих платформенных стандартов и каждый рисует как хочет).

Сначала ты утверждаешь, что де canvas это классный инструмент для UI, и приводишь целый пример с 3д тенями.
После этого выясняется, что на самом деле вы используете какую то 3d party библиотеку о которой ты не сказал ни слова.
Может тебе поработать над аргументацией?

I>>Чтото навроде пилят люди на курсах "фронтенд за 21 урок", где канвасу посвящается целых 1 или даже 2 занятия.

_> Ты похоже сильно путаешь просто canvas и webgl.

Трудно понть о чем ты пишешь, если у тебя canvas и 3д тени как основной аргумент.
Ну вебгл, и что с того?
Само по себе это низкоуровневый движок рендеринга, без высокоуровневой либы ничего интересного не происходит.

Тут есть большая разница
Скажем, от канваса требуется максимальный перформанс.
От либы UI требуется максимальная продуктивность специализированного разработчика. React тот же вполне себе справляется с этой задачей и не требует многих лет втыкания в QT, с++ и webql
Сам реакт или, скажем, только jsx можно без проблем использовать с другим рендерером, хоть в 2d, 3d графику или в *.txt или консольный скрин
Вобщем, трудо понять, что ты хочешь сказать.

_>Ты вот сам то знаешь что такое полигональная сетка (mesh), как её сформировать из иерархии контролов и потом прорисовать на шейдерах с наложением текстур? )))

Я ведь обычный человек, а не какой нибудь vdimas, который, с его слов, всё знает лучше всех. Я опираюсь на твои слова — ты сказал, что де у фронтов есть супер-пупер-мега-классный инструмент — канвас, а они пользуются HTMl/CSS/DOM.
Странно, что вашим супер-пупер-мега-классным инструментом пользуется ничтожное количество людей.
Парадокс! И конечно же у тебя объяснение в том, что фронтенды они того, недалёкие, не знают своего щастя!

I>>Я напомню — MFC, Winforms, WPF и многие другие вобщем слились, хотя обладали очень крутыми возможностями. То есть, не в крутости дело.
_>Угу, они все слились в пользу Qt, которая точно такая же, только кроссплатформенная. )))

Смешной аргумент. Сейчас 90% UI это бразерный на HTML/CSS/JS, а остальное примерно поравну делится межжу
1. джава
2. дотнет
3. всякие иос и макос придумки
и где то на грани статистической погрешности будут всякие QT

_>И ты не путай сайтики (причём оно останется сайтиком, даже если у него за спиной будет крутейший сервер типа яндекса или гугла) и приложения.

Ну да, надо только исключить неудобные для тебя факты.

I>> Ты сделал поддержку стилей? Ну что бы по десять раз на неделе сотни мелких фиксов в стилях делать не пересобирая вообще все и не ломая то тут, то там?

_>Да, вся прорисовка библиотеке полностью управляется стилями — можешь в один клик сделать всем окнам прозрачный фон или розовый и него зелёные кнопки с жёлтым жирным текстом курсивом. Однако у нас за всё время использования ни разу не возникло желания заниматься подобным — дефолтный стиль от разработчиков библиотеки полностью устраивает. Ну и да, стили естественно настраиваются не каким-то мутным текстовым DSL'ем, а нормальной такой жёстко типизированной структуркой.

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

I>> А сколько времени надо, что бы новому кастомеру вообще все стили переделать?
_>В теории мгновенно.

Это или понты, или ложь — ну не бывает мгновенного набора текста. Вам присылают желаемую картинку, а вы должны вписать все шрифты, цвета, отступы, итд и тд.

>А на практике такого никогда не будет — мы не на аутсорсе и менять что-то по прихоти отдельного клиента не собираемся в принципе.

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

_>Лично у нас был большой опыт написания приложений (на Qt), работающих под любой экран, так что тут вышло всё хорошо.

Звучит так, как будто вы художника сделали маляром

I>> А можно ли твой компонент встроить как отдельный элемент UI другого приложения, да так, что бы то, другое, могло подменить все стили, лайоут, итд твоего?

_>Какой ещё компонент? ))) У нас приложение! Ты вот можешь встроить AutoCAD в Photoshop? )))

Для веба, например, цельное приложение можно показывать из под другого сайта. Безо всяких COM, ActiveX и прочих чудес.
И выглядит гладко, что не видна граница.

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

_>Все контролы естественно размещаются автоматически и динамически. Т.е. я поверну телефон на 90 градусов и все они тут же автоматически перестроятся под оптимальный размер и позицию. Причём мне для этого ничего делать не надо. всё само. Вообще такие вещи являются нормой в GUI библиотеках уже десяток лет (в Qt всё было тоже самое) и только в мире веб-фронтенда такие простейшие и очевидные вещи до сих пор вызывают вопросы.

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

Судя по ответам выше, вам дизайнер или ничего не присылает, или его хотелки весьма пространные. Ну или UI тривиальный. Ну много строчек в списке, и что? А сложность то в чем заключается ? Ты молчишь, как партизан, рассказываешь только какие то странные подробности
— 3д тени
— красивости
— 10000 элементов в списке
— вебгл
— крутая либа
— огого
— агага
— у нас много опыта в QT и С++

Вобщем, это всё ни о чем.

_>Конечно это высосанный тобой из пальца пример, но почему бы не порассуждать и о таком.

Это пример из реального проекта. Забавно, что обыденные хотелки заказчика для тебя "высосанные из пальца "

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

Как все сложно то. А всех делов — описать xml-подобным языком элементы карточки и прописать стили. А вот дальше нужно смотреть ,как это хранить, т.к. взаимодействие с этой карточкой может иметь массу вариантов, в зависимости от придумки дизайнера. Нет взаимодействия — храним в обычном JSON в плоском виде. Отсюда ясно, что серилизация, десерилизация перед нами вообще не стоит — это тривиальная часть задачи, которую даже упоминать не стоит.

_>Всё оно отлично прижилось (я естественно про WebGL, а не какие-то там DOM поделки, типа голой canvas). ) Просто доля настоящих приложений (но при этом работающих в браузере) пока что ничтожна по сравнению с бесчисленными сайтиками.

"доля ничтожна" означает "не прижился"
А вот html/css/dom именно что прижился, т.к. его сейчас по скромной оценке процентов 90. На него переводят даже САПР, офис, итд. И даже в Микрософте. Вот так!