Scripting Languages and Compiled Languages in WebAssembly
The promise of WebAssembly is that it can be a common runtime for all sorts of languages. But there are differences between how we traditionally write in scripting languages (JavaScript, Python, Ruby) versus compiled languages (C/C++, Go, Rust). There are also compiled languages that run in an interpreter, like Java running in a JVM. In this post, we survey the WebAssembly landscape to see what is happening along these fronts.
Containers vs. WebAssembly: What's the Difference?
In the last few years, Docker Containers have been the most popular technology on the cloud side. Now, WebAssembly is arising as a new cloud technology. How does it compare to Docker Containers? Previously, we covered what WebAssembly is, and briefly touched on Docker. In this article, we explore the similarities and differences in more detail. We conclude that each has its place, but that WebAssembly opens some enticing possibilities.
Rethinking Microservices
Microservices are serving us well in many ways. But in some ways, we can do better. Having learned a bit from Functions as a Service, containers, and now WebAssembly, we can rethink some of our assumptions and perhaps devise a better way for creating microservices.
In our first blog post, we talked about how we envision a new iteration of microservices. Then we introduced our CMS system, which in many ways exemplifies our approach to microservices. Last week we answered the question, How should we think about WebAssembly?, discussing why WebAssembly is a promising cloud technology. Here, we spell out the problems with microservices v1, and pave the way for a microsevices v2.
How to Think About WebAssembly (Amid the Hype)
WebAssembly (also called Wasm) is certainly the subject of much hype right now. But what is it? Is it the JavaScript Killer? Is it a new programming language for the web? Is it (as we like to say) the next wave of cloud compute? We’ve heard it called many things: a better eBPF, the alternative to RISC V, a competitor to Java (or Flash), a performance booster for browsers, a replacement for Docker.
All those things are, to some degree, sensible ways of looking at WebAssembly. However, it might help to take a bird’s eye view of the technology and understand its essential properties. And from there, these other assessments will begin to make sense. Once we’ve covered the essential characteristics of WebAssembly, we’ll circle back to Fermyon’s stance that WebAssembly is the enabling technology behind the next wave of cloud compute.
Why LibreOffice in WebAssembly is a Big Deal
Earlier this week, demos began to circulate of LibreOffice (using the QT graphical toolkit) compiled to WebAssembly and running in the browser. This comes after Thorsten Behrens of Allotropia gave an interview announcing WebAssembly support in LibreOffice . The stories trended to the top of Hacker News. And this came hot on the heels of the Fosdem session explaining WebAssembly for LibreOffice. Why all the fuss?
For us at Fermyon, we see LibreOffice’s move as a strong indicator that WebAssembly is now poised to enter the practices of mainstream developers. And while Fermyon is focused primarily on the cloud side of things, we do think that (just as with JavaScript and Node.js) both sides of the network connection will benefit from pervasive use of WebAssembly.
