Building an agtech platform (with quite a few other people, including a designer and data scientist, but I'm currently the sole developer, and for the most part it was built by a single developer).
Backend: Rust, rocket, sqlx, postgres + a little bit of R. Ansible for deployment.
Frontend: Rescript + React. Also a significant portion of Rust/WASM, but that was a mistake I'm trying to undo.
It's not easy to separate WASM specifically from Rust, and also hard to separate Rust from seed-rs, the UI framework we're using. But as far as problems with all of them together, here's the major ones:
- Very slow compilation times. A medium-sized app can take 30s to build incrementally on a fast desktop computer. And that's just way too slow for front-end development where fast iteration is key. In comparison, Rescript takes maybe a few hundred milliseconds on an app that's about the same size.
- Poor abstraction mechanisms, for making reusable and configurable components with more than a few properties, some being required and some being optional. The common Rust solution for this is the "builder" pattern, which is very verbose to implement, and still quite awkward if you have more than a few required properties.
- Poor debugging ability. WASM is opaque and there's no debugger for it as far as I know. The stack traces you get from Rust is also very noisy and imprecise. You basically only get the function name, and have to search for it in a big noisy stack trace. And because of inlining the problem might not actually even be in that function. Also, when a panic happens the app just freezes. There's probably some way of intercepting and overriding this behaviour, but by default it's quite bad UX.
- The cognitive overhead of manual memory management. Fighting the borrow checker and having to always think about who owns what and what strategy to use to manage data ownership is just completely unnecessary for most front-end development. Most of the time the app is just waiting for an event to happen, and when something does happen the processing needed tends to be dwarfed by the time spent by the browser to update and render the DOM.
- Large bundle size. Because you tend to use native Rust libraries instead of binding to non-idiomatic and often poorly designed browser APIs.
- Somewhat poor browser support? We've had some issues with the app simply failing to load after a new version is deployed, and having to clear the browser cache in order to fix it. We've yet to reproduce this reliably and therefore still haven't been able to track down why it happens.
See the reply to parent. For a hobby project I think it's an interesting experience to try. Especially if you also intend to write a back-end in Rust. But for production use, and productivity in general, I don't think it's close to ready.
I find Rescript to be much more enjoyable for both hobby and production use. If you're looking for a front-end language that is quite similar to Rust, just without the manual memory management :)
What are we supposed to be competing for? Reason is a tool that makes different trade-offs than some other tools. These trade-offs might work for you or they might not. It all depends on what YOU actually need.
I think what @chenglou was referring to are issues like the "value restriction" [1] and the need to wrap "uncurried" FFI functions with a function that "adapts" it to curried form, thereby adding a layer of indirection.
Reason does not solve these, they're problems inherent to the underlying language and the choices made. I think the point being made was just that currying isn't a clear step forward, but causes some problems as well.
Yeah, definitely agree that there are trade-offs with currying when mapping it to a compilation target like JS, and I am consistently impressed by Bucklescipt's ability to convert the curried versions of functions to regular JS calls. That said, I do still think that it's worth the trouble!
Please stop the fanboyism. OP did not say there was anything wrong with Vue, but asked if there was any specific reason it was chosen, and suggested they try something that comes with good preconfigured defaults to avoid being overwhelmed by all the choices. Which you completely fail to address in your canned sales pitch.
What are you on about? I cited two specific reasons: the excellent documentation and easy syntax which made the learning process go very smoothly. You seem to be doing exactly what you accused me of doing. Are you suggesting that React and Angular both have "good preconfigured defaults" and Vue does not?
Being overwhelmed by all the choices is a valid concern which is why I find it strange for you to be suggesting OP switches to another framework when he has already started with Vue.
Recently I have created few tutorials on Vue.js. I comes from Angular JS 1 and 2 background. After few days of Vue.js, it seems very simple to begin with you.
If you are planning to build a side project, or dashboard kind of stuff so you can definitely give it a try. I feel it's like jquery :) little bit more concept to grasp.
Few video tutorials I am creating, you can watch and leave your comments:-
But you could have safely skipped the "first!" comment. Being first does not make you any more superior in the front-end world than it does in a youtube comment.
I couldn't help it, I'm sorry ;-). Although there is a point that Evan You has put a lot of effort into finessing the "developer experience" of using Vue. That includes vue-cli, "blessed" packages surrounding the main library (e.g. Vuex), being able to start using a script tag include if that's easiest, and clear documentation.
My "getting started" experience with React (which I use every day) was much more rocky. Admittedly this predates create-react-app.
He does suggest a solution, it's just not an easy one. But it is simple: Organize and get shit done. He often uses the womens liberation movement, civil rights movement and anti-vietnam-war movement as historical examples. There's still work to be done, and it takes a lot of effort and a long time to get anywhere, but we continue to progress towards the better.
Backend: Rust, rocket, sqlx, postgres + a little bit of R. Ansible for deployment.
Frontend: Rescript + React. Also a significant portion of Rust/WASM, but that was a mistake I'm trying to undo.
In short, statically typed and functional(-ish).