16 ms·

Can Rust Beat JavaScript in 2023?

74 points by stmblast 3y ago

gpmcadam 3y ago
no
tgv 3y ago
The speed of manipulating tables isn't a great benchmark (IMO), but I am surprised to see that Rust for browser frontend has come that far.
worldsavior 3y ago
No
bitlax 3y ago
"Question in Title" rule.
- Alifatisk 3y ago
  Betteridge's law of headlines
ianpurton 3y ago
One of the libraries from the article which I have experience with is https://dioxuslabs.com/ https://dioxuslabs.com/ It has a server side rendering mode, which for most projects will be all you need. So then if you follow the Islands Architecture https://www.patterns.dev/posts/islands-architecture https://www.patterns.dev/posts/islands-architecture means you can sprinkle some typescript when you need more dynamic functionality. I'd love to use Rust for front end enhancement in this way, but the problem is you have to completely open up your content security policy https://github.com/WebAssembly/content-security-policy/blob/main/proposals/CSP.md https://github.com/WebAssembly/content-security-policy/blob/... Which is going to get picked up in any security review. I've written up how I develop web apps with rust here https://rust-on-nails.com/ https://rust-on-nails.com/
- noobdev9000 3y ago
  Have you or anyone else how to organize and test a Rust web application that is structured around usual onion layer using DDD or similar?
  - ianpurton 3y ago
    I mainly test with a combination of unit tests and using selenium https://github.com/stevepryde/thirtyfour https://github.com/stevepryde/thirtyfour for integration tests I wrote it up here https://rust-on-nails.com/docs/continuous-integration/integration-testing/ https://rust-on-nails.com/docs/continuous-integration/integr...
Etheryte 3y ago
It's interesting to see Rust get up to speed in this realm, however I can't help but feel that so far, it's largely what I would call academically interesting. If I want to start a web project, I can hire a team of developers who know Javascript and its frameworks today. If some of them leave, I can rotate in other people with ease. Of course, this is a chicken and an egg problem, but for the time being it feels like a hard sell.
- deleted 3y ago
  [deleted]
pdpi 3y ago
Greg Johnston, author of the Leptos framework, did a pretty good video about this a few weeks ago[0]. The TLDR is (of course): it depends. WASM has no native access to the DOM, so all DOM manipulations from wasm-land have to go through JS bindings with all the (de)serialisation costs that go with crossing the language boundary. That eats up a lot of whatever performance gains you'd see from rust-on-wasm for pure compute. 0. https://www.youtube.com/watch?v=4KtotxNAwME https://www.youtube.com/watch?v=4KtotxNAwME
muglug 3y ago
Every so often a language comes out that allows frontend developers to put something other than "JavaScript developer" on their CV. First CoffeeScript, then Flow and TypeScript, then ReasonML, and now Rust with WASM & web macros. Of these only TypeScript has been successful, partly because it's backed by Microsoft, but mostly because the code you end up writing is very close to JavaScript. This is not a dig at Rust (which I love) but God help any developer inheriting a frontend codebase with random bits of Rust in 2024.
- VWWHFSfQ 3y ago
  My company did an initial evaluation of Rust web development just to see what the options were. Put out some feelers to our web developers to see if they had any opinions about it. It was almost universally negative. Not because the ecosystem or technology is immature, but because our JavaScript/Typescript devs simply could not grok Rust at all. It was too different, or too difficult, or whatever. So we didn't really pursue it any further. At some point though we'll probably just have to hire Rust engineers instead of trying to convert JS devs.
  - bayesian_horse 3y ago
    Rust engineers coming from a different niche than frontend development will just LOVE web development.
    - voidfunc 3y ago
      Maybe the web ecosystem will finally get some sane tooling... or not because those devs will probably be driven to madness.
      - illiarian 3y ago
        Funnily enough, web ecosystem has tooling most languages can't even dream of. - Instant hot reload of application - Inspect app/page structure in runtime - Runtime debugging - Monitor all network requests - Tools to monitor time spent in functions, painting, redrawing... - Runtime changes instantly applied ...
andybak 3y ago
Does anyone remember when the trend was towards expressivity in languages? At th time that meant dynamically typed languages like Ruby and Python. The pendulum has swung away from dynamic typing but are we sometimes sacrificing expressivity as a result? I don't really know Rust but from what I've seen of it, it doesn't feel like a natural fit for the web - either front or back-end. Maybe I'm missing something?
- KingOfCoders 3y ago
  After some years chasing exprssivity with Typescript and Scala, I now really enjoy the dumb simplicity of Go. I do think we'll see more simplicity (not Lisp-like) in the future.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- qtzaz 3y ago
  Personally, I expected dynamic languages to ever match or at least get close to the performance of static languages. That seems that it will never happen, and there's a point where I can't afford that much hardware just to run a website. Think of Twitter abandoning RoR, etc.
  - andybak 3y ago
    Several dynamic languages are faster than some static languages depending who you talk to. LuaJIT is famously fast and Javascript is no slouch
- bayesian_horse 3y ago
  Both Python and Javascript are eating Rust's lunch in terms of popularity. And Typescript is just a typechecker, it's still a very dynamically typed language/runtime underneath. Especially with Rust you have to think way more about banalities of the data model you normally really don't care about in web development.
xyzzy4747 3y ago
Rust is a great language until you want to hire someone to improve your code. Most developers aren’t familiar with it unfortunately and it would take some time to bring a new person up to speed.
- pdimitar 3y ago
  <raises hand> I can. I'm surprised this has been your experience. I've known some pretty strong Rust devs.
  - bayesian_horse 3y ago
    When you want to hire them, you'll have to compete (especially in salary) with employers who need them for something Rust is actually very well suited for.
    - pdimitar 3y ago
      Ah, not wrong, things are like that currently indeed. But IMO the Rust dev salaries are a bubble that's about to pop. Personally I'm ready to work with Rust at less than the crazy salaries that are offered (though I'd still expect more than the average JS dev salary).
- ModernMech 3y ago
  Why don't you just hire someone who does know Rust? They're out there, and there's more every day.
- deleted 3y ago
  [deleted]
alvarlaigna 3y ago
I'm confident its not about beating anything. Its about great building blocks for web and healthy competition is vital or both to succeed.
duxup 3y ago
So let's say I'm building a webapp. Why would i want to choose Rust? "Speed" and "not requiring as much of a memory footprint as well as more service uptime with less crashes". I dunno man. I'm not saying those aren't interesting but I'm not sure that when it comes to web development that those are big hang ups. There's got to be something more compelling IMO before you swing away from a fairly rich and frankly developer rich pool in JavaScript land... Granted I enjoyed the article and my interest is piqued but that's it.
- govolckurself 3y ago
  The biggest bottleneck in web applications was, is, and ever shall be, roundtrip time to the database, especially now that nobody bothers to install MySQL on the same box anymore, so every query has to go over the network. Of course, that's in a sane web application. Trendier approaches also try to shovel 10 MB of JavaScript over the wire first, so you can then call your API (which is slow for other reasons), and then render the result (which is also slow because you've shoveled 10 MB of JavaScript into the user's browser). The language you choose matters relatively little.
  - jeroenhd 3y ago
    I disagree, those 10MB of JS easily become 40MB of WASM. Picking a language that's compiled to Javascript for frontend code is the only good choice IMO. WASM is not unlike the JARs and SWFs we got shoved down our throat ten years ago when HTML and JS were lacking any useful web capabilities. Huge files with separate runtime that implement their own renderer and operating environment. Google Docs already does this, using a canvas element to render to rather than using HTML and CSS to lay out text.
    - madeofpalk 3y ago
      > using a canvas element to render to rather than using HTML and CSS to lay out text. That is independent to whether WASM is being used or not. Two completely orthogonal concerns.
rwalle 3y ago
> As you can see, the code is really not that far off from something like JSX I'm sorry, no.
kykeonaut 3y ago
I think the right approach would be to work with WASM in the same way that we work with GPGPU programming: write most of the code with JS/TS and write only the computation intensive tasks with Rust/WASM.
robertlagrant 3y ago
Can Rust beat Javascript without becoming Javascript[0]? [0] https://docs.rs/left-pad/latest/left_pad https://docs.rs/left-pad/latest/left_pad
- Aissen 3y ago
  Sure: https://crates.io/crates/left-pad/reverse_dependencies https://crates.io/crates/left-pad/reverse_dependencies https://www.npmjs.com/package/left-pad?activeTab=dependents https://www.npmjs.com/package/left-pad?activeTab=dependents
- marcosdumay 3y ago
  I am pretty sure this is a joke crater.
rwalle 3y ago
Engineering is a matter of tradeoffs. With JavaScript, you get simplicity but lose strict typing (can be compensated with TypeScript), performance etc. Rust gives you much better performance but is more complicated to write. However, for a lot of the websites out there, especially those that are not e-commerce or provide creative tools (e.g. Figma) and do not care that much about page performance, the potential performance gain from rewriting JavaScript code in Rust is not visible enough to end users. Of course there are bad websites out there that are slow, but it is often more about CDN/backend servers/the UI code itself rather than the JavaScript language. In other words, many websites are "fast enough", and most CTOs, product managers and developers would rather use JavaScript/TypeScript and release more features rather than write Rust, in the real world. Same thing for a Rust replacement for VSCode -- I am sure it is an interesting project, but VSCode performance is generally good enough (I don't ever complain about slowness while developing). A lot of the performance bottleneck comes from the language services anyway. If you improve the loading speed from 2s to .2s that is definitely great, but if at the cost of losing most of the existing extensions, I'm not going to consider it at all.
- MuffinFlavored 3y ago
  To me it's like a curve. Yes you can technically maybe get off the ground more quickly up front with JavaScript, but as soon as you hit a certain code base size threshold (not sure what it is personally, it is probably different case by case), you would've been better off with TypeScript or Rust as JavaScript starts to "crumble" under its own lack of types, etc.
  - Ygg2 3y ago
    JavaScript depends on use case but around 10-100k lines (or when node_modules reaches 3GiB) it gets gnarly. JavaScript is like Legos, durable and you can build many things in it.
    - kaba0 3y ago
      The analogy works, you may also step on it bare foot :D
billconan 3y ago
I’d love to use rust for the frontend, but some of the important dependences I need are still in js. How does rust call them?
cabirum 3y ago
Okay, if we only care about render performance, rust/webasm is kind of comparable to native js frameworks. Now: What is compile times for real-world medium to large projects? Do these even exist? Rust is infamous for its compile times, and frontend dev often requires live reload on every change. What does debugging look like? Can I set a breakpoint in rust code in my IDE? What do I see in browser devtools? Can I change values in my paused code at runtime, then resume execution?
- jeroenhd 3y ago
  I don't know how much the Rust dev tools have advanced for browser debuggers specifically, but source code maps allow just about any language to be debugged through the standard browser debugger. You're limited by the browser debugger of course (no time traveling debugger like in real Visual Studio) but it works well enough that it felt like debugging Javascript. This article from 2½ years ago shows what was already possible back then when you're debugging C++: https://developer.chrome.com/blog/wasm-debugging-2020/ https://developer.chrome.com/blog/wasm-debugging-2020/ Rust build times are huge at first, especially if you haven't downloaded any dependencies before, (comparable to running npm install) but incremental compilation makes small code changes very quick and easy. Having worked on a Javascript code base that's grown over a few years, I don't believe Javascript is any faster than Rust when it comes to compilation/transcription/packaging, especially when you need to add a layer like TypeScript between your tools and yourself if you don't want to go insane with JS' lack of typing. I wouldn't use Rust for a browser frontend, but I don't think the lack of tooling is a very good reason not to. The massive size of WASM binaries, the overhead, the lack of transparency, and all the other problems are, though. I'd stick with Rust on the backend instead.
misja111 3y ago
"If your newest tool is a hammer, every problem looks like a nail." There is hardly any language that doesn't have some kind of meta language that compiles to JS. And without exception they all are bad, except maybe if you have a backend which only needs some very basic front end which you prefer to write in the same language. But with any decent sized front end project, JS or TS are the better choices. JS, obviously, because it runs natively in the browser. So all browser tooling works out of the box, debugging is easy because what you see is what actually runs. TS, although it doesn't run natively, at least was designed to be compiled to JS and is widely supported so tooling is good as well. But any JS substitute that was added to a backend language as an afterthought will suffer: - inferior tooling - more troublesome debugging - and last but not least, because it was added as an afterthought, 95% of the language will work fine but the other 5% can give you as a developer serious head aches.
maeln 3y ago
I really, really can't wait for the extension to WASM to allow it direct access to the DOM and finally be able to remove the need for JS for 99% of its usage. I do a lot of frontend development and I just cannot fathom how badly design JS as a language is and how awful the developer experience is. Every time I talk about JS shortcoming with other frontend dev, they point out that JS can do X or Y which other language cannot, but usually it is just a hack that are just not needed in other language because they actually do things properly (like having an actual sane type system and not having three ways to express that a variable is null). And TS is just a crutch that can barely help JS shortcoming. Finally being able to compile from any language to a, reasonably sane, bytecode that can run in-place of JS is just a miracle and I don't understand why it took so damn long. JS should have been deprecated long ago. Even ActionScript was better. Anyway, rant over.
- madeofpalk 3y ago
  > and how awful the developer experience is. Can you put breakpoints in WASM and debug frontend code?
  - jeroenhd 3y ago
    Yes, source map generation for modern languages has existed for a few years now. You can debug Rust/C++/Go straight from your browser's dev tools. Altering memory is more complicated, though.
- jeroenhd 3y ago
  JS can do some things very well that others can't. Prototype based reflection is very powerful! Its problem is that the things Javascript excels at aren't all that useful, and the things it's bad at are often sold as features instead ("duck typing means I can iterate faster!").
- marcosdumay 3y ago
  > to allow it direct access to the DOM Hum... Direct calling the DOM API is there already. You may be thinking about FFI marshaling, that there is something on the pipeline for helping (I don't even remember exactly what). But that's only a small improvement on speed, and that almost never is a dealbreaker. For a while I thought the garbage collection helper was a dealbreaker (for anything except Rust), but GC languages are starting to compile into WASM too, with just a small performance hit. (I haven't looked exactly how.) This year and the next are looking like some serious promising period for non-JS programing on the browser.
javajosh 3y ago
In my view, JS is preferable because you are forced to ship source to the client. This provides a beneficial atmosphere for learning and sharing solutions. Compiling to WASM, and front-end builds in general, take this critical and unique quality away from the web platform. Rust-to-WASM is another attempt to abstract away the pain of JavaScript, attempts which began soon after the world discovered XHR. In fact Google released GWT specifically to appeal to Java devs who took one look at JS and said "no thanks". This is not so say that there aren't legit uses for this technology - its a great way to port other software, like sqlite or linux into the browser. But as a way to make applications designed to run on the web? I suggest that any dev that thinks this is necessary to have a good dev experience take the time to attempt to write a web app with just raw html, css, and js targeted at a modern browser. There's a lot of space there left to explore, I think, before labeling it as an unwieldy thing that must be wrapped in a safer abstraction to even think of touching.
- VWWHFSfQ 3y ago
  > you are forced to ship source to the client. This provides a beneficial atmosphere for learning and sharing solutions. This hasn't really been true anymore for quite a long time. Pretty much everything is bundled, minimized, and obfuscated now.
  - ModernMech 3y ago
    But it's still source, no?
    - VWWHFSfQ 3y ago
      Maybe by some legal definition. But I don't think most people would consider it source code anymore.
    - govolckurself 3y ago
      This is the weirdest gotcha. Nobody said it wasn't source anymore, they implied that it wouldn't be readable or conducive to sharing because it's unreadable.
JoeOfTexas 3y ago
Sure, if you want to go backwards. JavaScript was created and persisted because it solved a problem that C++, Java, and to some extent PHP, had of being overly verbose. While the idea is novel, it is not business practical.
- jeroenhd 3y ago
  JavaScript was created in a rush because a web browser in the 90s needed to do some basic form handling and user interaction. It's Java but with silly names, stupid scoping, a unique prototype system nobody seems to get down, a strong influence from the worst years of Microsoft, and a legacy that forces it to make some pretty stupid choices moving forward. It's incredible what browsers have been able to make Javascript do, but it's not exactly a well-designed language. As for being business practical, WASM is already widely employed by web apps. The front end ecosystem is in its early stages so it's quite messy, but it's developing faster than I expected. It may end up being a real competitor for frameworks like Blazor and ASP.NET if it the tooling continues to improve like this.
  - kaba0 3y ago
    It’s not Java, it’s more like a badly designed LISP in Java/C syntax, which in itself makes all the advantages of LISPs go out the window.
- kaba0 3y ago
  It didn’t solve any problem, it was politics.
willio58 3y ago
I want to be interested in Rust, but then I see a line of code like this in the post: let decrement = move |_| set_value.update(|value| *value -= 1); Maybe I've lost that interest I once had in learning language syntax.. I just don't really understand this intuitively and the barrier to understanding this line feels unnecessary. When I compare Rust with JS/TS, Python, or even Swift I feel like those other languages are created in a way that's easy to pick up and transfer knowledge from other languages, then the deeper parts of the language are easily accessible once you're introduced to the basics.
- duped 3y ago
  I mean compare to using arrow functions and it's almost identical let decrement = () => set_value.update((value) => value -1); The difference is that Rust isn't garbage collected and has reference value semantics, which is where the *value -= 1 comes in.
  - willio58 3y ago
    It's funny, I almost noted that arrow functions are a definite oddity of JS that I could see people thrown off by.
    - marcosdumay 3y ago
      > oddity of JS I can't think on any modern language that lacks some short syntax for lambdas. Hell, it's very easy to make a point that lacking short syntax for lambdas make a language not modern and unusable for our current standards.
      - willio58 3y ago
        I'm a little confused what you mean by JS lacking a short syntax for lambdas. let multiply = (a, b) => a * b; Is this not a lambda?
        kaba0 3y ago
zerocall__ 3y ago
Why not both? API Gateway + Lambda/OpenFaaS/Knative with rust handlers (low RAM/fast start), and typescript/react served via CDN. with serverless platforms, it honestly matters not what language. Rust is just a convenience for compiling to arm for gravitron and low memory footprint. Languages that carry runtime bloat are less desired though for cloud functions.
lucasyvas 3y ago
If there was a superset of Rust where everything was transparently reference counted, every data structure could hold mixed types easily, and closures were dead simple, then maybe. These are things that are, IMO, just too engrained as being possible in JS/TS for people to give up easily, especially in terms of UI programming. I've used both quite a bit - I am pulling for Rust to become more ergonomic for this use case where it makes sense because it has lots of other advantages. But when the rubber hits the road and you start writing, I think Rust gets in the way too much for UI programming. For a small project it may be OK, but in most orgs you have sweeping design changes occurring (probably too) often. Rust is best when things have stopped churning and stabilize. UI code often churns like a relentless beast, so something extremely approachable/flexible but strongly typed is best I think. This is why TypeScript is winning in this arena. I'm optimistic headway will be made, but Rust currently feels a lot better to write for back-end and systems. It's not a surprise since that's what it was designed for. Besides all this, I'm totally unsure where the size of the distributable comes in. In JS things can be chunked per page easily which keeps load times small. With WASM you get the whole thing by default, correct? That could be problematic.
doctor_phil 3y ago
This link is dead now. It seems to have been replaced by https://joshmo.bearblog.dev/can-rust-beat-javascript-in-2023/ https://joshmo.bearblog.dev/can-rust-beat-javascript-in-2023...

74 points by stmblast 3y ago

tgv 3y ago

The speed of manipulating tables isn't a great benchmark (IMO), but I am surprised to see that Rust for browser frontend has come that far.

worldsavior 3y ago

bitlax 3y ago

"Question in Title" rule.

Alifatisk 3y ago
Betteridge's law of headlines

ianpurton 3y ago

One of the libraries from the article which I have experience with is https://dioxuslabs.com/ https://dioxuslabs.com/ It has a server side rendering mode, which for most projects will be all you need. So then if you follow the Islands Architecture https://www.patterns.dev/posts/islands-architecture https://www.patterns.dev/posts/islands-architecture means you can sprinkle some typescript when you need more dynamic functionality. I'd love to use Rust for front end enhancement in this way, but the problem is you have to completely open up your content security policy https://github.com/WebAssembly/content-security-policy/blob/main/proposals/CSP.md https://github.com/WebAssembly/content-security-policy/blob/... Which is going to get picked up in any security review. I've written up how I develop web apps with rust here https://rust-on-nails.com/ https://rust-on-nails.com/

noobdev9000 3y ago
Have you or anyone else how to organize and test a Rust web application that is structured around usual onion layer using DDD or similar?
- ianpurton 3y ago
  I mainly test with a combination of unit tests and using selenium https://github.com/stevepryde/thirtyfour https://github.com/stevepryde/thirtyfour for integration tests I wrote it up here https://rust-on-nails.com/docs/continuous-integration/integration-testing/ https://rust-on-nails.com/docs/continuous-integration/integr...

Etheryte 3y ago

It's interesting to see Rust get up to speed in this realm, however I can't help but feel that so far, it's largely what I would call academically interesting. If I want to start a web project, I can hire a team of developers who know Javascript and its frameworks today. If some of them leave, I can rotate in other people with ease. Of course, this is a chicken and an egg problem, but for the time being it feels like a hard sell.

deleted 3y ago
[deleted]

pdpi 3y ago

Greg Johnston, author of the Leptos framework, did a pretty good video about this a few weeks ago[0]. The TLDR is (of course): it depends. WASM has no native access to the DOM, so all DOM manipulations from wasm-land have to go through JS bindings with all the (de)serialisation costs that go with crossing the language boundary. That eats up a lot of whatever performance gains you'd see from rust-on-wasm for pure compute. 0. https://www.youtube.com/watch?v=4KtotxNAwME https://www.youtube.com/watch?v=4KtotxNAwME

muglug 3y ago

Every so often a language comes out that allows frontend developers to put something other than "JavaScript developer" on their CV. First CoffeeScript, then Flow and TypeScript, then ReasonML, and now Rust with WASM & web macros. Of these only TypeScript has been successful, partly because it's backed by Microsoft, but mostly because the code you end up writing is very close to JavaScript. This is not a dig at Rust (which I love) but God help any developer inheriting a frontend codebase with random bits of Rust in 2024.

VWWHFSfQ 3y ago
My company did an initial evaluation of Rust web development just to see what the options were. Put out some feelers to our web developers to see if they had any opinions about it. It was almost universally negative. Not because the ecosystem or technology is immature, but because our JavaScript/Typescript devs simply could not grok Rust at all. It was too different, or too difficult, or whatever. So we didn't really pursue it any further. At some point though we'll probably just have to hire Rust engineers instead of trying to convert JS devs.
- bayesian_horse 3y ago
  Rust engineers coming from a different niche than frontend development will just LOVE web development.
  - voidfunc 3y ago
    Maybe the web ecosystem will finally get some sane tooling... or not because those devs will probably be driven to madness.
    - illiarian 3y ago
      Funnily enough, web ecosystem has tooling most languages can't even dream of. - Instant hot reload of application - Inspect app/page structure in runtime - Runtime debugging - Monitor all network requests - Tools to monitor time spent in functions, painting, redrawing... - Runtime changes instantly applied ...

andybak 3y ago

Does anyone remember when the trend was towards expressivity in languages? At th time that meant dynamically typed languages like Ruby and Python. The pendulum has swung away from dynamic typing but are we sometimes sacrificing expressivity as a result? I don't really know Rust but from what I've seen of it, it doesn't feel like a natural fit for the web - either front or back-end. Maybe I'm missing something?

KingOfCoders 3y ago
After some years chasing exprssivity with Typescript and Scala, I now really enjoy the dumb simplicity of Go. I do think we'll see more simplicity (not Lisp-like) in the future.
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
qtzaz 3y ago
Personally, I expected dynamic languages to ever match or at least get close to the performance of static languages. That seems that it will never happen, and there's a point where I can't afford that much hardware just to run a website. Think of Twitter abandoning RoR, etc.
- andybak 3y ago
  Several dynamic languages are faster than some static languages depending who you talk to. LuaJIT is famously fast and Javascript is no slouch
bayesian_horse 3y ago
Both Python and Javascript are eating Rust's lunch in terms of popularity. And Typescript is just a typechecker, it's still a very dynamically typed language/runtime underneath. Especially with Rust you have to think way more about banalities of the data model you normally really don't care about in web development.

xyzzy4747 3y ago

Rust is a great language until you want to hire someone to improve your code. Most developers aren’t familiar with it unfortunately and it would take some time to bring a new person up to speed.

pdimitar 3y ago
<raises hand> I can. I'm surprised this has been your experience. I've known some pretty strong Rust devs.
- bayesian_horse 3y ago
  When you want to hire them, you'll have to compete (especially in salary) with employers who need them for something Rust is actually very well suited for.
  - pdimitar 3y ago
    Ah, not wrong, things are like that currently indeed. But IMO the Rust dev salaries are a bubble that's about to pop. Personally I'm ready to work with Rust at less than the crazy salaries that are offered (though I'd still expect more than the average JS dev salary).
ModernMech 3y ago
Why don't you just hire someone who does know Rust? They're out there, and there's more every day.
deleted 3y ago
[deleted]

alvarlaigna 3y ago

I'm confident its not about beating anything. Its about great building blocks for web and healthy competition is vital or both to succeed.

duxup 3y ago

So let's say I'm building a webapp. Why would i want to choose Rust? "Speed" and "not requiring as much of a memory footprint as well as more service uptime with less crashes". I dunno man. I'm not saying those aren't interesting but I'm not sure that when it comes to web development that those are big hang ups. There's got to be something more compelling IMO before you swing away from a fairly rich and frankly developer rich pool in JavaScript land... Granted I enjoyed the article and my interest is piqued but that's it.

govolckurself 3y ago
The biggest bottleneck in web applications was, is, and ever shall be, roundtrip time to the database, especially now that nobody bothers to install MySQL on the same box anymore, so every query has to go over the network. Of course, that's in a sane web application. Trendier approaches also try to shovel 10 MB of JavaScript over the wire first, so you can then call your API (which is slow for other reasons), and then render the result (which is also slow because you've shoveled 10 MB of JavaScript into the user's browser). The language you choose matters relatively little.
- jeroenhd 3y ago
  I disagree, those 10MB of JS easily become 40MB of WASM. Picking a language that's compiled to Javascript for frontend code is the only good choice IMO. WASM is not unlike the JARs and SWFs we got shoved down our throat ten years ago when HTML and JS were lacking any useful web capabilities. Huge files with separate runtime that implement their own renderer and operating environment. Google Docs already does this, using a canvas element to render to rather than using HTML and CSS to lay out text.
  - madeofpalk 3y ago
    > using a canvas element to render to rather than using HTML and CSS to lay out text. That is independent to whether WASM is being used or not. Two completely orthogonal concerns.

rwalle 3y ago

> As you can see, the code is really not that far off from something like JSX I'm sorry, no.

kykeonaut 3y ago

I think the right approach would be to work with WASM in the same way that we work with GPGPU programming: write most of the code with JS/TS and write only the computation intensive tasks with Rust/WASM.

robertlagrant 3y ago

Can Rust beat Javascript without becoming Javascript[0]? [0] https://docs.rs/left-pad/latest/left_pad https://docs.rs/left-pad/latest/left_pad

Aissen 3y ago
Sure: https://crates.io/crates/left-pad/reverse_dependencies https://crates.io/crates/left-pad/reverse_dependencies https://www.npmjs.com/package/left-pad?activeTab=dependents https://www.npmjs.com/package/left-pad?activeTab=dependents
marcosdumay 3y ago
I am pretty sure this is a joke crater.

rwalle 3y ago

Engineering is a matter of tradeoffs. With JavaScript, you get simplicity but lose strict typing (can be compensated with TypeScript), performance etc. Rust gives you much better performance but is more complicated to write. However, for a lot of the websites out there, especially those that are not e-commerce or provide creative tools (e.g. Figma) and do not care that much about page performance, the potential performance gain from rewriting JavaScript code in Rust is not visible enough to end users. Of course there are bad websites out there that are slow, but it is often more about CDN/backend servers/the UI code itself rather than the JavaScript language. In other words, many websites are "fast enough", and most CTOs, product managers and developers would rather use JavaScript/TypeScript and release more features rather than write Rust, in the real world. Same thing for a Rust replacement for VSCode -- I am sure it is an interesting project, but VSCode performance is generally good enough (I don't ever complain about slowness while developing). A lot of the performance bottleneck comes from the language services anyway. If you improve the loading speed from 2s to .2s that is definitely great, but if at the cost of losing most of the existing extensions, I'm not going to consider it at all.

MuffinFlavored 3y ago
To me it's like a curve. Yes you can technically maybe get off the ground more quickly up front with JavaScript, but as soon as you hit a certain code base size threshold (not sure what it is personally, it is probably different case by case), you would've been better off with TypeScript or Rust as JavaScript starts to "crumble" under its own lack of types, etc.
- Ygg2 3y ago
  JavaScript depends on use case but around 10-100k lines (or when node_modules reaches 3GiB) it gets gnarly. JavaScript is like Legos, durable and you can build many things in it.
  - kaba0 3y ago
    The analogy works, you may also step on it bare foot :D

billconan 3y ago

I’d love to use rust for the frontend, but some of the important dependences I need are still in js. How does rust call them?

cabirum 3y ago

Okay, if we only care about render performance, rust/webasm is kind of comparable to native js frameworks. Now: What is compile times for real-world medium to large projects? Do these even exist? Rust is infamous for its compile times, and frontend dev often requires live reload on every change. What does debugging look like? Can I set a breakpoint in rust code in my IDE? What do I see in browser devtools? Can I change values in my paused code at runtime, then resume execution?

jeroenhd 3y ago
I don't know how much the Rust dev tools have advanced for browser debuggers specifically, but source code maps allow just about any language to be debugged through the standard browser debugger. You're limited by the browser debugger of course (no time traveling debugger like in real Visual Studio) but it works well enough that it felt like debugging Javascript. This article from 2½ years ago shows what was already possible back then when you're debugging C++: https://developer.chrome.com/blog/wasm-debugging-2020/ https://developer.chrome.com/blog/wasm-debugging-2020/ Rust build times are huge at first, especially if you haven't downloaded any dependencies before, (comparable to running npm install) but incremental compilation makes small code changes very quick and easy. Having worked on a Javascript code base that's grown over a few years, I don't believe Javascript is any faster than Rust when it comes to compilation/transcription/packaging, especially when you need to add a layer like TypeScript between your tools and yourself if you don't want to go insane with JS' lack of typing. I wouldn't use Rust for a browser frontend, but I don't think the lack of tooling is a very good reason not to. The massive size of WASM binaries, the overhead, the lack of transparency, and all the other problems are, though. I'd stick with Rust on the backend instead.

misja111 3y ago

"If your newest tool is a hammer, every problem looks like a nail." There is hardly any language that doesn't have some kind of meta language that compiles to JS. And without exception they all are bad, except maybe if you have a backend which only needs some very basic front end which you prefer to write in the same language. But with any decent sized front end project, JS or TS are the better choices. JS, obviously, because it runs natively in the browser. So all browser tooling works out of the box, debugging is easy because what you see is what actually runs. TS, although it doesn't run natively, at least was designed to be compiled to JS and is widely supported so tooling is good as well. But any JS substitute that was added to a backend language as an afterthought will suffer: - inferior tooling - more troublesome debugging - and last but not least, because it was added as an afterthought, 95% of the language will work fine but the other 5% can give you as a developer serious head aches.

maeln 3y ago

I really, really can't wait for the extension to WASM to allow it direct access to the DOM and finally be able to remove the need for JS for 99% of its usage. I do a lot of frontend development and I just cannot fathom how badly design JS as a language is and how awful the developer experience is. Every time I talk about JS shortcoming with other frontend dev, they point out that JS can do X or Y which other language cannot, but usually it is just a hack that are just not needed in other language because they actually do things properly (like having an actual sane type system and not having three ways to express that a variable is null). And TS is just a crutch that can barely help JS shortcoming. Finally being able to compile from any language to a, reasonably sane, bytecode that can run in-place of JS is just a miracle and I don't understand why it took so damn long. JS should have been deprecated long ago. Even ActionScript was better. Anyway, rant over.

madeofpalk 3y ago
> and how awful the developer experience is. Can you put breakpoints in WASM and debug frontend code?
- jeroenhd 3y ago
  Yes, source map generation for modern languages has existed for a few years now. You can debug Rust/C++/Go straight from your browser's dev tools. Altering memory is more complicated, though.
jeroenhd 3y ago
JS can do some things very well that others can't. Prototype based reflection is very powerful! Its problem is that the things Javascript excels at aren't all that useful, and the things it's bad at are often sold as features instead ("duck typing means I can iterate faster!").
marcosdumay 3y ago
> to allow it direct access to the DOM Hum... Direct calling the DOM API is there already. You may be thinking about FFI marshaling, that there is something on the pipeline for helping (I don't even remember exactly what). But that's only a small improvement on speed, and that almost never is a dealbreaker. For a while I thought the garbage collection helper was a dealbreaker (for anything except Rust), but GC languages are starting to compile into WASM too, with just a small performance hit. (I haven't looked exactly how.) This year and the next are looking like some serious promising period for non-JS programing on the browser.

javajosh 3y ago

In my view, JS is preferable because you are forced to ship source to the client. This provides a beneficial atmosphere for learning and sharing solutions. Compiling to WASM, and front-end builds in general, take this critical and unique quality away from the web platform. Rust-to-WASM is another attempt to abstract away the pain of JavaScript, attempts which began soon after the world discovered XHR. In fact Google released GWT specifically to appeal to Java devs who took one look at JS and said "no thanks". This is not so say that there aren't legit uses for this technology - its a great way to port other software, like sqlite or linux into the browser. But as a way to make applications designed to run on the web? I suggest that any dev that thinks this is necessary to have a good dev experience take the time to attempt to write a web app with just raw html, css, and js targeted at a modern browser. There's a lot of space there left to explore, I think, before labeling it as an unwieldy thing that must be wrapped in a safer abstraction to even think of touching.

VWWHFSfQ 3y ago
> you are forced to ship source to the client. This provides a beneficial atmosphere for learning and sharing solutions. This hasn't really been true anymore for quite a long time. Pretty much everything is bundled, minimized, and obfuscated now.
- ModernMech 3y ago
  But it's still source, no?
  - VWWHFSfQ 3y ago
    Maybe by some legal definition. But I don't think most people would consider it source code anymore.
  - govolckurself 3y ago
    This is the weirdest gotcha. Nobody said it wasn't source anymore, they implied that it wouldn't be readable or conducive to sharing because it's unreadable.

JoeOfTexas 3y ago

Sure, if you want to go backwards. JavaScript was created and persisted because it solved a problem that C++, Java, and to some extent PHP, had of being overly verbose. While the idea is novel, it is not business practical.

jeroenhd 3y ago
JavaScript was created in a rush because a web browser in the 90s needed to do some basic form handling and user interaction. It's Java but with silly names, stupid scoping, a unique prototype system nobody seems to get down, a strong influence from the worst years of Microsoft, and a legacy that forces it to make some pretty stupid choices moving forward. It's incredible what browsers have been able to make Javascript do, but it's not exactly a well-designed language. As for being business practical, WASM is already widely employed by web apps. The front end ecosystem is in its early stages so it's quite messy, but it's developing faster than I expected. It may end up being a real competitor for frameworks like Blazor and ASP.NET if it the tooling continues to improve like this.
- kaba0 3y ago
  It’s not Java, it’s more like a badly designed LISP in Java/C syntax, which in itself makes all the advantages of LISPs go out the window.
kaba0 3y ago
It didn’t solve any problem, it was politics.

willio58 3y ago

I want to be interested in Rust, but then I see a line of code like this in the post: let decrement = move |_| set_value.update(|value| *value -= 1); Maybe I've lost that interest I once had in learning language syntax.. I just don't really understand this intuitively and the barrier to understanding this line feels unnecessary. When I compare Rust with JS/TS, Python, or even Swift I feel like those other languages are created in a way that's easy to pick up and transfer knowledge from other languages, then the deeper parts of the language are easily accessible once you're introduced to the basics.

duped 3y ago
I mean compare to using arrow functions and it's almost identical let decrement = () => set_value.update((value) => value -1); The difference is that Rust isn't garbage collected and has reference value semantics, which is where the *value -= 1 comes in.
- willio58 3y ago
  It's funny, I almost noted that arrow functions are a definite oddity of JS that I could see people thrown off by.
  - marcosdumay 3y ago
    > oddity of JS I can't think on any modern language that lacks some short syntax for lambdas. Hell, it's very easy to make a point that lacking short syntax for lambdas make a language not modern and unusable for our current standards.
    - willio58 3y ago
      I'm a little confused what you mean by JS lacking a short syntax for lambdas. let multiply = (a, b) => a * b; Is this not a lambda?
      - kaba0 3y ago

zerocall__ 3y ago

Why not both? API Gateway + Lambda/OpenFaaS/Knative with rust handlers (low RAM/fast start), and typescript/react served via CDN. with serverless platforms, it honestly matters not what language. Rust is just a convenience for compiling to arm for gravitron and low memory footprint. Languages that carry runtime bloat are less desired though for cloud functions.

lucasyvas 3y ago

If there was a superset of Rust where everything was transparently reference counted, every data structure could hold mixed types easily, and closures were dead simple, then maybe. These are things that are, IMO, just too engrained as being possible in JS/TS for people to give up easily, especially in terms of UI programming. I've used both quite a bit - I am pulling for Rust to become more ergonomic for this use case where it makes sense because it has lots of other advantages. But when the rubber hits the road and you start writing, I think Rust gets in the way too much for UI programming. For a small project it may be OK, but in most orgs you have sweeping design changes occurring (probably too) often. Rust is best when things have stopped churning and stabilize. UI code often churns like a relentless beast, so something extremely approachable/flexible but strongly typed is best I think. This is why TypeScript is winning in this arena. I'm optimistic headway will be made, but Rust currently feels a lot better to write for back-end and systems. It's not a surprise since that's what it was designed for. Besides all this, I'm totally unsure where the size of the distributable comes in. In JS things can be chunked per page easily which keeps load times small. With WASM you get the whole thing by default, correct? That could be problematic.

doctor_phil 3y ago

This link is dead now. It seems to have been replaced by https://joshmo.bearblog.dev/can-rust-beat-javascript-in-2023/ https://joshmo.bearblog.dev/can-rust-beat-javascript-in-2023...