# Node-motoko Question - Dependency on oCAML? **URL:** \ **Category:** Language Support\ **Created:** [October 15, 2022, 12:37pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916 "2022-10-15T12:37:30Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [October 15, 2022, 12:37pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/1 "2022-10-15T12:37:30Z")
Hey @rvanasa, does [GitHub - dfinity/node-motoko: Compile and run Motoko smart contracts in Node.js or the browser.](https://github.com/dfinity/node-motoko) still depend on the oCAML compiler in some way, or is it pure js? Meta question for you + @lastmjs Could Azel compile/run a motoko contract with this? ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [October 15, 2022, 1:06pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/2 "2022-10-15T13:06:28Z")
Looking through the code,y buest guess is the Motoko compiler has been compiled into Wasm, and can thus be used in node. Look at the versions/latest directory. Azle could incorporate this at compile-time at least, I’m not sure the use case though. ---
**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\ **Post date:** [October 15, 2022, 2:32pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/3 "2022-10-15T14:32:59Z")
It looks to me like it’s been compiled to JavaScript and not Wasm: [node-motoko/versions/latest at c906f862dad4d314aa60576134917cffe1908212 · dfinity/node-motoko · GitHub](https://github.com/dfinity/node-motoko/blob/c906f862dad4d314aa60576134917cffe1908212/versions/latest) The ability to do this type of thing has been around since: > > > This relates to https://github.com/dfinity-lab/actorscript/issues/8. I went with… js\_of\_ocaml since BuckleScript seems to heavily rely on node.js and I would rather avoid that. > > I followed the instructions at http://ocsigen.org/js\_of\_ocaml/, which offered a number of options for build with js\_of\_ocaml. I took the ocamlbuild approach since we were already using it, and using jbuilder via nix for this seemed to use ocamlbuild anyway. > > I've cleared the first few hurdles of building using \`js\_of\_ocaml\` with nix but now I'm encountering an issue that I'm not sure how to address. The error relates to renaming the build product to be the \`asc\` binary, which would wouldn't want to do anyway. I'm assuming \`asc.js\` might be fine instead, and hoping someone more familiar with Makefiles can help be figure this part out. ---
**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\ **Post date:** [October 15, 2022, 2:40pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/4 "2022-10-15T14:40:09Z")
> [@skilesare](#): > > Could Azel compile/run a motoko contract with this? If that’s a goal for Azle maybe [GitHub - dfinity/motoko.rs: Motoko concrete syntax parser in Rust.](https://github.com/dfinity/motoko.rs) / [GitHub - dfinity/ic-mo-vm](https://github.com/dfinity/ic-mo-vm) is a better route. Perhaps @matthewhammer or @rvanasa can comment on that. ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [October 15, 2022, 3:01pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/5 "2022-10-15T15:01:48Z")
The use case would be that a black-holed canister could compile open-source code in a dependable way, making sure that only ‘blessed’ versions of canisters can be deployed. There are other ways of doing this of course, and Cover is trying to serve some of these use cases, but as we move toward DAOs and autonomous software, it would be cool if these DAOs could automate deployment, upgrades, or even create composable canisters on the fly. Imagine a DAO builder that lets you pick modules from a list and then compiles and deploys the DAO for you. ---
**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\ **Post date:** [October 15, 2022, 3:20pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/6 "2022-10-15T15:20:55Z")
For what it’s worth, Motoko Playground uses the JS version of the Motoko compiler as well. Would that be a sufficient basis for what you’re describing? ---
**Author:** ![rvanasa](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rvanasa/32/23650_2.png) [@rvanasa](https://forum.dfinity.org/u/rvanasa)\ **Post date:** [October 15, 2022, 3:58pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/7 "2022-10-15T15:58:48Z")
Yep! `node-motoko` uses `js_of_ocaml` under the hood, so everything is pure JavaScript. @matthewhammer and I are currently working on [a Rust interpreter for Motoko](https://github.com/dfinity/motoko.rs), which we are calling “MoVM.” This is much closer to the metal compared to `node-motoko` (probably at least 2-3 orders of magnitude faster than `js_of_ocaml` running on Azle). Here are [some benchmarks for the project](https://github.com/dfinity/canister-profiling/tree/gh-pages/collections) and [an example canister](https://github.com/dfinity/ic-mo-vm/pull/5) for reference. This project is very early in development, so it could still be worth looking into running the `node-motoko` compiler from an Azle canister. [Here is the js\_of\_ocaml file (moc.js)](https://github.com/dfinity/node-motoko/blob/main/versions/latest/moc.min.js) which should contain everything you need if you want to try this experiment. Cheers! ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [October 15, 2022, 5:13pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/8 "2022-10-15T17:13:33Z")
So the JS version of the Motoko compiler compiles Motoko to Wasm? If so @skilesare this sounds possible to me. And hopefully it wouldn’t even need to be incorporated into Azle, you should be able to install it with npm. We just need to make sure that it’s self-contained i.e. doesn’t rely on any APIs not available to a canister. ---
**Author:** ![rvanasa](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rvanasa/32/23650_2.png) [@rvanasa](https://forum.dfinity.org/u/rvanasa)\ **Post date:** [October 15, 2022, 6:48pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/9 "2022-10-15T18:48:15Z")
`moc.js` uses a virtual file system, so it’s fully self-contained, at least up to browser compatibility. Here’s a code snippet for compiling IC Wasm from Motoko: ```javascript import { Motoko } from "./moc.min.js"; const source = 'actor { public query func example() : async Text { "Hello" } }'; Motoko.saveFile('Main.mo', source); const result = Motoko.compileWasm('ic', 'Main.mo'); console.log(result.code.wasm); // Uint8Array(...) ``` I think there’s a solid chance that this could work! ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [October 15, 2022, 7:42pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/10 "2022-10-15T19:42:50Z")
Very cool, I will have to try this out to see if it works ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [October 15, 2022, 7:44pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/11 "2022-10-15T19:44:17Z")
Is the compiler completely synchronous? Azle doesn’t have support for promises or async/await yet. ---
**Author:** ![rvanasa](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rvanasa/32/23650_2.png) [@rvanasa](https://forum.dfinity.org/u/rvanasa)\ **Post date:** [October 15, 2022, 7:48pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/12 "2022-10-15T19:48:18Z")
Just confirmed that `moc.js` is fully synchronous. ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [October 15, 2022, 8:06pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/13 "2022-10-15T20:06:37Z")
Very nice, I’m excited to test this out ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [October 24, 2022, 8:55pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/14 "2022-10-24T20:55:52Z")
This doesn’t currently work in Azle for a couple reasons, one being this syntax error problem: [node-motoko causes syntax error · Issue #749 · demergent-labs/azle · GitHub](https://github.com/demergent-labs/azle/issues/749) That might be a bug with the underlying Boa JS engine. Another problem has to do with the next version of Azle, we have some buffer size issues with the way were handling some things, and because the node-motoko code is so large (~2mb) this causes problems. ---
**Author:** ![rvanasa](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rvanasa/32/23650_2.png) [@rvanasa](https://forum.dfinity.org/u/rvanasa)\ **Post date:** [November 30, 2022, 10:54pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/15 "2022-11-30T22:54:32Z")
Just checked back on this thread. The syntax error does seem like a bug with the Boa engine. It might be more feasible to run the interpreter (using `motoko/versions/latest/moc_interpreter.min.js`), although this would still be about 1.2 MB of generated code. This was certainly worth a try! I’ll keep this in the back of my mind in case there’s a way to eventually make this work. ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [November 30, 2022, 11:03pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/16 "2022-11-30T23:03:30Z")
Once the Wasm binary limit is increased the 1.2mb should be a non-issue I’m hoping. The syntax error is interesting and I will look into it more later, maybe once the Wasm binary limit is lifted. ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [January 19, 2024, 5:47am UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/17 "2024-01-19T05:47:31Z")
By the way this is finally working in Azle! > ---
**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\ **Post date:** [January 19, 2024, 1:24pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/18 "2024-01-19T13:24:43Z")
Is it just the interpreter, or will the compiler work as well? ---
**Author:** ![lastmjs](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/lastmjs/32/3406_2.png) [@lastmjs](https://forum.dfinity.org/u/lastmjs)\ **Post date:** [January 19, 2024, 4:26pm UTC](https://forum.dfinity.org/t/node-motoko-question-dependency-on-ocaml/15916/19 "2024-01-19T16:26:33Z")
Let me check and get back to you