beside the joke, I think there's already everything we need to bundle
modules, either synchronously, or asynchronously within a top level async
execution.
This is an example:
```js
const esm = (realm =>
js => realm.get(js = esm.cache[js]) ||
realm.set(js, import(
/^(?:.|\/|[a-z]+:\/\/)/.test(js) ?
js :
'data:application/javascript,' + js
))
.get(js)
)(new Map);
esm.cache = Object.create(null);
// define your modules inline (or via paths/urls)
esm.cache['rand'] = `
export const uid = (size = 8) => {
const arr = new Uint8Array(size);
crypto.getRandomValues(arr);
return [...arr].map(i => i.toString(16)).join('');
};
`;
// execute with ease on a top level async
(async () => {
// instead of
// import {uid} from 'rand';
const {uid} = await esm('rand');
document.body.textContent = uid();
})();
```
It works already live:
https://codepen.io/WebReflection/pen/xzYOWp?editors=0010
It enables the following:
- bundle applications as single file (not only web)
- create a similar CommonJS bundle preserving all ESM semantics
- pre tree-shake and minifiy those modules too, so bundle stand alone
modules after tree shaking
I think these are all nice to have features, but I also think we have all
the primitives we need to make it happen via pre-processing.
On Tue, Jun 19, 2018 at 9:48 PM, Jamie <m...@thejameskyle.com> wrote:
> I think having an inline module format would help make the composition of
> build tools much easier.
>
> Right now we have an ecosystem where everyone builds libraries into
> bundles using tools like Parcel, Rollup, Browserify, and Webpack. These
> create output which get recursively pulled into similar bundles.
>
> The problem is that the operation of merging files into bundles destroys
> static information we have with individual files. So optimizing compilers
> have difficulty doing code elimination (often called "tree shaking" in the
> community) across bundles.
>
> If we had a definition format for these bundlers to compile to which
> didn't destroy all the static information we have in separate files, we
> could build better optimizing compilers around them.
>
> I would hope that such a format would also allow engines to optimize the
> parsing of these inline modules (deferring most of the work until modules
> are actually loaded).
>
> There is other efforts in a similar space such was the webpackage format:
> https://github.com/WICG/webpackage/blob/master/explainer.md
>
>
> On Tue, Jun 19, 2018 at 11:23 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> we need to go deeper ...
>>
>> ```js
>> (async () => {
>>
>> const {getPersonType} = await import(`data:application/javascript,
>> export function getPersonType(person) {
>> switch (person) {
>> case 'Teacher': return 'A teacher';
>> case 'Director': return 'A director';
>> }
>> }
>> `)
>>
>> console.log(
>> getPersonType('Teacher')
>> );
>>
>> })();
>> ```
>>
>> 💩
>>
>>
>>
>> On Tue, Jun 19, 2018 at 12:10 AM, Darien Valentine <valentin...@gmail.com
>> > wrote:
>>
>>> ```
>>> import getPersonType from 'data:text/javascript,\
>>> export default function getPersonType(person) {\
>>> switch (person) {\
>>> case \'Teacher\': return \'A teacher\';\
>>> case \'Director\': return \'A director\';\
>>> }\
>>> }';
>>> ```
>>>
>>> okay, not a serious suggestion, but it does technically work :)
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
