►
From YouTube: How We (Manage) Do Vue - Manage 201
Description
The Manage team at GitLab is giving talks to share knowledge on particular topics. The aim is to make it easier for others to contribute, both within the team and beyond
This presentation will provide an overview on how Frontend development with JavaScript happens on the Manage team at GitLab, and how we are working to utilize Vue.js and our new design system as much as possible. It will cover the various "layers" of legacy frontend code that we have, and the various effort costs and strategies we use to continue to ship features while addressing technical debt.
Slides can be found at https://docs.google.com/presentation/d/1l1hRhEo4zgmkW7QPgz4OLpP69PHhxjABnAzdpl_-E9g/edit?usp=sharing, and be sure to check out https://gitlab.com/gitlab-org/manage/issues/9 for details of upcoming 201 sessions.
---------------
Read more about our product vision: http://bit.ly/2IyXDOX
Learn about FOSS & GitLab: http://bit.ly/2KegFjx
Get in touch with Sales: http://bit.ly/2IygR7z
A
Just
make
sure
the
recording
is
on
this
is
my
first
recorded
sim
call
so
hi,
YouTube
or
whoever's
watching
this.
So
this
is
gonna,
be
fun,
share
my
screen
and
then
we
should
be
good
to
go
thumbs
up.
You
can
see
my
slides
awesome,
so
I'm
just
getting
chat
open
just
in
case
you
know
what's
chiming
there,
but
yeah
so
welcome.
A
It's
gone,
that's
a
little
bit.
Well,
it's
this
floppy
way:
I'm
Dennis
I'm,
the
front-end
engineering
manager
for
managing
growth
and
I've,
been
at
gate
lab
since
March.
As
you
can
probably
indicate
from
my
contribution,
breath
and
I'm
here
to
talk
to
you
about
the
next
JavaScript
family.
Kick
it
lab.
A
Second
of
every
month,
sorry,
but
the
title
doesn't,
as
you
can
tell
really
flow
and
Liam
actually
suggested
that
the
title
be
how
we
do
UJS
long
before
I
even
put
this
presentation
together,
but
it
actually
kind
of
evolved
backed
into
that
title,
because
really
what
we're
gonna
talk
about
is
how
the
manage
team
uses
UJS
and
kind
of
the
challenges
we
encounter
developing
on
the
front
end
as
well
as
kind
of
some
workflow
improvements.
We've
made
to
kind
of
make
that
a
little
bit
of
an
easier
process.
A
This
is
not
your
typical
manage
201.
This
will
really
be
covering
any
specific
feature,
but
just
funnin
in
the
context
of
manage
at
github
it's
a
little
bit
of
a
kind
of
end
of
your
retrospective
for
the
team
as
well
as,
in
addition
to
it
being
a
little
bit
of
my
experience,
summary
of
my
experience,
Sekulow
and
hopefully
any
audience
will
find
this
somewhat
useful.
A
I
think
for
front
ends
especially
onboarding
front
end
routes,
there'll
be
a
lot
of
tips
and
things
that
we
kind
of
discovered
that
I
wish
I
could
kind
of
known
a
little
bit
earlier
when
I
started.
That
is
not
always
so
documented
and
but
also
be
useful
for
project
managers.
You
Xers
and
pretty
much
anyone
inside
or
outside
of
get
lab
into
getting
some
insight
on.
A
Our
agenda,
for
today
is
we're
gonna
go
over
a
brief
history
of
Frontenac
at
web
feature
costs
how
to
identify
them
with
some
examples,
as
well,
estimating
fun
and
work
some
of
the
challenges
we've
had
some
of
the
improvements
we've
made
to
try
to
break
things
down
in
terms
of
deliverable
scope.
What's
next
for
manage
front
end
and
maybe
get
into
some
questions,
please
feel
free
to
jump
in
at
any
point
in
time.
A
If
you
have
a
question,
I'm
happy
to
chat,
and
it
would
be
awesome
to
have
this
more
of
a
conversation
and
for
the
fun
dinners
that
are
on
the
call
feel
free
to
jump
in,
add
some
context
or
maybe
correct
me.
Any
errors
I
may
have
made
so
jumping
into
it.
A
brief
history
on
lab
at
sorry,
a
brief
history
on
fun
and
I
get
lab.
Where
do
we
come
from?
A
Where
are
we
going
so
further
that
aren't
familiar
get
lab
was
built
with
Ruby
on
Rails,
which
came
included
with
CoffeeScript
and
jQuery,
and
so
CoffeeScript
solved
a
lot
of
issues
with
ACMA
script.
Four
or
five
we're
in
a
question
really
wasn't
pulling
its
weight,
and
so
it
really
just
was
there
at
the
right
tool
at
the
right
time,
but
since
the
introduction
of
equity
of
2015
and
2016,
and
so
on,
I
think
they're,
now
just
known
as
the
yearly
versions
or
es6
radius
own.
A
In
addition
to
CoffeeScript,
where
we
have
inline
JavaScript,
where
it
served
its
purpose
for
small
interactive
features,
but
can
be
very,
very
difficult
to
manage
when
you
have
a
more
complex
application
or
some
interactivity
that
needs
to
happen
on
the
same
page,
that's
not
to
say
that
we
don't
need
inline
JavaScript
from
time
to
time,
we'll
dive
a
little
bit
more
into
that.
But
it
you
can
immediately
see
when
you
have
this
javascript
next
to
a
giant
page
template
how
this
can
be
quite
difficult
to
manage.
A
Once
you
get
into
more
a
single
page
applications
with
handling
a
lot
of
state
and
as
part
of
our
migration
from
CoffeeScript,
we
ran.
We
just
completely
compiled
everything
from
CoffeeScript
to
atmospheric
v,
since
when
you
actually
run
CoffeeScript,
that's
what
a
transpose
down
to
so
we
just
had
a
mix
of
jQuery
and
JavaScript
and
actor
script
5.
So
the
thing
the
nice
thing
was
that
there
was
a
clean
migration,
there's
no
broken
tests
because
literally
functionally
and
nothing
has
changed.
A
A
Additionally,
we
have
another.
Actually,
so
just
to
recap,
CoffeeScript
is
gone.
Inline
javascript
is
mostly
gone.
We
still
have
some
cases
where
we
still
need
that,
but
all
of
our
code
exists
as
jquery
actor
script,
six
or
view.
Now
there
are
still
areas
of
our
code
base
that
are
a
mix
of
handle
and
jQuery
and
that's
not
necessarily
a
bad
thing.
A
We
like
Hamel,
it's
kind
of
the
intersection
of
the
front
end
and
back
end
where
a
lot
of
the
backend
data
that
we
need
right
now
is
fed
through
as
handle
or
HTML
attributes
that
get
fed
into
our
JavaScript
and
view
applications.
Now
we
do
want
to
get
rid
of
jQuery,
but
there
are
some
strings
attached
to
that.
We
do
have
some
downstream
dependencies,
such
as
select
too
and
I.
A
Let's
move
on
so
this
is
getting
more
into
the
workflow
thing:
I
want
to
talk
about
fee
tree
costs
and
how
to
spot
them,
but
first
what
are
future
costs?
They
are
things
that
can
cause.
They
can
add
to
an
issues,
weight
and
influence
our
ability
to
deliver
on
them.
So
what
do
I
mean?
This
is
actually
one
of
my
deliverables
that
was
merged
into
eleven
six,
but
you
can
see
these
red
little
labels
here.
A
So
it's
more
specifically,
it
can
be
things
like
technical
debt,
cross
team
dependencies,
unfortunate
foreseen
requirements,
things
that
we
may
not
have
discovered
until
halfway
through
the
issue
and
maybe
a
disparity
between
how
our
open
source
edition
works
versus
our
source,
available,
edition
works
and
maybe
unaccounted
features
that
may
exist
that
we
haven't
accounted
for
when
we
were
working
on
it
and
see
so
earlier,
I
said
we're
moving
to
Vijay
s,
but
we
need
to
be
more
pragmatic
about
it.
So
what
does
that
actually
mean?
A
So
we
always
want
to
scope
things
as
a
minimum,
viable
change,
so
they're
moving
the
Vijay
s
is
very
important,
but
we
have
to
make
sure
that
we're
not
refactoring
for
the
sake
of
refactoring
and
choosing
to
refactor
II
can
really
add
to
our
ability
to
be
able
to
deliver
on
the
future
and
we
want
to
get
there.
But
we
have
to
also
continue
to
deliver
value
and
deliver
features
to
it
to
our
users.
A
So
some
strategies
when
we're
evaluating
deliverables
can
I
have
so
here
and
hopefully
it's
a
little
bit
easy
to
read
it's
kind
of
cause
and
effect.
So,
looking
at
something
and
thinking
back
to
our
layers
of
JavaScript
and
front-end,
if
we
are
just
doing
simple
table
listings
or
empty
states,
then
we
can
just
really
keep
it
simple
and
just
stick
with
Ruby
and
Hamel
and
there's
really
no
JavaScript.
That's
involved
there.
If
we
need
interactivity,
then
we
need
to
figure
out
what
layer
are
we
working
with
what
layer
of
JavaScript
it
does?
A
A
Then
it
makes
sense
to
convert
it
to
view
and
of
course,
if
you're
managing
state
across
components-
and
it
gets
a
little
bit
more
complicated
and
you're
dealing
with
state
across
components,
then
it
makes
sense
to
add
on
UX,
but
a
couple
of
things
to
keep
in
mind
when
we're
working
on
these
front-end
features
is
to
minimize
the
use
of
jQuery.
We
want
to
get
away
from
it.
We
don't
really
need
it
as
much
as
we
do
any
more,
and
so
we
should
always
try
to
prefer
a
bit
of
JavaScript.
A
A
Examples
of
feature
costs,
I'm
gonna,
go
over
a
couple
of
deliverables,
completed
and
ongoing
with
manage
that
kind
of
speak
to
the
way
we
have
to
kind
of
evaluate
these
these
deliverables
and
how
we
kind
of
approach
them
and
there's
some
lessons
learned
as
none
of
them.
Not
all
of
them
are
the
greatest
examples
of
estimating
and
breaking
down.
A
So
the
first
one
is
the
project
list
UI
redesign,
so
we
wanted
to
take
our
existing
project
list
and
give
it
a
little
bit
more
data
a
little
bit
more
interactivity
and
also
just
make
it
look
a
little
bit
nicer.
So
looking
at
this,
we
know
that
we
have
this
data
before,
because
we
have
these
in
our
project
overview,
we
can
see
that
we
have
a
star
control
which
already
exists.
So
if
we
look
at
this,
we
can
tell
that
is
the
data
there.
A
You
know
we
check
it,
make
sure
that
it's
available
and
we
can
surface
it
through
our
Hamilton
plaits,
make
sure
there's
no
head
back
in
dependency
that
we
need
to
do
to
actually
get
that
data,
but
overall
there's
no
new
functionality
that
isn't
present
elsewhere.
So
our
result
is
that
we
only
really
need
to
make
Hamel
a
template
and
CSS
changes,
so
we
don't
have
to
convert
this
table
to
giant
new
component.
It's
just
kind
of
doing,
along
with
our
Gilette
principles,
just
keeping
it
simple
using
boring
solutions.
A
We've
just
made
some
minimal
changes
possible
going
forward.
Another
example
is
our
import
project
status,
table
UI
refresh.
We
wanted
to
give
this
a
little
bit
more
statefulness
a
little
more
interactivity
and
actually
give
it
a
little
bit
more
information
and
as
well.
You
know,
okay,
make
it
look
nicer,
but
the
main
thing
was
that
we
wanted
to
also
make
it
more
maintainable.
A
So,
in
this
case,
while
we
added
statefulness-
and
you
know
when
we
can
tell
when
this
project
is
running
or
when
something's
done-
and
we
can
go
to
the
project,
we
also
realize
looking
at
the
code
that
it
was
quite
old
and
difficult
to
maintain
and
so
kind
of
summarizing
this
all
up.
When
we
needed
more
interactivity-
and
we
wanted
to
improve
the
maintainability
of
the
implementation,
then
it
makes
sense
to
convert
it
to
view
and
view
X
moving
forward.
A
We
had
a
group
level
project
templates,
and
this
is
actually
kind
of
the
example
where
we
currently
kind
of
need
inline
JavaScript,
but
this
one
is,
will
be
miss
chipping
in
eleven
six
and
is
a
follow
up
from
our
instance
level.
Project
templates
so
really
there's
not
much
difference
between
instance
level,
product
templates
and
group
level
project
templates.
The
main
difference
is
that
you
can
obviously
in
group
templates,
have
multiple
templates
that
belong
to
a
sub
group,
but
over
all
the
features
primarily
the
same
now.
B
A
Not
to
say
that,
on
the
back
end,
there's
still
work
that
he's
done
because
there
definitely
was,
but
on
the
front
end
side
of
things.
There
was
a
lot
of
existing
functionality
that
we
could
leverage.
And
so
again
we
went
with
the
boring
solution.
We
quite
literally
copied
the
solution,
from
instance,
level,
project
templates
and
added
of
a
minimal
Java
Script.
We
needed
to
be
able
to
have
that
expand
and
collapse.
Functionality.
A
We
have
this
project
drop-down,
which
allows
you
to
see
your
frequently
visited
projects,
and
we
wanted
to
copy
it
over
to
the
group's
tab
and
just
show
you
the
groups
that
you've
week
you
visit
the
most.
So
this
is
quite
easy.
There
were
no
dependencies.
The
data
was
already
there
and
my
manager
actually
advised
me
to
just
copy
and
paste
the
code
from
frequent
projects,
but
I
decided
being
near
to
get
live
and
wanting
to
really
deliver
as
much
value
as
possible
to
decide
to
consolidate
all
these
components
until
one
right.
A
Why
copy
the
code
I
have
to
placate
code?
Well,
we
can
just
make
it
easier
and
have
one
component
handle
it
for
both,
but
along
the
way,
I
also
decided.
Let's
convert
it
to
view
that
was
all
good
and
then
I
said
well.
There's
some
statefulness
involved
with
this
I
can
use
the
actions
to
retrieve
the
frequent
projects
and
groups.
A
I
can
use
some
mutations
and
really
get
UX
going
here
and
so
I
decided
to
add
view
X
on
top
of
it,
and
what
ended
up
happening
was
a
what
should
have
been
a
very
simple
tasks
turned
into
something
that
lasted
between
I
think
release
cycles.
So
it
was
definitely
something
that
I
learned
and
that
really
inspired
me
to
kind
of
put
this
presentation
together
to
really
understand
that
yeah.
A
We
really
need
to
be
pragmatic
about
how
we
migrate
things
to
view
and
how
we
get
there
and
also
understanding
the
scope
of
a
given
deliverable
and
how
we
really
want
to
approach
it,
but
to
recap,
in
terms
of
future
costs
and
how
to
identify
them
and
how
to
how
to
really
approach
it.
You
know
pick
the
best
approach
that
makes
sense
to
you.
A
A
Is
there
you
know
more
of
an
MVC
somewhere
in
between
and
all
of
us
just
to
figure
out
how
we
can
design
your
next
iteration
to
be
a
step
in
the
right
direction
to
get
things
like
UJS
and
it's
it's
obviously
okay
to
be
ambitious,
but
it's
also
important
to
you
to
have
a
gun.
I
can
be
a
little
bit
more
realistic
as
well.
A
Estimation
is
hard,
but
we
can
make
it
easier,
so
these
are
kind
of
the
tips
I
wish
I
had
known
or
kind
of
reminded
myself
repeatedly
when
I
was
first
starting
out
and
that
I
do
now
when
I
approach
any
deliverable,
and
so
these
are.
These
are
ways
that
you
can
identify
these
feature
costs
and
how
you
can
identify
dependencies
and
figure
out.
Okay
does
this?
Does
this
issue
really
need
to
be
broken
up
more
or
is
there
something
I
need,
or
is
there
somewhere
else,
I
have
to
check
such
as
jumping
into
it?
A
We've
got
a
front-end
development
process.
This
kind
of
checklist
of
all
these
things
that
we
can
do
when
we're
good
planning
and
executing
development
of
a
femine
feature.
There's
a
link
to
this
later
on.
It's
quite
exhaustive
I
would
say,
and
all
the
points
are
quite
valuable,
but
there
I
kind
of
have
a
top
I
think
it's
like
eight
or
so
that
I
really
ask
myself
for
each
deliverable
and
then
I
can
dive
a
little
bit
deeper.
If
these
questions
really
cause
more
questions,
so
the
first
one
is:
what
is
the
feature
composed
of?
A
Is
it
primarily
Ruby?
Is
it?
Does
it
need
back
in
support?
Are
there
helpers
for
this
as
their
as
your
data
I
need?
The
surface
is
actually
stretching
into
an
area
that
maybe
I
need
some
back-end
support,
for.
Is
it
primarily
jQuery,
vanilla,
JavaScript
view
a
little
bit
of
mix
of
the
all
of
the
above?
It
could
be
very
well
possible
that
what
you're
working
on
is
a
big
combination
of
it.
A
So
it's
really
important
to
figure
out
what's
list,
this
best
move
to
still
deliver
the
feature,
but
not
be
caught
up
in
converting
everything
to
view,
for
example-
and
this
really
leads
you
to
think
whether
you
should
consider
breaking
the
issue
down
and
especially
for
fun,
and
it
may
make
sense
to
have
separate
UX
and
back-end
issues.
If
there's
data
you
need-
and
you
don't
know
how
to
interface
with
the
backend
or
it's
not
available
on
the
API.
If
there's
you
expects
that
you
need
that,
you
know
you
really
need
before
you
expect
before.
A
You
can
estimate
the
front
of
involved
and
know
that,
if
you're
working
on
something,
for
example
like
product
overviews,
you
need
to
worry
about
the
geo
features.
The
project
mirroring
features
on
the
enterprise
side
of
things,
and
that
and
just
going
back
to
that,
that
may
actually
mean
that,
like
these
UX
and
back-end
took
it,
these
issues
might
have
to
be
like
unreleased
before
you
actually
go
in
and
and
execute
on
your
work,
and
that
might
be
ok.
A
But
taking
a
look
at
all
this
and
what's
involved
with
delivering
on
your
feature,
will
at
least
help
you
identify
that
and
makes
it
easier
to
make
that
case
for
splitting
things
up
and
maybe
schedule
anything
a
little
bit
differently.
Another
question
worth
asking
when
you're
breaking
this
down
is
how
much
interactivity
is
needed.
Does
it
even
need
be
jeaious?
Is
it
a
drop-down?
One
kind
of
perfect
example
of
technical
debt
is
that
we
have
four
different
job,
drop-down
libraries
so
which
library
do
we
need
to
use.
A
We
want
to
get
rid
of
all
of
them.
We
would
love
to
have
just
one
that
does
it
all
for
us,
but
certain
ones
solve
different
use.
Cases
and
I
have
my
night
mode
turning
on.
So
let
me
just
switch
that
back
sorry
about
that,
but
yeah.
It's
just
trying
to
figure
out
how
much
interactivity
is
actually
needed
and
determining
how
much
JavaScript
you
actually
have
to
write
to
achieve
it.
A
So
taking
a
look
at
what
you
needs
to
deliver
on
and
what
is
available
to
you
and
trying
to
figure
out
how
much,
how
little
you
actually
need
to
do
or
how
much
or
what's
the
diff
between
what's
available
what
you
need
to
actually
do
to
achieve
the
feature.
This
is
a
great
question,
but
also
one
thing
we're
asking
is:
if
there's
existing
code,
it
doesn't
make
sense
to
migrate
it
to
CSS
lab
or
get
lab
UI
and
so
getting
into
our
tools
a
little
bit.
A
It's
a
little
bit
of
a
break
between
these
approaches
is
our
tools
that
we
have
as
friend
energies
available
to
us.
So
we
have
four
jamas
our
gate,
lab
design
system,
with
all
the
components
and
all
the
methodology
and
the
reasoning
behind
our
typography.
Our
components
are
things
like
our
popovers,
how
we
do
modal's
and
things
like
that,
which
is
heavily
leaning
on
bouche
at
4:00,
but
also
with
the
gitlab
flavor,
it
kind
of
mixed
into
it.
A
Perhaps
as
well
and
another
question
to
ask
when
you're
evaluating
deliverables
on
the
front
end
is,
is
the
date
of
available
from
the
back
end?
And
that
means.
Can
you
make
the
right?
Can
you
write
make
the
right
queries
to
surface
if,
in
the
controller,
to
expose
it
in
the
handle
templates
or
is
it
available
on
the
API?
Should
it
be
available
on
the
API
we're
often
not?
Maybe
we
want
to
have
that
available,
not
only
for
the
front-end
to
consume,
but
for
API
users
as
well.
A
We
hope
you've
also
got
graph
QL
as
when
we
want
a
query
for
additional
data
which
we're
slowly
starting
to
use
as
well.
So
these
are
all
different
questions,
and
this
is
like
a
big
dependency,
of
course
is
front-end
of
you
know.
Is
there
back-end
data
available
or
do
I
need
back
and
scored
a
database
support
to
really
get
what
I
need
to
do
with
this
feature,
and
a
big
one,
of
course
is
how
does
it
behave
in
Enterprise
Edition
kind
of
touched
on
this
a
little
bit?
A
But
you
have
to
check
how
the
feature
differentiates
between
C
and
Yi,
and
this
is
especially
important
when
you're
getting
UX
pecs
and
there
may
be
some
hidden,
none
configured
options
or
features
on
the
enterprise
side
of
things
that
you
have
to
really
look
in
the
code
to
identify
things
like
geo
or
project
mirroring
or
impersonation,
which
you
don't
really.
These
are
tucked
away.
A
We
use
them
very
often,
but
can
be
quite
important
when
you're
redesigning
or
doing
a
page
overhaul
or
adding
new
features
that
may
conflict
with
these
existing
enterprise
features,
and
it's
also
just
good
just
to
check
twice,
which
is
why
I
put
are
you
sure,
because
it
can
definitely
come
to
haunt
you?
If
you
don't
account
for
the
different
feature?
A
The
feature
differences
between
Cee
and
EE,
and
then
one
thing
you
also
want
to
check
out
is
whether
you
need
a
managed
state
in
your
application
and
we
try
to
manage
an
event
state
with
interview
components.
But
we
want
to
avoid
using
event
hub,
because
at
that
point,
York
State
is
probably
getting
complex
enough
or
you're
having
to
manage
state
across
multiple
components
in
a
given
application,
and
you
at
that
point
you'll
want
to
use
view
X,
and
we
have
a
lot
of
resources
in
our
front
end
guidelines
on
how
gitlab
does
view
X.
A
A
Tests
you
got
to
check
if
there
are
any
and
we
have
to
account
for
it
in
unit
tests,
of
course,
but
also
check
our
functional
r-spec
tests,
see
if
where
the
existing
ones
are
and
if
we
add
we
have
to
add
new
ones
and
then,
of
course,
with
geo
X.
There's
a
lot
more
testing
involved
there,
making
sure
that
our
actions,
mutations,
getters
and
setters
are
all
accounted
for
as
well.
Thankfully,
we
have
a
view
CLI
that
Phillipos
working
on
that
will
make
a
lot
of
the
boilerplate
creation
a
lot
easier.
A
But
the
main
point
for
all
these
different
questions
that
we
ask
when
we
look
at
these
deliverables
is
to
figure
out
how
we
can
break
these
issues
down
into
as
many
pieces
as
possible.
This
really
helps
us
with
our
ability,
in
our
confidence
to
be
able
to
deliver
on
on
things
and
misses
things
that
we've.
These
are
things
that
we've
accounted
for
and
had
to
realize
working
on
manage
because
there
may
be
dependencies.
A
We
miss
or
hidden
requirements
that
we
didn't
see
at
first
glance,
and
so
it's
really
important
to
try
to
figure
out
and
answer
these
questions,
because
it
will
determine
how
heavy
or
how
much
weight
your
deliverable
may
have
and
there's
a
link
at
the
bottom
right
there
to
check
out
our
development
process
checklist
if
you're
interested.
But
it's
also
in
our
resources,
slide
towards
the
end
of
this
deck.
A
Cool,
so
we're
on
the
tail
in
here
and
I
realize
we're
a
little
bit
over,
but
I'll
try
to
hurry
it
up,
but
what's
next
is
not,
it
might
surprise
you,
but
we
just
keep
chipping.
We
move
fast
and
we
continue
shipping
the
minimum
viable
change,
but
along
the
way
we
can
improve
our
processes
and
our
work
close.
But
the
main
goal
is
that
we
just
continue
to
move
towards
new
UJS
but
mission
and
slowly
but
surely
bring
our
code
to
the
latest
standards
and
guidelines.
It
kind
of
opens.
That's
right.
A
Sorry
I
thought
that
was
at
3:00
about
3:30.
Thank
you
for
the
reminder,
but
I
don't
think
there
was
anything
that
I
missed
on
that
last
one.
It's
really
no
surprise
there.
We
just
have
to
keep
shipping,
but
we
have
to
just
continually
improve
ourselves
when
we
break
down
deliverables
and
try
to
identify
these
feature
costs
as
much
as
possible.
A
Some
questions
to
ask
ourselves
too,
which
is
kind
of
a
little
bit
excited
exciting.
Maybe
for
some
of
us
is,
you
know,
as
we
move
away
from
Hamill
and
and
Jen
Ruby,
you
know
what
we
need
server-side
rendering
if
we
need
to
worry
about
kind
of
the
content
when
we
first
load
pages.
Obviously
performance
is
a
continual
question
on
how
we
continue
to
deliver
the
better
user
experience.
A
A
You
know
if
we
want
to
say
we
want
to
hit
all
of
our
p
ones
and
some
of
our
p,
twos
and
so
on.
It's
gonna
be
really
important
to
really
get
these
things
right
or
at
least
get
better
at
it
because
estimation-
and
these
features
are
never
similar.
So
it
we
can,
estimation
can
be
all
over
the
place
as
I'm
sure
you
may
have
encountered
yourself.
A
A
I
will
update
this
to
include
links
to
get
web
UI
CSS
lab,
as
well
as
our
design
system
and
also
some
easier
names
to
ping.
If
you
want
to
talk
to
the
manager,
front-end
engineers,
otherwise
there's
their
channel
and
slack
and
that's
it
so
hopefully
you
found
that
useful
again.
Some
of
the
challenges
we've
encountered,
building
fun
and
a
lot
of
Assam
manager
quite
fresh
to
get
lab,
and
so
hopefully
there
were
some
useful
tips
or
strategies
that
can
help
when
you're.
Looking
at
your
deliverables,
we
get
lab.
B
I
just
want
to
say
thank
you,
I
started
last
Monday,
so
it's
kind
of
that
was
nice
just
to
see
kind
of
like
a
big-picture
kind
of
from
the
very,
very
beginning
kind
of
started.
Talking
about
the
various
technologies.
You
guys
have
you
over
time
and
the
migration
over
time
as
well.
That's
something
I!
Just
wasn't
really
aware
of
so
it's
kind
of
interesting
to
see
that
mm-hmm.
A
A
Yeah
I
would
highly
recommend,
checking
out
Jacobs
presentation
and
that
101
slide
that
I
put
together.
He
goes
into
much
much
deeper
dive
into
like
because
he
was
with
a
lot
of
other
funders.
They
were
there
when
they
were
converting
from
CoffeeScript
cs5
and
then
writing
read
manually,
rewriting
things
these
things
back
to
es6
and
so
on.
So
there's
a
lot
of
background
information
there,
which
that's
right
as
I
101
what
he.
A
Awesome
well
thanks
for
tuning
in
for
those
that
joined
live
thanks
for
watching
for
those
who
are
watching
the
recording,
I
hope
you
found
some
of
the
information
useful
and
hopefully
it's
will
continue.
Maybe
we'll
do
a
new
one
once
we
kind
of
refine
the
process
further
and
front-end
continues
to
evolve,
but
I
love
them.
That
I
wish
you
good
rest
of
your
day.
Give
you
back
35-ish
minutes
and
see
you
in
the
next
one
cheers
again.