►
From YouTube: Javascript under the hood - Ridhwana Khan
Description
According to Github statistics, Javascript is the most used language today. As new Javascript frameworks and libraries are released, teams are utilizing them across all levels of the stack - the frontend, backend, desktop apps, hybrid apps, embedded devices and so much more.
There are many developers that are using Javascript every day, all day - however, many of us haven’t really delved deep into understanding the internals. Newer frameworks have made it such that developers can build full applications without ever learning about things like the javascript engine, callback queues, runtime, call stacks, concurrency, event loops, and the V8 engine.
Understanding the nuts and bolts of javascript is no longer a requirement to be able to build applications, however, knowing the details assist developers to be able to build better, cleaner and optimized applications.
During this talk, I’d like to provide you with fresh insights on how Javascript works under the hood!
This talk was recorded at the Jozi.JS meetup group on 19 July 2018.
https://www.meetup.com/Jozi-JS/events/249460508/
Disclaimer: The opinions in this talk are those of the individual and do not necessarily represent those of this channel, the meetup group, or it’s sponsors.
A
A
So
I
do
a
couple
of
other
things:
I
organized
some
meetups
I
organized
a
meet-up
cool,
ladies,
that
you
X
and
another
meetup
called
women
in
tech,
and
these
meetups
basically
have
the
same
goal.
The
goal
is
to
promote
diversity,
to
promote
learning
and
to
promote
building
relationships
with
each
other.
The
only
difference
between
the
two
groups
is
one
is
in
the
user
experience
space
and
one
is
more
in
the
tech
space
I'm.
A
Also
a
co-founder
of
a
nonprofit
organization
called
Casa
Mia
Casa
Mata
is
a
program
that
runs
in
underdeveloped
areas
and
it's
a
program,
their
teachers.
Children,
are
to
develop
the
skills
in
mathematics,
to
build
their
confidence
in
mathematics
and
to
increase
the
enjoyment
of
mathematics,
above
all
of
that
I'm.
An
extreme
JavaScript
enthusiast
I
think
that
javascript
is
a
fun
and
quirky
and
exceptionally
powerful
language
that
I
absolutely
have
learned
to
love
and
sometimes
hate
so
I
think
we
all
can
agree.
I
mean
we
I
chose
ejs.
A
A
A
It
also
gets
up
also
mentions
that
the
different
converts
and
pushes
that
happen
to
github
28%
of
them
are
JavaScript
based.
So
looking
at
these
stats,
I
get
huge
FOMO
like
I'm
so
overwhelmed
at
times.
I
think
it
brings
all
my
insecurities
to
the
forefront
that
I
have
to
be
at
the
top
of
my
JavaScript
game,
always
every
day
all
day,
but
it's
difficult
to
stay
at
the
top
of
my
game.
A
Right
like
in
the
past
three
years,
I've
used
at
least
six
of
these
frameworks,
and
that's
a
lot
like
I
mean
there's
a
new
kid
on
the
block
every
single
year,
so
javascript
is
used
on
the
backend.
It's
used
on
the
front
end,
so
this
frameworks
also
on
the
back
end.
We
have
no
js'
on
the
front
end.
We
have
things
like
react:
angular
ember,
all
those
cool
kills
and
then
we
have
JavaScript.
We
use
in
embedded
devices,
we
use
it
in
hybrid
apps
and
we
use
it
on
desktop
apps
like
electron
there.
A
So
many
frameworks
out
there,
but
these
frameworks
in
these
libraries
they
come
and
go,
and
it's
difficult
to
stay
on
the
top
of
your
game
and
it's
difficult
to
remain
relevant
because
there
are
so
many
so
I
feel
that
by
understanding
the
core
JavaScript
and
then
being
able
to
apply
that
knowledge
to
the
different
frameworks,
that's
how
I
tries
to
stay
at
the
top
of
my
game
so
reflecting
back
to
when
I
started.
My
career,
these
terms
were
all
thrown
around
all
around
me.
Things
like
call
stack,
asynchronous
concurrent,
single
threaded,
v8
non-blocking
event
loops.
A
So
I
mean
people
would
ask
me
so
I
hear
you
do
development.
What
kind
of
development
do
you
do
and
I'd
go?
I
do
I
tell
them
what
I
work
on
and
they
ask
me
so
what
languages
do
you
use
and
I'd
say?
Oh
I
use
JavaScript
that
asynchronous
concurrent
non-blocking
language
and
I'd
smile
at
them.
Just
like.
A
I
probably
could
have
gone
a
couple
of
more
years
without
knowing
the
nuts
and
bolts
of
JavaScript,
but
as
you
grow
as
a
developer
and
as
you
become
more
experienced
in
the
industry,
you
realize
that
it's
important
to
understand
the
fundamentals.
It's
important
to
understand
the
mechanics
of
JavaScript
and
to
have
fine
fine,
grained
control
over
certain
things,
especially
when
the
application
is
a
new
normal
application.
A
Whilst
it's
possible
to
builds
large-scale
applications
without
knowing
the
JavaScript
engine
under
the
hood,
any
car
owner
will
tell
you
that
it
they've
at
least
left
it
after
hood.
Just
once
look
what's
under
so
by
the
end
of
the
presentation,
I'd
like
to
get
my
hands
greasy
and
tell
you
guys
exactly
what's
under
the
JavaScript
hood
and
how
knowing
each
of
these
things
allow
you
to
write
more
optimized
and
efficient
code.
A
So
let's
talk
about
how
JavaScript
works
under
the
hood
for
the
context
of
this
talk,
I'm
going
to
talk
about
JavaScript
in
the
web
environment.
So
basically,
these
this
diagram
represents
all
the
moving
parts
in
a
JavaScript
web
application.
From
the
time
we
load
a
URL
up
until
the
time
we
close
the
page
or
close
the
application.
A
A
A
We
also
have
the
browser
engine
and
the
browser
engine
acts
as
a
middleman
between
the
user
interface
and
the
rendering
engine,
and
it
also
is
responsible
for
communication
with
the
data
storage
layer.
Sometimes
the
browser
actually
has
the
browser
engine
and
the
rendering
engine
in
one
the
rendering
engine
is
really
interesting
to
me.
I'm
not
actually
going
to
cover
it
in
this
talk,
but
it's
definitely
on.
Am
I
less
to
talk
about
in
the
future,
so
the
rendering
engine
will
display
your
layout,
your
HTML,
your
CSS,
your
images,
your
pdfs?
A
A
A
Different
browsers
and
technologies
use
different
engines
and
initially
a
couple
of
years
ago.
This
was
a
little
strange
to
me
because
how
are
we
running
JavaScript
code
on
different
engines,
but
it's
true.
Each
browser
has
its
unique
here's
its
own
engine,
so,
for
instance,
Firefox
uses
an
engine
called
SpiderMonkey
Safari
uses
something
called
JavaScript
cool
and
the
v8
engine,
which
is
my
personal
favorite,
is
used
by
Google,
Chrome
and
nodejs.
A
So
I
think
the
I
think
it's
important
to
realize
that
the
end
goal
of
what
these
engines
do
is
all
the
same.
They
all
want
to
be
able
to
execute
JavaScript
code
in
the
most
efficient
way
possible.
However,
the
way
that
they
do
it
is
slightly
different,
so
the
way
that
code
may
be
interpreted
and
compiled
on
one
engine
may
be
slightly
different
to
the
way
that
it's
compiled
and
interpreted
on
another
engine.
Also
the
performance
on
each
end.
A
Engine
has
a
slight
difference,
but
the
purpose
of
this
talk
is
not
to
go
into
detail
around
each
engine,
but
rather
to
understand
the
context,
understand
the
context
in
which
this
engine
is
used
and
how
we
use
it.
In
the
context
of
development,
so
in
web
development
we
don't
actually
use
the
engine
directly
directly.
Instead,
we
use
the
JavaScript
runtime
and
throwing
all
these
storms
at
you,
the
JavaScript
engine,
the
JavaScript
runtime.
What?
But
what
are
they?
Actually
so?
A
Essentially,
the
JavaScript
engine
works
inside
of
environment
inside
of
an
environment
which
provides
additional
features
to
your
scripts.
So,
based
on
the
definition
that
you
see
there,
the
JavaScript
engine
essentially
translates
your
scripts
into
runnable
machine
code
instructions
so
that
it
can
be
executed
by
the
CPU
of
the
host
machine.
The
engine
translates
the
scripts
at
runtime
on
the
fly
your
code
won't
be
compiled
unless
you
run
it
well.
The
JavaScript
runtime
providers
provides
your
scripts
with
utility
libraries
which
can
be
used
during
execution.
A
It's
your
script
that
references
these
libraries,
the
engine
itself,
does
not
depend
on
them.
So
essentially,
what
that's
saying
is
that
the
runtime
provides
you
with
all
these
scripts
that
you
can
use
in
order
to
run
your
application
and
there's
something
really
cool
about
that.
So
remember
when
I
mentioned
it,
that's
the
noce,
nodejs
and
google
chrome
run
on
the
same
JavaScript
engine.
It's
because
they
actually
have
different
JavaScript
runtimes,
so
the
Google
Chrome
a
at
the
Google
Chrome
browser
in
its
runtime.
A
Our
code
allows
other
code
to
execute
or
run,
but
it
responds
at
a
little
bit
of
a
later
time,
so
we're
going
to
talk
about
JavaScript
in
the
context
of
synchronous
functions
and
then
we're
going
to
talk
about
it
in
an
asynchronous
environment.
So
when
we
executing
functions
functions,
synchronously,
there's
only
two
things
that
you
really
need
to
take
into
consideration.
The
first
thing
is
the
memory
heap,
and
this
second
thing
is
the
cold
stack,
so
the
memory
heap
is
used
for
memory
allocation
and
memory
management.
A
The
call
stack
is
a
data
structure
that
lives
in
virtual
memory
that
records
any
function
calls
that
occur.
So
let's
go
into
detail
about
them,
so
the
memory
heap
the
the
memory
here
essentially
performs
many
memory
management
automatically
and
completely
invisible
to
us.
The
garbage
collection
is
key
in
memory
management.
A
collector
aims
to
reclaim
memory
occupied
by
objects
that
are
no
longer
being
used.
Objects,
however,
there
are
still
being
referenced,
will
not
be
cleaned
up.
A
We
can
help
this
garbage
collector
by
setting
the
scene
for
it
to
be
able
to
collect
the
objects
that
it
requires
and
by
by
avoiding
memory
leaks
memory
leaks
is
a
memory
is
not
required.
Memory
leaks
is
a
basically
memory
that
is
not
required
by
the
application.
Any
longer,
however,
is
still
being
referenced
by
some
object,
and
therefore
this
memory
can
no
longer
be
across
by
the
OS.
A
The
goldstock,
so
the
call
stack,
is
a
data
structure
that,
if
set
records,
any
function
calls
there
occur
when
we
call
functions
to
execute,
we
essentially
pushing
it
onto
the
stack
and
when
we
return
from
functions
we
essentially
popping
it
off
the
stack.
We
can
think
of
a
stack
like
a
Pringles
container,
so
when,
when
you
see
over
the
Pringles
container,
when
the
Pringles
get
manufactured
and
basically
packaged
you
put,
the
first
Pringle
that
goes
in
is
the
last
one
that
you
take
out
and
eat.
A
So
we
have
access
to
this
old
stack
in
our
console
and
I'm
sure.
All
of
you
have
seen
it
it's
when
your
JavaScript
application
bombs
out,
which
is
for
me
pretty
often
we
can
step
through
the
stack
using
the
chrome,
dev
tools
when
we
get
the
error,
the
stack
is
halted
and
we
can
essentially
step
through
to
whatever
ledge
to
that
arrow.
A
A
A
Cool,
so
you
don't
need
to
worry
right
now
about
the
web.
Api
is
portion
and
the
callback
queue.
So
this
is
a
function
of
because
we're
only
talking
about
sort
of
synchronous
execution.
So
this
is
a
function
and
it
bit
what
it
does.
Is
it
composes
a
greeting
and
then
it
goes.
This
variable
isn't
actually
necessary,
but
it
goes
into
compose
greeting.
It
then
called
say
something:
nice
say
something,
nice
is
you
guys,
are
awesome
and
then
there's
a
console
log
and
that's
basically
what
it
does
so.
A
The
way
that
I
expect
the
call
stack
to
to
basically
execute
this
is
compose.
Greeting
is
the
first
function
that
it
basically
sees
and
it
puts
it
onto
the
stack,
so
it
pushes
it
onto
the
stack
compose
greeting
then
go
once
we
go
into
compose
greeting,
say
something.
Nice
will
get
cold,
one
say
something
nice
so
that
gets
pushed
onto
the
stack.
Once
we
go
into
say
something
nice.
A
It
actually
returns,
which
means
that
that's
our
first
popped
from
the
stack,
because
it's
synchronous,
JavaScript,
the
next
thing
that
gets
cold
is
console
dot
log
greeting
so
that
will
be
popped
onto
the
stack
and
it
will.
It
will
be
done
with
compose
greeting,
so
we'll
we'll
just
this
function
here
will
then
be
popped
off
the
stack,
so
I'm
gonna
run
it
quickly
and
I'm
gonna
have
to
pause
just
as
we
go
along
because
it
runs
very
fast.
So
you
can
see
compose
greeting
went
onto
the
stack
say
something.
A
Nice
was
the
next
thing
it
went
onto
the
stack,
it
will
then
be
removed
because
say
something
nice
got
executed.
So
as
soon
as
we
return
from
a
function,
it's
going
to
pop
off
the
stack.
The
program
continues
executing,
which
is
our
console
log
that
gets
pushed
onto
the
stack,
but
now
it
will
execute
so
it
should
pop
off.
A
So
there
are
some
errors
that
I've
encountered
that
I
didn't
really
understand
what
was
happening
behind
the
scenes,
but
now
I
do
the
most
common
one
is
the
Annoying
maximum
cool
stack
size
exceeded
and
then
your
browser
just
crashes,
and
it
tells
you
that
everything
is
just
unresponsive,
I
think
it's
what
Justin
was
talking
about
earlier.
So
what
actually
happens
behind
the
scenes?
Er
and
yes
JavaScript-
does
hate
infinite
loops.
A
A
So
that's
that's,
basically
how
that
error
occurs
and
there's
also
something
to
note
is
that,
depending
on
the
functions
that
you
are
executing,
that's
how
slow
or
fast
your
stack
might
execute.
So,
for
example,
a
console.log
will
be
really
snappy
and
quick,
but
something
like
a
loop
that
contains
multiple
lines
of
code
that
will
actually
take
a
little
bit
longer
to
execute.
A
So
since
javascript
is
single
threaded,
it
means
that
the
stack
can
not
execute
and
continue
until
a
function
returns
a
value.
Imagine
if
we
had
to
implement
something
like
network.
Imagine
if
we
had
to
get
data
from
an
external
server
and
we
were
implementing
it
synchronously.
What
would
end
up
happening
is
that
request
will
happen.
The
function
would
be
popped
onto
the
stack
and
say
if
the
server
that
we
connecting
to
is
really
really
slow
and
it
took
20
seconds
to
execute.
A
It
means
that
particular
function
would
remain
on
the
stack
and
not
allow
anything
else
to
execute
until
it
received
that
data
from
that
external
server.
This
would
be
extremely
painful
to
everybody,
and
this
is
where
we
bring
in
Ajax,
so
Atrix,
here's
a
callback
function
and
with
the
score
back
functions.
What
was
a
callback
function?
We
can
essentially
send
it
off
somewhere
and
once
it
gets
its
data
if/then
will
allow
the
it
will.
It
will
then
continue
rendering.
At
the
same
time,
it
will
allow
any
other
functions
that
are
rendering
to
continue
with
its
execution.
A
When
I
talked
about
synchronous
JavaScript
in
a
synchronous
context,
we
only
have
the
memory
heap
in
the
call
stack,
but
now
I've
introduced
three
other
components:
it's
the
web,
api's
the
callback
queue
and
the
event
queue.
So,
let's
go
into
detail
about
each
one
of
those,
so
with
api's,
essentially
executes
asynchronous
functions.
These
the
web
api's
are
provided
by
the
browsers
and
they
give
us
access
to
things
that
aren't
available
in
the
JavaScript,
so
things
like
the
dom
ajax,
timeouts,
etc.
A
So
when
the
stack
sees
a
function-
and
it
sees
that
it's
asynchronous
it,
then
it's
in
an
async
event
that
required
if
the
async
event
will
probably
require
one
of
these
calls
that
came
before
/
the
web
api,
the
browser
API
kicks
in,
and
it
calls
that
particular
elements
you
handle
it.
The
Web
API
uses
internals
to
get
what's
required
and
then
pushes
the
call
back
on
to
the
callback
queue.
A
So
it's
actually
what
the
Web
API
is
doing
is
when
you
call
a
function
in
your
script
and
if
it's
asynchronous
and
has
a
callback,
it
actually
needs
to
be
executed
by
the
Web
API.
The
Web
API
then
runs
this
portion
and
once
it
once
it's
run,
it
then
pulls
put
that
call
back
onto
the
callback
queue,
so
the
Cobra
queue
is,
it
can
be
called
message
queue
the
Kovak
you
the
task
queue.
They
also
refused
interchangeably
a
message
queue
we
can
think
of
almost
like.
A
You
know
any
queue
at
ShopRite
to
get
to
the
toll
in
to
pay.
So
it's
very
different
from
the
call
stack.
The
call
stack
wizard
is
like
a
Pringles
container,
the
last
in
first
out.
We
as
a
message
queue
is
first
in
first
out,
so
the
oldest
message
on
the
queue
will
be
the
first
one
that
is
sent
for
processing.
So
these
messages
are
actually
queued
up
with
risk.
In
response
to
the
async
events
there
are
executed
by
the
web
api
is
the
state
keeps
changing.
A
The
call
stack
keeps
changing
a
capacity
based
on
the
functions
that
are
being
executing
that
are
executing
and
that
are
returning.
So
when
stack
has
capacity,
the
callback
queue
of
the
message
queue
essentially
takes
the
message,
and
it
puts
it
onto
the
call
back
to
on
on
the
call
stack
to
be
able
to
execute
the
message.
Processing
is
actually
calling
the
callback
function.
It
ends
the
message.
Processing
portion
actually
ends
once
the
call
stack
is
once
the
call
stack
is
empty
again.
The
runtime
starts
handling
the
messages
on
the
queue
starting
with
the
oldest
one.
A
Each
message
of
Kobach
is
completely
processed
before,
and
next
a
new
one
can
actually
be
put
onto
the
stack,
so
they
vent
loop
when
I
think
of
the
event
loop.
I
think
of
the
out
surance
guys
that
staying
at
the
robot
and
the
direct
traffic
so
the
event
loop.
Essentially
what
it
does
is.
It
looks
at
the
call
stack
it
checks
if
the
call
stack
is
empty.
A
If
the
call
stack
is
empty,
it
sells
the
message
queue
of
the
Kovak,
you
hey,
the
call
stack
is
empty,
so
you
can
actually
take
a
message
and
we
can
process
it
onto
the
call
stack.
That's
what
the
event
loops
job
is.
So
it's
responsible
for
the
execution
of
the
callbacks
in
the
queue
and
pushing
it
onto
the
stack.
So.
A
A
Okay,
so
this
is
the
default
example
that
Philip
actually
puts
up
on
his
loop
application
and
the
way
this
works
is.
We
have
an
event
listener,
which
we
know
is
asynchronous
and
when
a
button
is
clicked,
this
particular
button
is
clicked.
It
then
goes
into
this
function.
In
addition
to
that,
we
have
a
console
log.
We
also
have
another
asynchronous
function,
which
does
a
set
timeout
and
finally,
there's
another
console
log.
So
the
way
that
we
expect
this
to
work
is
we
expect
the
console
log
to
go
onto
the
call
stack
because
that's
death
synchronous.
A
We
then
expect
the
set
time
out
to
also
go
onto
the
call
stack,
but
because
it's
asynchronous,
the
Web
API
will
need
to
give
it
input
on
to
set
timeout
so
set.
Timeout
will
then
go
to
the
Web
API.
It
will
then
run
for
five
thousand
milliseconds,
and
then
it
will
push
that
cool
back
onto
the
callback
queue
when
it's
unto
the
in
it.
On
the
Kovak
you
in
the
meantime,
the
console
logged
at
high.
It
will
not
stop
execution.
The
execution
will
continue
run
running
so
console
dot.
A
Log
high,
where
we
put
onto
the
call
stack
and
when
say
a
timeout
finally
comes
back
I
said
it
would
go
to
the
callback
queue
and
when
the
stack
is
empty,
that's
the
only
time
that
the
callback
you
will
actually
put
that
message
on
to
the
call
stack
so
the
way
this
will
run.
So
you
can
see
oops.
So
you
see
in
that
it
put
the
console
log.
It
then
put
the
set
time
out.
Sorry
put
the
on
pattern,
tick.
It
then
went
through
the
console
log.
A
A
So
that's
basically
how
it
works,
but
when
we
click
a
button
there
was
a
point
that
I
made
earlier.
That
said
that,
if
there
is
a
message
that
is
on
the
Kovac
you
and
now,
the
message
cannot
be
executed
and
pushed
to
the
call
stack
until
the
call
stack
is
empty.
So
we
see
that
we
have
two
set
timeouts
er.
The
one
set
timeouts
is
over
here
and
the
other
one
is
within
the
button
tick.
A
So
if
the
set
timeout
sorry,
this
bottom
set,
timeout
reiative
tick
button
is
being
executed
and
put
onto
the
call
stack
if
we
have
to
click
the
button.
While
this
is
happening,
it
will
first
have
to
wait
for
the
settimeout
to
execute
before
we
can
actually
execute
the
callback
within
the
button.
Click
set
timeout
and
one
of
the
things
that
I
learned
over
the
past
couple
of
weeks.
A
That
I
didn't
actually
realize
is
that
when
set
timeout
is
given
two
arguments,
the
first
one
is
the
callback
and
the
second
one
is
the
time
that
time
that
set
timeout
is
given
is
not
a
guarantee
time
for
the
timer
to
actually
run
it's
the
minimum
time.
That
it
will
be
executed.
It
will
be
the
minimum
time
that
the
Kobach
can
be
executed,
because
it
still
needs
to
wait
for
any
processing.
That's
happening
in
the
callback
you.
A
So
if
there
was
a
previous
set
timeout
that
was
running
and
that
took
five
seconds
five
seconds
and
if
the
next
one
is
put
onto
the
queue
and
that
will
run
in
two
seconds,
it
will
first
have
to
wait
for
the
five
seconds
from
the
first
set.
I
am
out
before
it
can
do
the
second
one.
So
it
has
to
wait
for
any
message:
queues
to
be
processed.
A
A
A
Now
that
we
understand
more
about
how
JavaScript
works
under
the
hood
I'd
like
to
cover
how
we
can
actually
use
this
knowledge
to
optimize
our
code
having
this
information
and
our
belt,
we
are
able
to
apply
techniques
to
our
code
that
sort
of
optimizes
it
for
the
runtime.
The
main
aspect
that
you
can
really
optimize
on
is
the
memory
management.
A
If
we
write
code
in
an
in
a
three,
we
want
to
write
code
that
ensures
that
we're
kind
of
setting
the
scene
for
the
garbage
collector
to
collect
all
these
objects
instead
of
just
leaving
them
lying
around
so
remember.
We
said
that
a
garbage
collector
is
essentially
aiming
to
reclaim
memory
up
memory
occupied
by
objects
that
are
no
longer
in
use.
So
the
one
thing
that
we
want
to
do
is
we
want
to
shoot,
ensure
that
the
objects
that
are
referenced
are
objects.
A
A
So
sorry,
so
these
are
all
the
things
that
we
can
do
in
order
to
optimize
for
the
runtime
and
I'm
gonna
walk
through
each
one
of
them
in
a
little
bit
of
detail
and
show
you
examples,
so
the
first
one
scoping
variables
appropriately.
So
we
all
know
what
scary
words
in
most
local
variables
global
variables.
A
The
way
it
works
is
that
global
variables
are
hoisted
to
the
top
whenever
an
application
starts
running
and
as
long
as
that
application,
as
long
as
the
page
is
open,
the
variable
that
is
scoped
to
the
global
object
will
remain
in
memory.
That
memory
will
never
be
reallocated
and
the
variable
will
never
be
collected
by
the
garbage
collector.
A
However,
when
you
scope
something
locally
and
we
can
use
now
with
es6
there's,
let's,
if
you
scope
it
locally,
scoped
variables
are
cleaned
up
as
soon
as
the
variable
falls
out
of
scope.
So,
as
soon
as
the
function
is
exited
from
or
there's
no
longer
a
reference
to
the
function,
it
will
then
fall
out.
It
will
then
get
cleaned
up
by
the
garbage
collector.
So,
for
example,
if
we
look
at
the
variable
value
blue,
there
exists
in
the
entire
app.
However,
it's
not
actually
necessary
to
exist
in
the
entire
path.
A
So,
for
example,
if
you
loading
a
script
in
an
application
just
once
off,
and
you
want
to
listen
for
a
load
event
and
do
something
once
off,
you
don't
want
that
event
listener
to
persist
or
throughout
the
lifecycle
of
your
application,
so
by
default
the.
So
if
we
look
at
this,
this
function
over
here
this
bottom,
one
that
says
setup
listeners
will
see
that
we
have
variables
a
variable
called
data,
and
then
we
have
an
event
listener
on
the
window.
A
That
figures
out
when
it
that's
basically
lessons
output
when
it
loads,
and
then
we
do
something
with
that
data.
Okay,
so
by
default
that
load
event,
listener
will
remain
in
the
remaining
scope
when
it
finishes
running,
even
though
it's
never
used
again
and
because
the
data
a
variable
is
used
within
that
callback.
That
will
also
never.
There
will
also
always
remain
in
memory.
It
will
both
these
via
the
variable
data,
as
well
as
the
event
listener
will
never
be
garbage
collected.
A
However,
if
the
callback
were
removed
via,
if
you
see
on
top
with
your
removed
eventless
now,
if
it
was
removed
via
the
FI
using
remove
event
listener
or
even
using
the
ones
true
property
which
you
can
see
in
the
second
block,
then
the
data
variable
as
well
as
the
event
listener,
would
be
a
potential
candidates
for
garbage
collection,
so
clean
cleaning
up
your
event.
A
Angeles
can
offer
huge
memory
efficiency.
However,
some
modern
browsers
would
do
the
job
for
you,
I
mean
they
know.
A
However,
in
some
past
browsers,
we
were
they
were
unable
to
handle
these
cases
and
yes,
I'm,
looking
at
you
good
old
internet
explorer,
so
the
next
technique
that
we
can
use
is
to
be
able
to
clean
up
local
caches
or
you
use
a
tuning
mechanism,
and
this
is
pretty
simple:
I
mean
if
you
have
data
that
you're
storing
locally,
and
you
no
longer
need
it.
You
should
probably
clean
it
up.
A
The
next
one
is
around
closures.
So
when,
when
we
use
closures,
we
just
need
to
make
sure
that
we
are
accessing
the
variables
correctly
and
then
we
don't
leave
variables
lying
around
so
that
the
garbage
collector
counts
are
coming
and
clean
it
up.
So
if
we
look
at
this
example,
we'll
see
that
we
cannot
access
large
string
via
a
so
there's
two
variables.
First
of
all,
there's
a
variable
called
small
string,
and
then
this
variable
called
large
string.
A
Large
string
isn't
used
in
this
F
in
in
this
particular
program,
but
it's
just
for
as
an
example.
So
large
string
can
not
be
accessed
via
a
and
hence
it
will
be
garbage
collected,
but
because
small
string
is
being
a
can
be
accessed
via
a
it
will
not
be
garbage
collected.
So
the
I
think
the
premise
of
this
is
that
we
should
always
declare
our
variables
based
on
whether
we
actually
need
them
to
be
global
or
whether
we
need
them
to
be
local.
Within
this
closures,
the
last
one
is
out
of
Dom
references.
A
A
It
contains
button
and
image
and
you
can
see
it
references
the
Dom
and
then,
if
we
look
at
the
bottom
function,
which
is
remove
image,
we
can
see
we
going
through
the
document
body
and
we're
removing
the
elements
image
by
its
ID.
So
we've
got
two
references
to
this
image
right.
We've
got
the
reference
in
remove
image
and
then
we've
got
the
reference
at
the
top
in
elements.
So
when
we
eventually
remove
the
image
in
the
function,
remove
image
that
reference
in
elements
actually
continues
loving
on.
A
It
doesn't
know
that
that
that
element
was
removed
and
because
it
scoped
as
a
global
variable,
it
will
remain
in
memory,
even
though
it's
completely
unnecessary
and
the
Dom
has
already
removed
that
element.
So
it's
important
to
ensure
that
you
make
both
references.
It's
important,
that
if
you
decide
to
get
rid
of
a
Dom
element,
you
need
to
remember
to
make
both
references
unreachable.
A
A
So
I'm
not
gonna,
say
that
all
of
you
guys
just
go
home
today
and
rewrite
all
the
code
that
you
ever
wrote
in
fact,
I'm
going
to
say,
take
step
or
take
one
step
at
the
time.
If
you
see,
if
you've
noticed
over
the
past
couple
of
months
or
even
years
that
your
application
is
running
a
little
bit
slower
than
you'd
like
it
to
there
are
some
tools
out
there
that
you
can
really
use
to
identify
your
performance
issues,
so
some
of
them
I'm
a
big
fan
of
Google
Chrome.
A
So
the
first
one
is
the
timeline
panel
and
the
timeline
panel
is
on
the
extreme
left,
the
timeline
panel
records
and
analyzes
all
activity
in
your
application.
As
it
runs,
it's
the
best
place
to
start
investigating.
If
you
have
perceived
performance
issues,
it
gives
you
stats
for
things
like
you
compile
times
your
pause
times
and
lots
of
data.
A
The
second
one
is
the
heap
profiler
and
that's
basically
a
profile
to
the
memory
distribution
amongst
your
pages
with
respect
to
the
JavaScript
objects
and
the
Dom
elements,
and
finally,
the
allocation
profiler,
and
this
combines
the
detailed
snapshot,
information
of
the
heap
profiler,
with
incremental
updating
and
tracking
of
the
timeline
panel.
It
uses
the
profile
type
to
isolate
memory,
leaks
by
not
writing
code.
There
is
not
optimal
and
performant
and
efficient.
We
risk.
We
run
the
risk
of
users
becoming
frustrated
with
our
applications.
A
A
Personally,
as
a
developer,
I
can
attest
to
that
I
think
it
takes
me
less
than
three
seconds
to
navigate
away
from
a
page,
but
there's
been
times
when
I've
loaded
up
in
application
and
it's
taken
a
little
bit
long
to
load
and
because
I
have
a
very
short
attention
span.
I've
now
moved
to
another
tab
and
I've
completely
forgotten
about
the
window.
A
That's
loading
up
in
another
tier,
so
it's
important
to
have
good
performance
on
your
application
and
I
think
by
leveraging
our
knowledge
about
the
JavaScript
engine,
we
can
really
increase
the
performance
on
applications
and
other
stats
is
that
one
out
of
two
people
expects
a
page
load,
a
page
to
load
in
less
than
two
seconds
and
I
hope.
This
is
the
JavaScript
engine
after
this
presentation.
A
So
in
conclusion,
the
JavaScript
engine
that
I
walked.
You
through
is
a
very
small
part
of
a
much
much
much
bigger
picture,
there's
so
many
fascinating
aspects
about
the
JavaScript
engine
that
keeps
me
engaged
and
so
many
fascinating
aspects
about
the
language
that
keeps
me
engaged
and
I'm
hoping
that
I've.
Given
you
something
to
sort
of
think
about
for
the
next,
however
long
you
using
javascript
and
that
my
friends
is
JavaScript
under
the
hood.
Thank
you
very
much
for
listening
to
me.