►
From YouTube: Reinventing Dojo as a Progressive, Modern TypeScript Framework - Dylan Schiemann, Open Web Conf
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Hello,
welcome
back
to
open
J's
world
hope
you
enjoying
the
event,
it's
kind
of
nice
being
at
a
conference
where
you'd
get
to
sit
at
home
and
just
attend
the
talks
you
want
without
having
to
switch
between
rounds
or
stand
in
lines
or
wait.
I
mean
I'm
kind
of
missing
out
on
the
the
talking
part,
but
at
least
there's
that
fun
of
or
that
comfort
of
just
being
at
home
being
able
to
enjoy
these
talks
at
your
leisure,
which
is
really
nice.
So
this
talk
is
about
the
dojo
community.
A
We'll
talk
plenty
about
features
and
whatnot,
but
in
the
context
of
how
we
reinvented
from
sort
of
a
toolkit
that
solved
the
problems
of
the
pre
es6
web,
the
IE
8
days
and
so
on,
to
the
modern
web
and
what
changed
and
how
we
changed
and
what
that
was
like,
because
a
lot
of
times
toolkits
or
libraries
or
frameworks
they're
created
and
they
die,
and
it's
really
difficult
to
sort
of
reinvent
and
restart
and
sort
of
what
decision
led
us
to
go
down
that
path?
And
why
and
what
that's
been
like.
A
So
again,
my
name
is
Dylan
I
Dylan's
on
github
and
on
Twitter
I'm
also
involved
the
half
stack
series
of
conferences
which
is
in
a
creative
celebration
of
JavaScript
we've
pivoted
to
online
recently,
but
normally
were
in
seven
cities
throughout
the
world
and
I'm
working
with
JavaScript
for
its
24
years.
So
I've
seen
quite
a
bit.
A
It's
probably
aged
me
quite
a
bit
as
well.
So
when
dodo
got
its
start,
it
was
kind
of
a
tiny
thing
like
dojo
became
fairly
popular
early
on
not
by
today's
standards
but
by
standards
back
then,
because
at
the
time
no
one
really
treated
the
browser
or
the
web
as
a
serious
application
development
platform.
A
At
the
same
time,
we
were
working
on
the
early
versions
of
dojo,
which
was
an
attempt
to
end
this
sort
of
challenges
of
building
applications
in
a
browser
with
JavaScript,
with
the
things
were
missing
in
the
language
to
make
it
viable
and
useful.
We
didn't
have
the
concept
of
UI
components,
which
of
course,
everyone
talks
about
UI
components
today,
and
there
were
really
no
concepts
around
how
to
architect
or
build
a
web
application.
A
These
were
goals
of
dojo
in
2004,
I,
wouldn't
say
we
necessarily
solved
all
of
them,
but
we
came
up
with
answers
for
a
lot
of
them
from
modules
to
asynchronous
programming
patterns,
to
a
component
system
which
I
think
in
many
ways
inspired
effort
on
web
components
and
so
on
so
keep
in
mind.
2004
there
was
no
Chrome,
there
was
no
query,
selector
all
Firebug
I
think
had
just
come
out
and
it
was
okay.
There
was
no
github,
no
iPhone,
no,
no
DJ
s.
A
So
there
was
basically
a
time
when
really
there
wasn't
much
fairly
shortly
in
parallel
of
dojo
or
shortly
thereafter
emerged,
Yui,
prototype,
jQuery,
mootools
cent
and
there
were
a
few
commercial
clients
and
there
were
some
others,
but
that
was
kind
of
the
the
landscape
we
were
in.
So
that's
why
the
way
you
created
an
ecosystem
is
you
did
everything
yeah?
You
could
maybe
share
some
efforts
on
like
a
build
tool
systems.
A
So
we
leveraged,
we
wrote
a
build
tool,
but
we
also
later
leveraged
the
closure
compiler
from
the
Google
team,
or
there
were
no
modules,
so
you
write
your
own
module
standard
and
then
so
on.
It's
also
like
everything
was
bespoke
custom
and,
if
you're
lucky
maybe
collaborated
with
another
toolkit
a
framework
and
came
up
with
a
similar
pattern
or
idea,
the
standards
process
was
not
healthy
or
productive.
This
is
the
time
they're
talking
about
es4,
which
ended
up
just
falling
off
a
cliff
and
being
a
dark
mistake
in
many
ways.
A
So
it
was
an
interesting
time
to
try
and
build
software,
but
what
dojo
did
and
what
other
communities
did
you
manage
to
bring
a
lot
of
smart
people
together
that
wanted
to
solve
this
problem,
and
we
came
up
with
a
collection
of
over
1400
modules
that
solved
pretty
much
everything
we
could
imagine
needing
to
do
in
a
browser
or
in
JavaScript
at
that
time,
so
dojo
continued
to
mature.
We
went
through
a
point
1.2.3.4
release.
A
So
what
we
did
is
we
worked
with
the
community
to
create
the
AMD
standard
or
de-facto
standard,
which
was
a
module
definition,
format
that
was
asynchronous
and
you
could
use
it
with
jQuery
or
dojo
or
other
projects
that
opted
in,
and
that
was
a
huge
advancement
forward
and
it
also
resulted
in
much
smaller
applications
and
whatnot,
and
so
it
did
help,
but
we
still
sort
of
lacked
the
choices
we
have
today.
In
that
modules
that
didn't
really
necessarily
coexist
in
different
frameworks,
because
and
JavaScript
itself
doesn't
really
have
the
concept
of
an
interface
definition
right.
A
A
At
the
time
we
were
stuck
supporting
ie8
users
in
some
cases,
even
IU
1796,
and
that
meant
a
pretty
severe
limit
on
what
we
could
do
to
clean
things
up,
because
most
of
our
craft
was
the
result
of
supporting
legacy
browser
users
and
it
wouldn't
be
until
about
2000,
16
or
17.
Even
that
enterprises
were
finally
like.
Ok,
I,
don't
care
about
ie
8
anymore,
maybe
I,
don't
even
care
about
9
or
10
and
then
suddenly
were
like
wow.
This
is
liberating.
We
don't
have
to
worry
about
this
stuff
anymore.
A
When
we
started
to
think
about
what
sudo
would
be,
we
said.
Well,
we
could
just
remove
all
the
craft
and
keep
it
API
compatible
and
have
a
1
dot,
X
and
a
2
dot
X.
Then
the
feeling
was
that
wasn't
going
to
be
enough.
People
would
look
at
that
and
be
like
Matt
I,
don't
really
care,
it's
not
really
something
at
what
he
use
and
we
also.
A
Then
we
thought
well,
we
could
do
a
pretty
major
rewrite,
but
then
we
saw
what
the
Yui
team
had
gone
through
from
2
to
3,
where
they
did
a
rewrite,
but
they
didn't
get
any
of
their
components,
ready
for
the
3.0
release,
and
so
it
was
pretty
much.
It
I
think
it's
what
eventually
killed
off
that
project.
Is
that
no
one
upgraded,
because
the
feature
set
didn't
match
the
capabilities,
so
we
sort
of
started
to
just
experiment
and
experiment
for
many
years.
A
A
Other
than
that,
what
we've
decided
was
that
we
were
going
to
kind
of
wait
until
the
ie8
and
earlier
things
died
off,
and
then
we
could
start
to
sort
of
rewrite
and
rethink
what
we
were
doing
around
2012
typescript
came
out,
and
we
were
really
fascinated
by
that,
because
we
sort
of
felt
like
the
thing
that
was
missing
from
true
interoperability
and
JavaScript.
Libraries
was
the
interface
definition,
language,
the
height
the
interfaces
right,
and
so
it
basically
worked
on
typescript.
A
So
we
sort
of
pivoted
to
rewrite
on
top
of
es6
and
typescript,
and
then
we
rewrote
again
and
again
and
again,
every
typescript
release
we're
kind
of
constantly
feverishly
updating
to
get
something
that
would
work
the
way
we
wanted
it
to
work
and
that's
a
bit
challenging,
because
what
we
found
is
like
before
typescript
2.2.
We
couldn't
really
do
composition.
A
The
way
we
want
it
like
mix-ins
and
and
other
patterns
weren't
really
viable,
and
then
we
sort
of
switched
to
a
class-based
architecture
that
worked,
but
it
didn't
quite
feel
as
natural
as
using
a
functional
based
system.
So
again,
type
scripts
continue
to
evolve
and
made
it
possible.
The
main
thing
we
said
is
we
made
people
wait
so
long
for
this
rewrite
we're
not
going
to
give
them
a
horrible
2.0
release.
A
We
not
that
angular
did
that,
but
we
felt
like
angular
2
was
an
early
beta
at
best,
even
though
it
was
their
sixth
or
seventh
beta
before
they
released.
It
still
felt
like
that,
so
many
things
that
weren't
quite
right
or
I'm
finished.
We
don't
want
to
do
that
to
our
users.
So
what
we
said
is
we're
gonna,
keep
working
on
this
and
working
on
this
working
on
us
until
it
feels
right
enough
that
we
would
use
it
ourselves,
and
so
that's
what
led
to
taking
many
years
to
get
there
today.
A
We
also
said
if
we
just
port,
what's
in
an
old
dojo,
that's
not
really
going
to
be
very
interesting
to
people,
because
most
of
the
things
that
the
early
dojo
did
we're
now
part
of
the
JavaScript
language
or
the
ecosystem,
not
all
of
the
a
lot
of
them
went
promises
and
modules
and
other
patterns.
So
instead
we
said,
if
we're
gonna
build
a
framework
today.
A
What
are
the
pain
points
and
for
us
some
of
the
pain
points
where
things
like
it's
really
difficult
to
build
a
modern
application,
the
right
way
and
maybe
not
the
right
way,
a
right
way.
So
what
we
did
is
like
we
said
all
right:
let's
start
by
aligning
with
modern
standards
and
best
practices
right,
so
dojo
one
existed
in
a
vacuum
where
modern
standards
were
kind
of
poor
and
they
didn't
really
work
well
and
the
ecosystem
for
updating
and
releasing
standards-based
stuff
was
not
particularly
good,
but
today
that's
not
the
case.
A
So
how
could
we
align
with
that?
So
we've
looked
at
like
every
viable,
modern
standard
or
best
practice
and
used
it.
So
from
the
web
platform,
we've
got
PWA
s,
custom
elements,
intersection,
observers,
pointer
events,
modules,
fetch
and
so
on.
We
also
leverage
post
CSS
to
be
able
to
sort
of
say
we're
gonna
write
our
CSS
like
we
should
write
it
rather
than
using
something
like
a
preprocessor
like
sass
or
less
or
whatnot.
We
felt
that
one
of
the
things
that
people
love
about
dojo
is
it
is
cohesive.
A
So,
there's
just
a
lot
of
churn
and
a
lot
of
choice
and
what
we
wanted
to
do
was
kind
of
reduce
the
number
of
decisions
you
have
to
make
to
immediately
be
productive
and
then
allow
you
to
build
on
top
of
so
of
course,
we
started
with
es2015,
which
has
a
really
good
release.
Cadence
a
good
base
feature
set:
it's
not
perfect,
it's
not
complete.
It's
still
missing
interfaces
from
our
perspective,
that's
where
typescript
comes
into
play
and
type
safety.
A
Really,
as
a
framework
author
allows
you
to
know
that,
like
you've
defined
the
API
footprint
that
you
want
to
expose
to
users,
the
biggest
challenge
without
having
that
was
a
framework
author.
Is
people
use
things
in
unexpected
or
unintended
ways,
and
then
you
break
them
upon
what
should
be
minor
updates.
Typescript
also
gives
us
a
fairly
nice
IDE
support
because
of
the
type
definitions
it
gives
us
better,
intellisense
or
auto-completion
and
other
nice
things
there's
a
large
move
to
reactivity.
A
We
really
wanted
to
do
this
back
in
like
2004,
but
it
just
wasn't
possible
because
it
would
consume
all
the
memory
and
I
eat.
So
our
component
system
on
the
surface
feels
a
lot
like
react.
There's
a
lot
of
subtle
differences
in
nuances
that
we
feel
make
it
more
powerful
and
we're
flexible
in
some
ways
or
in
some
ways
it's
just
different.
A
We
have
functional,
aware
widgets,
we
have
our
functional
widgets
resource,
aware,
widgets,
reconnect
a
resource
to
that
and
then
there's
middleware,
just
the
concept
of
kind
of
the
software
that
lives
between
a
thing
and
the
reactive
component.
So,
for
example,
if
you
want
to
make
a
widget
follow
the
intersection
observer
API,
normally
you
would
have
to
start
say
alright.
This
is
the
time
I
plant
from
the
V
DOM
and
I
go
and
I
do
my
dog
magic.
A
We
have
a
lot
of
functionality
for
applications,
but
it
kind
of
starts
in
this
framework
package,
which
includes
the
framework
system
for
the
components,
routing
state
management
through
stores,
internationalization,
shims
and
testing,
and
to
us
these
are
kind
of
the
building
blocks
for
building
a
modern
application,
and
that
makes
to
us-
and
we
really
were
originally-
these
started
out
as
a
separate
packages,
because
when
we
started
moderate
dojo,
the
trend
was
micro
packages
for
everything.
People
might
just
want
to
use
your
routing
library.
A
They
do
I
just
want
to
use
your
stores,
but
it
turns
out
you
can
still
do
that
with
mono
repo.
So
if
you
want
to-
and
now
with
you
know,
sort
of
modern
es6
modules
and
whatnot,
you
can
just
load
the
pieces
of
the
dependencies
you
need,
even
if
they
come
from
a
fairly
large
package.
Yeah,
though,
to
be
fair,
this
package
is
still
quite
small
much
smaller
than
anything.
We
did
integer
1.
We
have
a
nice
CLI
tool
and
we
do
a
lot
of
interesting
things.
A
So
we
provide
PWA
is
out
of
the
box
by
default
with
just
a
slight
bit
of
configuration,
we're
evergreen
by
default,
meaning
we
only
pull
in
the
dependencies
that
you
need.
So,
if
you're
targeting
modern
browsers,
only
your
build
or
your
bundles
won't
include
any
shoes
or
polyfills
of
that
nature.
We
follow
the
purple
pattern.
We
have
this
build
time,
rendering
framework
that
allows
you
to
create
static
sites
by
working
on
a
component
level,
so
you
can
like
sort
of
import,
a
dojo
block
which
is
a
node
module.
A
So
say
you
want
to
provide
markdown
content
a
component.
You
can
do
that
on
a
component
level
rather
than
say
something
like
gatsby,
where
you're
kind
of
working
with
a
graph
QL
system
on
an
application
level.
We
find
doing
this
on
the
component
level
makes
it
possible
to
create
applications
that
are
components
that
are
more
flexible
and
reusable.
A
There's
a
huge
focus
on
performance,
pretty
much
a
dojo
application
out
of
the
box
gets
hundred
out
100
on
lighthouse
and
so
on.
A
lot
of
that
is
we
do
smart
things
by
default.
We
code
split
by
default,
based
on
your
routing
or
your
configuration.
The
default
bundle
is
quite
small,
we're
very
focused
on
this.
It's
really
easy
to
create
a
static
site
if
you
want
that
has
near
or
no
JavaScript
at
all
on
the
runtime.
A
So
this
path
to
modern
dojo,
you
know
dota
1
still
exists,
we
still
ship
it
and
the
reason
for
that
is
that
people
still
use
it
right.
In
fact,
I
think
they're,
probably
still
more
dota
1
users
out
there
than
dota
modern
touch
about
users
out
there
simply
because
so
much
was
built
with
doja
one
of
the
enterprise.
Our
goal,
though,
is
to
just
really
create
a
nice
modern
framework
that
exists
in
the
ecosystem
gives
us
what
we
need
helps
us
be
more
productive,
takes
away
some
of
the
decisions.
A
One
person
on
our
team
described
it
as
you
shouldn't
need
a
PhD
in
JavaScript
and
all
dependencies
to
be
productive.
You
should
be
able
to
just
sit
down.
You
know
some
JavaScript,
you
know
sometimes
script,
you
can
build
an
application
and,
as
you
want
to
get
more
sophisticated,
you
can
dig
deeper
and
figure
things
out.
So
this
wasn't
built
in
a
day
or
even
a
year,
is
built
in
about
eight
years
but,
like
I,
said
circle,
a
lot
of
experiments
and
we
had
a
lot
of
churn
Mir
blenders,
throw
things
out.
A
We
wrote
like
a
an
entire
shim
for
streams
and
we
ended
up
never
using
it
at
all.
We
wrote
an
entire
system
for
composability
that
ended
up
not
being
needed
because
typescript
improved
and
so
on.
We
really
don't
want
to
break
people.
One
thing
we
did
into
one
is
we
just
kept
adding
to
it
and
we
pretty
much
be
running
application
dojo
one
in
2007.
It
should
be
upgradeable
with
minimal
effort
and
still
work
today.
A
So
that's
a
primary
goal
for
modern
dojo,
but
we
want
to
be
able
to
introduce
API
changes,
so
our
framework
doesn't
blow.
In
fact,
most
of
our
releases
have
gotten
progressively
smaller
in
terms
of
the
framework
size,
and
so
we've
relied
on
code
mods
and
an
upgrade
migration
script
to
help
users
migrate,
mostly
automatically
with
that
some
warnings
for
things
that
we
couldn't
do
automatically
for
someone,
and
this
allows
our
sort
of
large
enterprise
users.
A
So
we've
made
a
lot
of
progress
over
the
years
we
released
dojo
2
in
2018
and
again
that
took
a
lot
of
years
to
get
there,
but
we
started
out
with
this
modern
framework,
which
is
simple
web
components,
routing
state
management
through
digit
stores,
a
CLI
and
a
test
harness,
and
then
we
started
iterating
from
there
as
we
were
using.
They
were
like
this
is
kind
of
tedious,
so
this
has
a
lot
of
boilerplate,
or
this
doesn't
quite
work
for
this
use
case,
or
you
know,
and
so
I
just
kept
fixing
things.
A
Dojo
3
was
a
pretty
small
released
couple
months
later
and
what
we
did
is
we
combined
the
framework
II
stuff
into
a
reef
mono
repo,
so
we
combined
six
or
seven
packages
into
one
that
made
our
release
and
build
process
a
lot
simpler
for
managing,
because
managing
a
bunch
of
packages
separately
would
mean
it
would
take
a
day
for
someone
to
do
the
full
release
cycle,
which
is
just
not
worth
the
effort
typo,
and
then
we
had
a
lot
of
tooling
for
her.
The
CLI,
then
in
2008
later
in
2018,
dota
4
came
out.
A
That's
when
we
introduced
automatic
code
splitting
the
purple
pattern,
just
better
performance
out
of
the
box
outlets
were
sort
of
a
way
to
work
with
resources
that
are
based
on
routing,
and
then
we
introduced
the
first
grid
component
in
the
dojo
widget
system
version.
5
came
out
a
few
months
later.
That's
we
introduced
conditional
polyfills,
which
loves
to
get
really
small.
Evergreen
builds
modern
api
polyfills,
build
time
rendering
the
blocks
came
out
then
had
slightly
improved
assertion
template
system
for
testing.
A
It's
actually
fairly
challenging
to
test
reactive
architectures
in
an
efficient
way
without
having
to
really
know
about
the
internals
of
the
dogs.
We
want
to
provide
an
assertion
template
system
that
allowed
you
to
just
assert
against
the
expected
value
of
reactive
system
and
then
a
lot
of
improvements,
middle
layer
of
stores,
and
then
we
started
to
get
a
little
slower
in
our
releases.
A
It's
also
the
first
time
we
had
zero
configuration
custom
elements,
a
build
system
for
creating
widget
libraries
to
create
your
own
component
system
or
whatever,
and
then
just
a
much
more
streamlined
approach
to
our
documentation
process
and
our
website.
Oh
and
for
the
first
time
the
dojo
dot
IO
website
was
built
with
dojos,
build
time,
rendering
and
dojo
blocks,
creating
a
really
fast
static
website.
A
At
digital
I/o
version
7,
which
came
out
the
start
of
this
month,
we
introduced
type
2,
widget
children,
some
more
improvements
to
our
function,
based
components
we
added
slots
and
other
economic
support
for
custom
elements.
We
added
dojo
resources
which,
like
resource
to
wear,
widgets
a
better
test
renderer
we
simplified
routing
and
outlets.
A
We
added
a
concept
called
parade
which
is
a
documentation
system
and
like
just
so,
it's
sort
of
like
this
start
towards
a
style
guide,
but
basically
it
gives
you
documentation
and
running
examples
for
all
the
components
you
create
and
we
use
it
ourselves
to
show
off
our
widgets.
And
then
we
introduced
material,
themed
widgets
in
our
framework
as
well.
A
So
we've
made
a
lot
of
progress
over
the
past
couple
years
and
a
lot
of
us
were
not
afraid
to
say
that
wasn't
good
enough,
let's
fix
it
and
come
up,
but
we
need
to
come
up
with
a
way
to
migrate
people
from
old
to
new.
It's
never
perfect.
There's
always
a
scenario
where,
like
you
decide,
we
really
don't
think
this
widget
was
very
good.
We
replace
it
with
another
one,
and
someone
says
I
really
was
using
that
widget
and
then
you
sort
of
have
to
come
up
with
a
solution.
A
Luckily,
for
us,
it's
still
pretty
easy
to
say,
you
know
what
there
was
something
in
dota
6
that
it's
gotten
deprecated,
you
can
use
it
in
DotA
7
by
M.
It
still
kind
of
just
works.
It's
just.
We
don't
want
to
maintain
that
anymore,
because
we
don't
think
it
was
the
right
path
to
go
down
coming
up.
Next,
we
have
a
lot
of
goals,
but
some
of
the
short-term
goals
are
application
level
widgets,
which
is
kind
of
like
a
mega
widget
for
your
entire
application.
A
So
dojo
relies
on
a
lot
of
support
from
the
community.
We
build
things
based
on
what
people
ask
for
so
we
are
part
of
the
open,
gist
foundation.
We
actually.
Our
lineage
is
the
first
project
that
was
part
of
the
foundation.
If
you
go
back
a
few
foundations
where
foundations
kind
of
got
combined
and
to
create
a
bigger
Center
for
the
JavaScript
ecosystem,
the
website
has
a
lot
of
information
and
then
Seiken
provides
support
for
building
dojo
and
then
the
site.
A
Penta
team
also
spends
a
lot
of
time,
helping
people
on
the
discord
chat
as
well.
So
you
can
go
to
the
dojo
website.
You
can
check
out
the
community
resources.
We
have
an
examples,
repo
on
github.
We
have
a
code,
sandbox
template,
that's
quite
easy
to
use.
We
have
the
temp
of
the
widget
system,
the
widgets
dojo
tile,
which
is
the
parade
system
that
showcases
everything.
A
So
I
guess
you
know.
Through
this
process
we
did
lose
some
community
members,
but
a
lot
of
that
was
just.
We
took
a
long
time
to
get
modern,
dinger
right
and
we
wanted
to
do
something
that
would
not
impact
our
old
users
and
when
new
users
came
along
to
use
it,
it
would
be
pleasant
to
use
and
that
it
would
be
something
that
we
felt
was
built
to
last
so
dojos
window.
Just
main
tenants
is
longevity.
We
don't
want
people
to
feel
like
they're,
rewriting
everything
from
scratch
every
year
as
a
frame
changes
drastically.
A
A
The
first
came
out,
you
know
nearly
15
years
ago
and
then,
but
our
focus
primarily
is
on
LAN
or
dojo,
and
listening
to
our
users
and
working
with
them
and
rebuilding
this
community
and
I
say
rebuilding,
because
a
lot
of
people
have
switched
to
react
or
to
view
or
to
angular
and
that's
okay.
Those
are
great
frameworks.
What
we
think
that
we
have
that's
special
to
offer
is
this
sort
of
sweet
spot
in
the
middle
of
frameworks
and
that
it's
complete,
but
it's
super
lean
its
type
script
based,
but
it
doesn't
feel
heavy.
A
It's
got
a
lot
of
things,
but
it
doesn't
do
too
much
it's
approachable
and
easy
to
use
in
terms
of
complexity,
but
it
might
not
be
as
simple
as
just
an
HTML
framework
that
upgrades
itself
with
some
JavaScript.
So
we've
really
tried
to
find
that
midpoint.
Where
you
can
create
something
simple,
you
can
create
a
static
site.
You
can
create
a
small
application,
but
we
feel
we
have
all
the
building
blocks
and
features
in
place
to
be
able
to
scale
up
to
build
some
of
the
world's
largest
applications
efficiently.
So,
thank
you.
A
Please
check
out
dojo.
Let
me
know
if
we
have
any
questions,
feedback,
criticism
whatever
and
thank
you
for
the
time.
Let's
learn
more
about
dojo,
be
sure
to
check
out
our
workshop
tomorrow.
You're
watching
this
live
it's
tomorrow,
it's
going
to
be
a
90
minute
introduction.
You
can
get
started
with
dojo
and
be
productive
and
build
your
first
application.
Thank
you.