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

S>А DOM прекрасно строится и через мост JS. Это не большая проблема

Если надо на каждый чих делать JS-прокси, то проще уже сразу на JS писать, и WASM не нужен.

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

V>Здравствуйте, Евгений Акиньшин, Вы писали:

V>>>Для rust-а их всего пяток, и они все в чём-то похожи. ))
ЕА>>Так хотел получить рекомендацию чего-то конкретного, проверенного в боевых условиях.

V>Там все либы в бете или альфе.

alex_public говорит о уже существующем проекте. Хотелось бы посмотреть.

V>Думаю, пока рекомендации спрашивать рано.
V>Опять же, рекомендации лучше делать по результату сравнения либ, а не использования какой-то одной.


V>Но Flutter пока не перевели на wasm и не переведут до тех пор, пока в wasm не встроят GC, иначе каждое приложение потянет в wasm VM еще одну свою VM, как это делает Blazor. ))

Пусть тянет, мне не жалко. С блазором проблема, что VM сыроватая и тормозная пока.

V>Ты имеешь ввиду dart2js?
V>Я вообще считаю, что дёргать канвас из JS — плохая идея, бо жрёт батарейку.

Да, насколько я понял там трансляция в js. Но там багов хватает и без учета производительности\батарейки.

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

V>Здравствуйте, Константин Б., Вы писали:

КБ>>https://developer.chrome.com/docs/devtools/javascript/source-maps/
КБ>>И оно работает настолько автоматически, что любой кто хотя бы трогал краешек фронтенда за последние 10 лет об этой штуке знает

V>Разве?
V>

V>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

Published: March 21st, 2012

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

УП>Здравствуйте, Serginio1, Вы писали:

S>>А DOM прекрасно строится и через мост JS. Это не большая проблема

УП>Если надо на каждый чих делать JS-прокси, то проще уже сразу на JS писать, и WASM не нужен.
Ну там не каждый чих. Модель строится в Блазоре, сериализуется в json, а JS дергается уже для отображения данных.
Смысл блазора в единой модели классов на клиенте и сервере и кодовая база.
Например в 1С очень удобно в одном коде писать как клиентскую так и серверную часть.
Для классов можно применять условную компиляцию. Что то только на клиенте, что только на сервере, а есть и общая часть.
Уменьшает затраты на программирование и отладку

Здравствуйте, Евгений Акиньшин, Вы писали:

V>>>>Для rust-а их всего пяток, и они все в чём-то похожи. ))
ЕА>>>Так хотел получить рекомендацию чего-то конкретного, проверенного в боевых условиях.
V>>Там все либы в бете или альфе.
ЕА>alex_public говорит о уже существующем проекте. Хотелось бы посмотреть.

На их проект посмотреть?
Я бы тоже не отказался, если есть ссылка на демо.
А если их проект еще в активной разработке, в стадии беты или ранее, то никто ничего показывать не будет, бо не говори гоп, как грится... примета плохая. ))


V>>Но Flutter пока не перевели на wasm и не переведут до тех пор, пока в wasm не встроят GC, иначе каждое приложение потянет в wasm VM еще одну свою VM, как это делает Blazor.
ЕА>Пусть тянет, мне не жалко. С блазором проблема, что VM сыроватая и тормозная пока.

Ага.
А потом Blazor будут переделывать, если/когда в wasm добавят GC.

Здравствуйте, vdimas, Вы писали:
V>Ага.
V>А потом Blazor будут переделывать, если/когда в wasm добавят GC.
Угу и GC и DOM. Вопрос когда? https://github.com/WebAssembly/gc

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

S>Большое спасибо. Вот такое соотношение пользы к объёму участия в топике я могу только приветствовать.
S>Моё незнание инструмента напрямую связано с тем, что сам я на плюсах ничего не писал (и практически ничего не читал) с начала 2000х.

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

Но когда указываешь конкретную ссылку для скачивания зависимостей, то в этой ссылке версия обычно вшита жёстко, в то время как пакетные менеджеры позволяют указывать условия, например, "старше версии X.Y.0, но младше или равно X.Y.42", ведь мы пишем под зоопарк, где одновременно входу кучи версий одной и той же либы, например, OpenSSL. Такого рода зависимости Bazel не обслуживает.
https://github.com/openssl/openssl/issues/3840
https://github.com/bazelbuild/bazel/issues/11685

Т.е. сложно подхватить уже имеющуюся "родную" либу на целевых линухах.
Вместо этого Bazel предлагает то, что он может — скачать некую конкретную версию этой либы с github, но тогда её нужно собрать в виде статической либы, т.е. подключить её тело в проект, а не пользовать уже имеющуюся на машине DLL или SO.

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

_>И мне вообще странно представить, что кто-то (ну естественно кроме авторов соответствующих библиотек) мог подумать об идее рисовать кнопочки руками — это уж слишком стандартная в индустрии задача, чтобы плодить свои велосипеды в прикладных приложениях, вместо использования готовых библиотек.

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

I>>Ну вебгл, и что с того?
I>>Само по себе это низкоуровневый движок рендеринга, без высокоуровневой либы ничего интересного не происходит.

_>Эммм, WebGL — это вообще не движок. ))) Это просто бальный доступ для твоего кода к видеокарте пользователя и всё.

Джижок, engine, это настолько широкий термин, что крайне странно к этому придираться.
API рендеринга вполне себе подходит под термин "движок"

_>И кстати, насчёт низкоуровневости. Мы используем в одном месте и непосредственно сам WebGL (да, те самые шейдеры, текстуры и т.п.), но не для прорисовки элементов GUI, а как раз для того, что ты называешь контентом (в нашем случае это специальным образом обработанное реалтаймовое видео). А уже поверх этого библиотечка рисует всякие свои всплывающие окошки с кнопками и т.п.

Все как я и говорил — экзотический случай, никаких шансов интеграции с другими системами/компонентами.

_>Вообще то я всего лишь отреагировал на твоё утверждение, что в браузере кроме как в DOM рендерить больше некуда. Как видишь есть куда, причём там ещё и в разы больше возможностей.

Тут надо только добавить, что я нигде такого не писал.

I>>Парадокс! И конечно же у тебя объяснение в том, что фронтенды они того, недалёкие, не знают своего щастя!

_>Но ведь судя по твоей цитате, вообще даже не знают о существование такой возможности!

Ты снова приписл мне абы что, читай сам:

На самом деле canvas UI кое где используется — там, где нужны в основном фукнкциональные элементы, часто нестандартные. Доля таких случаев крайне невелика. Как только появляется какой то контент, поверх канваса нарастает слой DOM. Типичные рисовалки так и сделаны — контент это дивы поверх канвасного слоя.

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

_>Web безусловно впереди, но совсем не из-за качества библиотек (тут скорее всё наоборот и мир фронтенда всегда был пугалом в остальном IT), а исключительно из-за другой (гораздо более удобной) схемы распространения и установки ПО.

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

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

_>Просто слово фронтенд сейчас относят к любой веб-морде, будь то сайт-визитка или запускаемый в браузере CAD. Хотя это принципиально разные задачи, требующие абсолютно разных подходов. Заниматься украшательствами на сайтах — это действительно нормально. А вот заниматься таким же в приложениях...

Украшательства это твои 3д тени. А вот соответствие UX дизайну — это совсем другая вещь.

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

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

Ога, перейти к респозив дизайну или сменить дизайн это совсем не "забить значения в подготовленые поля"
Лично у меня есть сомнение, что ваша либо позволит любо вариант дизайна применить за короткое время.
Любой — это значит вообще любой. Пришел новый дизайнер и начал ваять всё с нуля.

I>>Это же очевидно — при изменении ориентации UI должен выглядеть так, как решил дизайнер, а не так, как считает либа.
I>>И эти правила нужно описать.
_>Ты похоже или реально не знаешь как автоматически размещаются контролы во всех GUI библиотеках уже лет 15-20 или же просто придуриваешься. )))

В том то и проблема — устарело на 15-20 лет. Вы UX привязали к либе, а в реальном мире ровно наоборот — UX определяет вообще все.
Например, дизайнер показывает совсем другое размещение, при чем изменения будут под конкретного заказчика.
Твои действия? Будешь говорить дизайнеру, что ваша либа по другому не умеет?

_>Я правильно понимаю, что ты предлагаешь не трансформировать данные в свои прикладные типы, а использовать в приложение то, что выплюнет xml парсер?

Очевидно, что это не так Не надо никакой трансформации в свои прикладные типы. И использовать xml тоже не надо. Это устаревшие подходы.
Современный подход — UI определяет API и данные. Отсюда ясно, что избавляемся от лишних приседаний сравнивая UI 10 и 20 летней давности.
Схема взаимодействия проще, API проще, данные проще, стейтменеджмент гораздо более эффективный.

> Понятно, понятно... )))

Телепатия, однако.

> Ну да ладно, пускай даже так, это же у нас не реальная архитектура, а умозрительный пример на тему GUI. Так вот, не вижу никаких проблем в визуализации при таких данных. Просто делаем цикл по всем элементам, в котором для каждого xml узла добавляем его прорисовку, в зависимости от значения атрибута "тип" (в большинстве случае в виде просто одного соответствующего контрола из библиотечки). Могу за 20 секунд накидать код прямо форуме. ))) И где обещанная "страшная" сложность задачи? )))

Успокойся — xml это рудимент времен начала-конца нулевых.

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

_>Ну как бы и фронтендеры в целом тогда тоже не прижились на этой планете, потому как их на порядки меньше таксистов...

Забавно, что ты съехал с темы. Речь то была про долю канвас UI во фронтенде.

Про такси — фронтендов не меньше чем таксистов. По крайней мере в нашей стране. И это при том, что такси у нас довольно популярная профессия.
На самом деле ёмкость рынка труда в такси гораздо ниже емкости рынка труда в IT.
Это никакой не парадокс — рынок IT растет очень быстро и значительная часть этого роста это тот самый фронтенд. А вот такси не растет нисколько, количество машин привязано к средней ЗП в стране и количеству населения. Тут ситуация меняется крайн слабо.

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

V>Чисто для коллег, кому было ранее нелюбопытно, как это делается:
V>

V>- Запустите Chrome на хосте Windows:

V>chrome.exe --remote-debugging-port=9222

Неверно. Ничего этого не нужно да и под условие не подходит. И ты забыл — я тебя просил показывать нативную отладку. Никак условие не прочтешь?

V>Для контор, сертифицированных по ISO-9000 это или принципиально невозможно, или за письменным обращением к руководству конторы или её отделу безопасности, с подробнейшим расследованием кейза — почему это вообще понадобилось.

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

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

V>В реакте они настолько приблизились в архитектуре приложения к обычным GUI-приложениям,

Не в реакте, а в single page application Это началось задолго до реакта. Скажем, SPA на Ext.js это практически обычное десктоп приложение.

> что этот способ построения JS-GUI практически скопировали спустя пару лет в react-native для мобилок, где GUI отбражается уже не браузером, а специальным движком, который создаёт нейтивные GUI-элементы платформы.

Не только для мобилок, еще и для десктопа, и даже не на жээс.

Собственно, ты плавно уперся носом в тот самый экспорт который секундой ранее отрицал

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

V>И задачи раздаются голосом? ))
V>Это даже не нулевые, а 80-е.

Задачи сначала обсуждаются, что бы все были в курсе, у кого какие ожидания, планы и тд.
Собственно это современный аджайл — митинги, митинги, митинги. И это всё голосом.
Похоже, у вас по старинке почтой. Надеюсь, не бумажной?

I>>А вот переписываться можно бесконечно. Голосом ответы находятся практически сразу.
I>>Отсюда ясно, для чего фронтам английский.

V>Который у них в среднем хуже по индустрии, т.к. основная часть тех разработчиков как контингент в школе прапоров — в обычный ВУЗ не поступили, в военный тоже, остаётся идти в прапора. И еще во фронте закономерно появились и продолжают в большом кол-ве появляться девушки, что тоже неплохо, ес-но, но тоже о многом говорит.

Это снова про твою специфику.

I>>Да я понял, что ты никак не успокоишься с ЗП.
V>Ну ты же трепыхаешься еще, что можно подумать мы в вакууме живём и у нас нет знакомых, работающих во фронтенде.

С твоих слов получается так, что вы фронтов или в рабстве держите с 00х или у вас их нет.
У вас они и ЗП не получают, и по английски не говорят

I>>Да-да, только ЗП хоть чего то значит...

V>Теперь у тебя усвояемость ни к чёрту, обычно это происходит из-за потери интереса к своей профессии.
V>И скучен ты именно по этой причине и ни по какой другой — из-за нежелания вникать в суть вещей.

Телепатия

I>>И это большая проблема — родовые травмы nodejs с этим и связаны, что люди неверно себе представляли разработку на жээсе.

V>Они не "не представляли", они её реализовали именно такой, какая она есть.

Это называется "сначала сделали а потом подумали"

V>Согласно же твоим рассуждениям выходит, что не надо было использовать JS до 2015-го года, когда в нём появился async/await (или даже до 2016-го, когда async/await узаконили в стандарте ES7)?

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

I>>Здесь снова говорит твоя телепатия.

V>Не, это ты так говорил, рассуждая о причинах смены стека.
V>Ес-но, ты не говорил, что на шарпе у тебя нет перспектив, ты говорил что они у тебя появились со сменой стека, явно не понимая, что именно ты говоришь. ))

Снова телепатия. Я то помню, что именно говорил, а ты это все выдумал.

V>Поэтому, рассуждать ты мог лишь о желаемом.

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

V>Тут снова галимейшая из всех отмазок — обсуждение-то на месте.

Покажи цитатой

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

V>>Чисто для коллег, кому было ранее нелюбопытно, как это делается:
V>>

V>>- Запустите Chrome на хосте Windows:
V>>chrome.exe --remote-debugging-port=9222

I>Неверно. Ничего этого не нужно

Для подключения к соседней машине в подсетке не нужно...
А через глобальный интернет если — нужно аж бегом.


I>да и под условие не подходит.

Кому какое дело до надуманных условий?


I>И ты забыл — я тебя просил показывать нативную отладку. Никак условие не прочтешь?

Я не забыл — ты утверждал, что в нейтиве нет удалённой отладки.
(Вернее, приводил в пример удалённую отладку клиентского HTML/DOM как некий образец того, чего нет в других технологиях)

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


V>>Для контор, сертифицированных по ISO-9000 это или принципиально невозможно, или за письменным обращением к руководству конторы или её отделу безопасности, с подробнейшим расследованием кейза — почему это вообще понадобилось.
I>Для нативной отладки так и есть.

Для твоей отладки тоже.


I>Спасибо за аргумент в мою пользу

Это аргумент в пользу твоего невежества.
Походу, ты "удалённо" отлаживался только у коллеги в собственной подсетке.
А теперь шаблончик треснул...
Я же говорю — зазвизделся.

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

V>>В реакте они настолько приблизились в архитектуре приложения к обычным GUI-приложениям,
I>Не в реакте, а в single page application

Хрен там.


I>Это началось задолго до реакта. Скажем, SPA на Ext.js это практически обычное десктоп приложение.

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


>> что этот способ построения JS-GUI практически скопировали спустя пару лет в react-native для мобилок, где GUI отбражается уже не браузером, а специальным движком, который создаёт нейтивные GUI-элементы платформы.
I>Не только для мобилок, еще и для десктопа, и даже не на жээс.

Речь про JS.
Это продолжение разговора о том, берёт ли JS практики из других ниш IT или вносит свои.
Пока мест больше берёт.
А которые практики вносит — это сугубо для собственного JS-мирка.


I>Собственно, ты плавно уперся носом в тот самый экспорт который секундой ранее отрицал

Забавная попытка всё выкрутить наоборот...
Но нет.

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

_>>И мне вообще странно представить, что кто-то (ну естественно кроме авторов соответствующих библиотек) мог подумать об идее рисовать кнопочки руками — это уж слишком стандартная в индустрии задача, чтобы плодить свои велосипеды в прикладных приложениях, вместо использования готовых библиотек.
I>Мне трудно понять, что же от тебя можно ожидать, особенно с учетом того, что ты регулярно хвастаешься, как твои наколеночные велосипеды обгоняют всё что угодно.

В рисовании кнопочек? ))
Написать не забыл, включить голову забыл...


_>>Эммм, WebGL — это вообще не движок. ))) Это просто бальный доступ для твоего кода к видеокарте пользователя и всё.
I>Джижок, engine, это настолько широкий термин, что крайне странно к этому придираться.
I>API рендеринга вполне себе подходит под термин "движок"

Что-то ты не догоняешь малость...
Требуемый АПИ и так есть, достаточно было дать к нему доступ.

Т.е., в wasm нет своего уникального АПИ графики, есть "открытая дверь" к одной из версий OpenGL — GLES.
Ровно это же АПИ использует внутренний движок рендеринга браузера, поэтому я и писал рядом, что wasm имеет такие же графические ср-ва оперирования отображением в своём "окне", как и хост-браузер.

Emscripten targets the WebGL-friendly subset of OpenGL ES 2.0. This is the set of GL ES commands that map directly to WebGL, so that each GL command has a roughly direct mapping to WebGL.

I>Все как я и говорил — экзотический случай, никаких шансов интеграции с другими системами/компонентами.

Как это "никаких шансов", если они используют третьесторонние библиотеки для OGL? ))
Ты не в курсе, похоже, как умеют работать те библиотеки — им можно подать уже готовый контекст и вью-порт.

И это только касательно GUI.
А касательно любого другого функционала — линкуй себе в проект любые третьесторонние либы для нужной функциональности, какие проблемы?


I>Именно. А еще интеграция — любой крупный UI как правило сборная солянка частей от разных команд и даже вендоров. И это не редкость.

Как и везде.


I>Современный подход — UI определяет API и данные. Отсюда ясно, что избавляемся от лишних приседаний сравнивая UI 10 и 20 летней давности.
I>Схема взаимодействия проще, API проще, данные проще, стейтменеджмент гораздо более эффективный.

Здесь брехня каждое слово.
В фронтенде всё это сложнее.
Единственный его плюс — это способ "размещения" и "обновления" приложений.
Вот тут он впереди планеты всей оказался по многим историческим причинам.
В т.ч. потому что отрубили плагинную систему.

А так-то в Сервелате всё тобой перечисленное в разы продвинутей было.

Ну ниче... Допилят GC для wasm и очередная инкарнация WPF/Cервелата туда проникнет. ))
А может быть даже и раньше, судя по скорости разработки Blazor.

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

V>Для подключения к соседней машине в подсетке не нужно...
V>А через глобальный интернет если — нужно аж бегом.

Вероятно, ты так настаиваешь, потому как другого варианта не знаешь

I>>да и под условие не подходит.
V>Кому какое дело до надуманных условий?

Никакие не надуманые

I>>И ты забыл — я тебя просил показывать нативную отладку. Никак условие не прочтешь?

V>Я не забыл — ты утверждал, что в нейтиве нет удалённой отладки.

Вот так цырк

V>Возникли дополнительные "требования"?

Я их изначально озвучил. С усвояемостью проблемы?

I>>Для нативной отладки так и есть.

V>Для твоей отладки тоже.

Наоборот. Здесь ведь внятная честная песочница и доступ только к тем данным, которые и так у меня есть. То есть, юзер не раскрывает мне ровно ничего. Отсюда понятно, что и особые пермишны для этого не нужны, приседания то тут, то там тоже не нужны.

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

V>>>В реакте они настолько приблизились в архитектуре приложения к обычным GUI-приложениям,
I>>Не в реакте, а в single page application

V>Хрен там.

Очевидно, ты не видел кода типичного SPA скажем в 10-12м году.

I>>Это началось задолго до реакта. Скажем, SPA на Ext.js это практически обычное десктоп приложение.

V>Это обычная лапша в коде, с которой реакт решил что-то следать.
V>"Обычным приложением" эта трудноотлаживаемая каша выглядит только снаружи, если на код не смотреть. ))

Как говорят, что о вкусе устриц надо говорить с теми, кто их ел.

I>>Не только для мобилок, еще и для десктопа, и даже не на жээс.

V>Речь про JS.
V>Это продолжение разговора о том, берёт ли JS практики из других ниш IT или вносит свои.
V>Пока мест больше берёт.

Это ты так издалека начал соглашаться Пока что да — заимствует больше, чем отдаёт. Факт в том, что экспорт таки идёт.

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

I>>Все как я и говорил — экзотический случай, никаких шансов интеграции с другими системами/компонентами.

V>Как это "никаких шансов", если они используют третьесторонние библиотеки для OGL? ))
V>Ты не в курсе, похоже, как умеют работать те библиотеки — им можно подать уже готовый контекст и вью-порт.

99% вокруг тебя это веб-UI, жээсный. Вот с ним и нужно интегрироваться, в ту или другую сторону. Отсюда ясно, что если ты запилил на вебгл, то и простой интеграции не будет. Что в одну сторону, что в другую.

V>И это только касательно GUI.
V>А касательно любого другого функционала — линкуй себе в проект любые третьесторонние либы для нужной функциональности, какие проблемы?

Каким чудом подлинковать в вебгл морду на реакте? Подробнее.

I>>Именно. А еще интеграция — любой крупный UI как правило сборная солянка частей от разных команд и даже вендоров. И это не редкость.

V>Как и везде.

Кроме тех UI, что целиком на канвасе. С ними всегда всё не так

I>>Современный подход — UI определяет API и данные. Отсюда ясно, что избавляемся от лишних приседаний сравнивая UI 10 и 20 летней давности.
I>>Схема взаимодействия проще, API проще, данные проще, стейтменеджмент гораздо более эффективный.

V>Здесь брехня каждое слово.
V>В фронтенде всё это сложнее.

Вероятно, ты снова про свой неудачный опыт.

V>Ну ниче... Допилят GC для wasm и очередная инкарнация WPF/Cервелата туда проникнет. ))

Устарело еще на момент первого выхода.

V>А может быть даже и раньше, судя по скорости разработки Blazor.

Судя по тому, что Микрософт унутре себя предпочитают Электрон этому блазору...

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

V>>А может быть даже и раньше, судя по скорости разработки Blazor.

I>Судя по тому, что Микрософт унутре себя предпочитают Электрон этому блазору...
Все течет все меняется
First .NET 6 Preview Introduces Blazor Desktop
Ну еще и Uno Platform v3.8 Adds Microsoft WinUI Grid Code, Windows AoT Support

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

V>>Согласно же твоим рассуждениям выходит, что не надо было использовать JS до 2015-го года, когда в нём появился async/await (или даже до 2016-го, когда async/await узаконили в стандарте ES7)?
I>А тут стоит почитать самого автора нода, он прямо сказал, чего они планировали, но не стали добавлять, т.к. не понимали актуальность концепции.

При чём тут "актуальность", если первая экспериментальная реализация async/await появилась спустя 6 лет после выпуска первого релиза ноды?
И разрабатывать её начали как минимум на 9-12 месяцев раньше первого релиза.

И сейчас никто не мешает постепенно дорабатывать АПИ основных либ ноды для большей поддержки async/await.
Так шта, никуда твоя нода не денется, а появившийся "конкурент" по классике жанра сделает лучше всем, т.к. конкуренция даст пинка ноде. ))

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

V>>Для подключения к соседней машине в подсетке не нужно...
V>>А через глобальный интернет если — нужно аж бегом.
I>Вероятно, ты так настаиваешь, потому как другого варианта не знаешь

Никто в индустрии не знает.


V>>Возникли дополнительные "требования"?
I>Я их изначально озвучил. С усвояемостью проблемы?

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


I>Наоборот. Здесь ведь внятная честная песочница и доступ только к тем данным, которые и так у меня есть. То есть, юзер не раскрывает мне ровно ничего. Отсюда понятно, что и особые пермишны для этого не нужны, приседания то тут, то там тоже не нужны.

Тебе нужен доступ к TCP-порту машины клиента, где на этом порту ожидает входящих TCP-соединений встроенный отладчик Хрома.
Настраивать пермишенны для подключения к порту нужны, ес-но.

Сам некий уникальный порт, выбранный для удалённой отладки Хрома, придётся пробросить через NAT, возможно более чем через один.
В случае VPN порт необходимо пробросить через контроллер VPN-сети, а это зачастую Cisco-железяка и на это у многих контор требуется письменный запрос и детальное его рассмотрение.

И да, сам Хром тебе обязателен, бо из кучи доступных браузеров (буде юзер к ним привыкни) у тебя будет требование в адрес юзверя установить локально Хром и зайти в него со специальной командной строкой.