I was going to write a big answer going into details while a `system` “special 
form” would be beneficial, extensible and future-proof, draw comparisons and 
parallels to `super()` etc.

Instead I will leave you with this quote and links from node.js enhancement 
proposals on `module.import` 
https://github.com/WebReflection/node-eps/blob/master/XXX-module-import.md: 

— start quote —

Why polluting module and not require ?

require function has been historically abused 
(https://www.npmjs.com/package/require.async) or polluted 
(http://requirejs.org/docs/api.html#data-main) in an era where Promise, as well 
as async and await patterns, weren't even discussed in the JS community.

...

On the other hand, being module where developers define their exports, I don't 
see any confusion in being module where developers can import their 
dependencies.

 

— end quote — 

It’s funny to see how TC39 ended up abusing and polluting `import`.

On Fri, 04 Aug 2017 at 16:58 "Caridy Patiño"

<
mailto:
> wrote:

a, pre, code, a:link, body { word-wrap: break-word !important; }

> Make “System” syntax, and there you go.

Dmitrii, I like that, let’s continue with that train of thoughts! How do you 
make System syntax? You can’t consider it an object (it is not an object, it is 
syntax), which means you can’t pass it around because it holds contextual 
information (linked to the source text were it was used, similar to our beloved 
eval), it means you can’t really use other syntax to spread it, because it is 
not a object, etc, etc, etc. Do you see where I’m going? You quickly ended up 
with something almost equivalent to import().

We didn’t come up with it in the shower, it took years to understand all the 
problems, and create consensus, definitely not rushed IMO.

/caridy

On Aug 4, 2017, at 3:31 AM, Dmitrii Dimandt <
mailto:dmit...@dmitriid.com
> wrote:

Make “System” syntax, and there you go.

Instead we have multiple ad-hoc random additions to random keywords just 
because someone needs something and since there are rarely any long-term design 
decisions anymore, we’re stuck with new.target, function.sent, import.meta (add 
your own)

Seriously. How is new.target is “syntax that has context information”, but 
System.whatever cannot be provided with context information because it’s API?

On Fri, 04 Aug 2017 at 09:26 Jordan Harband

 

<> wrote:

> 

There’s nothing stopping you from providing context to System.load. Or 
Loader.import, or…

Those are APIs. It is, in fact, impossible to provide context with API, since 
it's just normal functions - it must be with syntax.

Additionally, please don't use sexual language, especially in a derogatory 
manner - that's against TC39's code of conduct, and I'm quite sure it won't be 
tolerated on this list.

Criticism that's purely insult, and doesn't actually explain the cons of 
something, is also not productive or useful.

_______________________________________________

 

es-discuss mailing list

 

mailto:es-discuss@mozilla.org
 

https://mail.mozilla.org/listinfo/es-discuss
 

On Fri, Aug 4, 2017 at 12:20 AM, Gil Tayar

 

<
mailto:g...@tayar.org
>

 

wrote:

Myself, and tens of programmers I know, use ES6 modules (and their precursors, 
CommonJS modules) for years now and can't even believe there was a time when 
they didn't exist, given that they have totally transformed (in a good way) the 
way we work. And that is also the vibe I am getting from the community 
(twitter, blog posts, meetups, etc). So when you say that modules are "

redundant and unnecessary on the server-side.  and [...]continue to fail to 
solve an relevant pain-point for everyday programmers on the frontend-side 
now", I believe you are not talking about myself or about the community I 
surround myself with.

- Gil Tayar

On Fri, Aug 4, 2017 at 9:47 AM kai zhu <
mailto:kaizhu...@gmail.com
> wrote:

> I’m curious what the concerns were. You mentioned disliking the syntax, but 
> I’m guessing there’s more to it than that?

the concern is that es modules are starting to look like a solution in search 
of a problem.  its redundant and unnecessary on the server-side.  and it 
continues to fail to solve an relevant pain-point for everyday programmers on 
the frontend-side now, or in the foreseeable future, while creating new ones.

> I’ve been experimenting with ES Modules over HTTP 2 for a few months. I used 
> rollup to create my dep graph without actually bundling, then served 
> requested modules as entry points with a server push for their deps. I 
> imagine that it won’t be long brolefore generic tooling for this sort of 
> approach emerges (my own solution is pretty hacky, just wanted to see how it 
> might work).

for most projects, dep-graph and tree-shaking have marginal benefits in 
frontend programming, given their complexity.  for all that extra work and 
boilerplate, the result is typically not anymore smaller, more efficient, or 
more maintainable than a pre-es6 rollup file.

______________________________

_________________

es-discuss mailing list
mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

______________________________

_________________

es-discuss mailing list
mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________

es-discuss mailing list

mailto: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

Reply via email to