►
From YouTube: OpenJS Foundation AMA: jQuery
Description
The OpenJS Foundation is a member-supported non-profit organization that provides a neutral home for some of the most important project in the JavaScript ecosystem.
Learn more and join us at https://openjsf.org
A
Cool
looks
like
we
are
live
according
to
the
zoom.
Let
Rachel
confirm
we
are
live.
Super
duper.
Ok
well,
good
morning,
everyone
or
evening
or
afternoon,
depending
on
your
locality
proper
greeting
to
you.
My
name
is
joy
person,
I'm
the
open
days,
foundations
and
community
manager,
and
today
we
are
asking
questions
about
the
Open
Jazz
foundation,
impact
project,
probably
the
impact
project
of
all
time
jQuery
and
to
answer
those
questions.
I
am
joined
by
the
very
wonderful
Dave
methan
and
Timmy.
A
B
C
Just
just
about
every
change
we
make
I
think
at
one
point.
Probably
10
years
ago,
I
said
every
change.
Jquery
makes
is
a
breaking
change
because,
regardless
of
whether
it's
documented
or
not,
people
have
come
to
expect
certain
behavior,
even
if
it's
not
documented
to
be
to
never
change,
so
that
even
includes
things
that
are
that
are
security
bugs.
So
we
have,
we
had
a
feature
in
Ajax
that
would
accept
the
content
type
from
a
server
to
say:
oh
you're,
you,
the
server,
are
telling
us.
This
is
a
script.
C
I'm
will
execute
it,
and
someone
pointed
out
well
that
can
be
a
security
bug.
You
may
be
indicating
somewhat
untrusted
site,
normally
you're
getting
text
back,
but
if
an
attacker
was
to
be
able
to
say
you'd
start
executing,
we
said
yeah,
that's
true,
but
they're
people
who
are
depending
on
this
automatic
detection
of
types
able
to
run
their
real
servers,
and
so
we
don't
want
just
go
and
and
change
it
in
a
minor
release
and
break
everybody's
code.
C
So
those
dilemmas
we
face
making
any
change
is
we're,
probably
know
we're,
probably
going
to
break
someone's
code
that
the
only
the
only
saving
grace
we
have
versus
say
roster
is
that
people
choose
whether
they're
going
to
change
their
version
very
most
time
or
its.
What
a
browser
does
an
update.
They
really
have
a
higher
risk
of
breaking
the
web.
A
B
Sometimes
it's
not
even
about
changing
something.
That's
been
documented.
We
if
we
have
to
be
careful
even
changing
things
that
aren't
documented,
that
people
are
relying
on
that.
We're
discovering
that
they're,
relying
on
like
removing
jQuery
browser,
for
instance,
there
might
have
been
a
lot
of
people
using
that
to
sniff
the
user
agent
and
that
wasn't
really
why
I
was
there.
It
was
just
a
convenience
property
for
us
internally
and
we
eventually
removed
it
because
we
considered
it.
You
know
not
the
best
practice
to
sniff
abroad
rate
browser
agent
may
be
used.
B
A
A
C
That
I
think
the
most
the
most
critical
advice
for
anyone
both
for
us
in
the
past.
The
past
us
and
also
anyone
creating
software
that
is
used
by
a
lot
of
people
is
to
be
very
conservative
in
what
you
add
to
learn
how
to
say
no
in
a
nice
way,
because
everything,
you
add,
becomes
a
liability
for
the
future.
C
B
If
I
can
add
to
that
I
think
if
we
could
have
known
the
future
in
terms
of
how
the
specs
would
evolve
there
didn't,
there
would
have
been
a
lot
of
things
that
we
would
have
waited
on
and
not
added
or
altered
a
little
bit.
Because
that's
that's
the
way
the
spec
was
going
to
turn
out
so
jQuery
kind
of
led
the
specs
in
that
way,
but
they
didn't
always
define
them
and
like,
for
instance,
I'm
skipping
ahead
a
little
bit
but
I
think
we
have
a
question
about
deferreds.
B
We
I
would
have
liked
it.
Had
we
not
added
deferreds
at
all
and
just
use
native
promises,
but
they
weren't
out.
Yet
they
were
still
being
defined
and
it
it
turned
out
that
the
behavior
of
promises
alt
was
a
little
bit
different
than
what
we
thought
would
they
were
going
to
be
as
the
deferreds
are
still
different
than
problem
promises.
Although
that's
an
overstatement
because
we
still
have
dot
then,
which
is
completely
promises
compliant,
but
there's
still
an
odd
mixture
because
dot
done
isn't
promises
compliant.
B
C
I
think
we
we
also,
we
just
ran
into
a
lot
of
situations,
I
think
where
we
were
kind
of
ahead
of
the
curve,
like
we
were
part
of
the
process,
the
thinking
process
and
creating
some
Banford.
But
during
that
process
it
would
come
out
the
other
end,
looking
a
little
different
than
we
than
we
had
defined.
But
at
that
point
we
had
millions
of
people
using
our
API,
so
we
could
just
say:
well,
you
know,
for
reasons
of
being
standard,
we're
going
to
abandon
all
you
guys
and
break
all
your
code.
Mm-Hmm.
A
C
I
mean
that's,
that's
something
that's
a
very
difficult
line
to
walk,
because
the
only
way
you
can
kind
of
push
things
is
to
get
it
out
there
and
let
people
experiment
so
I.
Don't
think
we
would
want
to
say.
Oh
we're
just
not
going
to
put
any
of
these
things
here.
It
would
have
been
good
to
have
a
mechanism
by
which
we
could
have
like
had
like
supported
plugins
or
something
that
weren't
built
baked
right
into
baked
right
into
jQuery.
B
C
C
You
know
fetch
me
some
stuff
and
then
try
to
convert
it
to
JSON
and
then
do
this,
but
you're
on
it's
all
from
the
outside
you're
doing
that,
whereas
what
Ajax
did
is,
it
said,
fetch
me
some
stuff
and
I'm
going
to
pass
you
a
flag
telling
you
what
type
I
think
it
is
or
what
type
you
should
try
to
interpret
it
as
there
were.
There
were
every
time
we
added
a
feature
to
Ajax.
We
had
to
add
more
flags
to
it.
A
But
to
your
point
it
was
also
pretty
you
know
groundbreaking.
You
know
at
the
time
and
the
project
in
many
ways
helped
push
this
the
language
development,
the
standard
development
along
probably
more
quickly
than
it
would
have
than
the
language
would
have
evolved
with
without
jQuery.
So
you
know
I
mean
if
you
would
yes,
you
could
go
back
in
time
and
maybe
do
things
a
little
differently,
but
do
you
think
we'd
have
the
same,
the
same
language
that
we
do
today,
yeah.
B
That's
a
great
point:
I
think
Jay
Curry's
legacy
isn't
so
much
its
popularity
or
like
the
api's
in
themselves.
It's
how
they
influenced
the
web
as
a
whole
and
how
you
know
what
we
got:
query:
selector
all
which
is
largely
based
on
the
selector
engines,
the
JavaScript
selector
engines
and
fetch,
and
there
are
countless
examples,
but
I
think
it
just
goes
to
show
how
good
John
Resig
was
at
creating
api's
and
when
they
got
so
popular
and
carried
over
into
native
world.
C
Yeah,
definitely
we,
you
know
the
jQuery
project
has
fluence
standards,
but
to
your
point,
Joey
I
think
they
that
standards
always
move
slowly
and
deliberately
both
the
web
Dom
standards
and
JavaScript,
and
they
move
so
slowly
that
are
still
that
have
not
yet
been
memorialized
inside
the
Dom
API
that
are
proposed.
That
are
jQuery
features,
so
you
know
had
the
world
needed
to
wait
that
long.
You
know
15
years.
They
wouldn't
have
wanted
to
wait
that
long.
Some
other
solution
had
to
be
found.
Jquery
was
part
of
that.
B
A
That's
a
great
comparison
and
I
hadn't
actually
thought
about
it.
That
way,
so
you
know
I
think
another
in
addition
to
the
standards,
impact
and
influence
on
standards.
The
other
place
I
see
personally
jquery's
legacy
at
play
is
in
just
open
source
community
and
I'll
share
a
little
bit
about
my
background
I
when
I
first
got
into
open
source.
A
Jquery
was
the
first
community
that
I
discovered
and
it
was
mind-blowing
because
there
was
you
know
there
was
this
big
team
of
people
and
it
was
so
welcoming,
and
there
was
the
the
IRC
channels
and
and
all
of
all
of
that
kind
of
thing,
and
today,
working
with
open
source
communities
it
it's
so
funny
to
see
little
things
that
we
we
were
doing
with
jQuery.
You
know
that
are
now
kind
of
common
practice,
open
more
of
an
open
governance
style,
and
things
like
that.
C
C
We
just
followed
that
pattern
in
creating,
especially
for
the
jQuery
core
team.
I
think
you
know,
especially
as
you
go
through
the
life
cycle
of
a
project.
If
you
go
back
when
we've
got
hundreds
of
contributors
to
jQuery
core
the
majority
of
them,
the
first
ten
years
when
it
was
really
actively
being
developed
and
as
you
get
to
the
point
where
you
were
changes
and
the
impact
of
changes
are
highly
more
highly
felt,
I
think
with
a
small
of
who
have
kind
of
gotten
those
battle
scars
me
Timmy.
C
We
call
trying
to
think
of
who
else
who
particularly
active
Gib,
said
Richard
Gibson,
but
you
you've
got
folks
who
have
been
around
long
enough
to
know.
They've
stepped
on
the
mines
before,
and
so
they
don't
tend
to.
You
know
be
quite
as
quick
to
say:
oh,
let's
just
go
change
something,
but
that
sometimes
comes
off
to
a
community.
C
At
this
point
in
the
evolution
of
jQuery,
it
sometimes
comes
off
as
being
like
not
wanting
contributions,
but
it's
just
more
of
a
concern
as
contributions
come
in
that
the
end
the
person
making
the
proposal
doesn't
understand.
The
impact
and
we've
tried
to
fix
that
problem
by
having
documents
in
our
wiki
that
talked
about
the
criteria
we
use
for
deciding
the
whether
to
make
changes
or
not
I
think
that's
helped
some
as
well,
but
even
like
I
said,
I
mean
being
able
to
say
no
diplomatically.
C
B
I
think
that's
that's
a
good
point
like
Mike
Sheriff
I
think
brought
that
up
once
when
he
said
he
was
just
getting
started
and
he
introduced
a
change
or
you
know
he
opened
an
issue
and
then
he
opened
a
pull
request
and
it
was
his
first
pull
request
on
any
project
and
it
I
ended
up,
closing
it
and
rewriting
the
patch
and
fixing
it
myself.
But
in
that
process,
I
think
the
whole
team
tried
to
be
as
diplomatic
as
possible
and
talk
to
him
as
we
were
making
the
changes.
B
C
He's
also
one
of
the
people
who
I
think
has
gotten
that
fear
instilled
in
him
when
it
comes
to
making
changes.
We
were
just
talking
about
this
on
Twitter
last
week
about
how
there's
certain
changes
you
go.
Oh,
we
can
make
this
change
and
you
have
to
back
it
out.
You
say:
oh
well,
we
could
have
made
it
if
we
did
it
this
way.
Do
it
again,
it's
back
it
out.
So
that's
I
think
we're.
C
B
In
a
way
that
isn't
necessary
polite,
or
were
you
you're
already
on
the
defensive,
and
so
we
had
a
policy
to
try
to
negate
that
in
that
you
always
have
to
thank
them
for
opening
an
issue
and
starting
from
that
state
of
mind,
helps
you
to
be
more
accepting
of
possible
issues
and
not
get
defensive
right
away
and
that
that
was
a
community
policy
that
I
think
has
carried
over
to
lots
of
other
projects.
I.
A
Think
it
certainly
helps
people
feel
more
attracted
and
positive
about
you
know
the
project
and
not
just
the
project,
but
also
the
the
things
that
the
community
did
around
it
right
like
the
learn
website
and
the
IRC
channel
and
the
events
and
things
like
that,
like
you,
know,
and
and
feel
great
about
wearing
the
right.
Let's
do
more
swag
and
stuff
like
that.
A
So
I
think
about
jQuery.
You
know,
as
kind
of
a
prototypical
kind
of
like
as
a
sort
of
a
web
standards
historian
as
one
of
the
first
projects
that
really
started
to
try
and
like
define
what
a
successful
open
source
project,
a
successful
and
great
framework
really
was,
and
do
you
see,
jQuery
is
a
great
framework
and.
B
B
Really
so
I
I
guess
I
have
a
more
personal
connection
than
some
people
might
to
just
a
JavaScript
library,
so
I
would
I
was
in
class
in
a
computer
science
class
I
think
it
was
a
database
class
and
someone
from
Chattanooga
a
developer
came
and
spoke
at
our
class
and
told
everybody
that
they
had
to
learn,
jQuery
and
so
I
did
and
I
got
really
into
the
code
and
I
started.
Looking
at
the
issues
and
I
just
picked
a
few
and
started,
you
know
submitting
pull
requests
and
eventually
I
submitted.
C
C
Yeah
I,
obviously
personally
got
a
lot
out
of
jQuery
during
all
this
time.
I
think
that
is
interesting.
You
use
the
term
framework
because
I
think
jQuery
is
definitely
not
framework.
It's
really
more
of
library
and
that
our
desire
to
kind
of
keep
jQuery
as
a
as
a
focused
library
meant
that
people
had
to
go
elsewhere
to
find
ways
to
structure
Apple.
C
So
there
was
a
lot
of
frameworks
that
were
built
on
top
of
jQuery
in
the
early
days,
because
the
problem
of
that
jQuery
was
trying
to
solve
with
Dom
manipulation
and
browser.
Independence
was
particularly
hard
during
those
times,
not
quite
as
much
today,
but
even
so,
the
simplicity
and
the
jquery
api
itself
is
still
worthwhile,
even
if
you
don't
need
it
because
you're
not
using
IE
11
I.
A
Think
and
that's
a
great
place
to
segue
into
like
the
continuing
utility
of
jQuery.
You
know
there's
certainly
been
like
it
still
powers
a
lot
of
the
web.
It
still
powers
a
lot
of
these.
These
frameworks
that
are
still
in
use.
It's
still,
you
know
one
of
those
tools
that
is
easy
to
just
get
started
with
you
know
and
and
I
was
looking
at
the
HTTP
archive
data,
because
it's
just
very
mind-boggling
to
go,
look
and
see
okay.
A
Well,
what
what
where
we
at,
like
how
many
web
pages
are
using
using
jQuery
and
their
Almanac
from
last
year,
reported
that
it's
in
use
by
over
85%
of
desktop
pages
and
83
percent
of
mobile
pages?
And
that's
a
lot
of
that's
a
lot
of
web
pages.
So
you
know
I'm
curious
kind
of
how
how
that
data
factors
in
for
you
all,
as
you
think,
about
maintaining
jQuery
today
and
also
maintaining
it
into
its
into
its
future.
B
B
B
C
You
need
to
keep
track
of
I,
can't
imagine
trying
to
write
face
the
Facebook
site
just
using
jQuery.
But
if
you
look
at
the
majority
of
the
content
on
the
web,
most
of
it
is
not
really
doesn't
have
that
much
state.
It's
it's
just
kind
of
more
reading
type
material,
probably
the
most
complex
stuff
on
the
page
or
advertisements
and
I'm,
not
sure
I
really
want
to.
C
You
know
to
have
people
writing
react
advertisements
the
the
thing
that
I
that
I
think
makes,
especially
if
you're
going
to
use
the
app
effectively
and
you
want
to
use
it
like
with.
If
you
want
to
render
on
the
backend
or
react,
then
that
requires
a
complete
reactive
Rock.
We
architecting
of
your
system.
C
So
if
you
look
at
all
of
the
Drupal
and
WordPress
and
other
existing
backends
out
there,
those
really
have
already
baked
a
lot
of
the
state
management
and
content
management
into
that,
and
so
when
they
push
something
down
an
approach
that
jQuery
has
like
progressive
enhancement
where
you
say
well,
basically,
we
have
HTML.
You
just
need
to
add
some
things
to
make
it
a
little
more
lively,
jQuery,
still
a
good
solution
for
doing
that.
I
think
probably
I
can
certainly
say
in
the
work
that
I'm
doing
it
sounds
like
the
work
that
Timmy's
doing.
C
That's
not
really
the
paradigm
we're
trying
to
follow
for
the
doing
but
jQuery.
Obviously,
you
know
if
you're
running
a
wordpress
site,
you're,
probably
going
to
have
jQuery
there,
and
you
know
trying
to
say
well
we're
just
going
to
throw
that
out
and
build
a
react.
The
application
on
top
of
WordPress
is
probably
not
the
most
effective
way
to
solve
the
problem.
B
C
B
A
I
think
another
thing
is
for
a
lot
of
folks
learning
to
program.
You
know
that
it's
still
one
of
these
tools
that
gets
taught
in
boot
camps
and
code,
schools
and
things
like
that
and
because,
certainly
for
me,
I
think
it
I
found
it
very
easy
to
learn
and
start
to
think
about
and
reason
about.
This
was
several
years
a
few
years
ago
and
and
I
think
that's
still
true.
Do
you
think
that
jQuery
will
always
have
a
place
for
folks
learning,
JavaScript.
C
B
Instead
of
JavaScript,
because
it's
really
just
JavaScript,
it's
just
a
JavaScript
library
and
I-
think
there
were
a
lot
of
beginners
that
you
know
learned
the
jQuery
API
and
didn't
necessarily
have
an
understanding
of
how
JavaScript
worked.
You
know
that
they
weren't
familiar
with
prototypes
or
anything
like
they
get
native
to
the
language.
Exactly
and
they're.
C
B
B
C
Think
it's
you
know,
especially
looking
at
the
period
of
time
when
jQuery
was
created
2005-2006
time
frame,
it
was
really
difficult
to
do
even
simple,
animation,
simple
Ajax.
A
lot
of
that
was
it
all
required,
a
bunch
of
JavaScript
and
people
would
create
their
own
little
custom
libraries
of
various
kinds.
That
would
sometimes
only
work
for
certain
special
codes.
Oh,
but
you
know
out
today,
most
of
animations
can
be
done
with
CSS
and
are
the
best
done
with
CSS.
C
Most
of
Ajax
can
be
done
with
simple
fetches
and
a
few
little
odds
and
ends,
but
it's
still
relatively
easy
to
do
all
of
that
with
with
jQuery
as
well.
It's
just
that
even
even
for
those
of
us
who,
like
jQuery,
we
would
prefer
that
people
use
the
standards
that
are
already
there,
because
they're
more
efficient,
they're
better
on
battery
for
mobile
devices,
those
kind
of
things.
So
you
know
we
should
expect
things
to
have
all
that.
C
You
know
you
have
a
car
from
1990,
it's
not
going
to
be
nearly
as
it's
not
just
the
age
of
the
car.
It's
all
the
features
that
have
been
put
in
the
car.
So
you
got
backup
cameras
and
sideview
cameras
and
airbags
really
jQuery
was.
It
was
the
right
tool
for
that
time,
and
it
still
has
a
lot
of
features
that
are
useful
today.
Many
parts
of
it
that
are
have
been
superseded
by
either
CSS
or
JavaScript
or
Dom
api's.
There.
C
C
For
that
event
to
be
able
to
react
to
it.
Both
of
those
things
are
sometimes
constraints
that
you
don't
want
to
have
to
deal
with.
So
jQuery
has
a
document
ready,
API
that
says
I'm
going
to
give
you
a
function
and
if
the
documents
ready
call
it
if
the
document
becomes
ready
later
call
it
so
that
eliminates
the
need
to
be
there
to
watch
the
tree
fall
in
the
forest
to
hear
it.
You
can
just
you
know
at
any
point
say:
has
the
tree
fall
and
if
the
trees
fallen,
then
it
executes.
C
This
function,
that's
probably
the
biggest
benefit
of
document
ready,
but
it
still
turns
out
that
there's
complications
to
that.
There
aren't
that
I'd,
like
people
want
to
be
able
to
run
this
code
as
quickly
as
soon
as
possible,
but
but
no
sooner
so,
if
you
want
to
be
able
to
manipulate
the
document
before
it
shows
up
on
the
screen
so
that
you
can
avoid
any
flash
upon
the
screen.
C
B
B
However,
when
you
get
down
into
the
implementation
of
that,
it
can
get
really
complicated,
because
we
can't
we
can't
actually
use
interactive
all
the
time,
because
there
are
still
bugs
in
certain
browsers
that
we
support.
So
we
we
try
to
use
interactive
where
possible,
I.
Think
I
can't
remember:
we've
gone
back
and
forth
on
this
so
many
times,
because
we
just
keep
encountering
bugs
with
it.
What's
that
I
said.
B
B
B
C
A
So
we're
and
nearing
the
end
of
our
of
our
allotted
time,
but
to
kind
of
wrap
up
I
was
curious
if
we
could
talk
a
bit
more
about
jquery's
future,
which
you
know
I,
think
it's
a
good
point
that
you
make
the
projects
attempting
to
grow,
but
it
kind
of
is
organically,
especially
in
different
geographic
areas.
Where
do
you
all
see
the
project
in
the
next
say,
you
know
5
10
as
it
nears
the
end
of
its
second
decade.
B
Well,
we
do
have
a
roadmap
for
jQuery
core
and
that's
available
on
our
github
in
our
wiki.
That
shows
some
of
the
plans
we
have
for
the
projects
and
documents
them.
One
of
the
major
things
I
think
we
want
to
do
is
change
the
infrastructure
for
our
websites
or
update
it,
at
least
because
a
lot
of
that
stuff
is
really
old
and
needs
to
be
updated.
C
B
B
C
I
agree
with
that
I
think
jQuery
when
you've
got
85%
usage
across
the
internet,
that's
not
going
away
anytime
soon,
so
so
jQuery
is
not
going
anywhere.
I
think
that
the
the
big
challenge
that
jQuery
has,
which
is
really
not
necessarily
up
to
the
team,
is
to
deal
with
the
issues
of
security
problems
that
are
existing
in
their
peoples
code
that
uses
jQuery,
potentially
in
jQuery
itself,
probably
times
these
change.
C
C
C
C
But
the
issue
quite
often
is
websites
are
written
by
people
and
someone
purchases,
for
example
a
wordpress
theme
and
the
theme,
something
that
you
know
that
they
they
the
person
who
bought
it,
has
no
idea
what
it
does,
but
it
used
this
jQuery
and
it
uses
an
old
version
of
jQuery.
So
you
know
at
some
point
that
needs
to
be
updated.
I
think
that's
a
problem
for
a
lot
of
ecosystems
like
Drupal
and
WordPress,
and
several
others
that
use
jQuery
as
part
of
their
their
system.
Right.
B
And
if
they
have
the
same
problem,
we
have
with
backwards
compatibility
and
needing
to
make
incremental
changes
and
very
small
changes
so
that
they
don't
upset
the
ecosystem
too.
Much
and
part
of
that
is
not
updating
jQuery,
because
we've
made
ranking
changes
and
have
moved
on
to
major
versions
and
dropped
browser
support
for
old
browsers,
like
IE
8
9.
I
think
a
10
in
coming
up
here
for
a
version
4
and
that's
not
something
wordpress
necessarily
wants
to
do
just
yet
and
even.
A
A
C
There's
a
lot
of
there's
a
lot
of
other
platforms
out
there
that
use
jQuery
I
was
involved
in
nonprofit
fundraising
software
a
couple
of
years
ago.
There
are
four
or
five
different
systems
that
are
all
expecting
to
have
jQuery
there
to
build
all
of
their
donation
pages
and
that
you
know
those
are
small
enough
systems
that
nobody's
going
to
go
back
and
reinvent
and
redesign
all
of
those.
It's
just
too
much
work
they're
going
to
if
they're
not
actively
developed,
it'll,
just
don't
have
to
age
out.
Somehow.
C
A
B
We're
always
looking
for
more
contributors
and
not
necessarily
in
the
code.
It
could
be
documentation
or
the
websites,
specifically
the
docs
website
or
the
home
page
for
jQuery
comm,
and
that
we
have
issues
on
github
that
are
labeled
I.
Think
it's
help
wanted
so
that'd
be
a
good
place
to
start.
If
you're
looking
to
contribute.
B
C
B
C
C
B
A
Okay,
well
and
I
think
that's
probably
good
good
question
to
end
on
there.
Let
me
just
thank
both
of
you,
Dave
and
Timmy
for
dialing
in
today
and
chatting
with
us
and
sharing
your
experience
with
our
broader,
open,
J's
foundation.
Community,
if
you
watched,
please
give
Dave
Dave
muffin
or
at
Timmy.
Well,
you
know
a
nice
little
heart
emoji
on
Twitter
to
show
that
support
and
for
all
that
they
do
for
the
web.