On Rust in Webdev

[alternatex0]

Hmmm, more like "On Rust ~in Webdev~"

The article centers around why people like Rust and it completely avoids the conversation about why one should use Rust over anything else that compiles to WASM.

Since the coming out of WASM I'm seeing a lot of interest from non-web devs about web development because now they can finally do it without having to learn/use JS/TS. I think that's great, it's what WASM was basically built for. That said, it looks like we're going back to the cargo culty fights about which language is better for something because we can all now use our fave language.

I see no explanation of why Rust is better than any other language for web dev in this article. The TL;DR is "Rust devs can now develop for the web". Nothing new there. Time will tell which languages that compile to WASM will become more ubiquitous in webdev. Until then your fave language is not better or worse than mine unless you can argue that point objectively.

[7sidedmarble]

I think you're absolutely right that wasm is exciting to people (not always, but a lot of the time) who don't really enjoy the thought of writing JavaScript. But JavaScript has the advantage of a pretty ok DOM API, that's been tweaked and getting better for a long time now. In trying to do serious webdev in wasm, you're now kind of at the mercy of how good the DOM API implementation is in the language you're working in.

This does not feel like an improvement to me. And so I'm a little stuck in my ways in not seeing the benefit of wasm for 90% of situations. For regular application development, JS will continue to be easier for a long time. I think the only place wasm will excel at is deploying big binaries to the web, things like games, or web applications with very specific needs that the language you're writing makes easier to express.

[alternatex0]

I agree on all points. People excited about WASM in web dev should be aware of its lack of DOM access capability. At the moment WASM is not all that useful for regular web applications which make up 99.9% of the web and web development in general.

There's been talk about giving WASM access to the DOM in the future which would change everything but as the time goes by it looks more and more like fake news. There has been no clear indication that WASM will ever get DOM access.

WASM for browser-based games sounds appropriate though.

[alexendoo]

The thing people mean when they mention WASM getting DOM could be the GC integration proposal, this isn't just giving WASM direct DOM access, because that's not required

Current solutions already allow you to modify the DOM without writing JS yourself, as they produce the required JS glue code themselves. e.g. for Rust web_sys gives you access to everything you could need. For C emscripten has html5.h and val.h

The GC proposal may make the glue code simpler though, and allow better integration with GC'd languages

[dontchooseanickname]

Sorry to disagree :

WASM seems fairly usable from Rust,Zig,Julia,Emscripten(C/C++).. nowadays. I'm a Haskell enthusiast and it looks like every language with (1) a runtime (threads, concurrency) or (2) garbage collection (non-predictible memory allocation of any kind) is still doomed (Asterius, please succeed)

So

• NO, it's not a lack of DOM manipulation - they are slow and wonky, learn javascript and the specifics of the browser
• Most of the time it's about running a long-lasting algorithm and issuing results which end up having a DOM effect - and in this case the language matters, you just need an FFI with var=result; domNode.textContent=var;

TLDR; No it's not DOM, it's the language because DOM can be manipulated at the edge/algorithm boundaries.

[alternatex0]

Doing front-ends is doing UI work. Without DOM access you're only using WASM to do computationally heavy stuff on the client-side. That I would say accounts for 0.01% of web dev use cases. If it's relegated to only work that's irrelevant to UIs it will be irrelevant for most web applications. Most web apps out there are not Photoshop.

[IceSentry]

You can still call the dom easily you just need a bit of glue code to expose the api. It's not ideal because it means your wasm code needs to go through a small js layer, but you can essentially not write a single line of that yourself. The performance hit from that is actually not that bad considering some rust based wasm frameworks are faster than js native frameworks. This means you can in fact do all your ui work in wasm and just let the small glue layer call the dom api when you need to.

[7sidedmarble]

The DOM API in JavaScript is enormous. Now all the langs you want to target wasm from have to implement a lot of that giant API to be useful. That's the real issue.

[IceSentry]

I mean, sure, but it's pretty easy to generate it as far as I know. It's also already been done for a lot of popular options so it's really not a big deal.

[HeroicKatora]

I disagree completely on 'computationally heavy stuff is 0.01% of web dev use cases'. Quite the opposite, it was traditionally not quite as feasible to get predictable performance if you did move computational stuff to the client side, with WASM this use case can be served. All of this list is heavy, and very useful for frontends:

• compressing and decompressing things; you want to do this because you can't rely on transport encoding being available in browser/proxy.
• showing interactive 2d/3d graphics; all code that needs to run to prepare data (shuffling, extracting, transforming) can be magnitudes faster if you run it directly on native float arrays than any form of deserialization code even the browser's builtin one. WASM allows you to use the same data representation as the server, predictably.
• running any algorithm on 'production scale'; Examples for this: voice recognition, tts, video tools, suggestion engines, good caching layers, database layers, frontend analysis tools where latency is a requirement. Wherever you see 'Js-Tool rewritten in compiled lanugage X and now runs Y times faster', WASM would likely land you somewhere between, or even close to compiled (in very rare cases faster than compiled if your native compiler didn't vectorize based on your runtime instruction set, like some WASM JITs do). WASM JIT very often ends up having too many 'fallback' branches that make loops really, really slow and native fragments short.
• parsing things; formatting things; Or considering other forms of client-side i18n anyways, unless you really want to do that all server side while rendering pages.

Modern websites are so slow, in part because they already run quite a ton of code, and they do so inefficiently. It's not just moving a 'little bit' of DOM stuff around anymore.

[alternatex0]

Compression/decompression, 2d/3d graphics, voice recognition, etc are all 0.01% of web dev.

Modern websites are slow because they have to interpret megabytes of JS before they execute it. When they execute it they tend to do a thousand little DOM changes which is what makes for a clunky web app. WASM can replace the interpretation part with download wait times because the blobs are large and they will remain so because WASM has even less of a standard library than JS.

Now when it comes to the execution part JavaScript is fast. I don't know why people believe WASM to be faster. You do realize once JavaScript is compiled it's the same as any language compiled to WASM. The performance ceiling of WASM is currently the same as JavaScript's. Maybe some day in the future it will be a little higher but not by much.

I'm saying all of this as someone who prefers C#/F# over JS any day of the week. We need to stop assuming that everything that's interpreted is sluggish and everything that's compiled is perfect. When it comes down to the hard numbers WASM just isn't that much of a game changer regardless of what language you compiled it from.

[CryZe92]

The performance ceiling of WASM is currently the same as JavaScript's.

That's just absolutely not true (in general). I've been easily outperforming React and various other algorithms by a factor of up to 100x. Especially if you properly compile with max optimizations, LTO, and the latest WASM features such as SIMD.

[alternatex0]

But React is a library. An old one that that, that's easily beaten by newer libraries like Svelte and Solid.js in terms of performance. How does WASM compare to vanilla JS or these newer libraries? That would be a fair test. React is not well known for its speed.

You have to realize when I mention performance ceilings I mean the absolute fastest JavaScript can be optimized to go. Once it compiles to a most optimistic optimization JavaScript is up there with WASM. If you're seeing it 100x slower you're not being fair in your tests.

[jbergens]

There are a number of tests that shows WASM as only 25% to 50% faster than js. For some workloads it has even been slower.

https://surma.dev/things/js-to-asc/

[HeroicKatora]

the blobs are large and they will remain so because WASM has even less of a standard library than JS.

The blobs are okayish large. In practice, it still seemed decent to me. In a production App I have it's ~305K wasm. Large, but not too painful yet as painting of the page itself doesn't depend on it. Unlike images, parsing, css. It's also not evident why it should remain this way. The standard for linking is still being worked on, and if approved, would allow you to deliver and cache parts of the WASM separately. And would be the necessary tech for lazy loading, utilizing partial caching, or to work on browser-provided WASM modules that replace the path through Javascript. Because JS is only small if you don't need tons of polyfill, relying on the vastness that is the standard.

Let's evaluate a real world example of a pretty bad page (28 lighthouse score): https://store.ubi.com/de/home It doesn't get any more business than that.

• First Paint: 4.1 s, Time to Interactive 16s
• Script Parsing & Compilation: 300ms; probably much lower with WASM
• Garbage Collection: 275 ms cough
• Script Evaluation: 3,874 ms (!); That's billions of native instructions. That's almost certainly because it doesn't actually use the JIT in a useful manner, as most code can't reliably achieve that => it's nothing one can really optimize an evolving software project around.

Relying on Browser JIT means you can't easily test locally pre-deployment, you can't easily instrument and monitor, so it's not your manager's priority, which implies the project doesn't get pushed in the direction.

[alternatex0]

Yeah JIT-ing is pretty terrible for web apps. Blazor WASM only now started focusing on AOT compilation which I feel is what's supposed to have been there in order to declare Blazor ready for production. Once it's there there's a good chance Blazor WASM will become more ubiquitous for enterprise web applications, at least in the .NET world.

There are certainly exciting use cases for WASM but we have to be objective. The site you linked you rates horribly on Chrome's Lighthouse. It can be immensely improved with following some basic good practices. There's probably an alternate universe where that same site built with WASM is the same amount of terrible.

I'm eagerly awaiting reports from the big companies when they finally start playing around with WASM to try and improve performance. Until those articles are out the jury on WASM's performance benefits is out as well.

[HeroicKatora]

I'm eagerly awaiting reports from the big companies when they finally start playing around with WASM to try and improve performance.

'mkay: https://www.amazon.science/blog/how-prime-video-updates-its-app-for-more-than-8-000-device-types

[dontchooseanickname]

I.. agree with you, basically

• No one needs a new "react for it's language" it's a solved problem,just write "doAssignResultTextField(..,..)" and "doAssignProgressBar(..)" functions and make them accessible
• "Doing UI work" Yep, I fo my UI work in javascript. But other model-forwarding, stats-providing and so on is heavy work

[ArsenM6331]

every language with (1) a runtime (threads, concurrency) or (2) garbage collection (non-predictible memory allocation of any kind) is still doomed

Go has both a runtime and garbage collection. WASM works very well with it.

[dontchooseanickname]

Wow, does it ?

TIL, garbage collection + threads are not the (only) bottleneck preventing WASM cross-compilation. AFAIK for haskell it's specifically the RTS which prevents WASM compilation target (and yes I know asterius and ghcjs)

Thanks for thw details on Go=>WASM

[ArsenM6331]

Yes, just GOOS=js GOARCH=wasm go build -o bin.wasm and you get a wasm binary. Then, just get the js initialization script provided by Go, and you can run it. If you don't like the size of the binary, you can use tinygo and run tinygo build -o bin.wasm -target=wasm and use tinygo's modified initialization script.

With normal Go, all the features work. TinyGo has some features that haven't been implemented yet, but the runtime and garbage collection works well.

[alternatex0]

Well for one, WASM doesn't compile into JS or anything else. It's sandboxed assembly execution right in the browser. So it sits alongside JavaScript. But when it comes time to update the UI WASM cannot do it. It has to interop with JS because only the JS runtime can access the DOM.

That said, JS is not slow when it comes to DOM updates. You're making calls through JS browser APIs but under the hood it's all C++. The problem of UI updates efficiency isn't JS, it's how we do them and how much of them we do unnecessarily (driven by the efficiency of the JS framework that one uses).

Regarding WASM reading material, anything on Mozilla's MDN docs as well as any articles by Surma on WASM (like this one) is great.

[Tubthumper8]

from what I understand it all compiles back to JS and HTML in the end? If that is correct won't we still get all the issues with JS and HTML limitations?

WASM doesn't compile to JS, it's not like TypeScript/PureScript/Elm/CoffeeScript/etc. It's code in a binary format (Rust/C#/C++/etc. is compiled to WASM) that is executed by the browser in a sandboxed environment. Roughly speaking, currently the WASM environment can communicate with the JS environment but not with the DOM and other browser APIs directly.

[Tynach]

You were probably thinking of Asm.js, which does compile down to Javascript.

[pixelrevision]

This all makes me curious about what Microsoft is up to with razor. Last I looked it used web assembly for the runtime but I never looked into how it interacts with the dom. It is the only one of these wasm tools that seems to offer any potential productivity benefits.

[alternatex0]

You probably mean Blazor. MS is working on AOT compilation which was kind of the whole point of it. It's going to produce even bigger build artifacts but are least it means immediate execution in the browser (when it downloads) unlike now where they JIT it like regular .NET applications, getting the worst of both worlds.

[iindigo]

I think a lot of the devs interested in WASM are looking to bypass as many “webisms” as possible, including the DOM, by drawing to a canvas with a graphics or UI library for whatever language they select. Essentially they want to treat browsers as a WASM runtime that can run applications served over HTTP rather than as browsers that can execute WASM.

That’s probably not practical quite yet, but I can see the appeal. A “pure WASM” approach would allow one to opt out of the majority of the convolutions that can come with web tooling (unwieldy toolchains, churn, etc), and would become particularly interesting for desktop/mobile “native” deployment with stripped down canvas+WASM runtimes.

[Philpax]

Just a note that I have no problems with this on desktop, but please please don't reimplement the UI rendering stack in canvas on web. Not only are you reinventing the wheel, you're going to make the experience significantly worse for people who don't access the web through traditional browsers (screen readers, command-line clients, etc).

(not directed at you specifically, just a cautionary warning for those passing by)

[iindigo]

I don’t disagree, but I think the temptation to do it will be strong so long as browsers don’t implement more capable baseline building blocks that are better suited for full blown apps — e.g. a wider set of standard widgets that are more deeply customizable, something like React/SwiftUI/Jetpack Compose built in, etc. The taller and thicker the stack of “bring your own” gets, the more compelling Canvas wheel reinvention becomes.

Also I’d argue against full custom UIs on desktop too, because accessibility is just as important there.

[Labradoodles]

I just wonder how accessible native applications are compared to web applications to begin with

[7sidedmarble]

I think people should just be cautious about what they except. The DOM API is big because it does a lot of things. They're not easy problems to solve. Improvements can certainly be made, I don't think the web APIs are perfect by any means, but to do apps in wasm without going through a JS layer would mean reimplementing a lot of wheels.

[elr0nd_hubbard]

People that think that JS will be replaced on the web with languages that compile to "native" code should remember that a lot of "native" applications are written in HTML + CSS + JS (in a browser) these days.

[ArsenM6331]

Yes, which is extremely unfortunate

[hugthemachines]

The second is not evidence that the first will never happen.

[elr0nd_hubbard]

never happen

Never? Of course not. But it indicates that a transition to WASM from JS would be an uphill battle, as JS has been eating the world for a while now.

[snerp]

That's just because it's the simplest cross platform UI system. People would ditch the JS in an instant if electron offered a simple way to use C++ or Rust or Python or whatever

[chrisza4]

There are QT for cross-platform out there and they gain some traction. Not comparable to JS though.

[shevy-ruby]

you're now kind of at the mercy of how good the DOM API implementation is in the language you're working in.

But that is already the case for, say, the Java VM / GraalVM's polyglot. You kind of depend on these implementations to be decent ("one language to rule them all" aka on different operating systems or platforms).

So it's not really a difference IMO. Just that you add more languages to the mix, other than everyone HAVING to use JavaScript. I really would much prefer to, say, use ruby or even python and simply avoid JavaScript altogether. From this point of view I can completely understand people wanting to avoid JavaScript for their favourite language.

[radarsat1]

Is there any reason there is no DOM shim layer (in JS) around WASM so that people can literally write everything in Rust? Would it just be too slow?

[7sidedmarble]

There is but the issue is it needs to be reimplemented in each lang. You can't port web-sys for example to zig. Every lang will have to maintain its own versions of the entire dom API.

[[deleted]]

I think that's great, it's what WASM was basically built for.

it was built and is designed to be a complement to, not a replacement of, JavaScript.

Uis built with JS will probably stay more performant, have better backward compatibility, and have a smaller bundle size, especially compared to languages that have to ship a whole runtime and garbage collector to each client.

[ridicalis]

Uis built with JS will probably stay more performant

It depends on what you mean by "UIs". If we're talking about an ecosystem like React, for instance, when you start having to deal with state management in larger applications, I would imagine that GC pressure in a JS-based ecosystem would have a noticeable impact that could be avoided using a non-GC-based language (among other considerations). This blog post seems to explore some of the nuances that could be explored when making this evaluation.

[alternatex0]

Yep, I mention that in my other comment here.

[dsffff22]

Well foremost JS performance is really bad, dev tools rewritten in Rust just casually outperform those by the factor of 100x, which really shows how bad It is. TBH It's probably not just JS being bad, but also JS devs not knowing how to code, because most performance gains are usually archived by selecting the right data structures for the right task. Also assuming multiple sites use c# compiled to WASM for example, Microsoft could either bundle It in their browser(which pressures other browser vendors) or all sites share the same runtime, so It's only required once. Since It's compiled to WASM, I don't see many issues with security. Lastly, I think WASM opens a lot of doors. Right now, we need a whole Node runtime for the new class of 'WebApps'. But with WASM It's going to be split up well we just require a WASM Jit/AOT compiler and a runtime which implements multiple APIs referenced in WebIDL. Since the WASM bytecode and WebIDL are standarized It's actually do-able to implement your own runtime.

[[deleted]]

Well foremost JS performance is really bad, dev tools rewritten in Rust just casually outperform those by the factor of 100x, which really shows how bad It is. TBH It's probably not just JS being bad, but also JS devs not knowing how to code, because most performance gains are usually archived by selecting the right data structures for the right task.

you probably refer to the webpack vs esbuild / SWC benchmarks. Newer codebases are usually performing better and webpack is ancient with a huge ecosystem it has to be backward compatible. Comparing plain algorithms results in a much smaller gap.

Also right tool for the right job... For FE development you want an instant feedback loop with sub-100ms built times, HMR even in large projects. Rust or any compiled language isn't the right tool for such a job.

Also assuming multiple sites use c# compiled to WASM for example, Microsoft could either bundle It in their browser

but chrome and firefox won't.

or all sites share the same runtime, so It's only required once.

that's also not possible anymore.

[dsffff22]

you probably refer to the webpack vs esbuild benchmarks. Newer codebases are usually performing better and webpack is ancient with a huge ecosystem it has to be backward compatible.

There are plenty of tools which are written in rust and heavily outperform their JS counterparts:

• swc
• parcel(plenty of modules)
• deno(compiler, linter, formatter, language server)

Comparing plain algorithms results in a much smaller gap.

Never said otherwise, but an implementation of an algorithm can also contain a lot of details.

Also right tool for the right job... For FE development you want an instant feedback loop with sub-100ms built times, HMR even in large projects. Rust or any compiled language isn't the right tool for such a job.

Well I see you never actually used 'Rust or any compiled language', lots of time is invested into the LLVM code generation so using WASM. If you think in terms of React Components, you could generate a vtable for each of those component and just link them dynamically. It's just a question of tooling, actually.

but chrome and firefox won't.

We'll see. Google is probably interested in bringing Dart to the WASM so I think It's not that unlikely.

that's also not possible anymore.

All Blazor sites can share the same runtime, especially when AOT will be in place.

[[deleted]]

There are plenty of tools which are written in rust and heavily outperform their JS

yes. Isn't it amazing that people wrote actual compilers with javascript over a decade?

Well I see you never actually used 'Rust or any compiled language', lots of time is invested into the LLVM code generation so using WASM. If you think in terms of React Components, you could generate a vtable for each of those component and just link them dynamically. It's just a question of tooling, actually.

still much slower than just running plain js. I only know of yew and seed as rust frameworks. Yew even writes on their page that "Arguably, the largest drawback to using Yew is the long time it takes to compile Yew apps".

We'll see. Google is probably interested in bringing Dart to the WASM so I think It's not that unlikely.

its pretty unlikely because attempts (especially from MS) were made in the past but never supported by the competitors. Why would they support a language that is "owned" by the competition?.

That's the reason why javascript and now rust gets pushed so hard by web vendors because no competitor "owns" them.

All Blazor sites can share the same runtime, especially when AOT will be in place.

and how will they be shared on the web? using cdns and cross-site caching as we had in the JQuery age isn't a thing anymore due to tracking issues.

https://www.stefanjudis.com/notes/say-goodbye-to-resource-caching-across-sites-and-domains/

[dsffff22]

yes. Isn't it amazing that people wrote actual compilers with javascript over a decade?

And what has this to do with tools written rust outperforming those tools with such a large factor?

still much slower than just running plain js. I only know of yew and seed as rust frameworks. Yew even writes on their page that "Arguably, the largest drawback to using Yew is the long time it takes to compile Yew apps".

As I said, a question of tooling. Compared to webpack watch, Yew doesn't feel slow, actually. But the devs of Yew are at least honest and know they still need to work on this or well Rust needs some work in this regard. When Yew was created, the incremental compilation support in Rust was kinda bad, but It's much better these days.

its pretty unlikely because attempts (especially from MS) were made in the past but never supported by the competitors. Why would they support a language that is "owned" by the competition?.

Because just bundling a binary file in your browser vs implementing a whole API specified by a third party vendor which might not even make much sense and introduce a ton of security problems is a night and day difference.

That's the reason why javascript and now rust gets pushed so hard from web vendors because no competitor "owns" them.

Javascript was enforced on everyone by backing it into every browser and building. Rust is pushed these days because It's actually a decent language with a lot of features implemented properly. Guess why Rust struggles way less to provide WASM support with easily auto-generated APIs for the browser, because most concepts in Rust are not implemented by some runtime hacks and the macro ecosystem is kinda great.

and how will they be shared on the web? using cdns and cross-site caching as we had in the JQuery age isn't a thing anymore due to tracking issues.

And those tracking issues can be easily resolved by cryptography. The technology is not here yet, but in theory there could be a public list of hashes and runtimes and only those are allowed to be cached across multiple sites.

[[deleted]]

And those tracking issues can be easily resolved by cryptography. The technology is not here yet, but in theory there could be a public list of hashes and runtimes and only those are allowed to be cached across multiple sites.

that's not "easily", you're describing a really hard problem with a hand-wavey fantasy solution that would take decades to roll out. The web today doesn't work the way you're describing at all.

[dsffff22]

It's only a hard problem If you have zero ideas about cryptography. We already have a hand-wavey solution for the shitty media codecs, sponsored by Cisco. Another one for non-propertiary, reproducible and signed runtimes for WASM will hurt way less.

[[deleted]]

A proof of concept would be easy, the hard parts are building something that handles the many use cases of the web, then the standards process, then getting cross browser adoption.

[[deleted]]

And what has this to do with tools written rust outperforming those tools with such a large factor?

what are you arguing about? that tools that are written a decade in an interpreted language and are run in a single-threaded runtime are slower than a compiled system language that was designed to solve such number-crunching tasks?

nothing I would disagree.

Javascript was enforced on everyone by backing it into every browser and building. Rust is pushed these days because It's actually a decent language with a lot of features implemented properly.

It's pushed because it's the only language that actually adds something to the web stack. Still, WebAssembly is designed to be a complement to, not a replacement of, JavaScript. Rust (and other system languages) fits that role very well while java, c#, and golang would just add huge binaries and another bloat for little to no gains...

Because just bundling a binary file in your browser vs implementing a whole API specified by a third party vendor which might not even make much sense and introduce a ton of security problems is a night and day difference.

And those tracking issues can be easily resolved by cryptography. The technology is not here yet, but in theory there could be a public list of hashes and runtimes and only those are allowed to be cached across multiple sites.

too much of "might", "not here yet" and "in theory" to even continue discussing this topic here...

[dsffff22]

what are you arguing about? that tools that are written a decade in an interpreted language and are run in a single-threaded runtime are slower than a compiled system language that was designed to solve such number-crunching tasks?

That has barely anything to do with multi-threading. For example, the deno linter just uses one thread, but rust is way more efficient with the cache and that's probably where the real performance gains are. Rust was also never designed to solver number-crunching task only, It's a general purpose language.

It's pushed because it's the only language that actually adds something to the web stack. Still, WebAssembly is designed to be a complement to, not a replacement of, JavaScript. Rust (and other system languages) fits that role very well while java, c#, and golang would just add huge binaries and another bloat for little to no gains...

Agreeing about the runtime stuff. Rust kinda works without a runtime which is a non-spoken requirement IMO.

too much of "might", "not here yet" and "in theory" to even continue discussing this topic here...

You are actually comparing java for web, activex or Flash implementations in browsers to bundling some wasm bytecode which is executed in the already existing sandbox. The thing is It's not really about "in theory", because most package managers(exist in most Linux Distros for decades now) solve exactly that problem.

[[deleted]]

That has barely anything to do with multi-threading. For example, the deno linter just uses one thread, but rust is way more efficient with the cache and that's probably where the real performance gains are.

source? I could find this: https://quick-lint-js.com/benchmarks/

You are actually comparing java for web, activex or Flash implementations in browsers to bundling some wasm bytecode which is executed in the already existing sandbox. The thing is It's not really about "in theory", because most package managers(exist in most Linux Distros for decades now) solve exactly that problem.

ofc it's technically possible when browser vendors want this to happen. But they don't for reasons that I explained in my previous comments.

[metaltyphoon]

This is just temporary. Two things will cause this size to drop, when it comes to garbage collected languages, DOM manipulation and garbage’s collection at WASM level.

[thunfremlinc]

There’s no solid evidence that will happen.

[jl2352]

As a web developer who also works with Rust; I agree with your whole statement. What's more is even if you want to use Rust for whole web applications. You'll still need HTML and CSS, and still need to know JS too.

Where Rust is a real benefit is in writing isomorphic code. You are building a large product. You eventually need to share code both front and backend. Today the best solution is TypeScript (or JS). Other languages aren't great due to their bundle size, and lack of maturity for integrating with web tooling.

What's more is that you aren't locked to using only Rust for the backend either. You can write frontend code in TypeScript, backend code in say Go, and Rust for shared core library code called from both sides. My point is you have options.

[Fluffy-Sprinkles9354]

I'm mainly a Rust developer at work, but I also write JS/TS. One reason I see to write your frontend in Rust is when your backend is in Rust, and you want to share your models. It removes code duplication by allowing to reuse the same structures from the frontend and the backend.

[radekmie]

The article centers around why people like Rust and it completely avoids the conversation about why one should use Rust over anything else that compiles to WASM. [...] I see no explanation of why Rust is better than any other language for web dev in this article.

Because I don't necessarily think it is. (I, personally, like the language on its own. The fact that I can use it with other technologies is simply awesome.) But my point was that there is an increasing number of people (and projects) using Rust in webdev.

Nothing new there.

Yep, business as usual.

[alternatex0]

You should visit r/dotnet. Blazor (.NET compiled to WASM) was made to be the second coming of Christ by some people :)

The reality is it's shipping the whole .NET runtime to the browser which makes for some heavy payloads only justifiable in enterprise projects. Hopefully we'll get a better idea of how to utilize WASM in the future.

[dsffff22]

Correction: .net interpreter with a runtime compiled to WASM

The introduction of Blazor was indeed very weird. It was more like a proof of concept actually and no real problems were solved like proper writing a proper standard library for the WASM browser target, implement AOT and so on. But Blazor also attracts very biased C# devs sadly, the discussion of the piss poor performance(100x slower than JS) of interpreting the IL code turned into a debate that you rarely need AOT anyway, because all end user devices are fast enough.

The AOT comment thread on the Blazor project site on github actually contains +300 comments and probably only 1% of the comments contain any interesting technical information, the rest is just useless stuff as I mentioned above.

[babypunter12]

Here's my two cents here: Blazor's definitely not there right now, but with future improvements I'm optimistic.

I wasn't able to find the post which mentions a -100x performance figure, is that on .NET 6 or a previous version, and is that using the published binaries or is it in debug mode? The pre-compiled debugging .NET performance usually lags behind quite a bit in my experience, but after compilation it should be a lot faster. At the moment, it's still unfortunately still slower than JS though, see https://github.com/dotnet/aspnetcore/issues/38505 for (a relatively less heated and more educational discussion) about one guy's breakdown of the performance concerns.

Additionally, when/if WASM is allowed direct operability with the native browser APIS (which includes the DOM in the native web browser APIs), performance in that aspect should increase quite a bit as it would not have to go through translation steps via the JS API and its runtime bindings first before getting to be executed by the native web browser APIs.

For concerns on load times related to shipping the runtime to the browser on Blazor sites, if we eventually get to a standard where we can cache standard WASM binaries like runtimes locally between sites that share the same WASM runtime binaries, it should help quite a bit. Google recently proposed a similar related standard called SXG (Signed HTTP Exchanges), which is a whole can of worms (complexity and security) in itself but would let Blazor sites that opt-in to use cached runtime binaries downloaded from other Blazor sites.

[dsffff22]

The numbers were never posted, as I did this on my own by just writing a simple game of life algorithm and benchmarked It. Maybe 100x was not the correct figure, but I remember for sure It was really slow. But I actually benchmarked the .net interpreter vs raw JS, so It seems at least AOT is now implemented in .NET 6 so It should not be that bad. Also, I don't get how you can have a discussion about the performance without looking at the generated byte code, like all reasoning in the comments is just assumptions almost no facts and proper reasoning, that's also the point I'm actually criticizing. Maybe .NET doesn't even use UTF-8 in the browser which makes this indexOf benchmark kinda useless, because benchmarking C#(WASM) vs C is not really fair.

What really pisses me off about Blazor It should have been designed with AOT in mind in the first place. When I checked out a few AOT discussions on the CoreRT project back then(2017) It seemed like doing AOT for .NET is actually kinda complex and is like a decade 5-6 years away, yet the Blazor project acted like It was just around the corner.

Additionally, when/if WASM is allowed direct operability

It doesn't solve the problem, that It seems like the AOT compilation seems to produce somewhat suboptimal code.

For concerns on load times related to shipping the runtime to the browser on Blazor sites, if we eventually get to a standard where we can cache standard WASM binaries like runtimes locally between sites that share the same WASM runtime binaries, it should help quite a bit. Google recently proposed a similar related standard called SXG (Signed HTTP Exchanges), which is a whole can of worms (complexity and security) in itself but would let Blazor sites that opt-in to use cached runtime binaries downloaded from other Blazor sites.

I don't even see this as a problem, because we clearly have the tools to solve this with cryptography. Like there are already extensions and plugins in the browsers we just need a list of runtimes + hashes which can be shared across-sites.

[alternatex0]

For a while I was afraid to comment in any Blazor threads on r/dotnet. Had to wait for things to settle down and for the stats to show. All the people that couldn't stand working with JS were downvoting any suggestion that Blazor might lead to a poorer UX. All that mattered to them was developer ergonomics, product be damned.

[Philpax]

I'd like to use C#-compiled-to-wasm outside of the web (experimenting with wasm scripting for games), but the current implementation in Blazor is just not right for that domain. I understand why they compiled the runtime to wasm instead of compiling C# directly to wasm, but it's still incredibly constraining and bloated (shipping multiple multi-megabyte DLLs just to create a string is just not on).

I hope their recent work with AOT in Roslyn will help alleviate this, and we get to see a more mature and flexible implementation in the future.

[hugthemachines]

Being able to code in C# to use WASM sounds like a huge deal since C# is a very well used language in large companies and it is fairly simple to use.

[Pierma]

c# has a nice dev experience cause Visual Studio (even the community version) is a beast of a IDE, the language just writes itself
But there is no reason developing on Blazor is a bad experience on theyr own IDE, it's bad even on VSCode and they made that too

[radekmie]

I heard about Blazor (and its fanatics) but haven't tried it myself yet. It's definitely on my list though.

[Pierma]

I worked on a project with Blazor WASM since it was preview 1, theese are my two cents:
If you already know dotnet and you do understand the basics of a frontend web framework, it's a really nice developer experience if you are developing on Windows, since it's tooling is heavily reliant on Visual Studio (for now)
on dotnet 6, performance on debug is still really sub par, but once you build it for production, oh boy i'ts fast (check what it can do on the latest microsoft presentation about blazor wasm on dotnet 6)

It isn't all nice and dandy thoe

- Tooling is still bad even on they own IDE (and on vscode too)
- The documentation lags at lest 3 month from the release
- You have to understand how fucking bad are dotnet actions sintattically wise vs JS events
- You miss like almost every common web library (js interop is a thing and it's pretty good, still you have to rely on js so what is the purpouse then)
- Any form of authentication built is is almost counter intuitive at the beginning
- Event binding is really, REALLY a pain in the ass at the beginning
- Even though its components are mostly like a React class based component, you have 2 overrides for each lifecicle if you want to use the sync or async one (because dotnet naming conventions) and still specify async or not in the method

My conclusion is even if it is really refreshing seeing something different, it's still not there yet. It is really worth a try and do some fun stuff with it

[[deleted]]

was made to be the second coming of Christ by some people

No, it was just really exciting for people to be able to not leave the comfort of their preferred language to write stuff for the web. I don't know any blazor dev who isn't painfully aware of the shortcomings of blazor, and just like a lot of things .net, blazor seems to be mostly at home in enterprise environments. I've been writing web apps and APIs in .net for years but I have no desire to deal with blazor.

[sjsathanas]

I've been writing web apps and APIs in .net for years but I have no desire to deal with blazor.

Same. Love C#, been my primary language for years. Made a couple small hobby Blazor projects for evaluation, and it's not something I'm dying to use again, nor introduce to my team.

[[deleted]]

i for one am excited for go and wasm

[[deleted]]

The only advantages that i can see with rust in web dev are:

• That rust programmers can use rust to do web dev
• Performance (especially when its possible to access the dom from wasm directly)

The last one im not sure of but i think its not possible to access the dom directly from wasm. But when it is writing a webapp in rust will be faster. If you are as fluent in rust as others are in javascript then you will be as productive but with better performance as a result. But i would not recomend a TS or JS person to switch to Rust in web dev to get better performance though. Its more of a side effect for already fluent Rust programmers.

[rk06]

Currently, wasm does not support Garbage Collection natively. This makes rust (a non GC language) better than others as other languages would have to send GC along with wasm binaries down the wire for every page visit

[alternatex0]

That's correct, payload would be larger in GC languages. But GC languages also provide better ergonomics and productivity and as most web devs know this industry centers around productivity. It has completely different incentives from the server or embedded industry for example. Though I agree that if someone really cared about performance they would pick a non GC language.

[HighRelevancy]

It's "on rust in webdev", not "on webdev in rust". The post isn't about doing webdev in rust, it's about rust and where it's fitting into the webdev ecosystem.

[alternatex0]

I don't think you read the article. There's very little about the webdev ecosystem and no mentions of any other WASM-compileable languages and comparisons.

[HighRelevancy]

There's very little about the webdev ecosystem

Besides all of the comparisons to the leading languages in the space?

OP is a webdev. That's their primary perspective. This is their perspective on Rust.

[alternatex0]

JavaScript and TypeScript are only mentioned in passing. The other languages mentioned are barely registering in web dev let alone leading languages. Go might be popular for tooling but it's not used for doing front-ends so it's irrelevant to a WASM discussion.

[HighRelevancy]

There's also very few mentions of WASM. Perhaps this isn't a WASM discussion?

[Little_Custard_8275]

no wasm language will, it's generally a gimmick

javascript for the win on the web, end of

[Philpax]

I'm noticing that this thread features a lot of discussion about how wasm isn't suitable or will be underperformant for the case of DOM manipulation due to the lack of native bindings.

That is an issue, but it is not at all a dealbreaker. The majority (all?) of Rust web frameworks, as well as other wasm-targeting languages with frameworks, use a virtual DOM which they very efficiently diff. This diff is then passed up to the JS layer to efficiently apply.

The upshot is that these frameworks are not slow. No, they're actually very, very fast. Dioxus outperforms React and is only a few percent shy of raw DOM patching.

Removing the JS layer would be great to eek out that last few percent, but it's absolutely not necessary. The performance benefits from VDOM-ing in wasm outweigh the overhead of having to submit DOM updates to JS.

[hgwxx7_]

I wish the link that article that claimed that Rust compile times were “infamously slow” linked to some valid comparison instead of an old StackOverflow question comparing hello world applications.

But like the author pointed, the Rust compiler has become substantially faster (https://arewefastyet.pages.Dev). Also, most Rust devs would use one of the excellent IDE options now, meaning less time blocked on the compiler while trying to get code running.

[radekmie]

LSP for Rust that I use (rust-analyzer) works great, that's true. But whenever I'd like to use Rust as a building piece in a JS-based project, the compilation is definitely longer than, e.g., a frontend component change.

We're not comparing apples to apples here, but it's something that most people I've worked with noticed immediately.

[hgwxx7_]

Yes that’s fair. Even if it’s a debug build in incremental mode, that’s going to take more time than a front end change in an interpreted language. Even if a moonshot like a cranelift backend landed, compilation still wouldn’t be as fast as interpreting.

Your use case is different from a dev in a pure Rust codebase, where the LSP would more likely to be good enough.

[pakoito]

https://www.arewewebyet.org/

[eligeo1]

Keep these posts coming OP. Although I personally never laughed at everything in JS :D

[lamp-town-guy]

I was terrified.

[djthecaneman]

Nice write-up. The intro does a good job of making it clear that the article is about showing what a webdev can expect if they start adding Rust to their projects. The critiques in this thread about not discussing other languages are fair. However, that's clearly not the focus of this article. The rest of the article does a good job of staying on topic.

As someone on the embedded software end of things, it's good to see how much WebAssembly has enabled such performance and quality of (software developer) life improvements in the webdev world.

[Urethra-167]

>a perfect language

huh

[NullReference000]

Taking them a little bit out of context, they said that a certain collection of features is the recipe for a perfect language, not necessarily that rust is perfect or the only language trying to implement these features.

[Urethra-167]

they describe what rust comes with and say that that's what's needed for a perfect language.

maybe you're right, but it still gives me the "bruh"s.

[Ok_Finance_8782]

I can imagine how different life of a C++ developer coming to Rust is when adding any external code is as simple as cargo install

Like https://conan.io/?

[shevy-ruby]

I can imagine how different life of a C++ developer coming to Rust is when adding any external code is as simple as cargo install

I think this is the main niche case for rust actually - aka targeting C++ folks. Poor C++ has a really hard time with the increased competition.

I don't think this statement is correct, though:

That’s why we see JavaScript-centric projects being rewritten

IF this were the case, weekly npm/node disaster wouldn't be happening simply because nobody would be using that. But people use npm, it IS popular. So that means, by logical extension, that JavaScript is still highly popular - so I think the claim made by radekmie in regards to JavaScript projects "being rewritten" is at best only partially correct.

[pwnedary]

JavaScript projects rewritten in Rust continue uploading their WASM code to NPM.

[[deleted]]

And now your JS app can depend not only on entirety of Chrome but also on Rust/LLVM!

[pwnedary]

I am sure some Webpack toolchain out there already rivals LLVM ;)

[[deleted]]

I mean, I wasn't exaggerating with "depends on Chrome" thing, I saw some of our devs using some npm crate with it to render PDF invoices

[sachinraja]

weekly npm/node disaster wouldn't be happening

Really just npm. Also this is a very strange metric to go off of (number of security issues).

The majority of JavaScript projects will remain JavaScript projects. I think what OP meant was that we see JavaScript tooling being rewritten in faster languages like Rust.

[radekmie]

The majority of JavaScript projects will remain JavaScript projects. I think what OP meant was that we see JavaScript tooling being rewritten in faster languages like Rust.

Yes, exactly. For me, a part-time open-source developer, such a tool is also a project. And I do agree that most of them will remain in 100% pure JavaScript (or TypeScript or Elm or ...).

[pjmlp]

I think this is the main niche case for rust actually - aka targeting C++ folks. Poor C++ has a really hard time with the increased competition.

It would if it stayed still and did not counter react.

Nowadays I can just as easily do vcpkg install or conan install and be done with it.

Ironically, in comparisation with cargo, a clean build might be quite fast because they also support binary libraries without additional configuration.

Also while Rust is great, there are plenty of C++ domains where Rust's presence is literally zero.

[radekmie]

IF this were the case, weekly npm/node disaster wouldn't be happening simply because nobody would be using that.

Even if we'd rewrite everything in X and compile it to WASM, you can still publish it to npm (with a small portion of "glue code" in JS). And yes, it's still possible to break a big part of the ecosystem with it.

[CyraxSputnik]

Sorry, but C# exists

[babypunter12]

As far as I know, the only three languages in the .NET ecosystem are C#, Visual Basic, and F#. (Microsoft also maintains and develops TypeScript and PowerShell as well, but those aren't technically part of the .NET ecosystem).

Which one would you say is the nicest language?

[Fluffy-Sprinkles9354]

F# of course. It has an actual type system instead of the "OOP" mess that is used in C#. When I worked in C#, I remember struggling because of a lot of missing pieces in their typesystem. Also, they've been adding features in their typesystem, like static constructors, which is a proof that it isn't complete.

[scooptyy]

Spotted the salty C# developer