Разработчики JavaScript-движка V8 сообщили (https://groups.google.com/forum/#!topic/v8-users/PInzACvS5I4) о реализации экспериментальной поддержки WebAssembly (https://github.com/WebAssembly/design/blob/master/README.md) (WASM), не зависящего от браузера универсального низкоуровневого промежуточного кода для выполнения в браузере приложений, скомпилированных из различных языков программирования. Компоненты для выполнения байткода WASM, JavaScript API для доступа к функциональности WebAssembly и сопутствующие элементы инфраструктуры, такие как компилятор из C/C++ в WebAssembly, приняты (https://chromium.googlesource.com/v8/v8/+/4c5b3609fd4de3e0c1...) в кодовую базу V8 и проекта Chromium.
Реализация WASM, интегрированная в V8, основана на генерации движком WASM промежуточного кода, единого с оптимизирующим JavaScript-компилятором TurboFan, что позволило добиться высокой скорости компиляции и высокого качества кода за счёт задействования типовых и проверенных подсистем JIT и runtime. Интеграция также дала возможность обеспечить взаимодействие между WASM и JavaScript без дополнительных прослоек.По своим задачам WebAssembly во многом напоминает PNaCl (Portable Native Client) и Asm.js. Основное отличие от Asm.js состоит в том, что WebAssembly является бинарным форматом, не завязанным на исходных текстах JavaScript и позволяющим выполнять в браузере низкоуровневый промежуточный код. В отличие от PNaCl, промежуточный код WASM не является машинным кодом и не изолирован в отдельной виртуальной машине, а выполняется с похожим на JavaScript уровнем изоляции. Среди основных задач WebAssembly выделяется обеспечение переносимости между браузерами, предсказуемость поведения и идентичности выполнения кода на разных платформах. Использование WebAssembly также позволит существенно сократить размер приложений, благодаря компактному промежуточному коду, и увеличить скорость декодирования.
URL: https://groups.google.com/forum/#!topic/v8-users/PInzACvS5I4
Новость: http://www.opennet.me/opennews/art.shtml?num=43651
Быстрее бы уже, не терпится выкинуть JavaScript в окно.
JS никуда не денется после прихода WebAssembly. Сразу все переползут на C/C++? Это утопия. С php вон уже сколько лет слезть не могут.
Нет, даже в мск. А вот за 75 тр это можно
Да ну, на хедхантер искали пхпшника за 100 штук, масяца 2 назад.
> JS никуда не денется после прихода WebAssembly. Сразу все переползут на C/C++?
> Это утопия. С php вон уже сколько лет слезть не могут.Компилятор в WASM для других языков запилить труда не составит, особенно для Lisp и JVM-based.
> труда не составитсоставит. комменты писать - не мешки ворочать.
> не терпится выкинуть JavaScript в окно.Чем он вам так не угодил? Интернет не любите?
Ага. Сидит в сети и плачет, сидит и плачет =)
Почему только интернет? Поглядите логи графической сессии в линукс. Там куча ошибок js вылезает, а за ними и некорректная работа контролов. В мелочах. И при таком подходе к разработке, который обусловлен языком ( расслабляет девелоперов), отладить это невозможно.
Поглядел. Никакого JS не вижу. Наверное не надо gnome 3 было пользоваться.
>не зависящего от браузера универсального низкоуровневого промежуточного кода для выполнения в браузере приложений, скомпилированных из различных языков программированияно ЗАЧЕМ?
нужно быстро и под систему - используй с++ и компилируй бинарь.
нужно календарик или кнопочку на сайт - используй js.
зачем на js писать ВСЁ и в браузере потом страдать?
Чтобы календарик был в 3D и со спецэффектами.
Как этот
http://www.duarteramos.pt/media/share/DuarteRamos_2016Intera...
Быстрее обрабатывается браузером, меньше занимает места. Догадываюсь, что и компилятор в webassembly сделать проще
> скомпилированных из различных языков программирования
> зачем на js писать ВСЁ и в браузере потом страдать?Ну ты понял. WA, наоборот, в какой-то степени открывает дорогу конкурентам JS.
> нужно быстро и под систему - используй с++ и компилируй бинарь.Ага, юзеры так и побегут запускать мой бинарь. Браузер в первую очередь хорош тем, что при запуске скриптов обеспечивается приемлемая безопасность. Какое бы г-но ты не открыл, закроешь вкладку - и нет его.
Я хотел бы уточнить: а какие именно ограничения накладывают браузеры на исполняемый js-код? Я так понимаю, что скорее всего этот код может работать сетью. А может ли он работать с файлами? Подскажите, что и где почитать об этой самой безомасности, которую браузеры нам предоставляют.
> сетью. А может ли он работать с файлами? Подскажите, что и
> где почитать об этой самой безомасности, которую браузеры нам предоставляют.По стандартам с файлами только после диалогового окна на разрешение чтение(записи)файла .
Но в новых стандартах в браузерах разрешили создавать мини базы данных - и средств настройки этого безобразия пока нету :-(
В первую очередь код разных сайтов изолирован "пространством" самих этих сайтов. То есть, загружая и запуская веб-приложения - точно уверен, что они друг с другом не "воюют", не пытаются украсть друг у друга пароли и другие данные, подсунуть что-то своё и т.п. То есть в целом, это значительно более здоровая среда, чем полноправные приложения под системной учёткой пользователя с доступом ко всем файлам и в сеть, которые пользователь не может полноценно проверить (и не важно - из-за отсутствия исходников, квалификации или времени на всё это безобразие).
В первую очередь это приложения, которые пользователь не может контролировать. Он зачастую даже не понимает, когда они запускаются, не может остаться на определённой версии, не может модифицировать поведение за рамками разрешённого разработчиком.А вопрос невозможности проверки пользвателем нормальных приложений решается делегированием - сисадмину, а в линуксе - ещё и маинтайнерам.
Плюс "не воюющие" сайты в результате не могут толком взаимодействовать. Гугл когда-то хотел протолкнуть WebIntents как стандарт, но не вышло. В результате - многократная реализация одного и того же, причём, как правило, в весьма куцем виде. О зоопарке интерфейсов вообще скромно умолчим.
В основном потому, что нужно сложное приложение, над которым пользователь (и система) не имеет контроля. Это, насколько я понимаю, основная движущая сила развития веб-приложений.
Потому что теперь браузер — это доминирующая операционная система.
и ещё - они же изобрели JVM!?
байткод и виртуальная машина и раньше были, WASM более высокого уровня - "Абстрактное синтаксическое дерево".
> более высокого уровня -
> "Абстрактное синтаксическое дерево".Lisp, значит, наконе-то?
Любой скриптовый язык, созданный и до и после jvm.
> Любой скриптовый язык, созданный и до и после jvm.Практически ни в одном "скриптовом языке, созданном от и до" *нет* трансляции в AST. В реализации, да. Посмотрит, например, на трудности переписывания "рукописного" интерпретатора cpython в компилятор pypy.
При этом программирование на lisp-е можно рассматривать практически, как написание этого самого AST.
---
Или я не понял Вашей сложной без-глагольной реплики: любой ... язык $ЧТО? Эмм, они все изобетают лисп? Ну, да, десятое правило Гринспена.Только вот AST-то по жизни в компиляторах, да в лиспе. Хорошо-хорошо, и в V8.
...шутка как-то затянулась.
Зато интерпретаторы этих скриптовых языков написаны обычно на С, их запустить в браузере можно уже сейчас - но медленнее, чем хотелось бы. Фактически, WebAssembly даст инфрастурктуру, на которой их модифицированные версии можно будет гонять достаточно быстро - то же управление памятью, эффективное взаимодействие с DOM и так далее.Поэтому да, по факту - любой скриптовый язык - в том смысле, что его можно будет исполнить с достаточной производительностью.
А лисп... да пофигу на лисп. Со всей своей крутостью (с которой я не спорю) на практике эта штуковина больно уж неудобна по причине адски бедного синтаксиса.
Tcl же
>Lisp, значит, наконе-то?Под конём.
>>Lisp, значит, наконе-то?
> Под конём.Клавиатура с конём поведут меня к прокурору. //Не напоминайте!? Прошу!
> "Абстрактное синтаксическое дерево"«Двустороннее преобразование Лапласа».
Я не ошибся, это ж в этой ветке — конкурс на самый бессмысленный умно звучащий комментарий?
> Я не ошибся, это ж в этой ветке — конкурс на самый
> бессмысленный умно звучащий комментарий?Ты не ошибся. https://en.wikipedia.org/wiki/Abstract_syntax_tree В глазах смотрящего.
> https://en.wikipedia.org/wiki/Abstract_syntax_tree В глазах смотрящего.Ну, я знаю, что такое AST. Однако, смысл сего словосочетания в контексте целого комментария мне не ясен.
> целого комментария мне не ясен.Теперь мы в тебе не сомневаемся совсем.
Флеш уходит. ПНаХ никому не нужен. Видать кому-то очень не хватает возможности подсунуть клиенту нечитаемый бинарник. :-)Нормально закешированый JS в WebAssembly не нуждается.
Справедливости ради стоит заметить, что нечитаемость легко достигается и при использовании только JS.
Это правда — часто не хватает возможности отформатировать код прямо на странице view-source:, приходится копировать в редактор. Но всё же это легче чем проводить диззассемблирование и потом гадать над кодом вида if(0) { asd.324&*(#sdvc } — как оно вообще скомпилировалось?
В хроме. F12 -> вкладка "Sources" -> в левом нижем углу кнопка "{}" (Pretty print).
> "{}" (Pretty print).Попробуй это сделать на коде выданом emscripten.
Это помогает ровно до тех пор, пока код хорошо не обфусцируют. Благо такая пакость редво стречается, а в основном попадается eval(function(p,a,c,k,e,d){...}) и пободные безобидные штуки, легко разворачиваемые в исходый код.
*редко
> Справедливости ради стоит заметить, что нечитаемость легко достигается и при использовании только JS.Да, но WebAssembly — удобно-нечитаемый формат.
> Да, но WebAssembly — удобно-нечитаемый формат.Удачи в чтении того что выдал emscripten. Там такой чудный код, вида b158=15; a12=45; c81=25. Куда до него ассемблерной распечатке.
> Флеш уходит. ПНаХ никому не нужен. Видать кому-то очень не хватает возможности
> подсунуть клиенту нечитаемый бинарник. :-)
> Нормально закешированый JS в WebAssembly не нуждается.А нахрен в большинстве случаев нужна читаемость изолированного приложения? Либо доверяешь данные (которые сам же собственноручно предоставляешь поставщику услуги), либо не доверяешь. Каким образом он эти данные будет жевать - это уже его проблемы. Никто же не закатывает истерик за нечитаемость серверной части кода? :-)
Во-первых, закатывают. AGPL не зря придумали. Во-вторых - читаемость = модифицируемость. Вон, для того же youtube не зря есть масса браузерных расширений, подправляющих его поведение.
Оно не читаемо не больше, чем asm.js, при этом меньше по объёму и быстрее парсится браузером. Несколько мегабайт джаваскрипта - это вешаться можно. И это вполне реальный случай.А вопрос "зачем" исчезает, как только оказывается, что нужно делать что-то, на чём сборка мусора JS сходит с ума, или хотя бы где нужен эффективно реализованные структуры данных вроде графов. С объёмом данных, скажем, мегабайт 500. asm.js в помощь в таких случаях - но у него своих костыльных ограничений предостаточно, а вот WebAssembly - это именно asm.js done right.
В общем, есть планка объёма кода/данных, после которой джаваскрипт не справляется. Другое дело, что такое вообще-то надо в нормальных десктопных приложениях реализовывать, но тренд сейчас такой уж.
Я не стесняюсь таки спросить, на кой надо отдавать клиенту 500 мегабайт данных в браузер для разовой обработки? чтоб потом жалиться на огнелиса, что он ест овер чем дофига памяти?
Представьте себе, что там полноценный графический редактор. Или игра какая. Или офисный пакет с адовых размеров документом. А память - закроете вкладку - отдаст.WebAssembly - в основном именно о поддержке "больших" приложений, аналогичных десктопным. И, судя по спеке, они там замахнулись не только на браузер, а на "переносимые приложения в песочнице" в целом. Что, в общем, гнусно - но эта гнусность к техничским плюсам и минусам WebAssembly отношения не имеет.
> на "переносимые приложения в песочнице"Должно же это когда-нибудь у кого-нибудь получиться.
У этих не получится - следующие будут пробовать."За ними другие приходят
Они будут тоже трудны"
Ну, мне всё-таки ближе модель репозиториев, маинтайнеров и свободного софта. все эти "песочницы" создают слишком много проблем в плане взаимодействия, не решают основную проблему - недоверие создателю софта и создают у пользователя иллюзию безнаказанности.
> Несколько мегабайт джаваскрипта - это вешаться можно.Веб должен быть гипертекстовым, а не гипертолстым. Аудио-, видео- и даже текстовым редакторам — место на компьютере, а не в браузере.
>> Несколько мегабайт джаваскрипта - это вешаться можно.
> Троль должен быть виндогэдэишным, а не гипертолстым. Аудио-, видео- и даже GNU
> имаксу -- место на компьютере, долой браузерé, ситуайён.//trolled-over
как думаешь, тебя кто-то кроме тебя самого понимает? :)
> как думаешь, тебя кто-то кроме тебя самого понимает? :)Тебя утешает, что таких, как ты много? Ну, ничего-ничего.
Unreal Engine оплатил для своих игруль в IE?
Сколько можно переизобретать виртуальную машину? И ещё рассказывать сказки про безопасность, скорость, малый объём.
Сколько можно быть попугаем?
Про строгую статическая типизация можно забыть, теперь баги удвоятся.
Наоборот, вообще-то. В сущности, сейчас единственные отработанные пути генерации WASM - компиляция сишного и плюсового кода через Emscripten или преобразование готового asm.js. Оба варианта строго статически типизированы. а дальше - там, конечно, хоть интерпретатор Питона можно будет запустить (можно и сейчас, но тормозит), но хуже, чем сейчас, определённо не станет.
Нет. Проверка типов происходит на этапе компиляции, соответственно, вы можете использовать любой язык с любой системой типов, компилятор которого умеет генерировать байткод webassemble (или если будет бэкенд для llvm, то можно будет компилятор языка -> llvm ir -> webassembe ir). Теперь можно будет писать веб приложения на нормальных языках.
кто нибудь обьяснит, что хрень это WebAssemby?
Ассемблер для Web, что непонятного-то. Он будет исполняться в браузере, в него будут компилироваться другие языки, на нем самом никто писать не будет.
Если кратко, то ты сможешь запускать в браузере обычные программы и игры. Т.е. допустим есть у тебя игра Need For Speed и программа Ableton - если авторы перейдут на WebAssembly, то ты сможешь их запускать прямо в браузере. Так понятнее?
писать сайты на ассемблере
> кто нибудь обьяснит, что хрень это WebAssemby?Это рантайм для веба. Вместо извращений с JS и emscripten.
а в интерете нет ни одного примера использования этого WebAssembly (wasm).....есть только-лишь примеры того как бинарный формат (wasm) конвертируется в рантайме (средствами js, при открытии web-страницы) -- в формат AsmJs для последущего выполнения (выполнения AsmJs).
наиболее яркие примеры -- "AngryBotsPacked" и "PlatformerGamePacked" -- в них используется обычный формат AsmJs, запакованный в wasm-бинарник.
--------------------------------------------------
тык вот -- о чём это я -- а вот о чём!: вот написали новость -- "В JavaScript-движок V8 добавлена поддержка WebAssembly".
а как именно воспользоваться этой поддержкой? что именно нужно вызвать в V8, для того чтобы обработать wasm в режиме "native support"?
(и вообще -- точно ли её туда добавили, эту самую поддержку?)
просматривая исходный код полифиллов -- можно сделать вывод что там сразу происходит преобразование в AsmJs даже без проверки на возможность web-браузера нативно что-то сделать с форматом wasm
--------------------------------------------------
судя по https://github.com/WebAssembly/design/blob/master/Modules.md
использовать wasm-файлы можно будет -- через <script type="module">...</script> или importScripts внутри Worker. (или конструкция import , которая должна появиться во времена ES6)
Да забей пока, оно ещё совсем экспериментальное, десять раз поменяется. Плюс, TurboFan в даный момент - довольно бажная штука, с тем же asm.js иногда пессимизирующая так, что скорость на порядок падает, а то и просто чёрт знает что испольняется. Ждём нормальную поддержку (по факту - отдельный от JS движок).
Да лишь бы он был реально переносимым и кроссбраузерным, а то ж эти четыре упёртых барана как всегда не смогут согласовать стандарты и понапихают каждый своих фич, в итоге никакой совместимостью там даже пахнуть не будет.
четыре? два же, и при этом второй загибается
Над проектом работают Google, Microsoft, Mozilla и Apple. Как думаете, смогут они договориться и все дружно потом придерживаться единого стандарта? Особенно учитывая, что MS уже сейчас объявила, что WebAssembly будет поддерживаться только Edge, но не IE. А что ж дальше-то будет?
А что не так? IE скоро сдохнет в любом случае, чего его развивать? Страшнее, чем нынешние различия между, скажем, компиляторами C, не будет - а такого уровня проблемы вполне решаемы.
Сначала они кукарекают про то как ява и флеш не нужны, а потом сами же пытаются вставлять бинарники в веб и это типа круто потому что не флеш. Ох уж эти веб-хипстеры, лицемерие да и только!А мне вот эта хрень очень напоминает ActiveX. От которого все тоже плевались и плюются. Ах, ну да, это же Майкрософт изобрёл, а не Гугл, конечно, это всё меняет...
Веб ассембли работает на том же уровне изоляции, что и жс и имеет тот же апи, насколько я понимаю. Джава и флеш это внешние для браузера плагины, предоставляющие свой апи. Такой бинарник ничем не будет отличаться от минимизированного проприетарного скрипта на жс.
ЖС это вообще ошибка. Изначально надо было включить вм в браузер, и компилировать в её байткод код любом языке.
JVM в браузер не мешало воткнуть ничего.
И завязаться на оракл и монструозную махину, рассчитанную на сервер и даже память отдавать не умеющую.
10 лет назад, когда этот вопрос был актуален, вместо Oracle был Sun, являвшийся корпорацией добра, и практически каждый современный телефон был завязан на JME, и всем было счастье, и никто не страдал. Может быть, ты не застал те времена.
Куда б я делся :-) И как раз потому, что J2ME иметь дело пришлось, знаю, что это было убогое и прожорливое (для своих возможностей) окружение, с несовместимостями, вынуждавшими держать штабеля телефонов и тестировать на каждой физической железке отдельно.Ну и насчёт того, что связываться со штуковиной, завязанной на одну контору, не надо - тоже время показало, что это правильный подход.
Ну а кроме того, десять лет назад и веб-приложений как таковых ещё особенно не было, и необходимость полноценной VM в браузере была ни черта не очевидна.
>убогое и прожорливое ... с несовместимостямиОно не было идеальным, но прекрасно выполняло свои задачи, не нужно.
>связываться со штуковиной, завязанной на одну контору, не надо
Время показало, что советы и разработчики прекрасно покупаются заинтересованными сторонами, а большие компании неплохо заботятся о крупных клиентах, которые могли бы купить советы и разработчиков (если это не офигевший Google, конечно же, назвавший свое отсталое огороженное недоразумение "Java VM" без разрешения), так что все это смысла не имеет.
>десять лет назад и веб-приложений как таковых ещё особенно не было
Они начинали появляться. Очевидно, заботиться размещением JVM в браузере нужно было слегка заранее.
Оно хреново выполняло свои задачи. Оно запускалось по 15 секунд, было огорожено где надо и где не надо, имело безумную политику сертификации приложений и, как я говорил, очень проблемно в плане совместимости.Кто там какие советы и разработчиков покупал - не знаю. Зато знаю, что веб - это не о "крупных клиентах", а о самоорганизовавшемся хаосе, и пытаться его забить в рамки одного решения - искать проблемы, тот же IE был наглядным примером. Да и вообще - стандарты должны быть общими, а не реализации, иначе застой и выкручивание рук гарантированы, вопрос только во времени.
Что до конфликта гугла и оракла - лично мне здесь ближе позиция "оофигевшего гугла". Если оно компилирутеся обычным javac, а уже потом во что-то транслируется - по моему скромному мнению это всё же Java. А какие там батарейки-библиотеки прилагаются - дело, в общем, второстепенное.
А насчёт "заранее" - такое работает, когда есть какой-то план, а здесь - типичное стихийное развитие, скорее даже напоминающее революцию (если вспомнить историю WHATWG).
> По своим задачам WebAssembly во многом напоминает PNaCl (Portable Native Client) и Asm.js. Основное отличие от Asm.js состоит в том, что WebAssembly является бинарным форматом, не завязанным на исходных текстах JavaScript и позволяющим выполнять в браузере низкоуровневый промежуточный код.Что-то мне это напоминает. Постойте-ка, дайте подумать... А! Конечно же - WORA (Write Once, Run Anywhere). Конечно-конечно, не прошло и двадцати одного года, как то же блюдо, но под другим соусом. Браво, маэстры WASM! Перехватили всё-таки инициативу после затягивания петли на шее рабочего решения.
> Перехватили всё-таки инициативу после затягивания петли на шее рабочего решения.Развейте Вашу мысль: Оракел затянул на шее, Гугель перехватил. И что? Сорвите же покровы? Раскройте суть!
Очевидно, изенька имеет в виду, что проклятый гугль выкинул жабоплугин с нпапи и навязал всем конкурирующее решение. В действительности же, рабочее решение для кучи продуктов, приносящих деньги, похерено, а на новом добреце будут только трояны писать.
> Очевидно, изенька имеет в виду, что проклятый гугль выкинул жабоплугин с нпапи
> и навязал всем конкурирующее решение.После "встречи в суде" с оракелем, я даже готов понять сей ход. Мозиле заодно npapi прищемили. Пауки в банке, ядрёна...
> В действительности же, рабочее решение для
> кучи продуктов, приносящих деньги,
> похерено, а на новом добреце будут только трояны писать.Весь веб-два-нуль и далее оно ж и есть: троян-транспорт малварь.
Загрузить неизвестно что неизвестно откуда из интернетов и _исполнить_ в броузере (и молиться, что в этом нагромождении буферов, парсеров, свистоперделок и пр. (css, js, voip, more&more&more included; даже animated gif!) и пр и пр, (и несистеных патченых-бандленых библиотек, да) ничего не сбежит из "кастрюльки" песочницы с этим варевом). Медиа продАвцы, адвАреры и их друзья проприерасы, строители брозеров, знают, что делают с _вашим_ интернетом...
Ну, можно и так сказать... если внаглую проигнорировать все детали. Например, то, что на этой платформе запускается сишный код. То есть, по факту, там (с небольшими модификациями) запускается код на любом языке, с любыми парадигмами. У меня есть некоторый опыт работы с переводом на asm.js довольно сложной штуки на C - и оно действительно работает с приличной производительностью (не считая IE, правда - как всегда). С WebAssembly будет ещё лучше. А вот что-то подобное на джаве я слабо представляю.
Ясный пень, ты ведь кроме страшных баек о жабе, рассказанных в курилке старшими MVP о программировании для jvm ничего не знаешь.
Мать вашу, вот все всегда, понимаешь, в курсе, что я видел, а что нет. Я, если что, с энтерпрайзом не первый год работаю. Вот там жаба на месте - монстр, но стабильный, дубовый и предсказуемый. А вот приличных десктопных приложений на JVM я не видел ни разу, это да.Я вообще не понимаю, что вас так всех задевает, что некая технология имеет свою нишу и вне её - ни хрена не оптимальна? Нормальная же ситуация. В браузере завязываться на VM, допускающую довольно ограниченный набор подходов к написанию кода, глупо. Не дать возможность удобного портирования огромного мешка кода, уже существующего на различных языках - глупо вдвойне. Ну просто потому, что веб и жив за счёт анархии, разнообразия всего и вся и возможности что-то дёшево сделать, иногда поступаясь качеством.
Ок
> что нет. Я, если что, с энтерпрайзом не первый год работаю.
> Вот там жаба на месте - монстр, но стабильный, дубовый и
> предсказуемый. А вот приличных десктопных приложений на JVM я не видел
> ни разу, это да.Меня, как админа локелхостика, само-переучившегося в админа линухх-сервера, раздражает разделение десктопа и сервера. Оное против B) моей бизнес-стратегии.
И проприертарь (1 апстрим без независимого сообщества) тоже раздражает, по другой причине... И майкросоуфты с оракелами и гугелями этого мира -- по третьей...
Да, тараканы, да, локалхостик, да, непрофессиональненько. //И +1 Вам за "стабильный, дубовый и предсказуемый" aka _работает же_.
А что раздражаться? Десктоп и сервер - это разные условия. Как по надёжности железа, так и по режиму. Норма для сервера - одно приложение, долго крутящееся и потребляющее более-менее одно и то же количество ресурсов. Здесь разные JIT могут хорошо себя показать и можно приложить усилия, чтобы оттюнить всё под конкретную задачу, и делает это квалиифицированный персонал. А на десктопе, когда постоянно что-то запускается, гасится, хаотически меняется нагрузка - и впридачу нормально следить за всем этим часто некому. Понятно, что для разных условий решения тоже разные.Раздражение - это за пределами ТЗ. Проприетарь без независимого сообщества - риск, да. А вот когда собирается шайка майкрософтов, гуглей и чёртзнает кого ещё - это уже не риск. В том смысле, что могут сделать и криво (а могут - и нет), но тупят они долго и моментально всё угробить так, чтобы спрыгнуть некуда было - не сумеют, а скорее всего - вообще довольно долго тащить будут даже окровенно замшелые решения. В любом случае, WebAssembly ни в чём не хуже, чем существующий сейчас asm.js, но существенно менее костыльно. Единственное, где можно ждать проблемы - если эти товарищи всё попытаются в таком формате распространять. Но от засилья винды и припроетарного софта на ней это, вобщем-то, ничем не отличается.
Да, еще. "Стабильный, дубовый и предсказуемый" - это не о "работает же", а о том, что если не хотеть странного, то очень хорошо понятно, сколько надо вложить, чтобы работало и чтобы дописать такую-то фичу. И после этого результат с хорошими шансами будет именно тем, что ожидали.
> В браузере завязываться на VM, допускающую довольно ограниченный
> набор подходов к написанию кода, глупо. Не дать возможность удобного
> портирования огромного мешка кода, уже существующего на различных языках - глупо
> вдвойне.Не троллинга ради. Как VM ограничивает подходы к написанию и мешает портированию огромного мешка кода?
Пиши себе новый бекенд для GCC дающий на выходе байткод для browservm и готово. Ну или свой компилятор с нуля...
Я не в курсе, как это работает, но разве портирование того огромного куска C на asm.js (о котором ты упоминал) как-то принципиально отличалось?
Я имел в виду, что конкретно JVM - ограничивает, так как её байткод жестко завязан именно на джавовскую объектную модель. Там опкоды вида "вызвать метод интерфейса" и тому подобное.asm.js и его наследник WebAssembly в этом плане выглядят лучше - там достаточно низкоуровневый код, на котором можно сделать многое, плюс для WebAssembly в планах расширения, направленные именно на упрощение поддержки различных парадигм, вроде TCO, coroutines, низкоуровневого доступа к стеку и т.д.
А, если речь о JVM, то понятно. Спасибо.
Сколько можно переизобретать active script?
> Сколько можно переизобретать active script?Предыдущие попытки напомните. Больше ремейков джавы было, на моей памяти.
Уже сейчас народ пишет на других языках (TypeScript, ClojureScript, CoffeeScript, свежие версии EcmaScript) и компилирует в JavaScript. Думаю (и, наверно, надеюсь), что всё идёт к тому, что JavaScript вообще перестанет быть чем-то особенно "родным" для браузера и присоединится на общих правах к этому списку, а компилить все сразу будут в байткод.
Лишь бы на JS не писать. Неосиляторы.
даешь 100500 языков для написания менюшек!
Для менюшек-то и джаваскрипта хватает. Только сейчас в браузере отнюдь не только менюшки...