Using Docker multi-stage builds to produce WebAssembly

Some time ago I decided to start a fun project, the Wheel of WebAssembly, to demonstrate how different programming languages can be compiled to WebAssembly and loaded independently on the same web page. It supports languages like C, AssemblyScript, C#, Java, Kotlin, Go, Rust (I call them wheel parts). Initially, I decided to manually configure the toolchain for each programming language on my machine and then compile them altogether. This worked fine for a while, but with time it became complicated to handle updates for each toolchain. Furthermore, when someone else wanted to play around with the project, they had to go through the same pain of manually configuring their environment. This lead me to start using Docker for building the WebAssembly output for each language. Continue Reading…

How WebAssembly influences existing JavaScript frameworks

WebAssembly is a compiler target for programs on the Web. It allows developers to compile C/C++ or other static-typed languages in a format that can be run in the browser or a Node.js environment without the need to install any 3rd-party plugins. WebAssembly enables developers to reuse code and create highly efficient web applications with near-Native performance. WebAssembly has been supported by all major browsers since October 2017. Continue Reading…

The Wheel of WebAssembly

I have been following the WebAssembly development since its initiation and given talks about it, but I haven’t really blogged anything related to it. In this post I want to share with you an idea I got some time ago about gathering all languages that can be compiled to WebAssembly. You can see the demo or browse the source.

The initial idea around WebAssembly was to allow compilation from C and C++, as there are many libraries (f.x., gaming, VR, codecs) that could be ported to the Web right away. The compilation architecture is designed to be extensible, meaning that other languages could also be compiled to WebAssembly. Indeed, other language creators (and the community behind them) started experimenting with that.

My idea with the Wheel of WebAssembly is to create a demo of each language that can be compiled to WebAssembly. As the WASM format is standardized, in theory I would expect to get “same” WASM files and to be able to load them on the Web the same way. In practice, it is not the case. Continue Reading…

From MVC towards components

The nature of HTTP is to provide resources where each resource is identified by a unique URL. A resource can be any kind of file: image, text file, font. Initially web sites used to deliver static HTML pages, which were pretty much limited in terms of content. CGI and server-side scripting languages like PHP, ASP(.NET), and JSP changed this by generating dynamic HTML on the server and sending it back to the client. This allowed the page content to be “configured” by the browser, f.x. using query string. This traditional web architecture is denoted on the diagram below.

Traditional web architecture

It all worked fine until the Web became more complex and developers started to put more and more logic on the server. We ended up having to make requests like /index.php?module=employees&id=5 (especially with some CMS systems). This architecture tended eventually to cause many problems, from search-engine optimization to code maintenance. Continue Reading…