assemblyscript VS interface-types

Compare assemblyscript vs interface-types and see what are their differences.


A TypeScript-like language for WebAssembly. (by AssemblyScript)
Our great sponsors
  • Scout APM - Less time debugging, more time building
  • OPS - Build and Run Open Source Unikernels
  • SonarQube - Static code analysis for 29 languages.
assemblyscript interface-types
9 10
13,279 577
1.8% 4.7%
9.1 1.6
11 days ago about 23 hours ago
WebAssembly WebAssembly
Apache License 2.0 GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of assemblyscript. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-10-03.


Posts with mentions or reviews of interface-types. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-01-15.
  • Front-end Rust framework performance prognosis
    4 projects | | 15 Jan 2022
    Wanted to get thoughts from the Rust experts on this - the author of the Yew framework seems to think that Web Assembly Interface Types ( will allow Yew to eventually become faster than Vue, React, Angular, etc. Is there general consensus on this in the Rust community? The prospect of mixing Rust (for the performance critical pieces) with TS on the front end doesn't seem super appealing to me.
  • VSCode terminal from DOM to >canvas<
    3 projects | | 25 Dec 2021
    I can't help but feel like this is the worst. Every time we step away from HTML & the DOM & into a further farther reach of abstraction, into something custom crafted & artisinal, we lose our valuable common heritage. We flea from common understandability & recurse into something ever more unique & virtual.

    In the process- as is the case with Google Docs[1]- we lose things like the ability for web extensions to work, if this is a web hosted vscode instance (vscode server, openvscode, code-server, others). Running a debugger against this part of vscode- web or native- now yields only garbage junk information.

    Right now this is just the terminal. I think- "it could be worse". But it chills me deeply that the terminal is now no longer real information. It's now just a happenstance jumble of pixels, powered by only it's own inner logic & a unique maze of libraries. Big tech keeps optimizing and optimizing, & the motive we keep being sold- this is for your good, this helps you- is one I frankly have a very hard time negotiating with myself. De-webbifying the web, de-commonizing the common platform- as Facebook has done by virtualizing the DOM- feels like this ever-running big-bang from a truthful original universe into a sparse, cold, expanding universe where each little fragment defines itself, where the common hypertext medium no longer means anything.

    I keep waiting for some moments of contraction, some coming back together, for things to make more sense again, to recontract into something more solid. React's first WebComponents PR[2] is a notable re-contracting, re-platforming- a powerful act I frankly didn't expect, so rare as to feel practically unprecedented.

    I realize much of this flexibility, the demonstrated versatility of the web & usage of the various pieces of it represents much of it's strength. The platform being a low-level platform where higher level platforms can be created is amazing; the Extensible Web Manifesto[3] speaks to that emergence of newer higher levels systems. And right now we're in early days, just starting a precambrian explosion of higher level web, as technology like WebAssembly only just begins to become real- still so early, still way pre-pre- Interface Types[4]/Host Bindings, only just the crudest emulation beginning in via projects like Rust's wasm-bindgen / web-sys. I am happy we are still exploding. We have so much more to exlpore. But gee I also question so much when big enterprises turn hypertext into pixels. To move compute into webassembly is a bold leap but the hypertext can survive, the DOM is still truth. It's so uncertain to me, feels like so much might be lost when giants like Microsoft or Google yank out the HTML & replace it with pixels, pushed into our faces. It feels like betrayal, like sabotage, like we're giving up truth.


    [2] (16 days, 0 comments)



  • How is Redox OS (and similar projects) planning to deal with the lack of dynamic linking support?
    5 projects | | 10 Nov 2021
  • Masked input control for Blazor?
    4 projects | | 12 Sep 2021
    The tracking issues there gets updated when it changes phases and each proposal has it's own repo for discussion or how it works overall. For interface types it's this repo
  • Why should strings be lists of Unicode Scalar Values?
    1 project | | 2 Aug 2021
  • An Urgent Notice from AssemblyScript
    4 projects | | 24 Jul 2021
    This seems to be the discussion thread related to this.

    4 projects | | 24 Jul 2021
  • WebAssembly from Scratch: From FizzBuzz to Doom (2021)
    3 projects | | 14 Jul 2021
    Afaik for the WebAssembly MVP, the goal was to have a simple, efficient compile target - therefore only integers and floats. To make wasm more useful & easier to integrate, the plan calls for interface types[0], which allow both accessing complex (JS) objects and calling browser APIs.


  • Lunatic - An Erlang inspired runtime for all programming languages
    5 projects | | 8 Mar 2021
    Not at the moment, but this is the idea behind the WebAssembly interface type proposal.
  • Can we use WebRTC in Blazor?
    3 projects | | 28 Jan 2021
    I'm not familiar with WebRTC but as a generar rule you cannot access any browser API from wasm... yet. There's already a proposal (interface types) that will enable this but it has not been implemented by any browser yet. Then this will need to be adopted by Blazor, so I don't think we'll see it any time soon.

What are some alternatives?

When comparing assemblyscript and interface-types you can also consider the following projects:

rust-ffmpeg-wasi - ffmpeg libraries precompiled for WebAsembly/WASI, as a Rust crate.

ffmpeg.wasm - FFmpeg for browser and node, powered by WebAssembly

Lua - Lua is a powerful, efficient, lightweight, embeddable scripting language. It supports procedural programming, object-oriented programming, functional programming, data-driven programming, and data description.

deno - A modern runtime for JavaScript and TypeScript.

pyodide - Pyodide is a Python distribution for the browser and Node.js based on WebAssembly

Uno.Wasm.Bootstrap - A simple nuget package to run C# code in a WASM-compatible browser

reference-types - Proposal for adding basic reference types (anyref)

goscript - Go specs implemented as a scripting language in Rust.

tinyglitch - Just an experiment with libavformat/libavcodec

wasmtime - Standalone JIT-style runtime for WebAssembly, using Cranelift

wasm3_dino_rpi_pico - WebAssembly Dino game for PPi Pico

ASP.NET Core - ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.