►
Description
A
B
Sure
so
I've
been
working
with
John
David
Dalton
kind
of
discussing
what
could
happen
if
we
removed
some
ambiguity
that
is
present
between
the
different
grammars
in
the
ECMO
script.
Spec
on
that
led
to
publishing
something
called
the
I
think
it
was
unambiguous,
JavaScript
grammar
repository,
which
hopefully
John
gets
a
little
bit
of
time
to
talk
about
today.
E
Just
got
back
from
comp
sorted
work
with
Ashley
Williams
forest
Norville
and
Jeremiah
on
a
summary
site
summarizing
the
state
of
the
modules
discussion,
I'm,
trying
to
put
the
finishing
touches
on
it
today,
it'll
be
up
at
a
modules
guide
which
I
just
found
out
was
a
TLP,
so
I
I
think
next
up
would
be
Colin.
If
he's
here,
Oh
heaven.
F
G
C
J
C
K
J
A
Okay,
oh
really,
my
go
now:
okay,
so
tinkering
with
Alpine
Linux
support
in
CI
so
and
getting
that
green,
very
positive
response
to
community
announcing
that
that's
NCI,
so
I
think
people
are
really
looking
forward
to
that,
because
it's
very
popular
for
daca
security
release,
stuff
just
trying
to
wrangle
that
reviews.
Discussions
on
github,
so
much
going
on
I've
been
working
to
be
on
the
electron
and
node
relationship.
A
I
have
a
meeting
lined
up
with
the
electron
team
push
to
next
week,
just
looking
at
how
we
can
work
together
better
and
so
that
some
of
the
technical
issues
between
us,
particularly
there's
one
at
the
moment.
With
regard
to
the
API
version
incompatibility
at
the
moment,
they
are
identifying
as
currently
compatible
with
our
variant
6
ABI,
but
they've
bought
their
version
of
VA,
which
is
no
longer
a.
A
The
drama
figures,
GC
repo
started
some
discussions
in
a
just
getting
things
out
that
have
been
floating
around,
but
not
properly
documented
anywhere.
So
that's
it's
good
to
get
that
somewhere
down
and
the
usual
Jenkins
upkeep,
Johann
Bergstrom's
that
have
been
away
and
always
been
busy.
So
I've
been
picking
up
in
a
load
day
and
next
is
rich
I'm.
C
Setting
up
the
next
onboarding
and
also
was
at
node
comp
and
did
not
get
to
participate
much,
but
the
one
thing
I
did
do
was
facilitate
a
session
that
Myles
actually
was
supposed
to
facilitate,
but
then
he
realized
he
had
a
conflict
on
releases
and
what
users
pain
points
are
with
them
and
what
they
like
and
so
and
so
forth.
I
have
some
brief
notes,
along
with
names
attached
to
certain
comments
and
viewpoints,
I'm
going
to
share
it
with
the
build
working
group,
the
LTS
working
group.
C
M
I
M
A
Okay,
we
missed
you,
know
no
okay,
review
of
last
meeting.
We
talked
a
little
bit
about
Stan
later
problems,
but
without
Jeremiah
we
didn't
make
much
progress
there
and
we
talked
about
exposing
run
in
this
context
on
the
module
object
and
we
decided
to
push
that
back
to
github
for
discussion.
We
would
like
a
nice
or
API
for
that,
rather
than
just
exposing
something
that
we
Marky
batched,
so
discussion
is
back
on.
Github
would
be
good
to
push
that
forward,
but
I
guess
with
that
good
proposal,
it's
difficult.
A
So
if
you
are
interested
in
engaging
in
the
discussion,
please
go
to
issue
6288
yeah.
Is
this
not
one
of
those
things
that
it's
it's
gonna?
Be
it's
not
going
to
be
top
of
mind
for
anyone,
but
it
would
be
nice
to
get
that
out
there
to
assist
with
startup
speed
for
embedded,
particularly
so
getting
into
a
leash
boost
for
the
discussion
today.
The
issue
number
7
2
3
4,
which
is
reaching
return
valid
file
URLs
from
URL
format.
C
C
It
has
11
lgtm
from
a
CTC
member,
it's
a
kind
of
a
corner
case,
and
it's
also
a
bit
of
a
like.
You
know
we're
fixing
the
one
URL
format
that
well
that's
easy
to
fix
and
straightforward
to
fix.
The
real
fix
is
probably
James's
proposal
for
all.
You
know
for
what
WG
compliant
URL,
parsing
/
formatting
thing,
but
anyway,
I
did
just
want
to
give
CTC
one
last
opportunity
to
say:
whoa,
don't
land
this
yet
or
don't
land
this
at
all
before
I
go
ahead
and
land
it
in
the
next.
N
A
C
There
are
is
it
there
are
in
fact
other
protocols
where,
where
a
single
slash
is
not
valid,
I
mean
HTTP
would
be
the
big
one.
I
actually
initially
went
to
go
ahead
and
just
fix
all
of
the
ones
that
require
it,
but
it
turns
out
that
it
gets
kind
of
complicated
and
ambiguous
at
you
know
like
like
trying
to
figure
out
what
the
user
met
with
the
file.
Url
is
pretty
straightforward.
You
know
trying
to
figure
out
what
they
meant.
C
A
C
M
H
C
File
colon
slash,
slash,
slash
the
correct
URL.
The
the
file
URL
required
requires
fire
file,
colon
two
slashes
and
then
an
optional
hostname
and
then
an
absolute
path.
So
if
you
don't
specify
the
hostname,
you
need
three
slashes.
If
you
do
specify
the
hostname
it's
two
slashes
it
can
and
it
can
never
be
1
/
1
/
is
invalid,
but
browsers.
You
know,
liberal
what
you
accept
strict.
What
you
put
out
all
that
stuff.
A
A
A
K
Okay
else
is
pretty
fairly
simple:
we
already
ship
queries
a
query,
string
change
that
we
only
we
don't.
We
just
use
a
object
that
doesn't
inherit
from
object.
It's
like
it,
just
a
bare
plain
object
but,
and
then
I
submit
a
PR
to
do
this.
Basically,
the
same
thing
for
the
HTTP
headers
object,
the
object.
K
We
use
the
store,
headers
and
values
in,
but
people
seem
to
be
a
little
bit
more
vocal
about
that,
and
so
that's
kind
of
why
I'm
bring
here
to
see
what
people
thought
about
that
as
far
as
any
concerns
or
risks,
you
know
what,
if
they
thought
that
people
thought
it
would
be
acceptable,
or
some
people
suggested
cherry-picking
some
of
the
the
methods
from
object
up
prototype,
but
I'm
thinking.
It
should
be
more
of
an
all-or-nothing
type
of
thing
rather
than
cherry-picking,
but
that's
my
opinion.
So.
F
E
A
risk
that
it
would
throw
an
exception
yeah
we
were
just
changing
the
thing
it
would
throw
an
exception
on
I
guess
like
it
would
sometimes
throw
an
exception.
If
someone
sent
a
header
that
was
happy
about
the
the
key
has
owned
property
versus
well.
No,
actually,
it
wouldn't
fail,
because
we
lower
case
all
headers.
M
Ok,
this
is
gonna
sound,
completely
ridiculous,
but
I'm
you're
starting
out
there.
So
there
are
specific
objects.
Object
properties
assumes
that
people
want
to
propagate
to
it.
But
since
we're
doing
customs
anyway,
and
why
don't
we
not
just
simply
cherry-pick
but
include
each
one
in
kind
of
a
rapper
and
somehow
I'm
just
locally
thinking
like
and
I've,
dare
to
call
it
as
a
function
then
you're
to
return
as
a
function.
M
But
if
you
just
ask
for
the
property
that
I
might
be
looking
for
a
string
just
some
kind
of
munching
them
together,
so
that,
like
four
foreskin
like
for
future
future
wanting
to
remove
all
of
them,
but
the
same
time
still
be
backwards
compatible
for
the
moment.
But
deprecating
like
hey,
you
can't
use
any
of
those
normal
object
methods
for
the
moment
or
in
the
future.
M
Maybe-
and
this
is
really
have
thought
through
resum
talk
as
I'm
saying
it
well
but
like
say,
we
set,
has
owned
property
right,
but
then
also
there's
like
it
has
owned
property
symbol
in
the
object
that
it
kind
of
sits
outside
of
the
area
of
concern.
And
if
there's
a
header,
that's
called
has
owned
property,
then
that
can
be
set
up
and
symbol
that
if
they
call
has
owned
property
against,
we
can
look
and
say.
Is
there
a
header
field
that
matches
this
or
do
we
want
to
run
the
normal?
Has
owned
property
method.
M
E
We
so
another
point
curiosity
is
since
this
could
break
programs
that
all
right
that
currently
work
should
we,
instead
of
moving
it
off
of
turning
turning
the
headers
object
into
a
bear.
Object
instead
start
inheriting
from
something
that
would
start
warning
on
access.
Do
a
deprecation
cycle
on
it.
I.
G
F
E
So
this
is
similarly
foggy.
You
would,
instead
of
making
it
a
bear
object.
You
would
instead
insert
an
object
between
object,
a
prototype
and
the
Hatters
object
that
would
wrap
all
the
methods
of
objects.
Prototype
and
with
a
deprecation
warning
so
has
improperly,
would
still
call
has
em
property,
but
it
would
additionally
warned
that
we
were
going
to
be
removing
that
in
the
future.
F
E
E
F
N
K
E
H
If
you're
going
to
insert
that
deprecation,
interceptor
or
whatever
anyway,
then,
can
you
do
the
thing
Trevor
just
suggested
with
the
same
thing
or
is
there
meaning
Trevor
suggested
as
I
understood
it?
Look
if
there's
an
actual
header
with
that
name
and
otherwise
delegate
to
the
object
prototype
member
elsley,
the
deprecation
would
come
from
a
similar
interceptor,
yeah.
H
G
E
F
G
A
A
B
I'm
gonna
introduce
it
and
then
hand
it
off
to
John,
basically
the
ideas
that
we
have
problems
with
ambiguity
and
parsing
as
a
major
concern
for
how
we
could
support
es
modules.
We
wanted
to
take
a
new
approach
and
asked
if
we
could
remove
that
ambiguity.
What
could
we
do,
and
so
this
proposal
supposes
that
we
get
some
buy-in
from
the
ECMO
script
spec.
B
Basically,
several
members
of
tc39
have
been
willing
to
look
at
this
head
again,
which
kind
of
has
led
to
this
being
opened
as
a
thing
to
investigate
so
over
the
past
two
weeks
or
so.
John
has
done
a
lot
of
work
and
discussing
with
me
what
his
concerns
are,
what
our
concerns
are
and
move
forward
after
discussing
with
a
lot
of
other
stakeholders.
So
with
that
I'm
gonna
hand
it
over
to
John,
and
you
can
take
it
away
all.
N
N
So
if
everyone
pulls
that
up
you'll
see
the
proposal
there,
it
hinges
on
the
ability
to
distinguish
any
s
module
by
requiring
at
least
and
input
are
sorry
and
import
or
export.
If
it
has
either
one
of
those,
then
we
can
detect
through
parsing
that
it
is
a
module
goal.
So
that's
the
key.
That's
what
we're
we're
we're
going
to
be
talking
about
this
at
the
July
tc39
meeting.
It's
on
the
agenda
now
so
we'll
bring
that
up
there.
N
So
with
that
there
would
be
no
need
for
a
file
extension
change
extra
metadata
in
the
package.json.
There
would
be
less
need
for
special
file
names
things
like
that,
because
you
could,
with
the
parse
pass
figure
out.
If
it's
what
goal
it
is.
So
the
the
proposal
here
is
that
you
parse
looking
for
one
goal.
If
that
fails,
you
parse
looking
for
the
other
goal,
and
then,
after
that,
it's
neither
goal
so
then
it
would
air
out.
N
N
N
The
next
point
is
that
performance
is
generally
on
par
or
better
than
existing
common
J's
module
loading,
because
that's
that's
important
Bradley
has
worked
with
Trevor
and
some
others,
benchmarking,
the
possibility
of
caching
and
looking
at
the
existing
state
of
parsing
and
the
cost
for
that
with
caching
and
leveraging
things
like
bytecode.
Caching,
that's
where
the
performance
could
actually
be
improved
over
the
existing
loading
I
wanted
to
call
out
that
performance
for
ES
modules
would
still
be
significantly
improved
over
translation
workflows.
N
N
Let's
see,
if
there's
anything
extra
there.
We
also
have
adopted
the
modules
root
key
from
the
defense
of
jas
proposal.
It
should
be
noted
that
this
whole
proposal
that
that
I,
Bradley
and
I
started
working
on
came
out
of
discussions
from
the
defense
of
jas
proposal
and
the
existing
proposal
to
try
to
find
something
that
folks
could
agree
on.
So.
N
See
if
there's
anything
super
solid
there,
the
spec
goes
into
mechanics
of
how
to
resolve
modules
root
a
little
bit
more
than
the
previous
proposal
did,
and
that's
the
the
gist
without
that
with
with
the
parsing
technique,
it
also
can
actually
help
other
areas
too.
So
I
left
an
example
in
the
proposal
where
Microsoft
packaged
web
apps
can
benefit
from
this.
N
At
the
moment,
even
though
so
edge
for
those
that
don't
know
edge,
has
experimental
support
for
loading
es
modules,
with
the
type
equals
module
attribute
for
a
script,
but
even
with
that,
there's
no
way,
for
example,
from
the
packaged
webapp
standpoint
that
it
knows
what
mode
our
goal
the
script
file
is
in.
So
when
it
generates
its
bike
code
for
its
bike
code,
optimization,
it
generates
it
as
a
non
module
goal
and
then,
if
it
is
a
module,
it
has
to
throw
that
away.
N
Note
there
because
it
cuts
into
applications,
it
cuts
into
the
browser
a
bit
and
it
also
deals
with
module
loading.
So
that's
the
the
goal
there
in
terms
of
cashing
it
looks
like
there
is
still
room
for
improvement
as
well.
So
it's
not
like
this
is
a
dead
in
there
on
on
the
cash
perf
I've
got
chakra
has
bytecode
caching
that
we
could
that
we
can
leverage
v8
I
believe
now
has
bytecode
caching
too.
So
this
is
something
that
engines
are
equipped
for
and
looks
like
something
that
we
could
do
what's
nice
about.
N
This,
too,
is
it
leaves
less
things
hanging
on
for
people
moving
into
es
modules
in
the
future.
So,
for
example,
you
wouldn't
have
it
doesn't
change
fundamentally
change
the
ecosystem,
it
doesn't
create
a
new
file
name.
It
allows
for
a
more
a
more
seamless
flow
from
one
to
the
other,
without
big
impact.
So
that's
that's
the
proposal.
I.
E
Gosh
cool
I've
been
looking
at
over
this
for
a
bit
now,
so
I've
got
I've
got
a
bunch
of
weapons,
but
so
we
may
actually,
at
some
point,
wants
to
schedule
another
like
follow
on
meeting
just
free
as
modules
just
so
where
we
have
full
time.
But
the
first
question
I
have
when
you
talk
about
by
code.
Caching
is
this
something
that
looks
like
a
PI
C
file
exists
and
on
disk
cache
that
I
VA
then
just
like
our
engine.
Vm
dis
consumes
off
disc
I.
B
E
Okay,
how
would
this
gate
around
the
same
issues
that
existing
double-park
solutions
present
are
the
same
sort
of
so
that
the
existing
problems,
double
parse
as
I
understand
it?
There
was
the
ambiguity
this
resolves
that,
but
the
other
problem
was
the
required
cooling
authors
to
maintain
a
parser.
So,
for
example,
if
you're
working
with
sprockets
or
browserify
or
like
webpack,
you
have
another
parser
like
have
a
parser
around
and
no
to
go
purse
in
order
to
be
able
to
extract
this
information.
N
Great,
so
we
actually
consulted
with
josh
of
sprockets
in
signing
proposal
for
this,
and
we
have
a
section
called
tooling
concerns
where
it's
suggest
alternatives
for
this,
so
it
basically
links
back
up
to
the
implementation.
Where
we
say
hey,
the
recommendation
for
node
is:
is
cash
on
disk,
but
there's
other
solutions
there
for
four
people
who
consume
it
as
just
a
text
blob
and
that
is
with
command
line
flags
or
manifest
files
or
HTTP
headers
or
file
extensions
or
whatever,
etc.
From
that
so
there's
there's
them.
N
N
N
We
haven't
worked
out
yet
what
that
means
in
there.
In
our
proposal
we
say
if
you
try
one
mode
and
there's
an
option
to
fall
back
to
another
mode.
You
can
fall
back
to
that
mode,
but
depending
on
the
order,
eventually
it
errors
out.
So
that
still
is
a
little
bit
up
in
the
air.
I
know
with
the
browser
mode,
you're
you're
explicitly
opting
into
es
module
when
you
do
type
equals
module.
N
E
B
Proposal
is
saying
that
we
would
check
against
the
Akuma
262
spec
and
changed
that
it
wouldn't
be
unique
to
us
right.
So
if
we
down
the
browser,
there
is
yeah
how
the
browser
actually
does.
Its
own
form
of
parsing
is
not
covered
here.
We're
talking
about
changing
the
spec
itself,
so
you
could
not
parse
something
without
an
importer
export
in
the
module
grammar
mm-hmm.
K
E
That
would
apply
to
browsers
as
well
so
when
they
they
go
from
the
script
type
modules
that
from
that
top-level
module
and
they
import
a
second
level
module
that
doesn't
have
any
imports
or
exports
when
they
consume
that
level
of
module.
The
browser.
It
sounds
like
it's
a
little
bit
up
in
the
air,
but
it
sounds
like
we'd
be
opting
into
a
single
mode
and
that
that
second
level
module
would
be
parsed
as
an
es
module
by
browsers,
but
not
necessarily
by
node.
N
N
You
know
a
normal
file,
so
that's
something
to
still
be
discussed
and
ironed
out
with
them
cool,
but
the
big
deal
is
that
would
it
would
change
the
the
spec
definition
of
a
lot,
what
is
an
es
module
and
so
that
yeah
that
would
translate
into
something
that
does
equally
affect
the
browser.
As
note
so,
hopefully
there
we
can
iron
out
the
any
ambiguity,
because
the
whole
point
of
this
is
to
not
have
had
that
mm-hmm.
E
G
In
terms
of
single
file
modules
or
up
with
single
file
applications
which
we
sometimes
see
fit
like
CLI,
scripts
and
stuff,
is
that
any
reason
someone
would
want
to
use
a
module
without
an
import
or
export
that
isn't
because
of
implicit,
implicit
strictness?
Was
there
anything
else
there
that
we
were
missing
so.
B
A
Yeah
my
take
on
modules
is
that
it's
modules
is
one
of
the
ways
that
tc39
is
is
trying
to
migrate
to
all
the
goodness
which
use
strict
was
the
first
approach
here.
But
then
modules
is
like
that.
The
next
approach,
which
is
with
all
the
good
stuff
in
here
and
leave
backward
compatibility
over
there
so
I,
would
imagine
that
modules
will
throw
quite
a
bit.
A
N
I
I
kind
of
think
it's.
It
could
come
down
to
also
best
practice
practices
like
it's
it's
nice
to
be
explicit
about
the
intent
of
your
your
your
module.
So
if
you're
saying
your
module
is
intending
not
to
have
an
export
or
export
anything
then
exporting
a
like
a
default
of
null
or
an
empty
object
would
would
make
that
clear.
It
also
happens
to
opt
into
the
DES
module.
B
N
G
The
other
thing
that
I
noticed
is
that
this,
the
leaves
like-
okay,
maybe
maybe
tooling,
can
handle
this,
but
still
leave
some
ambiguity
for
people
that
are
actually
looking
at,
like
what
files
are
in
a
module
which
might
be
quite
large,
and
you
might
not
be
able
to
see
where
the
import
statements
are
or
export
statements
are
directly
in
the
future
when
other
features
may
be
available.
What
those
what
types
those
files
actually
are.
A
N
Inputs
are
top-level
like
they
can't
be
buried
in
functions
or
anything
like
that.
So
I
had
envisioned
that
most
would
treat
them
like
they
do.
Their
node
modules,
where
your
imports
are
generic,
are
generally
towards
the
top,
and
then
exports
are
towards
the
bottom.
So
that's
that's.
How
I
think
that
would
usually
be
handled.
A
A
My
point,
my
point
is,
though,
that
that
people
who
are
cuttin
you
like,
if
you're
contributing
to
an
existing
module
and
you're
looking
at
farms
thing
Awards,
it's
a
module
or
a
script
like
the
ambiguity
is,
is
there,
but
presumably
linters
would
pick
up
any
problems
you
had
any
way
before
trying
to
execute
or
test
like
Lynch's
would
actually
help
you
out,
and
editors
would
be
able
to
use
this
information
as
well.
So
the
ambiguity
would
be
solved
by
to
link
for
the
most
part,
I.
A
M
Some
I
would
like
to
I
do
wonder
how
many
modules
would
leave
their
projects
like
just
their
own
right,
never
mind
anymore
dependencies
or
anything
in
a
state
where
half
of
them
are
modules
than
half
of
them
are
common
jas
right.
This
seems
weird
to
me
that
if
somebody's
gonna
go
for
it,
I
feel
like
they're
they're
going
for
it.
Why
would
they
leave
the
module
for
a
year
just
sprinkled
with
one
or
the
other.
B
E
E
B
So
how
most
things
do
it?
Is
they
don't
exactly
match
the
spec
grammars
and
so
for
the
longest
time?
Actually,
yes,
lint
wasn't
an
AST
parser.
It
was
a
token
parser
I
think
that
changed
last
year.
Basically
things
like
Babylon,
which
is
babbles,
parser
kind
of
guess
it
things
and
verify
it
after
the
fact.
Oh
I.
E
B
B
I
B
Yeah
I
can
just
there's
I
to
two
things
we
get
from
it.
One
is
having
to
entry
points
having
to
entry
points,
14,
node
versions
that
support
modules
and
14
ones
for
node
that
doesn't
support
modules
that
allows
us
to
ship
packages
that
have
both
common
GS
and
es
modules
side
by
side,
but
resolve
against
the
preferred
one
and
the
other
is
for
deep
linking
this
was
pointed
out
in
the
defense
of
jas,
and
it's
actually
kind
of
an
interesting
approach
to
it.
B
So,
right
now,
if
I
do
readable,
require
readable
stream,
/,
readable,
j/s
I'll
be
able
to
actually
get
the
inner
file
of
a
package,
and
so
in
the
wild
people
actually
do
this
for
various
things.
Yeah.
We
just
can't
remove
that
behavior.
So
what
was
introduced
with
module
stock
root-
and
this
basically
says
when
you
enter
a
package-
a
jump
to
a
directory
within
that
package
and
resolve
against
that.
E
If
that
makes
sense,
so
assuming
assuming
we
were
to
land
modules,
we
would
grow
a
vm
dot,
create
module,
and
then,
when
you
require
to
package,
it
would
require
the
index
and
could
check
for
create
module.
Or
if
you
were
to
do
a
require
a
/b.
It
could
be,
could
be
a
directory
within
the
package
with
an
index
that,
yes,
that
did
the
same.
B
E
But
if
you
do
the,
if
you
created
directly
name,
be
inside
your
package
a
and
you
and
a
consumer
was
requiring
a
slash
b,
we
would
resolve
a
a
/
be
/
index,
so
we
could
continue
to
do
like
I
guess
what
my
core
question
is.
I'm.
Sorry,
sorry,
oh
I,
guess
my
core
question
is
how
how
tied
together
is
the
modules
route?
With
the
resolving
ambiguity?
Are
they
separable.
B
H
B
A
K
A
B
So
I'm
going
to
preface
this
by
whatever
I'm
talking
about
modules,
that
route
implies
that
we're
talking
about
a
version
of
nodes
that
supports
motorcycle
module
stock
route
is
not
directly
related
to
es
modules
themselves.
They're
a
cessary.
This
is
a
necessary
constrict
in
order
to
ship
packages
that
have
both,
but
it
has
some
other
effects,
so
one
that
Josh
just
talked
about
was
a
purely
common
jeaious.
A
G
This
module
is
now
does
that
route?
Does
that
point
to
the
older
version,
or
the
newer
version
like?
Does
that
point
to
what
what
older
versions
would
use
would
look
for
for
common
J's
files,
or
does
it
point
to
what,
if
like,
if
it
exists,
is
that
where
we
look
for
es6
modules,
that's
where
you
would
look
for
es6
modules?
H
A
So
how'd
it
happen,
I
haven't
thought
about
this
one,
but
it
may
be
is
a
good
answer,
but
how
browsers
approaching
this
idea
of
transition
period?
Is
there
any
thought
cording
to
the
fact
that
people
will
want
to
support
all
browsers,
but
also
use
modules?
How
does
that
work?
You
just
have
a
script,
a
with
module
and
that
just
doesn't
get
read
by
like
how
do
they
do
that
I.
Don't
understand!
Well,.
B
B
A
Okay,
so
even
doing
something
like
having
another
script
tag,
the
checks,
if
the
beguine
loaded-
and
if
it
has
been
another
script
back
to
load
your
script,
that's
a
it
does
it
does
that
suggest
that
we're
the
only
ones
thinking
about
transition
here
or
is
that?
Is
there
a
bigger
story
that
we're
missing
out
on
like
a
we
are
we've
been
criticized
because
work,
because
we
have
to
take
into
account
transition
period
and
or
the
browser's
have
a
story
there.
Another
got
a
great
story
for
detection
type.
A
B
B
A
It
does
my
initial
gut
reaction
is
simply
that
dot
MJS
solves
all
of
our
technical
concern.
So
it's
straightforward,
simple,
easy
to
crock,
but
we
I
guess
we
we
have
to
be
aware-
and
we
are
aware
of
biggie
concerns
out
there
in
the
people
that
have
you
know
very
attached
to
top
jeaious
and
don't
want
no
to
undermine
that
and
yeah.
So
I
guess
we
have
to
take
into
account
some
some
bigger
factors
than
just
solving
our
technical
problems,
but
it's
kind
of
tricky
to
have
to
do.