Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn WebAssembly by writing small programs

github.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Learn WebAssembly by writing small programs

#71

Post by tietjens »

raincole wrote: post #50
ysavir wrote: post #45

Looks very similar to the Exercism model, which also has a free WASM course filled with small exercises[1]. I wonder if the author considered contributing to that course or working together with them, it might get their work to a broader audience and leverage the existing toolset Exercism has to offer. [1] https://exercism.org/tracks/wasm

One thing I don't like about Exercism is that except for the most popular languages, the exercises are often not "sysematics". In other words, it's just a bunch of leetcode-like questions, ordered by difficulties. A proper course should order the exercises by language features. Exercism actually has built a fantastic interface for this[1], but not utiltized it for most langauges. [1]: https://exercism.org/tracks/csha…

I completely agree with this. I love the platform, the mentors, and the enthusiasm for languages. They’ve done a great series every month this year on a new set of languages, and have great YouTube interviews.

However, the problems they offer do not help you learn the syntax or quirks of specific languages and for me are only a place to practice leetcode/codewars style logic. Also important! But not what I need when I first begin a language.

Re: Learn WebAssembly by writing small programs

#72

Post by ReleaseCandidat »

xigoi wrote: post #69
ReleaseCandidat wrote: post #68

Earlier quoted context omitted.

> 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?

Don't ask me :).

At least WASM will get DOM access (and hopefully access to similar web APIs) as soon as the GC is stable and usable.

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

Re: Learn WebAssembly by writing small programs

#73

Post by oefrha »

RagnarD wrote: 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.

From reading about it, it seems to suffer the same problem as Go compiled to wasm: payload is huge, usually multi-MB after compression.

Re: Learn WebAssembly by writing small programs

#74

Post by hsbauauvhabzb »

RagnarD wrote: post #67
hsbauauvhabzb wrote: post #60

Earlier quoted context omitted.

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.

Sorry that misses my point, blazor runs client side which means that it’s sandboxed with the same permissions as JavaScript executed within a page - you can’t use blazor to read a file client-side, but there’s nothing to prevent wrapping what would be a server side library in a way where ‘it executes on the client except when it can’t, at which point it executes on the server’

Doing so would almost always be a security risk, as validation would presumably still run client side, but that doesn’t mean it’s not possible to actually achieve such an engine.

Re: Learn WebAssembly by writing small programs

#75

Post by andsoitis »

ReleaseCandidat wrote: post #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…

GC proposal is from 2018: https://github.com/WebAssembly/proposals/issues/16 and there’s code: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

Seems like an awefully long time for progress to be made, given all the possibilities it would unlock.

Re: Learn WebAssembly by writing small programs

#76

Post by ReleaseCandidat »

andsoitis wrote: post #75
ReleaseCandidat wrote: post #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…

GC proposal is from 2018: https://github.com/WebAssembly/proposals/issues/16 and there’s code: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O... Seems like an awefully long time for progress to be made, given all the possibilities it would unlock.

Yes, but it is now (for some months) supported by V8 (browser, Node and Deno - hidden behind a flag) and Wasmedge and Wasmtime will both have implementations soon.

But I wouldn't hold my breath to being able to call web APIs directly from WASM ;)

Re: Learn WebAssembly by writing small programs

#77

Post by lxgr »

xigoi wrote: post #69
ReleaseCandidat wrote: post #68

Earlier quoted context omitted.

> 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?

The issue here is the same-origin principle, which rules out most low-level networking (since you could just bring your own SOP-ignoring HTTP client).

Personally I think that enforcing the SOP at all cost (and even when no cookies or other authentication headers are injected by the browser) is misguided at this point and holding back modern webapps.

Re: Learn WebAssembly by writing small programs

#78

Post by Hadriel »

ReleaseCandidat wrote: post #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…

I haven't been following webassembly, but as the former 'cure' for JS, why has it taken so long to get the basics?

Re: Learn WebAssembly by writing small programs

#79

Post by cyanydeez »

hsbauauvhabzb wrote: post #74
RagnarD wrote: post #67

Earlier quoted context omitted.

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.

Sorry that misses my point, blazor runs client side which means that it’s sandboxed with the same permissions as JavaScript executed within a page - you can’t use blazor to read a file client-side, but there’s nothing to prevent wrapping what would be a server side library in a way where ‘it executes on the client except when it can’t, at which point it executes on the server’ Doing so would almost always be a securi…

Like most wasm, if the nugget is just a thin wrapper around a recompiled binary, it's not going to work.

WASM is a compile target. So if the code source is available and it's "pure", most wasm can now compile it.

Check out pyiodide for a extensive python project trying to bring everything in Python to the web.

Your specific concern regarding file access: they just create something like a indexeddb file system if you want to work with files.

Re: Learn WebAssembly by writing small programs

#80

Post by cyanydeez »

oefrha wrote: post #73
RagnarD wrote: 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.

From reading about it, it seems to suffer the same problem as Go compiled to wasm: payload is huge, usually multi-MB after compression.

Is there an article comparing other compile targets.

I mostly get the impression that the compiler in browser is the problem.

If it's adopted natively, that should disappear.

All I'd need is Firefox, edge and chrome to switch to publishing wasm.

Post reply on HN