Здравствуйте, vdimas, Вы писали:
V>Если клиент открывает тебе порт, то что угодно на чём угодно можно поотлаживать.
Очевидно, что нет. Я возможности перечислил, а ты никак решение для нативного варианта не покажешь.
Похоже, у тебя кроме нападок ничего вобщем и нет
V>Курить удалённую отладку в любой другой технологии.
Вот-вот, покури. Каким образом ты получишь хттп трафик приложения с внятной визуализацией? Ну или запись вызовов функций на критическом участке? Пермишнов нет, запускать у клиента ничего нельзя. Пдб нет. Что за чудо-компонент будешь встраивать, который выполнит функции пяти тулов?
V>Но я так и не понял, с чего ты решил, что клиент даст тебе доступ к своей машине?
К его машине мне как раз доступа не надо, в отличие от нативного дебагера, профайлера, сканера. И пермишнов не надо.
Собственно, всё что мне надо, это глянуть данные, к которым у меня и так доступ есть, обрабатываются в его браузерном движке.
V>>>А что ты пытаешься доказать через ругань в адрес всего и вся? I>>А где ты видишь ругань?
V>Вижу, вот опять.
Процитируй Может у тебя экран глянцевый? Это могло бы объяснить многие аспекты.
V>Ты, похоже, решил, что удалённая отладка — это изобретение JS.
Я перечислил возможности, покажи эквивалент для нативной апликачки, который закроет все это.
Re[26]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>>>Кстате, react — это не DOM браузера, 90% "навыков" фронтендера отваливаются. )) I>>А кто говорит,что react это DOM браузера? JSX это не DOM, а вот рендерится в DOM, ибо больше не во что. А отсюда ясно, что основные проблемы и особенности DOM остаются.
V>Да похер. V>Это как отлаживать C# программу по ассемблерному дебаггеру. V>Причём, ассемблер не CLR, а нейтивного проца.
Неверная аналогия. Что бы написать правильный код на JSX, надо хорошо знать DOM.
I>>Кроме того, кастомные вещи всё равно приходится закрывать работой с DOM, например, оптимизации и тд.
V>И опять похер, т.к. рендер-исходники компонент иммутабельны. V>Это описание нельзя изменять после создания компонента, что кардинально отличается от привычной практики фронтенда.
И всё мимо
Например, тебе надо правильно организовать работу с эвентами. А раз так, то и методы работы с эвентами никто не отменял.
Далее — интерграция с 3rd party компонентами, что есть норма. Здесь придется работать с дом, и подсказывать реакту,как всё должно быть на самом деле.
Далее, есть кейсы с анимацией. Её стараются заменить на CSS анимацию, но JS анимации так же используется. Тут все через dom.
Фокус, селекш — это тоже DOM.
I>>Если ты нарендерил херни, то херню и получишь, и работать она будет как и положено херне. Из этого ничего не следует, разве что про твой личный опыт в пол-часа втыкания в реакт.
V>Из этого следует ровно то, что я написал.
Ни коим образом.
V>>>И да, полезность Хрома в кач-ве отладчика react-приложух резко падает, т.к. после babel будет в отладчике неузнаваемая лапша, вместо твоего исходника. I>>Ты снова пишешь про какой то свой больной опыт. Если была цель лапшу сварганить, то — да, будет лапша.
V>Не надо переводить стрелки, это вся индустрия так работает — после babel в реакте всегда лапша.
У тебя — вполне возможно.
Re[24]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>И да, полезность Хрома в кач-ве отладчика react-приложух резко падает, т.к. после babel будет в отладчике неузнаваемая лапша, вместо твоего исходника.
Для начала проясню один момент, который ты в очередной раз себе нафантазировал. Похоже у тебя почему-то создалось впечатление, что у мы там играемся с треугольниками на шейдерах ради показа кнопки. Да, глубоко внутри соответствующей библиотеки оно на самом деле так и происходит, но мы этого всего не видим, т.к. пользуемся исключительно высокоуровневым API классической GUI библиотеки. И да, она естественно написана не нами. Т.е. мы просто перешли с Qt (которая не нужна, если ты не пытаешься писать кроссплатофермнное приложение, выглядящее нативно на каждой из платформ) на другую библиотеку со своей оригинальной прорисовкой (всё равно в браузере нет никаких своих платформенных стандартов и каждый рисует как хочет).
_>>У меня сейчас есть клиентское приложение для браузера, в котором от DOM есть ровно один элемент — один большой canvas и всё. Всё остальное рисуется самим приложением, причём на выходе имеем красивые 3D окна с теням и т.п. украшательствами. При этом список из 10000 элементов прокручивается при 60 fps с нагрузкой процессора в 0,2% (по измерялке браузера). I>Итого- сложность на уровне лабораторной работы курс "основы компьютерной графики" студента второго курса среднего института. Красивости, тени и тд это даже упоминать смешно. I>Чтото навроде пилят люди на курсах "фронтенд за 21 урок", где канвасу посвящается целых 1 или даже 2 занятия.
Ты похоже сильно путаешь просто canvas и webgl. Я подозреваю, что 99% фронтендеров не то что не способны написать подобную библиотеку, а даже банально не знакомы с необходимыми для этого понятиями.
Ты вот сам то знаешь что такое полигональная сетка (mesh), как её сформировать из иерархии контролов и потом прорисовать на шейдерах с наложением текстур? )))
I>Кстати, всего несколько лет назад ты хихикал и стебался с этого канваса, рассказывал какой он весь медленный А теперь ты рассказываешь, какой он быстрый Забавная трансформация, не правда ли?
Ты меня похоже с кем-то путаешь. ) Собственно голый canvas я вообще вряд ли когда-то обсуждал, т.к. там нечего обсуждать. А вот с webgl у меня всегда были хорошие отношения (я даже на этот форум примеры на нём выкладывал несколько лет назад). И да, webgl медленнее десктопных аналогов, но с учётом быстродействия современных видеокарт это можно заметить только на AAA играх и т.п., а вот прорисовка любых возможных интерфейсов не нагрузит современную видеокарту даже на 1%. Ну а для потенциальных AAA-игр (хотя не представляю откуда в них будут загружать сотни гигабайт текстур) и всяких там вычислений (нейросетки и т.п.) сейчас усиленно пилят webgpu (по образу и подобию Vulkan — https://github.com/gfx-rs/wgpu-native).
Кстати, используемая нами GUI библиотечка уже имеет отдельный бэкенд на webgpu, видимо из соображений перфекционизма (т.к. для их целей webgl с головой хватает и ни один пользователь не сможет ощутить улучшение). Но я их в этом поддерживаю и переключусь на этот бэкенд, как только webgpu станет поддерживаться всеми браузерами.
I>Текущий UI, это на 80% смешаный — функциональные элементы пополам с контентом. I>Если же ограничиться только функциональными, то получим UI конца нулевых на MFC или Winforms, и сразу становится ясно, что этот вариант остался давно в прошлом. I>Я напомню — MFC, Winforms, WPF и многие другие вобщем слились, хотя обладали очень крутыми возможностями. То есть, не в крутости дело.
Угу, они все слились в пользу Qt, которая точно такая же, только кроссплатформенная. )))
И ты не путай сайтики (причём оно останется сайтиком, даже если у него за спиной будет крутейший сервер типа яндекса или гугла) и приложения.
I>Какие возможности твоего решения? I> Ты сделал поддержку стилей? Ну что бы по десять раз на неделе сотни мелких фиксов в стилях делать не пересобирая вообще все и не ломая то тут, то там?
Да, вся прорисовка библиотеке полностью управляется стилями — можешь в один клик сделать всем окнам прозрачный фон или розовый и него зелёные кнопки с жёлтым жирным текстом курсивом. Однако у нас за всё время использования ни разу не возникло желания заниматься подобным — дефолтный стиль от разработчиков библиотеки полностью устраивает. Ну и да, стили естественно настраиваются не каким-то мутным текстовым DSL'ем, а нормальной такой жёстко типизированной структуркой.
I> А сколько времени надо, что бы новому кастомеру вообще все стили переделать?
В теории мгновенно. А на практике такого никогда не будет — мы не на аутсорсе и менять что-то по прихоти отдельного клиента не собираемся в принципе.
I> А она на всех девайсах заработает и адекватно смасштабируется?
А вот это по большей части зависит не от используемого инструмента, а от умений конкретных разработчиков интерфейсов. Я видел и отличные и ужасные примеры на эту тему с любыми технологиями. Собственно далеко ходить не надо — зайди на rsdn с телефона и сам всё увидишь... )))
Лично у нас был большой опыт написания приложений (на Qt), работающих под любой экран, так что тут вышло всё хорошо.
I> А можно ли твой компонент встроить как отдельный элемент UI другого приложения, да так, что бы то, другое, могло подменить все стили, лайоут, итд твоего?
Какой ещё компонент? ))) У нас приложение! Ты вот можешь встроить AutoCAD в Photoshop? )))
I> А лайоут у тебя как менять можно? А респонсив умеет? А флексы, флоаты и тд честные?
Все контролы естественно размещаются автоматически и динамически. Т.е. я поверну телефон на 90 градусов и все они тут же автоматически перестроятся под оптимальный размер и позицию. Причём мне для этого ничего делать не надо. всё само. Вообще такие вещи являются нормой в GUI библиотеках уже десяток лет (в Qt всё было тоже самое) и только в мире веб-фронтенда такие простейшие и очевидные вещи до сих пор вызывают вопросы.
I> А какой, собственно, контент оно умеет, кроме твоего захардкоженого списка? Сколько времени ты будешь пилить список, где каждый элемент это кастомная панель, которая может содержать вообще всё — фото, иконка, кнопки, прогрессбар, фрагмент текста, тайтл, футер ? Разумеется, начинка меняется по сотне раз на неделю. Ну вот надо так и всё.
Конечно это высосанный тобой из пальца пример, но почему бы не порассуждать и о таком. Собственно не вижу никаких проблем с реализаций, надо только в начале определиться с тем, в каком формате ты собираешься хранить подобные данные, подготовив соответствующие сериализаторы и десериализаторы в типы твоего языка. И как ты понимаешь, это всё не зависит от используемого средства для отображения (DOM, WebGL или вообще WinAPI), а зависит исключительно от самих данных. А вот имея уже соответствующую иерархию объектов в памяти твоего приложения, можно поговорить о визуализации. И подозреваю, что с помощью, упоминаемой мною, библиотечки это будет гораздо проще, чем с помощью DOM. Во всяком случае полноценный рендер из markdown, находящийся в примерах к библиотеке (там такое классическое приложение с разделённым пополам экраном, слева многострочное поле ввода для markdown, а справа его визуализация), занимает что-то около 150 строчек кода.
I> По таким причинам канвас-UI не прижился — первым делом сам собой вырастает самопальный DOM с самопальным подобием css... I>Попробуй дать внятный ответ на все вопросы выше и станет очевидно. I>Еще 8 лет назад было полно экспериментов на канвасе и было модно пилить уи там. Но не прижилось, по вполне конкретным причинам. I>На самом деле canvas UI кое где используется — там, где нужны в основном фукнкциональные элементы, часто нестандартные. Доля таких случаев крайне невелика. Как только появляется какой то контент, поверх канваса нарастает слой DOM. Типичные рисовалки так и сделаны — контент это дивы поверх канвасного слоя.
Всё оно отлично прижилось (я естественно про WebGL, а не какие-то там DOM поделки, типа голой canvas). ) Просто доля настоящих приложений (но при этом работающих в браузере) пока что ничтожна по сравнению с бесчисленными сайтиками. Поэтому и среди фронтендеров эта тема не особо известна. Но все кому надо, прекрасно в курсе вопроса и с удовольствием используют эту технологию.
Re[27]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, 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. На него переводят даже САПР, офис, итд. И даже в Микрософте. Вот так!
Это нормально — постепенно весь UI кочует в веб и визуализация данных, решений, итд становится все более востребованой.
Похоже, что канвас основательно ускорился. Запустил я софтинку свою, 4 года назад запилил для интересу. На новом хроме, но на том же железе образца 14го года. И вот я вижу, что раньше проц сжирался процентов на 50-80%, а сейчас всего 5. Очень неплохо.
Re[26]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>>>Требуется достаточный письменный у фронтендеров и кое-какой устный, чтобы хоть понимали о чём речь. V>>>Никаких "отличных разговорных "навыков от 99.9% фронтендеров не требуется. I>>Вероятно, это вашей сельской местности так.
V>В Лондоне которая?
Если у вас фронты общаются перепиской, это сельская глубинка, где бы ты ни находился, хоть в силиконовой долине.
Это примерно конец 00х.
I>>У нас фронтенды постоянно коммуницируют с другими людьми: I>>И все это идет как правило на английском.
V>И всё это, как правило, через переписку в JIRA или аналогах, Слаке или аналогах, по почте и т.д. и т.п.
Голосом. Это элементарно — фронт слишком часто становится ботлнеком, т.к. пока ты его не допилишь и не отполируешь, деливерить не получится. А раз так, то и продаж ждать не придется.
А вот переписываться можно бесконечно. Голосом ответы находятся практически сразу.
Отсюда ясно, для чего фронтам английский.
V>>>Потому что никто не интересуется пройденными этапами. I>>Это конкретно ты не интересуешься пройденными этапами
V>Никто.
Еще Гегель сообщил по отрицание отрицания. Это как раз прохождение пройденного.
Например, опыт джуниорства востребован каждый раз, когда ты начинаешь что новое — профессию, проект, домен, стек и тд.
Можно, конечно, "обойти" это — рассказывать всем какой ты крутой, и какие вокруг тебя все тупые. Ну, ты понял
I>>Трансформация профессиональной деятельности это непрерывный процесс, заканчивается только с прекращением этой деятельности. V>Речь была про доходы.
Да я понял, что ты никак не успокоишься с ЗП.
I>>Пройденные этапы никогда не выбрасываются на помойку, это всё опыт который можно и нужно реюзать, в т.ч. опыт джуниорства. V>Я даже представить не могу, что должно случиться, чтобы мне стали интересны доходы джуниоров, чтобы я их прям отслеживал на твой манер.
Да-да, только ЗП хоть чего то значит...
V>До тебя по-прежнему не доходит, что которые плюсовики написали для тебя ноду и продолжают наполнять её библиотеками — они при этом в джуниорство не возвращались.
И это большая проблема — родовые травмы nodejs с этим и связаны, что люди неверно себе представляли разработку на жээсе.
А отсюда крайне кривой системный АПИ, который ухудшает и без того проблемные места. Вот в deno уже гораздо лучше.
V>Обычно так резко меняют стек по одной хорошо известной причине — из-за отсутствия перспектив. V>Ты не сложился как спец на шарпе вот и стал ёрзать пятой точкой в надежде найти что-нить другое, где можно получать хоть что-то.
Здесь снова говорит твоя телепатия. Рядом с тобой случаем зеркала нет? А то выглядит так, будто ты сам с собой говоришь.
V>Звёзд с неба они не хватают, поэтому, твои сылки на топовые ЗП из своей области — это не для тебя ни сегодняшнего, ни для тебя будущего.
Спасибо, буду знать!
V>А ты чаще включаешь глотку. ))
Тут снова телепатия
V>Я говорю про твою нездоровую позицию. V>Это уже даже не клоунада, это клиника.
А монитор то у тебя не глянцевый? Всё больше и больше растет уверенность, что где то у тебя перед носом зеркало
_>Кстати, используемая нами GUI библиотечка уже имеет отдельный бэкенд на webgpu, видимо из соображений перфекционизма (т.к. для их целей webgl с головой хватает и ни один пользователь не сможет ощутить улучшение). Но я их в этом поддерживаю и переключусь на этот бэкенд, как только webgpu станет поддерживаться всеми браузерами.
А что за библиотека и где на нее можно посмотреть?
Здравствуйте, Ikemefula, Вы писали:
V>>И всё это, как правило, через переписку в JIRA или аналогах, Слаке или аналогах, по почте и т.д. и т.п. I>Голосом.
И задачи раздаются голосом? ))
Это даже не нулевые, а 80-е.
I>А вот переписываться можно бесконечно. Голосом ответы находятся практически сразу. I>Отсюда ясно, для чего фронтам английский.
Который у них в среднем хуже по индустрии, т.к. основная часть тех разработчиков как контингент в школе прапоров — в обычный ВУЗ не поступили, в военный тоже, остаётся идти в прапора. И еще во фронте закономерно появились и продолжают в большом кол-ве появляться девушки, что тоже неплохо, ес-но, но тоже о многом говорит.
И еще там много появляется людей, которые переучивались на IT с других специальностей, что опять говорит о том же самом.
I>Еще Гегель сообщил по отрицание отрицания. Это как раз прохождение пройденного.
Просто ты опять передёрнул, а я опять это показал.
Скучно.
I>Например, опыт джуниорства востребован каждый раз, когда ты начинаешь что новое — профессию, проект, домен, стек и тд.
Опытный разработчик видит много того, что уже неоднократно видел, ес-но.
И чем большим кол-вом технологий приходилось оперировать, тем большее де жа вю.
I>Можно, конечно, "обойти" это — рассказывать всем какой ты крутой, и какие вокруг тебя все тупые. Ну, ты понял
Ты не все.
I>>>Трансформация профессиональной деятельности это непрерывный процесс, заканчивается только с прекращением этой деятельности. V>>Речь была про доходы. I>Да я понял, что ты никак не успокоишься с ЗП.
Ну ты же трепыхаешься еще, что можно подумать мы в вакууме живём и у нас нет знакомых, работающих во фронтенде.
I>>>Пройденные этапы никогда не выбрасываются на помойку, это всё опыт который можно и нужно реюзать, в т.ч. опыт джуниорства. V>>Я даже представить не могу, что должно случиться, чтобы мне стали интересны доходы джуниоров, чтобы я их прям отслеживал на твой манер. I>Да-да, только ЗП хоть чего то значит...
Не только.
Слишком далёкий этап карьеры, слишком много было открытий, причём, часто даже не технического плана, бо IT в своей сути слишком социальная весчь.
И это оказывает влияние не только на архитектуру или АПИ систем, но даже на самый банальный код.
И для тебя, по-идее, должно было быть аналогично с "открытиями" в те периоды, ан нет.
Вернее, в какой-то период было, когда ты был любопытен, или даже любознателен.
Но однажды эту часть твоего мышления как отпилили.
Теперь у тебя усвояемость ни к чёрту, обычно это происходит из-за потери интереса к своей профессии.
И скучен ты именно по этой причине и ни по какой другой — из-за нежелания вникать в суть вещей.
Тебе откровенно неинтересно, часто даже до психа в духе "нахрена мне это надо знать???" (по опыту обсуждения с тобой технических вещей когда-то), поэтому ты вечный нуб джуниор.
V>>До тебя по-прежнему не доходит, что которые плюсовики написали для тебя ноду и продолжают наполнять её библиотеками — они при этом в джуниорство не возвращались. I>И это большая проблема — родовые травмы nodejs с этим и связаны, что люди неверно себе представляли разработку на жээсе.
Они не "не представляли", они её реализовали именно такой, какая она есть.
А "представлять" — это теперь твоя обязанность.
I>А отсюда крайне кривой системный АПИ, который ухудшает и без того проблемные места. Вот в deno уже гораздо лучше.
ЧТД, очередная демонстрация нубства — это непонимание тобой причинно-следственных связей.
Т.е. я уже молчу о самой форме постановки вопроса, согласно которому получается, например, что C# первых версий тоже не стоило выпускать, в сравнении с нынешней 9-й.
(даже лень объяснять, почему такая поставновка вопроса — само по себе днище)
Но конкретно async-await появился при тебе, когда ты уже прыгнул на ноду, вот что делает твой пассаж особенно забавным. ))
Т.е. нода была разработана для актуальной на 2009-й версии JS.
Согласно же твоим рассуждениям выходит, что не надо было использовать JS до 2015-го года, когда в нём появился async/await (или даже до 2016-го, когда async/await узаконили в стандарте ES7)?
Кароч, офигенный из тебя "технический обозреватель" получился...
Очередная технология изнасиловала журналиста.
V>>Обычно так резко меняют стек по одной хорошо известной причине — из-за отсутствия перспектив. V>>Ты не сложился как спец на шарпе вот и стал ёрзать пятой точкой в надежде найти что-нить другое, где можно получать хоть что-то. I>Здесь снова говорит твоя телепатия.
Не, это ты так говорил, рассуждая о причинах смены стека.
Ес-но, ты не говорил, что на шарпе у тебя нет перспектив, ты говорил что они у тебя появились со сменой стека, явно не понимая, что именно ты говоришь. ))
V>>Звёзд с неба они не хватают, поэтому, твои сылки на топовые ЗП из своей области — это не для тебя ни сегодняшнего, ни для тебя будущего. I>Спасибо, буду знать!
Да ты и так это знаешь, хосподя.
Ну не принято среди нас, коллег, хвастаться ЗП, заметно большей, чем в среднем по отрасли.
И ты здесь уже не первый год, должен был успеть обратить на это внимание.
Поэтому, рассуждать ты мог лишь о желаемом.
Это не возбраняется, ес-но, но это стоило именно так и подавать, мол, "вот бы и мне так!".
А еще более стоило что-то для этого делать, например, уделить своей професии немного усилий.
V>>А ты чаще включаешь глотку. )) I>Тут снова телепатия
Тут снова галимейшая из всех отмазок — обсуждение-то на месте.
Re[27]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
V>>И опять похер, т.к. рендер-исходники компонент иммутабельны. V>>Это описание нельзя изменять после создания компонента, что кардинально отличается от привычной практики фронтенда. I>И всё мимо
Не мимо, это ты опять слона-то и не заметил.
I>Например, тебе надо правильно организовать работу с эвентами. А раз так, то и методы работы с эвентами никто не отменял. I>Далее — интерграция с 3rd party компонентами, что есть норма. Здесь придется работать с дом, и подсказывать реакту,как всё должно быть на самом деле.
Побегай, побегай.
А мы тут такие дураки сидим и принимаем за чистую монету ту галиматью, что общение с публичными АПИ третьесторонних библиотек хоть как-то должно повлиять на иммутабельность описания компонент реакта и на кардинально иные в итоге принятые в реакте подходы к проектированию GUI.
И вообще на причину принятых таких подходов.
I>Далее, есть кейсы с анимацией. Её стараются заменить на CSS анимацию, но JS анимации так же используется.
Используется через IoC.
I>Тут все через dom.
Через колбэки, мистер вечный джуниор.(С)
В реакте в колбэках устанавливаются св-ва компонент (в т.ч. стили, когда требуется), а не перегенирируется прямо в обработчике события HTML-представление или перестраивается DOM через JS, как эти два способа часто применяют в традиционном лапшеобразном DOM-JS подходе.
Задачей реакта как раз являлось упорядочить всю эту кашу, отделив представление компонент от их модели — это зачем реакт вообще на свет появился.
В том числе после такого отделения упростилось повторное использование компонент, приблизив "дух и стиль" программы на react-е к оным из традиционных десктопных GUI-программ с современными GUI-фреймворками, что резко (даже слишком) отличается от лапшеобразного мейнстримового подхода в современном фронтенде.
И самое главное, react устраняет низкое зацепление кода, присущее традиционному фронтенду, где "код" логических единиц проекта расползается м/у HTML-страницами, JS-скриптами и CSS-файлами. В реакте это всё собрано в единый исходник компонента.
А ты и этого не понял. ))
В реакте они настолько приблизились в архитектуре приложения к обычным GUI-приложениям, что этот способ построения JS-GUI практически скопировали спустя пару лет в react-native для мобилок, где GUI отбражается уже не браузером, а специальным движком, который создаёт нейтивные GUI-элементы платформы.
Т.е. всего-то надо было отделить мух от котлет.
Re[39]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
V>>Если клиент открывает тебе порт, то что угодно на чём угодно можно поотлаживать. I>Очевидно, что нет.
Что именно "нет"?
Ты нам ссышь в уши, что клиент тебе позволяет заходить дебаггером к нему, что уже как минимум необычно.
Но еще более необычным является выдавание этого сценария за уникальный для JS.
I>Я возможности перечислил, а ты никак решение для нативного варианта не покажешь.
Почему я должен показывать, а не ты открыть гугл и поискать по фразе "удалённая отладка"?
RTFM!
I>Похоже, у тебя кроме нападок ничего вобщем и нет
Это скорее удивление, чем нападки, бо даже если ты с нейтивом никогда не работал, то по крайней мере в шарпе, на котором ты сидел кучу лет, удалённая отладка была с рождения.
Ну тогда всё сходится...
Если ты на прошлом стеке не освоил приличной части современных практик IT, то на новом стеке у тебя продолжаются открытия.
Ты, эта... сильно не напрягайся на нынешнем своём стеке, и тогда "открытия" тебе гарантированы на каждом новом. ))
V>>Но я так и не понял, с чего ты решил, что клиент даст тебе доступ к своей машине? I>К его машине мне как раз доступа не надо, в отличие от нативного дебагера, профайлера, сканера. И пермишнов не надо. I>Собственно, всё что мне надо, это глянуть данные, к которым у меня и так доступ есть, обрабатываются в его браузерном движке.
Ой нубство...
Мне нужен доступ, но он мне не нужен.
Чисто для коллег, кому было ранее нелюбопытно, как это делается:
Добавьте входящее правило в брандмауэр Windows:
— Найдите "Windows Firewall" и выберите результат "Windows Firewall"
— В левой части окна панели управления "Windows Firewall" нажмите кнопку "Advanced Settings". Это откроет "Windows Firewall with Advanced Security".
— В древовидном представлении слева нажмите "Inbound Rules"
— В крайнем правом углу нажмите кнопку "New Rule..."
— Выберите "Port" (Нажмите кнопку Далее)
— Выберите TCP и установите "Specific local ports" в 9222 (нажмите кнопку Далее)
— Выберите "Allow the connection" (Нажмите кнопку Далее)
— Выберите доступ к профилю (Домен, Частный, публичный) в соответствии с вашими потребностями (нажмите кнопку Далее)
— Дайте ему имя, например Chrome Remote Debugging (9222) (нажмите кнопку Готово)
— Следуйте инструкциям пользователя 3445047 по переадресации портов :
— Запустите Chrome на хосте Windows:
chrome.exe --remote-debugging-port=9222
И отдельный разговор о том, как пробросить порт, если клиент сидит за NAT-ом (более чем одним) или в VPN, там каждый конкретный случай может быть уникальным, ес-но.
Для контор, сертифицированных по ISO-9000 это или принципиально невозможно, или за письменным обращением к руководству конторы или её отделу безопасности, с подробнейшим расследованием кейза — почему это вообще понадобилось.
V>>Ты, похоже, решил, что удалённая отладка — это изобретение JS. I>Я перечислил возможности, покажи эквивалент для нативной апликачки, который закроет все это.
Ты зазвизделся по самое нимогу, а не "перечислил". ))
Скучно...
Re[37]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
I>Помнится, в прошлый раз ты сокрушался про смерть ActiveX, что де некому будет аутентификацию по УСБ делать. I>Однако же, теперь это делается на жээсе. Да-да
Это делается в драйвере токена, браузеры теперь предоставили доступ к АПИ драйвера.
Разумеется, они должны были это сделать, прежде чем отказываться от старой плагинной подсистемы.
Смотрю, опять у тебя проблемы с причинно-следственными связями...
I>Что бы тебе заменить взрослыми решениями, придется обмазаться тулами по самые нидерланды. Тулы дают тебе и контроль рендеринга, и репл, профайлеры, и сетевой сканер http.
Всё то, что даёт удалённая отладка?
Которая в нейтиве уже лет 20 мало отличается от локальной?
>> А так, всё выше описанное прекрасно работает для любого кода внутри браузера. I>Именно — внутри браузера. Не в нативной апликачке, а внутри браузера.
Который ты назвал "новой ОС"? ))
Тебе осталось открыть для себя, что ср-ва отладки приложений отродясь встроены в нейтивные ОС.
На основе низкоуровневого АПИ работают как локальные дебаггеры, так и "дебаггеры как сервисы", к которым пофик как коннектиться — локально или удалённо, бо он на одни и те же запросы будет выдавать одинаковые ответы, независимо от канала, по которому с ним общаются.
I>Понятно ли тебе, друг, что твой руст в виде веб-ассембли не является нативным приложением?
С т.з. того приложения оно просто выполняется в чуть другой "ОС" со своим АПИ.
Но это классика нейтивной разработки в любом случае.
Здравствуйте, Ikemefula, Вы писали:
I>Сначала ты утверждаешь, что де canvas это классный инструмент для UI, и приводишь целый пример с 3д тенями.
Только не canvas, а WebGL — если уж пытаешься цитировать, то делай это точно.
I>После этого выясняется, что на самом деле вы используете какую то 3d party библиотеку о которой ты не сказал ни слова. I>Может тебе поработать над аргументацией?
Ну так эта библиотека и рисует GUI с помощью WebGL в одинокий canvas, из которого и состоит вся html страница (и страница тоже единственная естественно).
И мне вообще странно представить, что кто-то (ну естественно кроме авторов соответствующих библиотек) мог подумать об идее рисовать кнопочки руками — это уж слишком стандартная в индустрии задача, чтобы плодить свои велосипеды в прикладных приложениях, вместо использования готовых библиотек.
_>> Ты похоже сильно путаешь просто canvas и webgl. I>Трудно понть о чем ты пишешь, если у тебя canvas и 3д тени как основной аргумент. I>Ну вебгл, и что с того? I>Само по себе это низкоуровневый движок рендеринга, без высокоуровневой либы ничего интересного не происходит.
Эммм, WebGL — это вообще не движок. ))) Это просто бальный доступ для твоего кода к видеокарте пользователя и всё. Слегка устаревший (где-то на уровне 2010-го года), но для целей GUI и этого даже много. Т.е. этот API просто позволяет твоему коду быть наравне (ну почти) с декстопным и всё. Ну а уж воспользуешься ты этой возможностью или нет — уже твой выбор...
И кстати, насчёт низкоуровневости. Мы используем в одном месте и непосредственно сам WebGL (да, те самые шейдеры, текстуры и т.п.), но не для прорисовки элементов GUI, а как раз для того, что ты называешь контентом (в нашем случае это специальным образом обработанное реалтаймовое видео). А уже поверх этого библиотечка рисует всякие свои всплывающие окошки с кнопками и т.п.
I>Тут есть большая разница I>Скажем, от канваса требуется максимальный перформанс. I>От либы UI требуется максимальная продуктивность специализированного разработчика. React тот же вполне себе справляется с этой задачей и не требует многих лет втыкания в QT, с++ и webql I>Сам реакт или, скажем, только jsx можно без проблем использовать с другим рендерером, хоть в 2d, 3d графику или в *.txt или консольный скрин
А с этим всем разве кто-то спорил? ) Я этот ваш React никогда не видел, но вполне допускаю, что это очень удобная для разработчика GUI библиотека.
I>Вобщем, трудо понять, что ты хочешь сказать.
Вообще то я всего лишь отреагировал на твоё утверждение, что в браузере кроме как в DOM рендерить больше некуда. Как видишь есть куда, причём там ещё и в разы больше возможностей.
I>Я ведь обычный человек, а не какой нибудь vdimas, который, с его слов, всё знает лучше всех. Я опираюсь на твои слова — ты сказал, что де у фронтов есть супер-пупер-мега-классный инструмент — канвас, а они пользуются HTMl/CSS/DOM. I>Странно, что вашим супер-пупер-мега-классным инструментом пользуется ничтожное количество людей. I>Парадокс! И конечно же у тебя объяснение в том, что фронтенды они того, недалёкие, не знают своего щастя!
Да ладно бы просто не использовали. В конце концов работа с подобными API — это специфика разработчиков или GUI библиотек или игровых движков или каких-то особенных случаев (как у нас например). Но ведь судя по твоей цитате, вообще даже не знают о существование такой возможности!
Если по аналогии, то это как если бы разработчик под Винду в 2000-ых не знал бы о возможности отрисовки через DirectX.
I>>>Я напомню — MFC, Winforms, WPF и многие другие вобщем слились, хотя обладали очень крутыми возможностями. То есть, не в крутости дело. _>>Угу, они все слились в пользу Qt, которая точно такая же, только кроссплатформенная. ))) I>Смешной аргумент. Сейчас 90% UI это бразерный на HTML/CSS/JS, а остальное примерно поравну делится межжу I>1. джава I>2. дотнет I>3. всякие иос и макос придумки I>и где то на грани статистической погрешности будут всякие QT
Web безусловно впереди, но совсем не из-за качества библиотек (тут скорее всё наоборот и мир фронтенда всегда был пугалом в остальном IT), а исключительно из-за другой (гораздо более удобной) схемы распространения и установки ПО. Собственно лично я сам являюсь живой демонстрацией этого. Однако не все приложения могут себе такое позволить, так что в определённых областях ещё долго будет необходим десктопный/мобильный GUI. И вот тут уже царит или вообще нечто самописное (могут позволить себе особо жирные конторы, т.к. там надо под каждую ОС отдельно писать) или же Qt. А все остальные как раз та самая статистическая погрешность... )))
I>Это значит, что вы занимаетесь узкоспециализированой работой, раз у вас не вожникают типичные для фронтенда задачи.
Просто слово фронтенд сейчас относят к любой веб-морде, будь то сайт-визитка или запускаемый в браузере CAD. Хотя это принципиально разные задачи, требующие абсолютно разных подходов. Заниматься украшательствами на сайтах — это действительно нормально. А вот заниматься таким же в приложениях...
I>>> А сколько времени надо, что бы новому кастомеру вообще все стили переделать? _>>В теории мгновенно. I>Это или понты, или ложь — ну не бывает мгновенного набора текста. Вам присылают желаемую картинку, а вы должны вписать все шрифты, цвета, отступы, итд и тд.
Ой, да не цепляйся ты так по глупому к мелочам, сам же от этого смешно выглядишь. Думаю всем очевидно, что забить значения в подготовленные поля — это в контексте разработки означает мгновенное изменение.
>>А на практике такого никогда не будет — мы не на аутсорсе и менять что-то по прихоти отдельного клиента не собираемся в принципе. I>Аутсорс здесь ни при чем — кастомизация это форма продажи нашего продукта. Например, если продаёшь китайцам или японцам, для них придется постараться, или твой продукт никто из них не купит.
Тогда это скорее будет прихоть нашего специалиста по Китаю/Японии, а не клиента, да и то будет выполнена один раз в жизни. Самое забавное, что у меня тут даже есть такой специалист (точнее специалистка), но что-то по GUI от неё никаких советов пока не было. Пока в основном советы о том, что лучше дарить при встречах и т.п. )))
_>>Все контролы естественно размещаются автоматически и динамически. Т.е. я поверну телефон на 90 градусов и все они тут же автоматически перестроятся под оптимальный размер и позицию. Причём мне для этого ничего делать не надо. всё само. Вообще такие вещи являются нормой в GUI библиотеках уже десяток лет (в Qt всё было тоже самое) и только в мире веб-фронтенда такие простейшие и очевидные вещи до сих пор вызывают вопросы. I>Это же очевидно — при изменении ориентации UI должен выглядеть так, как решил дизайнер, а не так, как считает либа. I>И эти правила нужно описать.
Ты похоже или реально не знаешь как автоматически размещаются контролы во всех GUI библиотеках уже лет 15-20 или же просто придуриваешься. )))
>> Собственно не вижу никаких проблем с реализаций, надо только в начале определиться с тем, в каком формате ты собираешься хранить подобные данные, подготовив соответствующие сериализаторы и десериализаторы в типы твоего языка. I>Как все сложно то. А всех делов — описать xml-подобным языком элементы карточки и прописать стили. А вот дальше нужно смотреть ,как это хранить, т.к. взаимодействие с этой карточкой может иметь массу вариантов, в зависимости от придумки дизайнера. Нет взаимодействия — храним в обычном JSON в плоском виде. Отсюда ясно, что серилизация, десерилизация перед нами вообще не стоит — это тривиальная часть задачи, которую даже упоминать не стоит.
Я правильно понимаю, что ты предлагаешь не трансформировать данные в свои прикладные типы, а использовать в приложение то, что выплюнет xml парсер? Понятно, понятно... ))) Ну да ладно, пускай даже так, это же у нас не реальная архитектура, а умозрительный пример на тему GUI. Так вот, не вижу никаких проблем в визуализации при таких данных. Просто делаем цикл по всем элементам, в котором для каждого xml узла добавляем его прорисовку, в зависимости от значения атрибута "тип" (в большинстве случае в виде просто одного соответствующего контрола из библиотечки). Могу за 20 секунд накидать код прямо форуме. ))) И где обещанная "страшная" сложность задачи? )))
_>>Всё оно отлично прижилось (я естественно про WebGL, а не какие-то там DOM поделки, типа голой canvas). ) Просто доля настоящих приложений (но при этом работающих в браузере) пока что ничтожна по сравнению с бесчисленными сайтиками. I> "доля ничтожна" означает "не прижился" I>А вот html/css/dom именно что прижился, т.к. его сейчас по скромной оценке процентов 90. На него переводят даже САПР, офис, итд. И даже в Микрософте. Вот так!
Ну как бы и фронтендеры в целом тогда тоже не прижились на этой планете, потому как их на порядки меньше таксистов...
Re[38]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, alex_public, Вы писали:
_>Т.е. браузер действительно уже стал платформой (как ОС), но буквально несколько лет назад и платформа эта пока крайне убогая и ограниченная. Хотя видно, что идёт активное развитие и когда-нибудь все нужные API добавят.
Т.е., можно использовать wasm как нейтивную VM-абстракцию от конкретной ОС.
(чего не хватает проекту LLVM и вряд ли там будет реализовано)
Думаю, в пределе это приведёт к тому, что не браузер будет эдакой виртуальной ОС, а именно wasm-машинка, где браузер будет пользоваться сервисами той.
Это полезно даже для облака, т.к. wasm-приложениям будет немного пофик, какая именно OS установлена на облачной ноде.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>А что за библиотека и где на нее можно посмотреть?
V>Для rust-а их всего пяток, и они все в чём-то похожи. ))
Так хотел получить рекомендацию чего-то конкретного, проверенного в боевых условиях.
Идея избавиться от HTML и все сделать на канвасе мне представляется здравой, но пока я только у flutter видел что-то не совсем убогое.
(И то там гибрид canvas c html и он настолько глючный, что использовать это в продакшене я бы не рискнул. По крайней мере 2-3 месяца назад, когда я смотрел примеры было так)
Здравствуйте, Ikemefula, Вы писали:
I>Сначала ты утверждаешь, что де canvas это классный инструмент для UI
Из JS-скрипта — медленный.
I>и приводишь целый пример с 3д тенями.
Скорее всего, речь шла о WebGL, а там такой же точно АПИ OpenGL (в спецификации ES) и такой же язык шейдеров, какой используется в графике везде — от десктопов, до игровых приставок и мобилок, т.е. ничего специфичного именно для веба.
И это было одно из самых грамотных решений, ИМХО, — перестать, наконец, изобретать для веба анально-огороженные технологии, типа как разработали когда-то JS.
То бишь, код самого браузера общается с отображаемым точно так же и с той же эффективностью, как обращается с ним код из webasm.
I>После этого выясняется, что на самом деле вы используете какую то 3d party библиотеку о которой ты не сказал ни слова.
Это не имеет никакого значения, когда используются открытые и популярные стандарты.
Библиотек GUI под OpenGL сейчас полно.
I>Трудно понть о чем ты пишешь, если у тебя canvas и 3д тени как основной аргумент.
Вам говорится, что есть инструмент, который может всё и быстро.
А "быстро" с т.з. мобилок — это потратить меньше энергии батарейки.
I>Ну вебгл, и что с того? I>Само по себе это низкоуровневый движок рендеринга, без высокоуровневой либы ничего интересного не происходит.
Нейтивные "высокоуровневые либы" там относительно тоненькие, т.к. OpenGL ES уже сама по себе помощнее чем, например, Windows GDI подсистема, поверх которой была когда сделана классическая оконная подсистема User32, которая тоже, в общем-то, довольно "тонкая" и даже неплохо работала на технике 30-тилетней давности.
I>Тут есть большая разница I>Скажем, от канваса требуется максимальный перформанс.
А толку от быстродействия самого канваса, если каждый вызов из JS в него дорогой?
Заколебешься заряжать батарейку. ))
I>От либы UI требуется максимальная продуктивность специализированного разработчика.
В нейтивных технологиях это не сложнее реакта, бо реакт унаследовал подход нейтивных библиотек.
I>Я ведь обычный человек, а не какой нибудь vdimas, который, с его слов, всё знает лучше всех.
Обладает некоторой эрудицией в тех темах, в которых участвует.
Чего и вам советую — не пытаться участвовать во всех подряд обсуждениях.
I>Странно, что вашим супер-пупер-мега-классным инструментом пользуется ничтожное количество людей.
А что странного?
Эти стандарты веба относительно молоды.
I>Парадокс! И конечно же у тебя объяснение в том, что фронтенды они того, недалёкие, не знают своего щастя!
Фронтендами пока заткнули вакуум, образовавшийся после удаления из браузеров старой плагинной системы.
I>Смешной аргумент. Сейчас 90% UI это бразерный на HTML/CSS/JS
Да фиг там.
Из мобилок в браузеры почти никогда не ходят, там пользуются мобильными приложениями.
Facebook — это react-native, не имеет ничего общего с HTML.
Инстаграмм, VK и т.д. тоже к HTML отношения не имеют.
Приложение Ютуб на мобилке написано на родных технологиях — т.е. на Джаве на Андроиде и на Obj-C на iOS.
Камеры, звонилки, фото/видео/ауди редкторы — это все во многом нейтивные приложухи на каждой платформе.
И т.д. и т.п.
А на чём сделан миллион свистелок, которымы никто не пользуется — да какая разница?
I>а остальное примерно поравну делится межжу
Оставь эти насосы из пальца себе. ))
Классический Web больше пользуют из десктопа, но декстоп, по заверениям того же НС, медленно но верно умирает.
_>>И ты не путай сайтики (причём оно останется сайтиком, даже если у него за спиной будет крутейший сервер типа яндекса или гугла) и приложения. I>Ну да, надо только исключить неудобные для тебя факты.
Скорее, неудобные для тебя.
Бо из мобилок, действительно, на сайты почти никогда не ходят.
I>Это значит, что вы занимаетесь узкоспециализированой работой, раз у вас не вожникают типичные для фронтенда задачи.
Термин "фронтенд" закрепился за связкой HTML+CSS+JS, т.е. обвинять кого-то, что у него "не возникают типичные для фронтенда задачи" — немного забавно.
Давай рассуждать о типичных задачах GUI.
I>>> А сколько времени надо, что бы новому кастомеру вообще все стили переделать? _>>В теории мгновенно. I>Это или понты, или ложь
Да нет, стили в относительно новых GUI-либах отделяют в отдельно-обслуживаемую сущность изначально при разработке таких библиотек.
Причём, если стили CSS в HTML используются в т.ч. для лейаута, видимости-невидимости, привязки координат и т.д., то в нейтивных приложениях стили используются только для управления темами, а не еще лейаутом. Т.е. мухи от котлет отделены.
I>ну не бывает мгновенного набора текста. Вам присылают желаемую картинку, а вы должны вписать все шрифты, цвета, отступы, итд и тд.
"отступы" ))
_>>Лично у нас был большой опыт написания приложений (на Qt), работающих под любой экран, так что тут вышло всё хорошо. I>Звучит так, как будто вы художника сделали маляром
Ну, "порог вхождения" в GUI в нейтивной разработке тоже сильно упал с середины 90-х...
I>Для веба, например, цельное приложение можно показывать из под другого сайта. Безо всяких COM, ActiveX и прочих чудес. I>И выглядит гладко, что не видна граница.
Webasm этого тоже не запрещает.
Но опять выглядит, что уже не знаешь, что бы такое сказать в ответ. ))
_>>Все контролы естественно размещаются автоматически и динамически. Т.е. я поверну телефон на 90 градусов и все они тут же автоматически перестроятся под оптимальный размер и позицию. Причём мне для этого ничего делать не надо. всё само. Вообще такие вещи являются нормой в GUI библиотеках уже десяток лет (в Qt всё было тоже самое) и только в мире веб-фронтенда такие простейшие и очевидные вещи до сих пор вызывают вопросы. I>Это же очевидно — при изменении ориентации UI должен выглядеть так, как решил дизайнер, а не так, как считает либа.
Ес-но, либа только даёт для этого инструмент, например, политики лейаута.
I>И эти правила нужно описать.
Ничего себе!
I>Судя по ответам выше, вам дизайнер или ничего не присылает, или его хотелки весьма пространные. Ну или UI тривиальный. Ну много строчек в списке, и что? А сложность то в чем заключается ? Ты молчишь, как партизан, рассказываешь только какие то странные подробности I>- 3д тени I>- красивости I>- 10000 элементов в списке I>- вебгл I>- крутая либа I>- огого I>- агага I>- у нас много опыта в QT и С++ I>Вобщем, это всё ни о чем.
Из навозной кучи весь мир кажется г-ном.
>> Собственно не вижу никаких проблем с реализаций, надо только в начале определиться с тем, в каком формате ты собираешься хранить подобные данные, подготовив соответствующие сериализаторы и десериализаторы в типы твоего языка. I>Как все сложно то. А всех делов — описать xml-подобным языком элементы карточки
Уже бугага.
I>Отсюда ясно, что серилизация, десерилизация перед нами вообще не стоит — это тривиальная часть задачи, которую даже упоминать не стоит.
Для утиной типизации? — ес-но. ))
Поэтому заряд батарейки так быстро и заканчивается.
_>>Всё оно отлично прижилось (я естественно про WebGL, а не какие-то там DOM поделки, типа голой canvas). ) Просто доля настоящих приложений (но при этом работающих в браузере) пока что ничтожна по сравнению с бесчисленными сайтиками. I> "доля ничтожна" означает "не прижился"
Выводы надо делать не по снапшоту, а по динамике.
А динамика такова, что все более-менее популярные веб-ресурсы зеркалят свою функциональность через мобильные приложения.
А webasm умеет работать и без браузера.
I>А вот html/css/dom именно что прижился
Не прошло и 25-ти лет, верно? ))
И то, "прижился" из-за того, что выкинули альтернативные технологии из браузеров.
А которую добавили — та еще совсем юная.
В общем, забавно, что ты смотришь более в прошлое, чем в будущее.
I>т.к. его сейчас по скромной оценке процентов 90.
Очередная твоя чушь. ))
Мобильные приложения используются чаще серфинга через браузеры, поэтому, оценка доли HTML будет менее 40% от всего показываемого в каждый момент времени GUI одновременно на всех в мире включенных устройствах с экраном.
I>На него переводят даже САПР, офис, итд. И даже в Микрософте. Вот так!
Но документы офиса продолжают набивать из локальных приложений, а сетевая инфраструктура используется более как хранилище с навигацией.
Re[31]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Евгений Акиньшин, Вы писали:
V>>Для rust-а их всего пяток, и они все в чём-то похожи. )) ЕА>Так хотел получить рекомендацию чего-то конкретного, проверенного в боевых условиях.
Там все либы в бете или альфе.
Пользоваться такими либами можно только в исходниках, чтобы иметь возможность исправлять/допиливать код.
Думаю, пока рекомендации спрашивать рано.
Опять же, рекомендации лучше делать по результату сравнения либ, а не использования какой-то одной.
ЕА>Идея избавиться от HTML и все сделать на канвасе мне представляется здравой, но пока я только у flutter видел что-то не совсем убогое.
Но Flutter пока не перевели на wasm и не переведут до тех пор, пока в wasm не встроят GC, иначе каждое приложение потянет в wasm VM еще одну свою VM, как это делает Blazor. ))
ЕА>(И то там гибрид canvas c html и он настолько глючный, что использовать это в продакшене я бы не рискнул. По крайней мере 2-3 месяца назад, когда я смотрел примеры было так)
Ты имеешь ввиду dart2js?
Я вообще считаю, что дёргать канвас из JS — плохая идея, бо жрёт батарейку.
Re[25]: MS забило на дотнет. Питону - да, сишарпу - нет?
Right now source mapping is only working between uncompressed/combined JavaScript to compressed/uncombined JavaScript, but the future is looking bright with talks of compiled-to-JavaScript languages
Может у тебя экран глянцевый? Это могло бы объяснить многие аспекты.
Забавная трансформация, не правда ли?
"доля ничтожна" означает "не прижился"
