Performance de blazor
J'aimerais commencer à utiliser Blazor, même s'il est toujours au niveau alpha. Si je comprends bien, blazor utilise WebAssembly pour compiler C # du côté client. Et j’ai une question: ce système fonctionne-t-il plus vite que, par exemple, React/Vue, compilé en JavaScript? Est-il vrai que le navigateur devra télécharger la bibliothèque Webassembly chaque fois que le pages chargées? Sur Internet, il n’existe aucune comparaison des performances des frameworks JS populaires, je souhaite donc connaître les performances théoriques du nouveau framework de Microsoft. Merci d’avance.
Est-il vrai que le navigateur devra télécharger la bibliothèque Webassembly à chaque chargement de la page?
Non, les navigateurs peuvent mettre en cache les fichiers. Un CDN commun pour les applications Blazor fera l'affaire.
Ce système fonctionne-t-il plus vite que, par exemple, React/Vue, compilé en JavaScript?)
Blazor utilise web Assembly, sur papier web Assembly doit être plus rapide que toute bibliothèque js, toutefois tous les navigateurs ne disposent pas encore d'un analyseur d'assembly web mature. Vous constaterez donc peut-être que les navigateurs n’exécuteront pas Web Assembly à une vitesse optimale pour le moment.
Vous pouvez créer une petite application Blazor et l’exécuter dans Firefox, chrome ou Edge. Dans la plupart des cas, Firefox exécute des applications Blazor beaucoup plus rapidement que chrome ou Edge, qui implique que les fabricants de navigateurs doivent encore s’améliorer, même Firefox peut s’améliorer.
Si votre application a besoin d'accéder à DOM fréquemment, alors certainement web Assembly/Blazor sera plus lent que toutes les bibliothèques JS car web Assembly ne peut pas accéder directement à DOM sans utiliser Invokes (ce qui est lent pour le moment, référez-vous à mon test de blazer ci-dessous) .
Sur Firefox 10 000 RegisteredFunction.InvokeUnmarshalle les appels aux méthodes vides prennent 250 ms tandis que chrome et Edge ont besoin de plus de 2 400 ms sur mon PC. ’Pour JS pur, il faut moins de 10 millisecondes pour le même scénario.
https://webassemblycode.com/webassembly-cant-access-dom/
En outre, Blazor possède son propre moteur MSIL en plus du navigateur Web Assembly Engine, ce qui signifie que deux interprètes travaillent pour exécuter un projet Blazor. Comme deux traducteurs interprétant une conversation sur un seul. Actuellement, Microsoft travaille sur un compilateur AOT, qui n'est pas encore publié. Une fois sorti, Blazor sera beaucoup plus rapide que l’implémentation actuelle.
http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/
Nous pouvons sans risque supposer que l’assemblée Web est l’avenir du développement Web, mais pour l’instant, nous ne pouvons rien dire sur l’avenir de Blazor. Sur papier, Blazor peut être plus rapide que n'importe quel framework, mais nous avons besoin de l'engagement des responsables de l'assemblage Web, des développeurs de navigateurs, de Microsoft et des communautés pour rendre les théories pratiques.
Mise à jour du 10 juillet 2018
Il y a de nouvelles propositions dans les dépôts WebAssembly.
- Permettre à WebAssembly de gérer DOM directement. https://github.com/WebAssembly/Host-bindings/blob/master/proposals/Host-bindings/Overview.md
- Types de référence pour WebAssembly avec GC. https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md
Les deux propositions ci-dessus vont ouvrir la voie à une interaction beaucoup plus rapide entre DOM et webassembly dans le futur. IOW Blazor sera beaucoup plus rapide dans le futur.
Mise à jour 17 octobre 2018
L’équipe de Firefox a été en mesure d’atteindre les appels JS -> WASM aussi rapidement que les appels de méthodes JS -> JS. À ce jour, FireFox est bien en avance sur tous les autres navigateurs en ce qui concerne la prise en charge de WebAssembly.