Robot Not a Dev? Pre-order Now
Not a Dev?

Misty Community Forum

Javascript Impersonation Syndrome


I just attended your Seattle Hackathon. Thanks for the opportunity to play with a Misty!

I found the JS environment unsettling to use, as it was ‘javascript / not javascript’-like. Some immediate improvements I think you could make:

  • Don’t invent your own packaging format / .json file. How about you leverage npm’s package.json? This will make people feel right at home. In particular, requiring a uniqueness-guid felt very not-javascripty, more like I was back in the days of heavyweight Java-like development. Yes, Guids prevent naming collisions, but the world as a whole (and especially the javascript community) have moved away from these types of anti-collision techniques and instead given ‘works most of the time but much more human friendly’ approaches such as simple namespaces.

  • Using CamelCase instead of pascalCase for your API functions immediately says, “this wasn’t written for the Javascript community, instead it was written for a different language and bulk imported”. Javascript-feel is much more important than cross-language API exactness matching.

  • As noted in “Thoughts on the development experience”, there were many functions which were duplicates of javascript bcl functions or commonly used libraries which were “Misty-ish” and very different. Calling conventions, this pointers, globals, async tasks were all different. This is a huge barrier to javascript developers. I would much rather have a setTimeout(…) function that was right 99% of the time and wierd 1% of the time than have to learn a new misty.RegisterTimerEvent(…) that has different parameters and behaves differently 100% of the time.

  • Jay

@jay.beavers Welcome to the community, and thanks so much for the quality feedback! We’re taking all this in as we think about the future of Misty’s API.


I felt somewhat constrained today by the debug/feedback process when learning about Misty programming. Principally it was two issues:

  1. I’m spoiled by a very fast dev/run/test turnaround for all my coding environments
  2. I’m used to having real time, touch free feedback on my coding via a ‘tail log’.

Granted, “printf debugging” sucks compared to a full IDE experience, but for better or worse it’s the world I live in as a web, services, or apps developer today. Fortunately, my environments make this much easier for me to live with. For example, if I’m testing services/NodeJS code on my dev box, I can keep an always open console window that spews my debug log at me and restarts when I change something without touch. For NodeJS, I use “nodemon” to auto-restart my service whenever I change a file and the console log nicely demarks the restart.

For services work, I always keep a “docker logs -f” console window running. It’s not quite as nice/fast as nodemon, but it’s pretty close. My docker deploy scripts generally take 5ish seconds to hit my dev instance.

In contrast, the Edit->Save->Restart->Log cycle from the Misty was much longer. I had to manually drag & drop two files every time I made a code change. I had to manually stop & restart the skill. I had to manually clear the chrome debug log window to get a clear debug spew/demarcation. As someone used to a “near painless” dev loop, this was starkly annoying.

I’d suggest a few changes:

  • Support the equivalent of a “docker tail -f” command, e.g. an always connected console log spew that survives skill changes and makes a clean demark on restart.

  • Support auto-upload on file changed (e.g. like the file watchers in nodemon). This likely means you need to allow individual JS files to be uploaded, rather than a zipped doublet of js/json.

  • Consider making a CLI tool, like the azure-cli or aws-cli that gives you both a “logs tail” and a “watch/upload/restart” command that you can pop in your tabbed console windows. After all, we’re already spoiled by our existing tools that support this.

Looking at the JSON file and what it contains, it feels to me like the value it brings is less than the complexity/friction it adds to your developer story. Think hard, do you really need it? For example, one aspect of it that seems important is the skill timeout. Could that be replaced with misty.setSkillTimeout(360000); at the top of the JS file, if needed?


Thank you for all of this. Very helpful

I think you mean:

“Using camelCase instead of PascalCase for your API functions immediately says”




  • jaY

Thanks for sending this along @jay.beavers!


I had some similar thoughts as well.

Using WebSockets to control the robot instead of running code directly solves the issue, you can use Node and whatever packages you want, run in an environment you control. But there’s something kind of disappointing about that… it makes it feel like just a remote control device.

But now I’ve been thinking about this a little more, I realize this is still a reasonable basis – maybe the easiest way to get a “normal” JavaScript environment on the robot directly is just to have a standalone executable that locally controls the robot via WebSockets.

THEN I thought about it a little more, and realized this is what ROS (the Robot Operating System) does, at least from my understanding. I haven’t used ROS, but my impression is that it is largely a message bus for your sensors, motors, and control processes to communicate over. I suspect the situation for Misty is normal in robotics: you have these disparate pieces of hardware, and even completely independent computation on different platforms (Misty’s Android and Windows processors), and there’s no real “native” API, no single process that controls everything. Instead it’s all communication. If you embrace that then things like these JavaScript environment issues become easier.