While it's just part one, I feel like whether the end result successfully overcomes the problems mentioned is missing. I wonder if in fact it does.<p>Personally I wouldn't refactor an entire application from scratch unless it was fairly simple. Instead I prefer incremental refactoring and I've found that typescript can be helpful in that regard.
Interesting take, but there is no indication that the new Rust-based stack will be « less expensive » to maintain than the current one. I am curious to see the next posts in the series. I would also like to know if they considered other alternatives; they mention Elm, what about TypeScript. The issues they mention seem to also have to do with the specific choice of frameworks or tools: React, Webpack, etc. Not so much with JavaScript itself?
While I love Rust, I don't think this here is a good use case for it - TypeScript nowadays works really well with JSX and can be introduced incrementally.<p>Rust's guarantees work best in a highly concurrent setting - a web app isn't really one.<p>Rust shines not on the application level, but on the framework/library level, where things like memory usage and performance are critical.<p>A framework with virtual DOM written entirely in Rust would go a long way. Same with a template compiler.
<a href="https://www.youtube.com/watch?v=kY-pUxKQMUE" rel="nofollow">https://www.youtube.com/watch?v=kY-pUxKQMUE</a><p>seriously though, i’ve been very interested to see how webassembly adoption goes. does anyone have examples of new projects implemented in webassembly? i’ve seen lots of examples of ports, but am more curious about its use in product development.
Sounds like typescript and angular would be a better fit here.<p>Angular is "batteries included" compared to react, so you generally won't hit the same dependency hell since angular comes with pretty much everything you need (although not redux pattern support (yet)). Typescript is a strictly-typed JavaScript.<p>Reprogramming a web front end in rust sounds like a way to lead to huge maintenance issues in the future (i.e. you need to find developers who know rust AND how frontends and things like redux actually work - you'll probably get someone who is good at one, and half-assed at the other). I am also uncertain how you'd debug things in the browser for wasm - e.g. would the redux Dev tools work?<p>Where I see wasm as useful is if you are doing any heavy-lifting in the browser - so all the examples they give on the various web sites about games and cryptography etc, but probably also parsing/serialisation of binary data from the server for example. I don't feel like basic SPA stuff is a good fit.
While Rust is a very cool technology, I don't think it is the best tool for web development. Manual memory management and constant thinking about ownership and memory sharing is additional productivity overhead, and you don't gain anything from it because the final code is running in a GCed runtime anyways.<p>I'd use TypeScript or Scala.js.
This seems like a solution looking for a problem but cool to see. A far more practical suggestion would be to just use typescript and incrementally rewrite.
> Maintaining Software that is written in a dynamically typed language like JavaScript is costly. Maintaining a JavaScript frontend that is build with React, NPM, WebPack and Babel is even more expensive.<p>Not exactly. In modern browsers JavaScript executes in a VM. If the JavaScript instance is written in a strongly typed way it executes quickly by receiving the full benefits of a compiled language. Aside from arithmetic it executes almost as fast as Java. That is one of the strengths of TypeScript.<p>I do completely agree about NPM, dependency overkill, and framework insanity.<p>In short, don’t blame the language for being slow. Blame marketing and bad developers. That being said I have little faith that WASM will be fast once it meets the reality of bad developers and marketing teams.