81–87 of 87 posts
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…
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…
If they "solve" that then they risk being the next Java Applets.
Am I getting this right?
Earlier quoted context omitted.
If they "solve" that then they risk being the next Java Applets.
Funny how have things have progressed. We went from using HTML + CSS for simple presentation of information, to enriching with small amounts of client side scripting, to plug-and-play sandboxed applications with Flash/Java. Then we realised those were a terrible idea, Flash and Java Applets died, so we started treating JavaScript as a compilation target to mount behemoth abstractions enabling a native application-lik…
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…
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?
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…
Earlier quoted context omitted.
If they "solve" that then they risk being the next Java Applets.
Funny how have things have progressed. We went from using HTML + CSS for simple presentation of information, to enriching with small amounts of client side scripting, to plug-and-play sandboxed applications with Flash/Java. Then we realised those were a terrible idea, Flash and Java Applets died, so we started treating JavaScript as a compilation target to mount behemoth abstractions enabling a native application-lik…