Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Yew is production ready? #888

Closed
mezeipetister opened this issue Jan 21, 2020 · 8 comments
Closed

Yew is production ready? #888

mezeipetister opened this issue Jan 21, 2020 · 8 comments
Labels

Comments

@mezeipetister
Copy link
Contributor

Hi Guys!

Another Yew question: is Yew production ready?
I am planning to start using it in production to build up our internal e-commerce POS UI for our sales team.

We are using rust for the backend, and we would like to use a solution for a web GUI as well, with the same strong compiler quality guarantees.

Do you think Yew is production ready in terms of stability? We do not mind if features are missing, we can be creative on that way, but we strongly mind quality and stability.

Do you think using Yew we can have a 100% stable product, without any potential crash? - using all the Rust related best practices.

Thank you in advance.

@jstarry
Copy link
Member

jstarry commented Jan 21, 2020

Hey there,

Great question! It certainly isn't nearly as battle tested as other frameworks but I would venture to say it's pretty stable at this point. I think the biggest risk for crashes is browser compatibility. If your use-case only involves modern browsers used by an in-house sales team, then I think it's relatively low risk! If you had an external facing site for customers, that'd be a different story 😉

EDIT: Here's an existing issue that needs to be addressed soon for browser compatibility: #109

@jstarry
Copy link
Member

jstarry commented Jan 21, 2020

Please take a look at the Roadmap for info on what's coming up in the pipeline. Notably, we don't have any examples or guides for how to properly test a Yew app, for example. I would consider that a blocker for production readiness. But if you're willing blaze the trail for others, I wouldn't let the lack of that stop you. In fact, it would be great if you could come back with some learned best practices :)

@jstarry jstarry added question and removed bug labels Jan 21, 2020
@ctaggart
Copy link
Contributor

It all depends on the situation and your team's level of comfort with new tech like WebAssembly. I started working on an app that used Yew in August and published it earlier this month. Yew is a wonderful project and I highly recommend it, but there will be some growing pains. I'm very excited about the upcoming web-sys support. You have to keep the rustwasm tooling all in sync as it matures. It is easiest to match Yew's dependencies. I have to align wasm-bindgen, wasm-bindgen-cli, js-sys, web-sys, and wasm-pack. There is also a lack of tooling to use existing JavaScript APIs from Rust. A couple of years ago, I helped build ts2fable to allow importing TypeScript definitions for and Fable (F# to JavaScript compiler). I wish there was something like that for Rust.

For my day job, my corporate job, I would recommend Yew for some internally facing web app UIs where the develops skillsets match or that is the direction we wish to go.

@tracker1
Copy link

As others have mentioned, for internal apps, and if you're comfortable with the tooling, go for it.

I would consider a peer project with node+puppeteer+jest (or mocha, jasmine) for testing your workflows on a running app against a test api service. Mainly because imho puppeteer is about as nice a test framework combination as you're likely to see and puppeteer

@mezeipetister
Copy link
Contributor Author

Thank you guys!

@jetli
Copy link
Contributor

jetli commented Jan 22, 2020

Hi, I've got a repo here https://github.com/jetli/rust-yew-realworld-example-app, a sort of "real world" example for yew, you can check it out for evaluation purpose, it's not that complex, but relatively full featured as a simple medium clone.

It includes jwt token based authentication, api request, url routing, user sign up/sign in, user settings editing, article publishing by markdown, list/detail page, pagination, user profile page etc. And I used wasm-pack/npm/parcel tooling for packaging, not std-web/cargo-web, considering yew is moving to wasm-bindgen/web-sys. A demo site is here https://jetli.github.io/rust-yew-realworld-example-app/

I think yew is adequate to build a middle-sized site, quite stable to me and fun to code.

Other things I want to mention, .wasm file size could be quite large, 1MB+ size, might be a problem for first-time page loading, and rust code compiling is relatively slow, you can see a release build result on a MacBook Pro (Retina, 13-inch, Late 2013) here:

Built in 337.80s.

dist/conduit_wasm_bg.f7159332.wasm       1.39 MB       36ms
dist/static.9ecfc83f.js.map            130.55 KB       48ms
dist/static.9ecfc83f.js                 85.77 KB    338.57s
dist/favicon.d7052eb9.ico               22.68 KB      427ms
dist/Cargo.5dbf0375.toml                   824 B    330.99s
dist/index.html                            700 B      2.65s

@hgzimmerman
Copy link
Member

The only things I find Yew lacking is ecosystem and compile times, and we don't really know how it stacks up performance-wise against other frameworks at the moment.

There aren't a whole lot of packages that interoperate specifically with Yew, so that ends up meaning doing some work yourself that you otherwise wouldn't have to in another framework. That situation might improve over time though once v1.0.0 releases.

Also, once your project grows beyond a couple thousand lines/a few pages - compile times really take their toll on productivity. You can scrape some of that back by splitting your project up on a per-page basis inside a cargo workspace, but there is still a price to pay for using Rust in this context. The compiler is getting 1-2% faster every release and over time that compounds - but a lot of easy wins have already been had and that may eventually slow down.

For company-internal stuff, I say go for it, but I'd hold off for anything customer-facing.

@mezeipetister
Copy link
Contributor Author

Thank you guys for the info. They are quiet useful.

@jstarry jstarry closed this as completed Jan 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants