Aedius, 21 days ago

@janriemer

#rustlang will definitively be the future of javaScript !

unless an other language got a better experience to generate wasm.

I wrote some webcomponent in rust with shared business code between frontend and backend : my TS coworkers are impressed about how convenient it is to have something that just run when it compile ( ok, that's not always the easy part ).

janriemer, 17 days ago

@Aedius Sorry for the late reply. 😔

That's awesome! Thank you for sharing! 🙂

Yes, sharing business logic between frontend/backend is a very compelling argument.

However, I just have this feeling that the advantages of Rust are not as apparent when designing interactive web pages.

As I said, for logic heavy apps, sure, but for small interactivity, satisfying Rust's strict rules might not be worth it.

#Rust #RustLang #Frontend #WASM #WebAssembly

ntha, 17 days ago

@Aedius @janriemer as long as you can’t leverage the massive frontend ecosystem of libraries with wasm I doubt this very much.

janriemer, 17 days ago

@ntha @Aedius This!

Interoperability and existing ecosystems are so important when talking about adoption of a new technology!

It must be interoperable, otherwise it won't be adopted at scale.

Aedius, 17 days ago

@janriemer @ntha

That's why I'm building webcomponents :
It integrates very nicely into the massive frontend ecosystem.

I replaced some parts of a big react application with some webcomponents, for the react concerns : it's just some html to display. And for style : I just generate the same DOM.

User didn't notice the change and now the microfronted code is alongside the microservice code .

ntha, 17 days ago

@Aedius @janriemer Can you use other ESM libraries within your Rust Web Component? E.g

import 'https://esm.sh/some-library'

And then use it? Because if not then I'd say that while yes you can create Web Components, it doesn't really integrate with the ecosystem, not fully at least.

Aedius, 17 days ago

@ntha @janriemer

Yes, that's the default use case with wasm-pack and you can push to npm or your repository as well.

ntha, 17 days ago

@Aedius @janriemer I think you misunderstood what I meant - I did not mean if your web component is importable to others, I'm sure it is - I meant if you can import JS libraries within your Rust Web Component? Because if you can, that would be very cool.

ntha, 17 days ago

@Aedius @janriemer At least I'm not able to find from wasm-pack documentation that it would be possible, so I assume it's not. Which mean you don't really have access to any of the JS ecosystem and can't leverage existing JS libraries, you can only create JS libraries. And that would mean having to re-invent so many wheels that it makes Rust not a serious option for work, for me at least.

Aedius, 17 days ago

@ntha @janriemer

i didn't test it, but it seems, it just need to be declared on the Rust side :

https://rustwasm.github.io/docs/book/reference/js-ffi.html

fn main() {
// import a JS function called foo from the module mod
#[link(wasm_import_module = "mod")]
extern { fn foo(); }

janriemer, 17 days ago

@Aedius @ntha

Yes, you can definitely import JS into your Rust - see wasm-bindgen guide (which is used by wasm-pack under the hood):

https://rustwasm.github.io/wasm-bindgen/examples/import-js.html

ntha, 17 days ago

@janriemer @Aedius Oh damn, that is cool. So yeah, I guess you can indeed use the entirety of the JS ecosystem within Rust. The only thing that really sucks and ends up being a huge grind is having to maintain Rust-definitions for those JS libraries, because it won't be able to automatically know any of that. Understandable, but sucks nonetheless.

Still, very cool.

Aedius, 17 days ago

@ntha @janriemer

Well, that's mostly the same for typescript, no ? Someone has to write the definition to us JS library into TS, so i dont think it's an hard issue.

ntha, 17 days ago

@Aedius @janriemer Well no not really, TypeScript can pick up JSDoc comment blocks as well and infer types from those, thus making it so that you don't have to recreate and maintain anything on your part. Besides that, most projects provide TS types themselves, so it's a non-issue in either case.

Whereas in Rust you have to do it yourself 100% of the times and if you're using 10+ libraries then that very quickly becomes unreasonable.

ntha, 17 days ago

@janriemer @Aedius Having had done Clojure/ClojureScript for 6 years taught me to generally try to avoid parasidic languages, because they seem to always be second-class citizens and encourages the creation of native "wrappers" to get proper IDE support for when interop is used, and it just is a massive grind and headache in the long term, so I'd rather just use JS itself even if it's not my favourite language, but the DX is just so much better.

alcinnz, 22 days ago

@janriemer Lua!

Its like if JavaScript was allowed to stay itself! They're the same age.

janriemer, 22 days ago

@alcinnz

> Its like if JavaScript was allowed to stay itself!

That's a beautiful way to put it!

I don't know Lua (I should look into it!), but I once saw something that, at first sight, looked like JavaScript, but also not quite...something was slightly different...

...well, it was Lua! ✨

So I totally get what you are saying.

ntha, 22 days ago

@janriemer I've done some WASM in Rust and have really enjoyed it, however I feel like the learning curve for that is way too high for most web devs to start doing that. Convenience seems to always win over safety when it comes to humans.

mo8it, 22 days ago

@janriemer Currently, TS is the best available option. WASM is the future, but it is not there yet. I mean, you get problems if you try to launch a thread…

funnylookinhat, 22 days ago

@mo8it @janriemer honestly... Dart?

It solved all of the problems with JavaScript a long time ago, and has had a remarkable staying power due to Flutter.

janriemer, 21 days ago

@mo8it

> I mean, you get problems if you try to launch a thread…

Which specific problems are you refering to?

As far as I understand, you can spawn threads in JS environments (e.g. in the browser) with no problems (using Web Workers and SharedArrayBuffer under the hood).

Only spawning them in non-JS environments is currently not supported, if I'm not mistaken. For this, we'll need the thread-spawn proposal implemented, right!?

https://github.com/WebAssembly/shared-everything-threads

#WASM #WebAssembly #WASI

mo8it, 21 days ago

@janriemer I can't point to anything specific and don't have enough experience in WASM anyway.

I just found out that I can't run my program with egui in the browser, most probably because I spawn threads in it. But the debugging experience was… there was none. The error that I got said nothing, similar to the experience with a SEGFAULT. Something went wrong, no idea what.

Don't get me wrong, WASM is the future, but not the present for me.

janriemer, 21 days ago

@mo8it Thank you for sharing, Mo!

Hmmm...that's unfortunate and sad. 😔

You might need to set appropriate headers in your server config (due to Spectre attack mitigation). See details in the last paragraph of this section:

https://web.dev/articles/webassembly-threads#sharedarraybuffer

It basically says you need to cross-origin isolate your site. Details at MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#security_requirements

Also, as a baseline requirement, you need to be in a "secure context":
https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts

Hope, this will solve your problem. 🤞