# The best way to develop Motoko? **URL:** \ **Category:** Language Support\ **Created:** [June 5, 2021, 8:57pm UTC](https://forum.dfinity.org/t/the-best-way-to-develop-motoko/4854 "2021-06-05T20:57:40Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![amanelis](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/amanelis/32/2780_2.png) [@amanelis](https://forum.dfinity.org/u/amanelis)\ **Post date:** [June 5, 2021, 8:57pm UTC](https://forum.dfinity.org/t/the-best-way-to-develop-motoko/4854/1 "2021-06-05T20:57:41Z")
Given a few standard approaches to writing code: - Write code, write test, run test =\> pass/fail - Write code, compile =\> returns success or errors Currently using dfx. It seems the feedback loop for writing motoko can be a slightly slow if you follow this approach: - Write code, execute `dfx build` =\> returns success or errors - Deploy or reinstall code to canister - Then call the canister’s method Is there a faster and more iterative approach to writing motoko, quickly compiling and testing? What are some best practices here? I noticed there was a `moc` executable/binary sitting in `~/.cache/dfinity/....../moc` ---
**Author:** ![ethdev1](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/ethdev1/32/1788_2.png) [@ethdev1](https://forum.dfinity.org/u/ethdev1)\ **Post date:** [June 5, 2021, 9:04pm UTC](https://forum.dfinity.org/t/the-best-way-to-develop-motoko/4854/2 "2021-06-05T21:04:55Z")
would like to know this too. painful to build, re-install and call the method. ---
**Author:** ![flyq](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/flyq/32/3637_2.png) [@flyq](https://forum.dfinity.org/u/flyq)\ **Post date:** [June 6, 2021, 1:42am UTC](https://forum.dfinity.org/t/the-best-way-to-develop-motoko/4854/3 "2021-06-06T01:42:49Z")
Try [vessel](https://github.com/dfinity/vessel) for module test. ---
**Author:** ![claudio](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/claudio/32/322_2.png) [@claudio](https://forum.dfinity.org/u/claudio)\ **Post date:** [June 6, 2021, 3:37pm UTC](https://forum.dfinity.org/t/the-best-way-to-develop-motoko/4854/4 "2021-06-06T15:37:11Z")
Vessel is really a package manager and won’t quite help with this problem. There’s a nice template for writing motoko libraries with unit tests here. > **[kritzcreek/motoko-library-template](https://github.com/kritzcreek/motoko-library-template)** > > A template for creating Motoko libraries. Contribute to kritzcreek/motoko-library-template development by creating an account on GitHub. But that’s best for the development of libraries that don’t require inter-canister messaging or actors. That template actually uses the motoko-matchers framework, which can also be used to test Motoko canisters (though I have not tried the canister support myself): [https://kritzcreek.github.io/motoko-matchers/](https://kritzcreek.github.io/motoko-matchers/) Another way to speed up working with dfx is to use the more lightweight emulator, not a full replica, but the emulator is still missing some features of the replica (like measuring cycle consumption). You can select the emulator, instead of local replica, using `dfx start --emulator` (better `dfx stop` any replica’s before you do this and perhaps even do `rm -r -f .dfx` in your project folder) The `moc` binary you found is the compiler but can also be used as an interpreter. Again, it does not model all features of the platform such a cycle management or state rollback on trap. You can use it to test simple actors and inter-actor messaging though. Your mileage may vary. ---
**Author:** ![ajerni](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/ajerni/32/2104_2.png) [@ajerni](https://forum.dfinity.org/u/ajerni)\ **Post date:** [June 6, 2021, 3:39pm UTC](https://forum.dfinity.org/t/the-best-way-to-develop-motoko/4854/5 "2021-06-06T15:39:56Z")
Check this: > [@UPDATED: Create IC App - Modern, unopinionated templates for all frameworks](https://forum.dfinity.org/t/easiest-way-to-get-started-with-frontend-templates-for-react-vue-svelte-based-on-vitejs/2589): > > Its based on ViteJS so you get hot module reloading etc. out of the box and its not very opinionated. It uses a regular dev server while you’re developing (for speed) and when you are finished you can deploy the frontend to the IC. Comes with an example Counter canister. At the moment React, Vue & Svelte are supported. Lemme know if there’s any issues or question marks.