5 ms·

I am not a Rust fan nor user, but I must heartily applaud the sign that the times are changing -- for that we will finally free ourselves from being forced to h

I am not a Rust fan nor user, but I must heartily applaud the sign that the times are changing -- for that we will finally free ourselves from being forced to have only one choice (Javascript) for delivering frontend code at the browser. Looking forward to many interesting stuff done by leveraging Webassembly to the max!

milesokeefe 9y ago
Not exactly, WebAssembly has no direct DOM access so if you want have your front end run in WebASM you’ll still need JavaScript to make anything work. Personally I think that’s a good thing, I don’t want front ends to get any more obfuscated than they have gotten.
- ozten 9y ago
  Not really, minimal bridge only has to be written once and is reusable across any language that compiles to Web Assembly.
  - tyingq 9y ago
    That minimal bridge is anywhere from 10x to 100x slower than pure JS right now. https://github.com/rust-webplatform/rust-webplatform/issues/20 https://github.com/rust-webplatform/rust-webplatform/issues/...
- adamnemecek 9y ago
  "Where we're going, we don't need a DOM."
- steveklabnik 9y ago
  You can bridge it though. See https://github.com/rust-webplatform/rust-todomvc https://github.com/rust-webplatform/rust-todomvc , rendered at http://rust-webplatform.github.io/rust-todomvc/ http://rust-webplatform.github.io/rust-todomvc/ That said, I think there are better opportunities for wasm than trying to oust JavaScript; that's not really a stated goal of the wasm project.
  - shams93 9y ago
    Its definitely meant to make javascript more capable. Currently while you can do some things with webaudio for example, with WASM you can use complex DSP, you can also build out valuable audio code that you want to keep locked down in binary format where someone getting your algorithm could do damage to your business but in the case of a webaudio DAW the code can't be run on the server.
    - steveklabnik 9y ago
      I’d argue it’s intended to make the platform more capabale. JS is clearly part of the platform. Really though, the point is that wasm’s goals aren’t somehow eliminating JavaScript, but complimenting it.
      - krapp 9y ago
        >the point is that wasm’s goals aren’t somehow eliminating JavaScript, but complimenting it That may not be the goal of WASM's creators, but it will certainly be the goal of many of its implementers.
  - flavio81 9y ago
    >better opportunities for wasm than trying to oust JavaScript; that's not really a stated goal of the wasm project. Yes, that's what the wasm guys say, however, what I think is that it will effectively displace Javascript. Not only that, the labor market implications for the current JS full stack developers and front-end developers will be interesting.
- pjmlp 9y ago
  Today, canvas and WebGL are enough, we don't need DOM. Tomorrow, DOM access might actually exist.
  - rickycook 9y ago
    but then we are kinda back in the realms of flash and why that was all so horrific
    - pjmlp 9y ago
      Yep, welcome to the future. Without having to deal with JavaScript.
    - jlebrech 9y ago
      it was only horrific because it had no ui libraries, also what was horrific is that it was a second class citizen.
- jlebrech 9y ago
  ditching html and css is not obfuscation :P
hacker_9 9y ago
Why would you use Rust over JS for front end work though?
- supergreg 9y ago
  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.
  - Thaxll 9y ago
    Like Java did 15years ago.
    - flavio81 9y 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.
- geofft 9y ago
  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.txt 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.
dualogy 9y ago
> being forced to have only one choice (Javascript) When it comes to JS, you already have a gazillion prettier and more enthralling languages to choose from that transpile neatly to JS. Are {{TypeScript/Flow/ReasonML/PureScript/Elm/CoffeeScript/Haxe/Haste/GHCJS/Fay/Fable/WebSharper/Scala.js/GorillaScript/Roy/Idris/etc}} really not enough choice? While wasm is still busy being hatched and birthed, JS has already long become "the web's choice compilation target". That's not to say that projects compiling to wasm aren't worthwhile of course :D but I observed that the precursor "asm.js" paradigm didn't get widely adopted even though browsers already do optimize-for/precompile it. Unless the whole "EcmaScript + Browser APIs" (dom/xhr/string/array/etcpp) are readily-available from within wasm by default without bridging (ie "the modern web client runtime" exposed fully within wasm -- in a prim-op/pointer fashion I guess), I remain mildly skeptical that it'll take off as "a full JS replacement" rather than remain a pluggable niche component for specialized high-perf computations and such..
- justinpombrio 9y ago
  > that transpile neatly to JS As a PL researcher, I can assure you that there is nothing "neat" about transpiling to JS. JS is an awful compilation target.
  - dualogy 9y ago
    How so? Interested in your elaboration. I would have surmised it'd be very smooth and fun to target, given all the freedoms it gives you (free-form records, dynamically-sized arrays, no types). All the things that are "foot guns" when hand-writing it, should make codegen-ing it a lot easier. Because when a code-gen "shoots yourself in the foot", one can just fix the transpiler once instead of one's individual JS code-base(s) time-and-again
    - TazeTSchnitzel 9y ago
      For one thing, JS has no unstructured control-flow. So your compilation process involves breaking down ifs, loops and so on into branches, then… trying to messily reconstruct them.
colde 9y ago
Have you looked at Dart? https://webdev.dartlang.org/ https://webdev.dartlang.org/

milesokeefe 9y ago

Not exactly, WebAssembly has no direct DOM access so if you want have your front end run in WebASM you’ll still need JavaScript to make anything work. Personally I think that’s a good thing, I don’t want front ends to get any more obfuscated than they have gotten.

ozten 9y ago
Not really, minimal bridge only has to be written once and is reusable across any language that compiles to Web Assembly.
- tyingq 9y ago
  That minimal bridge is anywhere from 10x to 100x slower than pure JS right now. https://github.com/rust-webplatform/rust-webplatform/issues/20 https://github.com/rust-webplatform/rust-webplatform/issues/...
adamnemecek 9y ago
"Where we're going, we don't need a DOM."
steveklabnik 9y ago
You can bridge it though. See https://github.com/rust-webplatform/rust-todomvc https://github.com/rust-webplatform/rust-todomvc , rendered at http://rust-webplatform.github.io/rust-todomvc/ http://rust-webplatform.github.io/rust-todomvc/ That said, I think there are better opportunities for wasm than trying to oust JavaScript; that's not really a stated goal of the wasm project.
- shams93 9y ago
  Its definitely meant to make javascript more capable. Currently while you can do some things with webaudio for example, with WASM you can use complex DSP, you can also build out valuable audio code that you want to keep locked down in binary format where someone getting your algorithm could do damage to your business but in the case of a webaudio DAW the code can't be run on the server.
  - steveklabnik 9y ago
    I’d argue it’s intended to make the platform more capabale. JS is clearly part of the platform. Really though, the point is that wasm’s goals aren’t somehow eliminating JavaScript, but complimenting it.
    - krapp 9y ago
      >the point is that wasm’s goals aren’t somehow eliminating JavaScript, but complimenting it That may not be the goal of WASM's creators, but it will certainly be the goal of many of its implementers.
- flavio81 9y ago
  >better opportunities for wasm than trying to oust JavaScript; that's not really a stated goal of the wasm project. Yes, that's what the wasm guys say, however, what I think is that it will effectively displace Javascript. Not only that, the labor market implications for the current JS full stack developers and front-end developers will be interesting.
pjmlp 9y ago
Today, canvas and WebGL are enough, we don't need DOM. Tomorrow, DOM access might actually exist.
- rickycook 9y ago
  but then we are kinda back in the realms of flash and why that was all so horrific
  - pjmlp 9y ago
    Yep, welcome to the future. Without having to deal with JavaScript.
  - jlebrech 9y ago
    it was only horrific because it had no ui libraries, also what was horrific is that it was a second class citizen.
jlebrech 9y ago
ditching html and css is not obfuscation :P

hacker_9 9y ago

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

supergreg 9y ago
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.
- Thaxll 9y ago
  Like Java did 15years ago.
  - flavio81 9y 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.
geofft 9y ago
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.txt 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.

dualogy 9y ago

> being forced to have only one choice (Javascript) When it comes to JS, you already have a gazillion prettier and more enthralling languages to choose from that transpile neatly to JS. Are {{TypeScript/Flow/ReasonML/PureScript/Elm/CoffeeScript/Haxe/Haste/GHCJS/Fay/Fable/WebSharper/Scala.js/GorillaScript/Roy/Idris/etc}} really not enough choice? While wasm is still busy being hatched and birthed, JS has already long become "the web's choice compilation target". That's not to say that projects compiling to wasm aren't worthwhile of course :D but I observed that the precursor "asm.js" paradigm didn't get widely adopted even though browsers already do optimize-for/precompile it. Unless the whole "EcmaScript + Browser APIs" (dom/xhr/string/array/etcpp) are readily-available from within wasm by default without bridging (ie "the modern web client runtime" exposed fully within wasm -- in a prim-op/pointer fashion I guess), I remain mildly skeptical that it'll take off as "a full JS replacement" rather than remain a pluggable niche component for specialized high-perf computations and such..

justinpombrio 9y ago
> that transpile neatly to JS As a PL researcher, I can assure you that there is nothing "neat" about transpiling to JS. JS is an awful compilation target.
- dualogy 9y ago
  How so? Interested in your elaboration. I would have surmised it'd be very smooth and fun to target, given all the freedoms it gives you (free-form records, dynamically-sized arrays, no types). All the things that are "foot guns" when hand-writing it, should make codegen-ing it a lot easier. Because when a code-gen "shoots yourself in the foot", one can just fix the transpiler once instead of one's individual JS code-base(s) time-and-again
  - TazeTSchnitzel 9y ago
    For one thing, JS has no unstructured control-flow. So your compilation process involves breaking down ifs, loops and so on into branches, then… trying to messily reconstruct them.

colde 9y ago

Have you looked at Dart? https://webdev.dartlang.org/ https://webdev.dartlang.org/