HN Gopher Feed (2017-10-22) - page 1 of 10
 
___________________________________________________________________
Rust to WebAssembly Made Easier
29 points by adamnemecek
https://lord.io/blog/2017/wargo/#
___________________________________________________________________
 
flavio81 - 2 hours ago
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!
 
  hacker_9 - 1 hours ago
  Why would you use Rust over JS for front end work though?
 
    geofft - 50 minutes 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....
    , 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  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.
 
    guessmyname - 48 minutes ago
    For the same reason people use JavaScript in the back-end
    (Node.JS) ? Code ReuseIf 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.
 
      tomjakubowski - 30 minutes ago
      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!
 
      yeukhon - 14 minutes ago
      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).
 
    supergreg - 1 hours 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 - 57 minutes ago
      Like Java did 15years ago.
 
  dualogy - 27 minutes 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 {{TypeS
  cript/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 - 18 minutes ago
    > that transpile neatly to JSAs a PL researcher, I can assure
    you that there is nothing "neat" about transpiling to JS. JS is
    an awful compilation target.
 
  milesokeefe - 1 hours 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.
 
    steveklabnik - 53 minutes ago
    You can bridge it though. See https://github.com/rust-
    webplatform/rust-todomvc , rendered at 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 - 37 minutes 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.
 
    ozten - 1 hours ago
    Not really, minimal bridge only has to be written once and is
    reusable across any language that compiles to Web Assembly.
 
    adamnemecek - 1 hours ago
    "Where we're going, we don't need a DOM."
 
    pjmlp - 16 minutes ago
    Today, canvas and WebGL are enough, we don't need DOM.Tomorrow,
    DOM access might actually exist.
 
kibwen - 13 minutes ago
If anyone here has an experience report from attempting to use Rust
with WebAssembly, the Rust team is currently seeking active
feedback from users!https://internals.rust-lang.org/t/state-of-
webassembly-and-r...In particular:1. If you?re using wasm/asmjs and
Rust today, how?s it going? Do things generally work well? Are
there weird pain points? Is crates.io missing support for key
functionality? Is key functionality missing from rustc?2. If you
looked at using wasm/asmjs and Rust historically, but decided not
to do so, why not? What are the blockers for enabling your use case
with wasm/asmjs and Rust?3. In general do you have an idea for a
use case with wasm/asmjs and Rust on the web? We?re wondering if
there?s some sweet uses of wasm/asmjs which really showcase how
Rust can shine on the web.(I'm not the author of that thread,
please leave feedback there to keep it all collected in one place.)