►
From YouTube: OpenJS Foundation AMA- Dojo
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
Okay
looks
like
we
are
live
for
the
openjs
foundation's
monthly
ama,
where
we
chat
with
projects
and
community
folks
about
the
cool
things
that
they
are
working
on
this
month.
We
are
super
excited
to
bring
on
the
dojo
project
and,
before
I
hand
it
over
to
dylan,
who
will
be
our
moderator
for
today,
for
those
tuning
in
please
feel
free
to
either
drop
your
questions
into
the
youtube
chat,
or
you
can
also
at
us
or
yeah
direct
director
questions
to
us
on
twitter
at
openjsf.
B
Hello
thanks
for
joining
us,
I'm
dylan,
I'm
one
of
the
co-founders
of
dojo,
for
I've
been
working
with
dojo
for
the
past.
B
Well,
like
16
years
now,
and
we
have
an
aunt
here-
aunt,
googler
and
wave
yeah
aunt
is
a
co-creator
like
co-maintainer
of
modern
dojo,
co-architect
of
it
with
matt,
I'm
god
and
ant
is
a
software
engineer
at
sitepad
and
lives
in
the
uk
and
I'm
the
ceo
at
livingstock
and
I
live
in
arizona
though
it
looks
like
I'm
hanging
out
in
the
northern
lights
area,
which
is
really
pleasant
and
nice
and
cool
so
yeah
thanks
for
joining
us.
Let's
kick
things
off.
B
I
think
we'll
start
just
giving
a
brief
glimpse
of
dojo
and
where
we
are
today
and
and
how
we
got
here
so
dojo
actually
started
in
2004,
which
is
many
lifetimes
ago
in
terms
of
javascript
frameworks
and
toolkits
and
whatnot,
and
we
started
the
project
because
we
needed
it.
We
wanted
to
sort
of
fix,
browsers
and
fix
compatibility
issues
and
treat
javascript
as
sort
of
a
real
programming
environment.
At
the
time
it
really
was
not,
and
it
was
kind
of
started
at
a
very
good
time.
B
The
time
when
sort
of
google
maps
and
gmail
came
out
the
same
year
and
they
were
working
on
apps
that
were
later
coined
as
ajax
applications,
which
quickly
came
to
mean
like
anything
interesting
in
a
browser.
So
it
kind
of
like
super
consumed
all
javascript
applications
at
the
time,
and
there
was
a
lot
of
buzz
and
a
lot
of
interest,
but
it
was
super
early
and
browsers
were
broken
and
javascript
had
limits.
B
Dojo
co-founder,
alex
russell
had
a
project
called
netwindows,
and
one
of
the
questions
we
were
asked
was
why
the
name
dojo,
and
so
in
2004,
alex
received
a
cease
and
desist
order
from
microsoft
over
the
name
windows
in
the
project
netwindows
and
had
to
choose
a
new
name,
because
he
didn't
want
to
pay
the
cost
or
couldn't
afford
to
pay
the
cost
of
defending
a
lawsuit
against
microsoft
at
the
time,
and
I
don't
think
they
would
do
that
today.
They've
changed
a
lot.
Maybe
they
would.
B
I
don't
know,
but
it
made
us
realize
how
terrible
we
were
at
naming
things,
and
so
we
were
exchanging
a
lot
of
really
bad
names
and
one
of
the
names
funny
enough
was
actually
node
at
the
time.
That's
a
terrible
name.
No
one
would
want
to
call
their
project.
No.
That
sounds
like
a
cancerous
disease.
B
So
we
we
through
that
we
rejected
that
name
and
we
had
names
like
shiny
marbles
and
modular
and
just
random
stuff,
and
one
person
proposed
the
dhtml
justice
league,
which
tells
you
like
how
obscure
things
were
back
then,
like
dhtml
was
a
phrase
we
would
use
the
straight
face
at
the
time
and
leonard
lynn
said
how
about
dojo.
You
know
you're
all
like
sort
of
these
javascript
kung
fu,
like
experts,
ninjas
whatever
and
dojo,
has
like
d
and
j
for
like
dynamic
javascript.
B
So
what
about
that
everyone's
like
well,
that's
way
better
than
the
name
we
can
come
up
with,
and
so
that's
been
the
name
ever
since,
and
we've
thought
about
changing
the
name
as
dojo
has
changed
and
we're
just
not
very
good
at
names,
so
we're
good
about
once
every
20
years.
So
maybe
someday
we'll
come
up
with
another
name,
but
for
now
that's
sort
of
how
we
came
to
the
name
dojo
and
around
2004
is
when
we
first
started
the
project
2005's
when
we
shipped
our
0.1
2007
was
1.0
and
around
2010
or
11.
B
We
started
talking
about
dojo
too
and,
like
many
things,
sort
of
like
your,
I
don't
know
like
your
duke
nukem
forever
or
quake,
2
or
just
sequels
are
really
hard
right,
and
so
we
had
this
challenge
of.
We
were
providing
all
this
stuff
that
mattered
for
users
of
browsers,
that
included
like
ie638,
and
that's
very
different
than
sort
of
the
types
of
frameworks
we
used
today,
and
so
it
took
us
a
long
time
to
sort
of
wait
out
the
need
for
dojo
one
to
sort
of
slow
down
and
wane
and
die
off.
B
Though
usage
is
still
there,
so
it
hasn't
really
truly
died.
It's
just.
I
don't
think
anyone
would
choose
old
dojo
to
build
a
new
application,
and
so
we
started
thinking
about
what
modern
dojo
should
be,
because
we
didn't
want
to
just
like
sort
of
port.
This
massive
set
of
modules
and
into
modern
syntax
and
call
it
good.
We
wanted
to
really
rethink
and
say
what
do
people
need
from
a
framework
today
and
for
us
that
changed
and
evolved
and
it
took
us
probably,
when
did
we
ship
like
2018,
was.
B
Yes,
yes,
it
took
us
a
long
time
and
many
rewrites,
but
we
wanted
to
really
not
like
give
like
pain
to
our
users.
We
wanted
to
give
like
nice
ergonomics
and
use
modern
features
and
align
with
modern
standards
and
provide
sort
of
the
smallest
simplest,
most
flexible,
but
yet
comprehensive
for
building
an
application
framework.
B
We
could
give
people,
so
we
spent
a
lot
of
time
matt
and
that
in
particular,
but
the
whole
team
just
trying
to
put
together
a
framework
that
took
the
things
we
like
from
the
current
ecosystem,
whether
that's
sort
of
standards
or
things.
Other
frameworks
do
nicely
that
we
wanted
to
sort
of
look
at,
perhaps
improve.
We
really
love
typescript,
but
we
didn't
want
to
just
say:
hey.
We
wrote
it
in
typescript
here
you
go
because
if
you've
used
typescript
at
any
length,
you
sort
of
know
that
typescript
is
not
like
just
hey.
B
It
just
works
for
every
possible
complex
thing
you
can
describe,
but
it
actually
takes
effort
to
provide
a
framework
that
gives
nice
ergonomics
for
use
with
typescript,
and
so
we
we
took
our
time
and
we
tried
to
get
things
right
and
then
we've
been
iterating
ever
since
we're
already
up
to
dojo
version,
seven
and
we're
working
on
version.
Eight.
Now
so,
and
maybe
I
can
shut
up
a
little
bit
and
let
you
tell
us
a
bit
about
modern
dojo
and
what
you
love
about
it.
C
I
have
to
say
I
love
dojo,
I
guess
that's
it.
I
think
you
yeah
so
like
for
us.
It's
been
a
challenge.
Obviously
we
shipped
the
the
first
release
of
modern
dojo
ii
in
april
2018.
I
think
at
the
time
you
know,
typescript,
you
know
from
the
inception
of
wanting
to
use
those.
I
wanted
to
use
typescript
for
dopa.
C
The
next
version
of
dojo
to
actually
releasing
like
typescript
has
come
on,
so
you
know
leaps
and
bounds,
but
even
so
it
was
still
difficult
to
do
to
just
to
describe
certain
types
and
scenarios
in
typescript,
so
yeah,
like
2018
over
over
the
last
two
and
a
half
years.
C
You
know
we've
been
progressively
trying
to
change
things
that
and
make
make
our
framework
more
ergonomic
for
users,
so
they
to
level
up
lower
the
the
boundaries
for
people
who
are
coming
on
board
with
dojo
to
make
it
easier
for
them
to
understand
to
get
started
and
that's
kind
of
very
important
for
us,
especially
you
know
we
want
to
target
not
just
a
hobbyist,
but
we
want
you
know,
dojo
to
be
kind
of
the
batteries
included.
Opinionated
framework
that
comes
is
out.
C
The
box
and
works
for
kind
of
the
hobbyists
through
to
kind
of
the
enterprise
users
that
have
got
big
teams
and
are
building
like
complicated
applications.
Let's
say
in
the
browser-
and
I
think
over
the
last
two
years,
some
of
the
some
of
the
improvements
we've
made
in
the
ecosystem
of
dojo
and
that's
through
from
kind
of
the
base
apis
or
the
the
primitives
of
building
widgets
through
to
kind
of
the
the
routing
system
and
the
stores
and
some
of
the
concepts
we've
built.
C
On
top
of
that
which
do
which
are
looking
to
deal
with
kind
of
like
how
you
interact
with
kind
of
remote
resources.
You
know
like
async
requests
requesting
data
from
you,
know
a
server
and
and
dealing
with
that
in
a
nice
reactive
way
within
within
your
widgets.
It's
very
important
to
reduce
kind
of
again
the
boilerplate
involved
and
the
overhead
involved
of
of
knowledge,
of
understanding
of
how
to
put
these
things
together.
C
So
for
me,
dojo
we're
working
always
working
on
dojo
to
make
it
easier,
lower
the
bat
lower
lower
the
the
kind
of
the
knowledge
required
to
start
to
get
started,
and
I
think
that's
you
know,
with
dojo
8
we're
looking
to
kind
of
kick
on
with
one
of
our
concepts,
which
is
resources
which
gives
kind
of
the
power
to
a
user
to
to
have
that
asynchronous
kind
of
data
available
within
a
widget
and
globally
cached
it
across
your
whole
application
without
having
to
deal
with
kind
of
how
that
data
is
stored
and
and
how
to
manage
whether
or
not
it's
loading
and
all
the
different
states
that
you
get
with.
B
Yeah,
I
was
going
to
say,
I
think
you
know,
for
people
who
use
dojo
toolkit
before
modern
dojo
is
pretty
much
as
different
as
switching
to
react
or
angular
or
vue,
and
it's
a
completely
new
modern
framework
it.
But
it
does
share
some
lineage
in
history.
With
some
patterns,
like
obviously
dojo,
had
a
build
system.
We
have
a
build
system
that
we
leverage
webpack
under
the
covers,
but
we
try
not
to
expose
the
specifics
of
dependencies
to
most
users.
B
Modern
dojo
has
sort
of
the
the
old
style
has
feature
detection
system
in
a
modern
way
that
is
integrated
with
the
build
system
and
runtime,
behavior
and
so
forth,
and
dojo
also
has
some
really
nice
stuff
that
01
never
could
have
even
thought
of
doing
like
static
generation
or
what
we
call
build
time,
rendering
where
we
have
access
to
sort
of
node.js
modules
and
dependencies
at
build
time.
B
So
we
can
compile
static
sites
and
you
know,
use
sort
of
simple,
like
modern
apis
to
generate
really
powerful
stuff,
but
I
think
you
know
so
I
touched
so
much
things
there,
but
I
think
it's
kind
of
interesting
to
help.
B
I'm
like
dojo
is
like
reactive
with,
like
they
use
jsx
as
the
primary
mechanism
for
defining
components,
but
when
I
go
to
do
something
with
dojo,
there's
kind
of
typically
one
way
to
do
it,
there's
not
like
this
myriad
of
do
I
use
hooks.
Do
I
use
like
these
various
patterns
that
have
emerged
over
time?
Part
of
that
is
dojo
is
a
bit
newer,
but
also,
I
think,
dojo
has
said
like.
B
Let's
try
to
think
about
how
these
problems
fit
together
and
what's
the
right
ergonomic
way
to
do
them,
rather
than
kind
of
like
well,
there's
20
ways
to
figure
it
out
yourself,
which
is
certainly
something
you
could
do
but
like
do
you
find
that,
like
when
people
are
first
learning
about
modern
dojo
and
trying
to
use
it
the
questions
they're
asking,
do
you
feel
like
they're
struggling
with
the
like?
Which
way
do
I
do
things
or
like
what
are
the
kind
of
typical
like
new
user
questions
like
that,
come
up
with
dojo.
C
That's
a
good
question:
we've
got
a
discord
channel,
and
so
we
get
quite
a
lot
of
engagement
with
people
who
are
just
trying
out
dojo.
C
Normally,
you
know
just
for
your
hobby
projects
and-
and
it's
not,
I
think
where
you
know
where
we
want
to
consistently
improve
is
is-
is
to
to
complement
kind
of
the
the
framework
and
what
we
believe
is
you
know,
a
very
you
know
very
easy
way
to
to
build.
You
know.
Web
applications
is
is
to
keep
our
documentation
on
dojo,
io
kind
of
up
to
date
to
help
people
get
started
with
dojo,
and
I
think
you
know
we
did
a
massive
revamp
of
that
early
this
year.
I
think
it
coincided
with.
C
C
Was
six
so
it
was
like,
I
think
it
was
like
august
last
year.
It
feels.
C
And
that's
I
mean
that's
hugely
important
to
us
for
people
to
have
kind
of
that
point
of
reference
and
one
of
the
big
you
know
one
of
the
hardest
things
I
mean
I
find
personally
is
actually
writing
good
documentation.
So
most
of
the
feedback
we
get
or
most
of
the
questions
we
get
aren't
like.
Oh,
how
do
I
do
this
there's
just
so
many
ways?
C
It's
you
know
I
want
to
do
something
I
want
to
do
x
and,
and
how
can
I
do
this
dojo
has
an
opinionated
way
and
we
obviously
can
point
them
to
the
documentation,
but
sometimes
I
think
that's
where
the
failure
is.
Is
it's
not
quite
as
clear
as
it
could
be
for
people
to
get
started
without
having
to
ask
that
question
and
that's
where
really
that
kind
of
feedback?
And
whenever
we
receive
that
feedback
we
try
and
address
that
in
documentation,
so
that
next
time
you
know
someone
who
comes
along
finds
dojo
they.
B
A
lot
of
times
like
when
we
used
to
do
a
lot
of
dojo
workshops
back
in
the
day.
One
days
people
said,
like
the
main
benefit
of
training,
was
to
actually
learn
how
to
ask
good
questions,
because
they
needed
to
know
like
enough
of
the
vocabulary
to
know
like
how
to
ask
the
thing
they
were
trying
to
do
right
rather
than
you
know,
sometimes,
there's
just
so
many
terms,
you're
not
familiar
with
or
you
don't
know
about.
You
don't
know
where
to
start.
B
You
know,
I
think
so
another
interesting
historical
thing,
so
dojo
was
probably
the
one
of
the
first,
maybe
not
the
first,
but
one
of
the
first
frameworks
or
toolkits
that
had
the
idea
of
a
widget
library
or
a
component
system,
and
that
was
known
as
digit
back
in
the
day
and
some
of
the
early
members,
the
digit
team
went
on
to
work
on
the
custom
elements
or
web
components,
standards,
process
right
and
obviously
that's
grown
a
lot
and
changed
a
lot
since
then,
but
their
early
traces
and
hints
of
like
what
dojo
did
became
sort
of
what
custom
elements
did
with
a
lot
of
iteration
and
feedback
and
custom
elements
have
kind
of
had
a
pretty
slow
uptake
in
general
compared
to
some
other
things
on
the
web
and
part
of
it
was,
I
think
it
took
a
while
to
sort
of
get
the
ergonomics
of
that
right.
B
C
C
Was
how
important
are
custom
elements
to
dojo
and
for
me
I
think
I
mean
it's
been
clear
since,
since
we
have
since
even
the
the
initial
release
of
modern
dojo
customer
elements
has
been
a
a
really
important
part
of
the
dojo
story.
For
us
and,
like
dylan
said,
is
not.
It
was
never
just
about
being
able
to
use
custom
elements
within
kind
of
dojo,
because
you
know
some
frameworks,
you
even
struggle
with
with
that.
It's
also
about
actually
being
able
to
kind
of
generate
custom
elements
from
your
dojo
widgets.
C
So
if
you
build
a
widget
library
for
in
your
in
your
in
your
work
in
your
in
your
company-
or
you
know
just
you
know
for
funsies
on
the
side,
you
can
you
can
actually
you
we
want
that
to
be
able
to
be
used
by
anybody
in
any
framework
and
lower
that
lower
those
boundaries
between
the
frameworks
and
and
get
that
interrupt
working.
You
know
between
dojo
and
the
community
and
the
wider
just
the
web
in
general.
C
So
it's
been,
it's
been
clear
from
so
from
version
two
that
yeah
that's
been
super
important
to
us
and
I
think,
even
the
initial
release
we
had
you
know
a
way
of
generating
or
compiling
custom
elements
from
your
dojo
widgets
and
over
the
last
two
years.
It's
it's
been
something
that
we've
been
working
on
to
provide
like
even
more
powerful
options
with
and
support
with
dojo
custom
elements
to
support
scenarios
that
you
build
into
your
widgets.
C
So,
for
example,
widgets
they
accept
children
which
widgets
have
that
have
complicated
kind
of
property
types
that
get
passed
to
them
or
property
data
types
that
and
now
and
obviously
in
a
html
world
that
becomes
difficult
to
to
work
within
a
declarative
way.
C
You
find
yourself
having
to
kind
of
create
the
element
and
then
get
a
handle
to
the
element
in
some
javascript
and
then
set
some
properties
on
it
with
the
data
it
requires,
whereas
you
know,
ideally,
what
we
want
people
to
be
able
to
use
is
import
that
widget
as
a
script
into
into
into
their
html
and
then
use
their
and
then
use
their
their
widget
directly
without
having
to
do
any
javascript
and
over
the
last
two
years,
there's
been
some
significant
kind
of
improvements
in
in
our
support
for
the
for
the
output
that
we
actually
compile
from
widgets
and
that's
you
know,
we
support
the
concept
of
children
of
widget
children
and
we
support
the
concept
of
kind
of
the
complex
like
non-primitive
types
that
can
get
past.
C
You
know
if
you,
if
there's
a
widget,
that
requires
an
object.
You
can.
You
can
pass
in
a
stringified
version
of
that,
and
so
you
can
still
use
the
widget
in
a
declarative
manner
and
dojo
and
the
the
the
wrapper
that
dojo
provides
around
that
will
automatically
know
what
to
do
with
it
and
equally
on
the
on
the
building
side
of
things.
C
You
know:
we've
moved
on
from
having
to
have
kind
of
some
wrapping
configuration
to
you
just
to
describe
what
the
the
properties
and
what
the
customer
element
should
be
outpost
and
and
we've
kind
of
leveraged.
That
type.
C
You
know
the
type
system
from
typescript
to
determine
and
introspect
each
widget
and
be
able
to
generate
kind
of
the
custom
element
kind
of
wrapper
and
with
all
of
the
configuration
of
all
of
the
properties
and
attribute
types
based
upon
kind
of
the
those
interfaces
that
you
create
with
your
widget,
hopefully
making
it
kind
of
a
seamless
process
that
you
can
just
you
know
you
can
use
the
build
like
the
build
widget
tool
to
build
your
library,
for
you
know,
consumption
in
a
dojo
application
or
you
can.
C
You
can
use
it
to
kind
of
output,
a
full
library
in
kind
of
custom
elements.
B
Yeah
one
of
the
challenges
I
remember
like
early
in
the
day
there
was
this
concept
of
like
html
imports
with
web
components,
which
was
beneficial
in
that
like.
If
you
were
going
to
have
100
web
components
in
a
page
and
they
shared
a
framework,
you
could
sort
of
just
load
the
the
code.
That
was
a
dependency
for
the
framework
once
for
all
of
them.
But
then
that
was
deprecated
because
it
was
kind
of
duplicative
with
with
es
modules
right
and
the
challenge
for
us
for
a
while
was
well.
B
C
I
mean
that's
something
that
we
are
looking
to
kind
of
build
ourselves
with
the
support
with
that
dojo
provides
you're
right
and
what
you're
saying
at
the
moment
when
you,
if
you
can,
if
you
build
a
library
of
custom
elements
with
the
custom
element
widgets
from
dojo,
the
the
dojo,
is
effectively
packaged
in
in
every
single
one
of
those.
It's
it's
not
it's,
not
a
large
library.
I
mean
it's.
You
know
we
come
in.
C
You
know
kind
of
a
minimum
yeah
15
to
20
like
kilobytes,
but
it
is
certainly
something
as
you
as
you
put
in,
like
hundreds
of
different
custom
elements
in
your
page,
you're,
going
to
feel
the
pain
of
that,
and
I
think
we
wanted
to
address
this
for
deja
vu.
We
might
still
get
around
to
it,
but
a
concept
of
actually
being
able
to
not
just
so
at
the
moment
you
have
to
in
you
have
to
import
all
of
your
all
of
the
individual
output
widgets.
C
You
have
to
actually
load
the
scripts
themselves,
each
time
so
like
so
we're
looking
at
kind
of
leveraging
kind
of
some
of
the
build
tooling
that
we
use
to
generate
the
custom
elements
to
so
you
can
only.
You
only
need
to
include
like
a
script
once
and
then,
as
you
use
the
widgets,
it
will
lazily
load
kind
of
just
adjust
the
the
wrappers
required
for
that
widget.
C
So
the
core
of
the
framework
will
be
included
once
in
a
page
and
then
everything
else
will
just
lazily
get
loaded
in
as
as
as
required,
rather
than
having
to
kind
of
specify
all
the
scripts
and
all
the
css
within
within
that
single
page.
So
I
think
that
will
significantly
one
reduce
that
footprint
that
you
could
have
if
you
had
like
a
large
app
using
like
multiple
custom
elements,
but
it
will
also
kind
of
provide
you
with
kind
of
that
lazy
loading
and
the
ergonomics
of
not
having
to
kind
of
include.
B
C
B
And
I
mean
one
of
the
things:
I've
spent
a
fair
amount
of
time
using
react
as
well
and,
like
I
feel
like
every
time
I
import
someone
else's
component
they've
taken
a
different
approach
to
styling
that
component,
so
I'm
sort
of
managing
like
20.
Well,
it
came
out
with
20,
but
at
least
five
different
ways
of
potentially
styling
a
component,
some
of
it's
css
and
js,
some
of
it's
like
a
jsx
style
tech.
Some
of
it
components
use
themes,
some
of
it
other
mechanisms
as
well
and
dojo
has
some
pretty
interesting
features.
B
I
think
which
I'll,
let
you
explain
in
a
moment,
but
also
one
of
the
nice
things
I
think
with
dojo7.
Was
you
added
support
for
we
added
support
for
material
design,
components
as
well,
so.
A
C
Yeah
so
so,
like
with
dojo
we
early
early
on,
we
made
the
decision
to
kind
of
to
go
with
css
modules,
as
as
the
the
recommended
and
supported
way
of
building
yeah
and
styling
widgets.
It
provides
us
it
provided
with
all
the
protection
that
we
wanted
in
terms
of
encapsulating
your
styles
for
a
widget
making
sure
there
was
no
clashes
between
widgets.
C
So
you
didn't
inadvertently,
like
you
know,
effect,
you
know
widget
somewhere
else
in
your
application
by
making
a
change,
and
it
gave
us
that
kind
of
encapsulation
that
we
that
we
needed-
and
it
also
gave
us
some
really
nice,
because
with
using
typescript,
we
were
able
to
generate
you
know
the
typings
required
for
each
of
the
css
files.
So,
as
you
imported
your
css,
you
know,
and
you
used
your
css
like
class
names.
C
You
could
actually
do
that
via
the
import
of
the
css
module
and
it
gave
you
the
typings
of
all
the
class
names
you
needed,
so
it
kind
of
gave
us.
It
was
a.
It
was
a
win
for
kind
of
the
ergonomics
while
developing
to
ensure
that
you
didn't,
like
miss
typing
a
style,
but
it
also
gave
us
all
of
the
kind
of
the
behavior
that
we
needed
or
wanted
from
kind
of
a
a
component
or
a
widget
scoped
css
yeah.
C
So
that's
really
good
and,
as
dylan
said
is
you
know
with
obviously
there's
like
if,
but
if
someone
else
wanted
to
come
out,
go
away
and
and
and
do
their
own
kind
of
starts,
you
know
do
styling
in
their
own
way
with
dojo,
I
mean
that
would
be
more
than
possible,
but
obviously
the
recommended
way
and
the
built-in
support
we
have
with
all
our
build
tooling,
is
to
use
the
css
module
pattern
which
comes
out
the
box
with
dojo
and
with
dojo
widgets
that
you
know
in
dojo7
basically
had
a
huge
overhaul.
C
It
was
the
biggest
probably
the
biggest
thing
in
dojo7.
It
was
to
we
we
we
basically
took,
and
we
took
an
approach
where
we
needed
to
kind
of
not
start
again,
but
we
needed
to
kind
of
understand
and
get
all
like
get
patterns.
Kind
of
you
know
straightforward
and
aligned
across
the
across
the
whole
of
the
of
the
project,
because
it
kind
of
over
between
versions
two
and
six
it
it
evolved
organically.
C
You
know
with
the
different
contributors,
without
kind
of
necessarily
all
of
the
the
rails,
that
we
wanted
to
to
give
people
not
just
internally
for
ourselves
of
building
that
library,
but
also
equally
kind
of
the
example
we
wanted
to
set
for
people
who
wanted
to
build
widgets
with
dojo.
So
we
kind
of
reset
that,
and
as
part
of
that,
we
we
also
provided
that
that
material
theme
and
and
the
concept
of
the
variant.
So
you
know
you,
can
you
can
swap
the
theme
at
runtime.
C
C
B
C
What
a
key
aspect
of
building
dojo
is
to
make
sure
that,
even
though
we
do
provide
some
kind
of
nice
syntactic
sugar
over
the
top
for
people
who
don't
want
or
need
to
support,
ie
11,
we
do
at
the
moment
still
consider
ie11
in
everything
that
we
do
from
the
build
tooling
to
kind
of
the
theming
to
stores
to
the
you
know
the
the
base,
the
widget
watering,
everything
is,
is
kind
of
thought
of
and
and
made
sure
that
it's
kind
of
compatible
across
the
board.
B
Yeah
there
was
a
nice
change
where
we
went
from
providing
shims
by
default,
only
for
browsers
that
needed
them
and
basically,
what
we
did
is
made.
Ie11
users
pay
the
performance
penalty
of
supporting
modern
apis
like
intersection
observers
or
resizing
servers
or
even
web
components
themselves,
rather
than
bundling
that
to
everyone,
even
when
it
was.
C
Yeah,
it
kind
of
goes
it
kind
of
goes
even
further
than
that
at
the
moment,
and-
and
it
goes
so
when
we
first
when
modern
dojo
was
first
released
two
years
ago,
like
dylan
just
said,
is
we
included?
We
effectively
included
all
of
this
all
of
the
shims
in
as
the
default
and
our
modern
build
was
a
flag
that
people
had
to
know
about
and
and
request
when
they
built
their
application
and
so
and
that-
and
that
was
basically
what
you
know.
C
We
had
a
bunch
of
kind
of
like
flags
that
told
our
build
system.
You
know
how
what
to
kind
of
a
light
a
build
time,
because
it
wasn't,
it
wasn't
necessary,
it
wasn't
needed,
and
so
we,
the
first
thing
we
did.
Is
we
switched
that
round?
So
the
default
was,
you
know
for
the
modern
browser
and
if
you
wanted
to
have,
if
you
want
to
support
kind
of
ie
11
and
you
needed
all
of
these,
you
know
basically
shims
that
we
that
dojo
can
provide.
C
Then
you
have
to
use
a
flag
and
that
basically,
so
that
will
support
that's
you
know,
that's
supporting
the
modern
and
that's
kind
of
that.
We
we
kind
of
changed
to
like
our
approach
there,
to
make
it's
a
modern.
C
First,
we
want
to
be
as
modern
as
possible,
keeping
up
with
the
standards
and
and
then
obviously
there
will
be
people
who
need
to
have
that
kind
of
legacy,
support
and
that
you
know
use
and
then
subsequent
to
that
and
we
actually
started
kind
of
doing
loading
kind
of
some
of
the
political
shims
that
we
provide,
like
dylan,
mentioned,
intersection
observer,
resize
observer,
even
fetch
kind
of
at
runtime.
C
So
we
determined
that
at
runtime
we
built
them
into
separate
bundles
that
weren't
included
in
your
application
unless
you
needed
them
unless
the
user
needed
them
because
they
were
using.
You
know
resize
observer
when
it
wasn't.
But
I
don't
know
I
don't
know
what
it
is
now,
but
it
certainly
wasn't
in
so
the
old
edge.
C
So
if
you
had
an
application
that
was
using
our
you
know,
resize
observer
or
shim,
then
it
would
only
load
that
if
the
user
was
actually
using
edge
or
was
actually
using
a
browser
that
kind
of
required
it-
and
I
think
that's
kind
of
it's-
it's
similar
to
kind
of
that
differential
loading
pattern
which
we
haven't
quite
got
to
yet.
But
but
we
we
are
working
and
hoping
to
get
towards
that.
So
it's
even
more
seamless
for
our
users.
B
And
then
the
other
thing
that's
doing
this.
Nice
is
when
you're
in,
like
your
your
inspector
or
debugger
browser
devtools,
whatever
you
want
to
call
them
and
you're.
Looking
at
that
node.
What
you're
seeing
is
like
a
hash,
the
name
of
the
class
name
and
then
like
a
hash
after
it.
So
what
it's
doing
is
it's
protecting
it
from
and
keeping
it
unique,
but
it's
still
human
readable
in
the
middle.
A
C
Also
now,
but
yeah
also
the
cs,
the
obviously
the
the
source
maps
worked
as
well,
so
mainly
that
right,
because
in
like
when
you're
in
your
dev
tools,
you
could
click
on
your
your.
You
could
click
on
your
style
and
you
could
see
the
actual
like
the
your
source,
css,
which
is
obviously
super
important
for
you
know
those
developer
economics
which.
C
B
Biggest
app
you've
seen
built
with
modern
dojo,
because
I
mean
I've
seen,
I
think
I've
seen
some
stuff,
that's
pretty
cool
but
like
in
terms
of
like
breadth
and
scope.
Do
you
think
there's
any
limits
or
have
you
seen
just
like
pretty
much
anything
you
could
build
in
front
of
javascript?
You
could
build
with
modern
dojo.
C
I
mean
I
haven't
seen.
I
haven't
heard
anyone
trying
to
build
something
in
dojo
and
not
being
able
to.
If
that's
the
question
right
site
pen,
we've
used
dojo
on
a
number
of
kind
of
big.
C
You
know
customer
projects
which,
and
by
big
I
mean
you
know,
you
know,
I
don't
know
whether
it
matters
how
many
modules,
but
then
you
know
thousands
of
modules
within
you
know
within
that
application
with
no
kind
of,
and
it's
it's
a
so
because
we've
been
able
to
do
that
and
basically
dog
food,
you
know
dojo
inside
them.
We,
you
know,
we've
had
feedback
from
our
own
engineers.
C
You
know
where
you
know
where
the
pain
points
are,
how
you
know
some
suggestions
on
like
where
the
boilerplate
is
as
well
to
make
things
you
know
easier
for
us
to
actually
easier
for
us
to
actually
kind
of
work
on
and
improve,
and
that's
where
kind
of
some
of
the
the
more
recent
patterns
have
come
about.
You
know,
we've
had
support
this
this
year,
we've
had
a
concept
of
a
global
application
store.
C
You
know
since,
since
you
know
the
initial
release
and
that's
not
really
changed
a
significant
amount,
there's
been,
you
know
some
small
enhancements
that
have
been
made
across
the
board,
but
not
no,
you
know
not
conceptually
has
not
really
changed.
It's
like.
If
you
need
kind
of
some
application
state,
then
you
use
stores
and
then
you
can
create
your
own.
C
You
know
you
can
you
can
interact
with
your
whatever
remote
resources
you
need
to
to
to
go
with
to
get
it
asynchronously
using
fetch
or
whatever,
and
then
you
know
put
them
in
the
store
and
your
widgets
will
kind
of
re-render
and
and
use
that
information
when
it's
when
it's
available
within
that
within
the
actual
application
store
and
some
of
our
more
recent
concepts
have
been
to
try-
and
I
bet
there's
a
lot
of
boilerplate
with
that.
You
know
you
have
to
create.
You
have
to
create
kind
of.
C
You
know
if
you're
talking
like
in
comparison
to
kind
of
some
of
the
other,
like
well-known
kind
of
applications,
state
stores
like
redux.
You
have
to
create
your
like
the
concept
of
your
kind
of
actions,
stroke,
reducers
and
you
have
to
and-
and
you
have
to
manage
kind
of,
like
the
structure
of
that
data
and
how
it's
stored
so
that
you
can
get
information
like
whether
something's
loading
or
is
in
progress
or
it's
failed.
Or
you
know
what
like
the
pagination.
B
And
so
I
think
that's
why
we
see
somewhat
of
a
proliferation
of
react
frameworks
lately
trying
to
solve
some
of
those
problems,
because,
like
they're,
just
kind
of
unanswered
or
open-ended
questions
for
most
people,
and
it's
where
we
see
a
lot
of
people
run
into
challenges.
In
that
space
I
mean
yeah.
C
Go
ahead,
yeah
we
said
we
saw
we've
seen
the
same
thing
you
know
internally,
to
site
then,
and
equally
like
on
discord
where
people
have
you
know
been,
had
challenges
in
in
dealing
with
these
kind
of
common
scenarios,
and
that's,
where
kind
of
our
you
know
the
new
concept
that
got
released
in
dojo7,
which
is
which
is
resources.
C
That's
where
that
we're
hoping
that
comes
in
to
play
to
help
people
like
manage
those
kind
of
application
interactions,
or
you
know,
and
dealing
with
application
data
without
having
to
worry
about
those.
You
know
the
boilerplate
required
and
all
of
the
machinery
you
need
to
put
in
place
in
order
to
actually
kind
of
get
that
to
be
all
wired
together
in
your
within
your
application.
C
Yeah
and
all
of
our
all
of
our
widgets
that
are
effectively
can
use,
are
powered
by
data
like
our
lists.
Apart
from
the
grid,
our
lists
and
our
type
of
heads
and
everything
like
that,
they
all
now
as
a
dojo7,
they
all
use
resources,
that's
what
powers
them
and
it
gives
us
a
very.
It
gives
us
a
really
nice
kind
of
common
api
across
all
of
our
widgets
to
author
in
and
gives
all
of
our
kind
of
all
our
consumers.
B
It
would
probably
help
if,
if
you
feel
like
it
to
just
sort
of
comparing
like
you,
did
a
little
bit,
comparing
redux
with
dojo
store,
which
is
kind
of
like
operations,
transforms
processes,
and
it
feels
like
there's
a
pretty
clean
way
to
do
things
and
there's
less
boilerplate.
I
don't
know
if
you've
used
mob
x
much
or
if
you
compare
it
or
contrast
it
with
that
or
if
that's
just
a
bad
question,
and
I
should
move
on.
C
No,
it's
fine,
I
mean
the
conceptually
that
is,
you
know
they.
They
do
the
same
thing
you
know
like
we.
There
would
be
no
point
us
coming
up
with
a
solution
for
application
state,
because
redux
isn't
kind
of
react
specific.
C
Obviously,
neither
does
mob
x,
necessarily
there'll,
be
no
point
where
else
coming
up
with
kind
of
a
state
solution
or
a
store
solution
in
in
dojo
if
it
was
kind
of
just
a
copy,
and
so
that's
where
we,
where
we
started
two
years
ago,
when
we
were
kind
of
thinking
about
what
we
wanted
to
start,
a
global
application
store
to
be
and
we
went
and
we
actually
went
with
a
pattern
called
with
using
jsonpatch
and
and
to
apply
changes
and
with
the
cop
with
obviously
the
stipulation
that
you
know
the
store
should
be
effectively
serializable
and
and
with
that
it
opens
up
kind
of
for
us.
C
It
opened
up
a
lot
of
power
in
terms
of
giving
us
the
ability
to
perform
those
kind
of
reducing
actions,
but
automatically
for
a
user
based
upon
those
changes,
those
those
operations
that
a
user
basically
creates
and
returns
from
our
store
commands,
and
it
also
enabled
us
to
kind
of
support
out
the
box
without
kind
of
having
any.
You
know
any
additional
like
middleware
or
machinery,
to
support
asynchronous
async
commands
so
that
you
know
we
don't
there's
not
there's
not
two
ways
of
doing
things.
C
There's
a
single
way
of
doing
things
you
return
operations
to
to
dojo
and
dojo
will
manipulate
and
change
the
store
based
on
those
on
based
on
those
operations,
and
that
was
kind
of
for
us
as
it
opened
up
a
load
of
potential,
future
ideas
and
abstractions
to
build
on
the
store.
You
know
we
can
serialize
and
deserialize.
C
You
know
our
state
to
local
storage
automatically.
We
can
support
out
the
box
things
like
undo
and
redo
by
applying
and
like
applying
the
reverse
of
a
an
operation
that
we
can.
Obviously
we
can
determine
so
they
kind
of
opened.
A
lot
of
you
know,
potential
future
features
and
some
of
which
we
haven't
actually
got
around
to
so
you
know,
there's
there's
plenty
to
to
to
kind
of
work
on
there
in
terms
of
the
store
and
resources.
C
It
does
read
at
the
moment
only
so
there's
no
kind
of
there's
no
persistence
and
or
modification
apis
that,
but
they
will
be
coming
in
in
a
in
order
to
kind
of,
but
it
does
support
by
default.
Other
box
kind
of
concept
of
pagination
querying
all
the
things
that
you
need.
You
would
expect
to
be
working
with
when
you're
working
with
you
know
a
resource
api,
and
so
therefore
it
provides
kind
of
the
all
of
the
meta
information
you
need,
and
you
can
access
that
within
your
widget.
B
Yeah,
I
kind
of
like
there's
they're
not
the
same,
but
there's
definitely
some
overlap
and
parallelisms
between,
like
how
react
hooks
make
it.
So
a
lot
of
things
don't
need
redux
like
simpler
applications.
Don't
need
redux
anymore.
Don't
need
to
think
about
that
and
how,
but
like
dojo,
also
has
this
concept
of
middleware
and
it
has
resources.
B
It
has
stores
and
react
kind
of
has
this
concept
of
hooks,
and
then
you
could
use
redux
or
mobx
and
there's
some
similarities,
but
also,
I
think,
there's
some
more
distinction
and
delineation,
but
also
like
jojo's
middleware
sort
of
fills
the
gap
for
like
reacts,
references
and
as
well
as
things
you
might
use
for
hooks
and
resources,
then
kind.
C
B
C
I
mean
hooks
hooks
and
contacts
are
effectively
kind
of
the
primitives
that
the
people
are
building
kind
of
custom
custom
hooks.
You
know
to
support,
you
know
redux,
and
things
like
that.
So
you
know
yeah
they've
obviously
got
this.
C
You
know
used
state
and
and
and
that's
a
primitive
hook
that
and
react
provides
that
you
know,
with
the
concept
of
you,
know
the
context
and
and
being
able
to
build
on
hooks
to
build
hooks
on
hooks
and
that's
where
kind
of
redux
have
been
been
able
to
build
their
own
hooks,
which,
for
me
ergonomic
ergonomic
wise,
it's
so
much
nicer
to
do
that
right.
You
know
hooks
hooks
where
you
know
you're
game
changing
for
react.
C
In
my
opinion,
in
terms
of
the
ergonomics,
I
think
most
people
are
kind
of
got
the
camera
out
at
least
come
around
to
that
now
and
and
for
dojo
middleware,
because
we've
talked
about
resources,
we've
talked
about
quite
a
few
things
in
terms
of
you
know.
Theming
but
middleware
is
is,
is
not
it's
not.
I
wouldn't
want
to
compare
it
to
hooks,
but
it's
you
know
it's
an
equivalent
machinery
that
we
have
for
dojo.
C
That
is
the
primitive
that
you
can
build
kind
of
some
shared
logic
that
you
can
use
within
your
widget
that
gets
injected
in
your
widget,
which
can
maintain
kind
of
references
across
across
renders,
for
example,
which
obviously
with
widgets
being
effectively
you
know
just
a
function.
C
That's
called
that's
something
that
dojo
like
react,
manages
kind
of
in
there
in
their
reconciler
or
you
know,
whichever
part
the
yeah,
this
library
is,
and
so
yeah
resources
is,
is
a
is
a
middleware
there's
a
core
middleware
that
that
dojo
provides
and
we
provide
them
in
quite
a
few
corner
ways.
You
know
we
have
something
called
an
icash
which
is,
I
would,
I
would
say,
that's
very
similar
to
kind
of
the
use
state
hook.
You
know
it's
a
way
to
maintain
and
manage
state
across
renders
locally
to
that
widget.
C
You
know
it's
called
an
icash
because
it
actually
stands
for
invalidating
cash,
because
here,
when
it
changes,
it
will
invalidate
your
widget
and
re-render.
That's
you
know
the
dojo
concepts
we
have
hooks
for
theming
and
internationalization,
which
we
haven't
really
touched
on,
but-
and
we
have
did,
I
say
hooks
on
that
middleware.
A
C
Have
middleware
for
some
of
the
cooler
kind
of
aspects
of
dojo,
so
we
have
like
intersection
observer
middleware.
We
have
middleware
for
resize
observer,
I'm
trying
to
try
to
think
without
looking
yeah.
B
These
things
that
are
intended
to
be
middleware
aren't
all
prefixed
with
the
word
use
like
they're,
just
they're
kind
of
called
what
they
are,
which
to
me
is
a
plus,
but
also,
I
think
that
it
was
just
part
of
the
design
of
the
framework,
and
so
like
hooks
to
me,
feel
like
something
that
kind
of
had
to
be
carefully
designed
around
what
react
was
already
doing
and
to
not
break
all
the
different
you
know
did
component
mount
and,
like
all
the
other
stuff
that
was
already
there
and
it's
like
if
you've
used,
react
forever.
B
It
just
kind
of
feels
straightforward,
but
if
you're
new
to
react
you're
like
wait,
why
is
this
thing
using
connect,
and
this
thing
using
component
did
mount
and
this
thing
using
use,
selector
or
use
state
or
whatever,
and
it's
pretty
easy
to
like
get
confused,
because
there
are
so
many
examples
like
that
or
even
you
pull
in
a
dependency
and
it's
used
in
the
old
way
and
you're
like
oh,
what
is
this
stuff
doing?
I
don't
get
it
right,
and
so
there's
there's
not
as
much
of
that.
B
In
my
experience
with
dojo
one
of
the
you
know,
one
of
the
things
that's
kind
of
interesting
is
so
there
are
things
we
tried
in
modern
dojo
that
we
ended
up
just
not
needing
as
much
of
one
thing
we
tried
early
on
was
wrapping
like
the
equivalent
of
first
we
had
rxjs
in
dojo,
and
then
we
switched
to
trying
to
wrap
the
observable
shim,
and
then
we
also
had
a
lot
of
a
lot.
B
We
thought
we
needed
a
lot
of
reducer
stuff
and
we
thought
we
might
need
streams
and
we
kind
of
ended
up
not
needing
any
of
those
things,
because
I
feel
like
we
just
wrote
apis
that
were
like
where
they
needed
to
be
reactive.
They
were
reactive
where
we
needed
to
reduce
things.
We
reduced
them.
So
it
wasn't
like
we
needed
to
bolt
those
things
onto
the
framework
they
were
just.
They
just
were.
C
I
mean
yeah,
I
mean
I
think
you
kind
of
touched
on
it
there.
I
don't
think
necessarily.
It
was
the
apis
because
you
know
early
in
your
early
dojo.
You
know,
I
think,
we've
you
know,
we
all
made
mistakes
in
terms
of
some
of
the
apis.
We
opened
up
and
some
of
the
some
of
the
apis
we
designed,
but
fundamentally
we
got
the.
We
hope
that
we
got
the
pattern
right.
The
reactive
pattern
wrote
which
meant
that
you
didn't
need.
C
You
didn't
need
kind
of
any
of
that
kind
of
like
the
rxgs
kind
of
patterns,
but
you
know
in
dojo
there
are
obviously
absolutely
you
know
times
and
places
to
use
kind
of
rxgs
and
the
observable
observable
patterns.
But
you
know
with
the
kind
of
the
top
down
reactive
kind
of
you
know:
property
passing
like
it
just
it
didn't,
it
wasn't
necessary.
C
So
obviously
we
played
with
it
we
kind
of
got
a
feeling
for
whether
or
not
that
would
be
that
would
in
and
and
if
we
don't
need
it
and
we
don't
need
to
depend
on
an
external.
You
know,
like
library,
that's
you
know,
that's
great
for
us.
C
That's
kind
of
if
you
look
at
dojo
itself,
it's
you
know,
there's
minimal
kind
of
external
dependencies
required
and
mostly
they're
kind
of
shims
for
like
intersection
observer
and
things
like
that,
we
kind
of
wrap
and-
and
that
gives
us
the
power
to
basically
like
conditionally,
include
them
for
certain
users
rather
than
make
it
so
that
users
have
to
include
that
themselves.
C
So
yeah
I
mean
obviously
over
over
the
over
the
last
two
years,
as
we
moved
away
from
you
know,
using
kind
of
typescript
classes
that
gave
us
two
years
ago,
all
the
power.
We
need
a
lot
of
power
we
needed
in
order
to
actually
kind
of
describe
apis
and
infer
kind
of
properties
for
widgets.
You
know
typing
wise
via,
like
a
form
of
generic,
to
kind
of
a
more
function,
a
functional
approach
trying
to
it.
It
felt
more
natural
to
us
as
javascript
engineers
as
well.
C
Ended
up
back
where
we
wanted
to
be
yeah
yeah.
We
obviously,
as
you
say,
like
we
started
off
with
a
kind
of
a
library
called
compose
in
dojo,
which
provide,
which
was
an
attempt
to
provide
a
functional
kind
of
composition,
api,
and
it's
not
that
we
got
to
a
composition,
api
now
per
se,
but
kind
of
that
was
that
was
the
original
kind
of
ergonomics
that
we
felt
would
be
the
nicest
way
to
achieve
something
it
just
was
it
wasn't?
C
Yeah
in
terms
of
like
mixings,
because
we
could
use
mixers
to
decorate
behavior
and
decorate
properties
onto
an
interface
that
would
then
you
know
be
typed
for
the
for
the
end
for
the
author
and
the
end
user,
so
that
was
crucially
important
to
us
at
the
time
and
then
obviously
touch
groups
even
in
the
last
two
years
has
you
know
like
come
on?
Even
you
know
it's
you
know
it's.
You
know
the
adoption
and
and
the
love
that
touch
was
getting.
I
think
it's
winning
over
kind
of
the
majority
of
the
community
at
the
moment.
C
Well,
as
far
as
I
can
see
and
yeah-
and
I
think
that's,
I
think-
that's
right
anyway.
You've
personally,
I
think
I've
seen
it
used
in
kind
of
our
customer
projects
at
site,
pen
and
and
how
well
it
really
helps
to
lock
a
larger
engineering
team
to
and
from
our
perspective,
is
kind
of
like
having
to
wrangle
types
to
get
something
so
that
it
works
perfectly
as
close
to
perfectly
for
a
user
in
a
lot
in
a
framework
or
a
library.
B
Yeah,
so
I
have
two
very
different
questions
that
I
think
we'll
probably
take
the
rest
of
the
time
we
have
one
is
like:
do
you
think,
there's
something
we
can
do
with
typescript
4.1
like
template,
string,
type
string,
literals
that
they've
added
to
maybe
support
a
syntax
beyond
jsx,
maybe,
and
then
the
other
question
is
sort
of.
If
you,
if
you're
writing
an
application
with
react
or
angular
or
something
else
are
there
things
you
might
do,
that
would
make
it
easier
to
eventually
port
an
application
to
dojo.
C
B
We
haven't
we've
been
experimenting
with
something
a
bit
right,
like
templates,
a
little
different
than
jsx
right.
C
You
mean
so
that's
the
figure,
that's
hugely
experimental
and
that
didn't
require
4.1.
That's
something
that
matt
gadsben.
You
know
experimenting
with
forever
in
terms
of
providing
a
a
mechanism
for
templating
in
dojo,
to
provide
kind
of
that.
I
guess
even
like
to
take
it
even
one
step
further
to
be
to
lower
those
boundaries,
those
barriers
eventually
to
eventually
to
make
it
so
that
people
can
use
kind
of
similar.
C
It
would
all
be
powered
by
the
same
machinery
under
the
hood,
but
it's
it
would
provide
you
kind
of
that
template
language
that
template
syntax,
that
users
could
build
and
yeah
I
mean
in
the
future.
I
think
that's
certainly
something
that's
a
big
it's
one
of
the
big
kind
of
ticket
items
that
we
want
to
get
around
to,
I'm
not
sure
it'll
make
eight,
but
I
know
for
a
fact
it
won't.
But
yeah
I
mean
that's
something
that
matt's
kind
of
wanted
to
kind
of
play
with
and
and
get
working.
C
You
know
for
a
while.
So
I'm
sure
that
will
come
back
round
and
what
was
the
second
question
again.
C
I
mean,
I
think
the
key
thing
is
is
obviously
like
with
you
know:
dojo
react
and
angular
and
vue
they
all
have
kind
of
their
own
like
patterns,
even
if
they're
similar
in
concepts.
So
I
think
for
me,
converting
kind
of
a
react
app
using
kind
of
the
you
know.
The
basic
hooks
would
be
pretty
straightforward
to
dojo.
I
mean
a
lot
of
the
time
if
you
squint
at
some
dojo
code.
You
know
if
you're
familiar
with
react,
you'll
kind
of
go.
Oh,
it
looks
like
react.
C
You
know
we
use
jsx.
We
we
have
things
that
don't
have
use
in
front
of
them,
but
kind
of
are
similar
in
a
paradigm
to
hooks.
So
that's
possible.
I
mean
angular
kind
of
is
a
different
beast
altogether
and
I
think
you
know
I
think
it
would
be
a
large
effort
to
convert
you
know.
Most
kind
of
you
know
it's
not
hello
world
angular
apps
and
I
think
the
same
is
probably
true
of
view.
To
a
lesser
extent,
just
generously,
just
you
know
the
patterns
they
used
single
file,
components
like
paradigm.
C
B
C
Yeah
I
mean
it
looked
really
good.
You
know
from
what
I've
seen
and
I
guess
that's
the
thing
is
like
I
mean
all
the
frameworks
you
mentioned
are
all
great.
The
biggest
the
biggest
goal
that
we
have
is
is
not
necessarily
kind
of
that
portability
from
like
react
or
view
or
or
angular.
It's
actually
kind
of
we
want
to
kind
of.
C
As
you
said
earlier,
is
you
dojo2
was
such
a
different
beast
to
dojo
toolkit
or
dojo
one
point
whatever,
and
you
know
one
something
we
really
want
to
look
at.
Is
we
really
want
to
provide
a
better
path
for
people
who
are
using
dojo
toolkit
today
with
their
applications
to
to
migrate
to
dojo
too
oh
dojo.
C
So
that's
something
that
I
like.
We
really
want
to
try
and
kind
of
smooth
over
smooth
over
and
and
make
more
possible,
because
at
the
moment
it's
you
know
there
isn't
you
know
there
isn't
much
tooling.
We
don't
provide
much
guidance
and
really
and
truly
the
those
are
the
kind
of
the
applications
and
projects
that
you
know
from
a
dojo
perspective.
C
We
want
them
to
their
first
choice,
to
be,
you
know,
migrate
their
app
to
dojo
progressively,
like
building
yeah
use,
modern
dojo
like
without
having
to
rewrite
their
entirety
of
their
kind
of
five
six
year
old
up,
which
is
you
know,
it's
no
mean
feat
anyway.
So
and
of
course,
it's
possible.
You
know
given
the
right
knowledge
and
the
right,
you
know
in
time
and
engineers
so.
C
B
Things
over
by
sort
of
keeping
like
jojo
does
a
pretty
good
job
of
this,
like
dojo
uses,
underneath
the
covers
like
post,
css
and
css
modules
and
webpack
and
a
few
other
things
right.
But
as
a
user
of
dojo,
you
really
don't
care
about
those
dependencies
which
means
that
like
if
we
need
to
migrate
to
something
else
besides
webpack
or
we
decide
that,
like
css
modules,
aren't
or
post
css,
isn't
the
right
package
for
that,
and
we
want
to
switch
to
something
else.
It's
pretty
easy
for
us
to
do
that.
B
A
B
Migration,
so
it's
kind
of
the
same
thing
like
if
you're,
like
going
really
low
level
into
all
the
innards
of
everything.
React
might
do
everywhere
on
your
code
base
and
similarly
with
angular
like
it's
hard
to
decouple
that
versus
like
if
you've
got
kind
of
a
clean
separation
of
like
this
is
my
components:
they're
pretty
much
aligned
with
standards
and
I'm
passing
some
data.
And
then
it's
pretty
easy
to
swap
things
out
at
least
know
what
we
know
where
you
need
to
swap
them.
C
Out
if
you've
got
kind
of
like
your
business,
your
logic,
your
wrapping
components
and
then
you
wrap
kind
of
your
leaf
components
that
are
kind
of
I'd,
say
dumb,
but
not
done,
but
don't
necessarily
use
any
of
kind
of
this
react
specifics
then
absolutely
you
know
it
does
reduce
kind
of
that
surface
area
that
you
need
to
kind
of
address.
If
you
were
to
kind
of
transition
from
you
know,
react
or
view
to
dojo
absolutely.
B
Awesome
well,
thanks
for
making
the
time
thanks,
openjs,
okay
foundation
for
having
us
and
thank.