►
Description
To learn more about critical open source JavaScript projects like Appium, Dojo, jQuery, Node.js, and webpack, and 27 more checkout The OpenJS Foundation: https://openjsf.org/
ECMA-419: The ECMAScript Embedded Systems API and J5e - Donovan Buck, BrandExtract
JW Grand Ballroom 2
Speakers: Donovan Buck
ECMA-419 is a new specification describing a standard API for interfacing with hardware on embedded systems running JavaScript. This leads to the ability to interact with a vast universe of hardware peripherals such as LED's, motors, cameras, lidar, accelerometers, and more. In the past, controlling hardware with JavaScript meant a host server running node.js, or proprietary platforms running a subset of JavaScript. Now alongside ECMA-419 we have modern, ECMA-262 conformant engines running on humble microcontrollers like the ESP8266 or ESP32 with no need for a host server. This talk is an introduction to ECMA-419, JavaScript engines available for Microcontrollers, and J5e (Johnny-Five for embedded systems), a beginner-friendly IoT and robotics framework built upon ECMA-419.
A
A
The
title
of
this
talk
is
ecma
419,
the
ecmascript
embedded
systems,
api
and
j5e,
which
is
a
bit
of
a
mouthful.
I've
decided
it's.
The
worst
title
for
talk
ever
should
have
called
it:
the
future
of
js
robotics,
the
future
of
js
iot,
the
future
of
smart
things
with
javascript,
but
no,
I
called
it
ecomma
419
the
ecmascript
embedded
systems,
api
and
j5e,
because
I'm
not
very
good
at
marketing.
A
A
A
A
It's
been
the
standard
bearer
for
javascript
on
hardware.
Ever
since
it's
been
used
at
hundreds
of
hackathons
to
teach
thousands
of
people,
who've
never
worked
with
hardware
how
to
do
so
in
a
language
that
they
already
know,
but
it's
also
been
used
to
teach
people
who've,
never
written
a
single
line
of
code
in
any
language.
It's
how
I
learned
to
work
with
hardware.
A
It
was
a
wonderful
hello
world
hardware
experience
and
because
of
the
great
experience
I've
had,
I've
become
a
contributor
to
johnny,
5
and
other
javascripts
robotics
projects
over
the
years,
because
I
want
to
help
other
people
have
the
exact
same
feeling
that
I
had
this
program
that
you
see
on
screen.
Here
is
a
typical
johnny
5
program.
It's
the
hello
world
that
I
was
referring
to,
where
all
we're
doing
to
make
it
happen,
is
requiring
a
couple
classes
that
we're
going
to
need
a
board
and
a
device.
A
A
A
A
But
yes,
there
were
ways
around
that
you
could
change
out
a
component
at
the
fermata
I
o
level
or
at
the
node
serial
port
level,
to
change
the
the
transport
layer
that
we're
using
to
talk
to
our
hardware.
We
could
switch
it
out
with
wi-fi
or
bluetooth,
and
the
cool
thing
was
that
the
surface
api
for
fermata
did
not
change.
So
the
program
that
the
user
had
written
did
not
have
to
change.
John
e5
did
not
have
to
change.
We
could
control
hardware
differently
using
the
exact
same
code,
save
for
requiring
one
different.
A
A
A
There's
no
changes
required
to
the
user
program
safe
to
require
a
different
plug-in
it
all
just
kept
working
but
single
board.
Computers
are
expensive
and
prices
is
a
problem
because
everybody
wants
to
build
something
right:
iot
products
require
cost
effective,
embedded
systems
and
single
board.
Computers
are
not
cost
effective,
they're
great
for
hobbyists
they're
great
for
prototypes,
but
they're,
not
great
for
entrepreneurs.
A
So
we
came
up
with
another
to
beat
a
dead
horse.
We
came
up
with
another
solution.
We
switched
out
the
fermata,
I
o
layer
with
another.
What
we
call
I
o
plug-in
in
this
case.
This
amp,
I
o,
is
the
one
I
want
to
talk
about,
and
companies
like
electric
imp
and
particle
had
services
where
they
offered
hardware
and
then
a
cloud
service
that
lets
you
communicate
with
that
hardware,
wherever
it
was
in
the
world.
A
So
we
just
replaced
that
format.
I
o
layer
we're
able
to
communicate
with
hardware
in
a
completely
different
way,
this
over
http
to
return
server
down
to
user's
local
wi-fi
and
control
their
thermostat,
their
robot
whatever
so,
we've
gone
through
four
different
hardware
stacks
here,
which
is
pretty
cool
without
changing
the
john
d5
code
or
the
user
program.
Significantly
at
all,
the
formatted
js
api
became
a
de
facto
standard
for
hardware
on
javascript,
but
sadly,
through
all
of
these
stacks,
you
still
need
a
host
computer.
A
Of
course
people
would
always
ask.
Can
I
just
run
johnny
5
on
the
microcontroller
and
sadly,
sadly,
no,
you
cannot
johnny
5
needs.
Node
node
needs
an
operating
system
and
the
microcontrollers
that
we're
talking
about
are
tiny.
They
may
only
have
32k
of
ram
for
your
code,
so
it
wasn't
going
to
happen
it's
impossible.
I
acknowledge
the
value
of
such
a
thing.
I
value
I
acknowledge
the
need
for
such
a
thing,
but
it
just
it
just
wasn't
going
to
happen.
A
They
were
either
subsets
of
the
language
or
they
were
built
to
old
versions
of
language.
Old
specifications,
es
2015
things
like
that,
so
they
were
kind
of
meh
and
we
also
we're
still
going
to
need
standard.
I
o,
because
if
we're
going
to
take
time
to
build
something
like
john
e5
for
embedded
systems,
we
can't
have
every
embedded
system
have
a
different
way
to
communicate
with
the
hardware.
We
want
to
build
it
once
and
have
it
work
for
a
lot
of
people
out
there.
A
That
was
the
thing
that
the
I
o
plug-in
ecosystem
of
back-end
nodebots,
provided
we
didn't
have
that,
but
at
jsconf
in
2018,
rick
waldron,
the
inventor
of
johnny5,
pulled
me
aside,
and
he
wanted
to
show
me
the
xsjs
engine
from
audible.
He
was
really
excited
and
he
had
a
gleam
in
his
eye.
I've
never
actually
seen
the
gleam
in
someone's
eye,
but
that
was
a
gleam
in
his
eye.
He
was
very,
very
enthused
and
he
was
showing
me
this
javascript
engine
and
I
was
like
yeah,
okay
thinking
of
those
other
projects.
A
A
So
some
time
passed.
Oh
actually.
Why
is
that
standard
api
so
important
with
johnny5?
I
could
build
something
like
a
gps
class
for
one
device,
the
arduino
in
this
case
and
without
having
to
do
anything
else.
It
would
just
work
on
all
the
devices
that
john
e5
supported.
So
that
was
a
really
nice
and
that's
the
kind
of
experience
that
you're
going
to
want
to
have
if
you're
developing
for
open
source
so
some
time
past,
then
I
got
a
an
email
just
completely
out
of
the
blue,
telling
me
about
tc53
ecma
technical
committee
53..
A
They
were
forming
and
they
were
tasked
with
bringing
standards
to
js
for
embedded
systems,
and
the
first
thing
that
they
were
going
to
work
on
was
a
standard
javascript
api
for
direct
access
to
underlying
hardware,
digital
pwm,
all
the
things
that
we
need
in
order
to
control
that
hardware.
So
I
traveled
to
the
first
in-person
meeting
as
an
invited
guest.
I
was
kind
of
nervous
kind
of
terrified
to
be
honest,
but
everyone
turned
out
to
be
really
nice.
A
It
was
a
good
experience,
but
in
the
opening
remarks
someone
referenced
the
question
that
shall
not
be
asked,
and
I
I
so
I
lacked
tact
and
by
the
way-
and
I
raised
my
hand-
and
I
was
like
what's
the
question
that
shall
not
be
asked:
why
use
javascript
on
hardware?
It's
slower,
it
consumes
more
resources.
A
A
So
I'll
admit
that
those
cons
are
true.
It
takes
more
resources,
it's
a
little
slower,
but
there's
a
lot
of
good
reasons
to
use
javascript
on
hardware.
Let's
start
with
the
language
itself,
javascript's
runtime
model
is
built
on
an
event
loop
that
event
loop
executes
code.
It
collects
and
processes
events
it
executes
subtasks
and
it's
patient
throughout
this
process.
A
Javascript
is
designed
to
wait
for
user
input
to
interact
with
things
in
the
real
world
in
this
case,
in
the
browser
right
this
model,
this
event,
loop
model
is
necessary
for
working
with
hardware
and
it
has
to
be
scaffolded
in
other
languages
like
c
now,
if
you've
worked
with
an
arduino,
they
give
you
the
loop
method.
You
know,
that's
not
part
of
c.
A
This
is
actually
from
a
talk.
That's
more
than
12
years
old.
This
is
from
jsconfigu
2010
and
they
were
just
kind
of
looking
into
the
future.
This
was
before
javascript
on
hardware
was
really
a
thing
and
they
were
talking
about
how
javascript
is
the
language
kind
of
fit
beautifully
with
real
world
hardware
applications,
and
in
this
particular
example,
I
I
don't
find
inspiring.
A
Were
there
chaining
methods
on
a
single
object
where
they're
telling
the
lights
to
go
to
75
and
then
damn
after
120
seconds,
but
it
did
inspire
one
person.
Chris
williams,
he
wrote
this
in
a
blog
post
in
2012,
oops,
sorry
by
modeling,
real
world
objects
and
actions
is
chainable.
Evented
processes
felt
almost
natural
and
he
was
inspired
enough
and
had
enough
need
to
go
out
and
create
node
serial
port
node,
serial
port
enabled
for
moda
for
moda
enabled
johnny
5..
All
these
things
exist
because
javascript
is
a
great
language
for
hardware.
A
So
back
back
to
the
language
asynchronous
operations,
there's
multiple
ways
to
handle
asynchronous
code
built
into
javascript
and
you're
free
to
choose
the
one
that
works
best
for
you
and
there's
more
than
just
language.
When
it
comes
to
javascript,
love
or
hate
it
javascript
is
eating
the
world.
It's
the
webs,
lingua
franca
most
web
apis
that
we
access
and
if
you're,
building
an
iot
device
or
a
smart
thing,
there's
a
good
chance
you're
going
to
be
accessing
web
apis.
A
They
use
json
in
the
request
bodies
of
the
response
bodies
in
order
to
communicate,
and
while
there
are
json
parsers
available
for
most
languages
now
json
is
javascript
right.
It
just
works
in
javascript,
so
it's
not
going
to
be
better
or
faster
than
what
we
have
available
in
javascript
for
us
and
there's
some
exciting
things
happening.
A
A
A
A
A
I
did
ask
the
secretary
general
if
it
could
be
ecma-420
and
he
said
no,
but
you
know
it
went
through
and
it
standardized
all
those
things
and
I'm
going
to
tell
you
right
now.
As
a
as
a
node
developer,
I
was
a
little
frustrated
with
it
and
here's
why
I
wanted
those
things
that
I
talked
about
in
the
language:
the
event
emitters
where
you
close
the
circuit.
The
light
turns
on
you
open
the
circuit.
A
The
light
turns
off,
there's
no
schedule,
it
happens
many
times
whenever
the
user
wants
to
do
it
and
the
new
ways
of
handling
asynchronous
code,
I
think,
are-
are
really
wonderful
and
they're
really
nice
to
have
when
you're
programming
in
javascript,
but
we've
done
everything
with
callbacks
in
ecma
419..
Why
is
that?
A
So,
let's
talk
about
guiding
principles.
Real
quick.
This
slide
has
language
from
the
extensible
web
manifesto,
but
it's
been
edited
so
that
it's
not
web
specific,
but
it
still
captures
the
intent.
We're
going
to
focus
on
adding
new
low-level
capabilities
that
are
secure
and
efficient.
In
order
to
allow
library,
authors
to
iterate
on
libraries
that
provide
developer
friendly,
high-level
apis
and
free
up
the
standards
process
to
focus
on
features
that
can
only
be
added
at
the
platform
level.
A
They
have
a
constructor,
pin
specifier
and
a
port
specifier.
All
of
them
do.
They
all
have
read
and
write
methods,
depending
on
whether
they're
input
or
output,
of
course,
and
they
all
have
a
format
property.
So
we
know
what
kind
of
data
they're
serving
up
to
us
and
then
they
all
have
three
callbacks
unreadable
on
writable
and
on-air.
A
That's
it
it's
that
simple,
so
a
very
consistent
interface
for
those
I
os.
We
also
have
providers
a
provider
is
a
collection
of
one
or
more.
I
o
classes.
It
represents.
Generally
speaking,
it
represents
a
device
that
is
connected
to
the
host
hardware
or
is
the
host
hardware,
but
it
could
be
connected
via
i2c
or
a
six
foot,
usb
cable
or
located
halfway
around
the
world
and
you're
talking
to
it
over
the
web,
but
ekma
419
or
the
program
that
the
user
writes
does
not
care
the
differences
in
the
providers.
A
So
peripheral
classes,
those
are
for
accessing
the
different
kinds
of
hardware
that
we're
going
to
talk
to
going
back.
Johnny
5
is
a
collection
of
peripheral
classes
right.
We
just
wrote
those
on
top
of
fermata
io
ion
node
serial
port,
so
ecma419
also
has
a
collection
of
peripheral
classes
to
to
guide
other
developers
who
are
developing
new
peripheral
classes.
Those
are
peripheral
classes
in
general.
I
think,
are
not
going
to
come
from
one
place:
they're
not
going
to
come
from
419
they're,
going
to
come
from
open
source
developers
who
are
following
the
standard.
A
So
sensor
classes
are
a
subset
of
peripheral
classes,
they're.
All
things
that
we
use
to
gather
input
from
the
real
world
around
us
thermometers,
gyroscopes
whatever
and,
of
course,
display
classes,
which
are
one
of
the
things
that
set
javascript
apart
and
its
ability
to
create
those
beautiful
user
interfaces
on
a
microcontroller
on
a
small
device
with
a
small
touch
screen
or
a
small
display
screen.
A
A
A
A
So
I
got
everything
I
needed
in
419,
but
I
didn't
get
some
of
the
stuff
I
wanted.
I
mentioned.
I
was
frustrated
like
where's
events,
where's
async
stuff.
Why
aren't
we
doing
this?
We're
we've
got
everything
with
callbacks,
but
I
remembered
this
part
of
that
extensible
modified
extensible
web
manifesto,
where
we're
going
to
allow
library,
authors
to
iterate
on
libraries
to
provide
developer
friendly,
high-level
apis.
A
A
We
were
able
to
get
poor
classes
straight
from
john
e5,
but
we
were
able
to
strip
out
a
lot
of
code.
So
in
the
case
of
led,
we
don't
care
if
the
pins
are
built
in
or
located
halfway
around
the
world
or
attached
to
your
computer
with
a
usb
cable.
As
long
as
we
have
a
provider
that
follows
ecma-419,
it
will
just
work.
A
A
We
can
just
do
this.
We
can
import
the
class
from
j5e
instantiate
an
led
and
tell
it
to
blink
we're
using
subpath
exports
with
either
a
manifest
file
or
package.json,
depending
on
the
platform
to
get
just
the
parts
that
we
need.
So
it's
very
small.
There
are
no
dependencies
to
j5e.
It's
it's
self-contained!
So
there's
you
don't
have
to
worry
about
bloat
or
importing
a
bunch
of
different
modules
because
again
we're
targeting
tiny
little
devices.
We
want
to
keep
things
as
small
as
possible.
A
We
are
using
top
level
await
here
when
we
are
instantiating
our
led.
We
can
get
away
with
that,
because
we're
using
an
asynchronous
immediately
invoked
function.
Expression
on
the
constructor
that
returns
it's
possible
to
not
do
that.
You
can
wrap
this
in
in
an
async
function
and
actually
get
a
little
better
performance
out
of
your
program.
But
if
you're
teaching
someone
javascript,
this
is
a
really
nice
way
to
do
it,
because
there's
a
minimal
amount
of
computer
vomit
so
really
great
way
to
teach
people
to
program.
A
This
is
it
in
action.
I
didn't
bring
hardware.
I
actually
have
hardware
with
me
if
anyone
wants
to
stop
me
and
check
out
some
demos,
but
the
program
is
installed
on
the
microcontroller
right.
You
don't
need
that
host
computer
anymore.
All
I'm
doing
here
is
applying
power.
It
just
fires
up
and
starts
running,
and
that's
a
really
good
feeling-
and
it
occurs
to
me
now
that
it
also
makes
hardware
demos
a
lot
less
intimidating.
A
So
we've
got
in
j5e
already.
A
group
of
classes
that
are
available
to
use
led
is
the
perfect
prototypical
one
because
it
uses
digital
pins
and
pwm
output.
Servo
uses
a
special
flavor
of
pwm.
We've
got
that
working
switch
and
button
use
digital
input.
So
we're
kind
of
testing
all
these
different
io
classes
with
j5e,
animation
and
easing
are
fun
because
they're
kind
of
computationally
expensive.
A
We
have
all
the
same
kind
of
easing
functions
that
you
might
find
in
something
like
jquery
ui.
When
you
were
animating
things
across
the
screen.
We
have
a
generic
sensor
which
uses
analog
input,
basically
anything
that
attaches
to
an
analog
to
digital
converter.
You
can
use
with
johnny
five
with
j5e,
so
flex,
sensors,
photoresistors
thermometers,
all
that
kind
of
stuff
is
really
nice
and
we
have
gps
class
in
there
that
uses
serial
to
communicate
both
ways
with
the
device
and
coming
around
the
corner.
A
We
have
a
i2c
based
device,
an
expander
that
allows
us
to
control
multiple
pwm
pins.
So
I'm
pretty
excited
about
that.
If
you
want
to
check
it
out,
you
can
at
j5e.dev.
All
you
need
is
an
esp8266
which
is
a
few
bucks
at
aliexpress
or
an
esp32.
If
you
want
more
room
to
play.
Also
moddable
has
some
really
beautiful.
A
A
A
B
A
Actually
not
that
much.
I
spent
a
lot
of
time
building
a
hexapod
that
ran
using
javascript
several
years
ago.
That
would
be
the
thing
that
I
would
point
to
and
say
you
know,
wow
look
what
I
made,
but
a
lot
of
little
things
just
basically
to
test
things
out.
I
got
to
be
honest.
I
get
more
excited
about
making
things
and
seeing
other
people
build
upon
those
things.
That's
a
really
cool
feeling
to
walk
into
a
room
and
see
people
running
code
that
you,
you
know,
that's
built
on
top
of
something
you
made.
A
So
I
spend
more
time
doing
that
than
actually
building
my
own
things.
That
said,
we've
done
a
few.
We
did
a
telepresence
robot
at
a
robotics
club
there
in
houston
that
ran
on
johnny
five.
It
was
six
feet
tall
with
a
ipad
and
you
could
walk
around
the
room.
It
was
awful,
it
looked
horrible,
but
it
worked
really
well.
It
was
a
lot
of
fun.
A
A
A
So
I
think
you
know.
If
we
standardize
on
that
comma
419,
then
it
gives
us
a
lot
of
options
and
the
ability
to
build
a
community
around
a
standard
instead
of
right
now.
You
know
when
you
look
at
microcontrollers
and
hardware,
especially
going
back
a
year
or
two
or
more,
it's
the
wild
west.
It's
where
browsers
were
20
years
ago,
where
everyone's
kind
of
doing
their
own
thing.
So
that's
why
I
comma
419
is
really
important
for
the
future
of
javascript
on
hardware
because
it
brings
everyone
and
rowing
in
the
same
direction.
A
A
A
So
so
what
I
did
for
j5e
j5e
runs
in
node
as
well,
there's
just
no
419
conformant
ios
that
I
can
talk
to
yet
or
providers
that
I
can
talk
to
yet.
But
I'm
doing
all
my
testing
in
node
that
has
burnt
me
on
one
occasion
just
where
the
javascript
parser
is
different
or
the
javascript
engine
is
a
little
different
for
for
resource
constraint
reasons.
A
A
A
A
It's
called
excess
bug.
So
a
debug
console
that
that
shows
you.
The
errors
returned
from
the
microcontroller
as
long
as
you're
running
in
debug
mode
and
that's
really
slick
and
that's
makes
it
makes
it
easy
to
solve
those
kinds
of
problems,
whereas
on
the
arduino
you
know
it
fires
off
into
space
and
you're.
Like
what
happened.
I
don't
know
what
happened.
So
it's
really
nice
all
right
cool.
Well,
I
guess
I
guess
we
went
a
little
over,
but
thank
you
all
for
the
questions.