►
Description
Discussing the 3 possible ways of rendering the code blocks/snippets using the frontend instead of Rouge on the backend
A
You
all
right
good
morning,
everyone
we're
here
for
another
fortnightly,
call
about
performance
in
the
blog
viewer
in
the
source.
Editor
thanks
dennis
and
jack
for
being
here
today
we
have
a
short
agenda,
but
I
just
wanna.
Maybe
we
have
evan
had
this
call
for
a
while.
So
let's
try
to
get
a
status
point
of
where
we
are
from
our
side.
A
We
are
getting
to
the
point
where
the
basic
functionality
of
the
blob
viewer
is
implemented
and
we're
getting
very
close
to
being
comfortable
in
turning
that
feature
flag
on
what
we
wanted
to
in
order
for
not
to
be
blocked
about
the
decision
about
the
the
source
editor
in
the
rendering
and
we'll
talk
about
that
right.
After
this
we
are,
we
are
adding
a
feature
flag
to
control,
whether
to
use
the
source
editor
to
render
the
read-only
or
to
just
use
the
old
way
of
the
hammel.
A
We
lose
the
benefit
of
not
requesting
the
server-side
rendered
hammel
we
lose
that
benefit,
but
as
soon
as
we're
ready
for
it,
we
have
fine-grained
control
over
that
and
we
can
enable
that
whenever
we
we're
ready
for
it,
if
we're
already
ready,
we
just
turned
that
feature
flag
on
already
so,
and
that
leads
me
to
my
second
question,
which
we've
talked
in
the
past
about
potential
ways
forward
for
the
source.
Editor
read
only
about
leveraging
highlight
js
about
leveraging
parts
of
monaco
to
render
the
syntax
highlighting
and
yeah.
B
Yeah
so
yeah
I
was
wondering
like
I,
I
saw
some
activity
in
the
pile
ideas
concept.
I
unfortunately
haven't
had
time
to
respond
there,
since
I,
after
I
came
back
from
from
my
vacation,
but
could
you
please
elaborate
a
bit
on
the
status
there
like
like
technically?
Have
you
had
any
chance
to
check
all
three
proof
of
concepts
which
one
looked
more
interesting
like
just
just
that.
C
C
D
A
Okay,
I
did
I
did
play
around
with
the
highlight
js.
I
took
a
look
at
the
other
ones,
but
I
didn't
I
didn't
check
them
out.
So
I
think
that's
what
I
think
that
that's
the
status
is
that
we
need
to
get
together
and
maybe
maybe
make
you
make
a
decision.
The
question,
the
question
that
is
on
my
mind,
I
so
I
have
some
feedback
on
the
highlight.js.
I
mean
I
think
some
files
didn't
render
properly.
Others
did,
even
though
it
had
some
small
variation.
A
I
don't
I'm
not
I'm
not
entirely
sure
whether
the
small
variation
that
I
saw
is
that
problematic
or
not,
because,
for
example,
in
some
parts
the
function
names
the
function
signatures
is
one
color.
The
other
is
a
different
color
right,
I'm
not
sure.
That's
that
big
of
a
deal
as
long
as
it's
highlighted
as
long
as
it's
different
and
highlighted
in
a
different
way.
So.
D
B
B
So
much
for
sending
this
up.
That
was
really
good
welcome.
It
was
actually
a
nice
and
interesting
exercise
because
I
had
a
lot
of
hopes
for
highlight
gs.
I
will
be
honest
with
you.
I
had
a
lot
of
hopes,
but
they
were
not
met.
They
put
it
this
way.
So,
yes,
we
do
have
like
when
we
talk
about
benefits
of
highlight
gs
over
monaco,
for
example,
we're
talking
about
much
wider
language
support
in
highlight
gs.
B
What
we
didn't
know
before
or
like
we
haven't
discussed
this
before,
is
that
the
language
support
in
this
case
means
tokenization
of
the
of
the
code.
What
does
it
mean?
It
means
that
highlight
gs
splits
the
code
into
like
you
know,
elements
that
can
be
styled
for
more
languages
than
monaco.
Does
the
problem
is
that
highlight
gs
doesn't
provide
this
syntax
highlight
out
of
the
box.
B
This
means
that
we
either
have
to
find
the
css
styles
for
high
syntax,
highlight
syntax,
highlighting
of
all
the
files
we
are
interested
in,
or
we
have
to
write
our
own
to
match
that
off
rouge
and
what
I
figured
out
as
you
can
see
from
the
screenshot
screenshots,
is
that
even
highlight
gs
doesn't
provide
enough
like
granular
enough
tokenization
of
the
code
comparing
to
rouge.
So
we
are
not
able
to
hundred
percent
copy
the
syntax
highlighting
brush,
no
matter
what
no
matter
what
we
use
on
the
front
end.
A
B
My
next
point,
like
the
question,
is
whether
we
really
need
to
100
much
range,
and
the
answer
is
probably
no
like
yeah.
It
doesn't
really
matter,
not
a
hundred
so
yeah.
So
in
my
examples
I
was
trying
actually
not
too
much
rouge
but
match
the
syntax
highlighting
of
the
vs
code,
so
that
you
know,
like
most,
people
are
familiar
with
how
yeah.
B
The
problem,
though,
is
that-
and
this
is
this
is
really
a
bizarre
thing.
So,
let's
consider
like,
let's
let's
say
we
want
to
support
100
languages,
100
syntax
highlighted
we
either
have
to
find
100
css
files
with
the
syntax
highlighting
for
those
files,
or
we
have
to
write
those
hundred
css
files.
Our
own
now
multiply
this
by.
I
think
six
in
order
to.
D
B
Of
a
sudden,
we
are
in
a
very,
very
tiring
process.
It's
like
it's
not
a
big
deal
to
write
a
syntax
highlighting
for
for
different
themes.
Once
we
have
sort
of
a
master
file
for
one
theme
that
defines
all
the
elements
and
then
we
just
sort
of
substitute
new
colors
for
different
visual
themes
right,
it's
just
a
matter
of
building
this
backbone,
the
master
style
sheet
that
we
can
copy
over
to
different
visual
themes
and
update
the
colors.
B
A
D
A
D
B
So,
okay,
this
is
the
the
highlight
gs
vertical.
So
let's
get
to
the
changes.
So
here
I
have
the
oh
okay
right.
This
is
wait
a
second
I
misinformed
you,
so
we
did
not
create
several
style
sheets
per
language.
We
we
can.
We
can
like
we
just
combine
those
with
the
with
scss
include
right,
so
we
can.
In
this
particular
case,
I
put
everything
into
one
solarized
light,
so
the
theme
style
sheet
and
then
I
put
the
highlighting
in
the
theme
file
right.
B
It's
like
the
way
we
organize
this
is.
What
is
this?
This
merge
request
doesn't
provide
a
good
pattern
to
follow,
so
we
have
to
split
into
different
code
on
style
sheet
per
language
basis.
I
believe,
but
nevertheless,
here
is
the
thing.
So
the
way
highlight
gs,
tokenizes,
it
adds
class
representing
the
language,
so
css
html
will
be
together
with
it's
like.
It
adds
this
class
on
the
root
element.
Hlgs
element.
B
B
This
syntax
is
for
for
css,
and
then
the
the
elements
within
that
root
element
will
have
the
same
class
like
kind
of
similar
elements
will
have
the
same
class
right,
so
symbols,
it's
kind
of
kind
of
like
whatever,
for
example,
if
we
take
this
hl
gs
title
whatever
highlight
gs
considers
to
be
a
title
in
ruby
or
css
or
html.
It
will
set
the
hlgs
title
class
on
that
element.
B
So,
as
you
can
see
like
this,
snippet
covers
the
syntax
highlighting
for
for
I'm.
Actually,
I
haven't
checked
python
pearl,
but
I
have
checked
the
syntax
highlighting
for
javascript
and
for
ruby
to
compare
with
with
rouge
and,
as
I
said,
they
were
not
100
identical,
but
not
by
any
by
any
means,
but
the
the
thing
is
that
we
shouldn't
probably
make
them
100
identical
right.
So
technically
it's
not
that
big
of
an
effort.
There
are
some
general
styles
that
we
can
put
into
the
into
the
actually.
A
B
The
language
style
sheets
can
be
just
the
as
css
mix
in,
and
then
we
just
you
pass
the
that
accepts
the
color,
and
that
just
adds
the
colors
to
to
the
to
these
to
the
places,
and
then
we
just
call
this
mixing
and
supply
the
required
color
for
that
or
or
another
visual
theme.
So
it's
it's
there
are.
There
are
several
ways
of
achieving
the
result
we
need,
but
this
is.
This
is
the
work
that
we
have
to
do
so.
A
D
A
A
A
But
I'm
weird,
so
I
I,
while
you
were
talking,
I
was
googling
out
and
there
is
some
themes
made
available
by
the
community.
They
will
won't
probably
match
exactly
our
themes,
the
ones
we
have.
We
would
like
to
at
least
maintain
some
sort
of
like
the
same
colors
the
same
thing,
so
I
envisioned
some
effort
of
at
least
adding
one
file
per
theme
like
at
least
that
to
give
us
the
baseline
for
most
foremost
languages.
What
this
does
give
you
is
the
control
over.
A
Fix
that,
because
we
have
control
over
that,
but
it
does
come
with
an
initial
effort.
The
one
thing
that
I
think
is
really
beneficial
is
the
tokenization
for
very
large
set
of
languages.
That's
the
harder
part
right.
We
couldn't
do
it
if
we
had
to
so
I
don't
see.
I
see
this
as
a
hurdle,
not
necessarily
as
a
blocker
myself
right.
What.
C
A
Terms
of
rollout,
I
think
you
should
definitely
do
iteratively
like
have
one
issue
per
theme
and
schedule
them
as
quickly
as
we
can,
because
I'm
thinking
about
making
it
deliverable
and
everything,
but
we
would
make
like
I
don't
know,
monokai
theme,
admonica
theme,
support
or
something
we
would
add
an
issue
for
that.
Then
we
had
an
issue
for
the
other
theme.
Until
we
have
all
the
themes,
it
would
be
a
little
bit
precocious
to
start
enabling
it
for
users,
because
then
you
what?
A
What
bothers
me
is
that
I'm
going
to
start
having
reports
on
the
blob
view
itself
that
changes
between
and
then
you
might
have
some
bugs.
That
appears
in
some
files
and
not
another
one.
So
I
would
rather
wait
for
all
the
themes
to
be
supported
to
enable
it
then
that's
like
just
a
baseline
theme.
We
wouldn't
be
doing
any
tweaks
specific
for
languages,
but
then
we
would
have
to
go
beyond
that.
A
B
Technically,
we
rely
on
what
monaco
does
right,
so
monaco
does
tokenization
moniker,
does
the
syntax
highlighting?
And
it's
it's
really
like.
You
know
this.
This
merger
quest
just
creates
the
component
for
rendering
code
snippets
that
we
can
reuse
anywhere
right.
So
the
same
technically
the
same
thing
for
highlight:
g
as
we
create
the
component.
B
A
B
On
the
edit,
so
if
we,
for
example,
introduce
the
in
context
editing
while
we
are
looking
at
the
file,
we
click
a
button
and
the
file
becomes
editable.
We
still
preserve
this
sort
of
smooth
transition,
as
we
would
have
with
the
source
editor
except.
We
did
not
pull
in
source
header
right
away
for
viewing
the
files,
and
then
we
have
the
very
smooth
transition
with
with
showing
exactly
the
same
syntax,
highlighting
when
we
switch
to
the
editing.
But,
as
we
said,
this
scenario
is
by
far
not
the
major
one
that
we
have.
D
B
B
So
this
is
like
this
is
the
way
of
creating
the
new
language
support
with
tokenization,
and
this
is
this
is
interesting
thing
to
keep
in
mind
that
technically
I'm
I'm
not
sure.
I'm
not
gonna
say
that
highlight
gs
doesn't
provide
this.
Probably
they
do
somehow,
but
I
know
should
I.
I
know
for
sure
that
monaco
does
provide
the
way
of
improving
the
tokenization.
For
that
or
another
language.
B
B
B
A
Easy
to
do,
and
what
that
tells
me
is
that
there
is
a
method
of
of
extending
the
support,
and
I
think
it's
one
of
those
things
that
we
either
do
a
decision
at
the
start
to
add
x,
y
and
z,
and
then,
as
people
complain
about,
we
can
try
to.
Does
it
have
a
component,
we
add
it,
but
what
this
tells
me
these
are
not
created
by
the
by
the
owner
of
the
project.
Is
it
this
is
just
community
packaging.
This.
A
A
C
B
Why?
Because
it
will
be
just
too
heavy
right
and
it
would
kind
of
limit
our
coming
limit.
The
way
we
we
reuse
this
functionality,
because
if
we
go
with
highlight
gs
or
plain
monaco
syntax
highlighting,
then
we,
as
I
said
we
can
create
the
component,
the
reasonable
component,
that
we
can
actually
render
code
snippets
with
anywhere
in
the
product
and
that's
pretty
pretty
cool.
B
A
A
B
D
A
A
As
we
evolve
and
as
we
evolve
support
like,
for
example,
as
we're
adding
support
for
that
4d
language,
we
would
test
with
the
4d
file.
We
would
see
the
gaps,
we
would
add
another
line
or
two
to
the
themes.
Yes,
it
is
hard
work,
so
I
do
think
we
need
to
account
for
that,
but
it
would
give
us
like
the
the
harder.
A
C
A
A
B
B
B
Use
source
editor
it's
up
to
source
code,
to
make
this
decision,
because
okay,
presenting
and
rendering
the
blobs
is
from
what
I
understand
is
the
source
code.
There
is
one
thing
to
keep
in
mind,
though:
okay,
all
of
these
tokens
tokenizations
for
tokenization
files
and
css
files,
this
will
be
the
there
will
be
also
the
maintenance
cost
right.
So
people
will
come
to
source
code
as
a
dri
on
the
on
this
solution
to
implement
that
or
another
file
type.
A
B
D
A
A
A
A
B
B
A
Correct,
so
all
right,
so
I
guess
we
can.
We
can
basically
reassess
so
jacques.
I
think
it
falls
on
us
a
little
bit
to
go
deeper
on
dennis's,
mrs,
and
just
make
sure
that
we're
completely
comfortable
with
this.
We
should
involve
mike
nichols
as
well.
Our
ux
designer
so
I'll,
probably
reach
out
to
him
and
have
him
wait.
I've
already
reached
out
to
him.
B
B
Take
a
look
at
all
three,
mrs
to
to
know
at
least
what
things
we
already
have
and
what
things
we
might
keep
in
mind
when
working
with
highlight
gs,
because
the
approaches
at
on
on
the
surface
they
are
similar,
but
they
are
quite
different
in
the
under
the
hood.
So
just
to
make
sure
you
understand
all
the
caveats
of
all
of
the
solutions.
Okay,
I
would
really
advise
checking
all
three
yeah.
B
A
A
He
didn't
enable
it.
Oh,
I
see
the
baseball
emoji
yeah
yeah,
so
yeah,
let's
so
I'll,
probably
sync
up
with
him
and
see
what
he
thinks
about
the
whole
three
scenarios
jack.
I
do
need
you
to
take
a
look
at
the
all
three
of
them
and
make
sort
of
a
summary
from
our
perspective
like
in
terms
of
what's
our
engineering
hunch,
and
then
we
can
sync
up
with
mike.
So
maybe
next
week
we
can
get
together.
A
I
I
don't
think
this
blocks,
the
rollout
of
the
feature
of
the
refactor
like
you
can
still
enable
it
have
the
feature
flag
off
for
the
text
viewer
so
that
we
can
start
pushing
this
to
users
and
start
getting
feedback,
but
we're
going
to
be
pushing
that
this
on
the
side,
because
I
think
this
this
highlight
js
could
be
potentially
revolutionary
for
the
way
we
render
code
on
the
front
end
because
I'm
guessing,
you
would
also
highlight
diffs
right.
If
you
have
just
a
diff,
it's
language
as.
B
Well,
so
you'll
be
able
to
tokenize
it
exactly
exactly
this
is
this
is
useful
for
this.
This
is
useful
for
like
as
long
as
we
do
not
again
for
divs
actually
yeah
for
divs,
it
will
be
beneficial.
It
will
be
beneficial
for
all
the
code
snippets
that
we
have
in
the
comments
when
we
write
comments
and
render.
So
we
will
just
imagine
an
issue
with
like
50
50
comments
right
and
at
least
half
of
them
contain
some
snippets
like
where
people
discuss
the
things.
A
B
A
C
B
B
B
D
A
A
A
What
I'm
thinking
here
is
that
for
us
to
valid
we'll
validate
this
approach,
also
for
diffs,
because
that's
the
upcoming
refactors
on
the
source
code,
but
also
it
could
also
help
us
on
the
code
review
side
of
things.
If
we
can
leverage
highlight.js
on
the
front
end
to
do
the
highlighting
now
the
challenge
there
is
that
we
break
up
each
line
right.
So
we
don't
have
a
content
file.
We
have
we
receive
from
the
back
end
each
line
yeah.
A
So
that
would
be
trickier
for
just
a
highlight
one
line
at
a
time,
because
I
guess
the
tokenization
would
vary
regardless
of
that,
we'll
need
to
look
into
it
so
jack.
I
we
we
do
need
to
take
a
look
at
this.
We
might
do
a
spike
in
the
next
milestone
or
on
the
off
hours,
not
not
off
hours
in
between
reviews
and
stuff.
A
B
B
Right
so
yeah,
so,
to
sum
it
up,
like
probably
my
part
is
in
in
this,
is,
is
more
more
or
less
done.
So
I
prepared
three
three
three
three
solutions
that
we
just
technically
have
to
evaluate,
because
all
of
them
work
all
of
them
do
what
we
need.
It's
just
a
matter
of
figuring
out,
which
one
is
is
more
beneficial,
more
beneficial
for
us,
especially
in
the
long
term.
A
Because
it
gives
us
like
three,
a
few
opportunities
to
three
three
paths
to
explore,
which
is
great,
yeah.
Okay,
I'm
satisfied.
I
don't
have
any
other
questions
for
now.
I
think
we'll
we'll
take
it
to
another
context,
explore
it,
probably
in
a
spike
talk
to
ux.
So
jacques,
I'm
I'm
looking
forward
to
getting
a
summary.
A
B
B
A
B
Yeah,
but
it's
like
no
matter
no
matter
what
we
pick
technically,
we
will
probably
well
in
some
not
so
distant
future.
We
will
have
to
cooperate
on
some
solutions
where
either
we
will
benefit
from
your
work
or
you
will
benefit
from
from
our
work.
So
that's
this
is
this
like
presenting
the
code
snippets
and
editing
those
code.
Snippets
will
inevitably
come
hand
in
hand
at
some
point.
A
Yeah
absolutely-
and
I
think
you
you
put
it
very
well
earlier
when
you
said
it,
I
didn't
comment
at
the
time
that
the
the
flow
from
seeing
the
file
going
to
editing
it
would
be
nice,
but
it's
not
the
priority
yeah,
so
I
think
you
put
it
very
well,
so
I
agree
with
that
too.
All
right,
I'm
done,
I
don't
have
anything
else
dennis
you
put,
you
push
the
recording
so
that
I
think
you
are
going
to
have
to
upload
it
to
youtube.
Yes,
so.