AssemblyScript grant proposal discussion

In the previous discussion we have agreed that AssemblyScript is valuable to NEAR and that NEAR wants to contribute more resources both to the development of NEAR-specific AssemblyScript devtools and to the development of general AssemblyScript ecosystem, while continuing maintaining the current $2k/month contributions through OpenCollective :slight_smile:

This exta contribution will come in two forms:

  • NEAR will give extra assets to the AssemblyScript core team, without attachments;
  • People in this thread will create a list of improvements to the AssemblyScript ecosystem and NEAR-specific AssemblyScript devtools. NEAR then will select a subset of them, formally specify a grant, assemble a team (separate from NEAR and AssemblyScript core team) with the help of @potatodepaulo , and kick off the work.

Now, in this thread, I invite everyone familiar with AssemblyScript ecosystem to say what they want to improve or add to the AssemblyScript ecosystem, this includes:

  • adding or improving existing AssemblyScript libraries;
  • contributions to AssemblyScript std and compiler;
  • anything else.

Also, I invite those familiar with NEAR AssemblyScript devtools to say what they want to add or improve in near-sdk-as or other NEAR tools related to AssemblyScript.

In 2 weeks from now, on February 8th, we will take a subset of the proposals mentioned in this thread, based on their popularity and impact to the AssemblyScript ecosystem, create a grant, and get people to work on them.

I am going to start, by proposing the following improvements, in no particular order. As people are going to be posting their suggestions, I will be adding them to this list.

General AssemblyScript Ecosystem

AssemblyScript libraries

AssemblyScript compiler and STD

  • Increase test coverage. It seems like core AssemblyScript team is welcoming PRs that increase test coverage of AssemblyScript compiler and STD. @dcode, @MaxGraey, @torch2424, @willemneal do you have a target coverage in mind? How many human hours approximately would be needed to get us there?
  • @dcode, @MaxGraey, @torch2424, @willemneal What is the current state of STD, what would you like to be improved&added, and how many human hours approximately do you think it would take?
  • Anything else? Please post your suggestions.

NEAR-specific Development tools

we probably just need to add float support given that there is no more limitation on runtime size

other than that more tests + bechmarks won’t hurt for sure
once we have floats should be easy to reuse test files from other JSON parser test suites and check roundtrip


my understanding is that here main thing we need is on-going support to have feature parity with our runtime and ideally helpers like AVL-tree support (right now AVL tree seems buggy)

long-term I feel like we need ActiveRecord-style ORM to make managing table-like objects with secondary indices, etc easier


we ideally need to add 256-bit number support (both safe and unsafe) + increase test coverage to make sure all performance optimization edge cases, etc are covered

muldiv proposal by @MaxGraey also going to be super useful to avoid common source of overflows

I think it’s pretty good as is, but we definitely need to give some grant to the creator of the project who’s been doing it on pure enthusiasm as for now AFAIK.


The only thing I miss right now is Closure support, but it’s being actively worked on.
Not much to say. The rest of the ecosystem works like a charm.


I only have a single request: In order to be able to use IDE, test & debug tools designed for Typescript & Javascript (100’s of them), it will be nice if an AssemblyScript project could be compiled (by TS) to js and run in a nodejs or browser environment with some specific support libraries. The idea is to be able to test and step-by-step debug complex code before compiling it to WASM for portability and speed.

I tried to do that and I found that allowing operator overloading impedes that route, also there is some management of UInt8 arrays that’s non-compatible with TS.

I think this could be useful for AS as a whole, since you get to use all the TS/JS tooling for AS debugging.

If you’re ok with having some restricted version of AS that is 100% compatible with TS’s IDEs and tools and also compilable to .js+libraries for testing and debugging, I offer my help as a test-developer-user and I can also add features if some AS core dev can provide some support and point me to specific points in the codebase where to add the features.

Best regards to all


Hello Again! I actually have a ton I could contribute to on this thread in terms of ideas and suggestions! :slight_smile:

So first, I actually gave a talk recently very related to this! And Here I dive into this topic of contributions and what would be helpful in particular:

From the last timecode, if you have 20 minutes, I’d highly suggest taking a look at it. But essentially I talk about all the tooling and things, and call out some things that’d we want to see to help round out the language and things :slight_smile:

And I’ll answer your questions as well:

I am very very confident in as-pect and it’s features. jtenner has done nothing short of building an amazing testing framework. Shopify, Fastly, and my personal projects all use as-pect and I am very confident in it’s usage.

The only large maintennce things I’ve noticed, is that when we do breaking runtime changes, this does require an update in as-pect. Which has always been done quickly. But, it does take a good amount of hours.

In general as a community, as long as we have someone keeping this up-to-date with the AssemblyScript runtime. I think as-pect is stable, and good to go :slight_smile:

Yes! I agree with Vlad here. as-pect is being done by the enthusiasm of the creator, and I agree a grant to them would be very well deserved. Especially, as I mentioned before, the project does require active maintenance with the runtime until AS hits a 1.0.

cc @vgrichina @willemneal , I actually have a PR open for float support now, that should be ready to merge: nearprotocol/assemblyscript-json/pull/111 (I hit the link limit for new users)

Putting on my Fastly Hat: Fastly very much has an interest in helping to maintain the assemblyscript-json repo with y’all (as shown by my PRs). And already has given me work time for this. My plan next was to spruce up the README. But also happy to contribute some tests :slight_smile:

Glad you caught that colin just posted there regex repo! :slight_smile:

Putting on my Fastly Hat again, this is another thing Fastly plans to start testing (I already started testing it on our platform), and happy to help maintain and contribute to.

Putting on my AssemblyScript Hat, this is also something I think will be important for the project as a whole, and also interested on a personal level to see this improve.

Putting on my Fastly Hat, one last thing we’d probably like to see is a library for encoding. Such as GZIP, and Brotli. As well as other small things that would correspond with handling network requests, that we are already working on. (Such as url parsing, encoding static files into a wasm module, etc… )

Putting on my AssemblyScript Hat, I think Regex was the last base we needed to cover, per feedback of the ecosystem. Which now has something that is workable. I think as a team, we could probably start shifting our focus more on closures. And then maybe host interop (which already is “okay enough” in my opinon :slight_smile: ). At this point, I think people will build what they need for their specific ecosystem (See something like Lume), or let us know where the gaps are.

I’ll let other team members answer this one. While I am familiar with the inner-workings of the compiler, I don’t have a deep enough knowledge to comment specific numbers.

If I remember correctly though, I know it was mentioned, that we can have the compiler, compiling itself in a CI script, would act as a great integration test to really help us with coverage concerns.

Personally I am decently happy with the STD. I think our goal here really is to just do what can be found on window in JS (where it makes sense). There are some small missing features here and there. But nothing that would break backwards compatibility. Or couldn’t be written with a small bit of code (In my experience. And at this point, I write AS like 4-5 days a week).

For instance, I wrote an article on porting a small node script to AS, and only one missing feature was noted:

One thing I would like to see more of in the STD lib though is a more WASI operations. We currently have this covered by as-wasi (I hit the link limit for new users…) . And it’s another case of it being good enough for now. But personally, what I’d really like to see once WASI is a bit more built out, is us to really push our Node Project (assemblyscript/node) . I think it will be a huge jumping in point for Node developers, when they can essentially bring over 90% of their JS using the exact same Node APIs, but in AS. And could be extremly powerful in brining over JavaScript developers to trying WebAssembly. Once we have the APIs in place, if we brought over an event loop, I think this could lead to a large number of Node applications to getting a Wasm speedup, almost nearly for free. But I’m getting a little ahead of myself haha! :slight_smile:


What is the current state of STD, what would you like to be improved&added, and how many human hours approximately do you think it would take?

One word … Date! That’s a big missing feature at the moment :slight_smile:

assemblyscript-regex: What is its the current state, what would you like to be improved&added, and how many human hours approximately do you think it would take?

The current state is brand-spanking-new. As the readme describes, it has just enough features to be considered useful. The immediate focus has been functional correctness over performance, so there is still much work to be done.

At the moment, @MaxGraey has provided some fantastic contributions - I was intending to do quite a bit of cleanup and he has thankfully done that or me.

Personally, I’d like to spend a bit more time consolidating, creating a roadmap, adding some more tests and benchmarking before encouraging more contributions.

Colin E.

Quick pause to give you a shoutout! Your site ( really made concepts click for me. Great to see you here and thanks for the great thoughts. :pray:t3:


as-pect please comment on what is the current state of as-pect (is it sufficiently feature complete? is it sufficiently stable?) and what improvements do you think it would be good to have. How many human hours approximately would be needed to get us there?

Creator and main maintainer of this excellent project is jtenner and it would be great to help him, especially since he always tries to keep this repository up-to-date at the cost of tremendous efforts.

as-bignum @MaxGraey What is its the current state, what would you like to be improved&added, and how many human hours approximately do you think it would take?

I would like finish muldiv, implement novel and cheaper division algorithm for u128 and finish i128 class. Also will be great add more tests. How many human hours approximately do you think it would take? Hard to tell, probably a couple of months.


Hello! Yay! I’m glad you found it helpful! Thank you for calling that out! :slight_smile:


Ah yes! I forgot about Date, and it’s on my TODO list :upside_down_face: :joy:

I know we can grab microseconds currently using WASI, in like an EPOCH-style format, which the host can then use (hopefully their languages built in Date object).

But in terms of formatting a date into a string entirely in AS, it’s something we will definitely need :slight_smile:

1 Like

Status update: me and @willemneal are working on the details of the grant based on the suggestions posted in this thread. Will post it soon.

1 Like

Hello! I am working on glas (WebGL in AssemblyScript), a port of Three.js to AssemblyScript.

It is hard to estimate how many hours it will take to complete the port because there are many unknowns and many things left to do to make glas useful enough for average 3D products like games, but a grant would help speed it up.

I imagine we could guarantee a certain number of hours of work based on a grant, regardless of how far we get in the porting process.

Our first goal is to get a box mesh with lighting and standard material rendering, which we’re very close to.

The porting process has been interesting:

As you may imagine various parts of the dynamic JS code have to be re-factored into something strictly-typed that AssemblyScript can make sense of, f.e. converting from lists that contain POJOs of amorphous types to lists that contain objects with ad-hoc and pre-determined discriminated union implementations and not objects with generics because generics require type unions for variability of contained types, and AS has no unions (yet) thus lists in AS can’t have objects with varying generic union types.

Is this something that may be sponsorable by a grant? :crossed_fingers:


Thanks for submitting the suggestion. It is not directly inline with blockchain ecosystem, so we are hesitant but will still consider contributing to it. In general, we are interested in adding a variety of mathematic and algorithmic libraries to AssemblyScript and that’s where blockchain interests and interests of your project might overlap. So if you have any ideas of developing some general-purpose math/algorithmic libraries or containers, e.g. a library for same-type unions in AS or some containers that are popular in other languages, but not implemented in AssemblyScript (maybe something that you already had to implement for your project, but haven’t extracted into a standalone library), this would be a much better candidate for the grant application.

You might additionally be interested in participating in other AssemblyScript projects mentioned in this thread that we will be supporting, since you are familiar with the AssemblyScript. CC @potatodepaulo who might be reaching you out at some point.


I think there is actually very interesting collab possible.

Imagine website with collectibles like Market — Paras, but every item isn’t just plain image or GIF. Instead you can create custom interactive 3D stuff, etc.

Basically like, but you can sponsor creator by purchasing their shader as NFT.


That’s true. Glas would be something that helps the AS community, but not necessarily Near specifically.

The collectible 3D graphics idea does sound neat! I hope glas will be useful for the AS community, including someone who may make such a marketplace. I’ll be focusing on getting glas there, regardless of a grant.

I have some other ideas I’ve been imagining:

  • Porting Tween.js to AS (animate numbers with easing curves). This lib is small and wouldn’t take long.
  • Porting Cannon.js physics engine to AS.
  • Porting AutoLayout.js to AS (constraint solver, based on Apple Auto Layout, with VFL syntax for describing 2D layouts, and I also want to add the 3rd dimension to make it 3D)
  • Lot’s of porting ideas :smiley:, and in some cases the libs (like Tween.js) area already written in TypeScript.
  • Implementing a dependency-tracking reactivity system (reactive computations) in AS (I made one in JS already, so porting over my own impl)
  • Making a DOM interface for AS. Is it worth it? Or should we wait for ability to reference DOM APIs in Wasm? How far off is that?
  • JSX syntax support for AS, which can take advantage of a DOM interface. In particular Custom Elements with JSX templating written in AssemblyScript is an attractive idea.
  • WebGL interface for WASI, on top of glfw for windowing.

Non of those are specifically helpful to Near, but more so to AS Community. Anything there Near folks may find useful?

Hey! I have posted the grant here: AssemblyScript Grant Q1 2021 Please feel free to submit the claims and apply for more projects.