14 ms·

Seed – A Rust front-end framework for creating fast and reliable web apps

322 points by ibraheemdev 5y ago

lbj 5y ago
Im excited to see Rust use more and more for webdevelopment, certainly some interest prospects. Im a little disappointed to see the amount of boilerplate in the examples. The Todo app is infinitely-5 longer than the Clojurescript example.
brundolf 5y ago
What sets Seed apart from other Rust front-end frameworks? Is the Elm-like approach unique in that space? Unique or not, I bet it makes working with the borrow-checker a whole lot easier
- ironmagma 5y ago
  Yew and Sauron also exist which use the MVU pattern like Elm. Percy might also, not sure about that. Seed has a less React-inspired interface.
  - ivanceras 5y ago
    Author of sauron here, Yes sauron[0] is very much elm-like than any of the other rust framework, and it's very fast. How fast? Fast enough to be used in a text-editor[1] at ~15ms typing latency. It also suited application that has recurring events such as animation[2] It also supports server-side rendering, and is used in one of my other opensource project svgbob[3] [0]: https://github.com/ivanceras/sauron https://github.com/ivanceras/sauron [1]: https://ivanceras.github.io/ultron/ https://ivanceras.github.io/ultron/ [2]: https://ivanceras.github.io/futuristic-ui/ https://ivanceras.github.io/futuristic-ui/ [3]: https://ivanceras.github.io/svgbob-editor/ https://ivanceras.github.io/svgbob-editor/
    - skohan 5y ago
      Is sauron ready for production in your opinion?
      - ivanceras 5y ago
        I've been using it in production for svgbob. There have been a lot of breaking changes for the past month, but things are starting to stabilize[0] in the 0.43.x release. Hopefully the version stays at 0.43.x and no more breaking changes, due to using better, appropriate or more descriptive names in Struct and functions. [0]: https://github.com/ivanceras/sauron/blob/master/Changelog.md https://github.com/ivanceras/sauron/blob/master/Changelog.md
ceocoder 5y ago
My most sincere thanks to the author(s) for “Why Not” section. This level of self awareness and transparency makes me so happy; it takes so much guess work and unnecessary back and forth out of the discourse. Again - kudos!
- zhiel 5y ago
  In my opinion, this is the way forward. You cannot convince anyone that does frontend stuff to even try, or EVEN switch to this. We have to prove that this is a viable option, WASM is a viable way, WASM is actually more efficient etc. there are benchmarks and targeted studies... it just seems that browser vendors and devs haven't catched up yet
  - labawi 5y ago
    HTML & CSS is a viable option. HTML is actually more efficient. There are benchmarks and studies, yet they are not needed, as the difference is apparent. Must we cede control of user agents to random third parties, loading and executing ever more obfuscated, inaccessible, bloated and hostile code? AFAICT, most of the coded loaded in a typical browser serves a user-hostile purpose. Do you think wasm support should be mandatory for random web pages? Do you think it will not be used to shove even more bloated, hostile etc code? Will it not be used to circumvent/prevent adblockers etc? Do I need to link to a study showing most wasm is used in a hostile manner? IMO, wasm is a net-negative on the web. Even though it does have significant good uses. It should be (or should have been) opt-in for specific pages that have a good use for it.
    - Animats 5y ago
      WASM is for when you need serious client side crunch power, like running a 3D game. If all you're doing is manipulating the DOM, it's overkill. For ordinary web sites, the other extreme, DaisyUI, a CSS-only system, seems useful. [1] https://daisyui.com https://daisyui.com
- apozem 5y ago
  So often people get emotional about languages and frameworks. They’re tools, and tools have trade offs. The “Why Not” section recognizes that. Super impressive.
echelon 5y ago
The code is terse right now, but all of the ideas are there. In two years, I fully expect Rust to begin taking off as a major frontend language choice. A framework like Seed will help usher this in. It'll be faster than Javascript, eventually multithreaded, and produce portable binaries that can run on a wide variety of platforms and architectures. It'll paint to DOM, but also do immediate mode and other types of rendering. We'll see incredibly rich applications: games, video editors, IDEs, etc. Electron will yield to this. We'll have fast, cross-platform apps that run not just on the browser, but natively on Windows, Linux, and Mac. If we're lucky, we might even start writing mobile apps this way and ditch the iPhone/Android specific APIs.
- void_mint 5y ago
  I don't think this will happen, I don't even think Rust will become 1/10th the frontend language you're predicting it will.
- hnlmorg 5y ago
  I love your optimism but I think you're overlooking a lot of why we've ended up in the landscape we are now, and it's not because we lacked a well designed language. It's because Javascript is like PHP: easy to learn, quick to develop in, cheap to hire, and just about good enough for people to stick with it. Don't get me wrong, I hate Javascript as a language. But sometimes worse is better.
  - homarp 5y ago
    [edited to make my point clearer] This is not about "value" of the language (worse is better) it is just about cost (cheap is better). Hiring js dev is cheaper because it is cheaper/faster to learn js.
    - hnlmorg 5y ago
      You're just reiterating the same points I made :)
      - 5y ago
super_flanker 5y ago
It's great to see good wasm frameworks. I know the DOM interaction still requires js bridging, but I'm still interested in knowing rendering performance relative to yew (another wasm framework) and reactjs. Also last time I tested, the release bundle sizes were quite big, has there been any improvement here?
- the__alchemist 5y ago
  I'm looking forward to the time when JS bridging isn't required. Once that happens, it should be possible to use Rust as more of a conceptual "drop-in" to the JS DOM-manipulation API - framework or not.
deleted 5y ago
[deleted]
ggregoire 5y ago
On a side topic, what are the recommended Rust frameworks for creating REST APIs?
- brundolf 5y ago
  Rocket is the most promising up-and-comer I know about: https://rocket.rs/ https://rocket.rs/ It manages to provide an experience along the lines of Flask or Express Iron and Actix are the more established but more complicated ones Edit: According to a reply, Iron is considered abandoned
  - agersant 5y ago
    Iron is very much abandoned, I would not recommend it. I agree Actix and Rocket are the more common picks!
    - brundolf 5y ago
      Got it. I knew Iron was kinda being phased out due to stuff like not having async/await, but I didn't know it had gone so far as being "abandoned".
  - deleted 5y ago
    [deleted]
  - ggregoire 5y ago
    Actix is #5 on techempower.com/benchmarks, that's impressive!
    - Zababa 5y ago
      And Rocket is surprisingly slow. Is this because it's not async yet?
      - deleted 5y ago
        [deleted]
option_greek 5y ago
Is there a way to use standard frameworks like bootstrap with this or other similar wasm based rust frontends? Otherwise, it's hard to see how it will ever have enough rich components to really take off.
- dureuill 5y ago
  I had some luck with yew + bulma.io. There's a crate called ybc they implements yew components using bulma classes. I had to reimplement a component myself though because I needed to hoist its state. Doing so wasn't very complicated.
fspeech 5y ago
I deleted my first question so that I could read on the subject a little to make sure the question wasn't a stupid one. After doing some reading I still have the same question so here it is again: Does wasm app save memory significantly at runtime? If not why should one choose manual memory management outside of porting existing code?
- monocasa 5y ago
  I wouldn't imagine here that Rust's value add in this case is the memory management. Instead it's probably the strict and ergonomic control over constness (I prefer rust in that specfic context to js Object.freeze), the typesafe concurrency, and if you're the kind of crazy person that would use rust on the frontend in 2021 you probably are using it in the backend and you can therefore share code.
  - brundolf 5y ago
    I could also see it helping with bundle size. Also, while uncommon, it's not impossible for VDOM rendering to be a performance bottleneck on complex apps. I used to work on one where we had enough components on the screen at a time that it was often a problem.
  - verdagon 5y ago
    IIRC, functional programming already offered const-ness and type-safe concurrency. Do you think Rust might succeed here where FP couldn't really make much of an impact?
    - monocasa 5y ago
      FP with typesafe concurrency hasn't really happened on the frontend yet in meaningful way. And I wouldn't frame it as Rust succeeding where FP failed, but instead a way to sneak in FP into the frontend in a way that gets really angry at you when you try to structure your code as mutable and imperative. Yes, most of the frontend languages let you opt in to constness and compile time typesafety, but Rust makes you opt out. It's soft developer thing, but it seems to have benefits to code quality from my experience.
zamalek 5y ago
I tried Seed out a while back, one thing I really enjoyed was the lack of JSX-like views. It's not necessarily the aesthetics of it, it's that it takes ages to compile those macros.
- brundolf 5y ago
  Meaning the style of macros used by this framework is just simpler and therefore faster to compile?
  - zamalek 5y ago
    Exactly, they are essentially "boring" macrorules.
- seph-reed 5y ago
  I loathe jsx. Having two separate coding languages in a single file that switch back and forth is such a ridiculous idea to me. And on top of that, I don't think jsx is any more readable than nested functions.
  - skohan 5y ago
    I like it. For me it makes it dead easy to glance through a file and instantly understand what's the boundary between the view layer and everything else. At the end of the day you're creating HTML, so JSX is like a WYSIWYG from that perspective.
purisame 5y ago
Does anyone know how this compares to Yew?
- zhiel 5y ago
  They are pretty much identical. Seed has better docs, Yew has a promise for multi-threaded stuff, but its not very well documented (or even working). I've tried projects with both and the nice thing with Yew is that the syntax for HTML is kinda compatible with the actual thing (think JSX.) Seed however is macros only. Both seem to compile in the same time, but I would bet there would be differences on bigger projects (which there are none atm?)
  - the__alchemist 5y ago
    Re big projects: I'm (sort of) using Seed on web-based scheduling and training software used by 7 operational fighter squadrons. The most complicated pages are in React/TS (eg the actual scheduling board), and the Seed pages are/were mostly simpler ones, like tracking qualifications, personalized schedules etc. I'm actively rewriting the smaller pages from Seed/Rust and TS/React to HTML/CSS/JS for performance and simplicity reasons.
  - purisame 5y ago
    I do like the JSX feel of Yew, but the docs are definitely lacking. And the latest changes on master have changed a ton of stuff.
- the__alchemist 5y ago
  Yew predates Seed, and provided inspiration. At the time, Yew wasn't in a usable state. There were no full examples, no documentation, and the starter code in the Readme didn't coincide with the release. I believe they fixed those sometime after Seed's release. This doesn't directly answer your question, but is the context in why Seed started, with Yew already existing. An immediately noticeable difference is that Yew uses a JSX-like syntax, while Seed uses a custom API based on list-like macros.
  - 5y ago
turtlebits 5y ago
Looking the home page (which looks to be built with seed-rs), a ~500k wasm file is loaded. The static part loads fairly fast, but none of the links work until after the wasm loads (you can tell because the header changes) Looks like the entire site is in the wasm file as no additional network requests are made. Doesn't seem great for general purpose web sites (like your home page).
- sfvisser 5y ago
  Not that I disagree — it's rather steep — but not super unlike many react/vue based sites. Frameworks like Next.js can help by adding seamless server side rendering so at least your links will work before your js/wasm is loaded. Maybe seed-rs can move into that direction as well.
- brundolf 5y ago
  Is that 500k with or without gzip? With gzip, that would be huge. Either way there are certain techniques like bundle-splitting and hydration that will probably have to be reinvented for these WASM frameworks, unfortunately. For the moment they're probably better suited to high-complexity browser-based tooling that needs the extra performance, vs simple crud sites. Edit: on second thought, for an entire multi-page site in one bundle this wouldn't be super huge. I'm used to smaller numbers but I'm also used to split-bundles.
  - turtlebits 5y ago
    For the site (including wasm) - (over the network) 597 kB transferred (uncompressed) 2.3 MB resources
    - azakai 5y ago
      The wasm file is dc7bb6f6208af7f13f16.module.wasm which is 2MB uncompressed.
- zhiel 5y ago
  Now imagine if the WASM folks had all the bundler/dead code elimination/link time optimization..., its coming, sorta...
aitchnyu 5y ago
How is interop with JS libraries like Leaflet?
jbandela1 5y ago
Kudos to the author for making this framework. I am using this for my personal project: https://www.biblemaze.com https://www.biblemaze.com which is a Bible trivia game. Here are some things I like about Seed: 1. The Elm architecture seems to flow nicely in Rust. 2. The way of defining the elements on the page is more Rust like rather than html like. I initially tried Yew which is another similar framework, but since I am a more backend developer, I found writing in a more Rust style more comfortable than writing in a more html-like dsl. Other with different experiences may be more comfortable with more html-like syntax. 3. Very easy to perform REST API calls. I am using Actix for the backend, and I have a shared library that declares the types which both the backend and frontend use. This is one big advantage for using Rust for both backend and frontend, in that you never have to worry about your types getting out of sync. 4. In general as to why Rust for the front end, apart for being able to share types, for more complex algorithms, for me, having a compiled language with an emphasis on safety and that tries to ensure correctness as much as compile time (and especially pattern matching) makes writing complex code more enjoyable for me. 5. Excellent documentation on the Seed website. There are lots of examples and walkthroughs of basics as well as examples of how to do stuff like integrate with Javascript libraries. Anyway, thanks again to the authors for making and supporting such an awesome library.
- rictic 5y ago
  - This is one big advantage for using Rust for both backend and frontend, in that you never have to worry about your types getting out of sync. One thing to be aware of here, you may have users with stale clients after deploying an update to the server. e.g. picture someone who leaves a tab open for a week and then comes back to it and interacts with your app some more without refreshing. Text based serializations will tend to be more forgiving of changes in the RPC schema (in the sense of erroring out when required fields are missing), while more compact serializations are more likely to incorrectly decode a message when they should fail.
  - mdtusz 5y ago
    The quick and dirty solution to this is to have a client response handler that checks for a header set on responses to ensure its a compatible version, then prompt a page refresh if not.
beders 5y ago
I will never understand why anyone would want to use a compiled language to do front-end development. The beauty of JS and especially the beauty of ClojureScript is that you can immediately see the effects of your work in an interactive environment. Using the right libraries you can have true hot reloading without destroying state giving you a terrific, fast, fluid development experience. What are acceptable compile and reload times for you guys loading WASM?
- onei 5y ago
  > ClojureScript is a compiler for Clojure that targets JavaScript. [1] If ClojureScript is compiled, why can't WASM be the same? [1] https://clojurescript.org/ https://clojurescript.org/
  - CraigJPerry 5y ago
    In clojurescript you can press your slime or calva keystroke to send a form (or an expression from a rich comment) to the browser repl and see that immediately reflect and use the current state of the app without reloading. What’s the equiv workflow when compiling to wasm? Save file > compile > hot reload? > reconstruct state somehow? Is it like clojurescript where you interactively work on the app in the same way you might interactively craft a sql statement in a live db?
    - onei 5y ago
      In Rust, no clue because I've never tried. However, I did find a hot reload of WASM compiled from C++ [1]. If they're not equivalent, I would imagine it's a matter of ecosystem maturity rather than it being impossible. Realistically, hot reload is going to be something like inotify(7) hooked into a compiler and whatever it takes to reload seamlessly. If it's been solved in one general purpose language, it's likely to be possible in another. [1] https://visualstudiomagazine.com/articles/2021/07/29/cpp-hot-reload.aspx?m=1 https://visualstudiomagazine.com/articles/2021/07/29/cpp-hot...
      - 5y ago
zackoverflow 5y ago
I have seen a few of these Rust front-end projects, they are all really great except for the fact that very few support SSR. This is especially important given the fact that it is much slower sending wasm over the wire and instantiating the module and the wasm environment vs plain js I'm not sure if this is because of the complexity of the undertaking (I imagine it would need some sort of virtual DOM) or just lack of interest
- brundolf 5y ago
  What makes you think sending WASM over the wire is slower? The payloads should be smaller than JS, assuming you aren't shipping a runtime alongside your code (which Rust doesn't). I don't know about the bootstrapping side, but I know some people use WASM specifically for the small bundle sizes.
  - zackoverflow 5y ago
    thanks for the correction, was formulating the sentence and somehow "wasm over the wire" injected itself in there. 100% transfering wasm in the binary format is a more efficient transfer than js.
  - rictic 5y ago
    The Rust compiler and ecosystem are tuned more towards generating faster code rather than generating smaller code. In my experience, even small wasm apps that are careful about their dependencies end up shipping hundreds of KB of wasm over the wire, and if you're not as careful that easily tips over to MBs. Time and space are in tension, and the web is more sensitive to binary size than most other targets, including many embedded targets. To take one example that often contributes a ton to binary size, consider data serialization in Rust vs JS. JS will tend to just use JSON.parse and deserialize into a JS object with little to no data validation. The JS object is then exclusively accessed via dynamic field lookup (with a JIT doing its best to notice patterns and hopefully optimize the hot paths). The same code paths can handle many different message shapes. It's far from optimal in terms of runtime speed, but the code can be made very compact. Rust deserializers by contrast seem to use compiler-time code generation to produce a different optimized struct layout, parser, and validator for every message type. When I've played with writing very small Rust + wasm apps, the choice of serialization library and format made a huge difference. If I recall correctly, using BSON + serde would have increased my total binary size by more than 3x. This isn't a fundamental issue with Rust as a language, I think it's partly still early days for the tooling. There is, however a certain fundamental amount of tension there in what's optimized for. In most environments, 30% faster deserialization for a binary that's 500KB larger (pulling numbers out of my ass) is in the "obviously yes, do that" category, but on the web adding 500KB to your binary is a steep price to pay, particularly for mobile users.
zhiel 5y ago
Not affiliated, but an alternative to Seed or Yew is a new lib: https://github.com/sycamore-rs/sycamore https://github.com/sycamore-rs/sycamore AFAIK Seed and Yew target the VDOM stuff which has always been an unnecessary overhead, Sycamore does what Svelte does. It's very early days for Rust/WASM/Frontend, but all of this progress is very promising.
- the__alchemist 5y ago
  This is a great approach. Ie, declarative coding GUIs (like webapps) is nice, but VDOM is performance overhead, ie unnecessary computation. I haven't looked into how Svelte (Or Sycamore) do it, but being able to compile declarative code into targeted DOM manipulation seems like a best-of-both-worlds.
- kitkat_new 5y ago
  no idea about Svelte, but what I've read in the documentation definitely looks very interesting!
- chrismorgan 5y ago
  I’d call Sycamore fairly different from Svelte; both eschew VDOM, but they do it in decidedly different ways, which I would summarise as Svelte being a component-oriented compiler primarily modelling reactivity implicitly, but Sycamore being a data-oriented library almost incidentally capable of producing HTML, exclusively modelling reactivity explicitly. Svelte is a compiler through and through, providing and requiring its own syntax for things like conditionals and iteration, and declaring reactivity at the syntax level, inextricably tying its reactivity to properties on components, except for stores which allow regular JavaScript to get involved in reactivity (though components also get special support for stores via the $foo syntax). Dirty tracking happens at the component level. Sycamore, on the other hand, is straight Rust (though typically assisted by procedural macros, which I will admit weakens the distinction), with only explicit reactivity (like Svelte’s stores), but keeping track of dependencies at runtime (more like Ember.js) and with things like conditionals handled as regular Rust code, and iteration as just a component that gets given an iterable rather than needing dedicated constructs. Dirty tracking happens at the data level. (Qualifier: I’m expert with Rust and Svelte, fairly familiar with Ember.js, and quite familiar with some of Sycamore’s similar precursors, but I have only skimmed Sycamore, reading docs and a bit of code; I haven’t actually used it.)
zhiel 5y ago
If anyone is curious about Seed, here is my example project for pushing it sorta to a limit: https://rsfractal.herokuapp.com/ https://rsfractal.herokuapp.com/ It doesn't really test Seed, but I guess Seed just works?! :shrug:
- jjwiseman 5y ago
  FYI it doesn't seem to work for me in Safari or Chrome.
  - jeroenhd 5y ago
    It works fine for me on Chrome (Linux or Android), Edge(ium, on Linux and Windows) and Firefox (Linux, for some reason not Android). It fails on Gnome Web (which is WebKit GTK), which is the closest I could get to Safari, because of SharedArrayBuffers being unavailable [0]. It seems like WebKit hasn't re-enabled them since the first Spectre mitigations like Chromium and Firefox have. One reason it could fail for you on Chrome is that perhaps you tested on iOS; Chrome on iOS shouldn't make or break web applications because Apple forces WebKit onto every browser on that platform, so they're all Safari with a skin. A broken website in iOS Safari is usually broken in all other browsers by Apple's design. Otherwise the code should work fine on up-to-date Chrome across all real Chrome platforms, unless you specifically toggled flags... [0]: https://caniuse.com/mdn-javascript_builtins_sharedarraybuffer https://caniuse.com/mdn-javascript_builtins_sharedarraybuffe...
the__alchemist 5y ago
Seed creator here. For some context, I now code all my websites in HTML, CSS, and targeted JS (ie no frameworks or dependencies). Writing this was a great way to learn the ins and outs of DOM manipulation! Overall, I'm happy with the way the Seed API turned out, but could never get the performance or package size to a good place. That said, I love coding in Rust, and use it all the time for embedded!
- azakai 5y ago
  > I [..] could never get the performance or package size to a good place. Do you have any more details on that? I'm curious how close this got, and what were the main issues (on both size and speed).
  - the__alchemist 5y ago
    I don't have specific info, but generally: - VDOMs in general have poor performance; they perform unnecessary computations in the diffing algorithm, and even well-designed ones perform extra DOM manipulations, compared to deliberately-written code. - The Rust WASM files would come out pretty large; a few hundred KB for a minimal app. This is better than some packages using React + common JS dependencies like Lodash and Moment, but with much room for improvement - DOM manipulation calls made in Rust via WASM(currently!) don't have any performance benefit over the native JS API
    - smt88 5y ago
      It sounds like you made a Rust version of React. I think a Rust version of Svelte makes more sense in the long run.
      - the__alchemist 5y ago
        Accurate, and I agree.
      - worik 5y ago
        Do it
darkstarsys 5y ago
How would you debug serious web apps written in this Rust/wasm? Chrome dev tools can't load your Rust code, right?
- ivanceras 5y ago
  I just `log` and `console_log` crate for showing values in the browser console. It's good enough for most cases.
fuddle 5y ago
Awesome looking forward to checking this out. FYI the header spacing looks a bit off: https://ibb.co/HzMNCJZ https://ibb.co/HzMNCJZ
kklisura 5y ago
I'm afraid that just like we have very simple web sites built with large SPA/frontend frameworks, we're gonna soon start seeing those same, but now built with WebAsembly. Let me be first saying that just like you don't need React, Ember, Angular, etc. to build your site, you also don't need the WASM as well!
- smt88 5y ago
  This project isn't just using wasm for the sake of it. It's the best browser-supported target language for Rust, so if you want a Rust front-end framework, you're going to compile to wasm.
rapind 5y ago
“You will likely have to roll your own components such as date pickers.” Anyone else think it’s insane that we’re still implementing JS date pickers in 2021? How was this not native like 20 years ago?
- spoiler 5y ago
  There are native solutions in browsers. I think they mean that they'd have to use their own custom "rust to dom" ones, if they didn't like the native browser ones (they do have some limitations around styling and formatting)
  - rapind 5y ago
    Very very recently some do, and they aren't amazing. I'm not even sure Firefox 93 is officially released yet? Safari support was less than a year ago. https://caniuse.com/?search=datetime-local https://caniuse.com/?search=datetime-local Don't get me wrong. I'm glad we finally have some consensus, but this should have happened before ES6 (2015!) IMO. jQuery had a date picker before 2009 at least (probably earlier, but I'm not sure).
- dragonwriter 5y ago
  > How was this not native like 20 years ago? Date inputs were standardized with HTML5, but browser implementations are of variable quality (and, important to designers, variable default look-and-feel, and limited, IIRC, customizability).
int_19h 5y ago
Why Rust for this application, though? You don't really need to be "close to the metal" in the frontend (and there's wasm overhead in any case), so it seems like it'd be better to go with something a bit higher-level, with GC etc, rather than fight with the borrow checker.
nitsky 5y ago
We chose to use Rust instead of TypeScript for the front end of https://github.com/tangramdotdev/tangram https://github.com/tangramdotdev/tangram. This allows us to: * Share code with our server written in Rust. * Avoid keeping types in TypeScript in sync with Rust. * Do server rendering without including a JavaScript runtime. * Avoid maintaining a JS stack, including TypeScript, Prettier, ESLint, and a bundler. Because we split our project into many crates, incremental build times are about 1-2 seconds on a linux desktop. This is not as convenient for quick iteration on UI/UX as hot reload with React, but on the other hand, code that type checks is more likely to run correctly. Overall, I would say that the trade offs are not clear, even for our unique case where we have a server written in Rust. I am hopeful that in the future, browsers will enable native DOM access from WASM, and the Rust compiler will support code splitting between multiple WASM entrypoints. When this happens, I think there will be a strong case to recommend Rust for more front end projects.
- nitsky 5y ago
  I should add that we wrote a crate called pinwheel that uses futures-signals for fine-grained reactivity, uses the builder pattern to avoid macros entirely, and supports server rendering: https://github.com/tangramdotdev/pinwheel https://github.com/tangramdotdev/pinwheel
- da39a3ee 5y ago
  > Avoid keeping types in TypeScript in sync with Rust. Out of curiosity, did you try auto-generating the typescript types from the Rust types?
  - nitsky 5y ago
    ts-rs did not exist at the time. Perhaps if it did, we would have chosen differently. Generating types with “cargo test” feels very hacky though.
- skohan 5y ago
  Yeah the build times were a killer for me. I did a small project with rust->wasm in the front-end, and this was a bit painful compared to a standard react workflow. It would be really nice if this could be improved in the future.
deleted 5y ago
[deleted]
journey_16162 5y ago
Do you think that Rust (or any other language that compiles to wasm) will become preferred over traditional JS for single page applications and Electron desktop apps? Would there be any advantages to this, or would it be an overkill? My thoughts; Pros: - Definitely will be useful for resource intensive application (rather not the majority of web and desktop apps) - Better source code protection if you are shipping a proprietary product (some people may view it as a con) Cons: - Build times ? - Larger download size (for web apps) - Rust is safe, but a GCed language will always be safer and have less low level overhead for the developer

322 points by ibraheemdev 5y ago

lbj 5y ago

Im excited to see Rust use more and more for webdevelopment, certainly some interest prospects. Im a little disappointed to see the amount of boilerplate in the examples. The Todo app is infinitely-5 longer than the Clojurescript example.

brundolf 5y ago

What sets Seed apart from other Rust front-end frameworks? Is the Elm-like approach unique in that space? Unique or not, I bet it makes working with the borrow-checker a whole lot easier

ironmagma 5y ago
Yew and Sauron also exist which use the MVU pattern like Elm. Percy might also, not sure about that. Seed has a less React-inspired interface.
- ivanceras 5y ago
  Author of sauron here, Yes sauron[0] is very much elm-like than any of the other rust framework, and it's very fast. How fast? Fast enough to be used in a text-editor[1] at ~15ms typing latency. It also suited application that has recurring events such as animation[2] It also supports server-side rendering, and is used in one of my other opensource project svgbob[3] [0]: https://github.com/ivanceras/sauron https://github.com/ivanceras/sauron [1]: https://ivanceras.github.io/ultron/ https://ivanceras.github.io/ultron/ [2]: https://ivanceras.github.io/futuristic-ui/ https://ivanceras.github.io/futuristic-ui/ [3]: https://ivanceras.github.io/svgbob-editor/ https://ivanceras.github.io/svgbob-editor/
  - skohan 5y ago
    Is sauron ready for production in your opinion?
    - ivanceras 5y ago
      I've been using it in production for svgbob. There have been a lot of breaking changes for the past month, but things are starting to stabilize[0] in the 0.43.x release. Hopefully the version stays at 0.43.x and no more breaking changes, due to using better, appropriate or more descriptive names in Struct and functions. [0]: https://github.com/ivanceras/sauron/blob/master/Changelog.md https://github.com/ivanceras/sauron/blob/master/Changelog.md

ceocoder 5y ago

My most sincere thanks to the author(s) for “Why Not” section. This level of self awareness and transparency makes me so happy; it takes so much guess work and unnecessary back and forth out of the discourse. Again - kudos!

zhiel 5y ago
In my opinion, this is the way forward. You cannot convince anyone that does frontend stuff to even try, or EVEN switch to this. We have to prove that this is a viable option, WASM is a viable way, WASM is actually more efficient etc. there are benchmarks and targeted studies... it just seems that browser vendors and devs haven't catched up yet
- labawi 5y ago
  HTML & CSS is a viable option. HTML is actually more efficient. There are benchmarks and studies, yet they are not needed, as the difference is apparent. Must we cede control of user agents to random third parties, loading and executing ever more obfuscated, inaccessible, bloated and hostile code? AFAICT, most of the coded loaded in a typical browser serves a user-hostile purpose. Do you think wasm support should be mandatory for random web pages? Do you think it will not be used to shove even more bloated, hostile etc code? Will it not be used to circumvent/prevent adblockers etc? Do I need to link to a study showing most wasm is used in a hostile manner? IMO, wasm is a net-negative on the web. Even though it does have significant good uses. It should be (or should have been) opt-in for specific pages that have a good use for it.
  - Animats 5y ago
    WASM is for when you need serious client side crunch power, like running a 3D game. If all you're doing is manipulating the DOM, it's overkill. For ordinary web sites, the other extreme, DaisyUI, a CSS-only system, seems useful. [1] https://daisyui.com https://daisyui.com
apozem 5y ago
So often people get emotional about languages and frameworks. They’re tools, and tools have trade offs. The “Why Not” section recognizes that. Super impressive.

echelon 5y ago

The code is terse right now, but all of the ideas are there. In two years, I fully expect Rust to begin taking off as a major frontend language choice. A framework like Seed will help usher this in. It'll be faster than Javascript, eventually multithreaded, and produce portable binaries that can run on a wide variety of platforms and architectures. It'll paint to DOM, but also do immediate mode and other types of rendering. We'll see incredibly rich applications: games, video editors, IDEs, etc. Electron will yield to this. We'll have fast, cross-platform apps that run not just on the browser, but natively on Windows, Linux, and Mac. If we're lucky, we might even start writing mobile apps this way and ditch the iPhone/Android specific APIs.

void_mint 5y ago
I don't think this will happen, I don't even think Rust will become 1/10th the frontend language you're predicting it will.
hnlmorg 5y ago
I love your optimism but I think you're overlooking a lot of why we've ended up in the landscape we are now, and it's not because we lacked a well designed language. It's because Javascript is like PHP: easy to learn, quick to develop in, cheap to hire, and just about good enough for people to stick with it. Don't get me wrong, I hate Javascript as a language. But sometimes worse is better.
- homarp 5y ago
  [edited to make my point clearer] This is not about "value" of the language (worse is better) it is just about cost (cheap is better). Hiring js dev is cheaper because it is cheaper/faster to learn js.
  - hnlmorg 5y ago
    You're just reiterating the same points I made :)
    - 5y ago

super_flanker 5y ago

It's great to see good wasm frameworks. I know the DOM interaction still requires js bridging, but I'm still interested in knowing rendering performance relative to yew (another wasm framework) and reactjs. Also last time I tested, the release bundle sizes were quite big, has there been any improvement here?

the__alchemist 5y ago
I'm looking forward to the time when JS bridging isn't required. Once that happens, it should be possible to use Rust as more of a conceptual "drop-in" to the JS DOM-manipulation API - framework or not.

deleted 5y ago

[deleted]

ggregoire 5y ago

On a side topic, what are the recommended Rust frameworks for creating REST APIs?

brundolf 5y ago
Rocket is the most promising up-and-comer I know about: https://rocket.rs/ https://rocket.rs/ It manages to provide an experience along the lines of Flask or Express Iron and Actix are the more established but more complicated ones Edit: According to a reply, Iron is considered abandoned
- agersant 5y ago
  Iron is very much abandoned, I would not recommend it. I agree Actix and Rocket are the more common picks!
  - brundolf 5y ago
    Got it. I knew Iron was kinda being phased out due to stuff like not having async/await, but I didn't know it had gone so far as being "abandoned".
- deleted 5y ago
  [deleted]
- ggregoire 5y ago
  Actix is #5 on techempower.com/benchmarks, that's impressive!
  - Zababa 5y ago
    And Rocket is surprisingly slow. Is this because it's not async yet?
    - deleted 5y ago
      [deleted]

option_greek 5y ago

Is there a way to use standard frameworks like bootstrap with this or other similar wasm based rust frontends? Otherwise, it's hard to see how it will ever have enough rich components to really take off.

dureuill 5y ago
I had some luck with yew + bulma.io. There's a crate called ybc they implements yew components using bulma classes. I had to reimplement a component myself though because I needed to hoist its state. Doing so wasn't very complicated.

fspeech 5y ago

I deleted my first question so that I could read on the subject a little to make sure the question wasn't a stupid one. After doing some reading I still have the same question so here it is again: Does wasm app save memory significantly at runtime? If not why should one choose manual memory management outside of porting existing code?

monocasa 5y ago
I wouldn't imagine here that Rust's value add in this case is the memory management. Instead it's probably the strict and ergonomic control over constness (I prefer rust in that specfic context to js Object.freeze), the typesafe concurrency, and if you're the kind of crazy person that would use rust on the frontend in 2021 you probably are using it in the backend and you can therefore share code.
- brundolf 5y ago
  I could also see it helping with bundle size. Also, while uncommon, it's not impossible for VDOM rendering to be a performance bottleneck on complex apps. I used to work on one where we had enough components on the screen at a time that it was often a problem.
- verdagon 5y ago
  IIRC, functional programming already offered const-ness and type-safe concurrency. Do you think Rust might succeed here where FP couldn't really make much of an impact?
  - monocasa 5y ago
    FP with typesafe concurrency hasn't really happened on the frontend yet in meaningful way. And I wouldn't frame it as Rust succeeding where FP failed, but instead a way to sneak in FP into the frontend in a way that gets really angry at you when you try to structure your code as mutable and imperative. Yes, most of the frontend languages let you opt in to constness and compile time typesafety, but Rust makes you opt out. It's soft developer thing, but it seems to have benefits to code quality from my experience.

zamalek 5y ago

I tried Seed out a while back, one thing I really enjoyed was the lack of JSX-like views. It's not necessarily the aesthetics of it, it's that it takes ages to compile those macros.

brundolf 5y ago
Meaning the style of macros used by this framework is just simpler and therefore faster to compile?
- zamalek 5y ago
  Exactly, they are essentially "boring" macrorules.
seph-reed 5y ago
I loathe jsx. Having two separate coding languages in a single file that switch back and forth is such a ridiculous idea to me. And on top of that, I don't think jsx is any more readable than nested functions.
- skohan 5y ago
  I like it. For me it makes it dead easy to glance through a file and instantly understand what's the boundary between the view layer and everything else. At the end of the day you're creating HTML, so JSX is like a WYSIWYG from that perspective.

purisame 5y ago

Does anyone know how this compares to Yew?

zhiel 5y ago
They are pretty much identical. Seed has better docs, Yew has a promise for multi-threaded stuff, but its not very well documented (or even working). I've tried projects with both and the nice thing with Yew is that the syntax for HTML is kinda compatible with the actual thing (think JSX.) Seed however is macros only. Both seem to compile in the same time, but I would bet there would be differences on bigger projects (which there are none atm?)
- the__alchemist 5y ago
  Re big projects: I'm (sort of) using Seed on web-based scheduling and training software used by 7 operational fighter squadrons. The most complicated pages are in React/TS (eg the actual scheduling board), and the Seed pages are/were mostly simpler ones, like tracking qualifications, personalized schedules etc. I'm actively rewriting the smaller pages from Seed/Rust and TS/React to HTML/CSS/JS for performance and simplicity reasons.
- purisame 5y ago
  I do like the JSX feel of Yew, but the docs are definitely lacking. And the latest changes on master have changed a ton of stuff.
the__alchemist 5y ago
Yew predates Seed, and provided inspiration. At the time, Yew wasn't in a usable state. There were no full examples, no documentation, and the starter code in the Readme didn't coincide with the release. I believe they fixed those sometime after Seed's release. This doesn't directly answer your question, but is the context in why Seed started, with Yew already existing. An immediately noticeable difference is that Yew uses a JSX-like syntax, while Seed uses a custom API based on list-like macros.
- 5y ago

turtlebits 5y ago

Looking the home page (which looks to be built with seed-rs), a ~500k wasm file is loaded. The static part loads fairly fast, but none of the links work until after the wasm loads (you can tell because the header changes) Looks like the entire site is in the wasm file as no additional network requests are made. Doesn't seem great for general purpose web sites (like your home page).

sfvisser 5y ago
Not that I disagree — it's rather steep — but not super unlike many react/vue based sites. Frameworks like Next.js can help by adding seamless server side rendering so at least your links will work before your js/wasm is loaded. Maybe seed-rs can move into that direction as well.
brundolf 5y ago
Is that 500k with or without gzip? With gzip, that would be huge. Either way there are certain techniques like bundle-splitting and hydration that will probably have to be reinvented for these WASM frameworks, unfortunately. For the moment they're probably better suited to high-complexity browser-based tooling that needs the extra performance, vs simple crud sites. Edit: on second thought, for an entire multi-page site in one bundle this wouldn't be super huge. I'm used to smaller numbers but I'm also used to split-bundles.
- turtlebits 5y ago
  For the site (including wasm) - (over the network) 597 kB transferred (uncompressed) 2.3 MB resources
  - azakai 5y ago
    The wasm file is dc7bb6f6208af7f13f16.module.wasm which is 2MB uncompressed.
zhiel 5y ago
Now imagine if the WASM folks had all the bundler/dead code elimination/link time optimization..., its coming, sorta...

aitchnyu 5y ago

How is interop with JS libraries like Leaflet?

jbandela1 5y ago

Kudos to the author for making this framework. I am using this for my personal project: https://www.biblemaze.com https://www.biblemaze.com which is a Bible trivia game. Here are some things I like about Seed: 1. The Elm architecture seems to flow nicely in Rust. 2. The way of defining the elements on the page is more Rust like rather than html like. I initially tried Yew which is another similar framework, but since I am a more backend developer, I found writing in a more Rust style more comfortable than writing in a more html-like dsl. Other with different experiences may be more comfortable with more html-like syntax. 3. Very easy to perform REST API calls. I am using Actix for the backend, and I have a shared library that declares the types which both the backend and frontend use. This is one big advantage for using Rust for both backend and frontend, in that you never have to worry about your types getting out of sync. 4. In general as to why Rust for the front end, apart for being able to share types, for more complex algorithms, for me, having a compiled language with an emphasis on safety and that tries to ensure correctness as much as compile time (and especially pattern matching) makes writing complex code more enjoyable for me. 5. Excellent documentation on the Seed website. There are lots of examples and walkthroughs of basics as well as examples of how to do stuff like integrate with Javascript libraries. Anyway, thanks again to the authors for making and supporting such an awesome library.

rictic 5y ago
- This is one big advantage for using Rust for both backend and frontend, in that you never have to worry about your types getting out of sync. One thing to be aware of here, you may have users with stale clients after deploying an update to the server. e.g. picture someone who leaves a tab open for a week and then comes back to it and interacts with your app some more without refreshing. Text based serializations will tend to be more forgiving of changes in the RPC schema (in the sense of erroring out when required fields are missing), while more compact serializations are more likely to incorrectly decode a message when they should fail.
- mdtusz 5y ago
  The quick and dirty solution to this is to have a client response handler that checks for a header set on responses to ensure its a compatible version, then prompt a page refresh if not.

beders 5y ago

I will never understand why anyone would want to use a compiled language to do front-end development. The beauty of JS and especially the beauty of ClojureScript is that you can immediately see the effects of your work in an interactive environment. Using the right libraries you can have true hot reloading without destroying state giving you a terrific, fast, fluid development experience. What are acceptable compile and reload times for you guys loading WASM?

onei 5y ago
> ClojureScript is a compiler for Clojure that targets JavaScript. [1] If ClojureScript is compiled, why can't WASM be the same? [1] https://clojurescript.org/ https://clojurescript.org/
- CraigJPerry 5y ago
  In clojurescript you can press your slime or calva keystroke to send a form (or an expression from a rich comment) to the browser repl and see that immediately reflect and use the current state of the app without reloading. What’s the equiv workflow when compiling to wasm? Save file > compile > hot reload? > reconstruct state somehow? Is it like clojurescript where you interactively work on the app in the same way you might interactively craft a sql statement in a live db?
  - onei 5y ago
    In Rust, no clue because I've never tried. However, I did find a hot reload of WASM compiled from C++ [1]. If they're not equivalent, I would imagine it's a matter of ecosystem maturity rather than it being impossible. Realistically, hot reload is going to be something like inotify(7) hooked into a compiler and whatever it takes to reload seamlessly. If it's been solved in one general purpose language, it's likely to be possible in another. [1] https://visualstudiomagazine.com/articles/2021/07/29/cpp-hot-reload.aspx?m=1 https://visualstudiomagazine.com/articles/2021/07/29/cpp-hot...
    - 5y ago

zackoverflow 5y ago

I have seen a few of these Rust front-end projects, they are all really great except for the fact that very few support SSR. This is especially important given the fact that it is much slower sending wasm over the wire and instantiating the module and the wasm environment vs plain js I'm not sure if this is because of the complexity of the undertaking (I imagine it would need some sort of virtual DOM) or just lack of interest

brundolf 5y ago
What makes you think sending WASM over the wire is slower? The payloads should be smaller than JS, assuming you aren't shipping a runtime alongside your code (which Rust doesn't). I don't know about the bootstrapping side, but I know some people use WASM specifically for the small bundle sizes.
- zackoverflow 5y ago
  thanks for the correction, was formulating the sentence and somehow "wasm over the wire" injected itself in there. 100% transfering wasm in the binary format is a more efficient transfer than js.
- rictic 5y ago
  The Rust compiler and ecosystem are tuned more towards generating faster code rather than generating smaller code. In my experience, even small wasm apps that are careful about their dependencies end up shipping hundreds of KB of wasm over the wire, and if you're not as careful that easily tips over to MBs. Time and space are in tension, and the web is more sensitive to binary size than most other targets, including many embedded targets. To take one example that often contributes a ton to binary size, consider data serialization in Rust vs JS. JS will tend to just use JSON.parse and deserialize into a JS object with little to no data validation. The JS object is then exclusively accessed via dynamic field lookup (with a JIT doing its best to notice patterns and hopefully optimize the hot paths). The same code paths can handle many different message shapes. It's far from optimal in terms of runtime speed, but the code can be made very compact. Rust deserializers by contrast seem to use compiler-time code generation to produce a different optimized struct layout, parser, and validator for every message type. When I've played with writing very small Rust + wasm apps, the choice of serialization library and format made a huge difference. If I recall correctly, using BSON + serde would have increased my total binary size by more than 3x. This isn't a fundamental issue with Rust as a language, I think it's partly still early days for the tooling. There is, however a certain fundamental amount of tension there in what's optimized for. In most environments, 30% faster deserialization for a binary that's 500KB larger (pulling numbers out of my ass) is in the "obviously yes, do that" category, but on the web adding 500KB to your binary is a steep price to pay, particularly for mobile users.

zhiel 5y ago

Not affiliated, but an alternative to Seed or Yew is a new lib: https://github.com/sycamore-rs/sycamore https://github.com/sycamore-rs/sycamore AFAIK Seed and Yew target the VDOM stuff which has always been an unnecessary overhead, Sycamore does what Svelte does. It's very early days for Rust/WASM/Frontend, but all of this progress is very promising.

the__alchemist 5y ago
This is a great approach. Ie, declarative coding GUIs (like webapps) is nice, but VDOM is performance overhead, ie unnecessary computation. I haven't looked into how Svelte (Or Sycamore) do it, but being able to compile declarative code into targeted DOM manipulation seems like a best-of-both-worlds.
kitkat_new 5y ago
no idea about Svelte, but what I've read in the documentation definitely looks very interesting!
chrismorgan 5y ago
I’d call Sycamore fairly different from Svelte; both eschew VDOM, but they do it in decidedly different ways, which I would summarise as Svelte being a component-oriented compiler primarily modelling reactivity implicitly, but Sycamore being a data-oriented library almost incidentally capable of producing HTML, exclusively modelling reactivity explicitly. Svelte is a compiler through and through, providing and requiring its own syntax for things like conditionals and iteration, and declaring reactivity at the syntax level, inextricably tying its reactivity to properties on components, except for stores which allow regular JavaScript to get involved in reactivity (though components also get special support for stores via the $foo syntax). Dirty tracking happens at the component level. Sycamore, on the other hand, is straight Rust (though typically assisted by procedural macros, which I will admit weakens the distinction), with only explicit reactivity (like Svelte’s stores), but keeping track of dependencies at runtime (more like Ember.js) and with things like conditionals handled as regular Rust code, and iteration as just a component that gets given an iterable rather than needing dedicated constructs. Dirty tracking happens at the data level. (Qualifier: I’m expert with Rust and Svelte, fairly familiar with Ember.js, and quite familiar with some of Sycamore’s similar precursors, but I have only skimmed Sycamore, reading docs and a bit of code; I haven’t actually used it.)

zhiel 5y ago

If anyone is curious about Seed, here is my example project for pushing it sorta to a limit: https://rsfractal.herokuapp.com/ https://rsfractal.herokuapp.com/ It doesn't really test Seed, but I guess Seed just works?! :shrug:

jjwiseman 5y ago
FYI it doesn't seem to work for me in Safari or Chrome.
- jeroenhd 5y ago
  It works fine for me on Chrome (Linux or Android), Edge(ium, on Linux and Windows) and Firefox (Linux, for some reason not Android). It fails on Gnome Web (which is WebKit GTK), which is the closest I could get to Safari, because of SharedArrayBuffers being unavailable [0]. It seems like WebKit hasn't re-enabled them since the first Spectre mitigations like Chromium and Firefox have. One reason it could fail for you on Chrome is that perhaps you tested on iOS; Chrome on iOS shouldn't make or break web applications because Apple forces WebKit onto every browser on that platform, so they're all Safari with a skin. A broken website in iOS Safari is usually broken in all other browsers by Apple's design. Otherwise the code should work fine on up-to-date Chrome across all real Chrome platforms, unless you specifically toggled flags... [0]: https://caniuse.com/mdn-javascript_builtins_sharedarraybuffer https://caniuse.com/mdn-javascript_builtins_sharedarraybuffe...

the__alchemist 5y ago

Seed creator here. For some context, I now code all my websites in HTML, CSS, and targeted JS (ie no frameworks or dependencies). Writing this was a great way to learn the ins and outs of DOM manipulation! Overall, I'm happy with the way the Seed API turned out, but could never get the performance or package size to a good place. That said, I love coding in Rust, and use it all the time for embedded!

azakai 5y ago
> I [..] could never get the performance or package size to a good place. Do you have any more details on that? I'm curious how close this got, and what were the main issues (on both size and speed).
- the__alchemist 5y ago
  I don't have specific info, but generally: - VDOMs in general have poor performance; they perform unnecessary computations in the diffing algorithm, and even well-designed ones perform extra DOM manipulations, compared to deliberately-written code. - The Rust WASM files would come out pretty large; a few hundred KB for a minimal app. This is better than some packages using React + common JS dependencies like Lodash and Moment, but with much room for improvement - DOM manipulation calls made in Rust via WASM(currently!) don't have any performance benefit over the native JS API
  - smt88 5y ago
    It sounds like you made a Rust version of React. I think a Rust version of Svelte makes more sense in the long run.
    - the__alchemist 5y ago
      Accurate, and I agree.
    - worik 5y ago
      Do it

darkstarsys 5y ago

How would you debug serious web apps written in this Rust/wasm? Chrome dev tools can't load your Rust code, right?

ivanceras 5y ago
I just `log` and `console_log` crate for showing values in the browser console. It's good enough for most cases.

fuddle 5y ago

Awesome looking forward to checking this out. FYI the header spacing looks a bit off: https://ibb.co/HzMNCJZ https://ibb.co/HzMNCJZ

kklisura 5y ago

I'm afraid that just like we have very simple web sites built with large SPA/frontend frameworks, we're gonna soon start seeing those same, but now built with WebAsembly. Let me be first saying that just like you don't need React, Ember, Angular, etc. to build your site, you also don't need the WASM as well!

smt88 5y ago
This project isn't just using wasm for the sake of it. It's the best browser-supported target language for Rust, so if you want a Rust front-end framework, you're going to compile to wasm.

rapind 5y ago

“You will likely have to roll your own components such as date pickers.” Anyone else think it’s insane that we’re still implementing JS date pickers in 2021? How was this not native like 20 years ago?

spoiler 5y ago
There are native solutions in browsers. I think they mean that they'd have to use their own custom "rust to dom" ones, if they didn't like the native browser ones (they do have some limitations around styling and formatting)
- rapind 5y ago
  Very very recently some do, and they aren't amazing. I'm not even sure Firefox 93 is officially released yet? Safari support was less than a year ago. https://caniuse.com/?search=datetime-local https://caniuse.com/?search=datetime-local Don't get me wrong. I'm glad we finally have some consensus, but this should have happened before ES6 (2015!) IMO. jQuery had a date picker before 2009 at least (probably earlier, but I'm not sure).
dragonwriter 5y ago
> How was this not native like 20 years ago? Date inputs were standardized with HTML5, but browser implementations are of variable quality (and, important to designers, variable default look-and-feel, and limited, IIRC, customizability).

int_19h 5y ago

Why Rust for this application, though? You don't really need to be "close to the metal" in the frontend (and there's wasm overhead in any case), so it seems like it'd be better to go with something a bit higher-level, with GC etc, rather than fight with the borrow checker.

nitsky 5y ago

We chose to use Rust instead of TypeScript for the front end of https://github.com/tangramdotdev/tangram https://github.com/tangramdotdev/tangram. This allows us to: * Share code with our server written in Rust. * Avoid keeping types in TypeScript in sync with Rust. * Do server rendering without including a JavaScript runtime. * Avoid maintaining a JS stack, including TypeScript, Prettier, ESLint, and a bundler. Because we split our project into many crates, incremental build times are about 1-2 seconds on a linux desktop. This is not as convenient for quick iteration on UI/UX as hot reload with React, but on the other hand, code that type checks is more likely to run correctly. Overall, I would say that the trade offs are not clear, even for our unique case where we have a server written in Rust. I am hopeful that in the future, browsers will enable native DOM access from WASM, and the Rust compiler will support code splitting between multiple WASM entrypoints. When this happens, I think there will be a strong case to recommend Rust for more front end projects.

nitsky 5y ago
I should add that we wrote a crate called pinwheel that uses futures-signals for fine-grained reactivity, uses the builder pattern to avoid macros entirely, and supports server rendering: https://github.com/tangramdotdev/pinwheel https://github.com/tangramdotdev/pinwheel
da39a3ee 5y ago
> Avoid keeping types in TypeScript in sync with Rust. Out of curiosity, did you try auto-generating the typescript types from the Rust types?
- nitsky 5y ago
  ts-rs did not exist at the time. Perhaps if it did, we would have chosen differently. Generating types with “cargo test” feels very hacky though.
skohan 5y ago
Yeah the build times were a killer for me. I did a small project with rust->wasm in the front-end, and this was a bit painful compared to a standard react workflow. It would be really nice if this could be improved in the future.

deleted 5y ago

[deleted]

journey_16162 5y ago

Do you think that Rust (or any other language that compiles to wasm) will become preferred over traditional JS for single page applications and Electron desktop apps? Would there be any advantages to this, or would it be an overkill? My thoughts; Pros: - Definitely will be useful for resource intensive application (rather not the majority of web and desktop apps) - Better source code protection if you are shipping a proprietary product (some people may view it as a con) Cons: - Build times ? - Larger download size (for web apps) - Rust is safe, but a GCed language will always be safer and have less low level overhead for the developer