SinglePageApplications mit Rust und Webassembly (e.g. via yew.rs)?

[new Account()]

https://yew.rs/docs/en/intro/

• Performance: Kompilierung (inkl. Optimierung) zu Webassembly statt Javascript; Multithreading
• Interoperabel mit JavaScript (NPM!)
• Echte typisierte Sprache (statt mit TypeScript die Typisierung rangeflanscht)
• Rust: hohe Standards was statische Codeanalyse angeht (durch Compiler)

Irgendein Grund warum das nicht bald durch die Decke geht und man sich nicht damit beschäftigen sollte?

 

[Falc410]

Rust ist schon seit ein paar Jahren recht gut im kommen, nur hat halt Mozilla mal eben das halbe Team entlassen Niemand kann vorhersagen was the next big thing wird.

 

[0x8100]

kommt drauf an, was du machen willst, oder? willst du doom3 laufen lassen, brauchst du webassembly. andere spiele laufen auch so im browser.

nur um eine kleine info-seite anzeigen zu lassen, würde ich mir den aufwand nicht antun

 

[new Account()]

Aufwand? Mehr als Angular oder React?

Und es geht ja nicht nur um Spiele.
Unternehmen klatschen alles mögliche in den Browser. Voran Microsoft MSO. Performance ist ein großer Faktor, wenn es um WebApps geht, die über Twitter hinausgehen.

 

[0x8100]

man sollte sich am anfang eines projekts gedanken machen, ob(!) und welche frameworks man braucht, ob die ganze sache performace-kritisch ist und man daher webassembly nehmen sollte.

wenn man zum schluss gekommen ist, dass sich webassembly lohnt, dann ist dieses yew.rs sicherlich einen blick wert, wenn man aus der rust ecke kommt. ansonsten kann man ziemlich viele sprachen als basis nutzen.

 

[new Account()]

ob die ganze sache performace-kritisch ist und man daher webassembly nehmen sollte.

Warum nicht per default yew nutzen?
Der Aufwand dafür erscheint trivial - egal ob man nur eine simple oder schnelle App möchte/braucht, oder nicht:
https://yew.rs/docs/en/getting-started/build-a-sample-app/
Die Performance schadet gewiss nicht 🤫

Warum Rust und nicht z.B. C++, sollte aus meinem initialen Post schon hervorgehen?

 

[Hellblazer]

WASM wäre mir persönlich noch zu neu.
Blazor von MS (also WASM mit C#) reizt mich zwar, aber es gibt dafür zu wenig UI Frameworks und Ressourcen, die OpenSource sind und gute Qualität liefern. Bei Angular ist zum Beispiel das Ionic Framework meine erste Wahl, wenns darum geht WebApps für mobile first zu entwickeln. Auch gibts mehr Tutorials, Tipps und work arounds im Netz um Probleme zu umgehen usw.
Sowas fehlt mir bei Blazor/WASM etwas. Angular/React sind einfach etablierter. In Zukunft sieht das aber sicherlich für WebAssembly auch besser aus.

WebAssembly mit C/C++ würde ich mir überhaupt nicht antun wollen. Viele Web-Entwickler kommen ja auch eher aus der JS-Ecke, haben mit C/C++ also noch weniger am Hut. Ok, könnte man als ANlass nehmen sich mal mit Rust zu befassen...

Für C/C++, C#, Java-Entwickler aber sicherlich interessant um mal im Web Fuß zu fassen, ohne sich mit JS rumschlagen zu müssen (deshalb kommt für mich bisher auch nur Angular mit Typescript in Frage, wenns um Webentwicklung geht). Als eigentlich Java/C#-Entwickler ist WebAssembly eigentlich genau das, was ich mir immer gewünscht habe. Gerade hinsichtlich AR und Games im Browser.

Aber die meisten SPAs sind eben keine AR-Apps oder Games, also reicht da einfach auch Angular/React/...

 

[new Account()]

Aber die meisten SPAs sind eben keine AR-Apps oder Games, also reicht da einfach auch Angular/React/...

Was heißt Angular/React würde ausreichen?

z.B. Yew wäre doch in gewisser Weise einfach eine weitere Alternative, und nicht ein zusätzlicher Aufwand.

 

[Hellblazer]

@new Account(): Alternative ja.
Aber eben deutlich anders, als Angular/React. Ein bisheriges Angular-Projekt würde keiner auf Yew umstellen. Auch auf der grünen Wiese anfangen geht nur ohne Zusatzaufwand, wenn die Entwickler Rust können und Erfahrung in Yew haben. Aktuell gibts da wohl eher weniger davon. Angular/React-Entwickler gibts einfach mehr.

Wie schon gesagt, ich sehe WebAssembly interessant für performance kritische Sachen oder Entwickler, die bisher nicht in der Web-Entwicklung unterwegs waren und von Java/C#/C++ kommen. Die fühlen sich da sicherlich wohler, als einer der von React/Angular mit JavaScript/TypeScript in WebAssembly geworfen wird.

Man sieht ja auch noch, dass AngularJS-Apps rumgeistern, die ewig mitgezogen und nie auf Angular 2+ portiert wurden.
Durch die Decke gehen wird WebAssembly wohl nicht. Stetig den Marktanteil vergrößern vielleicht eher. Wenn neue Projekte entstehen ist man auch freier in der Wahl der Technologie. Wenn sich WebAssembly anbietet, wirds auch genutzt. Wenn Angular/React ausreicht, wird das eher genutzt (mehr Entwickler vorhanden => billiger)


Wenn ich jetzt ein Projekt starten würde, würde es auch auf Angular basieren. Einfach weil ich Rust nicht kenne und es Zusatzaufwand wäre Rust zu lernen und in das neue Framework einzuarbeiten.
Blazor würde für mich schneller gehen, weil ich C# kenne. Da ist dann nur noch Aufwand für das Framework und eventuelle neue UI-Frameworks selbst zu leisten.
Yew wäre dann eher so ein Hobby/Weiterbildungsprojekt um das Framework und Rust kennenzulernen. Direkt Geld verdienen lässt sich damit aber nicht.
So ähnlich wird das auch in der Industrie ablaufen.

 

[Joshinator]

Das Problem bei solchen Frameworks ist oft das man auf die React/Angular/Vue-Zielgruppe abzielt.
Svelte macht auch einiges richtig, aber wirklich an fahrt aufgenommen haben die nicht.
Solange es da nicht irgendein Totschlagargument gibt wird man die Masse an Entwickler nicht dazu bringen können zu wechseln.
Die Bundlesize von Svelte ist im vergleich zu anderen SPA-Frameworks minimal und trotzdem wirds kaum benutzt.
Für 0815-User in einer 0815-Anwendung mit ordentlicher Internetanbindung und solider CPU (grade am Handy) ist der Overhead von JS-Frameworks kein riesiges Problem.
Aber um Leute die Jahre an Erfahrung in React & Co haben zu überzeugen wirds mehr als "bessere Performance" brauchen. Die meisten Seiten im Internet sind nicht hochkomplex wo die aktuelle Performance ein dorn im Auge ist. Office-Anwendungen sind die Ausnahme, nicht die Regel.

Bei Yew (oder anderen Frameworks per WSM) laufen kommt dann wohl noch oben drauf das es WSM ist. IE11 muss ich z.B. (leider) immernoch supporten. Kann mir auch gut vorstellen das WSM & Rust und Yew eigene Probleme mitbringt um die man sich kümmern muss.
Werd mir sowas bestimmt mal wie Svelte für kleine Hobbyprojekte angucken, aber für was "ernsthaftest" greife ich dann doch eher zu dem was ich kenne.

 

[Dalek]

Diese Projekte haben alle das Problem das sie auch die komplette runtime mitliefern müssen, was häufig eine Minimalgröße im Megabyte-Bereich bedeutet. Das ist kein so großes Problem wenn man z.B. eine komplexere Desktopanwendung damit in den Browser bringt, aber schon sehr viel Overhead für kleinere Webanwendungen.

Das ganze geht nur in recht neuen Browsern. WASM ist sehr neu, und das was momentan implementiert ist ist nur die MVP Version (mimimal viable product), und momentan wird an weiteren wirklich wichtigen Features gearbeitet.

Für mich persönlich mit großem Abstand der wichtigste Grund diese Art von Projekten zu meiden ist das man enorm viel Wissen über viele komplexe Systeme braucht wenn man in einen Fehler in dem Framework läuft. Da sind so viele Schichten zwischen dem Code den du schreibst, und dem was im Browser ankommt, und die meisten von denen sind sehr, sehr neu und noch nicht ausgereift.

Meine Erfahrung mit Programmiersprachen die behaupten das sie interoperabel mit einer anderen sind ist auch eher negativ. Das geht meistens so zu 95%, und der Rest kann dann extrem nervig werden. Meistens ist das eine sehr löchrige Abstraktion, und wenn man nicht genau versteht wie die Interoperabilität implementiert ist führt das zu ordentlich Frust.

WASM ist momentan auch nicht unbedingt schneller, weitere Optimierungen sind da für die Zukunft geplant. Und Javascript engines sind schon sehr schnell, langsame Webanwendungen liegen nicht unbedingt an der Programmiersprache.

 

[Hayda Ministral]

Irgendein Grund warum das nicht bald durch die Decke geht

DAS? Was "das"?

Du diskutierst hier, also benenne bitte hier worum es geht. Irgendwelchen anonymen Links zu folgen nur weil sie existieren ist was für sehr naive Menschen. Rattenfänger arbeiten so.

 

[Joshinator]

Der Titel vom Thread sagt doch ganz klar um was es geht.
Wenn du keine Ratte bist dann klick den Link nicht und bemühe Google.
Das wichtigste hat TE in 4 Punkten zusammengefasst und will Meinungen/Erfahrungen von anderen haben.
Muss man nicht gleich jemanden für anfahren.


Bezüglich: Performance: Kompilierung (inkl. Optimierung) zu Webassembly statt Javascript; Multithreading
https://rawgit.com/krausest/js-fram...ea0ac4ca1e5fd/webdriver-ts-results/table.html

Einige von den Testreihen sind ziemlich schwachsinnig (updaten von 1000 Rows und sowas), aber grade TTI und Network Cost sind ein Schuss vor den Bug.
Multithreading ist auch mit JS möglich, Node macht es schon mehr oder weniger von selbst und im Browser werden UI updates immer im Mainthread laufen. Alles andere lässt sich mit Webworkern machen (und mit div. Packages lassen die sich auch einfacher nutzen).
Liest auch an einigen Stellen das Interaktionen zwischen Yew und JS nicht ganz so einfach ist.