Пользователь
0,0
рейтинг
19 июня 2015 в 02:34

Разработка → Google, Microsoft, Mozilla и другие объединились для запуска WebAssembly, нового бинарного формата для Web перевод

Google, Microsoft, Mozilla и инженеры проекта WebKit 17 июня сделали анонс, что они объединились для запуска WebAssembly, нового бинарного формата для компилирования веб-приложений.

Веб развивается благодаря стандартам, и, плохо это или хорошо, JavaScript один из них. Однако на протяжении многих лет мы видели много попыток обойти ограничения языка, например, создание компиляторов, которые транслируют код из других языков в JavaScript. Некоторые из этих проектов фокусируются на добавлении новых возможностей в язык (например, TypeScript от Microsoft) или ускорении JavaScript (например, Mozilla asm.js). Сейчас многие из этих проектов объединяются в том или ином виде в WebAssembly.

Новый формат позволяет программистам компилировать их код для браузера (на текущий момент разработчики сфокусировались на C/C++, другие языки будут добавлены позже). Этот скомплированный код в дальнейшем исполняется внутри движка JavaScript. Вместо того, чтобы парсить исходный код, что все-таки часто занимает длительное время (особенно на мобильных устройствах), WebAssembly может быть декодирован значительно быстрее.

Идея состоит в том, что WebAssembly предоставит разработчикам единый способ компиляции, который в конечном счете станет веб-стандартом, реализованным во всех браузерах.

Файлы JavaScript это простые текстовые файлы, которые скачиваются с сервера и затем парсятся и компилируются движком JavaScript в браузере. Команда WebAssembly решила использовать бинарный формат потому, что код может быть сжат лучше, чем стандартный текстовый JavaScript файл, и потому, что для движка намного быстрее декодировать бинарный формат (до 23 раз быстрее в текущей реализации), чем, например, декодировать asm.js код.

Проект asm.js от Mozilla имеет долгосрочную цель привнести скорости, близкие к нативным в веб. Проект Native Client от Google для запуска нативного кода в браузере имеет похожую цель, но получил относительно небольшое распространение. Похоже на то, что сейчас WebAssembly имеет возможность привнести лучшее от этих проектов в браузеры.

В качестве первого шага, команда WebAssembly ставит цель достичь той же функциональности, что и asm.js (и разработчики смогут использовать ту же утилиту Emscripten для WebAssembly, что они используют для компиляции asm.js кода сейчас).

На этой ранней стадии команда также планирует запустить библиотеку polyfill, которая будет транслировать код WebAssembly в JavaScript таким образом, что он может быть выполнен любым браузером — даже без наличия встроенной поддержки WebAssembly (что, очевидно, абсурдно, потому что необходимость в этой библиотеке отпадет, как только браузеры получат встроенную поддержку WebAssembly). Со временем команда разработает больше утилит (компиляторы, дебаггеры и прочие) и добавит поддержку других языков (например, Rust, Go и C#).

Команда обращает внимание на то, что смысл их идеи не заменить JavaScript, а добавить возможность компилировать большое количество других языков для веб. Действительно, шансы таковы, что и JavaScript, и WebAssembly будут использованы вместе, бок о бок. Например, часть приложения может использовать модули WebAssembly (анимация, визуализация, сжатие, и проч.), а пользовательский интерфейс в основном будет написан на JavaScript.

Мы нечасто можем увидеть, что все значимые разработчики браузеров работают вместе над таким проектом, так что что-то определенно стоящее ожидает нас впереди.
Перевод: Frederic Lardinois
2tl @2tl
карма
9,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (192)

  • –44
    Главный спонсор данного проекта почему-то не указан. Догадываюсь что это АНБ.
    • +25
      Вам надо новый libastral скачать, ваша версия устарела.
  • +28
    Круто! Я ждвадцать лет ждал этого стандарта!

    Интересно, какой язык лет через 10 станет стандартом де-факто для фронта. Принимаю ставки :)

    что, очевидно, абсурдно, потому что необходимость в этой библиотеке отпадет, как только браузеры получат встроенную поддержку WebAssembly


    Абсурдно это для того, кто не знает что такое обратная совместимость. На настоящий момент в требованиях к публичному браузерному коду часто фигурирует IE8 (2009), встречается IE7 (2006), мастхэв IE9 (2011), а поддержка стандарта хорошо если будет в IE12. Экстраполируя, необходимости в библиотеке не будет только лет так через 10 минимум.

    • +1
      Как только Микрософт всех пересадит на десятую винду с годовой подпиской и принудительным обновлением, динозавров со старыми браузерами станет значительно меньше, а следовательно и внедрять стандарты в широкие массы станет легче и быстрее.
      • +5
        Особенно в гос. конторах. :)
        • +1
          и Китае
      • +9
        Особенно меньше их станет на андроидах.
        • +3
          Насколько я знаю, в android 5 уже webkit обновляется отдельно, независимо от прошивки
          • +1
            Это-то да, но вот доля 5-го андроида ничтожнейше мала. И завоюет большинство платформы еще ох как не скоро.
            • 0
              Могу сказать то же самое про windows 10
    • +1
      Вот вот, еще бы стандарты для верстки ввели, причем жесткие, а не как чейчас.
      • +13
        Жесткие стандарты и сейчас есть. Многие знакомые верстальщики выработали собственные жесткие гайдлайны и следуют им. А тот факт, что 80% веб-страниц сделано с нарушениями любых стандартов — это, по-моему, как раз то, что позволило Web вырасти так быстро и вовлечь огромное количество людей и бизнесов в индустрию.
        Низкий порог входа — это драйвер роста, как бы нам с вами не хотелось, чтобы все писали совершенный код по Макконнеллу
    • +2
      >Абсурдно это для того, кто не знает что такое обратная совместимость. На настоящий момент в требованиях к публичному браузерному коду часто фигурирует IE8 (2009), встречается IE7 (2006), мастхэв IE9 (2011)
      В куче проектов проще реально забить. Я давно сайты даже в IE не тестирую т.к. на моих площадках его доля составляет около 6%. Гораздо полезнее время потратить, чтобы доступность контента для людей с плохим зрением обеспечить, чем тратить кучу времени на поддержку малопопулярных браузеров.
      • 0
        Это кому как, у меня в копаративных проектах все сложнее, обязатаельная поддержка IE8. И без обратной совместимости вообще никак.
      • +3
        А какова доля на ваших площадках людей с плохим зрением?
    • 0
      а поддержка стандарта хорошо если будет в IE12

      IE 12 не будет, вместо него сделали Edge
      • +15
        Хоть горшком назовите :)
        • –1
          Дэк, если они никак не связаны, можно и пепелацом тогда
    • +8
      Интересно, какой язык лет через 10 станет стандартом де-факто для фронта.
      Дак по-моему абсолютно очевидно, какой. Такой же, какой и сейчас.
    • +1
      > Интересно, какой язык лет через 10 станет стандартом де-факто для фронта. Принимаю ставки :)

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

      *(благодаря подобной же логике вырос node.js)
  • +10
    Аллилуя! Аллилуя!
    Наконец то можно будет выгнать всех js-кодеров и начать писать SPA на хаскеле! :)
    • +4
      Так толсто, что даже тонко.
      • +4
        Тридцать три монады мне в эндофунктор, да он же прав!
  • 0
    Новый бинарный формат для Web

    От такого заголовка ожидал анонса нового: флеша, джава-апплетов, джава-эф-икс, сильверлайта…
  • +37
    Assembler → C → C++ → Javascript → AsmJS → Assembler → C → C++… :D
    • +4
      Я очень надеюсь, что до написания «движка ECMAScript -like на WebAssembly» дело не дойдёт :D

      P.S. уже предвижу срачи на форумах верстальщиков через 5 лет: «У меня Boost 1.67 под Chrome не компилится, что делать?»
    • +7
      image
    • +1
      D? Тоже хороший язык.
  • –8
    Может ли он заменить формат SWF от Adobe? Ну то есть, его можно попытаться использовать как контейнер для всего всего всего (вместо тысяч картинок, JS и CSS файлов), что позволит добиться такой же виральности, как и у Flash.
    • +6
      Очень надеюсь, что нет. Флэш — это такая операционка в браузере, у него свои кукисы, дырки, он до сих пор крадёт у меня мои хоткеи, итд., за это его и ненавидят. А это будет возможность сделать быструю pure computation library.
    • 0
      Переезжайте уже в 2015: Packaging on the Web.
  • +13
    То есть больше никаких исходников по Ctrl-U?
    И каждый сайт теперь — черный ящик?
    • 0
      Как сказать. Раз предоставят полифил для трансляции в JS, значит возможность понять в общих чертах что именно происходит в коде вполне возможно.
    • +3
      На самом деле — это путь к более мощным клиентским скриптам, в которые можно встраивать сокрытую логику, которая раньше была возможна только на сервере
      • +2
        Это так.
        Но вот банальный и попсовый кейс: кто-то хакнул чей-то сайт и вместе с контентом прилетает обфусцированный «злой» код на JS. Это противно, но понимаемо — код можно развернуть и понять что и как.
        В случае же бинарных данных — что делать? Всем срочно учить asm, дизассемблировать бинарники и ковыряться? По мне — для предприятий проще будет забанить на уровне корпоративной прокси получение таких данных, а за корпоративными проксиками так или иначе находится приличный процент веб-аудитории.
        • +4
          Не драматизируйте. Нормальный код на asm даже понятнее, чем код на asm.js, ибо используются нормальные низкоуровневые инструкции с запоминаемыми мнемониками, а не хаки, которые их имитируют. Главное не бояться, и бинарный код — вовсе не преграда. Да и наверняка у этого WebAssembly байт-код будет значительно проще, чем x86, всё же промежуточное представление.
          • +1
            вместо того что бы гадать, посмотрите по ссылке что уже имеется.
            Код будет распространятся в AST, что означает декомпиляция будет очень простой.
        • +8
          а вы сейчас как детектируете подозрительные скрипты? — вручную просматриваете исходники?
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Код в браузере будет работать быстро и при должном умении и старании не будет жрать столько, сколько сейчас жрет джаваскрипт. В наш век вебгл это особенно важный момент. К этому у разработчиков добавится возможность писать на языках, которые будут хорошо подходить к тем задачам, которые они будут решать и не городить костыли в виде компиляции в джаваскрипт. Я какое-то время назад писал свою фантазию о таком проекте, многим эта идея не понравилась (возможно, не стоило писать её в треде про джаваскрипт), а на мой возгляд, это одно из самых разумных начинаний для улучшения жизни как пользователей, так и разработчиков.
        • +4
          а чем принципиально отличается «ковыряться в js» от «ковыряться в asm»?
        • 0
          Ну во первых — есть отличные мониторы того, что делают скрипты. Какую информацию откуда и куда отправляют.
          Единственное — круто было бы — возможность выборочно давать доступ по мере возникновения потребности, например, как сейчас реализовано. Жмёшь на загрузить файл — появляется — вы хотите дать доступ к каталогу (не ко всем, а да, к отдельному каталогу)?
    • 0
      Будет можно переводить в человекочитаемый формат, как я понял. На гитхабе в целях:
      define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.
    • 0
      Вы ещё скажите, что каждый екзешник чёрный ящик, а дизассемблеров в природе нет :)

      С другой стороны, возможно, обфускация браузерного кода примет новые формы.
    • 0
      Не надо пугаться
      Will WebAssembly support View Source on the Web?

      Yes! WebAssembly defines a text format to be rendered when developers view the source of a WebAssembly module in any developer tool. Also, a specific goal of the text format is to allow developers to write WebAssembly modules by hand for testing, experimenting, optimizing, learning and teaching purposes. In fact, by dropping all the coercions required by asm.js validation, the WebAssembly text format should be much more natural to read and write than asm.js. Outside the browser, command-line and online tools that convert between text and binary will also be made readily available. Lastly, a scalable form of source maps is also being considered as part of the WebAssembly tooling story.

      github.com/WebAssembly/design/blob/master/FAQ.md
  • 0
    Я уже и не думал, что это когда-нибудь произойдет, наконец таки их осенило.
  • 0
    Думаю, все только выиграют от того что клиентская разработка станет не привязанной жестко к JS, хотя деплой клиентской логики при таком подходе существенно усложнится
    • +2
      И в чем это будет сложнее чем то, как это работает сейчас?
      • –3
        Компиляция
        • +2
          Я не знаток фронтенд-разработки, но вангую, что пайплайн из одного шага (компиляция) проще и короче пайплайна из полудесятка (трансляция, проверка, конкатенация, минификация и прочие -иции).
          • 0
            ну чисто практическая ситуация — кусок кода, который написан для обработки данных, которых пока нет на страничке, но они могут быть туда в какой то момент добавлены аджаксом. Компиляция подразумевает не только преобразование кода, но и установки ссылок на обьекты поздействия, в случае браузера это DOM обекты. Без привязки к структуре DOM вся эта компиляция — пшик, основное время как раз и занимает ползанье по модели, а не интерпретация команд скрипта. Получится очередная надстройка над html которая внутри себя все равно все приведет в реальный для браузера формат.
        • +3
          Ну вы же в курсе, что вроде как в современном вебе вообще принято делать сборку проекта, минификацию файлов, и хорошо бы еще инвалидацию кеша предусмотреть. Так что компиляция — практически и не проблема вовсе.
  • 0
    Не могли бы вы подсказать, как это повлияет на судьбы JS разработчиков, по вашему мнению?
    • 0
      Никак. Абсолютно.
    • +1
      Мы будем тратить меньше времени на чёрное шаманство т.е. сейчас, например, быстрые классы как бы есть, но как бы нет. Вроде просто, а начинаешь разбираться в производительности, залезаешь в сгенерированный LIR — ох ёёё. Оптимизация производительности — это изучение плохо документированных фич работы js-движков и борьба с их багами.
      Надо быстро? Взял C++ (неважно, какой язык будет использован на самом деле), написал, скомпилил — всё.
      В остальном всё останется как есть.
    • +3
      Кого не выбросит из профессии необходимость вместо коллбеков использовать промисы и затем вместо промисов использовать йилды да эвэйты (то есть буквально два раза стать с ног на голову после выхода ES5 и затем ES6), того добьёт WebAssembly.
      • +1
        Что нас не убивает – делает сильнее! WebAssembly встретим во всеоружии.
  • +3
    Немалая часть народа, программирующего сегодня фронтенд, к моменту реального запуска уже будет на пенсии.
    • +1
      Почему это Вы так решили? Над проектом работают немало людей, причём из серьёзных компаний. Да ещё и желающие приглашаются.
  • +4
    Я так понимаю что разница между JS и WebAssembly лишь в скорости парсинга. Но не понимаю чего все так ликуют ведь по сути не так много изменится. т.е. будет аля TypeScript на С# с набором абстракций типа DOM'а который как и обычный нужно компилить для браузера и в конечно счете получить тот же JS просто в более компактном виде.

    Если где то ошибся ткните носом. =)
    • 0
      Да, вы правы, разница между JS и WebAssembly лишь в скорости первоначального парсинга. В итоге код будет исполняться движком JS, значит время исполнения будет примерно одинаковое.

      Некоторые люди рады возможности использовать остальные языки (поддержку которых добавят в будущем) для веб-разработки.
      • +5
        Нет, это же будет не синтаксическое дерево, получаемое после парсинга обычного JS, а IR, наподобие того, что генерит сейчас asm.js, но в бинарном виде. Если такой формат будет поддержан браузерами, по скорости выполнения будет почти как нативный код.
        • 0
          Спасибо.
          Да, я не прав, в случае поддержки в браузерах, выполнение будет быстрее.
  • +17
    Внутренний Столлман во мне почуял, что грядут времена проприетарщины на вебе
    • +1
      Ну так и хорошо, что хоть кто-то денег на клиентских(frontend) разработках сможет поднять без риска мгновенного форка
      • 0
        для этого +- подходит только nacl, тут смысл в том что на клиент будет приходить уже распарсенное AST дерево, то есть тот же код, только без комментариев и уже с проставленными аннотациями о типах как в asm.js

        и сами авторы это прямо заявляют, что код можно будет свернуть обратно в некий код для чтения человеком, пруф:
        github.com/WebAssembly/design/blob/master/HighLevelGoals.md
        define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.
  • –6
    Это лично мое мнение, но выбор первичных языков огорчает. И честно говоря непонятен, с/с++/с# мало распространены среди веб разработчиков, взялиб JVM языки. Ну хоть гугл пропихнул go, уже кое что. А еще печалит что стек разработки веб приложения, усложняется огромными темпами… Зп веб девов бы так росли.
    • 0
      6 минусов и ни одного комментария… то есть — несогласны, но возразить не чем?!
      • 0
        Здесь уже несколько раз отвечали на подобные вашим комментарии. Повторяться — удовольствие из малоприятных. C/C++ — это первый обязательный язык для поддержки для любого низкоуровневого байт-кода или машинного кода. Потому что на этом языке написано огромное количество библиотек для всех возможных задач. Наверняка без C++ не обошлось и при разработке Java, и т.д. Это системный язык, и он построен так, чтобы генерировать эффективный машинный код, а не для того, чтобы на нём можно было писать не думая и не понимая как это вообще работает. Вообще если технология взлетит, то под неё быстро напишут кучу разных компиляторов под все популярные языки, для которых вообще возможно сгенерировать эффективный машинный код. В других случаях под WebAssembly будут собирать виртуальные машины, которые будут выполнять байт-код нужного вам языка. В общем, они всё правильно делают. Главное только чтобы этот WebAssembly действительно оказался близким по производительности к нативному коду :)

        Для вас ничего не изменится. Больше возможностей — лучше. Но вас никто не заставляет изучать их все. Вы как кодили на JavaScript, так и можете продолжать. Под WebAssembly будут программировать другие специалисты, и это актуально только для проектов, где нужна большая производительность на клиенте. Даже если вы захотите использовать это для того, чтобы сжать и оптимизировать картинку/видео на клиенте до отправки на сервер (без флэша) — наверняка для обычных кодеров под веб будут сделаны готовые библиотеки для удобного использования из JavaScript.
        • 0
          Спасибо за ответ, вы дали повод для размышлений. На что и надеялся сделав комментарий, а не молча минусы ловить.

          Я не пишу на js, умею, но не хочу. Так вот, как раз в этой ситуации, писать на с/с++ придётся мне, так как не ограничиваю себя познаниями лишь веб яп. И с этим фактом высказал личное мнение, что мне не нравится выбор языков. И привёл свои мысли на тему популярности с/с++ среди веб разработчиков, ведь технологий много создавалось, вопрос в том будут ли использовать…

          К тому же, цель проекта получить бинарник для браузера и для этих целей с/с++ не обязателен.

          П.С. Таки был прав в догадках, сишники минусовали.
          • +1
            Ну я не сишник, я вообще PHP-программист. Вам не придётся писать на C/C++, если вы не хотите. Подождёте компилятор языка, который вам нужен, и будете писать на нём. Всё равно после появления стандарта до момента, когда это распространится и можно будет использовать в продакшне пройдёт не один год. За это время все востребованные языки получат свои компиляторы, не переживайте.

            Цель получить быстрый код. Код на C++ будет быстрее кода на Java, потому что C++ ближе к железу. Эта технология создаётся для тех вещей, которые при помощи JS решались плохо, костыльно (через asm.js), медленно. Соответственно и язык выбран — самый популярный из подобных эффективных и близких к машинному коду языков.

            А C++ хотя бы поверхностно знать и уметь писать на нём полезно для общего развития. Для понимания как это всё работает, чтобы делать меньше глупостей.
            • –1
              Я же написал, что меня огорчает «первичный выбор»… А go меня вполне устраивает. Вы так защищаете си будто я написал что это плохой или никчёмный язык, но ведь, суть моего поста в другом.
              И да, я писал на сях, не много. Но мне хватило этого для понимания, что я этим пользоваться не хочу. Благо есть компилируемые языки способные заменить си почти в любой ситуации.
              • 0
                Я вам объясняю, почему в данном случае C/C++ — наиболее логичный выбор для «первичного выбора». Вас устраивает Go, кого-то устраивает Rust, а промышленный стандарт — C++, и с этим нужно считаться.
                • –1
                  Еслиб веб относился к промышленным технологиям, у меня вопросов не возникло, но ведь это не так. Я понимаю, что си прекрасно подходит для этой задачи, но у меня сомнения, что он подходит для сферы веб разработки.

                  И кстати ваши мысли, что если я не захочу писать на сях, мол и не придётся… Вы не правы, первым выйдет си и наиболшее количество библиотек выйдет на сях и мне таки придётся как минимум ковырятся в этом.
                  • –2
                    Вы сможете обращаться к модулям написанным на C/C++ из обычного JavaScript.

                    Ваш же вариант, первоочередная реализация JVM, попахивает оверинженерингом и большим оверхидом: по сути каждая бинарная сборка WebAssembly должна будет содержать полный код JVM на байт-коде WebAssembly, в которой будет крутится байт-код Java или Scala
                    • +1
                      К годалке не ходи что код jvm ни кто включать не будет, есть всякие jaccelerator и прочие. Собственно если они надумают включить java в список поддерживаемых языков им и так придется с этим что то делать.

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

                      Предвидя ваше возрожение по поводо либ php — да я туда лажу, приходится.
                      • 0
                        Если включать в список поддерживаемых JVM языки, в рамках объявленной парадигмы, то есть три пути:

                        1. игнорировать существующие компиляторы для них и писать компиляторы Java, Scala и т. д. в wasm

                        2. писать компиляторы байт-кода jvm в wasm или поддерживаемый уже язык (тот же С++)

                        3. написать jvm на wasm и включать её в загружаемые с сайтов бинарники.

                        Первый вариант совсем маловероятен. Второй в принципе возможен, но видится много подводных камней, особенно если компилять не напрямую в wasm. Третий будет оверхидный по ресурсам, но, имхо, обеспечит лучшую переносимость.

                        То что либу дергают из js ни как не влияет на то что придётся лезть в код самой либы.

                        Так код либы будет представлен в виде wasm-кода, на каком языке она была написана изначально мало будет иметь значения, если только нет желания запушить свои изменения в её исходники или поддерживать свой форк её.
                        • 0
                          Второй вариант: http://habrahabr.ru/post/240999/
                        • 0
                          Интересная смесь подходов 1 и 2: TASTY. Это промежуточное представление для компилятора скалы. А раз уж scalac умеет компилировать и java классы, то, полагаю, это представление будет доступно и для java.

                          Это фактически голые AST, после всех преобразований. Таким образом компилятор уже сделал всю сложную работу, но у нас все еще не потеряна никакая информация и мы все еще имеем высокоуровневое представление. В частности одна из целей этого формата в scalac — последующая компиляция в JavaScript.

                          От подхода 1 здесь наличие всей высокоуровневой информации, от подхода 2 — выполнение существующим компилятором всей основной работы.
  • +1
    Для Javascript может наступить новая эра и это может оказаться совсем ни шуткой.

    ЗЫ.
    По всей видимости Javascript превзойдет по сфере применения все остальные языки и будет их вытеснять из традиционных ниш.
    • 0
      Разве не уже пытается? NodeJS(iojs) и т.п. под сервер, NW.js под винду, Apache Cordova под мобилки. Увы WebAssembly лишь ускоряет парсинг и уменьшает вес.
      • +4
        Да, вы абсолютно правы, но WebAssembly даст гораздо больше.
        WebAssembly позволит создавать на javascript нативные приложения для различных платформ.
        Считаю, что даже такой монстр как Java в скором времени уступит свою пальму первенства.

        • 0
          WebAssembly в любом случае должен парсится движком (например V8 аля NodeJS(iojs)).
          т.е. по факту не даст гораздо больше.
          • 0
            Новый формат позволяет программистам компилировать их код для браузера (на текущий момент разработчики сфокусировались на C/C++, другие языки будут добавлены позже). Этот скомплированный код в дальнейшем исполняется внутри движка JavaScript. Вместо того, чтобы парсить исходный код, что все-таки часто занимает длительное время (особенно на мобильных устройствах), WebAssembly может быть декодирован значительно быстрее.


            Предполагаю, что там есть уже ВМ(VM) а скомпилированный код(b-code) представляет из себя код для это ВМ.

            PS.
            Скорее всего, вопрос времени когда нам покажут спецификацию ВМ.
            • 0
              Этот скомплированный код в дальнейшем исполняется внутри движка JavaScript. Вместо того, чтобы парсить исходный код, что все-таки часто занимает длительное время (особенно на мобильных устройствах), WebAssembly может быть декодирован значительно быстрее.


              Разве это не то о чем мы говорим? Возможно я ошибаюсь. Нужно оригинал почитать будет.
              • 0
                Мы гадаем на кофейной гуще.
                Как бы там ни было, вся суть к выводу языка на новый горизонт и он того стоит.

                • 0
                  Так смысл то как раз в том, чтобы писать под браузер не на JS, а на других языках, то есть не вывести JS на новый горизонт, а скорее наоборот.

                  Если это дело разовьётся, появятся компиляторы с других языков в WebAssembly, то количество желающих писать на JS может сильно поуменьшиться.
              • 0
                Вы почитайте описание на GitHub. К JS это все не имеет никакого отношения, основная цель — задать кроссплатформенный, портабельный IR, в который можно будет компилить (для начала) C и C++.
        • –2
          Считаю, что даже такой монстр как Java в скором времени уступит свою пальму первенства.


          ой не факт )

          Flash тоже планировали повсеместно заменить на HTML5
  • 0
    Хм, интересно, а как же дебажить тогда?..
    И будут ли ли либы на одном языке доступны для другого языка безо всякой магии (и как надо будет дебажить в этом случае)
    • 0
      отвечу сам себе: у них в FAQ это всё сказано
  • 0
    О да, как только после многих годов изучения Javascript я его постиг и полюбил, пришли сишники и все испортили. Теперь они будут диктовать мне условия и в вебе. :(
    • 0
      Внимательней прочтите. Они не учат браузер работать с C/C++. Они делают формат который быстрей парсится и по пути делают трансляторы. Клиент так и останется на JS. Условно вам делают формат в который можно собирать проект. Не нужно будет использовать минификаторы и т.п.
      • 0
        Не Ему, а Вам. :)
        • 0
          Поясните.

          sarcasm ->

          А слона то я и не заметил.
          • 0
            1. У нас есть 100500+ всяких разных стандартов. Правада, 99.(9) из них использует лишь пара гиков на Альфа Центавре. И ещё один, да, вот тот в пыльном углу, его используют в сепулькарии на Бетельгейзе.
            2. Мы же можем придумать ещё один, который заменит те 10 которые всеми уже изучены, чтобы всем НАМ было хорошо. Мы знаем C|C++ и т.п., и всё в наших руках. В конце концов, мы же всё это написали, так? Для того, чтобы сказать о «снижении порога входа» мы оставим трансляцию в байткод на уровне обратной совместимости с Нашими JS Engine.
            3.…
            4.…
            5. Ещё один Web стандарт, используемый непонятно кем и непонятно где.

            Но они могут, да, это Плюс. И они реально помогут товарищам, которые любят лепить Паттерны и Архитектуру там где достаточно Костылей и Велосипедов.
            И да, конечно, правильным людям с нормальными задачами они тоже помогут. Но это будет другая история.
            • +2
              1. У нас есть 100500+ всяких разных стандартов. Правада, 99.(9) из них использует лишь пара гиков на Альфа Центавре.
              99.(9) == 100.

              А вообще, ничо не понял.
        • +1
          Не Ему, а Вам. :)

          В этом вы все таки не совсем правы. =)
          • 0
            Да, ну, конечно «всем нам». Только я его не заказывал, и, подозреваю, что @graycow тоже.
            Основывался на Вашей фразе > «Условно вам делают формат в который можно собирать проект».
      • +2
        Ну, не знаю, у них там в FAQ написано:
        As explained in the high-level goals, to achieve a Minimum Viable Product, the initial focus is on C/C++. However, by integrating with JS at the ES6 Module interface, web developers don't need to write C++ to take advantage of libraries that others have written; reusing a modular C++ library can be as simple as using a module from JS.


        Я так понимаю, что на начальном этапе компилировать в .wasm можно будет только из C++. Это приведет к тому, что появятся библиотеки на C++, своя собственная субкультура и пр. Пока появятся компиляторы из других языков, C++ станет де факто стандарт. И, хотя я понимаю, что браузеру будет все-равно из чего .wasm получился, писать не на том, на чем написано большинство библиотек, мне будет неприятно а плюсы прийдется учить почти с нуля. Я не говорю, что так и будет, но вероятность всегда имеется. Хорошо, что хоть разрешили модули подключать из JS.
        • 0
          Поддерживаю. В С/C++ самом по себе нет ничего плохого, кроме чудовищного оверхеда.
          Я свои пределы знаю, Матан учил на троечку-четвёрочку, потому, что мозгов не хватило. Но это моя троечка была, я её заслужил всё-таки, и сдавал без шпор, просто интересно было себя всё-таки проверять. И да, это был не технический вуз.

          На JavaScript можно что-то начать писать даже будучи полным неофитом, и не разбираясь вообще в технологиях.
          И, если есть желание и стремление можно достичь в целом неплохого уровня, даже рисуя мелкие опусы для всяких нудных задач.

          Предлагаемый подход может изменить векторы приоритетов. Т.к. написание любого «мало-мальски» кода на любом «нормальном» языке, требующем запуска «компилятора» по определению не может быть простым, надеюсь это очевидно.

          А следовательно, не однозначно, но потенциально может сложиться ситуация, когда программирование для Web будет считаться элитарным занятием. Таким, как, например, считается сейчас умение программировать на ассемблере и C\C++.
          И не надо говорить, что на самом деле это типа «просто». Нихера это не просто, у кого нет в базе нормального матана и сотни регистров памяти в межушном нервном узле, может просто нехватить потенциала. И, да, я пробовал. Может попробую ещё, но сейчас не вижу смысла, мне хватает JS, и в нём нет оверхеда. Под Windows у меня есть HTML Applications и Windows Scripting Host. Под Linux у меня есть node.js, Rhino, commonjs (lib). Для общих задач я могу использовать NW.js. А так же у меня есть расширения для браузеров и куча других возможностей сделать ВСЁ самому. С приходом компилятора в веб лично моя жизнь может и не усложнится, но вероятность есть.
          • +3
            На самом деле просто количество инструментов пригодных для web увеличиться, затратные по производительности вещи будут уходить на уровень ниже и их можно будет использовать через js api.
    • 0
      sarcasm ->

      Как я Вас понимаю. Эти злые сишники, лепят свои паттерны и архитектуру, где надо и где не надо. И при этом они почему-то считают, что это и есть программирвоание. А нас, JavaScript Developer'ов при этом за людей вообще не признают. И вот сейчас они решили, что JavaScript стал не совсем нужен.
  • –12
    Взять бы туда Swift в качестве основы. Синтаксис очень простой, похож на JS, при этом с типизацией и т.д.
    • –1
      Ого, а почему тут Swift не любят?
      • 0
        Речь идёт про низкоуровневый двоичный код. Как можно взять высокоуровневый текстовый язык в качестве основы для низкоуровневого двоичного кода? Выглядит как глупость, вот и минусы. А компилировать в низкоуровневый двоичный код можно будет всё что угодно (для чего будут написаны соответствующие компиляторы).
        • –4
          А вот это:
          на текущий момент разработчики сфокусировались на C/C++
          видимо, тоже глупость?

          Не хочу и не могу навязывать свою модель поведения кому-либо, но, обычно, если я не понимаю чей-то коментарий, то либо спрашиваю, либо прохожу мимо…
          • +4
            Я процитирую чуть больше из статьи:
            Новый формат позволяет программистам компилировать их код для браузера (на текущий момент разработчики сфокусировались на C/C++, другие языки будут добавлены позже).
            Нет, это не глупость. Это значит, что первые компиляторы появятся для самых популярных системных языков программирования — для C и C++.

            Ваш комментарий написан чётко и ясно. Вы предлагаете WebAssembly основать на Swift. Если бы вы выразили желание получить компилятор Swift под WebAssembly — другое дело.
            • –4
              </зануда>
              Вы забыли за собой закрыть.
              Ок, специально для вас перефразирую мой первый комментарий:
              Вот бы там на Swift сфокусировались. Синтаксис очень простой, похож на JS, при этом с типизацией и т.д.
              • +7
                Я вам минусов не ставил, и специально для меня ничего не нужно делать. Я вам просто пояснил наиболее вероятную причину, почему вам прилетело столько минусов, и что ваше предположение что «Swift здесь не любят» скорее всего неверно.

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

                Сколько раз встречал случаи, когда кто-то публично огорчался по поводу минусов (а часто пишут, мол ну хоть кто-нибудь написал бы причину, негодяи, прикрываются анонимностью, трусы и т.д.), я писал в личку наиболее вероятную причину, и мне всегда тут же начинали присылать зачем-то кучу оправданий и даже каких-то обвинений. Не удивлён, что мало кто желает описывать причины поставленного минуса. Как оказалось, если человек сам не в состоянии адекватно отнестись к критике в виде минусов (и оценить что не так), то скорее всего и прямое указание причин ничего хорошего не даст.

                Хорошо. Будем считать, что вы хотели бы, чтобы разработчики в первую очередь бросили все силы на создание компилятора для языка Swift. Разумно ли это? База существующего кода на C++ намного богаче, чем на Swift. Компиляторы, архиваторы, декодеры аудио/видео/изображений, огромное количество различных библиотек. Полагаю, что и при создании самого Swift не обошлось без C++. То есть от реализации компилятора C++ будет намного больше пользы, чем от компилятора Swift, или Rust, или что там ещё кто-нибудь может захотеть. А когда стандарт будет готов, тогда и сами авторы этих языков смогут создать соответствующие компиляторы под WebAssembly.
                • –3
                  Мне как бы всё равно на минусы (иначе и не пытался бы спорить), но интересна была причина негативного отношения к комменту.
                  Спасибо, вы назвали возможную — непонимание смысла моего первоначального комментария (либо неправильная формулировка комментария, что, в общем-то, равноценно в данном случае – оценивался не тот смысл, который я вкладывал).
                  • +3
                    Думаю, проблема вашего комментария не в том, что его не поняли, а в том, что он выявляет ваше непонимание. Вы не понимаете того, что новый стандарт не пытается сменить основной язык на что-то вроде свифта, а создает возможность для выполнения высокопроизодительного кода в первую очередь. В этой связи, ваш комментарий звучит несколько неуместным, и особенно неуместен из за предложения проприетарного языка для открытого стандарта.
                    • –3
                      Спасибо, что разъяснили мне мои же мысли. ;)

                      И, к слову, Apple пообещали сделать Swift 2.0 опенсорсным.
      • +1
        А за что его любить?
    • 0
      Там просто нет основы как таковой. Вернее она есть, но простому разработчику лезть в неё практически никогда не нужно, как не нужно Swift-разработчику лезть в генерируемый компилятором машинный код, а С++ разработчику в код LLVM. Какая вам разница исполняется ваш код на х86 или ARM и какая вам будет разница исполняется ваш код на JS-движке, JVM или напрямую в машкоды компилируется?
  • +2
    … также планирует запустить библиотеку polyfill… что, очевидно, абсурдно, потому что необходимость в этой библиотеке отпадет, как только браузеры получат встроенную поддержку WebAssembly

    Абсурдно — это запускать технологию, под которую никто не будет писать пока _все_ браузеры на неё не перейдут. Тут всё логично.
  • +2
    Как человек далекий от веба, скажу, что я немного удивлен. Вроде как для тяжелых приложений лет много назад были придуманы Джава-аплеты (компилироваанная Джава) и исполение их в песочнице, предоставляемой браузером. Почему не стали развивать это направление? Чем оно хуже WebAssembly?

    Так же удивляюсь до сих пор, что для самого медленного типа связи, веба, стандартом стал самый длинный формат передачи данных — XML и его призводные: SOUP и т.п. и т.д. Получилось «медленно в квадрате»,
    • 0
      -1 вместо внятного объяснения? Так держать.
      • +6
        Я не минусил, но попробую объяснить. Апплеты, флэш, сервелат,… предлагалют браузер внутри браузера. Оно бажное, небезопасное, плохо адаптированное к операционке пользователя, проприетарное и избыточное. Всё для работы с UI уже есть, зачем ещё это? Нам не нужна отдельная библиотека контролов вместо DOM. Нам нужна возможность написания кросс-платформенной логики, а желательно ещё и производительность.
        Вобщем-то это и есть развитие идеи компилированного кода из апплетов, но «обезжиренное», избавленное от UI и нестандартизованного проприетарного API.
        • 0
          Про Флэш понятно, это полностью свой фреймворк со своим GUI.
          Сервелат — это сервлеты? Они вроде как вообще не про это и испоняются на сервере.
          Теперь к апплетам. Если у апплетов и есть своя GUI-библиотека (от Java), то она явно не проприетарная, а очень даже стандартная и кроссплатформенная, как и сама Java. Но что мешает писать на ней только логику?
          DOM? Я всегда думал, что это стандарт иерархической структуры сложных документов, а также навигации/поиску по ней. Она уже и GUI-контролы включает?
          Еще раз: казалось бы, уж что есть еще более кроссплатформенное, чем Java? Хотя сами исходники закрыты, конечно…
          • +2
            Сервелат — silverlight (то же, что флэш, но Microsoft).
            > уж что есть еще более кроссплатформенное, чем Java
            На iOS её нет в принципе. На Windows нет предустановленной. Включать её в браузеры? Просить ставить отдельно (как было в апплетах) — моветон.
            > она явно не проприетарная, а очень даже стандартная
            Jav-у разрабатывает Oracle, а не коммитет из Microsoft+Google+Mozilla+Apple+ещё некоторых.
            > DOM? Она уже и GUI-контролы включает?
            Кнопочки, поля ввода, взаимодействие с ними ит.д. — всё это включает в себя DOM API, и позволять заменять его категорически не надо.
            И получается — как же это развивать? Отобрать jav-у Оракла, выпилить UI, бОльшую часть стандартной библиотеки, оставить только VM (а зачем, когда есть свой)? По-моему, так проще взять уже имеющуюся JS VM и сделать компиляцию под неё.
          • +3
            > она явно не проприетарная, а очень даже стандартная и кроссплатформенная

            … а Оракл вовсе не судится с Гуглом за то, что гугл написал свою реализацию, да? И не пытается доказать в суде, что номенклатура классов и объектов языка защищается копирайтом?
  • –4
    До изобретения Явы осталось совсем чуть-чуть…
    • +5
      Это намного более низкоуровневая вещь, чем Java. В нее можно компилить C — попробуйте сделать это с JVM…
      • +1
        В нее можно компилить C — попробуйте сделать это с JVM…
        Да вы не поверите

        А человеку минусы поставили незаслуженно.
    • +4
      Это скорее LLVM для веба.
  • –10
    Новые машины тьюринга, исполняющие недоверенный код, новые дырки в реализации. Лучше бы договорились отключить JavaScript в браузере по умолчанию.
    • +4
      Может и HTML с CSS отключить, чего уж мелочиться.
      • –2
        К HTML с CSS претензий нет, технологии простые. Хотя потуги усложнять их есть.
        • +6
          > К HTML с CSS претензий нет,
          > технологии простые.

          Ооок.
  • –1
    Мне вот интересно, можно ли будет из нативного js прозрачно работать с кодом загруженным в этом формате? Например скомпилировать к примеру node.js, отдать клиенту и вызывать node.js api из js скрипта?
  • 0
    Интересно,
    а что с безопасностью?

    Кто-нибудь посоветует работы, посвященные ИБ в WebAssembly?
    • +3
      да только начали драфты стандарта делать, ещё мало материала который четко обрисовывает даже его принципы, какие работы по безопасности?!
      почитайте про NaCl от Google там про выполнение ассемблерного кода скачанного с интернета на процессоре
  • 0
    Web-разработка на Qt? :) Запуск десктопных программ в браузере?!
    • 0
      Уже реальность с emscripten-qt.
      • 0
        да, видел, но webassembly позволит выйти этой идее на новый уровень :)
  • 0
    аллилуйя!
  • 0
    Почему то никто из здесь собравшихся не обсуждает проблему веса всего этого кода, который будет компилироватся. Тот же boost или qt довольно прилично занимают.
    • +2
      Поработаю кепом: не пользуйтесь boost или qt, если их вес вас беспокоит.
  • –2
    Спираль развития вернулась к модели Java — компиляция в bytecode где-то на стороне — исполнение bytecode в песочнице browser — это наверное хорошо.

    Сомнения вызывает конкретно browser как target песочница.

    У каждой конторы и framework теперь будет свой язык. Хорошо это или плохо для web как платформы?

    Иметь возможность написать ray-tracer какой на некоем подмножестве C/C++ и их runtime на web page это наверное хорошо, но что потом делать с результатами? Ни к HTML ни к CSS этот ray-tracer не пришьёшь. И потом весь web sandbox API предполагает GC.
    Вообще идея программировать на C/C++ в web client вызывает больше вопросов чем ответов. Скорее всего в Web была более полезна модель MSIL/CLR как более продвинутой версии Java .class и runtime.

    Но опять же, что делать с HTML/CSS? По идее их тоже надо «раздевать». Чтобы можно было тот же LESS/SASS имплементирвать «нативно» на клиенте. Или скажем иметь возможность влезать в rendering tree и делать свои layout managers.

    Скорее всего мы наблюдаем начало фазы когда продвинутая общесвенность в конце концов осознала факт что никакой комитет не может толком разработать непротиворечивую платформу которая даст шастя всем и бесплатно. Поэтому эволюция возвращается к истокам — вот вам, пацаны, основы в виде ASM/bytecode и AWT, а дальше творите сами — бой покажет.

    • 0
      Место HTML займет WPF уверен в этом. Получится тот же Silverlight только с черного входа, чтоб никто не заподозрил.
      • 0
        WPF в web не будет никогда. Это точно. HTML худо бедно, но semantic markup.
        Я слабо себе представляю что должно по CTRL-C происходить с выделением на «WPF web странице». И что потом с этим делать.
    • +1
      Ни к HTML ни к CSS этот ray-tracer не пришьёшь.

      DOM доступен точно, вероятно и CSSOM. Собственно, всё что доступно JS в браузере должно быть доступно и WA-коду.
      • –1
        Далеко не всё доступно. Например rendering tree недоступно. А без него не пострить свой собсвенный layout manager. Скажем подправить тот недоделанный flexbox (который вообще недоразумение одно ломающее к тому же существующую box model). Свои length units не добавить. И пр.
        • +1
          А JS на странице это сейчас может?
  • +1
    Ребята, я немного не понял. То есть теперь веб-приложения потенциально могут состоять из c++ \ c# \ go \ js кода одновременно? Как все это поддерживать? Возможна ли ситуация, когда над проектом будет работать несколько разработчиков и каждый будет писать на языке, который он знает, в итоге превратив код в кашу?
    • +1
      Поддерживать так же, как сейчас emscripten (или нативные компоненты, скажем, в C#). То есть, некий модуль, который пишется на C++ (ну или что там будет), остальное на JavaScript. Теоретически-то возможно, а практически, это я не знаю, как в C# нативный код добавить — т.е. мимо архитектора сам по себе такое вот так просто не появится.
      • –1
        С emscripten не работал, к сожалению, поэтому не знаю, как там все устроено. Пытаюсь разобраться в такой ситуации: веб-проект писался на C#, C++ и т.д. Ты приходишь устраиваться на работу, как JS разработчик. Сможешь ли ты поддерживать (редактировать, добавлять новый функционал) в модули, написанные на этих языках, зная только JS? Или же будущему веб разработчику нужно будет знать кучу языков?
        • 0
          Ну вот Angular2 пишется на TypeScript. Значит нужно будет знание TypeScript если захочется его исходники понять.
          Да и как бы Angular сам по себе уже и не HTML/CSS/JS в чистом виде, а нечто уже другое — сам по себе другой язык как бы.
          • –1
            TypeScript ничто иное как синтаксический сахар над JS, это немного другое. К тому же у меня язык не повернется сравнить TS и тот же C++, это как минимум неуместно. Поймите, я не против веб технологий и того веб стека, который сейчас есть в вооружении у веб разработчика. Я всерьез обеспокоен приходом низкоуровневых ЯП в веб
        • +1
          Я сейчас работаю над проектом с большим куском логики на emscripten (ради кроссплатформенности). Команда сишников пишет на C++, команда JS-на JS. Приходишь как JS-разрабочик — пишешь фронт-енд на JS. Функционал на C++, если совсем не знаешь языка (или не хочешь), поддерживать, конечно, не сможешь. Когда устраивался, сказал, что знаю и JS и C++, занимаюсь интеграцией этого дела, т.е. одновременно приходится писать и на JS и на C++, но по большей части на JS, на C++ в основном мелочи, обёртки, binding-и всякие итд.
          • 0
            Сложилось довольно скептическое отношение к таким новшествам. Что будет с рынком труда, во что превратится веб-разработчик? Не хотелось бы внезапно (утрирую конечно) в вакансиях увидеть: требуется веб разработчик: уверенные знания js, c++, java, c# опыт от 5 лет. Ясно, что человеку, ушедшему в веб дев в наше время будет сложно переключиться на низкоуровневые языки (да и зачем? я не хочу, я веб-разработчик), чего не скажешь об обратном. По-моему порог вхождения и ур-ни з\п резко изменятся, что думаете?
            • 0
              > По-моему порог вхождения и ур-ни з\п резко изменятся, что думаете?

              Я думаю люди на «низкоуровневых» языках решают другие задачи и вашей зарплате изменения не грозят. Просто теперь в их вакансиях реже будет появляться «JS» рядом с «веб».
            • +2
              Зачем требования знаний js, c++, java, go все вместе к одному человеку? Это трэш какой-то, а не проект, если всем занимается кто-то один. Если действительно оправдана такая сегментация — скорее всего, проект большой, с разными командами, у каждой из которых свой язык (например, сервер на java, клиент на js, логика на c++, тесты на go), и уже становится не так страшно. Максимум может понадобиться знание одного языка + другого на уровне «читаю профессионально литературу, говорю плохо». Т.е. пишет на JS, может выполнить простые задачи на C++ (или наоборот).
              Насчёт сложности переключения на низкоуровневые языки и з/п — хороший веб-дев, который умеет написать быстрый код, и сейчас стоит недёшево, и обычно основы си знает. Скорее всего так и останется, массово это не нужно и требоваться не будет.
            • 0
              Собственно, в подавляющем большинстве веб-проектов используется минимум два языка (не считая языка СУБД) — JS и C++/C#/Java/PHP/Python/ Ruby/… И в вакансиях требования знать оба не редкость, а «будет плюсом» уже давно норма. И к низкоуровневым (по современным меркам) из моего списка только C++ можно отнести, и то с натяжкой.

              • –1
                Плюс то он плюс, но за этот плюс (из моей практики) редко доплачивают. Работадателю будет дороже нанять разработчиков, которые уверенно знают конкретно свою область, проще (дешевле) взять того кто знает что-то хорошо, а остальное на уровне «понимаю\разбираюсь». И это только касательно языка.

                С приходом c++\c#\java и пр. в веб так же появятся тонна библиотек. И разработчику уже надо будет знать не просто язык, а кучи архитектур. Взять нынешнего PHP разработчика. Надеюсь, согласитесь, что не просто найти того, кто отлично может разрабатывать \ масштабировать Drupal, WP, Joomla, Symfony, Laravel, Doctrine, хотя это один и тот же язык. Да, я намешал фреймворки, CMS и ORM, но это именно то, чего я и опасаюсь с приходом ряда языков в веб. Одних JS библиотек\расширений появляется с десяток в неделю.
            • 0
              Все это ради задач с повышенным требованием к производительности, знание этих языков еще ничего не дает, потому что писать производительный код умеет не каждый.
  • –4
    Java-ненавистники активно минусуют упоминания о Java… А будет ведь по сути всё то же самое, только с отставанием на несколько лет. Жалуетесь, что в Java (и в JavaScript) есть уязвимости, позволяющие обойти «песочницу»? Так они и в этой технологии появятся, никуда не денешься. Не один год пройдёт пока всё закроют. Жалуетесь, что «тормозит»? Про JIT-компиляторы безнадёжно упоминать, не слышат. Так и эта технология будет поначалу тормозить. Жалуетесь, что JRE раздута по объёму? Так там смотрите сколько в стандартной библиотеке полезного. Так и в этой технологии — будет либо почти голый рантайм с минимумом библиотек (и пишите всё сами и подгружайте динамически), либо когда всё это обрастёт стандартными библиотеками — точно так же раздуется сам браузер. Жалуетесь, что Java подгрёб под себя Oracle (а ранее Sun)? А вы уверены, что комитет из не очень дружественных компаний будет лучше, а не как в басне про лебедя, рака и щуку?
    • +1
      WebAssembly будет значительно более низкоуровневой, чем байт-код Java. Если в Java байт-код оперирует вполне себе объектами, то в WebAssembly всё будет близко к быстрому машинному коду, с указателями и тому подобными вещами. Не просто же так в качестве основного языка выбрали C/C++. Зато под WebAssembly можно будет собрать и Flash, и JVM, и Silverlight. И всё это будет выполняться в стандартной песочнице браузера. Разве не прекрасно? :)

      Полагаю, что минусы за безграмотность сравнения WebAssembly и байт-кода Java. Здесь уже несколько раз об этом упоминали, а любители Java продолжают писать те же глупости. Такое впечатление, что научились стучать молотком, и пытаетесь забивать им даже шурупы. И вообще непонятно, почему тогда уже не Flash или Silverlight? Flash, кстати, вполне себе позволяет выполнять код, скомпилированный из C++. И он очень популярен, есть на большинстве машин, в отличие от столь упоминаемой здесь Java. Но от него уже сколько лет пытаются избавиться. Всё потому, что это совершенно отдельная сущность, которая плохо интегрирована с браузером, и предлагает много лишнего.
      • –2
        Вы знаете, я ничего не писал про высокоуровневость или низкоуровневость. На что именно вы отвечаете? Ответьте уж лучше на те пункты, что были в моём комментарии.

        И откуда вы так уверены, что там чего-то будет? Пока одни тольно намерения да мечты. В жизни всё разбивается о разные трудности.
        • 0
          Чуть промахнулся, ответ здесь.
        • +3
          И откуда вы так уверены, что там чего-то будет? Пока одни тольно намерения да мечты. В жизни всё разбивается о разные трудности.
          У Google уже есть PNaCl, у него уже есть опыт в разработке таких штук. Просто другие не поддержали его начинания, видимо из-за того что это разработка лишь одного игрока. А теперь гиганты объединились, и вместе они наверняка смогут сделать нечто достойное стандарта. Не объявляли бы о создании такого альянса, если бы не были уверены в том, что у них что-то получится. А если не получится — конечно, жаль, но от этого идея не станет хуже, и JVM от этого не станет привлекательнее.
      • +1
        >> WebAssembly будет значительно более низкоуровневой, чем байт-код Java.

        Не вижу здесь никакой «большей низкоуровневости»: https://github.com/WebAssembly/v8-native-prototype/blob/master/src/wasm/wasm-opcodes.h

        Скорее даже с точность наоборот:
        — Есть отдельные опкоды для Break и Continue, оба из которых на x86 будут скомпилированы в банальный безусловный переход.
        — Зачем-то есть отдельные опкоды для IfThen и для Ternary (вероятно, это flag?foo:bar) с показательным комментарием «TODO(titzer): reduce duplication with kStmtIfThen.» вот здесь: https://github.com/WebAssembly/v8-native-prototype/blob/master/src/wasm/decoder.cc#L683

        >> Полагаю, что минусы за безграмотность сравнения WebAssembly и байт-кода Java.

        И там и там байткод, и там и там виртуальная машина.
        Умеющий абстрактно мыслить да увидит аналогию.

        >> WebAssembly всё будет близко к быстрому машинному коду, с указателями и тому подобными вещами. Не просто же так в качестве основного языка выбрали C/C++.

        Выбор C/C++ в качестве основного языка о наборе инструкций ничего не говорит.
        Как вы и упомянули, под Flash Player тоже можно скомпилировать исходники на C/C++ и это при том, что набор инструкций AVM2 весьма высокоуровневый.

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

        >> Но от него уже сколько лет пытаются избавиться.

        Кто пытается и отчего у него это до сих пор не получилось?
        • +4
          Ну так код на C/C++ можно скомпилировать и в JavaScript. Только в нём нет адекватных подходящих инструкций для типичных операций для низкоуровневого кода типа работы с данными по указателю. Для того чтобы это как-то исправить, придумали asm.js, но получилось всё равно сильно громоздко. К слову, текущая экспериментальная реализация — это по сути asm.js, переведённый в двоичный формат.

          Байт-код Java даже банально не то что указатели не поддерживает, там нет и простейших структур. Даже IL из .NET намного лучше годился бы для такой роли, потому что там разработчики изначально подумали над тем, чтобы предложить широкий набор способов оптимизации, не загоняя разработчиков в узкие рамки, и там целиком поддерживаются как полноценные структуры, так и указатели (но это с ограничениями, если не выходить за пределы управляемого кода).

          То есть компиляцию из C++ в байт-код Java конечно можно сделать (как и в любой другой байт-код или язык), вопрос только в том, насколько он получится эффективным. Байт-код Java — неэффективен, потому что он оперирует только слишком высокоуровневыми объектами и не разрешает работать с сырой памятью, то есть при компиляции в байт-код Java мы вынуждены были бы использовать неэффективные структуры данных для имитации простейших и всегда используемых низкоуровневых операций. Костыль, однако. Говорить о том, что этот байт-код можно расширить и добавить нужное, не приходится. Вспомните какими костылями прицепили туда поддержку generics в погоне за C#/.NET IL :)

          — Есть отдельные опкоды для Break и Continue, оба из которых на x86 будут скомпилированы в банальный безусловный переход.
          — Зачем-то есть отдельные опкоды для IfThen и для Ternary
          Вот именно, что в этих инструкциях нет ничего высокоуровневого — они легко переносятся на любой машинный код без потерь в производительности даже при компиляции под какой-нибудь древний 6502, который ещё в Dendy стоял. В том же FASM подобные вещи легко реализуются на макросах, можно делать полноценные условия, циклы, вкладывать код и т.д. Выглядит это так:
          .if eax<=100 & ( ecx | edx )
              inc ebx
          .endif
          
          Стал ли от этого ассемблер высокоуровневым? Нет, это всего-то макросы, которые генерируют простой код без накладных расходов — руками вы бы написали похожий на сгенерированный этими макросами код. Причём, если вам не нравится что-то в этих макросах — вы можете их изменить. Это я к тому, что эти макросы условий и т.д. не встроены в FASM, а реализованы на его макро-языке. Если что-то легко реализуется на простых макросах, эта реализация практически не имеет накладных расходов (то есть руками вы бы написали примерно то же самое) — значит, это достаточно низкоуровневая вещь.

          Формат у WebAssembly будет не просто линейным набором команд. Там будет готовое к употреблению AST, что сделано для возможности однозначного перевода двоичного формата в текстовый и обратно в двоичный. Но набор то инструкций всё равно создаётся с расчётом на компиляцию из языков типа C/C++, а значит он будет изначально рассчитан для эффективного представления типичных низкоуровневых операций. И то что там условия и циклы будут похожи на макросы FASM ничего не меняет. Все эти плюшки легко и без накладных расходов переводятся в машинный код для любого процессора.

          Кто пытается и отчего у него это до сих пор не получилось?
          Разработчики браузеров? На мобильных платформах с поддержкой уже совсем плохо. На десктопе ещё держится, но пропаганда отказа от Flash не прекращается. А почему его до сих пор используют — это вопрос не ко мне. Я не использую, на некоторых компьютерах, чтобы не возиться с убогим обновлятором Flash, просто отключаю его совсем. Например, мои родители полгода назад начали жаловаться, что youtube перестал работать. Оказалось, что Firefox заблокировал Flash и стал требовать активировать его отдельно для каждой страницы, поскольку его версия устарела. Чтобы не объяснять им процедуру обновления Flash (который почему-то не научился делать это полностью автоматически), я его просто отключил целиком и всё стало хорошо. Аудитория у мобильных ОС уже очень большая, и все основные поставщики контента вынуждены реализовать нормальную работу и без Flash. Так что процесс идёт.
          • 0
            А где написано, что оно будет уметь указатели?
            Если и будет, не вижу в этом ничего хорошего. Вирусню писать можно будет. Должен быть высокоуровневый байткод, где будут команды «взять объект из субстрата», «подергать методы», «освободить». Тогда такой байткод можно при закачке как-то верифицировать, обложить проверками безопасности/прав доступа.
            • 0
              Если это был не сарказм — то какая связь между указателями, верификацией, и вируснёй?

              Вирусы писали даже на VBScript, где указателями и близко не пахнет.
            • 0
              Вирусы выживают только за счёт того, что файловое пространство едино для всех приложений.
              Когда в ОС приложение будет иметь доступ только в разрешенном пространстве, отдельно от других приложений, в этом случае — вирусы просто не смогут ничего сделать (если в самой ОС не будет подходящих дыр). Например — в защищенном режиме процессора у каждого приложения — своя отдельная от других приложений память, с дисковым пространством было бы круто сделать то же самое.

              А указатели, байткод здесь вообще не причём. Любое приложение — это байткод )
              • 0
                и как такое реализуется на практике? тупо указателями же. Транслируем байткод в нативный, получаем обычные указатели. если их обложить проверками, а не вышли ли мы за пределы песочницы, то будет сильно медленнее.
                А вот если можно удостовериться, что некоторые функции из скрипта не вызываются вообще никогда, потому что есть только один способ их вызывать, мы все такие места нашли и проверили, — у меня такому механизму доверия больше.
                • 0
                  Я вас не до конца понимаю. Но попробую ответить.

                  Указатели и вирусы не зависят друг от друга.
                  Вы изучите сначала что такое защищенный режим и как работает страничная адресация. Там отлично описано почему одно приложение не имеет доступ к ОС и к другим приложениям (хотя отлично использует указатели).
                  • +1
                    Я наверное зря употребил слово «вирусы». Любые дыры в безопасности браузера. Межсайтовый скриптинг, исполнение кода, на который не выдали разрешение и т.п. — что угодно вне нормального секьюрного поведения браузера. В частности и вирусы могут юзать такие дыры. Да, может такой вирус и не получит доступ к ОС, но может успеть куда-то распространиться, или украсть приватные данные. Скриптинг работает обычно в процессе браузера, можно его теоритически вынести в отдельный, но чота мне кажется оверхэд там тоже будет неприемлемый.
                    Вот. Ну и раз мы в процесс браузера пускаем какую-то непонятную байду извне в виде бинарника, ну или там байткода, то к ней имеет смысл применять подходы антивирусов (поэтому я и назвал это вирусами) по выявлению нехорошего поведения. И я считаю, что применить такие проверки к чему-то типа лиспа проще, чем к чему-то типа скомпиленной сишки. Обфусцируем код, делаем указатель, который указывает вне песочницы на данные\код самого браузера — и вуаля, делаем свои грязные дела. Если у нас нет вообще способа превратить рандомную цифру в указатель и перейти на этот адрес — то и такой пролемы нет.
                    • 0
                      Вам человек пытался объяснить, что у процесса нет физического доступа к страницам памяти ядра системы или других процессов, за счет того что у них независимая адресация страниц. Единственная возможность это использовать ошибки в коде ядра, которые позволяют в конечном итоге получить доступ к страницам ядра или доступ к исполняемым файлам других программ. Если первое более менее оперативно исправляется, то второе выглядит как большущая дыра, закрывать которую даже не пытаются.
                      • 0
                        вы предлагаете для каждой странички сделать свой процесс? с каких пор межпроцессное взаимодействие бесплатным стало?
                        если мы думаем немножко о скорости, то этот код будет в том же процессе, и не обязательно получать доступ к ядру, чтобы делать гадости. даже если код просто может пережить ту страничку, с которой он запустился — уже можно пилить ботнет. можно украсть приватные данные и тп — ядро для этого не обязательно, в браузере секретов навалом хранится.
                        кроме того, виртуальная память у процессов не на всяком железе может быть. это же всё-таки интернет, там много всякого может быть, опять же, интернет вещей обещают…
                        облегчить статический анализ загружаемого кода всяко бы не помешало
                        • 0
                          Давайте представим, что у вас совершенно дырявый браузер. Да действительно, если мы захватили контроль над браузером, мы можем слить все письма, аккаунты и т.д. Но проблема еще и в том, что мы можем внедрить троян в калькулятор или еще куда нибудь, просто потому что система позволяет каждой программе делать на жестком диске все что ей вздумается. Система была бы намного более защищенной, если бы права доступа к файлам ограничивались по умолчанию папкой установки. Вот о чем речь.
  • +2
    А будет ведь по сути всё то же самое, только с отставанием на несколько лет.
    Это не то же самое. Все пункты что вы написали автоматически становятся бессмысленными, если понять это. Я думал, это будет очевидно из моего комментария.
    • –1
      Не очевидно. Кому очевидно? Слёту сказать «очевидно» — это демагогический приём.
      • +2
        Вы сказали:
        А будет ведь по сути всё то же самое, только с отставанием на несколько лет.
        На что я ответил:
        WebAssembly будет значительно более низкоуровневой, чем байт-код Java. Если в Java байт-код оперирует вполне себе объектами, то в WebAssembly всё будет близко к быстрому машинному коду, с указателями и тому подобными вещами.
        Я указал на существенное различие. Извините, я не знал, что нужно обязательно в конце добавить «вывод: это не одно и то же».

        Вспомнилось, как лет 10-15 назад учителя оценку снижали за отсутствие вывода в лабах :)
  • +2
    Забавно, одна и та же новость привела к двум противоположным выводам:
    1) JS умрет
    2) JS все зохавает
    :)
  • 0
    Интересно, а можно ли будет в хроме вставлять cpp код, что бы тестить скрипты на лету?
  • –1
    ActiveX-ом пахнет… Кроссплатформенным…
  • –2
    Я как и все рад, что программы будут исполняться быстрее. Но для браузерного веба этот прирост скорости будет незаметен. DOM по прежнему останется медленной задницой.
  • 0
    По сути это идея платформы .net там тоже assembly и несколько языков. Давно пора имхо. А вот шутку с C\C++ я не заценил, писать юзер интерфейс на С это уже слишком.
    • 0
      Можете писать на чём угодно и никто WA использовать для интерфейсов не обязывает. Один из стандартных юзкейсов — ядро скомпилировано под WA, интерфейс — обычный HTML/CSS/JS. Общаются между собой прозрачно синхронными вызовами в обе стороны. Ну и логично после C/C++ первым ожидать компилятор JS для WA — многие заинтересованы увеличить быстродействие без переписывания кода.
    • +1
      Посмотрите здесь и поймёте, что никто не собирается заставлять разработчиков писать ui на c++, стандарт предназначен для работы в браузере тяжелых задач вроде игр, видео, возможно какого-то сложного программного обеспечения вроде кад-ов, виртуализация и тому подобные вещи. Плюс дает возможность компилировать в производительный машинный код и другие языки за счет промежуточного низкоуровневого байткода. Более того, джаваскрипт по прежнему будет основным языком для работы на странице — по большому счету, эта новость в первую очередь для тех кто раньше в вебе вообще не работал или пытался компилироваться в asm.js.
  • 0
    Youtube сможет наконец сжимать видео в браузере перед отправкой, фотохостинги — сжимать изображение нужны алгоритмом (а не тем что в canvas) перед заливкой. В прочем, последнее делалось через flash/silverlight/java, но кого это волнует.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.