I see that @rckprtr experimented with an AssemblyScript CDK: GitHub - rckprtr/cdk-as: Unofficial Experimental AssemblyScript CDK for DFINITY.
Do others in the community want this to become a reality?
Are there any current efforts underway?
Is there any reason this shouldn’t be done?
Thanks!
So I think its interesting still…
One huge catch is you can’t take a TypeScript library and then compile it to AssemblyScript. So let’s see you need regex, you need to use the AS specific regex library.
The AS community is really helpful and constantly pushing forward, so Im guessing a ton has changed since I originally made that.
Rick
What are you looking for in an AssemblyScript CDK over a TypeScript CDK? I assume the only real reason is performance, and basically just cycle cost.
Why shouldn’t it be done? Maybe it should be, but not sure if it should have priority over something like Azle that is aiming for full TypeScript/JavaScript support. AssemblyScript is a “subset” of TypeScript, it will have far fewer language features than Azle gives you, but performance should be better. How much better? From our benchmarks I’d expect generally speaking around 2-4x. That’s for cost in USD, not speed or memory. I’ve seen no significant differences with canisters written in Azle vs Rust or Motoko on the speed of computation.
I share the same thinking.
It might be an alternative to Motoko as a “scripting language” for the IC, inheriting some of the good parts of TS without the performance hit of Azle. Full TS/JS support is absolutely needed, but if one wants to give up on tons of libraries for a more cycles efficient CDK, AssemblyScript might give Motoko a run for its money
Hey Jordan. 
Thanks for adding your knowledge to the discussion.
Azle is great for most use cases; however, JS devs should have another option when performance, storage and operational costs (cycles) matter more than development costs and time-to-market.
Here are my random thoughts and opinions on the matter:
High traffic dapps should optimize in every way possible.
Dapps with high storage needs should optimize for memory/cost.
Any loss of performance in dapps has a cumulative affect on the performance of the subnet.
The ability to use specific data types like 8 bit numbers instead of 64 bit numbers could have a significant impact on storage limits, depending on the types of data a dapp needs to store.
Paying for cycles is like paying a utility bill, and who wouldn’t want to cut their utility bills in half?
Better performance means fewer messages like this: “Exceeded the instruction limit for single message execution”.
A batch function can complete more operations before exceeding the instruction limit.
String manipulation of large text is particularly demanding, and a 2-4x performance gain could determine if a dapp can fulfill its functional requirements or not.
AssemblyScript is a powerful alternative to Motoko. While there’s no regex or JSON support in Motoko that I’m aware of, these libraries already exist for AS:
An AssemblyScript CDK would make JS/AS devs first-class citizens on the IC. I can’t think of any reason that wouldn’t be good for IC community, except that it would flood the market with more developers and increase competition for jobs currently filled by Motoko and Rust devs. If that’s a concern to anyone, then offset it with more ICP (not financial advice).
In short, a dev would chose AssemblyScript for the same reasons as Motoko or Rust: optimization of performance, storage and cost. If JS/AS devs were treated like first class citizens, it would increase adoption of the IC with high performance dapps that not only demonstrate the full capabilities of the IC, but assist in optimizing the entire network.
I would love it if Demergent Labs added an AssemblyScript CDK to their list of projects! 
Hi Rick. Thanks for responding!
It would be nice to have access to all TypeScript libraries, but since the AssemblyScript ecosystem offers more libraries than the current Motoko ecosystem, it’s well worth the effort to build a CDK.
In my opinion, the ability to compile TypeScript syntax to wasm with access to wasm data types and low level functions, makes AssemblyScript the most enticing option for the IC. I think there’s a good chance it would be a catalyst for mass adoption.
Thank you for pioneering the idea. I hope your wagon trail gets some pavement now.
Thanks for your opinion Diego. I think those priorities make sense. So now that we have Azle, it seems like a good time to start building an AssemblyScript CDK.
Very well said Zane!
Azle has an enormous amount of work left for us to do, and our new priority is the Python CDK. But I agree that AssemblyScript could be an excellent next step, I will deeply consider it. We are also planning on building a CDK framework, using it on both Azle and Kybra (Python). Perhaps at that point plugging in AssemblyScript could be simple…though our framework will be focused on high-level languages.
And here’s the bottom-line thought from me, full TypeScript/JavaScript support will be far more useful to devs and bring far more adoption than AssemblyScript ever will (until it improves its language compatibility). If you look at recent history as an example, AssemblyScript still struggles compared with TypeScript in the real world. As far as I know it’s still a toy language without much usage. We can also look to the NEAR ecosystem. They’ve had AssemblyScript support from the start basically, and I imagine it isn’t that widely adopted compared with Rust (not sure on those numbers though, I would just guess that). And considering they just made a huge fuss about their JavaScript SDK, I imagine they might believe the utility and demand for real JS outstrips the demand for a performance-sensitive subset.
As Brendan Eich says, always bet on JS. The language is just so powerful, as in the language itself. I believe people are willing to pay for that.
If someone else wants to try building this, we can provide guidance.
Thanks for offering your support. Just out of curiosity, what skillsets would be required to build a CDK?
I haven’t dealt with building a CDK that compiles directly to Wasm, as Azle builds a lot of of the Rust CDK.
But I would say it’ll be a lot of compiler wrangling, understanding the implementation details of programming languages, manipulating ASTs, and a working knowledge of Wasm.
Just wrangling languages and compilers around to get them to do what you want.