Здравствуйте, Евгений Акиньшин, Вы писали:
V>>А где вообще используют вебасм? ЕА>из интересного показали автокад и новомодную figma: ЕА>https://youtu.be/BnYq7JapeDA
Беда-беда.
Им еще пару лет это допиливать до чего-то вменяемого, чтобы достичь примерно того же, что можно было делать на сервелате 10 лет до этого: https://www.youtube.com/watch?v=RDIeijJkV14
Кароч, эти свиньи из Гугла украли у индустрии 10 лет насыщенной жизни.
По-другому это не выглядит.
Бо мы все должны были ждать эти 10 лет только затем, чтобы дать Гуглу время на разработку технологий, которые появились у конкурентов на 10 лет раньше. \
Надо было завалить Гугл судебными исками, как когда-то завалили ими MS, только теперь уже всерьёз.
Они же банальные вредители.
Здравствуйте, vdimas, Вы писали: S>>>>Где сервелат? V>>>В Блазоре. S>>Окай, код есть. А используют где? V>А где вообще используют вебасм?
Чуть менее, чем нигде пока еще. А почему вы спнашиваете?
Здравствуйте, Ночной Смотрящий, Вы писали:
С>>А куда же девать 50 миллионов фуллстеков, фронтендщиков и верстал? Мастеров различий между == и ===, укротителей NPM и Bower, повелителей LESS и прочей дури? НС>WebAsm не отменяет ни HTML, ни LESS, ни даже JS (пока не разберутся с доступом к DOM).
На самом деле их можно отменить даже в рамках JS. Смотри:
1. Берём HTML состоящий из одной загрузки нашего JS скрипта и всё.
2. В скрипте создаём WebGL поверхность (имеется во всех современных браузерах) на всё окно браузера.
3. Берём библиотеку 2D графики поверх OpenGL (полно таких).
4. Берём некую GUI библиотеку (грубо говоря набор контролов), реализованную с бэкендом поверх нашей 2D библиотеки.
5. (опциональный, т.к. не все такое любят) Можем придумать и использовать какой-нибудь свой язык разметки (типа того же QML), для расположения наших контролов на странице. И так же можно использовать в нашей библиотек контролов общую систему стилей с наследованием от родительского виджета.
Это всё без проблем реализуется прямо сейчас. Только вот работать будет сильно медленно, и главное совершенно не нужно при наличие уже подключённого в наш JS DOM браузера.
А вот если рассматривать ту же схему с позиции WASM, то уже не всё так однозначно... Тут и с быстродействием особых проблем не будет и главное что реализовать эту схему (особенно если делать это с помощью большого числа готовых C++ библиотек) может быть не сильно сложнее, чем протащить весь DOM через экспорт/импорт WASM (в случае схемы выше надо будет протащить только WebGL, что тривиально, т.к. это просто небольшой набор не ООП функций).
Здравствуйте, alex_public, Вы писали:
С>>>А куда же девать 50 миллионов фуллстеков, фронтендщиков и верстал? Мастеров различий между == и ===, укротителей NPM и Bower, повелителей LESS и прочей дури? НС>>WebAsm не отменяет ни HTML, ни LESS, ни даже JS (пока не разберутся с доступом к DOM). _>На самом деле их можно отменить даже в рамках JS. Смотри: _>1. Берём HTML состоящий из одной загрузки нашего JS скрипта и всё. _>2. В скрипте создаём WebGL поверхность (имеется во всех современных браузерах) на всё окно браузера. _>3. Берём библиотеку 2D графики поверх OpenGL (полно таких). _>4. Берём некую GUI библиотеку (грубо говоря набор контролов), реализованную с бэкендом поверх нашей 2D библиотеки.
И получаем никому не нужную какашку.
_>5. (опциональный, т.к. не все такое любят) Можем придумать и использовать какой-нибудь свой язык разметки (типа того же QML), для расположения наших контролов на странице.
Здравствуйте, alex_public, Вы писали:
С>>>А куда же девать 50 миллионов фуллстеков, фронтендщиков и верстал? Мастеров различий между == и ===, укротителей NPM и Bower, повелителей LESS и прочей дури? НС>>WebAsm не отменяет ни HTML, ни LESS, ни даже JS (пока не разберутся с доступом к DOM).
_>На самом деле их можно отменить даже в рамках JS. Смотри:
_>1. Берём HTML состоящий из одной загрузки нашего JS скрипта и всё. _>2. В скрипте создаём WebGL поверхность (имеется во всех современных браузерах) на всё окно браузера. _>3. Берём библиотеку 2D графики поверх OpenGL (полно таких). _>4. Берём некую GUI библиотеку (грубо говоря набор контролов), реализованную с бэкендом поверх нашей 2D библиотеки. _>5. (опциональный, т.к. не все такое любят) Можем придумать и использовать какой-нибудь свой язык разметки (типа того же QML), для расположения наших контролов на странице. И так же можно использовать в нашей библиотек контролов общую систему стилей с наследованием от родительского виджета.
Ну да, и запишишь свой ***ML, до кучи — к нему же ***SS. Практически все визуальные редакторы идут этим путем — сначала пилят документную модель, DOM, что бы отделить структуру от стилей, прикручивают Style Sheets и тд итд.
_>Это всё без проблем реализуется прямо сейчас. Только вот работать будет сильно медленно, и главное совершенно не нужно при наличие уже подключённого в наш JS DOM браузера.
"можно отменить даже в рамках JS" @ alex_public
Вот то, что ты написал, выглядит как "отменить нельзя"
_>А вот если рассматривать ту же схему с позиции WASM, то уже не всё так однозначно... Тут и с быстродействием особых проблем не будет и главное что реализовать эту схему (особенно если делать это с помощью большого числа готовых C++ библиотек) может быть не сильно сложнее, чем протащить весь DOM через экспорт/импорт WASM (в случае схемы выше надо будет протащить только WebGL, что тривиально, т.к. это просто небольшой набор не ООП функций).
V>Надо было завалить Гугл судебными исками, как когда-то завалили ими MS, только теперь уже всерьёз.
Ход мыслей правильный. Четкие ребятки именно это и делают. См. Oracle.
_>На самом деле их можно отменить даже в рамках JS. Смотри:
_>1. Берём HTML состоящий из одной загрузки нашего JS скрипта и всё. _>2. В скрипте создаём WebGL поверхность (имеется во всех современных браузерах) на всё окно браузера. _>3. Берём библиотеку 2D графики поверх OpenGL (полно таких). _>4. Берём некую GUI библиотеку (грубо говоря набор контролов), реализованную с бэкендом поверх нашей 2D библиотеки. _>5. (опциональный, т.к. не все такое любят) Можем придумать и использовать какой-нибудь свой язык разметки (типа того же QML), для расположения наших контролов на странице. И так же можно использовать в нашей библиотек контролов общую систему стилей с наследованием от родительского виджета.
_>Это всё без проблем реализуется прямо сейчас. Только вот работать будет сильно медленно, и главное совершенно не нужно при наличие уже подключённого в наш JS DOM браузера.
Здравствуйте, vdimas, Вы писали:
I>>И каждый вендор будет пилить свой собственный DOM
V>Будет. V>Потому что Xamarin.Forms выглядит как халявная кроссплатформенность.
В микрософте кроссплатформенные вещи пишутся не на хвалёном Ксамарине, а на Electron. Как то так.
Здравствуйте, Ikemefula, Вы писали:
I>В микрософте кроссплатформенные вещи пишутся не на хвалёном Ксамарине, а на Electron. Как то так.
Во-первых, Атом.
Во-вторых, от микрософта там только система организации плагинов, Атом был разработан гитхабом.
В-третьих, если брать VS Code — это ж опенсорс, туда "все пишут".
Доля кода MS в настроенной к работе VS Code — ничтожна.
Здравствуйте, vdimas, Вы писали:
I>>В микрософте кроссплатформенные вещи пишутся не на хвалёном Ксамарине, а на Electron. Как то так.
V>Во-первых, Атом.
Electron. Раньше это называлось Atom Shell, но это устаревшее название. Electron это движок для десктоп приложений, Chrome+Node.
Atom Editor это другой редактор на Electron.
V>Во-вторых, от микрософта там только система организации плагинов, Атом был разработан гитхабом.
Ога. Ты путаешь Atom редактор и Atom Shell который Electron.
V>В-третьих, если брать VS Code — это ж опенсорс, туда "все пишут". V>Доля кода MS в настроенной к работе VS Code — ничтожна.
14мб зипом. Совсем ничего, да.
Кроме vscode, есть и другие вещи от микрософта на ём:
Здравствуйте, Ikemefula, Вы писали:
V>>Во-вторых, от микрософта там только система организации плагинов, Атом был разработан гитхабом. I>Ога. Ты путаешь Atom редактор и Atom Shell который Electron.
Atom Shell был разработан гитхабом. ))
V>>В-третьих, если брать VS Code — это ж опенсорс, туда "все пишут". V>>Доля кода MS в настроенной к работе VS Code — ничтожна. I>14мб зипом. Совсем ничего, да.
Там ничего.
Чтобы настроить среду под какой-нить язык и основные сценарии сборки, еще в три раза больше изволь туда залить.
I>Кроме vscode, есть и другие вещи от микрософта на ём: I>Skype
Стало любопытно, натравил Spy++, вижу обычный UWP-стек.
В общем, все разы у тебя мимо. ))
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>WebAsm не отменяет ни HTML, ни LESS, ни даже JS (пока не разберутся с доступом к DOM). _>>На самом деле их можно отменить даже в рамках JS. Смотри: _>>1. Берём HTML состоящий из одной загрузки нашего JS скрипта и всё. _>>2. В скрипте создаём WebGL поверхность (имеется во всех современных браузерах) на всё окно браузера. _>>3. Берём библиотеку 2D графики поверх OpenGL (полно таких). _>>4. Берём некую GUI библиотеку (грубо говоря набор контролов), реализованную с бэкендом поверх нашей 2D библиотеки. _>>5. (опциональный, т.к. не все такое любят) Можем придумать и использовать какой-нибудь свой язык разметки (типа того же QML), для расположения наших контролов на странице. НС>И получаем никому не нужную какашку.
Оно действительно никому не нужно, но не потому что плохо (вполне допускаю, что можно сделать и получше современной реализации html/css, т.к. не требуется поддерживать совместимость со старым кодом и при этом известны старые ошибки), а просто потому что под рукой уже есть готовый HTML. А вот у WASM такого под рукой нет (во всяком случае пока), так что там подобный подход может быть вполне актуальным...
Здравствуйте, novitk, Вы писали:
_>>1. Берём HTML состоящий из одной загрузки нашего JS скрипта и всё. _>>2. 3. 4. 5. .... N>Ура, мы теперь можем делать ровно такие же апплеты на плюсах, как делали на яве 30 лет назад!
Да, общий подход тот же, более того, flash и silverlight тоже сюда относятся. Но есть отличия в реализации:
0. Насколько я помню для работы апплетов надо было самому устанавливать Java на компьютер.
1. Разница в быстродействие: и сам wasm работает почти как нативный код и не припомню доступа к GPU у апплетов.
2. Разница в безопасности: у апплетов была очень мутная (сложная, позволяющая получить контроль над компьютером и ещё много проблем там было) система правд доступа, в то время как у wasm буквально такие же права/возможности, что и у js в браузере (т.е. уже продуманная, проверенная временем и удобная для пользователя система).
3. Не припомню в Java вменяемого GUI фреймворка со своим языком разметки и темами во времена апплетов.
4. Сейчас (в отличие от времён апплетов) практически все сайты работают через ajax. А работающий через ajax бэкенд вообще не требуется переделывать при смене фронтденда с html на некий апплет (более того, очень многие сайты можно сказать что имеют такие апплеты прямо сейчас — мобильные приложения же это оно и есть!), в отличие от веб'а времён апплетов, который было весьма напряжно переписать.
Так что лично я совсем не удивлюсь, если та самая старая идея, не взлетевшая тогда, взлетит сейчас. Вообще мне кажется что при нынешних условиях основной минус данного подхода связан с индексацией поисковиками и т.п. вопросы. Однако для некоторых сайтов (скажем игр, или каких-то сложных интерфейсов (например контрольные панели какие-нибудь и т.п.)) это совсем не минус...
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
V>>>Во-вторых, от микрософта там только система организации плагинов, Атом был разработан гитхабом. I>>Ога. Ты путаешь Atom редактор и Atom Shell который Electron.
V>Atom Shell был разработан гитхабом. ))
А дважды два — четыре. Современное название Atom Shell — Electron.
V>Там ничего. V>Чтобы настроить среду под какой-нить язык и основные сценарии сборки, еще в три раза больше изволь туда залить.
Какую среду ? Ты путаешь редактор Atom и движок Electron, который фремворк приложений, а не редактор.
I>>Кроме vscode, есть и другие вещи от микрософта на ём: I>>Skype
V>Стало любопытно, натравил Spy++, вижу обычный UWP-стек. V>В общем, все разы у тебя мимо. ))
Интересно, как твой UWP-стек запускается под маком и линуксом ? Ты какую именно версию проверял ? Ты в курсе, что у скайпа много версий ?
Здравствуйте, alex_public, Вы писали:
_>0. Насколько я помню для работы апплетов надо было самому устанавливать Java на компьютер.
Это логистически-политическая проблема, а не технологическая.
_>1. Разница в быстродействие: и сам wasm работает почти как нативный код и не припомню доступа к GPU у апплетов.
Ява с jit работает "почти как нативный код". В нетскейпе у ява-апплетов был interop с JS, такой же как у wasm.
_>2. Разница в безопасности: у апплетов была очень мутная (сложная, позволяющая получить контроль над компьютером и ещё много проблем там было) система правд доступа, в то время как у wasm буквально такие же права/возможности, что и у js в браузере (т.е. уже продуманная, проверенная временем и удобная для пользователя система).
В Яве "мутная система с безопасностью" была с API вне js. Если такого API нет, как в wasm, ничего мутного не будет.
_>3. Не припомню в Java вменяемого GUI фреймворка со своим языком разметки и темами во времена апплетов.
А в wasm он уже есть? Или ты про QtQuick? подобное можно было бы сделать сейчас для JavaFX.
_>4. Сейчас (в отличие от времён апплетов) практически все сайты работают через ajax. А работающий через ajax бэкенд вообще не требуется переделывать при смене фронтденда с html на некий апплет (более того, очень многие сайты можно сказать что имеют такие апплеты прямо сейчас — мобильные приложения же это оно и есть!), в отличие от веб'а времён апплетов, который было весьма напряжно переписать.
Ничего не понял. В апплетах ajax был как бы нативный, через обычное сетевое API.
\
Ты какую именно версию проверял ? Ты в курсе, что у скайпа много версий ?
