Design: Webasm может заменить Javascript в браузере?

Я недостаточно знаком с C #, но на самом деле я думаю, что wasm не может полностью взять на себя javascript.

Во-первых, если бы вы попробовали, вы бы обнаружили, что javascript намного быстрее, чем wasm, в некоторых операциях более низкого уровня, таких как «+, -, *, /» и некоторых других связанных с математикой операциях, из-за небольших накладных расходов при вызове из JavaScript. в WebAssembly и обратно. # 1120

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

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

PS:
Независимо от C # или Java, если вы хотите сделать этот язык программирования более дружелюбным для разработчиков, эффективность этого языка будет ограничена из-за некоторых «простых в использовании» функций, таких как «слабый тип» и любых других функций, наоборот.

@Becavalier Может быть, да, если вы пытаетесь вызвать функцию wasm из JS-контекста, накладные расходы существуют, но среда выполнения не взаимодействует с Javascript до тех пор, пока это не требуется исключительно для .. как запрос / манипуляция DOM, встроенный CSS, рисование холста _etc .._ Все выполнение внутри контекста wasm происходит намного быстрее. Задержка появляется, когда вводится JS-мост, например, в случае # 1120 вы пытаетесь распечатать временную метку производительности в контексте Javascript для функции, которая выполняется в контексте wasm, что является дополнительной задержкой.

Популярные фреймворки, такие как Angular2 / 4, который представляет собой полную переработку с использованием Typescript, Android в Kotlin или iOS в Swift, когда за некоторыми фреймворками или языками стоит громкое имя, весь мир пытается принять это изменение.

Итак, суть в том, что существует вероятность того, что JS будет отодвинут на второй план или даже удален с картинки за счет абстрагирования мостов API и переноса среды выполнения в браузере. Webassembly открыл возможность компиляторам других языков конкурировать с Javascript в браузере.

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

Теперь вы можете ожидать, что компиляторы для Интернета заменят транспиляторы, такие как TypeScript, CoffeeScript и т. Д.

Разработчики Javascript, держите пальцы скрещенными . Можно ожидать больших сдвигов в ближайшие годы.

PS: я люблю Javascript и C-Lang

Webassembly открыл возможность компиляторам других языков конкурировать с Javascript в браузере.

Да, действительно, это одна из целей WebAssembly.

Вот цитата из FAQ по

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

• Целые, скомпилированные приложения на C ++, которые используют JavaScript для объединения вещей.

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

Вы уже можете скомпилировать C #, F #, C ++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl и т. Д. В JavaScript.

Вы можете скомпилировать байт-код .NET в JavaScript , вы можете скомпилировать байт-код OCaml в JavaScript , а GWT существует уже 11 лет и используется в больших проектах.

Эти проекты существуют уже много лет. На самом деле это не новость.

JavaScript уже конкурирует с другими языками. WebAssembly просто делает другие языки более эффективными, вот и все.

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

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

Итак, суть в том, что существует вероятность того, что JS будет отодвинут на второй план или даже удален с картинки за счет абстрагирования мостов API и переноса среды выполнения в браузере.

Нет, люди будут продолжать использовать JavaScript.

В течение многих лет для настольных ПК было доступно множество языков на выбор: Python, Perl, Ruby, PHP, Haskell, JavaScript (Node.js), OCaml, C ++, Java и т. Д.

Люди используют множество языков, включая JavaScript. JavaScript никуда не денется.

Даже в ( очень маловероятном) гипотетическом мире, где JavaScript не является первоклассным языком, люди все равно могут компилировать JavaScript в WebAssembly.

Теперь вы можете ожидать, что компиляторы для Интернета заменят транспиляторы, такие как TypeScript, CoffeeScript и т. Д.

Это маловероятно, у людей по-прежнему есть веские причины использовать TypeScript и JavaScript.

Конечно, будут альтернативы TypeScript, и некоторые люди будут использовать эти альтернативы, но TypeScript вряд ли исчезнет.

Я говорю это, потому что уже много лет существуют хорошие альтернативы TypeScript (например, Haxe ), но они никогда не заменяли TypeScript.

4 сентября 2017 года в 03:42 Pauan [email protected] написал:
>

JavaScript уже конкурирует с другими языками. WebAssembly просто делает
другие языки более эффективны, вот и все.

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

@ rossberg-chromium Действительно, вы правы, я забыл эту деталь. Спасибо за разъяснение.

@Pauan Спасибо за подробности. Хотя некоторые из ваших утверждений верны и имеют смысл, я не со всеми согласен.

C # на стороне клиента выглядит многообещающим и убийственным примером полного отказа от Javascript на стадии разработки. т.е. я могу использовать C # для написания полнофункционального веб-приложения без написания кода Javascript. У такого рода фреймворков, основанных на подходе, есть шанс заглушить наследие Javascript, по крайней мере, до некоторой степени.

Вы уже можете скомпилировать C #, F #, C ++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl и т. Д. В JavaScript.

Да, Javascript был на картинке. Но теперь с WASM / Webasm мой мотив компиляции в Javascript изменился. При необходимости можно напрямую скомпилировать в wasm и написать слой маски API или мосты в Javascript, поэтому разработчикам не нужно знать Javascript для разработки веб-приложения с помощью Webapp, я имею в виду чистый Webapp, а не ASP.net, своего рода JSP-фреймворки.

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

Вы уже можете скомпилировать C #, F #, C ++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl и т. Д. В JavaScript.

Хотя многие языки уже могут компилироваться в JavaScript, сможет ли компиляция в Webasm избежать значительных потерь производительности и нагрузки во время выполнения за это? И проблемы с производительностью, если вы скомпилировали виртуальную машину с полным C в Webasm, чтобы сделать это таким образом?

Если использование других языков приводит к неизбежным проблемам с производительностью или к множеству мест, которые нарушают эту языковую спецификацию (по соображениям производительности), в лучшем случае это частичная замена JavaScript, и, как правило, я видел, что они больше использовались для переноса устаревшего кода, чем новый код для «замены» JavaScript »(за исключением CoffeeScript, TypeScript и т. Д., Которые разработаны для удобной компиляции в JS).

Можно ли решить эти проблемы? например, с новым компилятором Ruby -> Webasm и получить сопоставимую производительность с текущим браузером JavaScript?

Чтобы использовать JavaScript и Ruby (с Opal) в качестве примера (как то, что я пробовал и в основном отказался от этого ранее):

В JavaScript с оператором + он позволяет преобразовывать числа в строку, например

5 + " example" === "5 example"

В Ruby намного более строгая типизация, а это недопустимо:

5 + " example"
#TypeError: String can't be coerced into Integer

Так что у Opal есть свой плюс и довольно сложные методы для многих основных типов.

function $rb_plus(lhs, rhs) {
  return (typeof(lhs) === 'number' && typeof(rhs) === 'number') ? lhs + rhs : lhs['$+'](rhs);
}
String.prototype['$+'] = function (r){var t=this,n=arguments.length;return 1!==n&&e.ac(n,1,this,"+"),r=ke.get("Opal").$coerce_to(r,ke.get("String"),"to_str"),t+r.$to_s()}

То же самое для многих основных операций.

# Ruby: if a || b
if ((($a = ((($b = a) !== false && $b !== nil && $b != null) ? $b : b)) !== nil && $a != null && (!$a.$$is_boolean || $a == true))) {

Возможно, теоретически JIT может полностью оптимизировать это, но не думаю, что они близки (не проводил микротест, но для всего прототипа приложения / страницы, которую я сделал, версия Ruby была значительно медленнее), и подобные преобразования, похоже, просто делают Оптимизаторам жизнь тяжелее?

И даже в этом случае некоторые вещи работают неправильно или не поддерживаются (хотя Webasm имеет собственные целые числа, так что, надеюсь, это начало, если компилировать в Webasm, а не на JS):

1 / 2 == 0.5 # Should be 0, Ruby has integer division

str = "Hello"
str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.
puts str # "Hello World"

@nirus

Я могу использовать C # для написания полнофункционального веб-приложения без написания кода Javascript.

Да, и я согласен, что это очень круто (я работаю над языком, который планирую скомпилировать для WebAssembly), но я считаю, что вы уже можете это сделать, даже без WebAssembly.

При необходимости можно напрямую скомпилировать в wasm и написать слой маски API или мосты в Javascript, поэтому разработчикам не нужно знать Javascript для разработки веб-приложения с помощью Webapp, я имею в виду чистый Webapp, а не ASP.net, своего рода JSP-фреймворки.

Действительно, и это было возможно уже много лет. Вам не нужно ждать WebAssembly, можете начать прямо сейчас : asm.js существует уже несколько лет.

@wnewbery

Хотя многие языки уже могут компилироваться в JavaScript, сможет ли компиляция в Webasm избежать значительных потерь производительности и нагрузки во время выполнения за это? И проблемы с производительностью, если вы скомпилировали виртуальную машину с полным C в Webasm, чтобы сделать это таким образом?

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

Позвольте мне кое-что прояснить: asm.js существует уже несколько лет. Это позволяет вам скомпилировать программу на JavaScript, и эта программа будет работать с почти собственной скоростью. Другими словами, вы можете запускать программу с той же скоростью, что и на рабочем столе.

Итак, уже можно было взять язык, скомпилировать его виртуальную машину, среду выполнения и сборщик мусора в asm.js, и затем вы можете запускать любой язык в браузере почти с той же скоростью, что и на рабочем столе. Это было возможно уже довольно давно.

Однако компиляция виртуальной машины, среды выполнения и сборщика мусора означает, что размер файла будет довольно большим (многие мегабайты).

И с JS API (например, DOM) сложно взаимодействовать.

Но некоторые люди все равно это сделали и создали такие вещи, как PyPy.js, который компилирует интерпретатор PyPy в asm.js.

Он работает быстрее, чем CPython (да, действительно! Интерпретатор PyPy, который был скомпилирован для JavaScript и работает в браузере, работает быстрее, чем собственный CPython на рабочем столе!)

Но размер файла довольно плохой (5 мегабайт в сжатом виде, 15 мегабайт в сыром виде).

Таким образом, вы можете скомпилировать виртуальную машину Ruby + сборщик мусора + среду выполнения в asm.js, и это будет очень быстро, но с этими проблемами. Вместо этого люди создают такие вещи, как Opal.

WebAssembly - это следующая эволюция asm.js. На данный момент все, что вы можете делать с WebAssembly, вы можете делать и с asm.js.

Итак, да, вы можете скомпилировать ваш язык + виртуальную машину + среду выполнения + сборщик мусора в WebAssembly, и он будет работать практически с собственной скоростью.

Но, конечно, у него есть те же недостатки, что и у asm.js: очень большой размер файла, и трудно взаимодействовать с JS API.

Между WebAssembly и asm.js есть семь различий:

1. WebAssembly немного (на 5%) быстрее, чем asm.js в целом.

2. WebAssembly значительно (~ 400%) быстрее, чем asm.js, если вы используете 64-битные целые числа.

3. WebAssembly можно анализировать намного быстрее. Это не улучшает скорость выполнения вашей программы, но означает, что время начальной загрузки быстрее с WebAssembly.

4. Размер файла WebAssembly меньше размера файла asm.js (примерно на 10-20% меньше).

5. WebAssembly может в будущем получить потрясающие функции, которых нет в asm.js (потоки, параллелизм, исключения с нулевой стоимостью и т. Д.).

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

7. WebAssembly в будущем получить возможность легко использовать JS API , (как в DOM).

Но даже в будущем по-прежнему необходимо будет скомпилировать среду выполнения VM + вашего языка в WebAssembly, поэтому размер файла по-прежнему будет проблемой.

Если компиляция виртуальной машины + среды выполнения + сборщика мусора вашего языка в asm.js для вас неприемлема, она, вероятно, все равно будет неприемлема даже с WebAssembly.

И если компиляции VM + время выполнения + сборщика мусора на вашем языке является приемлемым для вас, вы уже можете сделать это прямо сейчас с asm.js (и затем легко перейти к WebAssembly позже).

Можно ли решить эти проблемы? например, с новым компилятором Ruby -> Webasm и получить сопоставимую производительность с текущим браузером JavaScript?

Цель WebAssembly - запускать программы на собственной скорости. Другими словами, они запускаются с той же скоростью, что и на рабочем столе.

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

Ruby - довольно медленный язык. Медленные языки и медленные программы все равно будут медленными, даже если они скомпилированы с помощью WebAssembly.

1 / 2 == 0.5 # Should be 0, Ruby has integer division

Это ошибка в Opal, которую можно исправить, просто изменив определение функции $rb_divide .

str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.

Это можно исправить, если Opal скомпилирует строки в массивы JavaScript (которые являются изменяемыми).

@Pauan

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

Поток - очень важная функция для многих языков, библиотек, фреймворков. Без потоков многие приложения, созданные на C ++, C #, java, которые полагаются на многопоточность, не могут просто преобразоваться в webapp, поскольку это может вызвать странное поведение (не говоря уже о другой хорошей вещи, такой как SIMD поддержка _в будущем (?) _). Короче говоря, я думаю, что asm.js недостаточно хорош, ни по производительности, ни по возможности переноса, если он так хорош, должно быть больше библиотек, "портированных" на asm.js давным-давно.

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

@unmellow , чтобы снова развенчать этот миф: от компиляции JS в Wasm не будет никакого волшебного прироста производительности, как раз наоборот. Если вам нужна более высокая производительность, чем могут обеспечить JS-движки, вам нужно выбрать лучший язык.

да, извините, я забыл, я имел в виду, что он будет разбираться быстрее
edit: что-то может случиться, хотя браузер не обновляет свои движки javascript для поддержки
новые версии javascript sense люди могут компилировать в wasm без потери производительности

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

Я вижу, что многие люди скептически относятся к идее замены Javascript на WASM, но одно дело в том, что WASM - это не только производительность. Люди чаще всего забывают о том, что Javascript - это не тот язык, который они хотят (или хотят). Я имею в виду, что, по крайней мере, простой Javascript - это не то, что нужно людям. Все больше и больше людей используют транспиляторы, которые в основном являются компиляторами для сторонних языков. Просто люди перестали полагаться на стандарты и переключились на пользовательские (?) Решения.

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

Кроме того, существует проблема с дублированием усилий. Транспилеры - это компиляторы, а бандлеры - это линкеры. У всех нас веками были эти инструменты. Модули, встряхивание дерева, разделение кода, динамическая / ленивая загрузка, управление активами и т. Д. Ничего особенного нет, но людям нужны новые инструменты, чтобы иметь эти функции только для Интернета, что не подходит для не-веб-решений.

Не похоже, что WASM все изменит за один день. У Javascript сейчас хорошо построенная экосистема, в то время как на других языках нет. Я потрачу время, прежде чем Javascript действительно куда-то уйдет, но это явно произойдет в долгосрочной перспективе.

Javascript движется в том, что я считаю ужасным, поэтому я приветствую замену WASM. Я думаю, что несмотря на значительные улучшения, многие сообщество и руководство за последние несколько лет вводили в заблуждение. Я более чем приветствую подходящий язык, который ... не обязательно займет его место, но станет прямым конкурентом, чтобы мне не пришлось писать эту новую неприятную разновидность JS и его "фреймворков", которые появились.

@spencerudnick Никогда не писала сборку для повышения производительности, которую нельзя получить от C?