Ever since Netscape launched JavaScript, there were some developers that liked it and others that didn't.
Regardless of which side you're on, I th...
For further actions, you may consider blocking this person and/or reporting abuse
I think that Assembly will not get big potential for in-browser use until these functionality will be available:
1) syntax to use WASM as a page scripting module, like
2) Garbage collection support (seem to be in progress).
3) standard way of marshaling API calls between WASM environment and browser standard API necessary, like DOM manipulation, fetch, events handling, Web Cryptography API access, window object access or access to self & globalThis for workers, etc. It does not mean that WASM will call things like Math.ceil, but it is about different widely used APIs like Canvas, WebGL, indexedDB, etc.
This still will require 3.1) WASM pre-declared permissions or capabilities request, with way to say what capabilities mandatory for a WASM module to start, which are optional. Actual list of available capabilities can be sent to initialization code of webAssembly if all mandatory features available for module.
Imagine a WASM file that gives API for an encrypted keys-container a-la KeePass for browser?
Good points!
Not having standard APIs does make the file size of WASM much bigger. Maybe it can be solved by the browser caching runtimes client side?
It can be solved by stating some dependencies, like list of urls and hashes as way of versioning.
But this will require a WASM dependencies trust policy specified as part of CSP - like, dependencies must be origin-relative, can be urls from white-listed domains, etc.
Idea is make that language-specific "runtime" a dependency, not embedded into browser, who just have to organize marshalling mechanism between self (as host) and WASM module, and declare its capabilities - WebGL, DOM, UI interaction, 2D Canvas, IndexedDB, Web Cryptography, "Native Windows" (opened by WASM module), Controllers support, other features.
Runtimes caching require dependencies between modules, otherwise not clear what to cache.
I don't know what you mean by "big potential", but chances are if you're using any Web app working with images (like resizing, cropping, etc.) it runs on (C libraries compiled to) Wasm, and "secretly" does so for several years already. 😉
I don't even mention Web apps using Wasm big time like Figma, Photoshop and many others...
Big potential was essentially replacing JavaScript, to say it simply.
Replacing JS was never the goal of Wasm. The goal is to bring additional languages to the browser and other environments (Function-as-a-Service and Edge, for instance) and augment JS.
I personally agree that JS needs no replacement, while bringing other languages and having more options is very useful.
If JavaScript will not be replaced, it will always pressurize other languages out of Web.
If WASM will get equal capabilities at Web as JavaScript, it will be eventually step to replacing JavaScript with WASM, when browser have single runtime (WASM) and compiling JavaScript to WASM and executing as it since, not JS.
This is what I meant "replacing JavaScript" - simplifying browser internals by having single execution environment.
If WASM will get all capabilities of JavaScript from Web & HTML5, desktop and web apps will be merged as phenomena, like "write once, run everywhere".
Of course, some enshitification can happen in the process, but most users may be happy about that or will not care - most users already don't care is their desktop app is a native app or electron wrapper around a web page.
You're making a statement about the future which is notoriously hard to get right, and I don't see even present agreeing with it.
If anything I see C/C++ libraries compiled to Wasm "secretly pressurize JS out of Web". And it's not as if nobody was using Elm, ClojureScript, PureScript, ReScript and other languages instead of and alongside JS. I don't see JS "pressurize" these languages out of Web. Thus I see no reasons for this trend to reverse in the future.
Any decent runtime compiles both JavaScript (for ages) and Wasm (nowadays) to machine code. It makes no sense whatsoever to compile JS to Wasm first. And sure enough both V8 and SpiderMonkey reuse the same back-end for both JS and Wasm.
Any single browser has single execution environment — V8 or SpiderMonkey or JavaScriptCore — and it's the smaller part of the browser. The bulk of a browser's complexity lies in the implementation of Web Standards and Web APIs, which are not going to go away.
Well, try use WASm beyond narrow niches of some "heavy computations" - manipulate DOM with WASM, or use Web Cryptography API or Credentials API with WASM, or try do a fetch with WASM, or try load WASM as a "normal" module, via pure script tag. Until this happen, WASM can not be considered as "first class citizen" of Web.
Seems like writing WASM will be more verbose.
WASM is designed to be generated by a compiler.
I think most developers wouldn't write it directly. The compiler would generate it for them.
Actual
.wasmis binary, it's extremely terse. 😃But you don't have to write it yourself, right?
Most developers will never write
.wator.wasmthemselves. It will be generated for them by a compiler.The format is intended for programming language developers.
It's analogous to assembly language, most C++ and Java devs don't need to know it to be effective.
WebAssembly is truly revolutionizing the way we interact with the web. The concept of a portable, low-level bytecode that can be executed efficiently across different platforms opens up incredible possibilities for the future of web development. With WebAssembly, we're not only looking at enhanced performance but also a more secure environment, as the sandboxed execution ensures a level of isolation from potentially malicious code. It's exciting to think about the potential this technology holds for creating richer, more interactive, and faster web experiences. The future of web development is looking brighter than ever with WebAssembly paving the way!
I'd also add that many hosts/runtimes, Wasmtime included, can load and execute
.watfile directly.Interesting - thanks for sharing.
Am I right in thinking that WebAssembly is conceptually a bit like a 'native' Silverlight: you build/compile modules (in any language with a compiler), point a browser to it, and it starts running your app?
Also, does WebAssembly support parallel processing (and all of the accompanying synchronization mechanisms, etc.)?
I'm not familiar with the term "native silverlight". But it is similar to Silverlight in that your build an assembly and it can be opened in the browser
WebAssembly can support multi-threading and atomics. There is a spec under development:
github.com/WebAssembly/threads
In some cases, you can build the multi-threading into the host, and then the WebAssembly modules can run in their own threads, they might not need to know about multi-threading. If they need to synchronize data, they can call an API provided by the host.
'Native' Silverlight was just a term I made up when trying to describe a Silverlight-like experience (developed in a language and then compiled into binaries), but without having to install a plugin to run it.
Thanks for the info!
To me loading only single Wasm file sounds more like a (temporary, until we have Component Model) drawback. With many JS files we might not even need them all at once and all the time, so we might often save some time not loading some files at all.
Besides, "cold start" usually refers to the first loading of a program exhibiting a "warm-up" behaviour: allocating memory, loading data, initializing stuff, filling up the resident set and caches, JIT-compiling and so on. Wasm programs inevitably exhibit "warm-up" behaviour too: they also need to allocate memory, load data and JIT-compile the code before they can start doing useful work, though, most often it happens much faster than for JS.
In principle, the same can be done for JS too, though I don't know if any engine actually does. For Java and C# snapshotting is definitely an option.
At the same time for Wasm it's not "free" either: one have to do it explicitly...
Officially it's "Wasm"... 😂
Yeah, it looks like they specifically aimed at confusing everybody, but on the other hand WASM ain't no acronym either... 😃
I think it would be nice to mention that a
.wasmfile defines a module, which is a unit of code loading, somewhere before this point... 😉can it thread and also talk to os directly ?
There is a spec being developed for threading.
In some cases, the parallelization can be done inside the host, and the WebAssembly can be kept single-threaded and still achieve a multi-threaded system.
As for accessing OS, the host decides what APIs to provide. So a file-system API could be provided like this:
Nice 👌
Nope, that would be a huge security hole. Wasm can only use APIs explicitly provided by its host with Object Capabilities-based Access Control.
i see, thanks
Did you mean "What is WAT?"
not now more about but it might attention topic