►
From YouTube: Create::Editor. WebIDE product vision discussion
Description
The discussion dedicated to WebIDE, it's future and possible path forward.
The meeting chat room notes.
14:40:54 From Denys Mishunov : I think it makes sense to move the meeting notes to our Editor Team agenda after this meeting
14:41:00 From Denys Mishunov : So that everybody has access to it
14:53:01 From Roman Kuba : New perspective Himanshu :D
14:53:45 From Himanshu Kapoor : new camera :D
15:03:10 From Enrique Alcántara : I’m already onboard with that
15:07:49 From Roman Kuba : 900 Mio … wow
15:14:00 From Marcel van Remmerden - Product Design Manager : Gotta drop out, thanks for letting me listen in!
15:23:09 From Himanshu Kapoor : my mic isn’t working for some reason
15:26:03 From Roman Kuba : What’s a Editor Lite?
15:26:50 From Roman Kuba : Pains me to this day
15:30:42 From Denys Mishunov : With snippets it woould be more challenging gas those do not necessarily live in a projecy
15:31:45 From Himanshu Kapoor : I do use Web IDE mostly for documentation changes, but then again markdown linting doesnt work in the web ide
A
B
Yeah,
so
I
I,
I
dropped
a
few
almost
joke
questions,
things
that
come
up
often
related
to
web
id
in
the
document,
but
I
think
it'd
be
great
to
continue
our
discussion
from
our
last
team
meeting.
I
forget
which
one
like
I
said,
that
was
our
monthly
and
pick
up
where
we
left
off
so
yeah.
I
think,
speaking
about
a
longer
term
strategy
for
web
ide.
B
They
can
execute
code
and
compile
code.
I
guess
is
more
accurate,
so
yeah
I
don't
know.
I
know
the
there's
a
long
history
of
this
discussion
before
I
even
joined
as
product
manager
and
love
to
hear
your
thoughts
on
it.
I
have
not
changed
my
stance,
which
is
the
wait
and
see
based
on
the
get
pod
integration,
but
I
think
we've
seen
a
little
bit
of
promise
and
sort
of
a
higher
level
of
activity
with
the
gitpod
integration
than
maybe
I
initially
assumed.
A
This
is
this
is
like
the
the
global
global
global
questions
right.
These
are
the
global
questions,
but
the
the
main
point
that
that
led
to
this
meeting
was
actually
to
you
know
to
to
have
some
to
have
some
perspective
from
the
product
side
on
how
product
sees
this
right.
So
we
as
as
engineers,
have
our
vision
and
have
our
maybe
wishes
to
do
for
for
this
project.
A
A
B
You
know
a
bunch
of
compilation
or
you
know,
static
sites,
and
things
like
that
that
that
work
great
with
us
with
an
id
like
with
the
web
id.
I
think
you
bring
up
an
interesting
point
about
whether
or
not
the
web
id
as
as
a
concept
starts
to
fade
when
we,
when
we
start
working
on
the
source,
editor
and
being
able
to
pull
the
the
elements
that
make
the
web
id
usable
for
those
use
cases
and
and
specifically
like
editing,
multiple
files
and
viewing
diffs,
and
things
like
that.
B
Experience
of
editing,
multiple
files
right-
and
I
wouldn't
say
that
I
have
a
definite
answer
on
that.
But
I
can
see
us
going
down.
I
think
those
are
the
two
paths
that
we
would
explore
right
like
we're,
either
going
to
really
improve
the
ide
experience,
the
that's
and
I'll
say
I'll
write
like.
I
think
this
is
the
way
I
would
lean.
B
I
I
think
we
should
invest
in
the
ide
experience
and
bringing
in
information
from
our
security
features
and
and
integrating
it
with
the
ide
and
and
making
sure
that
you
know
it's
very
seamless
to
go
from
like
merge
requests,
reviews
to
ide
and
then
seeing
conversations
and
everything
like
in
the
right
context,
because
I
I
believe
that
that's
that's
where
the
single
application
benefits
could
outweigh
any
small
discrepancies.
We
have
related
to
feature
gaps
with
competitors
like
vs
code
or
something
like
that.
B
A
A
That
would
give
us
already
the
sort
of
the
web
id
thing
without
terminal
without,
like
last
merge,
request
or
like
different
things
like
this,
but
it
would
give
us
more
or
less
web
id
like
experience
and
and
that,
but
then
then
we
would
be.
It
would
not
be
full
featured
id,
of
course,
like
our
web
id
is
not
full
featured
ide
and
that
version
would
not
be
even
full-featured
web
ide.
A
I'm
not
gonna
gonna
use
like
bold
words
that
are
like
impossible
or
something,
but
it's
going
to
be
very,
very
challenging.
Considering
the
number
of
people
we
have
and
the
number
of
tasks
we
have
so
the
the
competitive
projects
that
we're
talking
about
and
want
to
be
compared
to
like
code
spaces
code
sandbox
like
git
pod.
Those
have
big
teams
dedicated
to
this
particular
task
right
to
build
this
these
environments
and
we
don't
have
the
this
resource.
A
However,
if
we're
saying
okay,
we
do
want
to
provide
more
or
less
full-featured
experience,
but
we
want
to
provide
it.
We
want
to
take
advantage
of
this
in-context,
editing
and
sort
of
build
the
whole
editing
experience
within
the
product
on
this
gradual
user
experience.
When
user
starts
simple
with
just
one
file,
then
user
says
okay
clicks
a
button.
Okay,
I
need
the
full
project
tree,
for
example,
so
they
click
the
button
and
they
get
this
full
full
tree.
Then
they
can.
A
They
are
able
to
select
another
file
and
then
we
all
of
a
sudden
convert
this
into
the
tabbed
interface,
where
they
can
switch
between
tabs
just
like
just
like
they
do
in
web
id.
At
the
moment,
I
we
won't
be
able
to
provide
things
like
terminal
most,
probably
because
it's
it's
very
heavy
feature
right.
A
A
That's
a
bit
sad
situation,
but
that's
that's
reality
right.
However,
we
won't
be
competing
with
anybody
that
much
if
we
take
the
first
path
and
go
to
in
context,
editing
providing
gradual
user
experience,
then
we
could
be
seen
as
visionaries
and
as
the
moving
force
within
the
industry
and
that's
that
is
much
much
better
perspective,
much
more
exciting
path
of
development.
In
my
opinion,
what
do
you
think
about
this?
Eric.
B
I
completely
agree
a
few.
A
few
points
I
want
to
make.
First
of
all
like
tactically
speaking,
I
think
in
context
editing
is
where
we
need
to
be
heading,
whether
I
don't
actually
feel
like
those
two
paths
are
mutually
exclusive,
but
I
100
agree
with
you.
We
are
not.
We
do
not
have
the
resources
to
compete,
viably
against
the
larger
competitors.
B
Right
now,
I
would
say
that
when
I
think
about
vision
and
where
we
want
to
go
with
the
category,
I
really
try
hard
not
to
limit
myself
to
thinking
about
what
we
can
do
today
with
our
team
and
if
we
identify
a
business
opportunity,
that's
worth
it
we'll,
invest
in
the
the
proper
resources
right
and
the
get
lab
way.
We
might
not
spend
as
much
as
some
of
our
other
competitors
and
we
might
always
be
working
with
a
bit
fewer
people,
but
I
think
the
the
two
paths
will
not
cancel
each
other
out.
B
I
think
we
are
more
well
suited
right
now
to
explore
the
the
edition,
or
maybe
the
abstraction,
of
the
web
ide
into
more
basic
elements
that
can
be
exposed
gradually,
as
your
use
case
requires
in
context
of
where
you're
editing
the
file.
While
we
explore
and
validate
a
more
robust
server
side
component,
I
could,
if
I,
if
I
had
this
perspective
and
an
unlimited
budget
and
could
just
jump
ahead
and
not
have
to
worry
about
technical
and
considerations
and
resource
constraints.
B
I
could
say:
there's
a
there's,
a
valid
path
where
you
have
people
like
me,
who
might
not
edit
code
every
day,
but
sometimes
would
appreciate
that
gradual,
like
progressive
enhancement
of
the
editing
experience
depending
on
the
context,
I'm
working.
If
I'm
working
on
a
single
file,
I
want
to
be
able
to
quickly
open
up
that
file,
change
the
typo
and
hit
commit.
But
if
I
want
to
work
on
multiple
files,
I
don't
necessarily
care
that
that's
a
separate
part
of
the
app.
In
fact
that
confuses
me
like
now.
B
So
I'm
not
saying
get
pod
container,
I'm
saying
like
if
we
had
a
feature
where
that
container
was
set
up
and
it
could
run
on
our
on
our
on
our
runners
or
something
somehow
like
it
exists.
I'm
not
gonna
imply
that
we
have
a
solution
today,
but
if
I
could
spin
up
a
server
and
then
communicate
back
and
forth
with
it
either
through
my
id
or
maybe
then
we
choose
like
okay.
B
We
know
we're
not
gonna
compete
with
vs
code
directly
in
the
next
three
years,
so
maybe
vs,
code's
embedded
or
see
because
we
can't
embed
vs
code.
Maybe
we
use
thea
or
something
like
that,
but
that
environment
would
then
provide
the
live
preview
and
terminal
and,
like
the
the
the
more
robust
ide
experience
that
that
we
kind
of
are
heading
on
the
path
of
offering
but
not
fully
offering.
Today,.
B
B
If
you
could
open
up
that,
you
can
apply
these
same
constructs
to
working
with
static
files
or
a
wiki.
You
know,
as
we've
talked
about
so
these
are
all
useful
things
to
apply
to
various
parts
of
gitlab
separately
of
the
web
ide
discussion
and
then
yeah.
I
think
we
we
need
to
look
at
the
usage
of
git
lab
and
the
competitive
landscape
and
decide
whether
the
company
wants
to
invest
significantly
in
that
other
path,
and
I
I
believe
it
would
be
another
whole
team's
job.
A
So
it's
it's
kind
of
like
to
me
to
me.
It
looks
like,
like
the
the
discussion
that
we
had
long
time
ago,
with
roman
when
we
sort
of
we
came
back
to
this
situation,
where
we
started
small
with
the
source
editor
and
then
we
sort
of
build
this
gradual
experience
of
web
id
2.0,
while
not
while
preserving
the
current
web
ide,
so
that
it
is
there
to
stay.
B
Process
yeah,
nothing
would
make
me
happier,
and
I
think,
maybe
to
sum
up
like
a
a
vision
and
a
strategy.
Nothing
would
make
me
happier
than
to
remove
the
decision
point
of
how
I
want
to
edit
this
file
and,
if
I
could
say
just
edit
this
file
and
allow
me
to
decide
how
much
like
detail
I
want
in
that
editor
and
how
much
like
I
want
to
manage.
B
There's
only
going
to
be
more
choices
as
we
build
integrations
and
as
we
have
different
types
of
files
like
the
content,
editor
could
support
markdown
files
like
I
want
to.
I
want
to
take
away
those
decisions,
not
add
more
so
this.
The
this
is
the
path
towards
combining
those
editing
experiences
into
just
one
concept
of
editing,
the
source
file,
editing
the
code
and
then,
depending
on
the
context
and
depending
on
what
you
need
you,
you
might
see
it
a
file
view
you
might
see
tabs.
B
You
might
see
a
diff
view,
but
it's
all
the
same
editor
and
you
can
get
to
those
things.
If
you
need
them
and
then
we
don't
present
them
the
first
time
so
yeah
I
I
mean,
I
think
that
is
a
an
achievable
goal
and
a
vision
that
we
can
have
for
the
for
the
source,
editing
experience.
We
won't
even
necessarily
need
to
call
it
the
web
ide
vision.
It's
just
like
how
we
edit
code
within
gitlab.
A
A
But
do
you
think
in
the
near
future
we
will
be
heavily
invested
in
web
id
or
we
will
still
keep
it
as
a
niche
product
that
we
maintain
don't
invest
too
much
time
in
the
futures
or
we
will
actually
when
we
see
the
opportunity
we
jump
on
it
and
roll
out
any
major
feature.
I
don't
know
what
that
can
be.
I
don't
know
like
gif
integration
or
something
something
very
useful
for
web
id
right.
B
The
web
id
as
a
feature
right
now.
I
don't
think
we
need
to
heavily
invest
in.
I
don't
and
then
we'll
say
in
the
next
six
months.
I
don't
see
us
shifting
our
attention
to
heavily
invest
in
that.
I
do
think
that
there
are
some
areas
that
we
can
improve
the
ux
in
the
near
term
with
fairly
low
effort,
but.
B
I
think
we
can
look
to
improve
the
experience
of
the
web
id
at
the
same
time
as
we're
evaluating
those
use
cases
and
user
flows
that
we
want
to
solve
for
in
the
in
context,
editing
and
then
invest
more
in
the
source,
editor
extensions
and
the
building
the
the
the
foundations
of
that
in-context
editing
experience.
I
think,
starting.
B
You
know
in
the
next
couple
milestones
after
we
hit
the
our
push
for
for
the
what
we're
trying
to
achieve
in
14-0
I
mean
the
the
numbers
are
on
our
public
performance
indicator
page,
but
I
think
the
the
right
operations
our
main
like-
or
I
guess
this
might
include
well.
This
is
just
web
editors.
I
don't
think
this
includes
wiki.
You
know
we're
right
about
400
000
write
operations
a
month.
I
mean
users
writing
from
web
editors
in
a
month.
That's
not!
B
It's
not
insignificant,
like
we're
not
going
to
drop
the
concept
of
editing
source
files
in
gitlab,
and
so
I
think
we
need
to
decide
where
we
want
to
invest,
and
it
seems
to
me
like
a
given
that
we
would
want
to
invest
in
the
in
context,
editing
experience.
We
need
to
validate
this
there's
probably
there's
there's
research.
We
need
to
validate
the
experiences
actually
better
and
then
this
is
what
everybody
wants,
but
it
is.
B
It
is
clear
that
consolidation
and
sort
of
cross-pollination
of
our
features
is
going
to
be
a
theme
over
the
next
couple
years
and
it's
what
we're
working
with
in
the
content
editor,
and
I
think
it's
a
nice
parallel
with
with
the
source
editor,
and
I
I
don't
hear
a
lot
of
objections
to
the
concept
of
making
it
easier
to
access
and
edit
stuff
in
context
so
yeah.
I
don't.
I
don't
think
we
will
be
to
directly
answer
your
question.
B
We,
I
don't
think
we
will
be
investing
heavily
in
the
web
id
as
a
current
feature,
in
the
sense
that,
like
we're
trying
to
get
it
to
the
point
where
it
competes
with
vs
code
or
something
like
that
locally,
there
will
be
features.
There
are
user
flows
that
could
be
better.
We
can
merge
those
tabs
together
for
review
and
and
compare
or
review
and
commit,
or
whatever.
B
B
If
ever
and
then
I
think
the
the
other
thing
is
like.
We
should
really
be
looking
at
extensions
to
to
source
editor
to
support
some
of
those
other
workflows
like
security
scan
reports,
and
things
like
that,
like
vulnerabilities
and
using
using
that
opportunity
to
build
out
the
experience
not
only
in
web
id,
but
also
in
single
file,
editor
and
potentially
pipeline
editor
and
anywhere
else
that
that
we're
loading
the
source
editor.
B
A
B
Yeah,
it
is
for
the
sake
of
the
the
recording
I'll
just
share
my
screen.
This
is
what
I'm
looking
at
here,
and
so
I
have
an
issue
to
investigate
this
spike.
It
is
not
on
trend
to
be
that
high,
but
we're
over
800
000
in
february.
I
believe
there
was
a
data
incident
in
january
where
sas
data
wasn't
reported
and
it
was
carried
over
in
february,
but
we
also
had
a
spike
that
we
were
going
to
investigate,
and
I
have
an
issue
in
here.
B
B
Yeah
right
there
was
a.
There
was
a
spike
in
sas
where
we
had
like
two
and
a
half-
or
you
know,
250
percent
increase
in
in
february,
so
we'll
see
how
that
levels
out
in
march,
but
even
still
you
know,
over
half
a
million
potentially
750
000
commits
per
month
from
the
web.
Ide
is
nothing
to
ignore.
We
want
to
make
sure
those
commits
are
being
done
efficiently
and
we
are
improving
performance
and
making
sure
that
continues
to
to
grow.
While
we
invest
in
a
more
contextual
editing
experience
so
it
technically.
A
What
web
id
needs
like
what
how
we
could
sort
of
frame
the
the
the
web
id
effort
is
web
id
needs,
no
new
features.
Web
id
needs
some
user
experience,
love
and
some
like
make
it
easier
to
use
and
more
user-friendly,
because
this
number
of
people
tells
me
that
yeah
okay,
it
is
like
probably
feature-wise.
We
are
really
good
there
right.
B
B
A
So
I'm
not
sure
whether
anybody
has
any
comments
or
questions,
but
it
seems
like
we.
We
do
have
some
some
vision
that
we
can
come
back
in,
like
I
don't
know
in
three
four
milestones
like
in
half
a
year
and
get
back
and
reevaluate
whether
we
are
still
on
track
with
with
this
effort
and
whether
we
progressed
on
any
of
the
of
the
three
routes
and
we
need
to
adjust
the
division
but
so
far
the
vision
is
that
we
do
like.
A
But
whenever
we
deal
with
web
id,
we
mainly
focus
on
the
user.
Experience
improvements,
low
hanging,
fruit
features,
and
we,
whenever
we
have
time
we
play
around
with
in
context
editing-
and
I
will
I
will
investigate
that
path
as
well
with
source
source
editor
because
team
salman.
He
demonstrated
on,
like
the
the
previous
application,
perform
application
performance
session
that
happened
like
two
weeks
ago.
A
He
showed
his
work
on
in
context
editing
using
the
source
editor
for
for
regular
files
like
technically.
He
he's
using
the
very,
very
simple
thing
that
I
was
I
was
considering
doing
as
well,
but
didn't
have
time
to
do
that,
but
we
technically,
we
just
show
the
we
use
source
editor
both
for
editing
and
for
viewing
the
files.
A
That's
a
really
cool
thing
that
technically
brings
us
to
instant
editing
capabilities
right.
So
we
just
flip
the
flag
of
the
editor
and
we're
done
in
the
editing
mode.
It's
and
it
works
brilliant
for
for
regular,
like
code
files
for
source
files
right,
it's
we.
We
still
need
to
figure
out
the
way
of
doing
this,
like
not
not
this,
but
how
to
to
to
frame
the
experience
for
binary
files
and
all
these
things.
A
But
the
idea
is
there,
the
the
base
implementations
are
there,
so
we're
not
that
far
from
this
and
like
I've,
I
I
still
have
the
poc
of
inline
editing
for
snippets
somewhere
around,
so
we
could
combine
those
those
those
pocs
and
actually
deliver
something
basic,
yet
very
effective.
I
think
pretty
awesome
and
that
would
be
that'll
be
really
cool.
B
This
is
a
much
more
concise
way
of
of
of
getting
to
it.
What
we've
been
working
towards,
which
is
yeah,
we
should
be
focused
on
usability
low
hanging.
Fruit
features
we're
not
investing
in
major
new
areas
of
of
the
web
ide,
but
we're
instead
investing
in
the
source,
editing
and
in
context,
editing
experience
across
gitlab
and
when
and
if
we
decide
to
invest
in
a
more
robust,
server-side
container
environment.
For
for
your
quote-unquote
real
development.
A
Yeah,
that's
that's
understandable,
but
actually
you've
raised
a
really
good
point
that
updating
the
the
direction
page
for
webide.
That
would
be
that'll
be
very
helpful
so
that
everybody
on
the
team
has
the
has
the
idea
of
where
we
are
going
and
what's
the
like
at
least
the
long-term
goal
of
where,
like
roughly,
we
want
to
be
that
that
would
be
very
helpful.
Yeah.
A
D
D
D
A
But
still
it's
better,
no
than
no
notes
at
all,
but
I
I
just
think
that
it
would
would
be
would
make
sense
to
move
these
notes
to
our
like
editor
group
agenda
like
the
general
agenda,
so
that
we
like,
if
so,
that
we
have
it
in
one
place.
And
if
we
get
back
to
this
discussion
in
like
three
four
six
months,
we
would
still
have
the
record
of
this
yeah.
That's
a
that's.
B
A
good
call
I'm
still
getting
used
to
the
it's.
I've
been
pm
here
for
four
or
five
months
now,
but
I
still
am
getting
used
to
the
single
agenda
for
the
whole
group
idea.
Sometimes
I
forget
that
we
try
and
keep
everything
there,
so
I
will
I'll
move
them
over
after
yeah.
No,
I
I
guess
in
closing,
maybe
just
a
question
to
think
about.
You
don't
even
need
to
answer
now
but
like
what
are
the
things
that
prevent
you
from
getting
work
done
in
the
web
ide
like?
B
So
is
there
stuff
that
we
can
address
and
and
make
sure
that
as
we're
moving
away
from
the
web
id
as
a
singular
construct
and
and
more
of
a
progressive
enhancement
of
the
source?
Editor,
then
what
are?
What
are
some
other
ways
we
can
make?
It
useful
I
mean
you're
engineers
build
it
for
yourself
right.
So
what
are
the
challenges
you
face
with
the
web?
Id
as
as
it
is
today
separate
from
the
conversation
of
like
not
being
able
to
compile
your
files.
D
But
my
two
cents
on
this
one
in
general
is
like.
I
would
like
to
see
the
web
ide
being
more
a
tool
that
comes
into
supporting
you
and
doing
certain
flows
in
gitlab
like
very
dynamically.
It's
like
okay,
I
want
to
kind
of
solve
problem
mix,
but
just
like,
maybe
in
a
while
doing
a
review
of
something
I
want
to
change
something
or
kind
of
make
more,
a
bigger
suggestion,
or
something
like
this
or
so,
and
this
is
like
something
where
I
say:
okay,
that
is
a
perfect
flow.
D
Well,
I
don't
want
to
kind
of
do
anything
on
my
local
machine.
I
will
just
open
it
up
with
the
editing
experience.
Do
something
maybe
in
this
web
ide,
but
it
kind
of
like
fluently,
comes
into
solving
the
problem
that
I
currently
have
and
then
kind
of
going
from
there
currently
very
often
feels
like
you
need
to
make
a
very
deliberate
choice.
To
say,
like
I
want
to
do
something.
Am
I
going
to
choose
web
id
to
do
what
I
want
to
do?
It's
not
like.
D
But
nothing
in
this
case
goes
against
like
what
was
said
like
I
think,
doing,
in-context,
editing
and
starting
in
this
way
and
going
from
there
and
kind
of
maturing
the
ideas
and
kind
of
adding
more
and
more
things
over
time.
Like
saying,
oh,
you
do
income
in
context,
editing
here
and
bam.
There's
like
your
tree
view
of
like
a
folder,
something
like
this
dynamically,
adding
it
using
the
context
of
where
the
user
is
right.
Now
and
then
maturing
to
start
from,
there
is
my
my
story
in
my
head.
B
B
E
C
So
I
don't
think
it's
I
mean
I
either
I
will
close
the
tab
or
I
will
do
something
that
unintentionally,
I
like
I
have
like
15
tabs
open
and
one
of
them
is
the
web
id
and
I
accidentally
closed
the
tab,
or
maybe
my
browser
crashes
and
or
something
like
that,
or
there
is
an
error
in
the
web
id
which,
like
is
unrecoverable
from
so
in
any
of
those
cases.
The
data
that
I
have
been
working
on
in
the
web
id.
C
Lost,
but
that
is
not,
that
does
not
happen
anywhere
else
in
gitlab.
So,
even
if
you
are
working
on
a
comment,
you're
working
on
them
on
the
merged
request
review
and
your
comment
is
like
half
written
and
then
you
close,
it
close
the
tab
and
when
you
come
back
to
it,
it's
all
still
there,
but
that's
not
the
case
with
your
idea.
I
think
we
should.
C
A
B
A
good
point,
I
think
we
talked
about
this
a
little
bit
in
the
context
of
the
editor
former,
formerly
known
as
editor
light,
in
that
we
could
use
local
storage
to
to
save
those
edits
and
and
provide
that
to
all
the
consumers
of
the
source
editor.
I
think
that
would
be
a
great
place
to
invest
a
great
extension
to
add
or
core
functionality
to
ad
and
then
obviously
we
wouldn't
need
to,
or
maybe
not.
B
A
A
We
can
implement
this
local
storage
mechanism
for
for
both
places
now
and
it's
it's
gonna
gonna
stick
and
but
because
this
is,
this
is
really
like
the
for
for
a
lot
of
a
lot
of
people,
editing
code
or
editing
any
content
on
the
web.
This
is
the
show
stopper
like
people.
People
do
not
trust
this
tools
just
because
they
don't
want
to
lose.
The
work
right
like
like
roman,
did
a
couple
of
days
ago
when
he
lost
to
the
result
of
two
hours
of
work.
A
A
A
The
ability
of
you
know
it
all
just
feels
very,
very
rubbish
to
me
in
terms
of
like
this.
This
is
related
like
to
our
performance
issues,
things,
but
it
all
feels
like
you
know,
you
click
something
and
it's
just
like
it
gives
you.
It
all
constantly
reminds
you
that
you're
in
the
web
environment,
like
it's,
just
slow
it
just
it
doesn't,
have
the
smooth
user
flow,
it's
very
discreet.
A
So
here
I
am
looking
at
my
file.
I
need
to
open
another
file,
I
click
and
like
that's,
that's
it.
That's
the
end
of
the
previous
experience.
Now
I'm
waiting
for
the
second
experience.
There
is
no
smooth
flow,
and
this
this,
this
discrete
experience,
always
sort
of
gives
users
time
to
think
about
the
flaws
of
this
product.
Instead
of
giving
this
smooth
flow,
where
users
just
start
doing
something
end
up
where
they
have
to
exit
the
product,
and
they
have
this
smooth
experience
about
the
product.
A
But
this
this
problem
is
very
sort
of
very
abstract
and
very
broad,
and
it
has
a
lot
of
entry
points
into
it.
So,
but
the
linters
and
technically
like
making
sure
that
my
code
meets
the
standard
of
the
project,
I'm
contributing
to
that's
the
main
thing,
because
there
were,
and
also
this.
This
also
includes
the
commit
messages,
because
sometimes
I
had
the
problems
where
my
commit
messages
made
from
web
ide
were
not
meeting
the
the
standards
of
of
the
project,
and
then
I
had
to
sort
of.
B
Yeah
all
good
points,
and
I
think,
highlighting
the
fact
that,
like
like,
I
said
with
the
decorating
lines
of
security,
vulnerabilities
and
parsing
information
that
comes
from
other
parts
of
gitlab
in
the
code,
editing
experience
in
source
editor,
those
aren't
exclusive
problems
to
the
idea
of
web
ide.
These
are
things
that
we
could
be
building
as
extensions
for
source
editor
and
providing
in
snippets
and
in
when
you're
editing
the
raw
source
in
the
wiki,
or
something
like
that.
B
You
know
these
are
universal
problems
that
we
can
be
solving,
and
I
think
linting
and
providing
scanning
of
any
kind
is,
is
something
that
we
should
be
looking
at
and
investing
in
and
I'm
going
to
share
right
before
I
drop,
even
though
we're
recording
I'm
going
to
share
a
little
secret
when
I'm
editing
content,
whether
it's
writing
like
prose
and
long
form,
content
or
code,
I
I
prefer
a
local
environment.
This
is
I
I
can't
I
I
can't
use
web
apps
for
for
for
that
work,
and
I
know
I'm
in
the
wrong
place.
B
Make
a
web
id
that
I
would
love
to
use
and
I
do
use
it
frequently
but
for
serious
work
and
for
work
that
I
I
need
to
like
if
I
I'm
going
to
go
at
it
the
direction
page
for
the
web
id
I'm
not
going
to
probably
do
that
in
the
web
id.
So
that's
our
use
case
right
there
like.
We
need
to
solve
that
problem.