> What's the relevance of learning Rust for someone into web development?
Rust is a language that cares a lot about correctness. If I were particularly interested in making sure the code I wrote worked in production, Rust would be my first choice in the set of a dozen languages I know.
Rust is probably quite a bit faster than whatever you're using for web development. The normal counterpoint to this is that web requests tend to be rate limited by the database. This is mostly true but using Rust pretty much guarantees this will be the case. I believe that this point isn't that compelling with current architectures but would be worthwhile in a CQRS architecture where formatted data gets pushed/cached by the web servers and servicing requests stays on-machine.
Rust is one of the more compelling web assembly languages due to not needing a garbage collector. Demos exist but this is mostly in the exploratory stages.
Longer term, I expect Rust to have a unified async networking stack. You can do blocking IO networking in Rust but I expect most network clients/servers to be mostly async once the Tokio stack settles. This is all expected in node but the networking libraries tend to be fractured in most languages.
I don't think you should run out and switch over to Rust for general web development. There's going to be a big release in the fall that rolls up a bunch of ergonomic/convenience stuff that should make it easier to pick up and less annoying to use. I also think that IDE support will be important for a lot of people learning Rust. The situation is improving but the support is not up to par compared to more mature languages. All told, it's serviceable but I don't expect it to be particularly compelling as a web development language for at least another year or two.
As a web developer, you can write servers that take orders of magnitude less space, memory, and CPU than a similar JS server, without having to deal with the madness that is first-time C development.
This does look interesting. I don't see a difference between this and any other server-side templating language though. I actually need an isomorphic representation on the client and server. (this is what makes renderToString() valuable) I guess I could be extremely careful in writing the server output, and writing the client output to match, but at that point, I'd be writing it twice... and I could use any language... unfortunately, it'd probably end up being Handlebars.
It's for client side, not for server side. It's compiled into Wasm and delivered to client. You can use same code for server-side pre-rendering (for faster loading or for search engine indexing), but it is not main goal of Yew.
You should look at the all-F# SAFE Stack, then. It uses F# and .net core for the whole application and supports elm-style UI programming on the client side with react and server side rendering:
https://github.com/fable-compiler/fable-react/blob/master/do...
I'm not very familiar with the React ecosystem but I thought the entire point was letting the client-side handle rendering and passing structured data via API calls? renderToString() sounds like it's doing what every scripting language and templating framework has been doing for the past 20 years?
Look up server-side rendering in React. The major benefits are better/faster first page load experience and better SEO, especially for crawlers that don't have good JavaScript support. This way you can run the same code on the client or server depending on the circumstances.
The fringe benefit being I don't have to represent my app twice (once for server-side markup, the second for client-side JSX). As the size of any give app grows, keeping things in sync would be a nightmare.
We have an entire working group dedicated to looking at the end-to-end web story this year, both backend and front end. Things are still a bit rough, but coming along nicely. The next release of Rust includes a major language feature that’s helpful when writing asynchronous code (impl Trait), for example.
It gets you very close to native performance while running in your browser and browser sandbox. That's mind-blowing.
You'd still use JS for UI stuff, but WASM lets you run algorithmic or CPU intensive tasks like e.g. games, video decoding, image resizing, AI, or anything else you need fast performance for client-side.
There was a demo the other day of Rust outperforming JS for stuff JS usually does. Presumably this will continue to improve, so it won't even be a case of equivalent, it'll be a case of "thoroughly beats the pants off".
"Very close to native" means "much more efficient than JS", because JS is nowhere near native.
(Have we really gone so far that people hear "native" and think of the browser? Like the web browser is the machine we target, and not the metal box the end user purchased?)
Is it pretty easy to write C++ extensions to V8? I've seen a couple of projects of that sort. I wonder if they're relatively difficult, and if that's perhaps why the push for WebAssembly has been so strong.
Mostly it lets you not use JavaScript, which you may or may not be excited about, depending on how much you think the problem with web development is JS.
There are plenty of languages that compile to JavaScript. They don't save you from having to interface with the DOM and other JavaScript APIs, but neither does WebAssembly (which currently has no such capabilities at all, save through JavaScript FFI).
You can run code written in a language you are comfortable with and run web code really, really fast. It's not an "either JS or WebAssembly", they can work together. Worth reading up on if you are interested - https://developer.mozilla.org/en-US/docs/WebAssembly
Rust is a language that cares a lot about correctness. If I were particularly interested in making sure the code I wrote worked in production, Rust would be my first choice in the set of a dozen languages I know.
Rust is probably quite a bit faster than whatever you're using for web development. The normal counterpoint to this is that web requests tend to be rate limited by the database. This is mostly true but using Rust pretty much guarantees this will be the case. I believe that this point isn't that compelling with current architectures but would be worthwhile in a CQRS architecture where formatted data gets pushed/cached by the web servers and servicing requests stays on-machine.
Rust is one of the more compelling web assembly languages due to not needing a garbage collector. Demos exist but this is mostly in the exploratory stages.
Longer term, I expect Rust to have a unified async networking stack. You can do blocking IO networking in Rust but I expect most network clients/servers to be mostly async once the Tokio stack settles. This is all expected in node but the networking libraries tend to be fractured in most languages.
I don't think you should run out and switch over to Rust for general web development. There's going to be a big release in the fall that rolls up a bunch of ergonomic/convenience stuff that should make it easier to pick up and less annoying to use. I also think that IDE support will be important for a lot of people learning Rust. The situation is improving but the support is not up to par compared to more mature languages. All told, it's serviceable but I don't expect it to be particularly compelling as a web development language for at least another year or two.