
WebAssembly First Public Working Drafts - EddieRingle
https://www.w3.org/blog/news/archives/6838
======
Ono-Sendai
Had a quick look through, looks interesting. Some thoughts

* Only 32-bit address space (although they do say "Future version of WebAssembly might provide memory instructions with 64 bit address ranges")

* Webassembly is pretty low level. Just 4 basic types (integers, floats). No C-style structures even. This is lower level than e.g. LLVM IR, and lower level than the Java VM.

* No garbage collection support.

I hope Webassembly can be used from not just Javascript, but something like
C++, directly.

~~~
tscs37
I would say that 32bit are more than enough for most web applications. I
struggle to recall any web application that would require more than 4GB of RAM
to run.

~~~
Doxin
Desktop applications are increasingly moving to the web. Regardless of whether
you think this is a good thing, the standard has to take that into account.

~~~
tscs37
I doubt that every single desktop application will move into the web for a
good long while, long enough to have a smooth transition from 32bit to 64bit
if necessary, though I doubt applications that need more will use WASM.

~~~
Doxin
> I doubt that every single desktop application will move into the web for a
> good long while

Oh sure, personally I hope it'll never quite happen. But It'll get there and a
standard needs to be forward-facing.

~~~
moocowtruck
so once all desktop is in the browser, can we then make the browser the sole
interface, and all in one stroke have desktop apps again? Ouroboros eh?

~~~
krapp
WebAssembly apps don't _have_ to be hosted on the web, or run in a browser.
They will, almost exclusively, because the "browser as OS" model is what
modern web developers have fixated on, because of javascript. But, there's no
reason users couldn't install and run WASM natively as well.

------
raisantos
The asp.net team is already hard at work on the Blazor project a web UI
framework using C#/Razor and HTML.
[https://github.com/aspnet/Blazor](https://github.com/aspnet/Blazor)

~~~
akmittal
It uses JavaScript for DOM?

~~~
nickthemagicman
No. I'm imagining it doesn't even have a traditional DOM. It's using it's own
custom rolled framework and web assembly which makes the browser like a blank
canvas. Super cool.

------
mrashes
I really love the idea of WebAssembly but am super intimidated by it. Being a
junior frontend dev it seems like a really powerful piece of tech that could
go in a million directions in the future.

My big hangup is understanding a low level use case for it. I've
console.logged in wasm but only knowing javascript I don't know where to go
from here. Is the idea that you can utilize packages in any language then
rebuild it in js?

~~~
Dude2021
With enough luck and given time you will be able to skip JS at all! If the
community will find the life force after wasting many years on SPA, then we
might even see some HTML—near-free canvas/WebGL GUIs!

~~~
pjmlp
Microsoft is already doing it with .NET, others as well.

Expect the revenge of browser plugins.

~~~
lunfardo
no way a .net plugin become mainstream, thankfully we left behind java-like-
plugins.

~~~
pjmlp
Sorry to disappoint you, but everyone is on the WebAssembly race, all plugins
will be back, like it or not.

[https://github.com/appcypher/awesome-wasm-
langs](https://github.com/appcypher/awesome-wasm-langs)

[https://github.com/mbasso/awesome-wasm](https://github.com/mbasso/awesome-
wasm)

As for Microsoft, they just announced the Blazor project.

[https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-
ex...](https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-experimental-
project/)

Thank browser developers for opening the pandora box.

------
jokoon
I hope this is the future of the web.

If the DOM gets accessible from wasm, we'll finally be able to avoid using
javascript entirely.

It's crazy how much time and effort are necessary to finally be able to make a
piece of software work on any computer, without having to make different high
level graphical API work together.

The cherry on top would be to have both the dom AND websockets.

~~~
themihai
Well, if it will support the DOM I believe it will support any web API(i.e.
including websockets)

------
mr_overalls
Is anyone else afraid that this will enable a "Tower of Babel" effect where
the coming sheer profusion of languages will fragment web programming into
dozens of competing, mutually-incomprehensible linguistic camps.

Javascript sucks, but at least it's the web's lingua franca.

~~~
krapp
>Is anyone else afraid that this will enable a "Tower of Babel" effect where
the coming sheer profusion of languages will fragment web programming into
dozens of competing, mutually-incomprehensible linguistic camps.

That's already happening - web development seems to assume that compiling _to_
javascript from any one of a legion of languages should be standard practice.

------
thefounder
So you still need JS to load/compile wasm or do anything useful(i.e
DOM)...what a disappointment!

~~~
banhfun
Now that makes me wonder what the point of WASM is because we could have
always transpiled code to JS

~~~
bastawhiz
Performance. WebAssembly has no JIT stage, it gets AOT compiled straight to
machine code. Plus, it gives (or will give) much lower-level access to
features like threads and memory allocation.

~~~
kllrnohj
> Plus, it gives (or will give) much lower-level access to features like
> threads and memory allocation.

There's no reason JavaScript couldn't just have those features. It already has
some amount of memory allocation control via ArrayBuffer & DataView.

~~~
imtringued
You're describing asm.js which had significant issues as a compilation target.
The generated javascript code was massive and it took several seconds just to
parse it.

~~~
caseymarquis
Related is a mozilla post on streaming wasm for big performance gains:
[https://hacks.mozilla.org/2018/01/making-webassembly-even-
fa...](https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-
firefoxs-new-streaming-and-tiering-compiler/)

