Skip to toolbar

Community & Business Groups

Call for Participation in WebAssembly Community Group

The WebAssembly Community Group has been launched:


The mission of this group is to promote early-stage cross-browser collaboration
on a new, portable, size- and load-time-efficient format suitable
for compilation to the web.


In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.

This is a community initiative. This group was originally proposed on 2015-04-29 by Luke Wagner. The following people supported its creation: Luke Wagner, Dan Gohman, David Herman, Jean-Francois Bastien, Alon Zakai. W3C’s hosting of this group does not imply endorsement of the activities.

The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.

We invite you to share news of this new group in social media and other channels.

If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at site-comments@w3.org

Thank you,
W3C Community Development Team

15 Responses to Call for Participation in WebAssembly Community Group

  • What kind of participation are you looking for? People to learn how to use WebAssembly (that might be me), people to help develop the WebAssembly itself or something else?

    Thanks.

    Reply

  • Just use Python 3. You have already a bytecode format, and the ability to execute both source and bytecode (pyc). Therefore, you can accept both at no cost. Nearly everything is done, just the standard library needs to be trimmed out, along with some additions for direct DOM manipulation.

    When it’s done, you just need an interpreter/compiler from JavaSCript to Python.

    Just my two cents.

    Reply

  • Wow, I’ve been publicly calling for a high-performance, “universal” web VM for more than a year now (and have been looking out for any jobs openings that are in any way related).

    As I’ve said before, I think this VM

    – should contain a variety of flexible primitives so that the core features of all known languages can be supported somewhat efficiently
    – should be high-performance, like Google NaCl; a single VM can and should offer high performance, power, and ease-of-use all at once.
    – should use a bytecode that is designed for optimization (LLVM bitcode seems like a reasonable starting point), but is non-obfuscated (highly decompilable) by default.
    – should allow and support garbage collection (but not require GC-based memory management)
    – should allow multiple threads, message passing (I suggest a system of strongly-type protocols: Session Types, or my research group’s variant, called MPL) and probably shared memory too
    – should be designed to allow code from different languages to communicate easily
    – should have a standard library of data types to promote interoperability between programming languages, and avoid the need to download a large standard library from server to client
    – should allow run-time code generation, dynamic loading & linking, and allow code running in the VM to limit how much CPU and memory a script is allowed to use.
    – should define a subset (e.g. without GC and other “big” features) for low-resource non-web environments.

    I hope to have the opportunity to get seriously involved in this project. Let me be clear, I will literally drop everything and move to Mountain View or Washington right now if I can get a job related to this.

    It doesn’t say if markup is accepted: testing HTML, **markdown**, [b]bbCode[/b]

    Reply

  • I was wondering what parts of a web page should be compiled : the parsing treatments on the DOM and css are also time consuming,

    So maybe it could be a good idea to think already about the problem of compiling a page in its entirety (for faster loading) rather than thinking only to replace js with a compiled language: a binary form of the “precomputed” welcome page would be a bandwith and time gain.

    Otherwise, I think it’s useless to try to think a new language for the purpose, it would be better that already existing languages adopt a “native web compiler”. Some languages like dart, phyton and js could be good candidates for that

    Reply

  • Marc Coiffier

    @Baltasar: No need to reinvent the wheel, sure, but I think we can do better than Python 3 bytecode for the Web language of tomorrow (first of all, I think it defines “print” as an instruction, yuck !). Something with automatic dependency management would be nice, for example (see Nix for a nice example of hash-based dependency management).

    @David: I mostly agree, except the part on GC. Like it or not, garbage collection isn’t yet a solved problem, and I’d rather not risk plaguing future generations of programmers by choosing the wrong memory model. Garbage collection should be the sole responsibility of the compiler until we can guarantee 100% efficiency in all cases. Plus, if we keep the list of heavy features short, we can have the same language for low-powered environments and regular ones.

    @Zied: I think a “native web compiler” needs a “native web machine” to target, which is what we are supposed to design 😉
    I agree though, why stop at Javascript when we can compile all the parts of an app and let them reference each other in inter-language glory ?

    Reply

  • Martin Gauna

    Python gave strong, fast, reliable, long life to so much of the web historycally.

    Let’s contribute to that project instead.

    Let’s give Python what it needs to address the remaining desired features.

    Let’s honor the great work, effort, quality, universality that already Python has and offers,which are sought also with this project.

    Reply

    • Marc Coiffier

      There is a multitude of languages that offer what Python does, with just as much effort, quality and universality. People who design languages don’t usually stop at having a calculator.

      Why should it be Python rather than, say, Java (which has done a lot for the Web too), Ruby (which rivals Python in terms of expressivity), Erlang (which puts all the others to shame in a distributed context), or even Perl ? Let’s not dishonor their work by not even considering it.

      If you ask me, I’d rather have Haskell as a universal language, but that’s because I’m a Haskell developper, not because it’s objectively the best 😉

      Reply

  • @Marc I’m skeptic about what a “native web machine” can do better than js with a language like js : the language allows too much flexibility with the eval() feature that it’s completely uncompilable : it’s kind of the same issue as we have in java reflexion where the compiler cannot see what is behind the string. But it’s worse because you can do recursive calls eval( “eval(“function dome{}”)” );

    So yes sure for a native web machine, but with which language. I thought about dart since it was created after the feedback of the attempt to use a java to js compiler, Google noticed that big differences in language structure can lead to performance issues. They invented therefore dart (for long months of work) to be “optimizable” in its js output. It is therefore kind of a done-work on the subject (knowing it has more assumptions that allow faster execution).

    This said, dart can be one of many languages compiled to the native web machine, which will by the way naturally target phones too and allow a “write once, run everywhere” (again)

    Reply

    • Marc Coiffier

      JavaScript has an ‘eval’ function, but that doesn’t make it uncompilable, just trickier. Most Lisps also possess ‘eval’ functions as part of their standard library, and they can be compiled to near-C performance, so there is no reason JS couldn’t.

      Now the case for a WM. A WM could have a super-optimizable language at its core (see Morte for example), which could be very interesting if we enable partial optimization on the server-side so that as little as possible is done on the client.

      If we choose strictly non-recursive semantics for the WM, we could theoretically implement an optimal garbage collection for all programs with a simple refcount algorithm. There are ways to automatically turn recursive programs into non-recursive ones using mathematical trickery (see Morte again for some examples of that), so this shouldn’t hinder existing languages from adopting it.

      Finally, a WM could define a proper module format enabling “separate compilation” in a distributed context. It could use a cryptographic hash to tag dependencies in an unambiguous way, then clients could use those hashes to request and verify the dependencies as they are needed (while caching them for future use, of course).

      What more could you want ? 😀

      Reply

  • I read all comments, I realize that most of you comparing python with WebAssembly, so what I already knew is that WebAssembly will replace javascript and will be 20 times faster than javascript, but I really don’t know much about python because I am a PHP developer so my question is python could replace both PHP and javascript or only PHP? I already knew that python could replace PHP, but python web pages will be faster than PHP pages?!

    Reply

  • Having read the design documents on GitHub, I would say right away that the VM design so far is 100% on target. It’s modular, low level, easily optimized, and load-time native code generation should be straightforward. There is plenty that could be added, but the things specified so far seem like a rock solid foundation.

    Two important goals here are modularity and safety. These are critically important goals at this point; most of our existing systems lack both. Your module and your dependencies (imports) do not share memory. You cannot access stack memory or code memory. Your AST code cannot jump around at random. You can still cause buffer overflows in your private memory, but this is under the control of your compiler and language.

    @Baltasar, @Martin One of the design goals of WebAssembly is to permit developers to deploy performance-critical code on the web. As such, the VM design specifies strongly typed operations that can be quickly and easily translated into native machine instructions at load-time. By contrast, the Python VM specifies operations on tagged values and hash-tables, requiring a JIT compiler to first run the code with an interpreter, detect the types and structures used, and if profitable, generate native traces with type guards; essentially how Javascript is handled in most browsers now.

    @Zied I think WebAssembly has more modest goals in order to have a good chance of achieving them. Indeed it is intended to provide a VM for all of the languages you mentioned and more; anyone can write a compiler for their language that targets the new VM. It’s better to think of WebAssembly as a way of packaging and distributing compiled, portable “nearly-native” code modules. It’s not attempting to introduce a new standard web language.

    @David I agree with Marc on the GC front. It’s a deliberately low-level VM, perfect as a clean target for compilers and for generating performance-critical code, where you can control such things as locality and memory allocation. A compiler could in theory implement GC within the linear memory. The current design specifies only basic machine-level types and operations, and leaves the rest up to your language compiler/linker.

    Threads and shared memory are already on the cards. I fully expect cross-module shared memory regions to come later. Dynamic linking is also planned, but I think it is intended to work more like linking together a set of strictly isolated modules that can directly call each-other with low overhead.

    Reply

  • Hi,
    someone can tell me whats the state of the art of wasm?

    Jojo

    Reply

  • I would like to be involved and stay up to day with the W3C but, as a non member, I cant find a way to do this.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Before you comment here, note that this forum is moderated and your IP address is sent to Akismet, the plugin we use to mitigate spam comments.

*