►
From YouTube: SES Meeting: Web Bundling
Description
Wherein we discuss Daniel Ehrenberg’s draft proposal for web bundles.
A
A
A
D
Okay,
so
let's
talk
about
bundles,
I'm
actually
right
now
in
the
middle
of
writing
a
new
version
of
the
document
about
bundles.
I
could.
I
could
share
like
a
very
early
rough
copy
with
you
if
you
want,
but
basically
the
one
one
of
the
core
goals
of
bundles
is
to
work
through
the
problem
where
it's
too
high
overhead
to
make
an
http
request
for
each
javascript
module.
D
There's
this
technique
called
cache
busting,
where
you
end
up
renaming
the
url
when
the
version
changes
and
then
you
have
to
do
that
up
the
tree
so
that
so
that
you're
not
I
mean
so
that
you
can
use
long-lived
cash
control
directives,
but
then
still
change
it.
When
you
need
because
you're
you
can
change
the
entry
point,
the
route
of
in
the
html
that
has
sort
of
a
that's
uncached,
and
so
I
think
I'm
gonna
quickly
upload
the
version
that
I
have
here
locally
and
then
we
can
talk
through
it.
D
D
D
How
can
we
chunk
up
the
the
resources
into
bundles
there's?
Also,
a
question
of
should
we
include
javascript
resources
and
non-javascript
resources,
and
so
chris
you
mentioned
that
you
were
interested
in
non-javascript
resources
as
well.
I
was
wondering
if
we
could
dig
into
that,
and
then
we
could
talk
about
the
other
issues,
the
the
core
sort
of
semantic
property
that
people
talked
about
preserving
is
preserving
url
semantics
and
preserving
kind
of
what
it
means
to
be
resources
on
the
web.
D
A
Sure
I
can
say
that,
from
my
experience
I
wrote
a
common
js
bundler
from
for
motorola
many
years
ago
and
ran
into
all
of
the
same
things
that
you're
discussing
that
you're.
Mentioning
the
only
thing
I
didn't
do
was
tree
shaking
and
tree
shanking
tree
shaking
is
complicated,
the
no
it
it
it's
it's
sort
of
like
in
this
space.
There
isn't
one
perfect
solution
right.
It
depends
up.
Much
depends
upon
what
you
want
to
achieve
and
like
if
we
could
have
a
perfect
solution.
A
Maybe
that's
something
that
could
come
out
of
this
conversation,
but
it
would
be.
It
would
be
a
stretch
because
there
are
a
whole
bunch
of
things
that
run
across
purposes
right.
So,
if
you're,
if
you're
talking
about
minimizing
the
footprint
of
of
the
app
of
the
of
the
first
slice
of
an
application
to
get
the
the
you
know,
the.
E
B
A
C
A
D
Yeah,
I
think
I
think,
creating
kind
of
inherently.
I
agree
with
you
that
it's
kind
of
a
thing
that
you
have
to
be
opinionated
about,
because
you
end
up
having
to
be
unsound
in
some
way
or
other
to
do
it
to
the
extent
that
people
want
it
to
be
done,
but
the
other
parts
about
running
native
javascript
modules
and
and
code
splitting-
and
you
know
in
particular
to
make
dynamic
import
work
seemed
seem
pretty
core.
D
D
That
they
express
some
preference
to
so
there's.
There
was
the
question
about
whether
we
want
to
include
javascript
just
javascript
resources
or
or
more
than
just
javascript
resources.
So
if
we
include
just
javascript
resources,
we
could
do
the
indirection
at
the
multiple
map
level.
You
know,
if
there's
a
question
about
us,
sending
bundles
the
bundles
could
be
increase.
In
the
I
mean,
each
entry
in
the
bundle
could
be
an
entry
in
the
module
map
or
it
could
be
at
the
level
of
fetching
resources.
D
So
my
my
impulse
to
handle
all
the
different
kinds
of
data
types
that
might
be
involved
is
to
do
it
at
the
fetch
level
rather
than
at
the
multiple
map
level.
Webassembly
might
be
doable
if
we're
in.
If
we're
doing
this
at
the
multiple
map
level,
because
we
have
webassembly
modules,
but
those
are
those
are
actually
not
not
reality
yet,
and
it's
not
clear
whether
they'll
meet
everyone's
requirements.
B
D
So
we
have
this
thing
called
html
that
can
then
make
these
references
to
to
resources.
Those
resources
are
not
looked
up
in
the
multiple
map,
but
there
is
an
idea
to
have
an
import
url
scheme.
Where
you
could.
You
know
instead
of
doing
http
colon,
you
do
import
colon
and
then
you
would
put
a
multiple
specifier
after
that.
I
I
don't
really
know
how
practical
this
was.
It
was
included
in
the
import
maps
proposal
initially,
but
then
it
was
pulled
out
because.
D
So
this
import
colon
url
scheme
would
would
the
idea
of
that
would
be
that
it
would
match
how
modules
are
how
module
specifiers
are
resolved.
I
think
resolving
a
module
specifies
a
different
operation
from
actually
importing
it.
So
in
theory,
it
could
be
more
tolerant,
for
example,
it
could
permit.
We
could
permit
images
this
way
and
have
them
be
indirected
through
import
maps.
A
E
So
last
I
heard
it
was
the
base
url
for
the
document
that
was
being
looked
at
and
in
general,
when
people
have
talked
about
these
import
scheme
urls,
I
was
part
of
why
it
got
removed.
Actually,
when
they've
talked
about
them
in
general,
either
they
want
you
to
reference.
Something
absolutely
which
is
a
little
bit
strange,
but
basically
like
dan
is
saying
it
would
go
through
a
mapping
operation
through
an
import
map
or
policy,
or
something
like
that
and
then
be
resolved
to
an
absolute
location.
E
E
D
So
I
I
feel,
like
the
optimistic
direction,
is
kind
of
on
the
other
side.
I
feel
like
it's
optimistic
to
to
see
if
we
can
do
bundling
at
the
fetch
level,
which
will
solve
the
broader
problem,
but
some
whip
kit
team
members
raise
the
concern
that
it
might
be
too
slow
to
implement
in
practice,
and
so
I
was
I
was
imagining
to
start
with.
The
fetch
version,
try
out
a
sample
implementation
and
see
if
it
can
work.
B
E
D
I
see
that
as
kind
of
part
of
this,
so
you
don't
have
to
emulate
javascript
multiples.
All
over
the
place
is
this
kind
of
the
I
mean
so
for
something
like
compartments.
If
compartments
have
these
multiple
apis,
if
everyone's
emulating
modules
they're
not
going
to
go
through
the
compartment
hooks,
that
kind
of
thing.
B
Right,
I
mean
that's,
that's
why
the
I
mean
we've
made
all
of
this
investment,
that's
not
a
language,
specific
investment
in
a
flexible
module.
You
know
resolution
and
linkage
system
and
we've
already
because
of
wasm
and
jason
already
kept
our
eye
on
making
sure
that
it
could
be.
You
could
do
cross-language
linking
of
modules.
B
I
think
chris
has
done.
You
know
fantastic
work
on.
You
know
working
out
the
semantics
of
that
and
coming
up
with
a
way
for
it
to
be
user
extensible
to
new
kinds
of
modules.
By
virtue
of
the
api
of
the
static
module
record.
You
know
the
extensibility
applies
only
to
modules
that
don't
have
a
live,
binding
semantics
and
I
think
why
binding
is
something
that
should
where
javascript
should
be
the
first
and
last
language
that
has
live
bindings.
I
think
it
was
just
a
terrible
mistake.
B
D
C
D
B
But
this
thing
about
you're
just
exporting
an
object.
A
mutable
object,
rather
than
exporting
a
location,
is
kind
of
the.
The
essence
of
it
is.
Is
that
that's
the
way
anything
that
wants
something
you
know
wants
to
to,
for
example,
accommodate
mutual
recursion
across
modules?
Can
do
it
with
exported
objects
rather
than
something
like
live
bindings?
B
I
think
you
know,
if
html
independently
does
you
know,
url,
mappings
and
and
and
all
sorts
of
of
you
know
import
namespace
manipulation
and
basically
encounters
a
similar
set
of
problems
and
comes
up
with
similar
sets
of
solutions,
all
of
which
are
disjoint,
and
you
have
the
complexity
of
two
separate
solution
mechanisms
to
what
are
really
abstractly
the
same
underlying
problem.
I
think
that
would
be
a
shame.
D
I
agree
that
it
would
be
a
shame
if
there
were
duplication,
so
there
was
there
was
an
idea
to
do
bundling,
so
we
could
do
bundling
at
the
module
level
or
we
could
do
it
at
the
level
that
underlies
modules
you
know,
for
every
module
system
there's
a
way
to
logically
kind
of
fetch
the
module.
Maybe
all
the
modules
are
there
on
the
system
already,
but
there's
a
way
to
to
you
know:
host
resolve
the
module,
and
so
there's
there's
sort
of
a
store
that
these
these
come
from
yeah.
D
A
If
we
want
so
the
only
so
my
take
on
this
is
that
the
only
solution
to
bundling
that's
going
to
have
signific
sufficient
coverage
to
cover
all
of
the
use
cases
for
which
it's
necessary
would
have
to
come
from
the
fetch
level
right.
But
okay,
this
isn't
necessarily
true.
But
my
my
perception
on
the
relationship
between
html
and
modules
is
that
html
is
at
the
moment
farewell
solid.
B
E
D
D
That,
ultimately,
I
think
there
there
will
probably
be
some
differences
in
how
bundling
works
based
on
the
underlying
I
o
system.
So
this
this
bundling
idea
points
to
a
you
know
a
particular
binary
format
that
I
think
should
work
in
several
contexts,
but
I
can't
assert
they
would
work
in
in
all
contexts.
D
A
Right,
so
I
think
so.
My
perspective
is
that
if
I
were
to
gaze
into
my
crystal
ball,
if
there's,
I
do
think
that
there
is
eventually
a
story
for
something
like
html,
but
is
a
module.
But
I
don't
think
it's
the
html
we
have
today
and
that
it's
better
to
have
a
to
better,
have
a
more
fundamental
solution
for
bundling
that
the
the
compartments,
etc
and
module
systems
in
general
can
ride.
B
To
understand
what
your
position
is
by
analogy,
in
the
same
way
that
in
javascript
we
had
scripts,
we
introduced
modules,
but
we
did
not
retroactively
rationalize
scripts
as
kinds
of
modules.
We
just
continue
to
support
scripts
as
something
outside
the
module
system.
Is
it
sort
of
the
same
thing
for
existing
html
versus
html
modules,.
D
Current
drafts
for
html
modules
are
more
like
are
a
bit
different
from
that,
because
it's
they're
more
like
the
main
page,
is
not
an
html
module
and
then
from
inside
of
a
javascript
module
or
script
with
dynamic
import,
you
can
import
an
html
module.
So
the
there's,
unlike
modules,
which
you
can
use
directly
with
script,
type
equals
module.
The
current
proposal
for
html
modules
can
only
be
used
when
bootstrapped
by
legacy
html,
so
that
that
could
change
in
the
future.
But
that's
the
current
proposal
for
each
email
modules.
A
Yeah,
I
I
think
that
there
I
think
that
there
is
a
very
different
idea
about
what
it
about.
I,
I
think
that
there
is
a
very
different
future
post
compartments
that
will
emer
something
that
will
emerge
from
compartments
is
the
possibility
of
a
rich
ecosystem
where
css,
html
and
javascript
are
all
reimagined
as
modular
in
a
shared
module
namespace
and
have
appropriate
linkage.
That
makes
sense.
That's
rational
across
those
boundaries.
A
A
Yeah,
absolutely
I
I
think
it
I
think
it's
orthogonal,
but
it
would
help
and
but
more
pressingly.
I
think
that
we
can't
wait
for
that
future
to
solve
the
problem.
Right,
like
the
bundling.
The
having
a
bundling
solution,
is
orthogonal
to
all
of
that
and
far
more
pressing
and
we
need
to.
It
needs
to
be
solved
for
the
script
and
html
layer
and
and
and
then
use
that
to
overshadow
everything
else
going
forward.
E
D
D
D
D
So
then,
there
more
subtly
there's
a
path
restriction,
so
service
workers
only
work
within
the
they're
only
able
to
like
intercept
and
change
responses
for
things
in
the
same
enclosing
directory.
I
think
that
kind
of
restriction
makes
sense
for
bundles
as
well,
because
they're
a
little
bit
like
a
declarative
service
worker,
but
even
more
tightly
identity
correspondence.
D
It
should
be.
This
was
a
constraint
that
braveries.
It
should
be
that
if
you
fetch
something
from
inside
a
bundle,
you
would
have
gotten
the
same
response
as
if
he
fetched
it
like
normally
so.
Each
thing
that
is
inside
the
bundle
will
have
just
a
completely
normal
url
that
you
could
fetch
individually
and
browsers,
could
use
this
to
make
sure
that
bundles
are
well
behaved
in
kind
of
a
stochastic
way.
D
D
For
browsers,
the
constraints
that
I
know
about
are
well,
it
would
be
nice
if
graceful
degradation
works.
One
way
that
it
could
work
is
if
we
say
that
the
underlying
contents
need
to
be
there
in
the
same
way,
that's
sort
of
the
completely
correct
graceful
degradation.
Sometimes
that
will
lead
to
slow
and
you
might
want
to
feature
detect
this
at
runtime
and
fall
back
to
some.
You
know
legacy
emulated,
bundling
solution.
D
But
that's
something
to
maybe
try
out
so
the
privacy
constraint
was
personalization,
so
brave's
post
was
all
about
potential
for
scrambling
urls,
making
urls
less
meaningful
and
meaningful.
It's
meaningful.
Urls
are
important
for
for
ad
blockers
or
content
blocking
in
general
because
they
need
to
be
able
to.
D
You
know
put
regular
expressions
against
those
urls
to
determine
what
not
to
render,
and
you
can
you
know
your
head
all
day
about
how
that
technique
is
not
meaningful
or
something,
but
it
works
today,
and
it
would
be
nice
for
it
to
not
break
also
for
content
blocking
when
those
content
blockers
block
urls,
they
avoid
the
overhead
of
downloading
that
content.
That's
linked
to.
It
would
be
great
if
we
could
avoid
that
overhead
for
bundling
as
well
bundling
weren't
a
thing
that
made
everybody
incur
that
overhead.
D
B
D
But
they,
you
know,
but
regular
expression
based
content
blocking,
does
work
in
in
practice,
even
as
surprising
as
as
it
is.
So
that's
so
there's.
I
want
to
say
that
this
was.
This
was
developed
with
a
lot
of
help
from
brave
in
a
very
long
conversation
with
them
over
months,
where
we
kind
of
clarified
the
various
points
here.
They
haven't
reviewed
this
particular
draft,
but.
B
A
Right
so
the
the
reason
for
that
today
and
you're
absolutely
right.
It
could
change
any
moment
depending
on
the
calculus
of
how
of
the
price
of
compute,
I
think,
is
a
big
piece
of
why
they
work.
Today.
It's
not
practical
to
generate
a
bespoke
bundle
for
every
user.
If
it
were
computationally
practical
to
create
a
bespoke
bundle
for
every
user,
they
could
obfuscate
your
entire
page
into
into
oblivion
and
make
it
completely
unintelligible.
D
I
told
them
this
thing
and
so
to
scramble
the
urls
you
would
have
to
like
associate
several
requests
and
responses,
and
so
they
were
concerned
that
this
would
be
a
change
in
the
the
economics
I
want
to
know
it's
also
at
the
bottom
of
the
document.
My
work
here
is
now
being
funded
by
io
by
adblock,
plus,
because
they're
concerned
about
the
same
thing.
So
we
want
bundling
to
happen
it's
important
for
the
web,
but
also
for
it
to
be
within
the
important.
E
E
D
E
It
comes
down
to
the
resolve,
I
believe
so
what
we
did
was
we
exposed
our
scoping
mechanism,
for
example
in
node,
and
it
it
works.
Similarly,
it
has
the
idea
of
origins
and
it
has
the
idea
of
paths,
but
in
order
to
get
that
working
in
policies,
we
actually
have
the
resolution
alter
at
each
level
of
that,
and
so,
if
we
are
going
through,
let's
say
the
compartment
api.
E
D
D
So
this
prefix
ring,
I
mean
the
the
alternative,
is
to
say
it's
the
enclosing
directory.
That's
what
service
worker
does
literally
be
prefixed
by
the
bundle
is
a
tighter
constraint,
slight
slightly
tighter
and
it's
I
don't
know
you
don't
have
to
do
as
much
url
parsing
in
javascript
to
to
enforce
it.
E
D
D
B
B
C
D
E
That's
that's
not
too
important.
I
do
know
whatever
prefix
scheme
is
used
here.
That
seems
fine.
That
would
also
mean
that
within
a
given
bundle,
you're
gonna
need
to
be
able
to
resolve
everything
relatively
so.
Does
this
mean
you
can't
escape
your
bundle
with
you
know
a
directory
access
traversal
up
past
it
so.
D
You
can
so
that's
one
of
the
faq
use
here.
The
bundles
are
not
isolated,
execution
context.
They
can
make
arbitrary
network
requests.
The
isolation
unit
in
html
is
more
like
the
document,
and
so
this
is
some
of
the
sub
resources
that
are
loaded
in
the
document.
The
idea
would
be
that
the
idea
would
be
that
all
of
the
things
that
are
inside
of
the
scoped
directory
that's
listed
would
be
served
by
the
bundle,
but
if
you,
you
know
dot
dot
out
of
that
or
you
just
reference
an
absolute
url,
that's
outside
of
that.
D
A
D
D
That
is
developing
this
binary
format,
but
their
charter
is
all
mixed
up
with
sign
exchange,
so
I'm
not
really
sure
what
to
do.
Actually,
I
propose
to
them
what,
if
you
just
focused
on
this
file,
format
not
signed
exchange,
and
I
don't
I
don't
know
whether
they'll
go
for
it
anyway.
It
has
a
section
based
architecture.
So,
if
you're
familiar
with
the
webassembly
binary
format,
you'll
find
a
lot
of
familiar
stuff,
you
know
magic
number
version
number
and
then
you
have
sections
and
sections
each
have
a
name.
D
D
You
know
based
on
the
the
url
or
the
or
the
path
it
provides
a
mapping
from
these
paths
to
indexes
in
in
the
resources,
and
then
the
resources
section
has
metadata
about
each
section
and
then
a
payload,
and
so
the
metadata
on
the
web
would
probably
be
hdp
headers.
It's
likely
that
the
set
of
hdb
headers,
that's
usable
in
this
context,
would
be
restricted.
D
The
use
of
headers
here
is
something
that
might
not
make
sense
in
all
environments.
So
maybe
it
makes
sense
in
node,
but
maybe
it
doesn't
make
sense
in
multiple,
for
example,
but
I
think
the
the
overall
binary
format
would
make
sense
more
broadly
and
then
there
could
be
extra
sections
for
for
certain
advanced
uses.
But
I
don't
think
those
come
up
in
in
this
loading
case
that
I
was
writing
up.
C
D
C
A
I
see
well
I
mean
that
settles
that
I
mean
we
know
that
zip
is
not
acceptable
and
we
know
that
tar
is
not
acceptable,
so
we're
definitely
in
the
territory
of
inventing
a
new
bundle
format
and
mark.
Incidentally,
seabor
is
also
one
of
the
options
for
as
a
as
a
message
pack
alternative
as
a
basis
for
a
cap,
tp.
B
E
E
A
D
A
Yeah
right
I
yeah
and
and
yet
it's
still
valuable,
there's
only
a
question,
and
it's
only
six.
I
think
that
it
has
failed
up
to
this
point,
because
the
value
and
the
cost
were
not
quite
well
aligned
enough.
I
think
it
would
be
a
different
story
if
it
were
possible
to
do
one
of
these
pieces
and
get
it
popular
first.
You
know
like
if,
if
I
needed
to
invent
jason
in
order
to
make
something
work,
then
it'd
probably
be
better
to
just
try
to
get
jason
popular
first
right,
which.
D
Piece
could
we
go
with,
I
mean
I
feel
like
having
something
shipped
in
browsers
will
will
increase
the
use
of
the
popularity
of
it,
but
we
would
need
to
solve
also
like
the
versioning
problem,
which
I
have
here
with
these
trunk
ids,
that
I
guess
we
can
talk
about
some
other
time
as
well
as
the
code
splitting
problem,
I
mean
they're,
both
handled
by
these
kind
of
chunk
ids.
So
I
mean
there
was
a
proposal
made
by
by
google
to
just
load
a
whole
resource
bundle,
but
I
don't
think
that
would
be
useful
enough.
C
C
So
no
no
aspersion
intended
I
I
I
do
have
some
concerns
that
you
know
this
is
encompassing
so
many
different
technologies
to
make
it
you
know
available
and
the
other
thing.
Despite
braves
assertion,
I
do
have
some
primary
privacy
concerns.
I
don't
know
who
you've
been
talking
to
in
the
webkit
team
and
I
haven't.
I
haven't
discussed
this
with
anybody,
but
I
do
have
privacy
concerns
that
we've
already
discussed
in
this
call.
D
Oh
I'd
I'd
like
to
hear
them.
I
don't
know
if
you
want
to
discuss
it
in
this
call
or
out,
we
had
a
thread
on
the
webkit
slack
and
that's
all
kind
of
public.
So
that's
why
I
was
kind
of
referring
to
it.
In
this
call
I
talked
to
ryosuke
and
also
john
john
wylander
raised.
I
don't
know
if
I'm
pronouncing
that
right,
but
he
raised
he
raised
some
concerns.
D
Some
of
them
seem
to
be
about
things
that
I
I
just
agreed
with
him
about.
Like
that,
we
need
to
continue
to
use.
You
know,
split
caches.
I
completely
agree
and
I
didn't
understand
if
they
were
still
like
open
questions,
but
there's
kind
of
a
you're
right,
there's
kind
of
like
a
big
barrage
of
things.
So
it's
it's
understandable.
B
C
C
You
know
what
what
happens
on
tooling
and
server
side
so
yeah,
I'm
I'm
part
of
the
apple
webkit
team,
but
I'm
not
the
right
person,
john
and
ryosuke,
and
and
probably
maybe
some
others
would
be
the
right
people
to
to
engage
if
you're
already
engaged
with
them.
That's
those
are
the
right
people
well,.
D
So
I
thought
that
prototyping
would
be
a
reasonable
way
to
investigate
that
concern,
which
seems
like
a
legitimate
concern
and
then
at
the
end
of
it
it
seemed
like
privacy
concerns
were
really
about
things
that
I'm
not
proposing
that
you
know
like
the
the
chrome
web,
bundles
were
problematic,
and
so-
and
ultimately
I
didn't
want
to.
I
didn't-
want
to
bother
people
too
much.
So
I
didn't
you
know
when
the
conversation
dropped
off.
I
didn't
like
keep
pinging
people
all
the
so
time
would.
C
D
D
I
don't
really
know
how
to
do
this,
this
branding
thing,
but
it
seems,
like
everyone
decided
web
bundles,
are
a
bad
thing
and
I
want
to
express
that
it's
not
controlled
by
by
google
and
things
like
that,
but
they're
not
they're,
not
competing.
I
have
that
written
in
this
document.
I
wrote
like:
what's
the
relationship
with.
C
C
Okay,
that'd
be
good
because
I
I
will
then
put
you
know,
circulate
that
url
in
our
internal
tracker
of
standards
proposals
and
we
can
discuss
it
in
one
place
so
yeah
if
you,
whenever
you
can
make
that
available,
that'd
be
good,
and
my
this
is
michael
speaking.
I
like
that
to
be
on
some
standards
bodies.