import.meta and TC39 process as a whole

classic Classic list List threaded Threaded
80 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

import.meta and TC39 process as a whole

Dmitrii Dimandt
Can anyone enlighten me as to how any input on features that are rushed into the standard works?

What is the purpose of hosting TC39 on GitHub if no input is expected from anybody but TC39 members?

Prime example: https://github.com/tc39/proposal-import-meta/issues/2

Somehow it’s already in stage 2. Which means: The committee expects to devote time to examining the problem space, solutions and cross-cutting concerns

Only reviews from committee members are expected, all other comments are locked out. If this makes it to stage 3 (and it will), it means: The committee expects the feature to be developed and eventually included in the standard

So what’s the point of the whole process? Just shove whatever features you want/need onto the language and be done with it.

Regarding import.meta. Instead of properly speccing out and designing a Loader (https://whatwg.github.io/loader/), the import keyword was turned into a not-really-a-keyword-not-really-a-function abomination. It quickly reached stage 3. Any and all concerns by people who discovered this and voiced their concerns were dismissed with no argument, and dynamic import is now everywhere.

Now, since there has been no proper design of the feature, a `meta property` is just tacked onto the already confusing mess that is `import`. Expect it to reach stage 3 within a week or so, and then we are stuck with it forever.

So, the question: why does TC39 even bother with the pretence of being transparent, o doing proper design on the language features etc.?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Sebastian Malton
I agree. There was a post on those email chain some time ago about moving to another platform. We already have TC39 why not move everything that we do here to there and have PRs be the finalization step. That is what Rust does, what CSS-WG does (sort of)

Sebastian 
Sent: August 3, 2017 4:10 PM
Subject: import.meta and TC39 process as a whole

Can anyone enlighten me as to how any input on features that are rushed into the standard works?

What is the purpose of hosting TC39 on GitHub if no input is expected from anybody but TC39 members?

Prime example: https://github.com/tc39/proposal-import-meta/issues/2

Somehow it’s already in stage 2. Which means: The committee expects to devote time to examining the problem space, solutions and cross-cutting concerns

Only reviews from committee members are expected, all other comments are locked out. If this makes it to stage 3 (and it will), it means: The committee expects the feature to be developed and eventually included in the standard

So what’s the point of the whole process? Just shove whatever features you want/need onto the language and be done with it.

Regarding import.meta. Instead of properly speccing out and designing a Loader (https://whatwg.github.io/loader/), the import keyword was turned into a not-really-a-keyword-not-really-a-function abomination. It quickly reached stage 3. Any and all concerns by people who discovered this and voiced their concerns were dismissed with no argument, and dynamic import is now everywhere.

Now, since there has been no proper design of the feature, a `meta property` is just tacked onto the already confusing mess that is `import`. Expect it to reach stage 3 within a week or so, and then we are stuck with it forever.

So, the question: why does TC39 even bother with the pretence of being transparent, o doing proper design on the language features etc.?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Caridy Patino
In reply to this post by Dmitrii Dimandt
Dmitrii, as stated by the champion of import.meta in the issue, issues/2 is one step of the process, in which we ask other members of the committee to review the spec text before it can be presented for stage 3. But you should be able to open other issues in that repo to voice your concerns about that proposal. Additionally, we have other channels, like this one, or via other members who can voice your concerns in upcoming meetings.

As for the particular feature that you’re referencing, I suggest you to look at previous discussions about `import`, and why it is different (a hint: it is different because like super, it needs some contextual information). As one of the champions of the whatwg loader, I can tell you that we spent many hours trying to figure the best course of actions based on the initial loader spec, and we believe `import` is the right thing to do. import.meta is just a progression of that decision.

/caridy

On Aug 3, 2017, at 4:10 PM, Dmitrii Dimandt <[hidden email]> wrote:

Can anyone enlighten me as to how any input on features that are rushed into the standard works?

What is the purpose of hosting TC39 on GitHub if no input is expected from anybody but TC39 members?


Somehow it’s already in stage 2. Which means: The committee expects to devote time to examining the problem space, solutions and cross-cutting concerns

Only reviews from committee members are expected, all other comments are locked out. If this makes it to stage 3 (and it will), it means: The committee expects the feature to be developed and eventually included in the standard

So what’s the point of the whole process? Just shove whatever features you want/need onto the language and be done with it.

Regarding import.meta. Instead of properly speccing out and designing a Loader (https://whatwg.github.io/loader/), the import keyword was turned into a not-really-a-keyword-not-really-a-function abomination. It quickly reached stage 3. Any and all concerns by people who discovered this and voiced their concerns were dismissed with no argument, and dynamic import is now everywhere.

Now, since there has been no proper design of the feature, a `meta property` is just tacked onto the already confusing mess that is `import`. Expect it to reach stage 3 within a week or so, and then we are stuck with it forever.

So, the question: why does TC39 even bother with the pretence of being transparent, o doing proper design on the language features etc.?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Matthew Phillips
whatwg/loader was too big of a spec. It was floated around in various forms for at least 5 years. Despite the very hard work of its champions it didn't garner enough implementer support. I think history has proven now that incremental improvements are more likely to succeed, so I'm happy to see import() and import.meta be able to go through the process at a relatively swift pace.

On Thu, Aug 3, 2017 at 4:43 PM, Caridy Patiño <[hidden email]> wrote:
Dmitrii, as stated by the champion of import.meta in the issue, issues/2 is one step of the process, in which we ask other members of the committee to review the spec text before it can be presented for stage 3. But you should be able to open other issues in that repo to voice your concerns about that proposal. Additionally, we have other channels, like this one, or via other members who can voice your concerns in upcoming meetings.

As for the particular feature that you’re referencing, I suggest you to look at previous discussions about `import`, and why it is different (a hint: it is different because like super, it needs some contextual information). As one of the champions of the whatwg loader, I can tell you that we spent many hours trying to figure the best course of actions based on the initial loader spec, and we believe `import` is the right thing to do. import.meta is just a progression of that decision.

/caridy

On Aug 3, 2017, at 4:10 PM, Dmitrii Dimandt <[hidden email]> wrote:

Can anyone enlighten me as to how any input on features that are rushed into the standard works?

What is the purpose of hosting TC39 on GitHub if no input is expected from anybody but TC39 members?


Somehow it’s already in stage 2. Which means: The committee expects to devote time to examining the problem space, solutions and cross-cutting concerns

Only reviews from committee members are expected, all other comments are locked out. If this makes it to stage 3 (and it will), it means: The committee expects the feature to be developed and eventually included in the standard

So what’s the point of the whole process? Just shove whatever features you want/need onto the language and be done with it.

Regarding import.meta. Instead of properly speccing out and designing a Loader (https://whatwg.github.io/loader/), the import keyword was turned into a not-really-a-keyword-not-really-a-function abomination. It quickly reached stage 3. Any and all concerns by people who discovered this and voiced their concerns were dismissed with no argument, and dynamic import is now everywhere.

Now, since there has been no proper design of the feature, a `meta property` is just tacked onto the already confusing mess that is `import`. Expect it to reach stage 3 within a week or so, and then we are stuck with it forever.

So, the question: why does TC39 even bother with the pretence of being transparent, o doing proper design on the language features etc.?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Bitovi
Development | Design | Training | Open Source

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

kai zhu

the rushed speccing of es6 modules is partly the reason people like me decided to join this discussion to voice opposition and provide inertia against such hugely disruptive changes in frontend programming.

i see this as a feature that primarily benefits companies with large code-bases and frontend teams.  its far too complicated to be useful for majority of smaller projects with 1-3 frontend devs, where attaching libraries to global namespace is not problematic at all.

On Aug 4, 2017 05:23, "Matthew Phillips" <[hidden email]> wrote:
whatwg/loader was too big of a spec. It was floated around in various forms for at least 5 years. Despite the very hard work of its champions it didn't garner enough implementer support. I think history has proven now that incremental improvements are more likely to succeed, so I'm happy to see import() and import.meta be able to go through the process at a relatively swift pace.

On Thu, Aug 3, 2017 at 4:43 PM, Caridy Patiño <[hidden email]> wrote:
Dmitrii, as stated by the champion of import.meta in the issue, issues/2 is one step of the process, in which we ask other members of the committee to review the spec text before it can be presented for stage 3. But you should be able to open other issues in that repo to voice your concerns about that proposal. Additionally, we have other channels, like this one, or via other members who can voice your concerns in upcoming meetings.

As for the particular feature that you’re referencing, I suggest you to look at previous discussions about `import`, and why it is different (a hint: it is different because like super, it needs some contextual information). As one of the champions of the whatwg loader, I can tell you that we spent many hours trying to figure the best course of actions based on the initial loader spec, and we believe `import` is the right thing to do. import.meta is just a progression of that decision.

/caridy

On Aug 3, 2017, at 4:10 PM, Dmitrii Dimandt <[hidden email]> wrote:

Can anyone enlighten me as to how any input on features that are rushed into the standard works?

What is the purpose of hosting TC39 on GitHub if no input is expected from anybody but TC39 members?


Somehow it’s already in stage 2. Which means: The committee expects to devote time to examining the problem space, solutions and cross-cutting concerns

Only reviews from committee members are expected, all other comments are locked out. If this makes it to stage 3 (and it will), it means: The committee expects the feature to be developed and eventually included in the standard

So what’s the point of the whole process? Just shove whatever features you want/need onto the language and be done with it.

Regarding import.meta. Instead of properly speccing out and designing a Loader (https://whatwg.github.io/loader/), the import keyword was turned into a not-really-a-keyword-not-really-a-function abomination. It quickly reached stage 3. Any and all concerns by people who discovered this and voiced their concerns were dismissed with no argument, and dynamic import is now everywhere.

Now, since there has been no proper design of the feature, a `meta property` is just tacked onto the already confusing mess that is `import`. Expect it to reach stage 3 within a week or so, and then we are stuck with it forever.

So, the question: why does TC39 even bother with the pretence of being transparent, o doing proper design on the language features etc.?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Bitovi
Development | Design | Training | Open Source

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: import.meta and TC39 process as a whole

Darien Valentine
In reply to this post by Dmitrii Dimandt
> their concerns were dismissed with no argument

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

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 before generic tooling for this sort of approach emerges (my own solution is pretty hacky, just wanted to see how it might work).

I love how it’s turned out so far. I haven’t used dynamic import yet though, and this is the first time I’m seeing complaints about web standards development being too efficient.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

kai zhu

> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Isiah Meadows-2
Inline 

On Fri, Aug 4, 2017, 02:47 kai zhu <[hidden email]> 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.

First, it would be very nice on the server side and in CLI applications to have a more efficient module system to implement, especially for larger applications and in desktop applications being built with Electron and NW.js, where startup time actually matters, and engines are presented with the opportunity to garbage collect unused parts of modules. 

Second, it pays off in spades on client side, due to much smaller bundles. We already have features primarily targeting browsers (shared array buffers and atomics - Node doesn't have threading support), so there's precedent, and I feel even if it has no value anywhere else, the need in the client side is more than enough. Oh, and having a module implementation built-in alleviates the need for a separate script loader, and it makes prototyping easier.

So there are pain points that having a good native module and script loader would solve very well. 


> 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.

Just because a feature exists doesn't mean you have to use it. I almost never use proxies or shared memory/atomics, because I don't need them. I also rarely use classes. You aren't obligated to use a feature you don't like - there's a *lot* of people who avoid classes like the plague. 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Dmitrii Dimandt
In reply to this post by kai zhu
I’ll reply to several emails with one, so as not to spread more-or-less similar texts over multiple small emails.

> whatwg/loader was too big of a spec. It was floated around in various forms for at least 5 years. Despite the very hard work of its champions it didn't garner enough implementer support. 

And the reason is: it was supposed to be a properly designed spec. That is why it was big. Because you either do it properly, or not at all

> I think history has proven now that incremental improvements are more likely to succeed, so I'm happy to see import() and import.meta be able to go through the process at a relatively swift pace.

No. These are not incremental improvements. These are ad-hoc solutions that beget more and more ad-hoc solutions. Calling it “incremental improvements” is putting slapstick on a pig.

Let’s take dynamic imports as a prime example of a horrible no-good ad-hoc solution and how it begat a horrible no-good ad-hoc solution in the form of import.meta.

import is a keyword. It’s scope and usage are known, simple, and understandable.

What is import()? It looks like a function, it behaves like a function (it’s invoked like a function, it accepts parameters like a function, it returns values like a function). Except it’s not a function. In *some* contexts it is a function:

    import(‘blabla’).then(() => …)

In *other* contexts it is not: 

   [‘bla’, ‘bla’].map(import) and others

To quote myself from an issue: "So, what is this new import? A new keyword? No. A builtin function on par with eval, parseInt et al? Why does it override the name of an existing keyword? Wouldn't it be better to introduce module-related functionality into a new global Module object exposing Module.import, Module.importAsync etc.?”

Well, the only somewhat-valid argument for the dynamic import is this:

> I suggest you to look at previous discussions about import, and why it is different (a hint: it is different because like super, it needs some contextual information).

Let’s consider this:

- super() is a *new* function-like keyword that doesn’t override behaviour of an existing one. It has its clearly defined place where it can be used, and, well, it is a function call as it ends up calling user-defined functions (etc. etc. etc., see https://github.com/tc39/proposal-dynamic-import/issues/23#issuecomment-263439543)

- the argument for context is especially funny considering how import.meta started

First of all, this is a language you design. There’s nothing stopping you from providing context to System.load. Or Loader.import, or…

Second. Let’s see how import.meta proposal started (https://esdiscuss.org/notes/2017-05-23#16iiia-accessing-host-specific-module-metadata-from-inside-a-module):

   > Probably a good idea to do import * as module from "js:context"

See? Since you scrapped proper implementation in favour of an ad-hoc solution eschewing common sense, now you scramble to find ad-hoc solutions to your ad-hoc solutions. Let’s just for a second assume you went with Module.import(). All of a sudden you’re free to extend Module with a Module.context or Module.meta, define it as Introspection API and have fun with it. Instead, you go for this (can’t find the link right now) in favour of import.meta:

  > Yes, we have new.target, super.* and function.sent as precedent

That is, you take horrible ad-hoc design decisions and present them as viable precedent. 

This morning literally in the span of time between stepping out of the shower and finishing my morning shave I came up with a solution that does away with new.target, function.sent and import.meta.

It’s called System.context (especially useful with https://github.com/tc39/proposal-optional-chaining)

    System.context.function.{sent, target, what,have,you}, System.context.module.{whatever,meta,info,you,might,want,to,slap,on}

See. Suddenly you have an infinitely extensible introspection API that you can (ab)use to your heart’s content instead of sodomizing the rest of the language. But that would require some sort of long-term thinking instead of ad-hoc (sorry, incremental) short-term solutions.

There is a reason PHP became a laughing stock in programming community. However, it took way more than 10 years to arrive at mysql_real_escape_string and \ as namespace separator. At the current rate JS will surpass PHP within a year or two.

On Fri, 04 Aug 2017 at 08:46 kai zhu <">kai zhu > 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Gil Tayar-2
In reply to this post by kai zhu
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Jordan Harband
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.

On Fri, Aug 4, 2017 at 12:20 AM, Gil Tayar <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

T.J. Crowder-2
In reply to this post by Gil Tayar-2
Could we please remember to keep posts on the list *professional*, *constructive*, and *courteous*?

I'm seeing a lot of frustration manifesting as rudeness here. The former is understandable. The latter is not constructive.

Thank you,

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Dmitrii Dimandt
In reply to this post by Jordan Harband
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 <">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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


On Fri, Aug 4, 2017 at 12:20 AM, Gil Tayar <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Jordan Harband
It can't be made syntax, because `var System = {};` is valid code, and we can't break the web. (seriously)

On Fri, Aug 4, 2017 at 12:31 AM, Dmitrii Dimandt <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


On Fri, Aug 4, 2017 at 12:20 AM, Gil Tayar <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Dmitrii Dimandt
But you can’t `var x = import`, for example. I guess you can’t `var import = {}`  either.

Hmmm… I wonder why…



On Fri, 04 Aug 2017 at 09:50 Jordan Harband <">Jordan Harband > wrote:
It can't be made syntax, because `var System = {};` is valid code, and we can't break the web. (seriously)

On Fri, Aug 4, 2017 at 12:31 AM, Dmitrii Dimandt <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


On Fri, Aug 4, 2017 at 12:20 AM, Gil Tayar <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss






_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Jordan Harband
Because it's been reserved syntax since JavaScript's inception, and System hasn't.

I'd recommend some light reading before attempting to continue arguing: https://mathiasbynens.be/notes/reserved-keywords

On Fri, Aug 4, 2017 at 12:53 AM, Dmitrii Dimandt <[hidden email]> wrote:
But you can’t `var x = import`, for example. I guess you can’t `var import = {}`  either.

Hmmm… I wonder why…



On Fri, 04 Aug 2017 at 09:50 Jordan Harband <[hidden email]> wrote:
It can't be made syntax, because `var System = {};` is valid code, and we can't break the web. (seriously)

On Fri, Aug 4, 2017 at 12:31 AM, Dmitrii Dimandt <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


On Fri, Aug 4, 2017 at 12:20 AM, Gil Tayar <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss







_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

T.J. Crowder-2
In reply to this post by Dmitrii Dimandt
On Fri, Aug 4, 2017 at 8:53 AM, Dmitrii Dimandt <[hidden email]> wrote:
>
> But you can’t `var x = import`, for example. I guess you can’t `var import = {}`  either.
>
> Hmmm… I wonder why…

Because `import` has been on the list of reserved or future reserved
words since *at least* ES3 (1999). I didn't go back further than that.

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Dmitrii Dimandt
In reply to this post by Jordan Harband
I’d recommend you assume your opponent has done some light reading. And I’d suggest you yourself read the links you post (that is, practice what you preach).

Multiple reserved keywords have been both added to the language and removed from the language. Because *the language evolves*.

However, you (and TC39 in general) keep insisting that short-sightedness and ad-hoc solutions is the only way forward for JavaScript.

You don’t like System, you think it cannot be used? Oh, introduce an `introspect` keyword. Introduce a `system` keyword. Heck, nothing stopped you from introducing a language-level built-in in the form of Symbol, what’s stopping you now?



On Fri, 04 Aug 2017 at 09:55 Jordan Harband <">Jordan Harband > wrote:
Because it's been reserved syntax since JavaScript's inception, and System hasn't.

I'd recommend some light reading before attempting to continue arguing: https://mathiasbynens.be/notes/reserved-keywords

On Fri, Aug 4, 2017 at 12:53 AM, Dmitrii Dimandt <[hidden email]> wrote:
But you can’t `var x = import`, for example. I guess you can’t `var import = {}`  either.

Hmmm… I wonder why…



On Fri, 04 Aug 2017 at 09:50 Jordan Harband <[hidden email]> wrote:
It can't be made syntax, because `var System = {};` is valid code, and we can't break the web. (seriously)

On Fri, Aug 4, 2017 at 12:31 AM, Dmitrii Dimandt <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


On Fri, Aug 4, 2017 at 12:20 AM, Gil Tayar <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss








_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

Dmitrii Dimandt
Let’s continue with the trend of light reading. Let’s see the multitude of things that are in JS, and no one bats an eye:

— start quote — 

Note that implementsletprivatepublicinterfacepackageprotectedstatic, and yield are disallowed in strict mode only.

You may have noticed I included eval and arguments in the list. These are not strictly reserved words, but they sure act like them — they’re disallowed in strict mode too.

Also, the (unlisted) NaNInfinity, and undefined properties of the global object are immutable or read-only properties in ES5. So even though var NaN = 42; in the global scope wouldn’t throw an error, it wouldn’t actually do anything. To avoid confusion, I’d suggest avoiding the use of these identifiers altogether, even though they’re not strictly reserved words.

— end quote — 

Oh, hello. What do we have here? Non-reserved words like they are reserved, and JS treating them in a special way.

So. The *only* reason *not* to introduce a proper global introspection API is?

On Fri, 04 Aug 2017 at 10:03 [hidden email] <[hidden email]> wrote:
I’d recommend you assume your opponent has done some light reading. And I’d suggest you yourself read the links you post (that is, practice what you preach).

Multiple reserved keywords have been both added to the language and removed from the language. Because *the language evolves*.

However, you (and TC39 in general) keep insisting that short-sightedness and ad-hoc solutions is the only way forward for JavaScript.

You don’t like System, you think it cannot be used? Oh, introduce an `introspect` keyword. Introduce a `system` keyword. Heck, nothing stopped you from introducing a language-level built-in in the form of Symbol, what’s stopping you now?



On Fri, 04 Aug 2017 at 09:55 Jordan Harband <">Jordan Harband > wrote:
Because it's been reserved syntax since JavaScript's inception, and System hasn't.

I'd recommend some light reading before attempting to continue arguing: https://mathiasbynens.be/notes/reserved-keywords

On Fri, Aug 4, 2017 at 12:53 AM, Dmitrii Dimandt <[hidden email]> wrote:
But you can’t `var x = import`, for example. I guess you can’t `var import = {}`  either.

Hmmm… I wonder why…



On Fri, 04 Aug 2017 at 09:50 Jordan Harband <[hidden email]> wrote:
It can't be made syntax, because `var System = {};` is valid code, and we can't break the web. (seriously)

On Fri, Aug 4, 2017 at 12:31 AM, Dmitrii Dimandt <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


On Fri, Aug 4, 2017 at 12:20 AM, Gil Tayar <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss









_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: import.meta and TC39 process as a whole

James M Snell
Dmitrii,

Quick aside: the rude manner in which you are communicating is interfering with your goal of convincing anyone. Perhaps if you tried not being so rude, people here would be more willing to listen to what you're saying.

- James

On Fri, Aug 4, 2017 at 1:09 AM Dmitrii Dimandt <[hidden email]> wrote:
Let’s continue with the trend of light reading. Let’s see the multitude of things that are in JS, and no one bats an eye:

— start quote — 

Note that implementsletprivatepublicinterfacepackageprotectedstatic, and yield are disallowed in strict mode only.

You may have noticed I included eval and arguments in the list. These are not strictly reserved words, but they sure act like them — they’re disallowed in strict mode too.

Also, the (unlisted) NaNInfinity, and undefined properties of the global object are immutable or read-only properties in ES5. So even though var NaN = 42; in the global scope wouldn’t throw an error, it wouldn’t actually do anything. To avoid confusion, I’d suggest avoiding the use of these identifiers altogether, even though they’re not strictly reserved words.

— end quote — 

Oh, hello. What do we have here? Non-reserved words like they are reserved, and JS treating them in a special way.

So. The *only* reason *not* to introduce a proper global introspection API is?

On Fri, 04 Aug 2017 at 10:03 [hidden email] <[hidden email]> wrote:
I’d recommend you assume your opponent has done some light reading. And I’d suggest you yourself read the links you post (that is, practice what you preach).

Multiple reserved keywords have been both added to the language and removed from the language. Because *the language evolves*.

However, you (and TC39 in general) keep insisting that short-sightedness and ad-hoc solutions is the only way forward for JavaScript.

You don’t like System, you think it cannot be used? Oh, introduce an `introspect` keyword. Introduce a `system` keyword. Heck, nothing stopped you from introducing a language-level built-in in the form of Symbol, what’s stopping you now?



On Fri, 04 Aug 2017 at 09:55 Jordan Harband <[hidden email]> wrote:
Because it's been reserved syntax since JavaScript's inception, and System hasn't.

I'd recommend some light reading before attempting to continue arguing: https://mathiasbynens.be/notes/reserved-keywords

On Fri, Aug 4, 2017 at 12:53 AM, Dmitrii Dimandt <[hidden email]> wrote:
But you can’t `var x = import`, for example. I guess you can’t `var import = {}`  either.

Hmmm… I wonder why…



On Fri, 04 Aug 2017 at 09:50 Jordan Harband <[hidden email]> wrote:
It can't be made syntax, because `var System = {};` is valid code, and we can't break the web. (seriously)

On Fri, Aug 4, 2017 at 12:31 AM, Dmitrii Dimandt <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


On Fri, Aug 4, 2017 at 12:20 AM, Gil Tayar <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss








_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
1234