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

DM>Люди, следившие за их рассылкой, говорят, что те пока только договорились, что надо договориться, но дальше этого — о фичах — пока не очень еще договорились.
Интересно, а как повлиять на то о чём они договариваются?
Ибо сейчас они делают очередной кошмар, с которым люди застрянут надолго.
Не настолько кошмарный как жабаскрипт, но всё же.

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

WH>Здравствуйте, D. Mon, Вы писали:

DM>>Люди, следившие за их рассылкой, говорят, что те пока только договорились, что надо договориться, но дальше этого — о фичах — пока не очень еще договорились.
WH>Интересно, а как повлиять на то о чём они договариваются?
WH>Ибо сейчас они делают очередной кошмар, с которым люди застрянут надолго.
WH>Не настолько кошмарный как жабаскрипт, но всё же.

1. Вступить в UG https://www.w3.org/community/webassembly/
2. Открывать issue по конкретной проблеме в проекте https://github.com/WebAssembly/design/issues

DM>http://techcrunch.com/2015/06/17/google-microsoft-mozilla-and-others-team-up-to-launch-webassembly-a-new-binary-format-for-the-web/
DM>https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
DM>https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md
DM>https://github.com/WebAssembly/design/blob/master/UseCases.md
Выглядит коряво. Так что есть все шансы прижиться.

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

BDA>Короче, сдается мне, вся эта история закончится левой рекламой, от которой не избавиться, и окончательной потерей приватности. Рад буду ошибиться.
Если подписывать такой байткод сертификатом, то как минимум можно избежать врезания рекламы. А ещё можно запретить и вырезания рекламы браузером т.к. проле модификации байткод станет не подписанным и браузер не захочет его выполнять.

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

BDA>>Короче, сдается мне, вся эта история закончится левой рекламой, от которой не избавиться, и окончательной потерей приватности. Рад буду ошибиться.
K>Если подписывать такой байткод сертификатом, то как минимум можно избежать врезания рекламы. А ещё можно запретить и вырезания рекламы браузером т.к. проле модификации байткод станет не подписанным и браузер не захочет его выполнять.

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

Реклама как таковая — хрен бы с ней, нацеливание, неотделимое от показа — вот что отвращает. Фейсбук хвастался, что раньше теток про беременность узнает. Но с ихними трекерами и фейсбучить не надо, на каждой странице десяток доносчиков.

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

goto легко реализуется с помощь блоков и continue/break

      case kStmtBreak: {
          unsigned depth = Operand<uint8_t>(pc_);
          if (depth < blocks_.size()) {
            Block* block = &blocks_[blocks_.size() - depth - 1];
            Goto(ssa_env_, block->break_env);
            ssa_env_->state = SsaEnv::kControlEnd;
          } else {
            error(pc_, "improperly nested break");
          }
          Leaf(kAstStmt);
          len = 2;
          break;
        }

Как-то не очень понятно что это в итоге даст:

• Размеры скриптов с учётом минификаторов и gzip вроде никогда не были особой проблемой (это при том, что GWT+Sencha на выходе выдавали ~750КБ минифицированного javascript в релизе). Т.е. есть обоснованное сомнение что оно будет настолько меньше, что кто-то кроме гугла это ощутит.
  
• В большинстве задач производительность веб-приложения упирается в relayout браузера. От того что скрипт будет работать в 10 раз быстрее отрисовка не ускорится.
  
• Компиляция из любого языка и сейчас не проблема. Просто особо никому это и не надо. Да и, как минимум поначалу, всё равно придётся параллельно компилировать в js, ради браузеров не поддерживающих новую суперфичу.

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

O>Выглядит коряво. Так что есть все шансы прижиться.

Вы прямо на философские размышления толкаете, о том было ли хоть что-то не корявое в интернет-стандартах.

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

S>Как-то не очень понятно что это в итоге даст:
S>

S>
• Размеры скриптов с учётом минификаторов и gzip вроде никогда не были особой проблемой (это при том, что GWT+Sencha на выходе выдавали ~750КБ минифицированного javascript в релизе). Т.е. есть обоснованное сомнение что оно будет настолько меньше, что кто-то кроме гугла это ощутит.
  S>
• В большинстве задач производительность веб-приложения упирается в relayout браузера. От того что скрипт будет работать в 10 раз быстрее отрисовка не ускорится.
  S>
• Компиляция из любого языка и сейчас не проблема. Просто особо никому это и не надо. Да и, как минимум поначалу, всё равно придётся параллельно компилировать в js, ради браузеров не поддерживающих новую суперфичу.
  S>

1. Скорость компиляции из ВАСМ в исполняемый код будет мгновенной, так как все высокоуровневые оптимзации делаются до получения ВАСМ. Тут по факту только распределение регистров.
2. Так как модель компиляции будет максимально приближена к машинным кодам(полная противоположенность С#), то можно будет формировать очень высокопроизводительный код.
3. Например можно будет делать DOOM 4 в браузере, производительности хватит, а с учетом того, что все это будет работать в любом браузере (Эпл присоединиться) все игры просто сменят платформу (ну не все....)

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

s22>1. Скорость компиляции из ВАСМ в исполняемый код будет мгновенной, так как все высокоуровневые оптимзации делаются до получения ВАСМ. Тут по факту только распределение регистров.
Как-то даже на мобильных браузерах незаметно особой проблемы со скоростью компиляции. И соответственно, есть либо страницы с малым количеством js — хорошо если выйгрыш будет измерим хотя-бы инструментально, либо большие SPA у которых выйгрыш будет только на начальной загрузке. Ну да, есть ещё и ублюдки: страницы с огромным количеством js и не SPA — тут да, будет весомый выйгрыш. Слава говнокоду.

s22>2. Так как модель компиляции будет максимально приближена к машинным кодам(полная противоположенность С#), то можно будет формировать очень высокопроизводительный код.
S>> В большинстве задач производительность веб-приложения упирается в relayout браузера. От того что скрипт будет работать в 10 раз быстрее отрисовка не ускорится.

s22>3. Например можно будет делать DOOM 4 в браузере, производительности хватит, а с учетом того, что все это будет работать в любом браузере (Эпл присоединиться) все игры просто сменят платформу (ну не все....)
Угу. Игры же известны своими огромными требованиями к процессору.

S>Как-то не очень понятно что это в итоге даст:
S>

S>
• Размеры скриптов с учётом минификаторов и gzip вроде никогда не были особой проблемой (это при том, что GWT+Sencha на выходе выдавали ~750КБ минифицированного javascript в релизе). Т.е. есть обоснованное сомнение что оно будет настолько меньше, что кто-то кроме гугла это ощутит.
  S>
• В большинстве задач производительность веб-приложения упирается в relayout браузера. От того что скрипт будет работать в 10 раз быстрее отрисовка не ускорится.
  S>
• Компиляция из любого языка и сейчас не проблема. Просто особо никому это и не надо. Да и, как минимум поначалу, всё равно придётся параллельно компилировать в js, ради браузеров не поддерживающих новую суперфичу.
  S>

Дык как с хардваре. Ты только дай больше ресурсов, а уж как их использовать быстро придумают. Не?

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

BDA>Интересно, как это скажется на приватности, рекламе и безопасности вообще.

Больше причастных узнают о CORS