In my previous blog post, I presented an example of universal code and outlined some guidelines on how to best approach writing code that can be deployed on every target without modification. I am going to continue posting examples and interesting pieces of code that you can freely copy and experiment with, but before we continue I want to take a moment to talk about WebAssembly.
As of writing, coding for the browser has seen three stages of evolution:
Perhaps you have seen games like Quake III run at full speed directly in the browser? Those demos are indeed Asm.js, so the power of this technique should not be dismissed.
Note: I want to stress that Asm.js is by no means a defunct standard. Asm.js remains a labor of love by a handful of passionate web developers, and like I underlined - it's a technique rather than something you would find an RFC for. Anyone can emit their own bytecodes into a buffer and execute it. There is no right or wrong way here, except what works and what doesn't.
One of the things developers learned from Asm.js experiments was that the core developers behind Chrome and Firefox had to get on board. Sure, Asm.js is very capable, but without a proper standard adopted by both Google, Microsoft, Apple and the Mozilla foundation, the quality and safety of such code could never be guaranteed.
WebAssembly has an intermediate format called WAST. It might look indecipherable, but thankfully you don't have to deal with it unless you want to.
And this is, for all means and purposes, how WebAssembly was born.
Benefits of WebAssembly
- Sophisticated business applications
- Photoshop level image manipulation
- Final cut style video engineering
- Pro-tools quality audio processing
- Natural language analysis
- 3D modeling and ray-tracing
- Machine learning and A.I
.. and much more
I have briefly mentioned C/C++ as used by the Asm.js initiative; not surprisingly that is also true for WebAssembly. So different language vendors are slowly coming to terms with WebAssembly as a target, with radically different approaches on how to best leverage the technology. Some chose to do a clean break with HTML and DOM (document object model) completely, and implement their own graphics libraries etc. that do everything on their own, others are going for a more HTML friendly approach.
As of writing, Elements represents the only WebAssembly offering that spans five languages (Oxygene, C#, Swift, Java and Go). The way we have organized our tool chain means that you can go down both paths, the HTML friendly path, and the solo path. There is nothing stopping you from doing your own thing separate from the browser. Or, you can opt for a more moderate approach and enjoy the best of both worlds.
This is perhaps a good time to mention our Delphi VCL compatibility library. This is a clone of the much loved VCL framework that Delphi users love so much. And it's designed to make porting code from Delphi easier. This library can be used by all our languages, so even though you are coding in Swift or Go, you can tap into our VCL to become productive faster. And it is supported from WebAssembly to craft HTML user interfaces.
Thankfully that is not the case. You can start benefiting from WebAssembly almost immediately providing you know one of the five high-level languages we deliver.
WebAssembly can be used in one of two ways:
- To write full applications
- To create libraries
If you are starting a new application, you can mix and match between both worlds. I would design the UI as normal HTML, perhaps find a cool library like JQuery UI or Sencha Ext JS and make a polished, animated and interactive user interface. And once that is in place, you can easily reference the buttons, lists, text boxes etc. directly from WebAssembly.
I hope this brief overview of WebAssembly has been informative. We have only scratched the surface of what WebAssembly can do, and I will return to this topic in the near future.
As a target that all our languages can use, WebAssembly is here to stay.