what is the goal of j5e?

[tve]

Ok, someone has to make a first post after the official welcome message, right? :-)

I've started using the moddable sdk. I'm a (former?) micropython user. I've heard of johnny-five but have not used it. I find ecma-419 not exactly intuitive but in the end well done. I'm wondering... why j5e? I assume that you prefer the johnny-five API for stuff over ecma-419 and so you're building j5e as a layer? (Nothing wrong with that, just trying to clarify.)

[dtex]

Peripheral classes from TC-53 weren't a thing when I first built J5e, so I didn't build it as an alternative, but there is a difference in my approach. The 419 peripheral classes are intentionally minimal to keep conformance easy for implementors, whereas J5e tends to bring more methods and options to the user (in the spirit of Johnny-Five).

I love J5, and yes, it heavily inspires J5e. I've attended and/or run a bunch of JS workshops over the years where developers with varying degrees of experience have used J5 to blink LEDs, make robots dance, or monitor their environment. In a few hours, they go from zero hardware experience (and occasionally zero JavaScript experience) to empowered enthusiasts. To that end, It's a lot easier for a novice to write led.blink() than it is to set up a loop and use a bitwise operator to toggle the state of a digital pin. That's just the simplest example though. Some of the J5 classes are pretty complex on the backend, but the API glosses over that to make it easy on users.

The thing I don't like about Johnny-Five is that it requires node.js to run. I love node.js too, but requiring it limits the number of platforms on which J5 can run. That's the inspiration for J5e. Building upon ECMA-419 provides a standard hardware API that I can use to write peripheral classes that run on multiple platforms, and I think that's pretty cool.

I've made a few changes to the J5 experience, all designed to make J5e even easier for new users. If you have a few minutes to spare this video (starting at about 55s) covers my motivation.

[dtex]

Also, I didn't even realize Discussions were a thing on this repo, LOL. This feature is new to me.

[tve]

Nice talk!

[tve]

What is the status of j5e? It looks like you haven't worked on it in a bunch of months. Probably sitting there awaiting the mythical free time to continue? Or are you working on other options?

[dtex]

Honestly, I'm waiting to share it with other people. Need to travel and do some talks focused on J5e. I've got two things I'm working on right now; Stepper motor support and support for the PCA9685. Can't recall if this will be the first ECMA-419 expander or not.

[phoddie]

Can't recall if this will be the first ECMA-419 expander or not.

Second. ;)

[monteslu]

Full on firmata.js with node-serial for sure, but it's IO class's only dependency is EventEmitter. Is there not an implementation of that on those targets?

[dtex]

I know of one

[phoddie]

The goal was not Firmata. The goal was to validate the ECMA-419 provider design by implementing a Firmata client as a provider. Bringing up firmata.js would have been more of a distraction than a help in that. And it would have been quite a bit bigger, limiting where it can run. One of my goals in exploring ECMA-419, especially at that time, was is to see how small a system we can run on.

It is probably possible to run firmata.js on the XS engine. As you note, it is mostly just standard JavaScript with no complex dependencies (other than the I/O!) It might be a stretch to fit that into an ESP8266, but an ESP32 is likely fine.

[dtex]

Regardless of the goal of Peter's implementation, I think there are some advantages to having a new, lighter firmata js. First, I'm worried about the state of the firmata project now that Jeff (and Rick) aren't as involved as they used to be.

I'd really like to see Peter's implementation controlling a device with firmata in JS (as opposed to the client, firmata.js).

Imagine how much easier it would be to grow that stack vs. having half the stack in Arduino C. I know a JS version won't happen on an Uno, but we would be able to quickly add more IOs to the protocol and get them implemented vs. waiting a decade (SPI). That's not a knock on anyone involved with firmata, just an acknowledgment that it's a hell of a lot of work, and it's a lot less work with 419.

[phoddie]

To be clear, there's surely no intention to compete with any existing Firmata implementation. This was a learning exercise for me – mostly about the ECMA-419 provider but it was also my first experience with Firmata.

I did both the Firmata client and server as part of the exercise. The server uses ECMA-419 I/O, of course. It hasn't been extensively tested, but it could be useful as a starting point for additional work. To Donovan's point about extensibility, I added a "Poco" I/O type to do some simple graphics. That was very quick to do (three cheers for JavaScript!).