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.
"It makes no sense whatsoever to compile JS to Wasm first"
While I would agree in part. Javascript need not necessarily compile to WASM, first on everything but can be an option and choice for optimizing performance by pre-compiling elements of code that would otherwise be slower by interpreting line by line the javascript. JIT compilers would be only equal to or faster ONCE the code compiled either to WASM or ML but only a rerunning of the code. The initial run of the code would take longer. Additionally, WASM can bring file size down which speeds up the stuff transferring over the bandwidth bottleneck (the internet connection itself) to the local side. Then we also have other optimizations like CDNs which can reduce latency as well. However, WASM serves for web browsing much what P-Code did back in the day of Pascal and BASIC which was often compiled to P-Code which was allowed the same code to be used on multiple computer platforms because ML is unique for each CPU Instruction Set Architecture (ISAs). ARM, X86, X86-64, PPC, etc. So WebAssembly is portable as P-Code was but engineered around Javascript and the web on purpose for interoperability by design. You can even write WebAssembly code by hand (text and binary... the latter is harder to do until you get your head around the WebAssembly's Virtual Machine Language's instruction set. I call it "Virtual Machine Language" as the stack processor of WebAssembly is the "virtual machine" or virtual CPU. So I state virtual for the point it is not the physical CPU's machine language but the "virtual one" represented by WebAssembly's specification and implemented in the web browser. Then "machine language" as a sort of parallel to physical machine language because it would actually look very much like a real CPU's machine language and you can use a hex editor to write the code by hand but that's a bit more intense than the slightly more human friendlier text format which is akin to assembly language as an intermediary format between high-level languages which can be BASIC, C/C++/C#, Java, Javascript, Lua, or any number of high level languages source code to this intermediate format before webassembly binary format. Only way you would get faster performance would be basically to compile to machine language but you lose the platform independence portability so you have to trade off some performance for portable code that you don't have to recompile, edit+recompile for all the different CPUs a web browser could be available for. Most of you will be using high-level languages to write most of the original source code and maybe handwrite some tuned code in webassembly but even then, maybe not because its not human friendly as Javascript (the "BASIC"/"PASCAL" for the web browser). So you have choices just as I saw with BASIC compilers back in the 1980s which would either compile to P-Code or actual machine code.
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!
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.
You could say that about machine language of any CPU even the Intel 4004. However, so what. It is just that today's programmers and web programmers (especially the latter) is not accustom to low level programming in machine language so they would be comfortable writing in a higher level programming language where the syntax is more human readable and then "compile" the human readable code to machine language or a "virtual" machine language like WebAssembly binary format would sort of be.
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.
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