►
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).
B
A
A
Not
on
the
URL,
the
sidebar
doesn't
seem
to
be
updated.
Understanding,
client-side
web
development
tools.
I
actually
approached
Remy
sharp
to
write
this
because
I
thought
he
knows
that
stuff
pretty
well
and
I
know
him
fairly
well,
and
he
would
probably
do
a
good
job
of
right
now.
So
I'm
not
going
to
go
for
every
one
of
these
in
great
detail.
Albert.
You
know
we
have
client-side
tooling
overview,
which
sort
of
takes
you
through.
You
know
what
are
all
the
different
classifications
of
tool
you
might
use.
We
we
split
it
in
two
and.
A
Safety
net
as
Remy
calls
it
or
or
basically
you
know,
tools
that
help
you
to
code
more
efficiently
and
more
effectively
and
the
second
top
kind
of
classification
we
have
is
transformation
tools,
so
things
like
build
tools,
free
processes,
all
of
that
kind
of
stuff,
and
then.
Thirdly,
we
have
post
coding
tools,
including
things
like
deployment
and
testing.
A
These
days,
they
all
seem
to
just
assume
that
you
know
the
command
line,
whereas
a
lot
of
young
folk
coming
up
into
this
industry-
probably
don't
so
much
so
that's
real
basics
of
command
line
which
management.
Basically,
you
know
how
to
use
NPM
and
yarn
to
do
interesting
things.
What
the
pointed
package
managers
is,
etc,
etc,
how
to
use
one
at
the
basic
level,
and
then
we
introduced
a
complete
tool
chain
which
basically
provides
a
very,
very
simple
react.
App.
A
It
uses
post
CSS
to
use
a
couple
of
features
that
are
actually
in
the
browser,
yet
it
uses
pass
or
to
do
the
build.
It
uses
es
lint
and
prettify
to
do
a
couple
of
useful
kind
of
codes,
caring
type
things,
and
then
we
use
github
to
send
it
up
to
a
repo,
and
then
we
deploy
that
onto
a
necklace
I
instance.
A
So
it's
just
like
a
nice
sort
of
simple
well
I,
say
simple:
it
doesn't
seem
that
simple
to
me,
but
and
it's
a
nice
simple
kind
of
ten
thousand
foot
walk
through
of
the
sort
of
stuff
that
you
should
be
able
to
do
with
web
tools.
Then
I'm
kind
of
thinking.
Well,
let's
keep
it
relatively
generic
and
not
and
include
as
little
as
possible
stuff
about
the
actual
tools
so
but
it'll
be
simpler
to
keep
maintained
and
keep
actually
working.
A
So
that
was
that
and
then
I
was
very
quickly
gonna
into
you
to
the
other
bit
that
I've
got
available,
which
is
the
framework
section,
so
understanding,
client-side,
JavaScript
frameworks
so
again,
JavaScript
frameworks
is
such
a
big
deal
these
days
that
I
thought
well.
This
probably
deserves
several
modules
by
thought.
Well,
let's
just
produce
one
module
to
begin
with
just
to
kind
of
dip,
our
toes
in
the
water
and
say
you
know:
let's
see
how
successful
this
is
and
then
what
people
ask
for
later
and
then
we
can
always
add
more
later
on.
A
So
the
idea
here
was
I've
got
a
couple
of
introductory
guides,
that
kind
of
say:
okay
as
an
aspiring
web
developer,
who
probably
knows
a
bit
of
vanilla
JavaScript?
Why
bother
to
learn
frameworks?
On
top
of
that?
How
do
they
relate
to
vanilla
JavaScript?
Why
do
they
exist?
What
problems
that
they
actually
solve
and
that
modern
apps
require
and
the
native
platform
has
a
bit
of
trouble
with
sometimes
what
general
kind
of
features
do
all
frameworks
tend
to
have
and
had
they
all
work
together?
A
When
should
you
use
a
framework?
When
should
you
not
use
a
framework,
which
is
another
important
thing
there?
You
know
you
don't
really
get
with
a
lot
of
framework
vendors
documentation,
it's
just
basically
a
framework
is
great,
so
use
it
for
everything.
This
is
wonderful
kind
of
thing,
I've
never
been
all
like
that,
but
a
lot
of
them
tend
to
so
I
want
to
provide.
You
know
as
neutral
of
you
as
possible,
but
kind
of
says.
You
know,
let's
step
back
a
bit
and
ask
why
or
when
you'd
even
use
this
stuff.
A
So
with
those
bits
out
of
the
way
in
the
first
two
articles
there
I
then
provide
I
originally
intended
this
to
be
a
fairly
simple
kind
of
walkthrough
of
the
real
basics
for
each
framework
and
like
an
article
or
so,
but
I
very
quickly
realized
that
frames
do
so
much
ever
so
complicated
that
you
can't
really
explain
even
the
basics
just
in
a
single
article.
A
So
we
ended
up
with
quite
a
few
articles
about
react
covering
all
the
main
sort
of
parts
covered
ember
as
well,
because
that
still
seems
to
be
and
fairly
popular
covered
view,
because
the
is
really
cool
and
it
seems
to
be
up
and
coming.
We
also
wanted
to
cover
angular,
because
I
think
from
the
last
time,
I
looked
at
the
stats.
A
Angular
seems
to
be
the
sort
of
the
second
most
used
framework
still
luxuriant,
but
I
couldn't
well
I,
had
a
few
office
snafus
and
offers
dropping
out
and
in
the
end,
I
just
ran
out
of
time,
but
we
want
to
it.
We
want
to
cover
react
later
on
and
then
after
I
published
this
stuff
Sebastian
scurry,
and
they
approached
me
and
said
he'd
love
to
provide
a
course
about
swell
basics.
A
But
I
also
thought.
Well,
let's
cover
a
smaller,
more
up-and-coming
one.
Just
to
kind
of
you
know
give
a
little
bit
of
fairness
to
the
small,
the
smaller
frameworks
and
and
something
I
mean
I've
already
had
a
bit
of
abuse
about
this
online,
which
is
inevitable
there
and
I
have
included
this
big
section
here,
which
is
which
frameworks
did
we
choose
because
I
kind
of
thought?
A
Well,
it's
difficult,
but
whenever
and
I'll
just
stop
sharing
a
second,
but
when,
whenever
we
cover
anything,
that's
not
pure
web
technologies
and
MD
and
we
tend
to
get
abuse
because
it's
like
MD
and
it's
supposed
to
be
the
neutral
place
to
go
and
learn
about
web
standards.
And
how
dare
you
cover,
react
and
stuff?
Are
you
just
a
facebook,
shill
rah
rah
rah,
rah
rah?
A
And,
what's
on
your
sign,
that's
like
well,
no
I,
literally
just
wanted
to
choose
a
variety
of
a
few
frameworks
so
that
beginners
had
a
place
to
at
least
start
because,
of
course,
you
know
it's
all
well
and
good.
Explaining
generally
what
framework
features
do,
but
really
you
can't
learn
about
them
without
showing
a
specific
example,
and
for
that
you
have
to
show
a
specific
frame.
Look
so
so
yeah,
that's
kind
of
the
first
part
of
my
talk
done
and
the
reason
that
I
was
referring
to
the
the
issue
where
I
delivered
my
talk.
A
Information
is
basically
the
there's
a
bit
there
that
says
to
solicit
feedback.
You
can
either
fill
in
a
questionnaire
or
write
some
freeform
feedback
on
a
Google
Doc
link,
I've
provided
or
you
can
tweet
me
an
email
me
so
and
if
there's
any
feedback
you
have
about
this
stuff
after
the
session
that
you
forgot
to
mention
then
feel
free
to
put
it
in
one
of
those
places.
But
I
know.
Where
did
any
of
you
folks
have
any
questions
like
this
stuff
or
any
feedback
to
share
immediately.
A
B
A
B
Like
first,
of
course,
you
would
need
a
version
of
this
like
you
would
need
versioning
and
a
distribution
method
for
this,
but
also
what's
more
important
is
like
it.
I
would
like
to
see
in
an
IDE
that,
if
I
have
this
JavaScript
method-
and
this
is
a
promise
like
if
in
typescript
there
is
a
promise
popping
up
that
I
could
see
more
information
about
you
know
in
dev
documentation
or
articles
around
it
immediately,
while
I'm
editing
without
the
round
trip
to
the
browser.
Well,.
A
I,
that
is,
that
is
a
very
good
bit
of
feedback,
and
it's
not
the
first
time.
I've
heard
it
and
I
do
have
some
kind
of
interesting
news
on
both
fronts:
release
of
the
first
really
it's
kind
of
being
unpacked
I
can
unpack
this
into
two
questions.
Really
the
first
one
is,
you
know:
can
we
have
an
offline
version
of
mdn
available
to
you
so
that
we
don't
have
to
keep
loading
up
in
the
browser
and
the
second
one?
Really?
What
you're
saying
is?
A
Is
there
some
way,
but
I
can
have
kind
of
mdn
information
popping
up
inside
an
IDs?
What
I
have
even
have
to
leave?
It
I
think
that's
both
points
pretty
much
cupboards
in
there
and
so
for
the
first
one.
We
have
been
asked
about
whether
we
can
have
an
offline
mdn
a
few
times
before,
and
that's
my
first
question
is
kind
of.
B
Since
the
formatting
is
in
HTML
at
least
the
content
wouldn't
need
to
be
named
tml,
but
it
should
be
semantic
eNOS,
I'm,
not
sure
if
it
is
feasible
in
Visual
Studio
code,
just
pop
up
an
iframe
and
you
know,
drop
the
resources
in
a
step.
I'm
also
not
sure
how
resize
properties
work.
You
know
if
it.
If
you
have
to
documentation
in
a
sidebar
of
the
IDE,
the
the
layout
should
work
for
that.
B
So
they
might.
It
might
be
a
good
idea
to
have
a
semi
semantic
version
or
like
an
advanced
HTML
mode,
where
you
can
maybe
pass
it
in.
You
know,
through
the
hash
parameter
of
the
HTML
site,
you
can
pass
in
some
visualization
hints
where
you
can
say
that,
like
okay,
please
use
this
in
dark
mode
now
or.
A
B
Importantly,
like
broad
information
or
thin
information
mode,
something
like
that
I
would
not
be
looking
for
a
completely
devoid
of
branding
things.
I
would
be
okay
with
branding
I
would
be
okay
with
the
Mozilla
logo
being
in
there
and
stuff.
Like
that,
fine,
it's
just
a
deep
linking
is
important.
You
know
like
that.
I
can
inside
the
code
like
if
link
and
and
see
like
one
example
for
how
it
would
be
cool
in
the
ID.
B
A
And
so
I
have
even
better
news
kind
of
on
that
front.
So
just
this
week
I
saw
one
of
the
MV
end
developers
and
Gregor
who's
based
in
our
Berlin
this
and
was
playing
around
with
an
idea
of
being
able
to
just
pull.
You
know,
pull
up
mdn
data
kind
of
anywhere.
You
know
bail
the
ultimate
idea
that
he's
working
on
is.
A
Could
we
present
all
of
the
mdn
content
is
basically
like
a
query
queryable
api,
so
you
can
just
bring
it
up
anywhere
that
you
can
access
it,
that's,
ultimately
what
all
the
ones
waiting
for
now
at
a
moment,
that
would
be
a
bit
painful
because
all
of
the
NBN
data
is
contained
in
a
my
sequel
database
and
all
the
vm
content
should
I
stay.
So
it's
not
really
structured
content.
It's
just
big
blobs
of
stuff
inside
my
sequel.
A
So
at
the
moment,
we'd
probably
have
to
do
some
kind
of
scraping
of
the
pages
as
we
queried
and
I'm
not
sure
how
yeah
the
performance
would
be
on
that
I
suspect.
Probably
it
wouldn't
be
great
and
there'd
be
a
lot
of
troubles
of
doing
that,
but
I
mean
he
is
investigating
that
to
start
off
with
now,
the
good
bit
of
news
is
around.
A
The
corner
is
coming
probably
end
of
this
year
start
of
next
year
and
we're
gonna
happen
again
available
in
a
github
repo
and
I'm
moving
out
of
the
my
sequel
database
and
we're
aiming
to
represent
the
content
in
a
github
repo.
Initially,
that
would
be
HTML
files
and,
of
course,
if
it's
just
flat
files
and
sat
there
available
like
that,
it
might
be
a
bit
easier
to
query.
But
what
were
ultimately
aiming
to
do
is
we're
aiming
to
turn
it
into
structured
markdown
and
some,
like
three
members
of
my
team,
are
already
working
on.
A
Writing
the
schemas
writing
the
recipes
writing
a
linter
to
lint
all
the
content
pages,
and
you
know
fixing
the
errors
to
make
sure
that
all
the
pages
are
totally
consistent
and
then,
when
we
turn
it
into
the
Martin
content
and
plus
metadata
to
actually
organize
the
content.
This
is
the
point
when
we
should
be
able
to
start
doing
this
a
lot
more
easily.
So
it's
a
little
way
off,
perhaps
but
we're
already
looking
into
this
we've
we've
already
come
into
contact
with
this
whole
idea.
A
Wouldn't
it
be
great
if
you
can
just
query
all
of
mDM's
content
as
structured
data
and
just
pull
it
where
you
need
it?
So
that's
what
we're
aiming
towards,
of
course.
At
that
point,
if
we
could
get
it
into
that
state
and
anybody
could
just
write
plug-ins
for
their
favorite
IDs
using
it
or
web
extensions
or
whatever
they
want,
so
that's
kind
of
where
we're
going
with
one
as.
B
Developer
of
my
own
modules
are
things
I
need
to
invent
the
wheel
reinvent
the
wheel
when
it
comes
to
documentation
and
if
and
Iain
would
manage
it
too.
You
know
like
have
a
big
fancy
collaboration
with
typescript
that
would
kind
of
lead
the
way
towards
other
tools,
also
being
able
to
use
the
same
documentation
concept
in
theirs.
So
let's
say
if
the
MDM
would
provide
a
general
purpose.
B
You
know
surface
layer
for
for
documentation
for
advanced
documentation
for
things
or
additional
documentation
on
things
like
conceptually
speaking
for
me,
MDM
is
you
have
a
concept
of
promise
and,
yes,
a
promise
can
be
explained
very
briefly
as
a
very
easy
sort
of
thing,
but
it
adds
these
facets
to
the
documentation.
It
gives
more
information,
it
gives
more,
it
explains
it
well,
there
are
some
nice
examples
and
stuff
like
that.
B
So
it's
like
you,
have
this
raw
documentation
that
is
usually
coming
from
the
developer
and
you'd
have
an
additional
layer
of
documentation
that
come
can
come
on
top
of
it,
and
that
is
true
for
pretty
much
any
project.
Doesn't
matter
what
like,
if
you're
writing
code
you,
the
developer,
might
do
the
initial
bit
of
documentation
and
somebody
might
doing
a
top
of
bit.
B
A
I
mean
that
would
be
amazing,
like
we
all
of
the
stuff
that
we
provide
is
generally
under
permissive
licenses
and
and
we'd
like
to
give
it
all
back
at
the
end
of
the
day.
So
if
we
could
provide
that
sort
of
layer
made
generic
enough
so,
but
it
could
be
used
for
any
jobs
project
that
would
be
brilliant,
I
mean
I'm.
I'm,
probably
gonna
get
go
back
to
our
developers
and
share
this
with
them
to
give
them
a
bit
of
an
idea
of
God
and
of
how
much
further
we
could
go
with
it.
A
A
Yeah,
what
I
was
thinking
is
we
only
have
about
five
minutes
left
and
I
think
we
need
to
rush
onto
and
the
verb
I
think
there's
another
call
going
on
after
that,
but
I
mean
I.
Don't
really
have
time
to
discuss
now.
The
second
bit
of
what
I
was
going
to
discuss,
let's
go
on
to
a
couple
more
questions
and
fill
up
the
rest
of
the
time.
That
way,
so
do
you
want
to
give
me
an
AFOL?
Oh.
B
Sure,
okay,
the
other
question
that
I
had
is
about
translation.
I,
have
a
deep
interest
in
translation
and
I
have
worked
at
a
project
that
does
a
lot
of
translation.
So
just
brief.
Beckenham
yeah
I
was
a
big
organized
at
note
school.
We
did
two
tutorials
for
note
and
they
were
translated
in
many
languages
as
though
not
as
many
as
MDM,
but
we
were
struggling
with
this
concept
of.
B
There
is
code
in
our
documentation
that
should
be
equal
in
all
in
all
languages,
and
there
is
text
in
those
documentation
that
is
not
equal
like
we
have
updates
to
our
tools
where
we
say
like
okay,
we
need
to
update
the
code.
Example
it's
broken
and
then
all
the
translations
would
need
an
update.
But
if
there
is
only
like.
B
Informal
piece
of
text
wrong,
or
it
explains
it
if
you
know
like
badly
in
one
language
and
well
in
another
language.
We
only
need
to
update
that
language,
so
there's
some
responsibility.
That
is
only
for,
let's
say
the
Japanese
be
current
or
something
that
is
more
general
and
I
was
wondering
how
you
figured
out
to
make
this
process
like
smooth
like
if
you
notice
that
there
is
an
update
in
code
that
effects
all
the
translations
that
you
like
get
to.
Let
them
know
that
it
works
and
if
there
is
like
you
know,
like.
B
A
So
the
answer
I'm
gonna
give
you
here
is
probably
gonna.
Be
quite
disappointing.
Really
I
mean
yes,
we
do
do
translations,
but
what
I
find
is
I
mean
in
in
terms
of
purely
the
technical
problem,
you're
discussing
what
we
tend
to
do
is
we
just
have
the
English
version
written
first
and
then
we
offer
the
service
where,
if
you
want
to
create
a
translation
of
that,
you
click
on
the
languages
drop-down,
you
click
add
a
new
translation.
A
A
So
if
you
look
at,
for
example,
our
interactive
examples,
which
is
the
little
editable
examples
that
you
see
at
the
top
of
all
of
the
JavaScript
reference
pages,
these
days,
they're
all
contained
in
a
github
repo
and
generated
when
the
static
pages
are
generated,
so
they're
kept
there
they're
there
they're
kept
consistent
regardless
of
the
language
and
and
then
we
have
some
others
too,
but
it's
by
no
means
consistent.
Yet
this
is
another
huge
problem.
The
the
main
problem
that
we
have
is
we
don't
really
have
any
management
structure
that
does
the
translations
properly.
A
B
Yeah
maybe
like,
if
you
know
like,
if
you
were
halfway
up
the
mountain,
you
still
see
the
rest
of
the
top,
but
if
you're
at
the
bottom,
anybody
at
least
half
at
the
mountain
knows
a
lot
more
than
you
do.
I
guess.