> 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
> 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 bundl
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 fronten
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
imp
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 abou
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)
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 sta
On Thu, Aug 3, 2017 at 10:18 AM, James Browning
wrote:
>
> The 1, 1 would happen if you decided that `[a, ...rest, b]` read
> in both directions (although personally I'm not a fan of this
> approach)...
Gotcha. Yeah, having it duplicate things would seem wrong. :-)
> One option could be (althoug
I think T.J. had the most intuitive logic (and this has been mentioned in
previous threads too), where non-rest parameters have priority:
```
const [a, ...rest, c] = [1] // -> 1, [], undefined
const [a, ...rest, c] = [1, 2] // -> 1, [], 2
const [a, ...rest, c] = [1, 2, 3] // -> 1, [2], 3
```
If y
The 1, 1 would happen if you decided that `[a, ...rest, b]` read in both
directions (although personally I'm not a fan of this approach) e.g.
```
const arr = [1]
const [a, ...rest, b] = arr
// Roughly equivalent to:
const [a] = arr.slice(0, 1)
const [c] = arr.slice(-1) // So they get duplicated
c
Jan-Ivar Bruaroey,
You are perhaps conflating asynchronicity with non-linearity.
Many asynchronous data flows are most definitely linear.
Hence the great benefit in code cleanliness afforded by `await` `async`.
I've concluded that a lot of stream-like functionality can be achieved
already with
On Thu, Aug 3, 2017 at 5:44 AM, James Browning
wrote:
>
> Given the above, it should really just be the case that
> `[...rest, last]` would just be the same as destructuring the
> reversed array, then re-reversing the rest part
Or the other way to think of it, since as you say it's going to end u
12 matches
Mail list logo
