I've been a developer for decades and I'm still getting highly confused by all of this WASM, Wasmer, WasmEdge, Wasmtime, etc.
There was another one on the front page today that allowed you to use WASM to program other programming languages ("Extism: make all software programmable").
Where are we headed with all of this?
I can see a future where WASM supports GC-languages, then you esentially have things like C# or Java desktop applications running "in the browser" via WASM? Doesn't that throw all of HTML, CSS, etc out the window?
Honest question, sorry if it's dumb. But all these WASM terms, releases, etc. have me completely lost. I'll stick to my day job.
I might be wrong but I think you can conceptualize like this...
Wasm is essentially a target bytecode and runtime based on the well tread security model of javascript in the browser.
Browsers can run it, languages can compile to it, apps of any language can host a runtime that runs it. This leads to infinite permutations and nesting of concepts.
Because its web tech there's a dozen ways to do the same thing.
Yep. That's my take. The vision is that you write code in any language you like. You compile (transpile?) it down to efficient low-level JS (WASM), run in the browser as if you wrote JS code.
I have zero experience with it, but I think I get it and it's neat. I'm a little curious about what working with the DOM is like in C# > WASM or Rust > WASM. I pitty the foo who had to code that... and will we get non-breaking, more efficient native DOM manipulation at some point?
Lots of great answers as to the "how" and "what" here, but here's a real short one for you to answer "why?": Capabilities Security model. It's absolutely ludicrous that all software doesn't run this way. One of those "so obvious, it sounds dumb" things, but that's what all this stuff is bringing imo. And I was an "I hate WASM and I'll never use it" person in the past.
I still think, somehow or another, capability-based microkernels are the future of computing. There have been many attempts, though the most serious one is probably Google's Fuchsia.
Maybe they'll gain some new life as a natural home for WASM.
Extism is great [1], and I have great admiration for what they are doing.
We didn't know they were working on that, if that was the case perhaps we the need for WebAssembly Interfaces ("WAI") would have been minimized.
In any case, it seems that there will be multiple ways of generating bindings going on in the future. And you will probably need to pick the option will fit better your needs! (similarly as how you can use Protocol Buffers, Cap'N'Proto or Thrift).
To the future where Silicon Valley funded startups try to find angles to extract value from WASM. A lot of competing efforts with different business models.
Hopefully in the end we get good VC funded open source and can discard any too aggressive monetisation attempts.
You can compile software to WASM using emscripten. When you see a video game that runs in a web browser it was probably done via emscripten and wasm. When you see old DOS games on archive.org those are done by compiling dosbox to the browser. Emscripten includes some shims for pretending you have a file system and a clock and all that stuff.
There are also GC'd languages ported to WASM, things like Pyodide, but they're pretty big and have some rough edges as they're not normally allowed to do things like make network calls.
WASM is just a virtual machine, sort of like the JVM, but that runs in the browser. It might help to think of WASM (Web-ASseMbly) as a new CPU architecture. It's a minimal CPU instruction set (a virtual instruction set) that can be relatively easily jitted or transpiled into machine code.
WASM by itself doesn't do anything, the specs for what kind of interfaces exist between the WASM sandbox and the host app are still sort of in the air. It's soft of like saying "what can I do with a RISC-V CPU". The answer is "not much until we make more infrastructure that supports it.
Right now you can port large C code bases over to run in a browser with emscripten so that's nice. Maybe you'll write a web component using WASM at some point.
> Right now you can port large C code bases over to run in a browser with emscripten so that's nice. Maybe you'll write a web component using WASM at some point.
But doesn't this have the potential for a massive, paradigm shift in how we look at the "web"?
Take just one example, a GC language like C# or Java being able to run under WASM (inside a web browser?).
It could bypass HTML, CSS, and JS entirely and just run as if it were a desktop application.
Doesn't this lead us down the rabbit hole back to Java applets, Flash plugins and other similar plugins, albeit more secure/sandboxed?
If every website is free to render a button using any programming language it wants, there is no longer any standardization, accessibility features, a layout engine, etc.
What is the point of a "web browser" at all, if all it does is host a WASM-based application?
I think that's the part where my brain starts to give up.
Well yes, but it would probably be violating accessibility laws in the US if they did that, and if search engines can't read the text than that's probably going to be a problem.
>What is the point of a "web browser" at all, if all it does is host a WASM-based application?
It's to get around various walled gardens apparently.
I continue to be surprised that nobody has started marketing a browser (complete with accessibility features, internationalization, etc) that’s built in WASM.
I can imagine any number of media companies who would love to continue using their current web-dev pipeline but, by walling access to their servers off to this “trusted” WASM browser, could be reasonably assured that users aren’t using ad blockers, archive bots, etc. It’s the next logical extension of those ridiculous scripts that you used to see, popping up a “Access denied” message on a right-click because the website owner wanted to limit “view source”. The kind of numbskull who would do that would love a WASM-based browser.
>Not quite, because in order to display anything to the user, it still has to use HTML/CSS/JS
Webassembly was designed to be usable outside of the browser, and multiple native runtimes already exist for it. It doesn't require the web stack, that just happens to be the most convenient way to use it at the moment.
A more lightweight tool than emscripten is the WASI SDK (https://github.com/WebAssembly/wasi-sdk/releases). It doesn't generate JS or HTML but you can run its output on the command line with wasmtime or wasmer.
Kinda same, when I learn 8086 assembly it was easy, walk through registers, interrupt, byte|word allocation, draw bitmap on screen, etc. I was able to build a 2D game by hand within 2 weeks. Started with zero assembly knowledge.
Sorry for long whining, Webassembly should have materials for 1) a complete guide on how to write it by hand 2) have a toy language as a source to demonstrate how to map its ast to wasm instruction, it should cover at least 60-70% of wasm essential features.
Stop pointing to c++/rust/and tool chains. It's doesn't help understanding Webassembly itself.
For me, it's distribution and convenience. I don't have to apply for permission and certification on multiple app stores, no scary popups that my app is untrusted, no worry about dependencies or permission to install locally, just point people to a url on any device and run.
> I'm still getting highly confused by all of this WASM
You are not alone.
On my side of things, I've been looking for an approach to deliver non-trivial in-browser apps while protecting the codebase from theft. In the early days I thought WASM could be that. I don't know any more. JS is a non-starter. It is common knowledge that sites where you hire freelancers to write code often result in these freelancers simply stealing JS code from websites with similar code and charging money for it.
A few years ago I was helping a friend who wanted to launch a custom printing (t-shirts and other items) business. He hired someone on a freelancer site to make him a JS tool to add pictures to items, visualize them, etc. He hired three different people in order to have the ability to pick the better solution. In all three cases he got code lifted from existing commercial websites doing similar work. They didn't even bother to remove identifying information from the code. I can see thousands of less sophisticated users of these sites not realize they are being sold stolen code.
Anyhow, I thought WASM would allow one to make a serious investment in R&D and deliver reasonably protected highly-performant in-browser tools for various applications. I don't think that is the case, except, potentially, for the case where the end-user would access the tools behind a login and is "filtered" (B2B SaaS tools behind a login, etc.).
It doesn't quite throw css/js/html out of the window (yet) but it does remove the historic limitation that browsers have had of that being the only thing that worked in them. So, it gives people more choice and indeed the option to not bother at all with html+javascript+css.
That stack has always been a bit limiting and dated as technologies. There's a reason why people feel the need to do native apps on mobile: it's a competitive space and those limitations are simply not acceptable there.
Browser based applications have gotten away with being merely good enough (some would argue barely good enough) for the last 20 years mainly because the tradeoff of them working in any browser was worth some sacrifices with respect to UX, design, performance, etc. Now we are getting some more options.
It's specifically meant to render HTML, JS, CSS layouts. If it's just a shell hosting a WASM application, you may as well get rid of the browser altogether.
This is where I get confused. It's sort of like what Electron has done to make "web applications" into desktop applications, but here we are talking about true desktop applications, not HTML pages inside an OS shell.
I can't see where this all headed, I'm sure it will become clearer over the coming years.
Just think of WASM as a cross-platform instruction set, similar to .NET or JVM bytecode, but with a few internal design differences, and suddenly everything makes a lot more sense.
Most importantly: "WebAssembly" isn't tied to the web, nor has it anything to do with assembly.
Hot take: WASM is a dead technology and has failed to displace vanilla JS. There are only a few very niche use cases, most of which have zero product-market fit (e.g., no one wants to play video games in a browser).
Furthermore, no one wants to seriously write C++/Rust/Java and then compile it to WASM. These days, WASM projects are a neat way to pad your resume or get tech "thought leaders" to tweet about you. As far as Extism goes, it sounds like a problem looking for a solution. We already have LUA and JS as embeddable scripting languages, so here we go overengineering yet again.
yeah I don't understand the hype. Every release of wasmwhatever seems to make the front page here. But the number of real products using the technology seems miniscule. It's been out for many years, if it was going to change the world it seems like it should be making more progress.
Have some hope on Component Model (this is kinda module system for the whole WASI thing). It wasn't growing because .. bespoke ABI for different langs and bespoke interfaces between host<->guest. Lack of guide too, it's mostly specification which is hard to read.
You are wrong and missing the point. I mostly agree with you and had the same opinion. BUT, the “money” is in the runtime and the real isolation of code and capability based access.
Forget about the browser, games, etc ( at least for now) and think about the server, dock and kubernetes.
If developers adopt a plug-in model of programming it will be a game changer. I don’t have a crystal ball but that’s what’s fueling wasm right now and it has merits
Erm, WASM works just fine on iOS Safari since a very long time now? I can't remember when I dropped the asm.js fallback for my WASM stuff, maybe around 2017/18? And unlike Chrome, the switch from asm.js to WASM actually made a massive performance difference on Safari, because the Safari team never bothered to add special support for asm.js.
Yeah, I meant on android you can use it to make a webapp that goes full screen, can be granted position info etc. by the user, and push notifications. A PWA in other words. Apple doesn't want PWAs, as they circumvent control of the appstore.
Yeah, I meant on android you can use it to make a webapp that goes full screen, can be granted position info etc. by the user, and push notifications. A PWA in other words. Apple doesn't want PWAs, as they circumvent control of the appstore.
WASM is involved because webapps would be a primary usecase for it. A way to deploy your webapp with more performance and less effort at obfuscation. If webapps aren't first class citizens, the effort to port buts of your native and webapp together to make a WASM based PWA has a lower ROI.
A quick search show plenty of articles talking about the limitations of webapps on iOS. Here is one, it is a year old, but then most WASM project repos I look at haven't had a commit in that long...
I'm not attacking anyone's choices. I don't particularly love the idea of all these blackbox WebApps and the more stuff we let theough the sandbox the bigger the attack surface. Once again Apple's motive to retain complete control aligns with the motive to keep devices secure. I don't like native apps either for the most part, black boxes with even more attack surface. If webapps with less attack surface displace native apps with more, I mostly call that a win.
I write embedded numeric heavy code in c++/cuda and rust, so it is at best peripheral to my day job, meaning I don't have the expertise or motivation to have a strong opinion. I'm engaging in the conversation primarily to learn.
> A quick search show plenty of articles talking about the limitations of webapps on iOS.
Again: "PWAs" are a dozen different standards (or perhaps more). And everyone selects a different subset of them to call "the one true PWA".
For example, some may say that "omg I need direct access to Bluetooth or other hardware APIs". Well, those are Chrome-only non-standards that neither Firefox nor Safari will implement.
There are some like push notifications which are debatable (but arriving in Safari this year). And then there's background sync that Chrome enabled by default in 2016, and which still had issues in 2019 that both Firefox and Safari objected to: https://github.com/mozilla/standards-positions/issues/214 No idea what their position on it is now.
And so on and so forth.
But these articles and half of HN will scream until they are blue in the face claiming that "it's Safari that's holding the PWAs back". Where reality is more complex and the narrative is mostly driven by Chrome, unfortunately.
> Doesn't that throw all of HTML, CSS, etc out the window?
It doesn't. Because those things are already in the browser. With WASM you'll need to download the entire runtime for your app before you're able to run anything.
And you still need to go through the browser to display anything
> And you still need to go through the browser to display anything
No, you don't, and even if that was the case you can just throw a <canvas> tag on a page and render whatever custom UI you want to that, sort of like one of Flutter's web output options is.
This scraps decades of work in HTML, JS, CSS, engines like V8 and SpiderMonkey, etc.
You may as well just toss the browser out the window and consider it a "program" you are running from the internet.
> No, you don't, and even if that was the case you can just throw a <canvas> tag on a page and render whatever custom UI you want to that
Ah, yes. Canvas. Tell me, what is the API for canvas exposed to WASM (hint: there isn't one, you go through the Javascript API)
> This scraps decades of work in HTML, JS, CSS, engines like V8 and SpiderMonkey, etc.
And instead it forces you to do the same decades of wrok because you have to re-invent the whole rendering part from scratch (including the funny little case of accessibility). Canvas couldn't even render text properly until relatively recently.
> You may as well just toss the browser out the window and consider it a "program" you are running from the internet.
Well, of course you can't. Because there are literally no APIs exposed to WASM except a Javascript bridge.
I think one reason many people are really interested in WASM is because it creates the possibility of a secure runtime environment that can be used outside browsers too.
Uh oh, they still don't seem to have fully relinquished their claims to the name "WebAssembly". Their vscode package is listed under "WebAssembly Foundation".
It's been this way for a little bit already (actually since 3 years ago! [1]).
It was an intentional thing though, because we want to put this extension under a common group, not something that only Wasmer owns... that's why we haven't changed it yet. But I agree that probably using WebAssembly Foundation is perhaps not the best name :)
You actually gave me a great idea!
Perhaps we can rename it to OpenWasm Foundation (I think that's a great name, your suggestion inspired me). I will discuss with more people to see what name will make more sense to rename it to.
And please let me know if you have other suggestions!
Good luck. I wouldn't mind having multiple organizations. The Bytecode Alliance is great but I would rather people recognize that WebAssembly belongs to the W3C (or everyone via the W3C if you prefer to think of it that way) and not them or the CNCF.
Interesting, sounds like the. Kubernetes in tree vs out of tree + CSI situation.
In the end the real solution was this:
> All host generators are being removed from this repository for example here and here. The JS generator will eventually move to its own repository as well, just takes time.
Should have been what they did from the start, but I understand how they could have put it off. Thread was informative with regards to understanding where the rifts in the community are and how people think though.
I'm not entirely convinced Wasmer will ever be able to shake its constant controversies.
I'm by no means a fan of the Bytecode Alliance, and would much prefer a startup tackle the problems that Wasmer is tackling, but between the trademarks [1], the lackluster response to the trademarks (How did you not know your lawyers were trying to trademark “WebAssembly”? Seriously?) [2], the working conditions [3], the drama surrounding the BCA [4][5], and everything else, I don't think Wasmer is the right choice either, at least not under current leadership.
One of the most exciting aspects of wasm is a safer and more expressive API surface for universal FFI. Currently, the lowest common denominator is the C ABI. In the future, it could be wasm.
Obviously wasm can be much more, but just that alone can be really useful.
* No custom language-A to language-B bindings necessary, only 1 wasm binding per lang. That's O(N) bindings in total, instead of O(N^2), which isn't feasible and that's why we don't have Julia-intercal or PHP-Java today (or maybe we do?)
How would (e.g.) strings work in this FFI, considering that wasm doesn’t have a built-in string type or any way to pass variable-length data to a function without allocating space for it in the instance’s memory, and languages have different native string representations (UTF-8 vs UTF-16 vs “UTF-16”)?
Very poorly considering that it seems like all the people doing wasm FFI work have decided that UTF-16/WTF-16 based language maintainers can pound sand and unless your native string type is UTF-8 your string performance is gonna suck.
It's sad since many widely used runtimes (JS, Java, .NET) and one widely used operating system (Windows) all use WTF-16. UTF-8 is great and all but reality needs to be taken into account when drafting specs...
That's a cool question. There are several aspects to that. One is storage and another is encoding.
Let's start with storage. C strings, for instance, are terminated by NUL (zero) characters. Are they good enough? You would never answer that question unless you are somehow versed in math. From the mathematical standpoint, it is a mistake to narrow down the space by giving its elements special meaning. Imagine an integer number from -100 to 100. Would you be happy if somebody said you that you cannot use zero because "it has a special meaning"? No, you would be outraged every time you need to use it! (even if it's a rare event). So, from the mathematical standpoint universal strings cannot give special meanings to its characters.
Now to the encoding. Is UTF-8 good enough? Or maybe UTF-16? Or something else? How to decide? Let's use math. From the math standpoint, it's always preferable to use an existing concept if it fulfills the need. So, it means that we should use the existing encoding scheme to avoid reinventing the wheel. The next thing the math dictates is that: the most minimal and normalized thing is always preferable to more complex synthetic things provided that they all do the job. This puts UTF-8 encoding at a special place - it's minimal and universal as it can encode the endless number of Unicode symbols (if we, for whatever reason, will decide to colonize the space and consequently add some more billions of characters to Unicode to dial the new cultures and knowledge in).
What to do we have in result? UTF-8 string is universal and should be used in a standard component model.
But how to encode string length? We already decided that giving special meaning to the NUL characters is a no-go from the math standpoint because it is opinionated and thus informal. The formal approach says that we should store the length of a string alongside the string itself. The beginning of the string is the right place because we want to know string length beforehand. What should we use? Is 32-bit unsigned integer good enough? It surely will be enough for anyone for all times, right? But the math says that a 32-bit unsigned integer can only represent [0, 2^32) range of string lengths. That's not universal because, you know, there may be foreign cultures out there in the universe who have longer strings than that. So what should we use then? The answer is: an unsigned infinite integer number with variable length encoding. We already have a Variable-Length Quantity (VLQ) concept, so let's use just that because it's already invented and universal.
What do we have in the final result? The answer may surprise you: UTF-8 encoded Pascal-like immutable strings, where the string lengths are located at the start of the string and encoded with VLQ encoding. They are formally universal and pass the high mark of a standard component model as we may call it some day.
At the same time, this way of building strings is quite a departure from what we have now and will have performance implications. That's why we should cut corners to make such level of universality to be practical in the computer world. An obvious measure we can take is to use size_t instead of VLQ-encoded integer for string length representation. The computer memory cannot hold strings larger than that anyway, so this will do the job. The math behind this decision is formal and clear: max_string_size = min(∞, 2 ^ sizeof(size_t)) = 2 ^ sizeof(size_t).
This also means that a standard component model should have a notion of size_t-like type which is tied to the memory size of a host architecture. In this way, we make our component model dependent on a host architecture. In return, we get considerable performance benefits while preserving the formal universality which is a win.
I did a test of an ALU/BP(non-vecorized JSON deserialization) heavy library last year and the price of Wasmer/wasm was only about 20-25%. For many things, that's not going to even be noticed.
"The Amsterdam Compiler Kit (ACK) is a retargetable compiler suite and toolchain written by Andrew Tanenbaum and Ceriel Jacobs, since 2005 maintained by David Given. It has frontends for the following programming languages: C, Pascal, Modula-2, Occam, and BASIC."
"The ACK's notability stems from the fact that in the early 1980s it was one of the first portable compilation systems designed to support multiple source languages and target platforms."
"Maximum portability is achieved by using an intermediate language using bytecode, called EM. Each language front-end produces EM object files, which are then processed through several generic optimisers before being translated by a back-end into native machine code.
ACK comes with a generic linker and librarian capable of manipulating files in the ACK's own a.out-based format; it will work on files containing EM code as well as native machine code. However, EM code cannot be linked to native machine code without translating the EM binary first. "
"One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language."
> "The Amsterdam Compiler Kit (ACK) is a retargetable compiler suite. It has frontends for the following programming languages: C, Pascal, Modula-2, Occam, and BASIC."
All those languages have only plain data and functions, no OOP. So it's just a C-like FFI all over again.
It does not matter whether it's a bytecode or native code: instruction set is a totally separate thing from the component model.
> There are already nearly two dozen languages being developed for Visual Studio .NET
... that can only be used from .NET. And that's the point about the absence of universality. Well, you can export functions (DllExport). However, it would be just a plain FFI.
WASM is a runtime only. It does not try to define a component model. And that's a bonus for its wider appeal and adoption.
You can treat WASM just like you treat a CPU architecture. One among many. It does its thing and does it reasonably well (official 64 bit support would be awesome though).
But trying to tie a component model to a specific CPU is kind of a bad idea, don't you think so? For me it causes immediate Intel iAPX 432 vibes and I fear that WASM may diverge in that utopian direction some day.
That page seems to seed wrongful directions without understanding their true consequences. This may render WASM as another Macromedia Flash of its time if those aspirations materialize.
You don't have to use the component model in CLR. And if you do not, the remaining subset is basically just as expressive as wasm - you can compile C to it, for example. It's "just like a CPU architecture". And then you can build your own component models on top of that, or FFI with existing ones (I had to do this with COM once instead of using COM Interop - it was all hand-rolled with structs etc).
Between WebAssembly, Cloudflare Durable Objects/Workers are the equivalents from Fly.io, it seems we are finally recreating the features of IBM System/360 mainframe from 50 years ago, in terms of portable code that could run reliably and scalably even with faulty hardware.
WebAssembly is the modern 360 Assembler that allows you to compile once and run anywhere.
(Kubernetes is the modern JCL)
Ah it's these guys that tried and still try to hijack the glory of webassembly just for their startup to succeed. Wasmer is doomed to fail cause it's leadership smells fishy.
Btw a packaging solution has already started to be designed by the people that actually care about the wasm ecosystem, so it's not going to be wapm.
Hi, I'm Syrus from Wasmer. I usually try not to get drawn into hate comments that don't add any value, but I'll make an exception today as it's sunny here in San Francisco!
We care deeply about the Wasm ecosystem. In fact, we care so much that we are wary of putting it at mercy of the big tech.
Wasm is a beautiful community that should embrace many points of view, starting from the Web and permeating back to the servers.
I think is a strength to collaborate, to let developers with different points of view discuss without forcing one unique point of view on all.
Unfortunately it will not be a surprise for some to learn that certain players on the industry want to force their unique perspective on the rest, where only "one way" is the right way of doing things. I'm betting my horses (I have two parked in the hallway), that the packaging initiative that you are talking about comes from these groups.
Thankfully, Wasmer is probably one of the few companies with great context on how to do a Package Manager in WebAssembly (we started it 3 years ago, and got tons of learnings since then!), so just trying to replicate without collaboration seems like a big mistake (best of luck to them there!).
In any case, I'm not the only person that feels this way and I know this feeling is shared by big part of the Wasm community.
I like the idea, but I do not like that it's for WASM only. What about other runtimes and languages?
In general, I'm very skeptical about yet another runtime + component model combo. This makes the situation O(N^2) once again: every runtime has its own component model instead of having a standard component model that can be used from any runtime. This path has been deemed unsatisfactory far too many times: Java, .NET, BEAM etc (they're fine as long as you're inside the ecosystem).
This is why we only have FFI as lingua franca between the languages. We cannot agree on a standard component model yet. And runtime has nothing to do with it.
would it be possible, for example, to access the standard decimal library of C# or Python via Javascript, thus not having to wait for the TC39 spec / implementation? [1]
The code you want to use has to compile to Webassembly.
This is in fact possible for C# and Python, but especially in the browser you would want to have a small binary size, and avoid bringing along the whole runtime of these managed languages if all you want is a small functionality subset.
A very viable solution would be creating a decimal package with either a native Rust crate (I think there are a few decimal implementations) or with one of the goto C libraries.
In her wasm summit presentation [1], Ashley Williams had a slide that showed a different picture. AssemblyScript came out with the smallest footprint, while Rust and C (through Emscripten) had bigger footprints--the slide is qualitative.
An article posted last week on HN [2] also seems to support this hypothesis, this time with some numbers. The AssemblyScript program had 6% the filesize of the Rust program.
So it seems like, if you want small wasm libraries, AssemblyScript may be your best shot.
Decimal values are not currently represented as a first-class type by WAI (as int, floats or string types are) but I believe it would be a great idea to do so.
Would you mind opening an issue in the WAI repository [1] so we can follow up there? Thanks!
Probably a known thing for those already working with wasm but I had to install the rust nightly compiler and add the `wasm32-unknown-unknown` target to get this demo to work.
It would be worth mentioning on the demo walkthrough.
wasmer add --pip wai/tutorial-01
Querying WAPM for package bindings
error: Unable to find bindings for wai/tutorial-01@latest
╰─▶ 1: The package doesn't contain any bindings
I guess one needs to publish a pip package? pip has very high requirements to publishing packages. the wai tutorial gives zero info on how to create a local pip package.
/opt/wasm/wai/tutorial-01/ python3 consume.py
Traceback (most recent call last):
File "/opt/wasm/wai/tutorial-01/consume.py", line 2, in <module>
from tutorial_01 import bindings
File "/opt/homebrew/lib/python3.10/site-packages/tutorial_01/__init__.py", line 7, in <module>
from wasmer import Store as _Store # type: ignore
File "/opt/homebrew/lib/python3.10/site-packages/wasmer/__init__.py", line 1, in <module>
raise ImportError("Wasmer is not available on this system")
ImportError: Wasmer is not available on this system
Hey, Syrus here from Wasmer. This is the first time I'm hearing from this.
No, there shouldn't be any security concerns in our website (it's actually fully open source as well [1], if you want to take a look)
Do you happen to know what firewall does your work use? I'd love to follow up with them to make sure this is resolved asap
I remember that a couple of years ago any wasm file hosted on any github page would be blocked by the EasyPrivacy list (apparently some idiots used github pages to host coin miners). Maybe it's a similar over-eager blocking rule.
Not sure what's up. No idea what the local filter software is.
I'll fill out the local complaint form.
wasm files are being served up from github.io , so wasm files, per se, are not the problem.
Not really “on the verge” considering how long it took to migrate most projects from Python2 to Python3. I mean, people won’t just drop existing projects, and adoption will be awfully slow.
There was another one on the front page today that allowed you to use WASM to program other programming languages ("Extism: make all software programmable").
Where are we headed with all of this?
I can see a future where WASM supports GC-languages, then you esentially have things like C# or Java desktop applications running "in the browser" via WASM? Doesn't that throw all of HTML, CSS, etc out the window?
Honest question, sorry if it's dumb. But all these WASM terms, releases, etc. have me completely lost. I'll stick to my day job.
Wasm is essentially a target bytecode and runtime based on the well tread security model of javascript in the browser.
Browsers can run it, languages can compile to it, apps of any language can host a runtime that runs it. This leads to infinite permutations and nesting of concepts.
Because its web tech there's a dozen ways to do the same thing.
I have zero experience with it, but I think I get it and it's neat. I'm a little curious about what working with the DOM is like in C# > WASM or Rust > WASM. I pitty the foo who had to code that... and will we get non-breaking, more efficient native DOM manipulation at some point?
There was a "predecessor" project (Asm.js) that would output low level JS, though.
https://stackoverflow.com/questions/31502563/what-is-the-dif...
Maybe they'll gain some new life as a natural home for WASM.
In any case, it seems that there will be multiple ways of generating bindings going on in the future. And you will probably need to pick the option will fit better your needs! (similarly as how you can use Protocol Buffers, Cap'N'Proto or Thrift).
[1]: https://extism.org/
> But all these WASM terms, releases, etc. have me completely lost.
I don't blame you, I work on this and even for me it's a bit hard to keep up. Hopefully things will improve and become more clear over time!
https://www.destroyallsoftware.com/talks/the-birth-and-death...
To the future where Silicon Valley funded startups try to find angles to extract value from WASM. A lot of competing efforts with different business models.
Hopefully in the end we get good VC funded open source and can discard any too aggressive monetisation attempts.
There are also GC'd languages ported to WASM, things like Pyodide, but they're pretty big and have some rough edges as they're not normally allowed to do things like make network calls.
WASM is just a virtual machine, sort of like the JVM, but that runs in the browser. It might help to think of WASM (Web-ASseMbly) as a new CPU architecture. It's a minimal CPU instruction set (a virtual instruction set) that can be relatively easily jitted or transpiled into machine code.
WASM by itself doesn't do anything, the specs for what kind of interfaces exist between the WASM sandbox and the host app are still sort of in the air. It's soft of like saying "what can I do with a RISC-V CPU". The answer is "not much until we make more infrastructure that supports it.
Right now you can port large C code bases over to run in a browser with emscripten so that's nice. Maybe you'll write a web component using WASM at some point.
But doesn't this have the potential for a massive, paradigm shift in how we look at the "web"?
Take just one example, a GC language like C# or Java being able to run under WASM (inside a web browser?).
It could bypass HTML, CSS, and JS entirely and just run as if it were a desktop application.
Doesn't this lead us down the rabbit hole back to Java applets, Flash plugins and other similar plugins, albeit more secure/sandboxed?
If every website is free to render a button using any programming language it wants, there is no longer any standardization, accessibility features, a layout engine, etc.
What is the point of a "web browser" at all, if all it does is host a WASM-based application?
I think that's the part where my brain starts to give up.
>What is the point of a "web browser" at all, if all it does is host a WASM-based application?
It's to get around various walled gardens apparently.
I can imagine any number of media companies who would love to continue using their current web-dev pipeline but, by walling access to their servers off to this “trusted” WASM browser, could be reasonably assured that users aren’t using ad blockers, archive bots, etc. It’s the next logical extension of those ridiculous scripts that you used to see, popping up a “Access denied” message on a right-click because the website owner wanted to limit “view source”. The kind of numbskull who would do that would love a WASM-based browser.
Not quite, because in order to display anything to the user, it still has to use HTML/CSS/JS
Webassembly was designed to be usable outside of the browser, and multiple native runtimes already exist for it. It doesn't require the web stack, that just happens to be the most convenient way to use it at the moment.
Then what do we have?
A C# desktop application running under WASM inside a browser with a custom UI rendered to a <canvas> element?
Is that where this is going?
https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
Sorry for long whining, Webassembly should have materials for 1) a complete guide on how to write it by hand 2) have a toy language as a source to demonstrate how to map its ast to wasm instruction, it should cover at least 60-70% of wasm essential features.
Stop pointing to c++/rust/and tool chains. It's doesn't help understanding Webassembly itself.
You are not alone.
On my side of things, I've been looking for an approach to deliver non-trivial in-browser apps while protecting the codebase from theft. In the early days I thought WASM could be that. I don't know any more. JS is a non-starter. It is common knowledge that sites where you hire freelancers to write code often result in these freelancers simply stealing JS code from websites with similar code and charging money for it.
A few years ago I was helping a friend who wanted to launch a custom printing (t-shirts and other items) business. He hired someone on a freelancer site to make him a JS tool to add pictures to items, visualize them, etc. He hired three different people in order to have the ability to pick the better solution. In all three cases he got code lifted from existing commercial websites doing similar work. They didn't even bother to remove identifying information from the code. I can see thousands of less sophisticated users of these sites not realize they are being sold stolen code.
Anyhow, I thought WASM would allow one to make a serious investment in R&D and deliver reasonably protected highly-performant in-browser tools for various applications. I don't think that is the case, except, potentially, for the case where the end-user would access the tools behind a login and is "filtered" (B2B SaaS tools behind a login, etc.).
That stack has always been a bit limiting and dated as technologies. There's a reason why people feel the need to do native apps on mobile: it's a competitive space and those limitations are simply not acceptable there.
Browser based applications have gotten away with being merely good enough (some would argue barely good enough) for the last 20 years mainly because the tradeoff of them working in any browser was worth some sacrifices with respect to UX, design, performance, etc. Now we are getting some more options.
It's specifically meant to render HTML, JS, CSS layouts. If it's just a shell hosting a WASM application, you may as well get rid of the browser altogether.
This is where I get confused. It's sort of like what Electron has done to make "web applications" into desktop applications, but here we are talking about true desktop applications, not HTML pages inside an OS shell.
I can't see where this all headed, I'm sure it will become clearer over the coming years.
Most importantly: "WebAssembly" isn't tied to the web, nor has it anything to do with assembly.
We are heading nowhere.
Hot take: WASM is a dead technology and has failed to displace vanilla JS. There are only a few very niche use cases, most of which have zero product-market fit (e.g., no one wants to play video games in a browser).
Furthermore, no one wants to seriously write C++/Rust/Java and then compile it to WASM. These days, WASM projects are a neat way to pad your resume or get tech "thought leaders" to tweet about you. As far as Extism goes, it sounds like a problem looking for a solution. We already have LUA and JS as embeddable scripting languages, so here we go overengineering yet again.
Nowadays the whole hype about WASM containers is basically reselling what Java and .NET application servers have been doing for 20 years.
Forget about the browser, games, etc ( at least for now) and think about the server, dock and kubernetes.
If developers adopt a plug-in model of programming it will be a game changer. I don’t have a crystal ball but that’s what’s fueling wasm right now and it has merits
WASM has been on Safari since version 11 released 5 years ago. Same year it became available on Chrome and Firefox.
Apple has supported the absolute vast majority of them since forever. And they have literally nothing to do with doing anything in WASM.
A quick search show plenty of articles talking about the limitations of webapps on iOS. Here is one, it is a year old, but then most WASM project repos I look at haven't had a commit in that long...
https://hub.tigrenpwa.com/pwa-on-ios/
I'm not attacking anyone's choices. I don't particularly love the idea of all these blackbox WebApps and the more stuff we let theough the sandbox the bigger the attack surface. Once again Apple's motive to retain complete control aligns with the motive to keep devices secure. I don't like native apps either for the most part, black boxes with even more attack surface. If webapps with less attack surface displace native apps with more, I mostly call that a win.
I write embedded numeric heavy code in c++/cuda and rust, so it is at best peripheral to my day job, meaning I don't have the expertise or motivation to have a strong opinion. I'm engaging in the conversation primarily to learn.
Again: "PWAs" are a dozen different standards (or perhaps more). And everyone selects a different subset of them to call "the one true PWA".
For example, some may say that "omg I need direct access to Bluetooth or other hardware APIs". Well, those are Chrome-only non-standards that neither Firefox nor Safari will implement.
There are some like push notifications which are debatable (but arriving in Safari this year). And then there's background sync that Chrome enabled by default in 2016, and which still had issues in 2019 that both Firefox and Safari objected to: https://github.com/mozilla/standards-positions/issues/214 No idea what their position on it is now.
And so on and so forth.
But these articles and half of HN will scream until they are blue in the face claiming that "it's Safari that's holding the PWAs back". Where reality is more complex and the narrative is mostly driven by Chrome, unfortunately.
It doesn't. Because those things are already in the browser. With WASM you'll need to download the entire runtime for your app before you're able to run anything.
And you still need to go through the browser to display anything
No, you don't, and even if that was the case you can just throw a <canvas> tag on a page and render whatever custom UI you want to that, sort of like one of Flutter's web output options is.
This scraps decades of work in HTML, JS, CSS, engines like V8 and SpiderMonkey, etc.
You may as well just toss the browser out the window and consider it a "program" you are running from the internet.
Ah, yes. Canvas. Tell me, what is the API for canvas exposed to WASM (hint: there isn't one, you go through the Javascript API)
> This scraps decades of work in HTML, JS, CSS, engines like V8 and SpiderMonkey, etc.
And instead it forces you to do the same decades of wrok because you have to re-invent the whole rendering part from scratch (including the funny little case of accessibility). Canvas couldn't even render text properly until relatively recently.
> You may as well just toss the browser out the window and consider it a "program" you are running from the internet.
Well, of course you can't. Because there are literally no APIs exposed to WASM except a Javascript bridge.
Presumably once I've made progress on rust the rest will have settled down into something more cohesive
https://marketplace.visualstudio.com/publishers/dtsvet
It was an intentional thing though, because we want to put this extension under a common group, not something that only Wasmer owns... that's why we haven't changed it yet. But I agree that probably using WebAssembly Foundation is perhaps not the best name :)
[1]: https://github.com/wasmerio/vscode-wasm/commit/0f7f00f44aa72...
https://en.wikipedia.org/wiki/WebAssembly
I like that OpenJS Foundation is called OpenJS Foundation and not JS Foundation.
That said, the main thing I object to is the trademark.
And please let me know if you have other suggestions!
I 300% agree with you on this
https://github.com/bytecodealliance/wit-bindgen/issues/306
In the end the real solution was this:
> All host generators are being removed from this repository for example here and here. The JS generator will eventually move to its own repository as well, just takes time.
Should have been what they did from the start, but I understand how they could have put it off. Thread was informative with regards to understanding where the rifts in the community are and how people think though.
I'm by no means a fan of the Bytecode Alliance, and would much prefer a startup tackle the problems that Wasmer is tackling, but between the trademarks [1], the lackluster response to the trademarks (How did you not know your lawyers were trying to trademark “WebAssembly”? Seriously?) [2], the working conditions [3], the drama surrounding the BCA [4][5], and everything else, I don't think Wasmer is the right choice either, at least not under current leadership.
[1] https://uspto.report/company/Wasmer-Inc
[2] https://wasmer.io/posts/wasmer-and-trademarks
[3] https://mnt.io/2021/10/04/i-leave-wasmer/
[4] https://github.com/wasmerio/wasmer/issues/956
[5] https://github.com/WebAssembly/WASI/issues/3
Obviously wasm can be much more, but just that alone can be really useful.
* No custom language-A to language-B bindings necessary, only 1 wasm binding per lang. That's O(N) bindings in total, instead of O(N^2), which isn't feasible and that's why we don't have Julia-intercal or PHP-Java today (or maybe we do?)
It's sad since many widely used runtimes (JS, Java, .NET) and one widely used operating system (Windows) all use WTF-16. UTF-8 is great and all but reality needs to be taken into account when drafting specs...
Let's start with storage. C strings, for instance, are terminated by NUL (zero) characters. Are they good enough? You would never answer that question unless you are somehow versed in math. From the mathematical standpoint, it is a mistake to narrow down the space by giving its elements special meaning. Imagine an integer number from -100 to 100. Would you be happy if somebody said you that you cannot use zero because "it has a special meaning"? No, you would be outraged every time you need to use it! (even if it's a rare event). So, from the mathematical standpoint universal strings cannot give special meanings to its characters.
Now to the encoding. Is UTF-8 good enough? Or maybe UTF-16? Or something else? How to decide? Let's use math. From the math standpoint, it's always preferable to use an existing concept if it fulfills the need. So, it means that we should use the existing encoding scheme to avoid reinventing the wheel. The next thing the math dictates is that: the most minimal and normalized thing is always preferable to more complex synthetic things provided that they all do the job. This puts UTF-8 encoding at a special place - it's minimal and universal as it can encode the endless number of Unicode symbols (if we, for whatever reason, will decide to colonize the space and consequently add some more billions of characters to Unicode to dial the new cultures and knowledge in).
What to do we have in result? UTF-8 string is universal and should be used in a standard component model.
But how to encode string length? We already decided that giving special meaning to the NUL characters is a no-go from the math standpoint because it is opinionated and thus informal. The formal approach says that we should store the length of a string alongside the string itself. The beginning of the string is the right place because we want to know string length beforehand. What should we use? Is 32-bit unsigned integer good enough? It surely will be enough for anyone for all times, right? But the math says that a 32-bit unsigned integer can only represent [0, 2^32) range of string lengths. That's not universal because, you know, there may be foreign cultures out there in the universe who have longer strings than that. So what should we use then? The answer is: an unsigned infinite integer number with variable length encoding. We already have a Variable-Length Quantity (VLQ) concept, so let's use just that because it's already invented and universal.
What do we have in the final result? The answer may surprise you: UTF-8 encoded Pascal-like immutable strings, where the string lengths are located at the start of the string and encoded with VLQ encoding. They are formally universal and pass the high mark of a standard component model as we may call it some day.
At the same time, this way of building strings is quite a departure from what we have now and will have performance implications. That's why we should cut corners to make such level of universality to be practical in the computer world. An obvious measure we can take is to use size_t instead of VLQ-encoded integer for string length representation. The computer memory cannot hold strings larger than that anyway, so this will do the job. The math behind this decision is formal and clear: max_string_size = min(∞, 2 ^ sizeof(size_t)) = 2 ^ sizeof(size_t).
This also means that a standard component model should have a notion of size_t-like type which is tied to the memory size of a host architecture. In this way, we make our component model dependent on a host architecture. In return, we get considerable performance benefits while preserving the formal universality which is a win.
Amsterdam Compiler Toolkit, 40 years ago.
CLR since 2002.
It provided only a plain C-like API, without OOP classes and stuff, pretty much like anyone else.
> CLR since 2002
It's only for .NET, it's opinionated, so not a universal thing.
"The Amsterdam Compiler Kit (ACK) is a retargetable compiler suite and toolchain written by Andrew Tanenbaum and Ceriel Jacobs, since 2005 maintained by David Given. It has frontends for the following programming languages: C, Pascal, Modula-2, Occam, and BASIC."
"The ACK's notability stems from the fact that in the early 1980s it was one of the first portable compilation systems designed to support multiple source languages and target platforms."
"Maximum portability is achieved by using an intermediate language using bytecode, called EM. Each language front-end produces EM object files, which are then processed through several generic optimisers before being translated by a back-end into native machine code.
ACK comes with a generic linker and librarian capable of manipulating files in the ACK's own a.out-based format; it will work on files containing EM code as well as native machine code. However, EM code cannot be linked to native machine code without translating the EM binary first. "
-- https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit
"One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language."
-- February 2002 issue of MSDN Magazine
https://learn.microsoft.com/en-us/archive/msdn-magazine/2002...
A common theme among WASM advocates....
All those languages have only plain data and functions, no OOP. So it's just a C-like FFI all over again.
It does not matter whether it's a bytecode or native code: instruction set is a totally separate thing from the component model.
> There are already nearly two dozen languages being developed for Visual Studio .NET
... that can only be used from .NET. And that's the point about the absence of universality. Well, you can export functions (DllExport). However, it would be just a plain FFI.
You can treat WASM just like you treat a CPU architecture. One among many. It does its thing and does it reasonably well (official 64 bit support would be awesome though).
But trying to tie a component model to a specific CPU is kind of a bad idea, don't you think so? For me it causes immediate Intel iAPX 432 vibes and I fear that WASM may diverge in that utopian direction some day.
This GitHub page seems to contradict that:
https://github.com/WebAssembly/component-model/blob/main/des...
https://www.youtube.com/watch?v=phodPLY8zNE&list=PLj6h78yzYM...
Or is it WinRT?
Maybe Apple's XPC.
Or could it be Android Binder, or Fucshia IDL?
https://github.com/WebAssembly/component-model/blob/main/des...
Btw a packaging solution has already started to be designed by the people that actually care about the wasm ecosystem, so it's not going to be wapm.
We care deeply about the Wasm ecosystem. In fact, we care so much that we are wary of putting it at mercy of the big tech. Wasm is a beautiful community that should embrace many points of view, starting from the Web and permeating back to the servers.
I think is a strength to collaborate, to let developers with different points of view discuss without forcing one unique point of view on all. Unfortunately it will not be a surprise for some to learn that certain players on the industry want to force their unique perspective on the rest, where only "one way" is the right way of doing things. I'm betting my horses (I have two parked in the hallway), that the packaging initiative that you are talking about comes from these groups.
Thankfully, Wasmer is probably one of the few companies with great context on how to do a Package Manager in WebAssembly (we started it 3 years ago, and got tons of learnings since then!), so just trying to replicate without collaboration seems like a big mistake (best of luck to them there!).
In any case, I'm not the only person that feels this way and I know this feeling is shared by big part of the Wasm community.
I wrote a bit more about this here as well: https://news.ycombinator.com/item?id=33805585
What do you mean by that? What are they doing, apart from existing as a company in the webassembly ecosystem?
In general, I'm very skeptical about yet another runtime + component model combo. This makes the situation O(N^2) once again: every runtime has its own component model instead of having a standard component model that can be used from any runtime. This path has been deemed unsatisfactory far too many times: Java, .NET, BEAM etc (they're fine as long as you're inside the ecosystem).
This is why we only have FFI as lingua franca between the languages. We cannot agree on a standard component model yet. And runtime has nothing to do with it.
[1] https://github.com/tc39/proposal-decimal
This is in fact possible for C# and Python, but especially in the browser you would want to have a small binary size, and avoid bringing along the whole runtime of these managed languages if all you want is a small functionality subset.
A very viable solution would be creating a decimal package with either a native Rust crate (I think there are a few decimal implementations) or with one of the goto C libraries.
That would be much smaller and faster as well.
An article posted last week on HN [2] also seems to support this hypothesis, this time with some numbers. The AssemblyScript program had 6% the filesize of the Rust program.
So it seems like, if you want small wasm libraries, AssemblyScript may be your best shot.
Although it has to be said that you can get Rust code to be really small if you know what you are doing and work towards it.
But I recommended Rust or C because there are reasonably mature decimal implementations. No idea if there is one for Assemblyscript.
Would you mind opening an issue in the WAI repository [1] so we can follow up there? Thanks!
[1] https://github.com/wasmerio/wai
Wasmer and others are just making things more confusing, bloated and slower, this is not how i envision WASM to be
It would be worth mentioning on the demo walkthrough.
This link was helpful: https://www.hellorust.com/setup/wasm-target/
I guess one needs to publish a pip package? pip has very high requirements to publishing packages. the wai tutorial gives zero info on how to create a local pip package.
EDIT: (+25 min) The command should be fully working now
/opt/wasm/wai/tutorial-01/ python3 consume.py Traceback (most recent call last): File "/opt/wasm/wai/tutorial-01/consume.py", line 2, in <module> from tutorial_01 import bindings File "/opt/homebrew/lib/python3.10/site-packages/tutorial_01/__init__.py", line 7, in <module> from wasmer import Store as _Store # type: ignore File "/opt/homebrew/lib/python3.10/site-packages/wasmer/__init__.py", line 1, in <module> raise ImportError("Wasmer is not available on this system") ImportError: Wasmer is not available on this system
which wasmer /opt/homebrew/bin/wasmer
wasmer -v wasmer 3.0.2
Content blocked by [redacted]
Reason: This Category is filtered: grayware
Are there security concerns with wasmer.io ?
Do you happen to know what firewall does your work use? I'd love to follow up with them to make sure this is resolved asap
[1]: https://github.com/wasmerio/wasmer.io
One of the best outcomes would allow app developers to avoid app stores and still provide native-like user experiences.
And how is it going to do that when wasm has literally no access to anything, except through browser's HTML, CSS, Javascript etc.?
WebGPU won't be available for a while. It's API is Javascript-only browser API.
Canvas are only accessible through Javascript through the browser.
Next question is: how are you going to accommodate accessibility?