Design: Webasm은 브라우저에서 Javascript를 대체할 수 있습니까?

나는 C#에 익숙하지 않지만 실제로는 wasm이 자바스크립트를 완전히 인수할 수는 없다고 생각합니다.

먼저, 시도했다면 JavaScript에서 호출할 때 약간의 오버헤드 때문에 "+,-,*,/" 및 기타 수학 관련 연산과 같은 일부 하위 수준 연산에서 JavaScript가 wasm보다 훨씬 빠르다는 것을 알게 될 것입니다. WebAssembly로 그리고 다시. #1120

둘째, 웹 개발자들은 이미 자바스크립트와 그 문법에 익숙했기 때문에 웹이 아닌 다른 개발 언어로 웹 앱을 구축하는 것은 불필요하고 어렵습니다.

마침내 " Binary AST "의 도움으로 현재 웹 응용 프로그램의 성능은 해당 응용 프로그램에 대한 수정 없이 새로운 수준으로 향상됩니다.

추신:
C#이나 Java에 상관없이 이 프로그래밍 언어를 개발자에게 훨씬 더 친숙하게 만들고 싶다면 "약한 유형"과 같은 일부 "쉽게 사용하는" 기능과 다른 기능(반대의 경우도 마찬가지)으로 인해 이 언어의 효율성이 제한될 것입니다.

@Becavalier JS 컨텍스트 오버헤드에서 wasm 함수를 호출하려는 경우 예일 수 있지만 런타임은 DOM 쿼리/조작, CSS 인라인, Canvas 페인트와 같이 독점적으로 필요한 경우가 아니면 Javascript와 통신하지 않습니다. _etc.._ wasm 컨텍스트 내에서 일어나는 모든 실행은 상당히 빠릅니다. 지연은 #1120의 경우와 같이 추가 지연인 wasm 컨텍스트에서 실행되는 함수에 대해 Javascript 컨텍스트에서 성능 타임스탬프를 인쇄하려고 하는 것과 같이 JS 브리지가 도입될 때 그림으로 나타납니다.

Typescript, Kotlin의 Android 또는 Swift의 iOS를 채택한 완전한 개정판인 Angular2/4와 같은 인기 있는 프레임워크 또는 일부 프레임워크 또는 언어 뒤에 큰 이름이 있을 때 전 세계적으로 변경 사항을 채택하려고 합니다.

따라서 요점은 API 브리지를 추상화하고 브라우저에서 런타임을 포팅하여 JS가 제외되거나 사진에서 제거될 가능성이 있다는 것입니다. Webassembly는 다른 언어의 컴파일러가 브라우저에서 Javascript와 경쟁할 수 있는 문을 열었습니다.

처음에는 V8 및 기타와 같은 VM에서 실행하기 위해 JS 코드를 보다 효율적으로 만드는 기술을 채택했지만 이제는 JS 코드를 뛰어넘을 수 있는 어셈블리 코드를 작성하고 컴파일할 수 있습니다.

이제 TypeScript, CoffeeScript 등과 같은 변환기를 대체하는 웹용 컴파일러를 기대할 수 있습니다.

Javascript 개발자, 손가락을 교차 시키십시오. 앞으로 몇 년 동안 큰 움직임을 기대할 수 있습니다.

추신 : 저는 자바스크립트와 C-Lang을 사랑합니다

Webassembly는 다른 언어의 컴파일러가 브라우저에서 Javascript와 경쟁할 수 있는 문을 열었습니다.

그렇습니다. 그것이 WebAssembly의 목적 중 하나입니다.

다음은 WebAssembly FAQ 의 인용문입니다.

WebAssembly는 시간이 지남에 따라 많은 언어를 웹으로 컴파일할 수 있게 되지만 JavaScript는 엄청난 추진력을 가지고 있으며 위에서 설명한 것처럼 웹의 유일한 동적 언어로 남을 것입니다. 또한 JavaScript와 WebAssembly는 여러 구성에서 함께 사용될 것으로 예상됩니다.

• JavaScript를 활용하여 모든 것을 결합하는 전체 컴파일된 C++ 앱입니다.

다른 언어 는 수년 동안 JavaScript로 컴파일되었으며 WebAssembly가 있든 없든 계속 그렇게 할 것입니다.

이미 C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl 등을 JavaScript로 컴파일할 수 있습니다.

.NET 바이트 코드를 JavaScript로 컴파일 할 수 있고 GWT는 11년 동안 주변에 있었고 큰 프로젝트에서 사용되었습니다.

이러한 프로젝트는 수년 동안 진행되었습니다. 그것은 정말로 새로운 것이 아닙니다.

JavaScript는 이미 다른 언어와 경쟁하고 있습니다. WebAssembly는 다른 언어를 더 효율적으로 만드는 것뿐입니다.

처음에는 V8 및 기타와 같은 VM에서 실행하기 위해 JS 코드를 보다 효율적으로 만드는 기술을 채택했지만 이제는 JS 코드를 뛰어넘을 수 있는 어셈블리 코드를 작성하고 컴파일할 수 있습니다.

예, 자바 스크립트 VM은 당신이 코드 실행의 꽉 낮은 수준의 제어를 필요로 더 높은 성능을 원하는 그렇다면 때문에 JIT 엔진의 오버 헤드 (자바 스크립트의 본래 동적 특성)의 네이티브 성능을 달성하지 못할 수 있기 때문입니다. WebAssembly는 이러한 제어를 제공합니다.

따라서 요점은 API 브리지를 추상화하고 브라우저에서 런타임을 포팅하여 JS가 제외되거나 사진에서 제거될 가능성이 있다는 것입니다.

아니요, 사람들은 계속 JavaScript를 사용할 것입니다.

수년 동안 데스크탑에는 Python, Perl, Ruby, PHP, Haskell, JavaScript(Node.js), OCaml, C++, Java 등 선택할 수 있는 많은 언어가 있었습니다.

사람들은 JavaScript를 비롯한 많은 언어를 사용합니다. JavaScript는 아무데도 가지 않습니다.

JavaScript가 일급 언어가 아닌 ( 매우 가능성이 낮은) 가상의 세계에서도 사람들은 여전히 ​​JavaScript를 WebAssembly로 컴파일할 수 있습니다.

이제 TypeScript, CoffeeScript 등과 같은 변환기를 대체하는 웹용 컴파일러를 기대할 수 있습니다.

그럴 가능성은 없지만 사람들이 TypeScript와 JavaScript를 사용하는 데에는 여전히 타당한 이유가 있습니다.

물론 TypeScript에 대한 대안 이 있을 것이고 어떤 사람들은 이러한 대안을 사용할 것이지만 TypeScript는 사라질 것 같지 않습니다.

나는 이미 (같은 년 타이프 좋은 대안 되었기 때문에 말 Haxe )하지만 그들은 타이프 라이터를 대체하지 않습니다.

2017년 9월 4일 03:42 Pauan [email protected]에서 다음과 같이 썼습니다.
>

JavaScript는 이미 다른 언어와 경쟁하고 있습니다. WebAssembly는
다른 언어가 더 효율적입니다. 그게 전부입니다.

후자는 정확하지 않습니다. Wasm의 또 다른 목표는 기능을 활성화하는 것입니다.
JavaScript에서 지원하지 않으며 잠재적으로 지원하지 않을 수도 있습니다. 을위한
예를 들어 동시성, 꼬리 호출 또는 재개 가능한 예외는 모두
로드맵.

@rossberg-chromium 실제로 당신이 맞습니다. 나는 그 세부 사항을 잊어 버렸습니다. 명확히 해 주셔서 감사합니다.

@Pauan 자세한 내용 감사합니다. 귀하의 요점 중 일부는 유효하고 의미가 있지만 모두 동의하지는 않습니다.

클라이언트 측의 C# 은 개발 단계에서 Javascript를 완전히 피하는 유망하고 킬러 예제로 보입니다. 즉.. C#을 사용하여 Javascript 코드를 작성하지 않고도 완전한 기능을 갖춘 웹 앱을 작성할 수 있습니다. 이러한 태도 기반 프레임워크는 적어도 어느 정도까지는 자바스크립트 레거시를 뮤트할 가능성이 있습니다.

이미 C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl 등을 JavaScript로 컴파일할 수 있습니다.

예, Javascript가 그림에 있었습니다. 그러나 이제 WASM/Webasm 을 사용하여 Javascript로 컴파일하는 동기가 변경되었습니다. 하나는 wasm으로 직접 컴파일하고 필요할 때마다 Javascript에서 API 마스크 레이어 또는 브리지를 작성할 수 있으므로 개발자 기반은 Webapp으로 웹 응용 프로그램을 개발하기 위해 Javascript를 알 필요가 없습니다.

다른 언어는 수년 동안 JavaScript로 컴파일되었으며 WebAssembly가 있든 없든 계속 그렇게 할 것입니다.

이미 C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl 등을 JavaScript로 컴파일할 수 있습니다.

많은 언어가 이미 JavaScript로 컴파일할 수 있지만 Webasm으로 컴파일하면 상당한 로드 및 런타임 성능 저하를 피할 수 있습니까? 그리고 그렇게 하기 위해 언어 전체 C VM을 Webasm으로 컴파일하면 성능 문제가 발생합니까?

다른 언어를 사용하여 불가피한 성능 문제가 발생하거나 해당 언어 사양을 위반하는 많은 위치(성능상의 이유로)가 발생하는 경우 기껏해야 JavaScript를 부분적으로 대체하고 일반적으로 "교체"할 새 코드보다 레거시 코드를 이식하는 데 더 많이 사용하는 것을 보았습니다. JavaScript"(JS로 멋지게 컴파일되도록 설계된 CoffeeScript, TypeScript 등 제외).

이러한 문제는 해결할 수 있습니까? 예를 들어 새로운 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는 이를 완전히 최적화할 수 있지만 가깝다고 생각하지 않습니다. 옵티마이저의 삶이 더 어렵습니까?

그럼에도 불구하고 일부 사항이 잘못되었거나 지원되지 않습니다(Webasm에는 기본 정수가 있으므로 JS가 아닌 Webasm으로 컴파일하는 경우 시작하기를 희망합니다).

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

Javascript 코드를 작성하지 않고도 C#을 사용하여 완전한 기능의 웹 앱을 작성할 수 있습니다.

예, 매우 훌륭하다는 데 동의합니다(저는 WebAssembly로 컴파일할 언어를 작업 중입니다). 하지만 제 요점은 WebAssembly 없이도 이미 그렇게 할 수 있다는 것입니다.

하나는 wasm으로 직접 컴파일하고 필요할 때마다 Javascript에서 API 마스크 레이어 또는 브리지를 작성할 수 있으므로 개발자 기반은 Webapp으로 웹 응용 프로그램을 개발하기 위해 Javascript를 알 필요가 없습니다.

실제로, 그리고 그것은 이미 수년 동안 가능했습니다. WebAssembly를 기다릴 필요가 없습니다. 지금 시작할 수 있습니다. asm.js 는 몇 년 동안 존재해 왔습니다.

@wnewbery

많은 언어가 이미 JavaScript로 컴파일할 수 있지만 Webasm으로 컴파일하면 상당한 로드 및 런타임 성능 저하를 피할 수 있습니까? 그리고 그렇게 하기 위해 언어 전체 C VM을 Webasm으로 컴파일하면 성능 문제가 발생합니까?

구문 분석 시간에는 도움이 될 수 있지만 런타임 성능에는 도움이 되지 않을 것입니다.

정리 하자면 asm.js 는 몇 년 동안 존재해 왔습니다. 이를 통해 프로그램을 JavaScript로 컴파일할 수 있으며 해당 프로그램은 거의 기본 속도로 실행됩니다. 즉, 데스크탑에서 실행되는 것과 동일한 속도로 프로그램을 실행할 수 있습니다.

따라서 이미 언어를 가져와서 VM, 런타임 및 가비지 수집기를 asm.js로 컴파일한 다음 데스크톱에서와 거의 동일한 속도로 브라우저에서 원하는 모든 언어를 실행할 수 있습니다. 이것은 이미 꽤 오랫동안 가능했습니다.

그러나 VM, 런타임 및 가비지 수집기를 컴파일하면 파일 크기가 상당히 커집니다(수 메가바이트).

그리고 DOM과 같은 JS API와 통신하기가 어렵습니다.

그러나 어떤 사람들은 어쨌든 그것을 했고 PyPy 인터프리터를 asm.js로 컴파일하는 PyPy.js 와 같은 것을 만들었습니다.

CPython보다 빠르게 실행됩니다(예, 정말! JavaScript 로

그러나 파일 크기는 상당히 나쁩니다(5MB gzipped, 15MB raw).

당신이 asm.js에 루비의 VM + 가비지 컬렉터 + 런타임을 컴파일 할 수 있으며, 매우 빠른 것,하지만 그래서 그 문제가있을 것입니다. 그래서 대신 사람들은 오팔과 같은 것을 만듭니다.

WebAssembly는 asm.js의 차세대 버전입니다. 현재로서는 WebAssembly로 할 수 있는 모든 것을 asm.js로도 할 수 있습니다.

예, 언어 + VM + 런타임 + 가비지 수집기를 WebAssembly로 컴파일하는 것이 가능하며 거의 기본 속도로 실행됩니다.

그러나 물론 asm.js와 같은 단점이 있습니다. 파일 크기가 매우 크고 JS API와 통신하기 어렵습니다.

WebAssembly와 asm.js에는 7가지 차이점이 있습니다.

1. WebAssembly는 일반적으로 asm.js보다 약간(5%) 빠릅니다.

2. 64비트 정수를 사용하는 경우 WebAssembly는 asm.js보다 훨씬 (~400%) 빠릅니다.

3. WebAssembly는 훨씬 빠르게 구문 분석할 수 있습니다. 이것은 프로그램의 런타임 속도를 향상시키지는 않지만 WebAssembly에서 초기 로드 시간 이 더 빠르다는 것을 의미합니다.

4. WebAssembly 파일 크기는 asm.js 파일 크기보다 작습니다(약 10-20% 작음).

5. WebAssembly 는 미래에 asm.js에 없는 멋진 기능(스레드, 동시성, 제로 비용 예외 등)을 얻을 수 있습니다.

6. WebAssembly 는 앞으로 JavaScript의 가비지 수집기에 액세스할 수 있습니다(즉, 더 이상 언어의 가비지 수집기를 WebAssembly로 컴파일할 필요가 없으므로 파일 크기가 작아짐).

7. WebAssembly는 미래 에 DOM과 같은 JS API를 쉽게 사용할 수 있는 기능을 얻게 될 것

그러나 미래에도 여전히 언어의 VM + 런타임을 WebAssembly로 컴파일해야 하므로 파일 크기가 여전히 문제가 될 것입니다.

언어의 VM + 런타임 + 가비지 수집기를 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

그것은 단순히 $rb_divide 함수의 정의를 변경하여 수정할 수 있는 Opal의 버그입니다.

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

이는 Opal이 문자열을 JavaScript 배열(변경 가능)로 컴파일하도록 하여 수정할 수 있습니다.

@파우안

WebAssembly는 미래에 asm.js에 없는 멋진 기능(스레드, 동시성, 제로 비용 예외 등)을 얻을 수 있습니다.

스레드는 많은 언어, 라이브러리, 프레임워크에서 매우 중요한 기능입니다. 스레드가 없으면 다중 스레드에 의존하는 C++, C#, Java로 만든 많은 앱이 이상한 동작을 유발할 수 있으므로 웹 앱으로 변환할 수 없습니다(SIMD와 같은 다른 좋은 점은 말할 것도 없습니다. _앞으로(?)_)를 지원합니다. 간단히 말해서 asm.js는 성능도 이식성도 충분하지 않다고 생각합니다. 그렇게 좋다면 오래 전에 asm.js에 "포팅"된 라이브러리가 더 많아야 합니다.

모두가 자바 스크립트가 인기가 있고 레거시 지원을 위해 사라지지 않을 것이라고 말했듯이 대부분의 브라우저는 여전히 기본적으로 자바 스크립트 실행을 지원하지만 미래에는 자바 스크립트로 새로운 웹 사이트를 만드는 사람이 모든 성능 향상을 위해 그것을 wasm으로 컴파일 할 것이라고 생각합니다

@unmellow , 그 신화를 다시 폭로하기 위해: JS를 Wasm으로 컴파일하면 마법 같은 성능 향상이 없을 것입니다. 오히려 그 반대입니다. JS 엔진이 제공할 수 있는 것보다 더 나은 성능을 원한다면 더 나은 언어를 선택해야 합니다.

예 죄송합니다 더 빨리 구문 분석한다는 것을 잊었습니다
편집 : 브라우저가 자바 스크립트 엔진을 지원하도록 업데이트하지 않는 경우 발생할 수 있습니다.
최신 버전의 JavaScript 감지 사람들은 성능 손실 없이 wasm으로 컴파일할 수 있습니다.

나는 1년 된 티켓을 걷어차는 것이 정말 편하지 않지만, 토론과 약간의 횡설수설을 위해서입니다.

많은 사람들이 Javascript를 WASM으로 대체하는 아이디어에 회의적이라는 것을 알 수 있습니다. 하지만 한 가지 사실은 WASM이 성능에 관한 것만은 아니라는 것입니다. 사람들이 대부분 잊고 있는 것은 자바스크립트가 그들이 원하는(또는 원하는) 언어가 아니라는 것입니다. 내 말은, 최소한 베어본 자바스크립트는 사람들이 원하는 것이 아닙니다. 점점 더 많은 사람들이 기본적으로 타사 언어용 컴파일러인 트랜스파일러를 사용하고 있습니다. 이것은 사람들 이 표준에 의존하는 것을

그러나 번역은 본질적으로 컴파일보다 훨씬 어렵습니다. 한 언어를 다른 언어로 매핑하는 수학적 문제는 항상 지역 범위에 국한되지 않습니다. 일부 컨텍스트 정보는 다른 쪽으로 전달되어야 하며 올바르게 수행하는 것은 어려운 문제입니다. 이것이 자바스크립트와 유사하지 않은 트랜스파일러가 널리 채택되지 않는 이유입니다(또는 의존해서는 안 되는 이유).

또한 중복된 노력에도 문제가 있습니다. 변환기는 컴파일러이고 번들러는 링커입니다. 우리 모두는 오랫동안 그러한 도구를 가지고 있었습니다. 모듈, 트리 쉐이킹, 코드 분할, 동적/지연 로딩, 자산 관리 등. 완전히 새로운 것은 없지만 사람들은 이러한 기능을 웹용으로만 사용하려면 새로운 도구가 필요하며 웹 솔루션이 아닌 솔루션에는 친화적이지 않습니다.

WASM이 하루아침에 모든 것을 바꾸는 것은 아닙니다. Javascript는 현재 잘 구축된 생태계를 가지고 있지만 다른 언어는 그렇지 않습니다. Javascript가 실제로 어딘가로 가기까지는 시간이 걸리겠지만 장기적으로는 분명히 일어날 것입니다.

Javascript는 내가 생각하기에 끔찍한 방향으로 나아가고 있으므로 WASM 교체를 환영합니다. 상당한 개선이 있었지만 지난 몇 년 동안 많은 커뮤니티와 방향이 잘못 인도되었다고 생각합니다. 적절한 언어를.. 반드시 그 자리를 차지할 필요는 없지만 직접적인 경쟁자가 되어 이 새로운 불쾌한 JS 및 그 "프레임워크"를 작성할 필요가 없었습니다.

@spencerudnick C에서 얻을 수 없는 성능 향상을 위해 어셈블리를 작성한 적이 없습니까?