Blazor가 아직 알파 수준이라는 사실에도 불구하고 사용을 시작하고 싶습니다.
내가 알기로 Blazor는 WebAssembly를 사용하여 클라이언트 측에서 C #을 컴파일합니다.
그리고 다음과 같은 질문이 있습니다.
이 접근 방식은 예를 들어 JavaScript로 컴파일 된 React / Vue보다 빠르게 실행됩니까?
페이지가로드 될 때마다 브라우저가 WebAssembly 라이브러리를 다운로드해야한다는 것이 사실입니까?
인터넷에서는 인기있는 JS 프레임 워크의 성능에 대한 비교가 없습니다. 따라서 Microsoft의 새로운 프레임 워크의 이론적 성능을 알고 싶습니다. 미리 감사드립니다.
답변:
페이지가로드 될 때마다 브라우저가 Webassembly 라이브러리를 다운로드해야한다는 것이 사실입니까?
아니요, 브라우저는 파일을 캐시 할 수 있습니다. Blazor 앱용 일반 CDN이 트릭을 수행합니다.
이 시스템이 예를 들어 JavaScript로 컴파일 된 React / Vue보다 작동 속도가 빠릅니까?
Blazor 는 웹 어셈블리를 사용합니다. On paper 웹 어셈블리는 js 라이브러리보다 빠르지 만 모든 브라우저에 아직 완성 된 웹 어셈블리 파서가있는 것은 아닙니다. 따라서 브라우저가 현재 최적의 속도로 웹 어셈블리를 실행하지 않을 수 있습니다.
작은 blazor 앱을 만들고 Firefox, chrome 또는 edge에서 실행할 수 있습니다. 대부분의 경우 Firefox는 Chrome 또는 Edge보다 훨씬 빠르게 blazor 앱을 실행합니다. 이는 브라우저 제작자가 여전히 개선해야 함을 의미하며 Firefox도 개선 할 수 있습니다.
앱에서 DOM에 자주 액세스해야하는 경우 웹 어셈블리가 Invokes를 사용하지 않고 DOM에 직접 액세스 할 수 없기 때문에 웹 어셈블리 / Blazor가 모든 JS 라이브러리에 비해 느릴 것입니다 (현재 느립니다. .
Firefox RegisteredFunction.InvokeUnmarshalle에서 빈 메서드에 대한 10,000 번의 호출은 250ms가 걸리지 만 크롬과 에지는 내 PC에서 2400ms 이상을 필요로합니다. ' 순수 JS에서는 동일한 시나리오에 대해 10 밀리 초 미만이 걸립니다.
또한 현재 구현 Blazor에는 브라우저 웹 어셈블리 엔진 위에 자체 MSIL 엔진이 있습니다. 즉, Blazor 프로젝트를 실행하기 위해 작업하는 두 명의 인터프리터가 있습니다. 마치 두 명의 번역자가 대화를 대신 해석하는 것처럼 말입니다. 현재 Microsoft는 아직 출시되지 않은 AOT 컴파일러를 개발 중입니다. 출시되면 Blazor는 현재 구현보다 훨씬 빠릅니다.
http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/
웹 어셈블리가 웹 개발의 미래라고 안전하게 가정 할 수 있지만 현재로서는 Blazor의 미래에 대해 아무 말도 할 수 없습니다. 문서상 Blazor는 어떤 프레임 워크보다 빠를 수 있지만 이론을 실용화하려면 웹 어셈블리 관리자, 브라우저 개발자, Microsoft 및 커뮤니티의 헌신이 필요합니다.
WebAssembly 저장소에 새로운 제안이 있습니다.
WebAssembly가 DOM을 직접 처리하도록 허용합니다. https://github.com/WebAssembly/proposals/issues/8
GC를 사용하는 WebAssembly에 대한 참조 유형. https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md
위의 두 제안은 앞으로 DOM과 웹 어셈블리 간의 훨씬 더 빠른 상호 작용을위한 길을 열 것입니다. IOW Blazor는 앞으로 훨씬 더 빨라질 것입니다.
Firefox 팀은 JS-> WASM 호출에 JS-> JS 메소드 호출만큼 빠르게 도달 할 수있었습니다. 현재 FireFox는 WebAssembly 지원과 관련하여 다른 브라우저보다 훨씬 앞서 있습니다.
내가 알기로 Blazor는 WebAssembly를 사용하여 클라이언트 측에서 C #을 컴파일합니다.
절반은 사실입니다. WebAssembly (WASM) 클라이언트 측에 코드를 작성할 수 있지만 (예, 클라이언트 측에서는 C # 임) 논리 서버 측을 실행할 수도 있습니다. 둘 다 장점이 있습니다. WASM 경로로 이동하면 모든 코드를 볼 수 있습니다. 그러나 논리가 모두 서버 기반 인 경우보다 빠르게 다시 렌더링 할 수 있지만 서버 기반 인 경우 코드를 볼 수 없습니다.
이 접근 방식은 예를 들어 JavaScript로 컴파일 된 React / Vue보다 빠르게 실행됩니까?
아니요. Vue를 많이했고 Vue가 더 빠르게 실행됩니다. 하지만 Blazor를 사용하여 훨씬 빠르게 코드를 작성할 수 있습니다. Blazor는 더 빠르게 표시 할 수있는 가상 스크롤 솔루션을 제공합니다. 제 경우에는 사용 가능한 플로팅 구성 요소가 너무 느 렸습니다. 저는 매우 잘 작동하는 C #과 JavaScript를 사용하여 Blazor 구성 요소를 작성했습니다. 대부분의 경우 WASM 코드가 너무 느리게 실행되는 것에 대해 걱정하지 않습니다.하지만 플로팅은 훨씬 빨라야합니다. JavaScript에서 레벨 작업. Blazor 실행은 지난 6 개월 동안 더 빨라졌고 팀은 .Net 6이 나올 때 더 많은 것이있을 것이라고 말합니다. 하지만 내가해야 할 일의 99 %를 처리 할만큼 충분히 빠릅니다.
페이지가로드 될 때마다 브라우저가 WebAssembly 라이브러리를 다운로드해야한다는 것이 사실입니까?
캐시 된 경우에는 그렇지 않습니다. 그리고 처음로드 할 때도 괜찮은 연결이 있으면 느리지 않습니다. 10 메가 정도입니다.
묻지 않은 위대한 질문은 사용할 가치가 있다는 것입니다. 나는 6 개월 동안 그것을 사용하고 있습니다. 저에게는 정말 좋았습니다. C #은 아주 좋은 언어입니다. 때로는 속성을 동적으로 추가하는 것을 놓치고 종종 수동으로 다시 그리기를 시작해야하지만 nullable 개체 검사와 같은 기능을 사용하면 코드가 null 참조 검사를 유발할 수 있는지 확인하지 않았다고 경고합니다. JS. 나는 종종 자바 스크립트 "툴체인"으로 작업하는 것이 고통 스럽다고 느꼈다. JS의 라이브러리 스 래시에서 옵트 아웃 할 수있어서 너무 좋습니다.