Hacker News Reader

Comment by hacker_9 | Hacker News Reader

Why would you use Rust over JS for front end work though?

For ... reasons ... I want to build a Chrome extension that implements USB-IP support as described in the Linux kernel https://www.kernel.org/doc/Documentation/usb/usbip_protocol.... , with the Chrome USB API on one end and a websocket tunnel on the other, leading to websockify running on an EC2 instance. (Or, apparently, WebUSB is a thing these days and I don't need an extension?) I could do protocol parsing in JS, but Rust seems like a much more well-suited language for this.

The frontend itself, as in the UI, I'll write in JS, but there are parts that need to be running client-side that aren't really "frontend".

Someone I know built a thing which (for more complicated reasons) ends up speaking HTTPS tunneled over a websocket connection, with a need to terminate TLS within the local JavaScript context. There are a few pure-JS TLS libraries, but it'd be nicer to use an actual TLS library.

Someone else I know literally built a Kerberos client in JS. Again, having the UI in JS seems good but the protocol bits probably shouldn't be in JS. (Also, it is possible that I keep weird company.)

As a maybe more sympathetic example, consider noVNC or Guacamole, which are JavaScript clients for VNC. It would be a lot simpler to just hand an existing VNC implementation a <canvas> and let it do what it's been doing on desktop for years (drawing to a region of memory) than to reimplement VNC in JS.

Because a lot of us really hate JavaScript. I see JavaScript as being somewhat like racism. It used to be really bad and it's gotten a little better. And those who are happy with the status quo (JS devs) keep saying stuff along the lines of, "it's better now...I thought we were past this." They're continually told, "no, from our perspective it's a fundamentally-broken language and we won't be happy until we can write anything front-end without a single line of JavaScript." And yet because they're happy with the way things are, they have problems really hearing that message and understanding just how unacceptable the current situation is for others.

> I see JavaScript as being somewhat like racism

That's a really dumb thing to say.

Btw, WebAssembly has nothing to do with choice, but with performance, its primary purpose being to let C/C++ to run in the browser. And was preceded by Asm.js.

This is actually very relevant. Going with WebAssembly means you're going low level — e.g. a language author will no longer have the JavaScript runtime to piggyback on, no garbage collector for example. Which might be good news for a language like Haskell, because people now have the opportunity to run the actual GHC runtime and garbage collector in the browser. But you have to port it all and the binary size downloaded by users will have to include everything.

So language implementations like Scala.js or PureScript aren't rushing to WebAssembly yet. In the future anything is possible of course, but currently it's not a useful compilation target for garbage collected languages.

Therefore I don't have good news — if diversity is what you're looking for, then know that WebAssembly was built for C/C++ and Rust and languages not fitting this narrow profile are out.

> "a language author will no longer have the JavaScript runtime to piggyback on"

WASM has been designed to run in the same VMs that run JavaScript.

First, Rust is a far superior language to JavaScript, so even if it were a 1-for-1 swap, we'd still be coming out ahead. But you've forgotten a huge example of a language that fits into your "narrow profile." Swift is also an LLVM language and people are already writing front-end code in Swift for Apple platforms. Being able to share front-end code across web and iOS/macOS platforms will be a huge win. There hasn't been much movement towards compiling Swift to WebAssembly yet, but there's nothing that should make that much more difficult than Rust.

But the list of LLVM-capable languages is much longer than that. So even if it does force an initial download of a GC, that's still more choice than we have now. And you seem to still be assuming that the JavaScript runtime is a good thing. Lots of us feel otherwise. It's a huge source of bugs and vulnerabilities and the sooner we can ship browsers that no longer rely on it, the better it will be for everyone. WebAssembly will eventually get the equivalent of shared libraries so GCs can be downloaded once from a CDN and cached for future use.

WebAssembly is the first web platform development that promises a future that doesn't rely on JavaScript in any capacity. It's obviously not there yet and initial forays into it will be primarily about performance until crucial web APIs like DOM manipulation are enabled for the platform. But the future of WebAssembly really is about choice and not just performance. Don't confuse the current state with the end state.

For the same reason people use JavaScript in the back-end (Node.JS) — Code Reuse

If you are a Rust developer and need to create some code for the frontend of a web service, this solution allows you to keep your confidence in the language that you are already used to use (Rust in this example) instead of having to worry about the ambiguity of the JavaScript language.

I would expect WebAssembly to be used to implement things like video codecs that aren't provided by the host browser, not for typical frontend code. I'm happy to be proven wrong by ambitious WebAssemblers, though!

But don’t forget you still have css and html in your frontend stack. Javascript libraries need to be written in Rust so we can mainpluate the DOM (which needs support with browser API).

i think that’s probably right, but sharing things like form/api validation so that you can fairly reliably say that there’s unlikely to be backend validation errors (other than DB) would be nice... and it doesn’t require high throughput at all

Not exactly rust, but there's benefits to running the same language both on the front and back end. You could reuse template systems and validation logic for example.

Like Java did 15years ago.

But it's not a fair comparison:

1. Java (apple) plugins were not built into the browser; and it was not an internationally agreed standard between browser vendors. You needed to install a big plugin to make it work.

2. Due to the computing capacity of the average PC on those times, startup was slow and it consumed lots of memory.

3. Java applets could only be written in Java.

In comparison:

1. Webassembly is an standard, and its support is built into the browser.

2. Webassembly is very high performance, higher than what users come to accept as good (= Javascript under Google V8)

3. Startup should be quick.

Note the GP's use of "delivering" - people have been using non-JS languages for a while and they have mature tooling & good communities. Elm, ClojureScript, etc. And the semi-Javascripts like TypeScripts and CoffeeScript.

WebAssembly can hit better perf

How much better and for what cost?

Last comparison I saw gave it about 25% compared to js. And it currently loses in dom manipulation, if you do that a lot it will be slower. It can of course still be worth it but I think people sometimes overestimates the performance gains of wasm.

Reply on news.ycombinator.com