Yew: Rust framework for making React-like client web apps

by syrusakbary • 9 years ago

500 137 9 years ago

ctulek2• 9 years ago

I was imagining a React style UI framework but for desktop apps. The ingredients I have in mind are React, GraphQL, and Rust. I think these three solve the problems of their respective areas the best and combining them together would be priceless.

Yoric• 9 years ago

How would GraphQL be useful for a desktop app?

odammit3• 9 years ago

I think GraphQL is useful for getting data for UIs on any platform.

- build views without being blocked waiting for a new rest endpoint

- get exactly what the UI needs to render

[edit]

Although to negate my own first point, nb4 being blocked on waiting for new mutations and queries :P

ctulek2• 9 years ago

A typed query language will definitely help for anything you store either locally or remotely. In this case, it would provide information to compiler to do most of the type checking for you.

It is not only GraphQL itself I had in mind though. It is also about implementing a client library similar to Apollo GraphQL where you can provide watch queries wrapping your UI components. Watch queries provide great developer ergonomics for handling the flux data flow, that is, whenever there is a change to your data in store, if the corresponding elements in datastore are watched by a query, the UI components wrapped by this watch query are re-rendered with new data, automatically.

I think this combination will help desktop development by helping to reduce boilerplate code and by providing a convention to development team. We enjoy this combination already in web UI development for the last one year, in our team.

danieldisu• 9 years ago

I think Rust may be a bit too low level for that but at least you will be in the HN frontpage with that combination for sure!

xfer2• 9 years ago

How is rust too low level for a desktop app? All the native ui toolkits are in C/C++ ...

steveklabnik6• 9 years ago

There's been some work on GraphQL and Rust https://www.gjtorikian.com/posts/2017/08/15/wrapping-rust-in...

mastax• 9 years ago

https://github.com/antoyo/relm is almost that, except elm-inspired rather than react-

bcherny• 9 years ago

Wow, that's a really clean API. Nice work!

cdaringe• 9 years ago

Great concept. This is my desired FutureStack for 2018!

kochthesecond5• 9 years ago

Why does update(...) mutate the model instead of returning the next state? This would make update a function instead of a side effect mutating the model.

vvanders6• 9 years ago

Probably for performance reasons, allocating a whole new state each frame is pretty expensive.

kochthesecond5• 9 years ago

I would argue that it is obviously worth it for the simplicity of being explicit what is the next state.

This kind of performance optimization, especially outside of game engines seem unnecessary.

algesten• 9 years ago

it's not any more expensive than allocating a new object in Javascript. possibly less. if you want immutable models, allocation will most likely happen on mutation.

whateveracct2• 9 years ago

Incremental updates to large, immutable data structures do not require allocating a whole new state per update (despite maintaining immutability!) Mutation is still frequently more efficient though, at the cost of not being able to reason immutably about your program. But if you're doing something that requires multiple versions of your state (e.g. history, undo/backtracking), the immutable version is going to be more efficient and definitely easier to write efficiently in the first place.

Flow• 9 years ago

But the state is likely a tree structure and there will be lots of sharing if coded right.

I think frameworks like React should explicitly demand that state and props will be referentially compared to optimize the rendering.

skariel123• 9 years ago

mutating in Rust is not like mutating in JS, Python, Java C# or many other languages. Rust tracks ownership, you always know who might mutate the object and when. It is a very unique experience programming Rust

kochthesecond5• 9 years ago

This might be more sane in Rust, I am not familiar with Rust.

I have used a lot of redux in js and written a few things in Elm, and the immutible property of application state is very central in both, and an important part of being able to reason with the ui, as well as events happening concurrently.

rbalicki2• 9 years ago

Returning a nextState in Redux/JS land is a workaround. Basically, one wants to avoid the situation where the state is mutated, but the framework does not know. This happens because there are multiple references to the state, and because, for performance reason, the framework is comparing the states based on referential (===) equality. Thus the view (in whole or in part) and the model can go out of sync. Always returning a new state object is an expensive way of ensuring this, but on the human time scales we're talking about, an insignificant cost.

On the other hand, in Rust, we have the compiler on our side. If one grabs a mutable reference to the state (&mut Model in the update function in https://github.com/DenisKolodin/yew/blob/master/examples/cou...), then the Rust compiler ensures that there are no other references to that Model. Thus, when the framework does `nextState = mutate(&currentState)`, one is guaranteed that there are no existing references to `&currentState`, and thus it is impossible for a shadow update to occur.

IMO, this is better not primarily for performance reasons, but because it is conceptually easier to mutate a state object instead of using reducers. (I haven't looked into this framework much, so I don't presume to speak about it's internal implementation, so this may be off in some framework-specific details.)

mlevental5• 9 years ago

in a nutshell this the counterargument to functional purity: side effects can be done correctly/safely when you have/build the right tools. i'm inclined to agree with it.

kochthesecond5• 9 years ago

Referential equality is possibly an optimization, and makes re-rendering efficiently at least simpler.

Debugging and rewind/replaying application state is also greatly simplified by keeping states immutable.

Having the state mutable would also need some kind of locking between the render view and updateState method

inglor• 9 years ago

FWIW, it's more of a "simplicity" choice - it is entirely possible to keep mutations reactive in React with libraries like MobX - it's just extra functionality that React doesn't ship out of the box but it works just fine without a borrow checker.

api• 9 years ago

So here's my Christmas present, and maybe an excuse to learn Rust. Ho ho ho!

mlevental5• 9 years ago

color me shocked: this is really a rust web framework (compiles to wasm). i was expecting a backend framework that supported react development on the frontend in some non-trivial way. wow. very cool.

but i thought wasm couldn't manipulate the dom? is that not the case anymore?

steveklabnik6• 9 years ago

Wasm can't directly, but it can call into JavaScript, which can. That's what this does.

DOM support for wasm really means native DOM support, which removes that layer of indirection, and therefore will make it faster.

mlevental5• 9 years ago

i was going to ask if DOM support is on the road map and this comment

https://news.ycombinator.com/item?id=13614886

claims it is but it's no longer in the high level goals in the spec link is dead... so do you know if it is?

pohl3• 9 years ago

It can through a thin bridge.

See https://github.com/koute/stdweb

mlevental5• 9 years ago

so how mature is this tech? is this really feasible? writing browser client code in rust?

013a• 9 years ago

Plus first class DOM support for wasm is coming at some point in the future, so I'd imagine any properly supported library could implement it once it is finalized.

tobyhinloopen• 9 years ago

WASM is just something that can run compiled code in the browser. You can communicate with the Javascript environment. You cannot access the JS libraries directly, but you can with thin bridges.

Using such bridges, you can create anything you can with Javascript in any language that compiles to webassembly.

carlosdp• 9 years ago

I was literally thinking "Maybe I should try using stdweb with React" last night. Awesome work, can't wait to use it/contribute!

fiatjaf3• 9 years ago

Coming next year: PHP apps that compile to WASM, so you can <?php ?> right in your HTML.

krapp• 9 years ago

Or, I bet, a WASM port of Arc and the default Arc forum.

aeleos• 9 years ago

When I saw the work being done with adding web assembly support to rust I though it was cool but I never really put much thought into how far it could be taken. Seeing projects like this is really great and makes me realize just how much room there is for using rust for web front ends. Given all the consideration for performance that the web has needed recently, I am excited to see what is possible with wasm and rust in the future.

Also, its amazing how fast this has popped up. Wasm was added to the compiler literally a month ago and already there is a standard library from dom manipulation and front-end frameworks. 2018 is definitely going to be interesting

MrBuddyCasino• 9 years ago

As the great cambric JS framework explosion fizzled out, only a few lucky survivors where left (angular/react/vue.js).

Little did they know that web-assembly was already scheming their demise.

jacobush• 9 years ago

I'd like to think it is more like when Oxygen entered the scene. Maybe we can never get rid of of Javascript, but like anaerobic bacteria, maybe it can stay put and out of sight under some rock.

sophiebits• 9 years ago

Don’t worry, we know.

murukesh_s• 9 years ago

Wondering if you are doing anything about it?

p.s asking as @spicyj is, from her profile, an "eng manager of React @ Facebook".

hokkos• 9 years ago

The counter demo is 9.4mb in amsjs and 1.5mb is wasm.

mkl• 9 years ago

Is this after running wasm-gc? https://www.hellorust.com/news/native-wasm-target.html

dethos• 9 years ago

This is awesome. Is one of things I was hoping to happen when I first heard about wasm.

Nothing against JavaScript, but I is nice that other languages can now be first class citizens on the web as well.

Dowwie• 9 years ago

Wanted: Full stack rust developer

bsaul• 9 years ago

Any update on wasm support for mobile platforms ?

whatever_dude• 9 years ago

Uh, it works? https://caniuse.com/#search=Webassembly

Remember you can also have a polyfill (at a performance cost when parsing).

patientplatypus2• 9 years ago

Maybe I don't get it, but why would I use this? What problem is it solving that insert JS framework isn't?

I understand JS is popular to hate, for a variety of reasons, but those reasons seem mostly to boil down to nerd cred. The "hate what's popular because being contrarian means I'm cool" crowd.

So, and this is an honest question here, why should I invest the time to learn an entirely new syntax for a framework to build web applications? What can this do that vue.js or react cannot? (And I don't mean it does it differently I'm looking for it does it better or JS framework doesn't do it.)

coldtea• 9 years ago

What can this do that vue.js or react cannot?

It allows you to write your web app in Rust.

And I don't mean it does it differently I'm looking for it does it better or JS framework doesn't do it.

"Better" depends on the use case, so merely by being different something might better fit another use case.

patientplatypus2• 9 years ago

Ok...is there a use case where Rust is better? This seems like you're punting. Why would I want to invest the time and energy to learn this?

justaaron• 9 years ago

I'd imagine that it's useful to be able to share a data context between a route-handler, for example, and it's rendered template and the embedded client side "scripting" that may be quite extensive these days.

("scripting" in quotes because of how rust embedded in the html templates can be so much more than logic-less templates- a bit like a server side template, the dom, and clientside javascript all in one- and I'm just guessing, but because it's not dynamic, but compiled, nonetheless safe even though logic is in there...)

unrealhoang• 9 years ago

Simply put, at the moment, you wouldn’t. But when wasm is mature enough (host binding to control DOM directly), there will be framework for 10x performance (compares to js’). This framework is a step toward that direction. Also it provides options for Rust programmers to not touching js. Totally worth it.

lmm3• 9 years ago

I understand JS is popular to hate, for a variety of reasons, but those reasons seem mostly to boil down to nerd cred. The "hate what's popular because being contrarian means I'm cool" crowd.

Then you're not paying attention. I'm not sure how you expect anyone to answer your "honest question" when you've already dismissed all the answers. It's not just fashion, programming language design is a real thing that it's possible to do badly or well, Javascript is a legitimately bad language, and Rust is a legitimately good language.

Learn Rust or another ML-family language, actually learn it to the point where you can write a decent, full-sized, idiomatic program in it. It won't be easy, but it's worth it. I mean, I could talk through all the reasons such languages are better, but it seems like you're already determined to dismiss them, so really the only way is to see for yourself.

_Tev5• 9 years ago

Javascript is a legitimately bad language, and Rust is a legitimately good language.

Yeah, statements like these without even trying to back them up are pretty ridiculous.

Sometimes someone brings some stupid issue that's never a problem in practice, but most of the time people just admit they simply have no real experience with JS. They just love to claim how superior they are, and anyone who disagrees is "not paying attention".

FYI you are just showing how awful are communities around "legitimately good" languages.

gytdev• 9 years ago

Javascript is a legitimately bad language, and Rust is a legitimately good language.

Could You elaborate?

tormeh• 9 years ago

The reason people like Rust more than JavaScript is that Rust is a better at what it tries to do than JavaScript is at what JavaScript tries to do. That said, they don't try to do the same thing, so you shouldn't use Rust in all situations. Rust is focused on speed, safety, and low bug count, but it's slow and annoying to write and refactor. If you are willing to make that trade-off then do; if not, then don't.

_Tev5• 9 years ago

Why is JS bad at "what it tries to do"? I've honestly not seen answer in these discussions, even though everyone acts like they are obvious.

From my experience main problems seem to be:

1) poor static analysis of code, leading to bad Intellisense etc. - Mostly solved by TypeScript.

2) DOM manipulation APIs. I don't see how Rust will help here. Especially considering JS frameworks solve this. I guess that's what's new in the OP.

Otherwise JS serves as pretty good language for beginners/UI wiring.

But thanks for at least describing some strengths (and weaknesses) of Rust when directly compared with JS.

qarioz• 9 years ago

Benchmark?

Yew: Rust framework for making React-like client web apps

Related Stories