by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 11 18:13

    martinheidegger on gh-pages

    Automatic deploy (compare)

  • Feb 11 18:13

    martinheidegger on master

    final commit (compare)

  • Feb 11 18:06

    martinheidegger on master

    Archiving (compare)

  • Nov 26 2017 09:29
    giltayar added as member
  • Sep 04 2017 11:26
    guybedford opened #20
  • Sep 07 2016 04:43
    martinheidegger closed #19
  • Sep 07 2016 04:43
    martinheidegger commented #19
  • Jul 06 2016 16:09
    ljharb commented #19
  • Jul 06 2016 12:50
    clavecoder opened #19
  • Jun 28 2016 21:25
    qraynaud commented #11
  • Jun 28 2016 16:14
    Mouvedia commented #11
  • Jun 28 2016 16:14
    Mouvedia commented #11
  • Jun 28 2016 16:13
    Mouvedia commented #11
  • Jun 28 2016 16:08
    ljharb commented #11
  • Jun 28 2016 15:29
    qraynaud commented #11
  • Jun 28 2016 14:58
    ljharb commented #11
  • Jun 28 2016 09:20
    qraynaud commented #11
  • Jun 27 2016 18:07
    ljharb commented #11
  • Jun 27 2016 08:52
    qraynaud commented #11
  • Jun 27 2016 08:52
    qraynaud commented #11
Martin Heidegger
@martinheidegger
Hello!
Yaw Etse
@yawetse
Hi @martinheidegger, first of all, great write up of the the current state of es6 modules
has the use of an asynchronous implementation of require been explored as an alternative to e6 modules?
a la something like this: http://stackoverflow.com/a/20528452
Martin Heidegger
@martinheidegger
I think it was certainly explored. And I can faintly remember a discussion somewhere.
I do know that the discussion is flaming again with the introduction of async/await which would break that logic.
Martin Heidegger
@martinheidegger
My assumption is that it simply would break too many projects if the packages were to be async suddenly.
Yaw Etse
@yawetse
Got it, I was actually suggesting / wondering about keeping the existing require logic in place, and add an additional module loader that was async, instead of a replacement. That way by default, require works as it currently does - synchronously and requireAsync would return a callback or a promise
Martin Heidegger
@martinheidegger
@yawetse One of the big problem with solutions like this is that they affect the whole infrastructure.
If you write a module that is async it can hardly be assumed sync.
Janus Troelsen
@ysangkok
@martinheidegger what happened at the Tuesday, 26 July 2016 meeting?
Martin Heidegger
@martinheidegger
@ysangkok nothing and a lot. The UnambiguousSyntax proposal was not accepted - for a conceputual reason.
Martin Heidegger
@martinheidegger
I took quite some time for me to figure this out but:
The reason why it “has to contain either” is: Because the TC39 decided so.
It was a concious and calculated decision.
So: if you follow EcmaScript then there are in future ALWAYS two kinds of files. On purpose
Yet: the TC39 does not want to give recommendation how to differentiate between those two files.
And - in order for future versions of ecmascript modules to be unambigous - the differenciation has to happen outside of file format.
Martin Heidegger
@martinheidegger
i.e. through the file ending, http headers, project specification, etc.
But the outside-information (out-of-band metadata) is something that the TC39 doesn’t (want <- my opinion) specify.
So: we need to come up with something in a different standardisation process.
>
?
Janus Troelsen
@ysangkok
Looking at discussions like nodejs/node#7273 , it seems that not much happened in the last few months. Is it because we are waiting for standardization of things like tc39/ecma262#692 Where is discussion currently happening?
Martin Heidegger
@martinheidegger
^_^ in back-channels and at TC39 meetings I guess.
This repo needs updating.
Dearly.
Janus Troelsen
@ysangkok