Thoughts about WebAssembly outside-the-browser, inside-the-desktop
Some reflections about WebAssembly, the Bytecode Alliance and desktop application development.
To know more about the Bytecode Alliance (WebAssembly outside-the-browser), you can read this nice article by Mozilla.
Note that I don't plan to work on this, it's just some thoughts about what could the future bring us. If someone is interested, this would be a really, really nice project that would totally change the landscape of native desktop application development. I'm convinced that the solution isn't Rust or C++, or C# or Java, or whichever new language will appear in 20 years that will make Rust obsolete; the solution is some piece of infrastructure such as nanoprocesses.
GNOME, C/GObject and language bindings
Historically, the GNOME project has chosen the C language to develop its libraries, because it's easier to implement language bindings: to be able to use these libraries from other languages.
The GObject library, at the heart of GNOME, has been implemented with language bindings in mind. When writing C/GObject code, it requires extra work to the developer because of language bindings. With the advantage that after that, the library is automatically usable from a wide range of languages thanks to GObject Introspection.
So, that is the strategy used by GNOME and GTK to provide an attractive development platform for application developers: the latters can ideally use their favorite language to develop an application.
An attractive platform for application developers
So I've talked about one advantage of the GNOME development platform for application developers: language bindings.
But it's not enough in order to provide an attractive development platform. To be able to write new applications quickly, conveniently, and with enough flexibility, you need high-level, domain-specific libraries, with still an access to lower-level APIs when the need arises.
And this is where GNOME could be much improved! Providing high-level APIs for various kinds of application domains. You don't like that new UI trend? No problem, you can just fork the application, and assemble the UI with different widgets. You want to create a specialized application (in contrast to the general-purpose one that GNOME provides)? No problem, use this framework and configure it that way.
In other words, with an attractive development platform, it's possible to easily create different, but similar, applications in the same domain. Or, in short, a software product line.
Example in a field that I know well, text editors:
- First choice to make:
- Either a general-purpose text editor: can be used for different CS languages.
- Or a specialized text editor: targets a specific CS language or platform.
- Second choice to make:
- Either a traditional UI.
- Or a smartphone-like UI.
The two choices are orthogonal. With a software product line, it would be possible to have the four combinations. With each application having a small amount of code.
(It would also put an end to the endless discussions and disagreements about which UI is best, just create one application with the desires of the designers, and if a developer disagrees, he or she can create another application. With code written as a library, and a small codebase for the application, this is doable).
But is C/GObject an attractive platform for library developers?
The conclusion of the previous section is that most of the code should be written in a library fashion. Like the LLVM project does. This prevents reinventing the wheel, and enables new low-hanging fruits. Another name for this is "re-targettable code": you can leverage the codebase for new purposes, as the needs arise and as requirements change.
But for GNOME, writing almost all the code in C/GObject is, well, how to say it, a little cumbersome. The C language is not memory-safe, C/GObject is hard to learn and not used by a lot of developers in the world.
Nanoprocesses, a solution
Back to the WebAssembly and the Bytecode Alliance topic.
With the concept of nanoprocesses applied to a desktop application, this would bring the benefit of being able to write libraries in various languages other than C, while still having good performances (in contrast to using a more heavyweight IPC solution like D-Bus, which already permits to develop services in other languages, since the services run in their own OS processes).
Inter-nanoprocess communication isn't much slower than regular function calls, as explained in the Mozilla article linked above. So the primary purpose of C/GObject (language bindings) would no longer be relevant.
On a more personal note, I don't know well recent web technologies, but Mozilla's article about the Bytecode Alliance has convinced me. I'm also convinced that I don't want to develop primarily in C/GObject for at least the next decade. I have heavily developed in C/GObject since 2012 or so, during at least 6 years, and then less heavily with ups and downs. With as focus during these years to make more code re-usable (which means, creating new libraries, with higher-level APIs, and losing a few feathers in passing). And, no, sometimes I don't have the same opinion as most other GNOME developers or designers. But I know that I did good work, I was going in the right direction architecture-wise, I have received many thank-you emails from users over the years.
This article outlines potential solutions, actionable things. To stay relevant compared to web applications, the cloud, etc. Because, I still prefer "normal", desktop applications for which I own my data, is privacy-respecting, without ads, etc etc ;-)