33 ms·

Single Page Applications using Rust

886 points by rkwz 6y ago

sharpercoder 6y ago
The promise of Rust is safe and fast low-level development. What is the primary selling point of using rust for webdev? Speed? I can mainly see disadvantages when using rust for this scenario.
- kolektiv 6y ago
  Well, that's definitely a sweet-spot, but as a by-product of that, Rust is still a well-thought through language with a strong and logical type system, some very useful features for expressing domain models, etc. and a model of memory management which maps very well to WASM. So if you already know Rust, this is a short and logical step. If you don't already know Rust, I wouldn't learn it just to write web apps in - but if you do, you now have all the advantages of "same language client/server side" as well as the advantages of safety, good libraries in certain spaces, etc.
  - Vinnl 6y ago
    > I wouldn't learn it just to write web apps in I'm going to be looking into the other way around: writing a web app in it to learn it. Seems like a great use case that would make it easier for me to learn, as someone who has experience with web apps and not so much with desktop software.
- skocznymroczny 6y ago
  Possibility of sharing code between backend and frontend.
  - hinkley 6y ago
    Yes. Isomorphic code was always about having to prove the correctness of a smaller body of code. Web assembly will see a whole new round of people trying to do monoglot programming. Which I welcome, because I like JavaScript well enough but I don’t like writing it all day, every day, for years at a time.
- danShumway 6y ago
  A few advantages: - Rust compiles to WASM, not JS, so you can actually take advantage of its low-level nature in the browser for performance critical tasks within your app. - The Rust code you're writing is still statically compiled, so you still get to take advantage of Rust's typechecking and IDE features. - Some people just like writing Rust code more than Javascript. Part of the reason Javascript took off so quickly on the server was because there's a huge productivity boost from using one language everywhere. Similarly, if you love Rust but think that Javascript paradigms around prototypes, closures, or `this` are weird, you get to ignore that and take advantage of one of the best app distribution platforms in the world without learning a new language. I pretty solidly hold to the position that increasing language diversity on the web is a good thing. Particularly with Rust, since they've put in the work to have proper, accessible support that's still separating app logic from DOM layout and CSS styling. I'm really happy with how their community has approached building out Rust as a first-class language on the web rather than just as native language that happens to have a web compile target.
  - muglug 6y ago
    > you can actually take advantage of its low-level nature in the browser for performance critical tasks within your app. Yeah, but the problem is that 99.9% of front-end work is only performance-critical for DOM rendering (the 0.1% is stuff like video encoding & decoding) and WASM can't help with that.
    - cogman10 6y ago
      > the 0.1% is stuff like video encoding & decoding In which case, rust still isn't a good fit for a front end library (Unless you are patching in support for a new codec into old browser). Frankly, the browser will have a faster version of the codec that can also take advantage of other hardware that you wouldn't want to expose to WASM.
    - brundolf 6y ago
      > 99.9% of front-end work is only performance-critical for DOM rendering There are two meanings of "DOM rendering" in the context of UI-as-a-function-of-state libraries: 1) generating the virtual DOM from data, and 2) modifying the real DOM to match it. Arguably there's even a 3) browser reflow as a result of those DOM changes. You're right that 2 and 3 can't really be helped by WASM. But 1 can, and while it's not usually the bottleneck, it certainly can be. At my last company it was not terribly uncommon that fixing UI jank came down to eliminating unnecessary React render function calls because the sum total of them all - running the actual JavaScript logic - was taking too long. Assuming yew computes the virtual DOM in WASM (I don't see how it could be otherwise), the performance increase could definitely be beneficial for certain highly-complex apps.
- gavinray 6y ago
  > Speed? As surprising as it might sound -- not really. There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization. It's more of a familiarity/existing tooling thing. Same as Blazor in C# writing web apps in that. If your entire team only knows C# and you have all your existing tooling there then it could seem an appealing option. But there's also the argument for more stringent safety with Rust compared to IE, Typescript.
  - danShumway 6y ago
    > There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization My understanding is that this is going to get a lot better in the future though -- last I checked the plan was for WASM to eventually have direct bindings to DOM APIs, at which point you won't need to interact with JS at all.
    - gavinray 6y ago
      That's true, if the Interface Types proposal gets accepted that overhead should be significantly less. At that point it'll get really interesting what the potential performance looks like for DOM-interaction heavy apps. https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/master/p... I wouldn't think it's far behind. The Multi-Value proposal, which had huge ramifications, was recently accepted in April so WASM is clipping along at a fair pace still. https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/ https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/
      - markdog12 6y ago
        Firefox Nightly and Chrome Canary both recently landed multi-value and reference types: https://webassembly.org/roadmap/ https://webassembly.org/roadmap/
  - dom96 6y ago
    I was very surprised to find this. I have done some WASM experiments and found that JS is very often incredibly well optimised, often running faster than WASM. Do not underestimate the years of JIT optimisations that went into V8 and other JS engines.
- paulgb 6y ago
  Although Rust is most known for bringing safety to low-level development, it also happens to be a nice, modern programming language with things like match statements and sum types. I find myself using it frequently for things I used to do in Python, with greater productivity once a program reaches the point that I can't keep it all in my head.
- the_gipsy 6y ago
  A fast webapp is a selling point on it's own. Of course, maybe just because it uses WASM it doesn't automatically have to be faster - but this looks promising.
- stmw 6y ago
  I don't think Rust is just for low-level development anymore, for example at Commure we have been using it very successfully for "enterprise app". So if you're already using Rust for the app backend, I think the interest is more about using the same language in the back and in the front. Since nowadays one usually wants a typed Javascript (e.g. Typescript) anyway, it is far shorter of a leap to Rust.
- nilkn 6y ago
  It's the reverse of what happened with JavaScript. In other words, JavaScript started on the front-end and then spread to the back-end because it was advantageous to have one language for both. One of those advantages is that folks who were experts in JavaScript were suddenly able to use their language of choice for back-end work too. Rust started on the back-end but is fairly likely to spread to the front-end in the future for the same reason. One of the advantages will again be that folks who are experts in Rust will be able to use their language of choice for front-end work too. Beyond this, I would argue that Rust's type system is a significant draw for many folks as well. I dare say it has a lot more potential than Elm, a Haskell-like language designed just for web development.
- k__ 6y ago
  Predictability? As far as I know, Rust's WASM performance is much more uniform than JS'.
- pmarcelll 6y ago
  I haven't seen it mentioned, but memory usage might also be better, and I have a good real-world example to show why it still matters in 2020: we use Jira to manage our software projects and our team's project manager uses a newish MacBook Air with 8GB of RAM. Jira is written in React and a single page for a ticket can easily eat 150+ MB of memory (it's even more for Jira boards). Our PM regularly complains about the slowness of his machine and I think Jira is a big contributing factor. I don't think much of the memory is used for presentation (so it might not be React's fault), but rather for business logic processing a large amount of data. And IIRC calling a simple `filter()` on a JS array creates a new array for the operation while Rust uses iterators.
  - akiselev 6y ago
    I regularly slow to a crawl on a 32gb Mac Book Pro requiring a reboot because it starts swapping thanks to Chrome tabs, electron apps/VSCode, and webpack/cargo/whatever to the point that running cat on a file takes 5-10 seconds. All it takes is a little memory exhaustion for the kernel to pick a process for swap (iterm and its children? why, thank you kernel!) and drive it into the ground. With Chrome it might swap just a single tab process or it might swap the rendering process I don't know why it seems React apps are some of the worst offenders, but I think it has to do with hooks injecting context components everywhere (at least that's what it looked like last time I popped open React dev tools). I'm guessing that out of tree state tracking is particularly memory intensive.
- jillesvangurp 6y ago
  Type safety is the key selling point here. Rock solid behavior for asynchronous and concurrent behavior is another one. Both could be considered weaknesses for Javascript. I agree it's a bit too far out for a lot of javascript/typescript developers. But then the Rust community has a lot of former full stack refugees joining it. My observation is that "full stack development" using javascript is a phase developers go through before upgrading to some other language. You see similar patterns in the Go community. Both communities have lots of people who used to do lots of web and node.js development. My money is more on languages like Kotlin, C#, and Swift crossing over to the browser. Both already have wasm compilers that are still need a lot of work. This work only kicked off for Kotlin fairly recently. Kotlin also has a decent javascript transpiler that you can use right now. Both Swift and Kotlin are very popular for mobile UI development. C# has been used extensieley for Desktop and web server development. Obviously these languages come with lots of features that make them very suitable and popular for exactly the kind of stuff people use Javascript (and Typescript) for. I haven't done much with Swift and C# but Kotlin is great for this. Most of my experience with that language is server side but I have done a few things with kotlin-js as well as some Android stuff. As of a few months ago, the kotlin-js tooling is getting to the point where it's a very solid choice. It builds, it eliminated dead code, it runs webpack for you, etc. The upcoming version (1.4.0) is currently available as a release candidate and includes something called Dukat. Dukat generates kotlin type headers from typescript type headers for npm dependencies. So that means you can integrate a lot of existing npms if you have to. Also the build tools integrate with webpack and you can target both the node.js ecosystem and the browser ecosystem. Most of the bottlnecks for adopting either transpilers or wasm compilers in this space is the relative immaturity (or lack off) mature alternatives to popular javascript frameworks. You can do react apps in a bunch of languages now but it just feels wrong to do it. The pattern you see in other language communities is that they pretty much start rolling their own alternative frameworks. In any case, the amount of third party code making it to a browser is typically not that much for most webapps. For all it's popularity, the react run-time code is not that large. A few hundred KB is considered a lot.
praveenperera 6y ago
Great post. I'd love to see one talking about building a full stack app using Yew and Actix (or Rocket). And good ways of sharing types between the frontend and the backend.
- deleted 6y ago
  [deleted]
- rkwz 6y ago
  Thank you! The sharing common types and logic is pretty easy using cargo workspaces, will include this in future posts :)
  - praveenperera 6y ago
    Awesome! I think it would also be cool to explore alternatives to REST with JSON for a full stack Rust app.
    - gameswithgo 6y ago
      I have a hobby project where I am serializing everything to bincode with serde, and communicating with my own protocol over websockets. its quite nice! Rust's enums make this kind of serialization and communication super easy.
      - praveenperera 6y ago
        That sounds very interesting. Do you have a public repo I could check out?
- areille 6y ago
  You should have a look to this project built with actix, diesel and yew: https://github.com/saschagrunert/webapp.rs https://github.com/saschagrunert/webapp.rs
  - praveenperera 6y ago
pedrocr 6y ago
We're finally getting back to this point where you can choose whatever language you want to program for the web. It only took us 15 years of being flamed every time you pointed out you didn't like Javascript but were forced to use it to be part of the modern web. One of the motivations for Viaweb was being able to do Lisp, hopefully this gets the web back to that mindset of only the behavior mattering and whatever language you want to use go for it.
- devwastaken 6y ago
  It took 15 years for llvm and wasm to be made. Sandboxing and cross compilation in a way that isn't crazy has always been a big problem for allowing the web to just run whatever it wants. Though I'm still skeptical on wasms real security given its use in browsers is independently implimented, non seperable from the Js stack, and we're still using JIT. Everyone else goes and impliments their own runtime too.
  - ChrisSD 6y ago
    Independent implementations are important. We don't want another Flash.
    - pjmlp 6y ago
      "Everything Old is New Again: Binary Security of WebAssembly" http://www.software-lab.org/publications/usenixSec2020-WebAssembly.pdf http://www.software-lab.org/publications/usenixSec2020-WebAs...
  - amelius 6y ago
    We could as well have used VirtualBox instead to sandbox applications on the web, and run them at near-native speed. No need for LLVM and WASM. The only thing needed would be to incorporate VirtualBox into the browser.
    - derefr 6y ago
      Besides VirtualBox being an single implementation rather than a standard, that wouldn't have worked—VirtualBox is just a hypervisor, not an emulator, and so "has" whatever ISA the host has. So you'd need separate binaries for x86, ARM, etc. Google did a much better version of this, without these problems; they called it PNaCl. People still didn't like it, because LLVM IR is still not technically a formal standard, only a de-facto one.
jandrese 6y ago
I remember back when people generated html with native code using CGI.pm and it was considered a bad idea. Don't mix languages they said. The current CGI.pm deprecated all of the HTML generating parts in fact. The official justification: The rationale for this is that the HTML generation functions of CGI.pm are an obfuscation at best and a maintenance nightmare at worst. You should be using a template engine for better separation of concerns. See CGI::Alternatives for an example of using CGI.pm with the Template::Toolkit module.
boltzmann_ 6y ago
waiting for a rails like framework that would let me use only one language full-stack.
- danShumway 6y ago
  Isn't this example already using Rust full-stack, or am I missing something? You still need to write HTML, but that's also the case with Ruby on Rails.
- nilkn 6y ago
  You can definitely already do that in Rust, although I'm not sure how mature all the tooling is yet and rather than using a single framework you'd be using a few different toolsets (e.g., Actix/Rocket, Diesel, Yew).
- whb07 6y ago
  F# does this via Fable.
  - dmit 6y ago
    This is a tangent, but does Fable still require you to manually toposort your module hierarchy in an XML file? That was my experience using the language with VS Code circa a year ago.
    - whb07 6y ago
      I've actually not been an actual user besides running a random repo to see how it all fits in nicely. But... i've been playing more with F# and it really is a fun language to use and capable. I was able to compile a number of F# applications to "native" or as close as possible and they ended up getting significant performance improvements. For instance a ray tracing application when compiled to native had improvements of 50%.
  - intelleak 6y ago
    Hi, would you be able to give your experience in brief, how is fable? And elmish? How happy are you with fable?
johannes1234321 6y ago
Sorry for being the pedantic one, but the article early on states "without writing a single line of JavaScript" and then, in the first code, after showing configuration files, one can read <script type="module"> import init from "/wasm.js"; init(); </script> So two lines of JavaScript ...
- ncmncm 6y ago
  Ah, but that wasn't written, it was cut'n'pasted, which Doesn't Count. Or does it?
  - johannes1234321 6y ago
    Answer A: For a joke it doesn't matter. Answer B: By that logic it is "without writing any code" But yes, the example is nice and it's not a production line, probably not even copyrightable.
- arkanciscan 6y ago
  And some HTML as well. Yew seems to use a JSX-like template language, but it's got to hit the DOM eventually. Then you're gonna need to handle Events and style with CSS. How do you handle errors? What does all this look like in DevTools? People act like JS is the worst part of web development which is simply naive.
  - johannes1234321 6y ago
    About HTML they made no claims. For a SPA HTML also is essential (they could use GL if they don't want to use (lots of) HTML) And errors and events are handled in the Rust code.
- rwoerz 6y ago
  Yes, two of them instead of a single one. Promise kept!
crazypython 6y ago
Full-stack Dlang framework https://github.com/huntlabs/hunt-framework https://github.com/huntlabs/hunt-framework
- NationalPark 6y ago
  No wasm stuff here though.
deschutes 6y ago
What is the size of the served wasm binaries?
- M2Ys4U 6y ago
  Looking at the linked demo site[0] the wasm file is 476kb (133kb compressed with brotli). [0] https://rustmart-yew.netlify.app/ https://rustmart-yew.netlify.app/
- deleted 6y ago
  [deleted]
arkanciscan 6y ago
I eagerly await every single NPM package being rewritten in every single language just so someone can post a ShowHN about it.
- runawaybottle 6y ago
  It’s demo day everyday like kindergarten.
raggi 6y ago
136kb feels heavy for what this is
- kinghajj 6y ago
  A lot of that comes from a few large libraries needed to provide base runtime functions (like memory allocation).
nilkn 6y ago
I am hopeful that Rust can achieve what Elm did not. I really fell in love with Elm early on, back when it was an experimental language for functional reactive programming that just happened to compile to JavaScript. It was an outgrowth of failed experiments in FRP from the Haskell world. I thought it got so many things right -- and it totally did. But then, just as soon as it started gaining real traction, development on Elm went silent and became siloed, staggeringly slow, locked-down, and unresponsive to users. I understand why this happened and I don't even hold it against the Elm team, but it certainly stunted the language's growth and adoption. Rust has a much more expressive type system than Elm. The Rust world is much more open, responsive, and caring about user concerns. Rust isn't afraid to offer unsafe escape hatches even if they're not pretty or elegant. With Rust you have the added advantage of being able to use the language for the entire stack, both front- and back-end. That's especially compelling because Rust is on its way to being one of the strongest languages for back-end development due to its combination of type safety, expressiveness, and performance.
- bgorman 6y ago
  I don't understand why Rust is more compelling than ReasonML (OCaml). Reason is more expressive and on the web low level memory management isn't a concern.
  - nilkn 6y ago
    Isomorphic codebases. I would much rather use Rust on the back-end than ReasonML/OCaml.
    - smabie 6y ago
      Why's that? Ocaml has excellent performance and is a lot higher level than Rust. I personally see Rust as a language that really only should be used if utmost performance or hard latency requirements makes GC'd languages unsuitable. Most backends for web-app would run only marginally better with Rust than Ocaml and incur a steep productivity and maintenance penalty. A lot of people seem to be suggesting Rust as a GC language replacement instead of a C/C++/asm replacement, which I've never really got. Is the mutation/lifetime/pointer management really worth it for this kind of thing?
devxpy 6y ago
Can anyone please tell me how the author able to use html syntax in rust? I get that there are macros, but how are html tags valid syntax? Is rust just interpreting the html content as strings? I've only ever seen C macros, and I don't remember seeing this kind of wizardry happening there.
- Ciantic 6y ago
  It's using this: https://yew.rs/docs/concepts/html https://yew.rs/docs/concepts/html and no, just like JSX, it's not HTML strings. It's building HTML-like AST in macro. One great thing about JSX (and Yew) is that it's way more secure way to build an HTML, because you don't need to worry about escaping behaviors as much. (Sometimes you still need, like injecting inline CSS etc. but not that often)
  - devxpy 6y ago
    whoa, so you can write like a DSL parser using the rust macro matcher syntax?
    - dgb23 6y ago
      Essentially yes. Macros in Rust are very powerful, similar to Lisp macros (although they are naturally clunkier). As you would expect, you will find macros for HTML, JSON etc. in libraries, but there are also quite a bunch of smaller, frequent macros that simply reduce common boilerplate.
      - db48x 6y ago
        And then there are the Rust macros that let you write code in Lisp syntax, although I don't recall that any of them had a defmacro form…
        devxpy 6y ago
        Oh god, what have I seen
vlucas 6y ago
It's worth noting that the WASM package takes up 476kb shipped and the wasm.js loader is another ~25kb. So this bare-bones site is already sitting at > 500kb of JavaScript shipped to the client. I am glad to see things like this are possible now with WASM, but there is a lot of room for improvement here that I hope gets captured by browser vendors over time.
- dstaley 6y ago
  Just to clarify, 476kb of WebAssembly != 476kb of JavaScript. Still, your point stands in that wasm-based sites will likely never beat their pure JavaScript counterparts in terms of data transfer; you'll need to make up the increased cost of wasm somewhere else. One place that browsers attempt to make up the difference is in the use of streaming compilers, where the browser can start compiling wasm as it's coming in from the network, whereas with JavaScript browsers have to wait until the entire resource is delivered before the parsing stage can begin.
  - chrismorgan 6y ago
    To expound on this difference: 476KB of WebAssembly loads like 476KB of images (that is, super fast) rather than like 476KB of JavaScript (which is pretty slow and blocks the main thread). https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/ https://hacks.mozilla.org/2018/01/making-webassembly-even-fa... explains more.
  - tiborsaas 6y ago
    I could build his example in 2-3kb of vanilla JS unminified :)
  - vlucas 6y ago
    Thank you for the explanation - I didn't know this about WebAssembly! I followed a link from another reply here and learned something new today.
- HugoDaniel 6y ago
  luckily WebAssembly is stream compiled while data is being fetched in parallel; unlike JS it does not need to load the whole file to start working on it :)
doomedlung 6y ago
What are the debugging tools like for this?
joshsyn 6y ago
zero overhead on the web or just zero and overkill for the web? Seriously I don't get the appeal of doing frontend in Rust? Isomorphic you say, thought Json solved that problem? Hell, I'd rather choose typescript even.
bodhi_mind 6y ago
Anyone know when all browsers will support 64bit wasm and allow >4gb memory?
Naac 6y ago
So as I understand it Rust is compelling because it is a safer alternative to C++ ( and sometimes C but mainly a C++ replacement ). We wouldn't usually create a single page app in C++ right? So why would we want to do that in Rust ( other than, "just because" ). Right tool for the right job and all that.
- K0nserv 6y ago
  Rust is much more like Ruby than C++ while retaining the characteristics of C++/C. The build system and ecosystem is also excellent, something that you cannot say for C++. In terms of WASM Rust and C++/C are in the same boat i.e. the few languages you can realistically use because they don't require a heavy runtime or GC.
- nikitaga 6y ago
  Rust is also a safer alternative to Javascript (and even Typescript for that matter).
- deleted 6y ago
  [deleted]
bob1029 6y ago
From the article: > Building UIs by composing components and passing data in a unidirectional way is a paradigm shift in the frontend world. It’s a huge improvement in the way we reason about UI and it’s very hard to go back to imperative DOM manipulation once you get used to this. IMO, UI structure and state management of the UI are orthogonal concerns. Trying to make these part of the same problem - a 'Component' - is how you wind up in the Angular-style trap where you can never quite cover 100% of the use cases, so you have to keep adding new leaky abstractions to compensate for prior ones. Passing events back up the chain is a particularly egregious constraint when you are trying to do things with the UI that the modeling does not agree with on paper (i.e. modals, status bars and nav menus are children of whom? One big global component?). I have made this realization recently when working with Blazor. The statefulness of a UI is a completely different thing from the visual presentation of the UI. We do one-way binding into UI (e.g. foreach over collections to build table rows). But, stateful concerns are injected as scoped services (i.e. per user session/request). UI events are passed into the state service methods directly, and the UI is redrawn on top of the updated state. Each state service can only be mutated by way of one of its public methods. This approach allows for us to build & test our UI state machines to deterministic levels of correctness without a single line of HTML/JS/CSS or manual user testing being involved. Once we have the state machine figured out, we can build whatever arbitrary UI we want on top of it.
- grok22 6y ago
  I am interested in understanding this further -- is there a write-up or explanation with example anywhere regarding how you achieve this in Blazor.
  - bob1029 6y ago
    As far as I am aware, there is no public document on the internet which describes this approach in a consolidated way. Unfortunately, I cannot share examples from the codebase I am currently operating on. That said, I can offer some MS documentation links in hopes that this paints a slightly better picture for how I achieve this outcome. This describes how you would request a scoped stateful service from an arbitrary Razor Component: https://docs.microsoft.com/en-us/aspnet/core/blazor/fundamentals/dependency-injection?view=aspnetcore-3.1#request-a-service-in-a-component https://docs.microsoft.com/en-us/aspnet/core/blazor/fundamen... This describes how you would inject these stateful services into DI in a way that scopes them as desired: https://docs.microsoft.com/en-us/aspnet/core/blazor/fundamentals/dependency-injection?view=aspnetcore-3.1#service-lifetime https://docs.microsoft.com/en-us/aspnet/core/blazor/fundamen... Note that we are using Server-Side Blazor, so this approach works for us. I do not think it works with WASM (at least out of the box), but we do not care for this form of Blazor hosting right now, so its not a concern for us.
kibwen 6y ago
I like how this post uses diffs to demonstrate how the code changes at each step, it's much easier to follow along than with blog posts that just show the complete code at each step and leave mental diffing as an exercise for the reader.
- lioeters 6y ago
  Dug in the source, I believe they're using Prism's Diff Highlight plugin: https://prismjs.com/plugins/diff-highlight/ https://prismjs.com/plugins/diff-highlight/
  - deleted 6y ago
    [deleted]
pier25 6y ago
Can you load WASM modules dynamically like we in do in JS with import()?
- steveklabnik 6y ago
  In some sense, that's the only thing you can do in the browser, as you have to execute JS to instantiate the wasm. The code in this post actually uses import to dynamically import said JS that imports the wasm.
  - pier25 6y ago
    Right, I guess the tooling would need to support code splitting into separated wasm modules like we do with Webpack or Rollup.
intelleak 6y ago
I've been hearing good things about zig, and someone mentioned that zig has better wasm support than rust, is it true? I wish rust had a js ecosystem too ...
svnpenn 6y ago
> without writing a single line of JavaScript Looks like 680 lines to me: https://rustmart-yew.netlify.app/wasm.js https://rustmart-yew.netlify.app/wasm.js
- steveklabnik 6y ago
  You do not write that JavaScript, it is generated for you by the tooling.
  - svnpenn 6y ago
    If the end solution relies on hundreds of lines of JavaScript... its JavaScript. I will just write the whole thing in JavaScript instead of messing with something like this.
    - steveklabnik 6y ago
      Sure, and you are very welcome to do so. That's not what the original post said, nor what you said in response, though.
- CryZe 6y ago
  That's auto generated and will shrink more and more in the future as WASM gets more abilities to directly call into DOM APIs and store JS objects.
  - austincheney 6y ago
    There is no indication that will ever happen.
batt4good 6y ago
Frameworks like this and other similar non-standard approaches like Elixir Phoenix and LiveView are awesome, however, I'm still lost as to how one should go about styling and / or dynamically structuring styling? Does anyone have recommendations for guides or simple approaches that only focus on the pure UI side of the problem. I've never really "had" to learn JS and honestly every time I have to dip my toes in it leaves a very bad taste in my mouth.
hpen 6y ago
Why create web apps in Rust? Won't that slow down development?
- pettusftw 6y ago
  Depends who the developers are. My company has been acquired several times over the past decade and it has been for our backend. The frontend has been largely left to rot and is a seldom used nightmare at this point. Our backend devs that use Rust may be asked to build a simple SPA for a client relatively soon, so you can understand why they _may_ be happy to give this a try for the POC. My initial impression is that it would require a lot less KT/overhead to at least give them this option before shuffling another team in that really doesn't have the roadmap bandwidth to begin with.
  - hpen 6y ago
    Fair point. I just don't know that right now at the beginning will be a good time. A solid ecosystem can make all the difference.
tus88 6y ago
Whats the point. Javascrupt cannot have memory errors and has no threading, so why bother with a memory safe language like Rust?
- M2Ys4U 6y ago
  Well for one Rust has a very nice type system
kuon 6y ago
I was thinking of a project I wanted to start, but I don't know if it would interest anyone. Basically, I'd like to try to build all sort of app with program components similar to the Elm architecture (init, update, step, subscribe). Those programs would be a bit similar to objects in OO except with stricter rules. I did a proof of concept and it works very well for simple tasks (like subscribing to HttpServer.sub and getting messages for requests to your update function). The good side is that you can have very simple API (I'd really like it to be usable by anyone), it's very easy to go massive multi-threading, refactoring is easy, you never introduce hard dependency in your code and having a very strict model helps organizing code. I wanted to support wasm with a subset of the API (that's why I think of it now). But I stopped, because I realized it would certainly be of little interest except for show.
fmakunbound 6y ago
I'll do just about anything to avoid JavaScript, including learning Rust.
- alpineidyll3 6y ago
  You read my mind.
- thealienthing 6y ago
  I can only imagine how many JS diehard fans are screaming in rage when they read this. I’m with you.
  - ahmedalsudani 6y ago
    All three of them :) Mostly there are diehard haters for JS, not diehard fans. A lot of people who use JS are pragmatists and fantastic problem solvers that I have a ton of respect for. -Someone who's not too fond of JS
    - shepherdjerred 6y ago
      I used to be a die-hard hater but converted to a die-hard fa n when I started actually learning the language. Once you know the quirks it's quite nice. Of course since it's dynamically typed it's hard to use for larger programs, but TypeScript solves that.
  - gwbas1c 6y ago
    I took the time to learn some modern JavaScript and I love it... But give me a statically typed compiled language any day! The browser is so important that we shouldn't be locked into using a single language, so I fully support being able to choose between Rust or a JavaScript!
- nobleach 6y ago
  While I do get annoyed at JS often, I get just as annoyed by Rust. Sometimes, I really just want to read a CSV and create a Map<String, String> from a few of the columns. But oh my god if Rust doesn't make that a nightmare. Is it a String? an &str? Do I want to allocate that string on the stack? I won't know the size of it at compile time, so of course not... right? So no to 'static? Give me a nice middle of the road like TypeScript, Kotlin, OCaml/Reason... Rust just goes SO FAR in the other direction that I don't find it a pleasant experience. I get that it's the ULTIMATE in performance, I just always question if I really need it for doing web work.
AlchemistCamp 6y ago
I've been going through Programming WebAssembly with Rust, from Pragmatic Bookshelf and have been getting interested in the possibilities. Yew is just one part of the book, but it's a good crash course and motivation for digging in. https://pragprog.com/titles/khrust/ https://pragprog.com/titles/khrust/
ori_b 6y ago
This is a big reason that I think wasm is a step in the wrong direction. It's basically nudging people into making things even more opaque. How, for example, would you go about blocking ads in this kind of app?
- jakogut 6y ago
  > This is a big reason that I think wasm is a step in the wrong direction. It's basically nudging people into making things even more opaque. WebAssembly is a tool, not a technique. It's not meant to replace JavaScript or the DOM, it's meant to supplement it in projects where it makes sense. Is it any more opaque than any other transpiled and minified SPA that in no way resembles anything remotely human readable anymore? I don't consider this a valid criticism of WASM. > How, for example, would you go about blocking ads in this kind of app? Probably the same way it's done now, by blocking requests to blacklisted domains known for hosting advertisements.
- jelder 6y ago
  If it’s actually harder to block ads in apps built like this, that’s a great reason for site owners to choose wasm.
  - ori_b 6y ago
    And a great reason for users to resist it.
  - AnyTimeTraveler 6y ago
    You can still use normal adblockers with this. Most of them just have a blacklist of domains that they block the requests for. Wasm won't change anything about that. The requests are still exactly the same as in JS, so blocking will work exactly the same.
- AgentME 6y ago
  Sites using WebAssembly still need to use the DOM just like JS sites, and be equally ad-blockable. Technically a site could render everything as an opaque image in a canvas element, which would be hard to do ad-blocking on, but there's nothing about WebAssembly inherently connected to canvas elements. Whether a site uses WebAssembly and whether it puts all its contents in a canvas element are orthogonal issues. JS sites are equally capable of putting all their content in canvas elements, and very few of them do.
merrvk 6y ago
Cannot wait for the days where i no longer have to write JS
millstone 6y ago
The wasm on this page is 476 KB.
kissgyorgy 6y ago
You build your website in Rust, I build 3 websites in that same time with Python/JavaScript.
- ioseph 6y ago
  In which time I build 30 websites using wordpress. Heaven forbid the author does something for any reason other than productivity gains
truly_furqan 6y ago
That's interesting. But, IMO it has a lot of room for improvement to compete with frameworks like React, Vue, and Svelte. Isn't it?
1vuio0pswjnm7 6y ago
I was hoping "single page" meant all the code fit on one page.
joshsyn 6y ago
Its funny anything questioning use of Rust is being downvoted. Rust evangelism strike force is in play. Again I don't get the appeal of Rust for Dom manipulation unless its computationally heavily.
gwbas1c 6y ago
I'm still baffled by the need for a boilerplate Javascript file to call into rust. Why can't I just include the wasm directly from HTML? Seems like someone's feelings will be hurt when they realize that many developers want to skip JavaScript and just work with wasm.
- fb03 6y ago
  committee is working on a DOM-access-directly-from-WASM spec. but for now we still need to use things like wasm-bindgen to generate the boilerplate needed for us. It's still fast, tho. Have you tried https://sandspiel.club/ https://sandspiel.club/ ?
- steveklabnik 6y ago
  The browser API requires it.
  - gwbas1c 6y ago
    It's just two lines of JavaScript to call into wasm: 1 line to load the wasm, another to call a function in it. This adds latency, and is easily replaced by a single tag.
BooneJS 6y ago
Is blocking WASM a thing yet? I guess I wouldn’t know if I’ve launched a WASM page, but I was curious if WASM was popular enough for IT security folks to block on enterprise computers.
- bob1029 6y ago
  Not to my knowledge. I don't see any reason for it to be blocked, even in theory. It's not like you get access to a more permissive API surface or anything. If someone is going to feed you malicious code to execute, all WASM will do is make it harder to inspect.
nojvek 6y ago
Until we fix the wasm->dom bridge to be just as fast as the js->dom bridge, js will still have a leg up. AFAIK the hard bits are in bindgen which makes js structs look like wasm ones and vice versa. I’ve been doing frontend for over a decade and quite bullish on wasm once that boundary isn’t so expensive. It should be possible to make super performant apps with wasm. Figma sticks out to me as someone really pushing the edge.
apiudit 6y ago
Hate to be that guy but with a such small SPA I was expecting a better file size, 136KB compressed with brotli 487KB uncompressed. Being said that score in Page Speed Insights is pretty good (95). Will be interesting how size increases with bigger/complex apps.
- deleted 6y ago
  [deleted]
- ChrisSD 6y ago
  I wouldn't assume the growth in binary size is anything like linear with code size (i.e. there's probably a lot of fixed overhead). And they appear to be using the "--dev" compiler profile, which is unoptimized and meant for debugging.
austincheney 6y ago
I have never understood why people find UI challenging, aside from accessibility and security. State management is ridiculously easy. So easy that you are going to 10x greater effort reading your favorite framework’s API. To manage state store your state criteria in a central object. Save that to storage somewhere, such as localStorage. To restore state read the stored state object and apply each item to its respective area of the application. Modules and components are ridiculously easy now too thanks to ECMAScript modules.
tristanMatthias 6y ago
Am I the only one that finds this REALLY verbose for doing some really simple stuff? Forewarning, I'm a JS dev trying to get out of the "JS" box. I'm super interested in WASM for a lot of reasons (running ML models on the client in python, etc). This syntax (and maybe it's just Yew) feels like it has SO much boilerplate. For you seasoned rustacians out there, is this something that could be reduced? It feels overkill for me. But then again, maybe I'm a spoiled JS dev with the wrong expectations. Really curious to answers on this.
- steveklabnik 6y ago
  It's hard to say without knowing what specifically you find to be verbose. "verbose" is a very subjective measure.
rriepe 6y ago
Thanks for this. I was wanting to look into this, and this page is way more than enough to get me started.

886 points by rkwz 6y ago

The promise of Rust is safe and fast low-level development. What is the primary selling point of using rust for webdev? Speed? I can mainly see disadvantages when using rust for this scenario.

kolektiv 6y ago
Well, that's definitely a sweet-spot, but as a by-product of that, Rust is still a well-thought through language with a strong and logical type system, some very useful features for expressing domain models, etc. and a model of memory management which maps very well to WASM. So if you already know Rust, this is a short and logical step. If you don't already know Rust, I wouldn't learn it just to write web apps in - but if you do, you now have all the advantages of "same language client/server side" as well as the advantages of safety, good libraries in certain spaces, etc.
- Vinnl 6y ago
  > I wouldn't learn it just to write web apps in I'm going to be looking into the other way around: writing a web app in it to learn it. Seems like a great use case that would make it easier for me to learn, as someone who has experience with web apps and not so much with desktop software.
skocznymroczny 6y ago
Possibility of sharing code between backend and frontend.
- hinkley 6y ago
  Yes. Isomorphic code was always about having to prove the correctness of a smaller body of code. Web assembly will see a whole new round of people trying to do monoglot programming. Which I welcome, because I like JavaScript well enough but I don’t like writing it all day, every day, for years at a time.
danShumway 6y ago
A few advantages: - Rust compiles to WASM, not JS, so you can actually take advantage of its low-level nature in the browser for performance critical tasks within your app. - The Rust code you're writing is still statically compiled, so you still get to take advantage of Rust's typechecking and IDE features. - Some people just like writing Rust code more than Javascript. Part of the reason Javascript took off so quickly on the server was because there's a huge productivity boost from using one language everywhere. Similarly, if you love Rust but think that Javascript paradigms around prototypes, closures, or `this` are weird, you get to ignore that and take advantage of one of the best app distribution platforms in the world without learning a new language. I pretty solidly hold to the position that increasing language diversity on the web is a good thing. Particularly with Rust, since they've put in the work to have proper, accessible support that's still separating app logic from DOM layout and CSS styling. I'm really happy with how their community has approached building out Rust as a first-class language on the web rather than just as native language that happens to have a web compile target.
- muglug 6y ago
  > you can actually take advantage of its low-level nature in the browser for performance critical tasks within your app. Yeah, but the problem is that 99.9% of front-end work is only performance-critical for DOM rendering (the 0.1% is stuff like video encoding & decoding) and WASM can't help with that.
  - cogman10 6y ago
    > the 0.1% is stuff like video encoding & decoding In which case, rust still isn't a good fit for a front end library (Unless you are patching in support for a new codec into old browser). Frankly, the browser will have a faster version of the codec that can also take advantage of other hardware that you wouldn't want to expose to WASM.
  - brundolf 6y ago
    > 99.9% of front-end work is only performance-critical for DOM rendering There are two meanings of "DOM rendering" in the context of UI-as-a-function-of-state libraries: 1) generating the virtual DOM from data, and 2) modifying the real DOM to match it. Arguably there's even a 3) browser reflow as a result of those DOM changes. You're right that 2 and 3 can't really be helped by WASM. But 1 can, and while it's not usually the bottleneck, it certainly can be. At my last company it was not terribly uncommon that fixing UI jank came down to eliminating unnecessary React render function calls because the sum total of them all - running the actual JavaScript logic - was taking too long. Assuming yew computes the virtual DOM in WASM (I don't see how it could be otherwise), the performance increase could definitely be beneficial for certain highly-complex apps.
gavinray 6y ago
> Speed? As surprising as it might sound -- not really. There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization. It's more of a familiarity/existing tooling thing. Same as Blazor in C# writing web apps in that. If your entire team only knows C# and you have all your existing tooling there then it could seem an appealing option. But there's also the argument for more stringent safety with Rust compared to IE, Typescript.
- danShumway 6y ago
  > There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization My understanding is that this is going to get a lot better in the future though -- last I checked the plan was for WASM to eventually have direct bindings to DOM APIs, at which point you won't need to interact with JS at all.
  - gavinray 6y ago
    That's true, if the Interface Types proposal gets accepted that overhead should be significantly less. At that point it'll get really interesting what the potential performance looks like for DOM-interaction heavy apps. https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/master/p... I wouldn't think it's far behind. The Multi-Value proposal, which had huge ramifications, was recently accepted in April so WASM is clipping along at a fair pace still. https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/ https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/
    - markdog12 6y ago
      Firefox Nightly and Chrome Canary both recently landed multi-value and reference types: https://webassembly.org/roadmap/ https://webassembly.org/roadmap/
- dom96 6y ago
  I was very surprised to find this. I have done some WASM experiments and found that JS is very often incredibly well optimised, often running faster than WASM. Do not underestimate the years of JIT optimisations that went into V8 and other JS engines.
paulgb 6y ago
Although Rust is most known for bringing safety to low-level development, it also happens to be a nice, modern programming language with things like match statements and sum types. I find myself using it frequently for things I used to do in Python, with greater productivity once a program reaches the point that I can't keep it all in my head.
the_gipsy 6y ago
A fast webapp is a selling point on it's own. Of course, maybe just because it uses WASM it doesn't automatically have to be faster - but this looks promising.
stmw 6y ago
I don't think Rust is just for low-level development anymore, for example at Commure we have been using it very successfully for "enterprise app". So if you're already using Rust for the app backend, I think the interest is more about using the same language in the back and in the front. Since nowadays one usually wants a typed Javascript (e.g. Typescript) anyway, it is far shorter of a leap to Rust.
nilkn 6y ago
It's the reverse of what happened with JavaScript. In other words, JavaScript started on the front-end and then spread to the back-end because it was advantageous to have one language for both. One of those advantages is that folks who were experts in JavaScript were suddenly able to use their language of choice for back-end work too. Rust started on the back-end but is fairly likely to spread to the front-end in the future for the same reason. One of the advantages will again be that folks who are experts in Rust will be able to use their language of choice for front-end work too. Beyond this, I would argue that Rust's type system is a significant draw for many folks as well. I dare say it has a lot more potential than Elm, a Haskell-like language designed just for web development.
k__ 6y ago
Predictability? As far as I know, Rust's WASM performance is much more uniform than JS'.
pmarcelll 6y ago
I haven't seen it mentioned, but memory usage might also be better, and I have a good real-world example to show why it still matters in 2020: we use Jira to manage our software projects and our team's project manager uses a newish MacBook Air with 8GB of RAM. Jira is written in React and a single page for a ticket can easily eat 150+ MB of memory (it's even more for Jira boards). Our PM regularly complains about the slowness of his machine and I think Jira is a big contributing factor. I don't think much of the memory is used for presentation (so it might not be React's fault), but rather for business logic processing a large amount of data. And IIRC calling a simple `filter()` on a JS array creates a new array for the operation while Rust uses iterators.
- akiselev 6y ago
  I regularly slow to a crawl on a 32gb Mac Book Pro requiring a reboot because it starts swapping thanks to Chrome tabs, electron apps/VSCode, and webpack/cargo/whatever to the point that running cat on a file takes 5-10 seconds. All it takes is a little memory exhaustion for the kernel to pick a process for swap (iterm and its children? why, thank you kernel!) and drive it into the ground. With Chrome it might swap just a single tab process or it might swap the rendering process I don't know why it seems React apps are some of the worst offenders, but I think it has to do with hooks injecting context components everywhere (at least that's what it looked like last time I popped open React dev tools). I'm guessing that out of tree state tracking is particularly memory intensive.
jillesvangurp 6y ago
Type safety is the key selling point here. Rock solid behavior for asynchronous and concurrent behavior is another one. Both could be considered weaknesses for Javascript. I agree it's a bit too far out for a lot of javascript/typescript developers. But then the Rust community has a lot of former full stack refugees joining it. My observation is that "full stack development" using javascript is a phase developers go through before upgrading to some other language. You see similar patterns in the Go community. Both communities have lots of people who used to do lots of web and node.js development. My money is more on languages like Kotlin, C#, and Swift crossing over to the browser. Both already have wasm compilers that are still need a lot of work. This work only kicked off for Kotlin fairly recently. Kotlin also has a decent javascript transpiler that you can use right now. Both Swift and Kotlin are very popular for mobile UI development. C# has been used extensieley for Desktop and web server development. Obviously these languages come with lots of features that make them very suitable and popular for exactly the kind of stuff people use Javascript (and Typescript) for. I haven't done much with Swift and C# but Kotlin is great for this. Most of my experience with that language is server side but I have done a few things with kotlin-js as well as some Android stuff. As of a few months ago, the kotlin-js tooling is getting to the point where it's a very solid choice. It builds, it eliminated dead code, it runs webpack for you, etc. The upcoming version (1.4.0) is currently available as a release candidate and includes something called Dukat. Dukat generates kotlin type headers from typescript type headers for npm dependencies. So that means you can integrate a lot of existing npms if you have to. Also the build tools integrate with webpack and you can target both the node.js ecosystem and the browser ecosystem. Most of the bottlnecks for adopting either transpilers or wasm compilers in this space is the relative immaturity (or lack off) mature alternatives to popular javascript frameworks. You can do react apps in a bunch of languages now but it just feels wrong to do it. The pattern you see in other language communities is that they pretty much start rolling their own alternative frameworks. In any case, the amount of third party code making it to a browser is typically not that much for most webapps. For all it's popularity, the react run-time code is not that large. A few hundred KB is considered a lot.

praveenperera 6y ago

Great post. I'd love to see one talking about building a full stack app using Yew and Actix (or Rocket). And good ways of sharing types between the frontend and the backend.

deleted 6y ago
[deleted]
rkwz 6y ago
Thank you! The sharing common types and logic is pretty easy using cargo workspaces, will include this in future posts :)
- praveenperera 6y ago
  Awesome! I think it would also be cool to explore alternatives to REST with JSON for a full stack Rust app.
  - gameswithgo 6y ago
    I have a hobby project where I am serializing everything to bincode with serde, and communicating with my own protocol over websockets. its quite nice! Rust's enums make this kind of serialization and communication super easy.
    - praveenperera 6y ago
      That sounds very interesting. Do you have a public repo I could check out?
areille 6y ago
You should have a look to this project built with actix, diesel and yew: https://github.com/saschagrunert/webapp.rs https://github.com/saschagrunert/webapp.rs
- praveenperera 6y ago

pedrocr 6y ago

We're finally getting back to this point where you can choose whatever language you want to program for the web. It only took us 15 years of being flamed every time you pointed out you didn't like Javascript but were forced to use it to be part of the modern web. One of the motivations for Viaweb was being able to do Lisp, hopefully this gets the web back to that mindset of only the behavior mattering and whatever language you want to use go for it.

devwastaken 6y ago
It took 15 years for llvm and wasm to be made. Sandboxing and cross compilation in a way that isn't crazy has always been a big problem for allowing the web to just run whatever it wants. Though I'm still skeptical on wasms real security given its use in browsers is independently implimented, non seperable from the Js stack, and we're still using JIT. Everyone else goes and impliments their own runtime too.
- ChrisSD 6y ago
  Independent implementations are important. We don't want another Flash.
  - pjmlp 6y ago
    "Everything Old is New Again: Binary Security of WebAssembly" http://www.software-lab.org/publications/usenixSec2020-WebAssembly.pdf http://www.software-lab.org/publications/usenixSec2020-WebAs...
- amelius 6y ago
  We could as well have used VirtualBox instead to sandbox applications on the web, and run them at near-native speed. No need for LLVM and WASM. The only thing needed would be to incorporate VirtualBox into the browser.
  - derefr 6y ago
    Besides VirtualBox being an single implementation rather than a standard, that wouldn't have worked—VirtualBox is just a hypervisor, not an emulator, and so "has" whatever ISA the host has. So you'd need separate binaries for x86, ARM, etc. Google did a much better version of this, without these problems; they called it PNaCl. People still didn't like it, because LLVM IR is still not technically a formal standard, only a de-facto one.

jandrese 6y ago

I remember back when people generated html with native code using CGI.pm and it was considered a bad idea. Don't mix languages they said. The current CGI.pm deprecated all of the HTML generating parts in fact. The official justification: The rationale for this is that the HTML generation functions of CGI.pm are an obfuscation at best and a maintenance nightmare at worst. You should be using a template engine for better separation of concerns. See CGI::Alternatives for an example of using CGI.pm with the Template::Toolkit module.

boltzmann_ 6y ago

waiting for a rails like framework that would let me use only one language full-stack.

danShumway 6y ago
Isn't this example already using Rust full-stack, or am I missing something? You still need to write HTML, but that's also the case with Ruby on Rails.
nilkn 6y ago
You can definitely already do that in Rust, although I'm not sure how mature all the tooling is yet and rather than using a single framework you'd be using a few different toolsets (e.g., Actix/Rocket, Diesel, Yew).
whb07 6y ago
F# does this via Fable.
- dmit 6y ago
  This is a tangent, but does Fable still require you to manually toposort your module hierarchy in an XML file? That was my experience using the language with VS Code circa a year ago.
  - whb07 6y ago
    I've actually not been an actual user besides running a random repo to see how it all fits in nicely. But... i've been playing more with F# and it really is a fun language to use and capable. I was able to compile a number of F# applications to "native" or as close as possible and they ended up getting significant performance improvements. For instance a ray tracing application when compiled to native had improvements of 50%.
- intelleak 6y ago
  Hi, would you be able to give your experience in brief, how is fable? And elmish? How happy are you with fable?

johannes1234321 6y ago

Sorry for being the pedantic one, but the article early on states "without writing a single line of JavaScript" and then, in the first code, after showing configuration files, one can read <script type="module"> import init from "/wasm.js"; init(); </script> So two lines of JavaScript ...

ncmncm 6y ago
Ah, but that wasn't written, it was cut'n'pasted, which Doesn't Count. Or does it?
- johannes1234321 6y ago
  Answer A: For a joke it doesn't matter. Answer B: By that logic it is "without writing any code" But yes, the example is nice and it's not a production line, probably not even copyrightable.
arkanciscan 6y ago
And some HTML as well. Yew seems to use a JSX-like template language, but it's got to hit the DOM eventually. Then you're gonna need to handle Events and style with CSS. How do you handle errors? What does all this look like in DevTools? People act like JS is the worst part of web development which is simply naive.
- johannes1234321 6y ago
  About HTML they made no claims. For a SPA HTML also is essential (they could use GL if they don't want to use (lots of) HTML) And errors and events are handled in the Rust code.
rwoerz 6y ago
Yes, two of them instead of a single one. Promise kept!

crazypython 6y ago

Full-stack Dlang framework https://github.com/huntlabs/hunt-framework https://github.com/huntlabs/hunt-framework

NationalPark 6y ago
No wasm stuff here though.

deschutes 6y ago

What is the size of the served wasm binaries?

M2Ys4U 6y ago
Looking at the linked demo site[0] the wasm file is 476kb (133kb compressed with brotli). [0] https://rustmart-yew.netlify.app/ https://rustmart-yew.netlify.app/
deleted 6y ago
[deleted]

arkanciscan 6y ago

I eagerly await every single NPM package being rewritten in every single language just so someone can post a ShowHN about it.

runawaybottle 6y ago
It’s demo day everyday like kindergarten.

raggi 6y ago

136kb feels heavy for what this is

kinghajj 6y ago
A lot of that comes from a few large libraries needed to provide base runtime functions (like memory allocation).

nilkn 6y ago

I am hopeful that Rust can achieve what Elm did not. I really fell in love with Elm early on, back when it was an experimental language for functional reactive programming that just happened to compile to JavaScript. It was an outgrowth of failed experiments in FRP from the Haskell world. I thought it got so many things right -- and it totally did. But then, just as soon as it started gaining real traction, development on Elm went silent and became siloed, staggeringly slow, locked-down, and unresponsive to users. I understand why this happened and I don't even hold it against the Elm team, but it certainly stunted the language's growth and adoption. Rust has a much more expressive type system than Elm. The Rust world is much more open, responsive, and caring about user concerns. Rust isn't afraid to offer unsafe escape hatches even if they're not pretty or elegant. With Rust you have the added advantage of being able to use the language for the entire stack, both front- and back-end. That's especially compelling because Rust is on its way to being one of the strongest languages for back-end development due to its combination of type safety, expressiveness, and performance.

bgorman 6y ago
I don't understand why Rust is more compelling than ReasonML (OCaml). Reason is more expressive and on the web low level memory management isn't a concern.
- nilkn 6y ago
  Isomorphic codebases. I would much rather use Rust on the back-end than ReasonML/OCaml.
  - smabie 6y ago
    Why's that? Ocaml has excellent performance and is a lot higher level than Rust. I personally see Rust as a language that really only should be used if utmost performance or hard latency requirements makes GC'd languages unsuitable. Most backends for web-app would run only marginally better with Rust than Ocaml and incur a steep productivity and maintenance penalty. A lot of people seem to be suggesting Rust as a GC language replacement instead of a C/C++/asm replacement, which I've never really got. Is the mutation/lifetime/pointer management really worth it for this kind of thing?

devxpy 6y ago

Can anyone please tell me how the author able to use html syntax in rust? I get that there are macros, but how are html tags valid syntax? Is rust just interpreting the html content as strings? I've only ever seen C macros, and I don't remember seeing this kind of wizardry happening there.

Ciantic 6y ago
It's using this: https://yew.rs/docs/concepts/html https://yew.rs/docs/concepts/html and no, just like JSX, it's not HTML strings. It's building HTML-like AST in macro. One great thing about JSX (and Yew) is that it's way more secure way to build an HTML, because you don't need to worry about escaping behaviors as much. (Sometimes you still need, like injecting inline CSS etc. but not that often)
- devxpy 6y ago
  whoa, so you can write like a DSL parser using the rust macro matcher syntax?
  - dgb23 6y ago
    Essentially yes. Macros in Rust are very powerful, similar to Lisp macros (although they are naturally clunkier). As you would expect, you will find macros for HTML, JSON etc. in libraries, but there are also quite a bunch of smaller, frequent macros that simply reduce common boilerplate.
    - db48x 6y ago
      And then there are the Rust macros that let you write code in Lisp syntax, although I don't recall that any of them had a defmacro form…
      - devxpy 6y ago
        Oh god, what have I seen

vlucas 6y ago

It's worth noting that the WASM package takes up 476kb shipped and the wasm.js loader is another ~25kb. So this bare-bones site is already sitting at > 500kb of JavaScript shipped to the client. I am glad to see things like this are possible now with WASM, but there is a lot of room for improvement here that I hope gets captured by browser vendors over time.

dstaley 6y ago
Just to clarify, 476kb of WebAssembly != 476kb of JavaScript. Still, your point stands in that wasm-based sites will likely never beat their pure JavaScript counterparts in terms of data transfer; you'll need to make up the increased cost of wasm somewhere else. One place that browsers attempt to make up the difference is in the use of streaming compilers, where the browser can start compiling wasm as it's coming in from the network, whereas with JavaScript browsers have to wait until the entire resource is delivered before the parsing stage can begin.
- chrismorgan 6y ago
  To expound on this difference: 476KB of WebAssembly loads like 476KB of images (that is, super fast) rather than like 476KB of JavaScript (which is pretty slow and blocks the main thread). https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/ https://hacks.mozilla.org/2018/01/making-webassembly-even-fa... explains more.
- tiborsaas 6y ago
  I could build his example in 2-3kb of vanilla JS unminified :)
- vlucas 6y ago
  Thank you for the explanation - I didn't know this about WebAssembly! I followed a link from another reply here and learned something new today.
HugoDaniel 6y ago
luckily WebAssembly is stream compiled while data is being fetched in parallel; unlike JS it does not need to load the whole file to start working on it :)

doomedlung 6y ago

What are the debugging tools like for this?

joshsyn 6y ago

zero overhead on the web or just zero and overkill for the web? Seriously I don't get the appeal of doing frontend in Rust? Isomorphic you say, thought Json solved that problem? Hell, I'd rather choose typescript even.

bodhi_mind 6y ago

Anyone know when all browsers will support 64bit wasm and allow >4gb memory?

Naac 6y ago

So as I understand it Rust is compelling because it is a safer alternative to C++ ( and sometimes C but mainly a C++ replacement ). We wouldn't usually create a single page app in C++ right? So why would we want to do that in Rust ( other than, "just because" ). Right tool for the right job and all that.

K0nserv 6y ago
Rust is much more like Ruby than C++ while retaining the characteristics of C++/C. The build system and ecosystem is also excellent, something that you cannot say for C++. In terms of WASM Rust and C++/C are in the same boat i.e. the few languages you can realistically use because they don't require a heavy runtime or GC.
nikitaga 6y ago
Rust is also a safer alternative to Javascript (and even Typescript for that matter).
deleted 6y ago
[deleted]

bob1029 6y ago

From the article: > Building UIs by composing components and passing data in a unidirectional way is a paradigm shift in the frontend world. It’s a huge improvement in the way we reason about UI and it’s very hard to go back to imperative DOM manipulation once you get used to this. IMO, UI structure and state management of the UI are orthogonal concerns. Trying to make these part of the same problem - a 'Component' - is how you wind up in the Angular-style trap where you can never quite cover 100% of the use cases, so you have to keep adding new leaky abstractions to compensate for prior ones. Passing events back up the chain is a particularly egregious constraint when you are trying to do things with the UI that the modeling does not agree with on paper (i.e. modals, status bars and nav menus are children of whom? One big global component?). I have made this realization recently when working with Blazor. The statefulness of a UI is a completely different thing from the visual presentation of the UI. We do one-way binding into UI (e.g. foreach over collections to build table rows). But, stateful concerns are injected as scoped services (i.e. per user session/request). UI events are passed into the state service methods directly, and the UI is redrawn on top of the updated state. Each state service can only be mutated by way of one of its public methods. This approach allows for us to build & test our UI state machines to deterministic levels of correctness without a single line of HTML/JS/CSS or manual user testing being involved. Once we have the state machine figured out, we can build whatever arbitrary UI we want on top of it.

grok22 6y ago
I am interested in understanding this further -- is there a write-up or explanation with example anywhere regarding how you achieve this in Blazor.
- bob1029 6y ago
  As far as I am aware, there is no public document on the internet which describes this approach in a consolidated way. Unfortunately, I cannot share examples from the codebase I am currently operating on. That said, I can offer some MS documentation links in hopes that this paints a slightly better picture for how I achieve this outcome. This describes how you would request a scoped stateful service from an arbitrary Razor Component: https://docs.microsoft.com/en-us/aspnet/core/blazor/fundamentals/dependency-injection?view=aspnetcore-3.1#request-a-service-in-a-component https://docs.microsoft.com/en-us/aspnet/core/blazor/fundamen... This describes how you would inject these stateful services into DI in a way that scopes them as desired: https://docs.microsoft.com/en-us/aspnet/core/blazor/fundamentals/dependency-injection?view=aspnetcore-3.1#service-lifetime https://docs.microsoft.com/en-us/aspnet/core/blazor/fundamen... Note that we are using Server-Side Blazor, so this approach works for us. I do not think it works with WASM (at least out of the box), but we do not care for this form of Blazor hosting right now, so its not a concern for us.

kibwen 6y ago

I like how this post uses diffs to demonstrate how the code changes at each step, it's much easier to follow along than with blog posts that just show the complete code at each step and leave mental diffing as an exercise for the reader.

lioeters 6y ago
Dug in the source, I believe they're using Prism's Diff Highlight plugin: https://prismjs.com/plugins/diff-highlight/ https://prismjs.com/plugins/diff-highlight/
- deleted 6y ago
  [deleted]

pier25 6y ago

Can you load WASM modules dynamically like we in do in JS with import()?

steveklabnik 6y ago
In some sense, that's the only thing you can do in the browser, as you have to execute JS to instantiate the wasm. The code in this post actually uses import to dynamically import said JS that imports the wasm.
- pier25 6y ago
  Right, I guess the tooling would need to support code splitting into separated wasm modules like we do with Webpack or Rollup.

intelleak 6y ago

I've been hearing good things about zig, and someone mentioned that zig has better wasm support than rust, is it true? I wish rust had a js ecosystem too ...

svnpenn 6y ago

> without writing a single line of JavaScript Looks like 680 lines to me: https://rustmart-yew.netlify.app/wasm.js https://rustmart-yew.netlify.app/wasm.js

steveklabnik 6y ago
You do not write that JavaScript, it is generated for you by the tooling.
- svnpenn 6y ago
  If the end solution relies on hundreds of lines of JavaScript... its JavaScript. I will just write the whole thing in JavaScript instead of messing with something like this.
  - steveklabnik 6y ago
    Sure, and you are very welcome to do so. That's not what the original post said, nor what you said in response, though.
CryZe 6y ago
That's auto generated and will shrink more and more in the future as WASM gets more abilities to directly call into DOM APIs and store JS objects.
- austincheney 6y ago
  There is no indication that will ever happen.

batt4good 6y ago

Frameworks like this and other similar non-standard approaches like Elixir Phoenix and LiveView are awesome, however, I'm still lost as to how one should go about styling and / or dynamically structuring styling? Does anyone have recommendations for guides or simple approaches that only focus on the pure UI side of the problem. I've never really "had" to learn JS and honestly every time I have to dip my toes in it leaves a very bad taste in my mouth.

hpen 6y ago

Why create web apps in Rust? Won't that slow down development?

pettusftw 6y ago
Depends who the developers are. My company has been acquired several times over the past decade and it has been for our backend. The frontend has been largely left to rot and is a seldom used nightmare at this point. Our backend devs that use Rust may be asked to build a simple SPA for a client relatively soon, so you can understand why they _may_ be happy to give this a try for the POC. My initial impression is that it would require a lot less KT/overhead to at least give them this option before shuffling another team in that really doesn't have the roadmap bandwidth to begin with.
- hpen 6y ago
  Fair point. I just don't know that right now at the beginning will be a good time. A solid ecosystem can make all the difference.

tus88 6y ago

Whats the point. Javascrupt cannot have memory errors and has no threading, so why bother with a memory safe language like Rust?

M2Ys4U 6y ago
Well for one Rust has a very nice type system

kuon 6y ago

I was thinking of a project I wanted to start, but I don't know if it would interest anyone. Basically, I'd like to try to build all sort of app with program components similar to the Elm architecture (init, update, step, subscribe). Those programs would be a bit similar to objects in OO except with stricter rules. I did a proof of concept and it works very well for simple tasks (like subscribing to HttpServer.sub and getting messages for requests to your update function). The good side is that you can have very simple API (I'd really like it to be usable by anyone), it's very easy to go massive multi-threading, refactoring is easy, you never introduce hard dependency in your code and having a very strict model helps organizing code. I wanted to support wasm with a subset of the API (that's why I think of it now). But I stopped, because I realized it would certainly be of little interest except for show.

fmakunbound 6y ago

I'll do just about anything to avoid JavaScript, including learning Rust.

alpineidyll3 6y ago
You read my mind.
thealienthing 6y ago
I can only imagine how many JS diehard fans are screaming in rage when they read this. I’m with you.
- ahmedalsudani 6y ago
  All three of them :) Mostly there are diehard haters for JS, not diehard fans. A lot of people who use JS are pragmatists and fantastic problem solvers that I have a ton of respect for. -Someone who's not too fond of JS
  - shepherdjerred 6y ago
    I used to be a die-hard hater but converted to a die-hard fa n when I started actually learning the language. Once you know the quirks it's quite nice. Of course since it's dynamically typed it's hard to use for larger programs, but TypeScript solves that.
- gwbas1c 6y ago
  I took the time to learn some modern JavaScript and I love it... But give me a statically typed compiled language any day! The browser is so important that we shouldn't be locked into using a single language, so I fully support being able to choose between Rust or a JavaScript!
nobleach 6y ago
While I do get annoyed at JS often, I get just as annoyed by Rust. Sometimes, I really just want to read a CSV and create a Map<String, String> from a few of the columns. But oh my god if Rust doesn't make that a nightmare. Is it a String? an &str? Do I want to allocate that string on the stack? I won't know the size of it at compile time, so of course not... right? So no to 'static? Give me a nice middle of the road like TypeScript, Kotlin, OCaml/Reason... Rust just goes SO FAR in the other direction that I don't find it a pleasant experience. I get that it's the ULTIMATE in performance, I just always question if I really need it for doing web work.

AlchemistCamp 6y ago

I've been going through Programming WebAssembly with Rust, from Pragmatic Bookshelf and have been getting interested in the possibilities. Yew is just one part of the book, but it's a good crash course and motivation for digging in. https://pragprog.com/titles/khrust/ https://pragprog.com/titles/khrust/

ori_b 6y ago

This is a big reason that I think wasm is a step in the wrong direction. It's basically nudging people into making things even more opaque. How, for example, would you go about blocking ads in this kind of app?

jakogut 6y ago
> This is a big reason that I think wasm is a step in the wrong direction. It's basically nudging people into making things even more opaque. WebAssembly is a tool, not a technique. It's not meant to replace JavaScript or the DOM, it's meant to supplement it in projects where it makes sense. Is it any more opaque than any other transpiled and minified SPA that in no way resembles anything remotely human readable anymore? I don't consider this a valid criticism of WASM. > How, for example, would you go about blocking ads in this kind of app? Probably the same way it's done now, by blocking requests to blacklisted domains known for hosting advertisements.
jelder 6y ago
If it’s actually harder to block ads in apps built like this, that’s a great reason for site owners to choose wasm.
- ori_b 6y ago
  And a great reason for users to resist it.
- AnyTimeTraveler 6y ago
  You can still use normal adblockers with this. Most of them just have a blacklist of domains that they block the requests for. Wasm won't change anything about that. The requests are still exactly the same as in JS, so blocking will work exactly the same.
AgentME 6y ago
Sites using WebAssembly still need to use the DOM just like JS sites, and be equally ad-blockable. Technically a site could render everything as an opaque image in a canvas element, which would be hard to do ad-blocking on, but there's nothing about WebAssembly inherently connected to canvas elements. Whether a site uses WebAssembly and whether it puts all its contents in a canvas element are orthogonal issues. JS sites are equally capable of putting all their content in canvas elements, and very few of them do.

merrvk 6y ago

Cannot wait for the days where i no longer have to write JS

millstone 6y ago

The wasm on this page is 476 KB.

kissgyorgy 6y ago

You build your website in Rust, I build 3 websites in that same time with Python/JavaScript.

ioseph 6y ago
In which time I build 30 websites using wordpress. Heaven forbid the author does something for any reason other than productivity gains

truly_furqan 6y ago

That's interesting. But, IMO it has a lot of room for improvement to compete with frameworks like React, Vue, and Svelte. Isn't it?

1vuio0pswjnm7 6y ago

I was hoping "single page" meant all the code fit on one page.

joshsyn 6y ago

Its funny anything questioning use of Rust is being downvoted. Rust evangelism strike force is in play. Again I don't get the appeal of Rust for Dom manipulation unless its computationally heavily.

gwbas1c 6y ago

I'm still baffled by the need for a boilerplate Javascript file to call into rust. Why can't I just include the wasm directly from HTML? Seems like someone's feelings will be hurt when they realize that many developers want to skip JavaScript and just work with wasm.

fb03 6y ago
committee is working on a DOM-access-directly-from-WASM spec. but for now we still need to use things like wasm-bindgen to generate the boilerplate needed for us. It's still fast, tho. Have you tried https://sandspiel.club/ https://sandspiel.club/ ?
steveklabnik 6y ago
The browser API requires it.
- gwbas1c 6y ago
  It's just two lines of JavaScript to call into wasm: 1 line to load the wasm, another to call a function in it. This adds latency, and is easily replaced by a single tag.

BooneJS 6y ago

Is blocking WASM a thing yet? I guess I wouldn’t know if I’ve launched a WASM page, but I was curious if WASM was popular enough for IT security folks to block on enterprise computers.

bob1029 6y ago
Not to my knowledge. I don't see any reason for it to be blocked, even in theory. It's not like you get access to a more permissive API surface or anything. If someone is going to feed you malicious code to execute, all WASM will do is make it harder to inspect.

nojvek 6y ago

Until we fix the wasm->dom bridge to be just as fast as the js->dom bridge, js will still have a leg up. AFAIK the hard bits are in bindgen which makes js structs look like wasm ones and vice versa. I’ve been doing frontend for over a decade and quite bullish on wasm once that boundary isn’t so expensive. It should be possible to make super performant apps with wasm. Figma sticks out to me as someone really pushing the edge.

apiudit 6y ago

Hate to be that guy but with a such small SPA I was expecting a better file size, 136KB compressed with brotli 487KB uncompressed. Being said that score in Page Speed Insights is pretty good (95). Will be interesting how size increases with bigger/complex apps.

deleted 6y ago
[deleted]
ChrisSD 6y ago
I wouldn't assume the growth in binary size is anything like linear with code size (i.e. there's probably a lot of fixed overhead). And they appear to be using the "--dev" compiler profile, which is unoptimized and meant for debugging.

austincheney 6y ago

I have never understood why people find UI challenging, aside from accessibility and security. State management is ridiculously easy. So easy that you are going to 10x greater effort reading your favorite framework’s API. To manage state store your state criteria in a central object. Save that to storage somewhere, such as localStorage. To restore state read the stored state object and apply each item to its respective area of the application. Modules and components are ridiculously easy now too thanks to ECMAScript modules.

tristanMatthias 6y ago

Am I the only one that finds this REALLY verbose for doing some really simple stuff? Forewarning, I'm a JS dev trying to get out of the "JS" box. I'm super interested in WASM for a lot of reasons (running ML models on the client in python, etc). This syntax (and maybe it's just Yew) feels like it has SO much boilerplate. For you seasoned rustacians out there, is this something that could be reduced? It feels overkill for me. But then again, maybe I'm a spoiled JS dev with the wrong expectations. Really curious to answers on this.

steveklabnik 6y ago
It's hard to say without knowing what specifically you find to be verbose. "verbose" is a very subjective measure.

rriepe 6y ago

Thanks for this. I was wanting to look into this, and this page is way more than enough to get me started.