Web Programming - Web Assembly?

[lpetrich]

The World Wide Web emerged in the early 1990's, as the collective of users of HTML documents across the Internet. Soon afterward, in the mid 1990's, client-side webpage programming emerged. Client-side meaning run in the web browsers that display the pages, rather than in the servers that transmit the pages. Server-side webpage programming is almost universal,

The first was Java, run as "applets", displaying inside of webpages. Webpage Java is no longer very common, with webpage Flash largely superseding it. But applets usually have very little interaction with the pages that contain them.

Not long afterward, JavaScript emerged, with its code embedded in the text of webpages, and with it being able to manipulate just about all of a webpage's content -- the page's Domain Object Model (DOM). But since its introduction in late 1995, it has had only one successful bit of competition: Cascading Style Sheets, introduced a year later. However, CSS is limited to specifying properties of webpage objects like their size and color, and it has no programmability. While JavaScript is Turing-complete, neither HTML nor CSS is.

JavaScript has several problems. All its type checking is done in run time, and it is transmitted as source code, complete with the resulting bulkiness. This makes it difficult to do proprietary software with it, like online games. The Top 10 Things Wrong with JavaScript – JavaScript Non Grata – Medium

1) There is no integer type! JavaScript has only one numerical type and that’s (double precision) floating point.
2) JavaScript’s loose typing and aggressive coercions exhibit odd behaviour.
3) Automatic semicolon insertion. This can cause subtle bugs and unexpected behaviour.
4) JavaScript is seriously abused. Much of the code in the wild, especially those in commonly used libraries, are very badly written.
5) JavaScript is highly dependent on global variables. ... JavaScript also has horrible scoping rules.
6) JavaScript code can fail silently due to syntactical slip-ups.
7) Object prototypes do not scale well to large applications; it’s a rather primitive and sloppy way to do object-oriented programming (but it’s flexible!).
8) Asynchronous programming in JavaScript is very messy.
9) Douglas Crockford says that JavaScript is “Lisp in C’s Clothing.” ... But JavaScript is nothing like Lisp!
10) The main draw of JavaScript is actually in frameworks like Node.js and AngularJS. If not for them, why would you use JavaScript???

But adding another programming language has plenty of problems, like getting the support of major browser writers. That may also be why webpage support for image formats has remained very conservative. So why is Web Assembly getting anywhere where others have yet to get off the ground?

 

[J842P]

Most people would not be using raw Web Assembly, if I understand it correctly. Instead, it would be a target for compilation so that you could write web apps in any language.

For example: a Python interpreter in web assembly:

https://github.com/iodide-project/pyodide

The key aspect of this is that it uses emscripten to compile C to Web Assembly. There have been various projects to get Python on the web, but this one shows the most promise of actually taking off because it takes advantage of all the C extensions written for Python. Python's power comes from libraries, like `numpy`, `pandas`, and `scipy` (the so-called scientific Python stack). These are rich, feature full libraries which offload the heavy work onto the C-layer, allowing you to write fast numerical code in a higher-level language like Python, but it requires CPython's tight integration with C. This is a big part of why other alternative implementations of Python, i.e. Jython (Python that targets the Java Runtime Environment), Iron Python (Python that targets .NETs CLR), or PyPy (a fast, JIT compiled version of Python written in a subset of Python) have not taken off.

Here's a link from the Mozilla blog that describes the project: https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/

 

[lpetrich]

Enter Web Assembly, or WASM for short. It was adopted by major web-browser makers in 2017, though it does not seem to have caught on very much.

Assembly? That's from "assembly language", a small step up in abstraction from "machine language". The latter is programming in the 1's and 0's that a computer CPU directly executes. It's possible to program in it with a hexadecimal text editor, but I doubt that anyone has ever done that in a long time, except for small bits of code here and there. Assembly language is much easier to understand. It has format

(optional label) (operation code (opcode)) (operands, if any) (optional comments)

The labels are both for branching and for data layout. The opcodes include both CPU instructions and data-layout instructions for the assembler. An assembler can include a macro facility, much like the C preprocessor. One defines instructions that get expanded into several instructions each.

Nearly all low-level programming is nowadays done in assembly language, and has likely been done that way since the emergence of assemblers in the early 1950's or thereabout.


Web Assembly can be distributed in this form, but it is designed to be distributed as bytecode or pseudocode or p-code. This is a stream of instructions in opcode-operand form, like instructions for a CPU, but not executed directly. Instead, the instructions are translated into instructions for whatever CPU it will be run on. That is how Java software is typically distributed.

If one translates as one goes, then this translation slows down the running by a sizable factor. But one can get around that difficulty by caching one's translation -- "just in time" (JIT) compilation. Running Java software is typically done in JIT fashion these days.

As one can expect, bytecode is much less voluminous than its original source, meaning that it goes across the Internet much faster and occupies much less disk space. It is also better for distributing proprietary software, because it is relatively difficult to reverse-engineer.

 

[lpetrich]

Most people would not be using raw Web Assembly, if I understand it correctly. Instead, it would be a target for compilation so that you could write web apps in any language.

That is the main purpose of WASM, to enable support of most programming languages without having to support them in browsers.

For example: a Python interpreter in web assembly:

https://github.com/iodide-project/pyodide

The key aspect of this is that it uses emscripten to compile C to Web Assembly. ...

 Emscripten was originally designed to produce code for asm.js, a predecessor of WASM. The asm.js interpreter translates WASM-like instructions into JavaScript for execution.

The purpose of Wasm is to enable the JavaScript engine of a web browser to execute page scripts nearly as fast as native machine code. But this is not a full replacement for JavaScript; rather, Wasm is only intended for performance-critical portions of page scripts.[1][2][3] Wasm code runs in the same sandbox as regular script code, but only regular scripts have direct access to the DOM tree.

So WASM does not have direct access to webpage contents.

 WebAssembly, WebAssembly, WebAssembly | MDN

 

[Loren Pechtel]

I truly hate the weak typing and syntax checking of Javascript.