
Intro to WebAssembly - codelitt
https://www.codelitt.com/blog/web-assembly/
======
Klathmon
The official FAQ specifically states the opposite of the second bullet point.

Web Assembly is not meant to be a replacement for JavaScript. And although the
blog doesn't explicitly say it, it's alluding to it being easy to create
entire applications without using JavaScript at all.

JavaScript is going to continue to be used as "glue code" at the very least,
and UI code in the majority of cases. I think it's really important to make
this distinction.

Trying to use web assembly as a solution to problems it's explicitly not meant
to solve is only going to lead to pain and frustration.

Furthermore, things like "static type checking", easy functional programming,
and making application coding "less painful" aren't really goals as the post
seems to make them out to be as well.

~~~
bluejekyll
> Web Assembly is not meant to be a replacement for JavaScript.

This seems like a very short sighted view. It's meant to offer options other
than JavaScript. For many of us who dislike JS, this is exactly what
webassembly represents, a way to deploy applications without JavaScript to the
browser, in effect finally achieving the full dream of the JVM.

And yes, DOM integration isn't there right now, but it will be. It makes sense
to me that this is initially being limited for a number of reasons. It
definitely means people won't immediately glob onto it, reducing the potential
of accidentally locking in implementation bugs/features.

Some people think the DOM is unnecessary even in a webassembly world, but I
think CSS and the DOM are generally good, what I've always wanted is a better
language option.

I'm practically giddy with the potential for all of this finally happening!

~~~
TheAceOfHearts
I think people are severely underestimating the challenges of integrating WASM
with JS an DOM. Right now styling and DOM are the two biggest performance
bottlenecks. No doubt it'll happen, but I'd be amazed if performance weren't
terrible out of the box.

Plenty of DOM APIs are terrible. Oh, you want a database? Tough luck, here's
IndexedDB.

~~~
pjmlp
Not really, when WebAssembly gets better it will be the revenge of Java, Flash
and Silverlight.

Future web applications will be mainly plain WebAssembly + Canvas + WebGL.

~~~
mvindahl
There is a tradeoff between development speed and execution speed. For web
apps, development speed is usually the most important of the two and the
language ironing away the most technical details tends to be a strong choice.

Roughly speaking, C is further from the metal than assembly (and WASM) for
obvious reasons; Java is further from the metal than C (or Rust) due to having
garbage collection, and Javascript is slightly further from the metal than
Java due to abstracting away threads (the gap was far wider before Java got
lambdas). LISP, of course is off the scale due to abstracting away readability
;)

On a serious note, though, I don't see the advantage that Java or Flash or
Silverlight would bring to web apps unless they bring greater development
speed.

But I _do_ see WASM as an excellent future supplement to JS-based apps, for
optimizing time consuming parts of the code.

~~~
pjmlp
It will be like Unity, Unreal do nowadays, and how many plugin runtimes used
to do in the past.

The productivity of doing WPF/XAML development with RAD tools like Blend,
using an export button to generate an WebAssembly executable.

I might be wrong, but that is where I see it going to.

------
nevi-me
If the author states that there are already a number of Hello World examples,
why not spend a bit more time and create something else that's still simple
enough?

As a self-taught programmer, one of the difficulties I found (before SO) was
that the many articles one read up on would typically repeat what someone else
said. This especially with new technologies.

I think if authors pointed us to an existing "Hello World", and then expanded
on that, in the long-run, beginners would sometimes find it easier to learn
fadter.

~~~
codelitt
That's fair feedback. There will be a part 2 where we will dig in more. As I
mentioned in another comment, it's eating an elephant. 1 bite at a time.

------
bluejekyll
I'm really surprised to read an article like this that doesn't mention Rust.
The reason is that I find it hard to believe that developers will want to move
to unsafe languages like C/C++. Many of the other languages mentioned require
runtimes, runtimes that will need to be built on top of webassembly.

Rust doesn't have any of these drawbacks, is runtime free, and can already
target webassembly. Given that both of these technologies are young,
webassembly even younger, there's no big argument for legacy code in this
context, which means adopting something new would be fine, and good in this
case because of the safety guarantees.

Anyway, a great intro in general, but for anyone looking at getting into this,
I highly recommend checking out the Rust tutorials, like this one:
[https://medium.com/@ianjsikes/get-started-with-rust-
webassem...](https://medium.com/@ianjsikes/get-started-with-rust-webassembly-
and-webpack-58d28e219635)

~~~
kjksf
WebAssembly is in a large part about re-using vast quantities of existing
C/C++ code in the browser.

C++ will dominate in that space over Rust for the same reason it'll dominate
in all other spaces: the amount of existing C++ code and the number of
existing C++ programmers will always dwarf the amount of Rust code and Rust
programmers.

Even if Rust was uniformly 10-20% better than Rust, economics dictate that for
most people it'll make most sense to continue with C++ than rewrite thousands
or millions lines of code in C++ or embark on months-long retraining of large
number of programmers, some of which will not be happy about going from being
proficient C++ programmers to beginner Rust programmer.

And that's why we don't need to mention Rust when writing about WebAssembly.
At this point in time it's immaterial to the subject.

~~~
bluejekyll
I tend to agree with you in the context of porting existing C/C++ code to the
Web is going to follow exactly the pattern you mention.

But, for new software, with no previous dependencies? The stdlib in Rust is
decent, and the ecosystem is growing quickly. For new projects, I do think
these will help in it's adoption in a new environment like WebAssembly, but we
shall see!

~~~
pjmlp
For me Rust is a deja vu experience, in a certain sense.

I started to use C++ around 1992, on MS-DOS, as my next loved programming
language after Turbo Pascal. Never saw any value in plain C, other than
writing code unsafer as straight Assembly (Assembly has less UB than C).

Have taken part in C vs C++ flamewars on Usenet since those days, only to see
C++ finally overtaking C in many fields in the last 10 years.

In some fields, like embedded programming, C still reigns over C++.

So while I look forward to have my managed languages, OSes and performance
critical libraries written in a safer language, my life experience tells me it
will take a few decades to achieve the same level of market adoption.

~~~
bluejekyll
By no means do I believe it will overtake these other languages quickly. But
one huge benefit that Rust has over these others is this idea of "fearless
programming". Watching Ruby Devs jump into Rust, fight the compiler for a bit,
but then have a blazing fast app with some very detailed systems level
interaction, is amazing. On top of that, it never segfaults!

Jumping into C and C++ is in my own experience, much more difficult. All of
the complexity of those languages disappears into the Compiler in Rust. I
think the big thing here is that Rust can appeal to many developers from all
walks, not just those of us who've spent years or decades with Assembly/C/C++.

~~~
pjmlp
I agree, but also feel a bit sorry for Ruby devs, in the sense that they could
have had that experience with Dylan or even with Apple's short love with a
Ruby AOT compiler (which eventually became RubyMotion), while staying in Ruby.

------
zzo38computer
I like the idea of WebAssembly too; it is another kind of VM code. However, is
there a C API to WebAssembly? Having a JavaScript API that is usable in both
HTML and Node.js (and could easily be added to any other JavaScript too) is
good, but a C API can also help (and I have written on some file on my
computer what are some ideas for making a C API).

(I did not read the linked document much though, but only the official FAQ.
However I do think you would not use WebAssembly all the time, but it can be
helpful in some cases, including wanting VM codes.)

~~~
kjksf
It's like asking "is there JavaScript API to JavaScript".

WebAssembly is a portable instruction set, a simplified CPU.

The main use case for WebAssembly is compiling C/C++ code to that instruction
set using emsscripten, which is a clang-based C/C++ compiler that emits
WebAssembly modules.

Depending on how you look at it, the answer to "is there C API to assembly?"
is:

a) yes, that's the first API there ever was and it's the main API

b) the question doesn't make sense. C/C++ is compiled to WebAssembly, there's
no API to it. You could imagine a system that would allow using WebAssembly
modules from native C/C++ code, where you would need a C/C++ bridge to
executing WebAssembly functions (similar to JavaScript bridge for calling
WebAssembly functions), but this is not really why WebAssembly exists

~~~
zzo38computer
b) is what I meant. I know that would not have been the original intention but
I still think it can be useful in some cases, and there does not seem anything
wrong with it. (It clearly wouldn't be for static linking WebAssembly codes
with C codes, like what you might do with JavaScript, although it can have
different uses.)

------
IshKebab
Is anyone experimenting with using WebAssembly in non-web contexts? Could be
great for cross-platform native apps, microcontrollers, etc.

~~~
mbel
What benefits do you expect? Which of them aren't provided today by JVM or
.Net?

------
drmeister
Looks great! I'm looking forward to exception handling support.

------
timwaagh
i read it but it does not really explain wasm the language.

~~~
codelitt
This was just an intro. There will be a part 2. It's a pretty large subject.

