{"id":6954,"date":"2019-12-23T01:00:00","date_gmt":"2019-12-23T01:00:00","guid":{"rendered":"https:\/\/gtechbooster.com\/?p=6954"},"modified":"2023-04-01T01:36:47","modified_gmt":"2023-04-01T01:36:47","slug":"w3c-adopts-webassembly","status":"publish","type":"post","link":"https:\/\/gtechbooster.com\/w3c-adopts-webassembly\/","title":{"rendered":"W3C adopts WebAssembly"},"content":{"rendered":"\n

WebAssembly has been adopted by W3C and is now an official web standard. This doesn’t mean it is ready to use, however. <\/p>\n\n\n\n

\"\"<\/a><\/div><\/div>

The saga of WebAssembly will probably mystify programmers in years to come. We have browsers that have “native” JavaScript support and this has been refined and evolved over the years. Most programmers don’t like JavaScript for a range of reasons – it’s not elegant, it’s not class based, it’s weakly typed and it’s slow. Over time there have also been attempts to allow programmers to write in their language of choice and have this run in the browser. <\/p>\n\n\n\n

While compiling to JavaScript does nothing much for speed, Google’s NaCL which allowed programs to be compiled into native code, permitted running at full speed.\u00a0 This seemed like a better idea, but no one wanted to get behind Google on this one. Later Google implemented a platform-independent version of NaCL\u00a0, however it had no more success in being adopted.<\/p>\n\n\n\n

The next suggestion was to invent a sub-set of JavaScript that could \nbe used as a browser assembly language – asm JS.This worked but perhaps \nnot with the speed up that was hoped for.<\/p>\n\n\n\n

The final approach was to think of implementing a new language that could coexist with JavaScript. This idea involved of a whole new lowish-level language based on syntax trees. The advantage of a language based on syntax trees is that it makes the code quick to execute and you can choose a range of architectures to implement it – for example a stack machine, which is slow but easy to implement. <\/p>\n\n\n\n

An alternative would have been to adopt, say, the Java VM and take advantage of the existing compilers and tools. I can see why the web community might not have wanted to use anything connected with Oracle’s approach to Java, but there are alternatives.<\/p>\n\n\n\n

Instead what we have is a brand new ecosystem that has to be \npopulated with new tools and at the moment there aren’t very many and \nthey are difficult to use. It is clearly going to be some time yet \nbefore WebAssembly goes mainstream.<\/p>

\"\"<\/a><\/div><\/div>\n\n\n\n

To be clear – you aren’t going to be writing your code in \nWebAssembly. You are going to be writing in Python, Julia, R or C and \nusing a compiler to create WebAssembly. The problem is that at the \nmoment the compilers and the associated infrastructure isn’t well \ndeveloped enough for you to get a junior programmer to do the job. \nUltimately it has to get this simple and this polished for WebAssembly \nto be widely used.<\/p>\n\n\n\n

Another interesting choice is the fact that you still cannot dispense with JavaScript. If you hate it then get used to the idea that JavaScript is still very much part of WebAssembly. You need JavaScript to marshal WebAssembly and talk to the UI. A one-language solution is now no longer possible if you want maximum performance. You still have to write substantial parts of any application in JavaScript. The reason for this is supposed to be that having JavaScript handle the outside world makes use of JavaScript’s security mechanisms. <\/p>\n\n\n\n

This might provoke a hollow laugh as not only is JavaScript capable of being subverted, adding WebAssembly to it makes things more complicated and hence more vulnerable. The attack surface has just been enlarged. Complexity is the friend of malware.<\/p>\n\n\n\n

It is not just the browser that WebAssembly hopes to shake up. The \nidea is to extend the standard to include environments that WebAssembly \ncan be run under. So I guess the idea is to make it a viable target for \nevery language on the planet, running on every platform on the planet. \nSounds unlikely to me.<\/p>\n\n\n\n

I can’t help but think that in a few years programmers will see this \nas a missed opportunity. WebAssembly has many things that are \nattractive, but the way that it extends JavaScript and has to interwork \nwith it is undesirably complex.<\/p>\n\n\n\n

We could have implemented something completely new and completely simple and allowed JavaScript to co-exist or wither depending on the will of the world.<\/p>\n\n\n\n

More information<\/h2>\n\n\n\n