Я хотів би почати використовувати Blazor, незважаючи на те, що він все ще знаходиться на альфа-рівні.

Як я розумію, Blazor використовує WebAssembly для компіляції C # на стороні клієнта.

І у мене є такі запитання:

Чи працює цей підхід швидше, ніж, наприклад, React / Vue, скомпільований у JavaScript?

Чи правда, що браузер повинен буде завантажувати бібліотеку WebAssembly щоразу, коли сторінка завантажується?

В Інтернеті немає порівнянь ефективності популярних фреймворків JS. Тому я хотів би знати теоретичні показники роботи нового фреймворку від Microsoft. Спасибі заздалегідь.

Чи правда, що браузер повинен буде завантажувати бібліотеку Webassembly щоразу, коли сторінка завантажується?

Ні, браузери можуть кешувати файли. Загальний CDN для додатків Blazor зробить трюк.

Чи швидше ця система працює, ніж, наприклад, React / Vue, складена в JavaScript?

Blazor використовує веб-збірку. На папері веб-збірка повинна бути швидшою за будь-яку js-бібліотеку, однак ще не всі браузери мають зрілий аналізатор веб-збірок. Тож ви можете виявити, що браузери не запускатимуть веб-збірку з оптимальною швидкістю на сьогодні.

Ви можете створити невеликий додаток blazor і запустити його у Firefox, chrome або edge. У більшості випадків Firefox запускає програми blazor набагато швидше, ніж chrome або edge, що означає, що виробникам браузерів все одно потрібно вдосконалюватися, навіть Firefox може вдосконалюватись.

Якщо вашій програмі потрібно часто отримувати доступ до DOM, тоді веб-збірка / Blazor буде повільнішою у порівнянні з будь-якими бібліотеками JS, оскільки веб-збірка не може безпосередньо отримати доступ до DOM без використання Invokes (що на даний момент є повільним, будь ласка, зверніться до мого тесту blazer нижче) .

У Firefox 10 000 RegisteredFunction.InvokeUnmarshalleвикликів порожніх методів займає 250 мс, тоді як chrome та edge потребують більше 2400 мс на моєму ПК. ' У чистому JS для того самого сценарію потрібно менше 10 мілізондів.

Крім того, поточна реалізація Blazor має власний механізм MSIL поверх веб-браузера веб-браузера, що означає, що для запуску проекту Blazor працюють два інтерпретатори, як два перекладачі, які замість цього інтерпретують розмову. В даний час Microsoft працює над компілятором AOT, який ще не випущений. Після випуску Blazor стане набагато швидшим, ніж поточна реалізація.

http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/

Ми можемо сміливо припустити, що веб-збірка - це майбутнє веб-розробки, але наразі ми не можемо сказати нічого про майбутнє Блазора. На папері Blazor може бути швидшим, ніж будь-який інший фреймворк, проте нам потрібні зобов’язання розробників веб-збірок, розробників браузерів, Microsoft та спільнот, щоб зробити теорії практичними.

Оновлення 10 липня 2018 р

У репозиторіях WebAssembly є нові пропозиції.

1. Дозвіл безпосередньо обробляти DOM WebAssembly. https://github.com/WebAssembly/proposals/issues/8

2. Типи посилань для WebAssembly з GC. https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md

Вище дві пропозиції прокладуть шлях до набагато швидшої взаємодії між DOM та веб-збіркою в майбутньому. IOW Blazor буде набагато швидшим у майбутньому.

Оновлення від 17 жовтня 2018 р

Команда Firefox змогла досягти виклику JS -> WASM так само швидко, як виклики JS -> JS. На сьогоднішній день FireFox набагато випереджає будь-які інші браузери, що стосується підтримки WebAssembly

https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/

Як я розумію, Blazor використовує WebAssembly для компіляції C # на стороні клієнта.

Напівправда. Ви можете написати свій код на стороні клієнта WebAssembly (WASM) (так це C # на стороні клієнта), але ви також можете виконати сторону логічного сервера. Обидва мають переваги. Весь ваш код видно, якщо ви йдете за маршрутом WASM. Але він може повторно відображатись швидше, ніж якщо логіка базується на всьому сервері, але якщо на його сервері ваш код недоступний для перегляду.

Чи працює цей підхід швидше, ніж, наприклад, React / Vue, скомпільований у JavaScript?

Ні. Я зробив тонну Vue, і Vue працює швидше. АЛЕ я можу набагато швидше написати код за допомогою Blazor. А Blazor пропонує віртуальне рішення для прокрутки, яке може зробити його швидшим. У моєму випадку доступні компоненти побудови графіку були занадто повільними. Я написав компонент Blazor, використовуючи C # та JavaScript, які працювали дуже добре. Здебільшого я не хвилююся через те, що код WASM працює надто повільно .... але планування було набагато швидшим ... робота рівня в JavaScript. За останні 6 місяців виконання Blazor пришвидшилося, і команда каже, що буде більше, коли вийде .Net 6. Але це більш ніж досить швидко для 99% того, що мені коли-небудь потрібно було робити.

Чи правда, що браузер повинен буде завантажувати бібліотеку WebAssembly щоразу, коли сторінка завантажується?

Ні, якщо вони кешовані. І навіть перший раз, коли вони завантажуються, це не повільно, якщо у вас гідний зв’язок. Це близько 10 мег.

Чудове запитання - чи варто його використовувати. Я використовую його близько 6 місяців. Для мене це було чудово. C # - дуже хороша мова. Іноді я пропускаю динамічне додавання властивості, і часто доводиться ініціювати повторне малювання, але з такими функціями, як перевірка об’єктів, що допускає обнулення, що попереджає вас, що ви не перевіряли, чи може ваш код спричинити перевірку нульового посилання - це набагато краще, ніж JS. Я часто відчував, що боляче працювати з "ланцюжком інструментів" JavaScript. Так приємно мати можливість відмовитися від бібліотечного трешу JS.