Live data from Hacker News

Learn WebAssembly by writing small programs

github.com

61–70 of 87 posts

Re: Learn WebAssembly by writing small programs

#62

Earlier quoted context omitted.

The two language problem is, indeed, awkward. DOM bindings in WASM would be awesome. I would be a happy nerd if I could do all of my web dev in OCaml. In the meantime, WASM has real, just not for front end dev. The two language problem is hardly unique to web dev. It’s also ubiquitous in the machine learning/data science space with Python and C/C++/CUDA playing the roles of JS and WASM, respectively.

> I would be a happy nerd if I could do all of my web dev in OCaml. You don't like Bonsai? Or do you just want something that doesn't "transpile" to JS at all?

I find that these compile-to-JS languages are great until you want to bring in other JS libraries. Then you’re stuck writing bindings which is annoying, and often brittle if you’re not really careful.

Re: Learn WebAssembly by writing small programs

#63
post #59

I'm cheered by ongoing progress in adoption of WebAssembly. While Microsoft is often given minimal notice here, I urge anyone interested in WASM to experiment with Blazor WebAssembly. It's an incredibly powerful framework that lets you use C# and most .NET libraries (including NuGet packages) as compiled WASM in the browser.

[deleted]

Re: Learn WebAssembly by writing small programs

#64

Earlier quoted context omitted.

> I would be a happy nerd if I could do all of my web dev in OCaml. You don't like Bonsai? Or do you just want something that doesn't "transpile" to JS at all?

I find that these compile-to-JS languages are great until you want to bring in other JS libraries. Then you’re stuck writing bindings which is annoying, and often brittle if you’re not really careful.

Oh I didn't even think of that--that sounds like a huge pain in the ass lol

Re: Learn WebAssembly by writing small programs

#65

Earlier quoted context omitted.

Is being a "JS killer" even a goal of WASM? From what I understand, WASM's goal is to allow computationally heavy workloads (e.g., image and audio processing) to the browser by providing a compilation target for C code. This is how we get nice things like Figma or MS Office running in the browser. Let WASM do the number crunching, let JS do the UI.

It's not the goal from what it seems. But it's definitely what would make it the most interesting to a lot of people, and it's what I think most people expected at some point. For a lot of companies the only place JavaScript is ever used is on their website frontend. And it makes you wonder, why does it even still need to be JavaScript? With the rise of SPAs and the fall of normal document based websites, browsers ar…

You can certainly bridge the DOM to WASM with a virtual DOM. The problems with WASM are not just interoperability.

The biggest problem is tooling. You cannot build tooling for in-browser WASM because it runs in a browser sandbox. JS has the same problem but the difference is that JS has a known object model that the browser can provide good tooling for.

Whereas with WASM the browser has little insight into what those opaque Memory objects contain. So you need to bring your own tooling and run it inside the sandbox, and the sandboxing does not make this easy.

Let’s say for example you want to pause execution, inspect the object tree, and run a REPL while it’s paused.

Re: Learn WebAssembly by writing small programs

#66

Earlier quoted context omitted.

Is being a "JS killer" even a goal of WASM? From what I understand, WASM's goal is to allow computationally heavy workloads (e.g., image and audio processing) to the browser by providing a compilation target for C code. This is how we get nice things like Figma or MS Office running in the browser. Let WASM do the number crunching, let JS do the UI.

It's not the goal from what it seems. But it's definitely what would make it the most interesting to a lot of people, and it's what I think most people expected at some point. For a lot of companies the only place JavaScript is ever used is on their website frontend. And it makes you wonder, why does it even still need to be JavaScript? With the rise of SPAs and the fall of normal document based websites, browsers ar…

If it was the JavaScript killer it will attract JavaScript devs and they’ll make it just like JavaScript

not syntax-wise just community wise, where the package and package managers are a mess and why there is demand for a JavaScript killer

Re: Learn WebAssembly by writing small programs

#67
post #59

I'm cheered by ongoing progress in adoption of WebAssembly. While Microsoft is often given minimal notice here, I urge anyone interested in WASM to experiment with Blazor WebAssembly. It's an incredibly powerful framework that lets you use C# and most .NET libraries (including NuGet packages) as compiled WASM in the browser.

Re ‘most nuget packages’ What’s the limitation here? If it requires the ability to read a file on disk, does it straight up fail or does the file read interface push the action back into a server-side rendering type action?

The NuGet packages are zip files containing compiled binary and possibly other resources. They're referenced in the source code and included at compile time. Since they become integrated into the overall compile, there's no need to reference them in the final runtime product.

Re: Learn WebAssembly by writing small programs

#68

Earlier quoted context omitted.

It's not the goal from what it seems. But it's definitely what would make it the most interesting to a lot of people, and it's what I think most people expected at some point. For a lot of companies the only place JavaScript is ever used is on their website frontend. And it makes you wonder, why does it even still need to be JavaScript? With the rise of SPAs and the fall of normal document based websites, browsers ar…

The two language problem is, indeed, awkward. DOM bindings in WASM would be awesome. I would be a happy nerd if I could do all of my web dev in OCaml. In the meantime, WASM has real, just not for front end dev. The two language problem is hardly unique to web dev. It’s also ubiquitous in the machine learning/data science space with Python and C/C++/CUDA playing the roles of JS and WASM, respectively.

> DOM bindings in WASM would be awesome. I would be a happy nerd if I could do all of my web dev in OCaml.

DOM is not enough for that. You almost certainly would like to be able to communicate with your backend ;)

Here is a list of the "usual" web APIs: https://developer.mozilla.org/en-US/docs/Web/API And everything that needs network access or access to local resources (file system in the worst case) will never happen to WASM because of security considerations.

Re: Learn WebAssembly by writing small programs

#69

Earlier quoted context omitted.

The two language problem is, indeed, awkward. DOM bindings in WASM would be awesome. I would be a happy nerd if I could do all of my web dev in OCaml. In the meantime, WASM has real, just not for front end dev. The two language problem is hardly unique to web dev. It’s also ubiquitous in the machine learning/data science space with Python and C/C++/CUDA playing the roles of JS and WASM, respectively.

> DOM bindings in WASM would be awesome. I would be a happy nerd if I could do all of my web dev in OCaml. DOM is not enough for that. You almost certainly would like to be able to communicate with your backend ;) Here is a list of the "usual" web APIs: https://developer.mozilla.org/en-US/docs/Web/API And everything that needs network access or access to local resources (file system in the worst case) will never happ…

How is allowing WebAssembly to use the network any less secure than allowing JavaScript to use the network?

Re: Learn WebAssembly by writing small programs

#70
Because I've read it here and elsewhere quite often: What is missing from WASM in the browser isn't "just" DOM access, but "everything" else - including fetch or XMLHttpRequest - too. Here is a list of all web APIs supported by browsers and not supported by WASM, the DOM is just one of them: https://developer.mozilla.org/en-US/docs/Web/API

But at least there is hope, that these interfaces will be available once GC is final and supported by browsers:

    Once GC is supported, WebAssembly code would be able to reference and access JavaScript, DOM, and general WebIDL-defined objects.
Last paragraph at https://webassembly.org/docs/web/
Post reply on HN