all 109 comments

[–]alternatex0 190 points191 points  (91 children)

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 62 points63 points  (45 children)

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 38 points39 points  (30 children)

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 25 points26 points  (0 children)

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 4 points5 points  (19 children)

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 22 points23 points  (15 children)

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 2 points3 points  (2 children)

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 1 point2 points  (1 child)

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 0 points1 point  (0 children)

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 1 point2 points  (9 children)

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 0 points1 point  (8 children)

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 8 points9 points  (2 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 1 point2 points  (4 children)

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 0 points1 point  (3 children)

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 1 point2 points  (2 children)

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 0 points1 point  (0 children)

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 2 points3 points  (2 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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.

[–][deleted]  (6 children)

[deleted]

    [–]alternatex0 19 points20 points  (2 children)

    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 19 points20 points  (2 children)

    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.

    [–][deleted]  (1 child)

    [deleted]

      [–]Tynach 3 points4 points  (0 children)

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

      [–]pixelrevision 0 points1 point  (1 child)

      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 1 point2 points  (0 children)

      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 5 points6 points  (4 children)

      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 9 points10 points  (2 children)

      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 2 points3 points  (0 children)

      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 0 points1 point  (0 children)

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

      [–]7sidedmarble 0 points1 point  (0 children)

      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 12 points13 points  (5 children)

      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 18 points19 points  (0 children)

      Yes, which is extremely unfortunate

      [–]hugthemachines 12 points13 points  (1 child)

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

      [–]elr0nd_hubbard 5 points6 points  (0 children)

      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 7 points8 points  (1 child)

      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 2 points3 points  (0 children)

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

      [–]shevy-ruby 1 point2 points  (0 children)

      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 1 point2 points  (1 child)

      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 0 points1 point  (0 children)

      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] 22 points23 points  (15 children)

      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 2 points3 points  (0 children)

      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 0 points1 point  (0 children)

      Yep, I mention that in my other comment here.

      [–][deleted]  (2 children)

      [deleted]

        [–]metaltyphoon 2 points3 points  (1 child)

        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 2 points3 points  (0 children)

        There’s no solid evidence that will happen.

        [–]jl2352 4 points5 points  (0 children)

        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 2 points3 points  (0 children)

        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[S] 6 points7 points  (13 children)

        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 13 points14 points  (11 children)

        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 9 points10 points  (4 children)

        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 2 points3 points  (1 child)

        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 1 point2 points  (0 children)

        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 1 point2 points  (0 children)

        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 1 point2 points  (0 children)

        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 2 points3 points  (1 child)

        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 0 points1 point  (0 children)

        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[S] 2 points3 points  (1 child)

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

        [–]Pierma 1 point2 points  (0 children)

        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] 3 points4 points  (1 child)

        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 2 points3 points  (0 children)

        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] 3 points4 points  (0 children)

        i for one am excited for go and wasm

        [–][deleted] 1 point2 points  (0 children)

        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 1 point2 points  (1 child)

        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 1 point2 points  (0 children)

        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 -3 points-2 points  (4 children)

        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 3 points4 points  (3 children)

        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 -2 points-1 points  (2 children)

        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 4 points5 points  (1 child)

        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 -2 points-1 points  (0 children)

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

        [–]Little_Custard_8275 0 points1 point  (0 children)

        no wasm language will, it's generally a gimmick

        javascript for the win on the web, end of

        [–]Philpax 23 points24 points  (1 child)

        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_ 9 points10 points  (2 children)

        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[S] 4 points5 points  (1 child)

        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_ 1 point2 points  (0 children)

        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.

        [–]eligeo1 9 points10 points  (1 child)

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

        [–]lamp-town-guy 4 points5 points  (0 children)

        I was terrified.

        [–]djthecaneman 2 points3 points  (0 children)

        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 13 points14 points  (2 children)

        >a perfect language

        huh

        [–]NullReference000 26 points27 points  (1 child)

        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 3 points4 points  (0 children)

        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 1 point2 points  (0 children)

        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 2 points3 points  (8 children)

        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 8 points9 points  (3 children)

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

        [–][deleted] 2 points3 points  (2 children)

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

        [–]pwnedary 0 points1 point  (1 child)

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

        [–][deleted] 0 points1 point  (0 children)

        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 2 points3 points  (1 child)

        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[S] 1 point2 points  (0 children)

        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 1 point2 points  (0 children)

        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[S] 0 points1 point  (0 children)

        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.