| 13:56 | <devsnek> | its not possible to export * from something and then replace one of those exports with your own is it |
| 13:56 | <devsnek> | like `export * from 'fs'; export function readFile() {}` |
| 14:09 | <bradleymeck> | devsnek: sure you can |
| 14:10 | <bradleymeck> | https://tc39.es/ecma262/#sec-getexportednames step 9.c.i.1 |
| 14:12 | <devsnek> | oh interesting |
| 14:12 | <devsnek> | i thought all collisions were errors |
| 14:17 | bradleymeck | laughs nervously at ever thinking i've learned all of `export *` |
| 14:18 | <bradleymeck> | this came up in our APM example loader we did a few years ago (... this ESM stuff has taken too long) |
| 14:47 | <bradleymeck> | i still wish we had been able to add `default` back to `export *` |
| 14:47 | <bradleymeck> | just couldn't get consensus |
| 15:24 | <jridgewell> | Maybe time for `export default from ''`? |
| 15:26 | <bradleymeck> | jridgewell: that won't help |
| 15:26 | <bradleymeck> | jridgewell: cause you still need to know that '' has a default |
| 15:26 | <Bakkot> | `export { default } from ''` already works |
| 15:27 | <ljharb> | jridgewell: https://github.com/tc39/proposal-export-default-from |
| 15:27 | <jridgewell> | I think that requires people to understand that `default` is just a named export |
| 15:27 | <jridgewell> | It's easier for me to think about it as separate |
| 15:28 | <jridgewell> | Especially because it's teated separately in `export * from ''` |
| 15:29 | <ljharb> | i'd like that proposal to go forward, fwiw. default is special, it's not *just* a named export - it's just unfortunately implemented as one |
| 15:32 | <bradleymeck> | i don't think it should be considered special |
| 15:33 | <bradleymeck> | cause if you named an export "default" it would be really weird if it was a different thing |
| 15:35 | <ljharb> | it's conceptually special, regardless of what's observable |
| 15:40 | <bradleymeck> | special because of the a syntax or something else? |
| 15:42 | <ljharb> | i usually describe it to folks as: a default export is what a module *is*, a named export is something a module *has* |
| 15:44 | <jridgewell> | I've always looked at it like the difference between `module.exports = …` vs `exports.foo = …` |
| 15:44 | <bradleymeck> | i think thats a hard thing to think personally |
| 15:45 | <bradleymeck> | jridgewell: well you can kinda see how the `default` gets really gross if you think of it that way |
| 15:45 | <bradleymeck> | at least in node's issue tracker trying to do things like make __esModule interop work |
| 15:45 | <jridgewell> | In commonjs, yes it will. In our system, we don't have to mutate default to get similar behavior |
| 15:46 | <bradleymeck> | can you clarify that |
| 15:47 | jridgewell | Sorry, I thought you were talking about mutating the `module.exports = function foo() {}` |
| 15:48 | <ljharb> | bradleymeck: CJS only has a default export. |
| 15:48 | <jridgewell> | ^ that wasn't supposed to be a `/me`... |
| 15:48 | <Bakkot> | ljharb we have argued about that before |
| 15:48 | <ljharb> | `exports.foo` is people trying to shoehorn named exports into a module system without them. |
| 15:48 | <jridgewell> | Then doing a `foo.bar = other`, so that you can `const { bar } = require('')` |
| 15:48 | <Bakkot> | ljharb CJS has a different notion of exports than ES modules; I don't think "CJS only has a default export" is really a meaningful claim |
| 15:49 | <Bakkot> | "default export" is a concept which makes sense in the context of ES modules, not CJS modules |
| 15:49 | <ljharb> | i mean, CJS only exports a single value |
| 15:49 | <ljharb> | but sure, fair |
| 15:49 | <Bakkot> | yeah, that claim I can agree with |
| 15:49 | <ljharb> | (also the concept of default exports in ESM was added for the purposes of matching CJS, iirc) |
| 15:50 | <Bakkot> | yeah, that was the original sin |
| 15:50 | <ljharb> | that is certainly one take |
| 17:59 | <devsnek> | bradleymeck: what would you think about `export get function whatever() {}` |
| 17:59 | <devsnek> | so you could wrap live bindings |
| 17:59 | <ljharb> | ew |
| 17:59 | <bradleymeck> | we talked about it previously |
| 18:00 | <bradleymeck> | i have no strong feelings but replacing it gets weird, would it always call that identifier if accessed or would that be a "non-configurable" export? |
| 18:00 | <bradleymeck> | right now fn decls can be replaced |
| 18:00 | <ljharb> | that would expose a new ability tho |
| 18:01 | <ljharb> | currently you can't replace a live binding as a *response* to someone importing it |
| 18:01 | <ljharb> | iow with a getter it seems like you'd be able to count imports |
| 18:02 | <devsnek> | not imports, accesses |
| 18:02 | <ljharb> | ah ok so `import { whatever }` wouldn't trigger it, but referencing `whatever` would |
| 18:02 | <ljharb> | ok so then that seems even worse :-) |
| 18:02 | <ljharb> | you can't do that on variables now |
| 18:02 | <devsnek> | i think any useful abstraction here, not just `export get`, would have that |
| 18:03 | <devsnek> | or you would have to be aware of changes within the module you're wrapping |
| 18:03 | <devsnek> | Object.observe lol |
| 18:09 | <Bakkot> | yeah that's terrible |
| 18:10 | <Bakkot> | local references should not cause side effects |
| 18:10 | <Bakkot> | strongly affirmed |
| 18:11 | <jackworks> | those reasons are also applyable for falsy evaluation of document.all. 1. it's increasing engine maintaining cost; 2. security problems happened for this behavior |
| 18:11 | <jackworks> | IMO if we can remove this big feature from the language, we should also remove document.all == false |
| 18:12 | <ljharb> | jackworks: i think to change anything about document.all you'd have to prove it was web compatible to do so |
| 18:12 | <jackworks> | it's even smaller and won't break much sites as restring subclass ability |
| 18:13 | <jackworks> | yeah, we can collect a list of classic sites that using document.all == false and no longer maintaining, then only let document.all == false on those sites |
| 18:14 | <ljharb> | jackworks: browsers have refused to do that in the past |
| 18:14 | <ljharb> | but you could certainly ask :-) |
| 18:14 | <jackworks> | is there a good reason for that? 🤔 |
| 18:16 | <jackworks> | I have to say I think [[IsHTMLDDA]] is poisoning the spec text |
| 18:16 | <rkirsling> | priority of constituencies |
| 18:16 | <devsnek> | (https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) |
| 18:16 | <ljharb> | ^ that. the spec text can be as ugly as it needs to be to ensure things work properly for users |
| 18:17 | <rkirsling> | we couldn't get rid of it but we *could* give it a passive-aggressive name :p |
| 18:17 | <rkirsling> | hence IsHTMLDDA |
| 18:17 | <devsnek> | MISTAKESWEREMADEDDA |
| 18:17 | <jackworks> | can leave this [[IsHTMLDDA]] extension in the HTML spec since only HTML is using it. and only exact 1 object has this internal slot |
| 18:18 | <ljharb> | jackworks: the reason it was added to the JS spec is to remove the willful violation from HTML |
| 18:18 | <devsnek> | yeah it used to be in the html spec |
| 18:18 | <ljharb> | jackworks: we can't remove the slot from JS without HTML having to restore the willful violation in equality semantics |
| 18:19 | <jackworks> | > you'd have to prove it was web compatible to do so; Yes, it should be proved to be safe, but how? I can't access telemetry data from Chrome or Firefox afterall. |
| 18:20 | <ljharb> | you'd have to make the case to one or more browsers to ship counters |
| 18:21 | <jackworks> | [[IsHTML_document.all]] lol |
| 18:21 | <ljharb> | that's what we have already yes |
| 18:24 | <Bakkot> | jackworks yeah there is zero chance removing document.all would be web-compat |
| 18:24 | <Bakkot> | and shipping the list of sites where it would work would bloat browsers by at least megabytes, probably more |
| 18:24 | <Bakkot> | jackworks you could ask Chrome or Firefox to explore it |
| 18:25 | <jackworks> | > there is zero chance removing ... would be web-compat \n yes, and this argument also works for the builtin subclass restriction |
| 18:26 | <ljharb> | jackworks: except there's tons of sites that use document.all from the olden days |
| 18:26 | <Bakkot> | jackworks I don't think that's actually true |
| 18:26 | <ljharb> | there's unlikely to be many, or even any, that have shipped subclassing in the last 5 years |
| 18:26 | <Bakkot> | it is an emperical question |
| 18:26 | <Bakkot> | you can make a custom build of a browser that does not have built-in subclassing, and see what breaks, and do the same for document.all |
| 18:27 | <ljharb> | (less than 5; `class` hasn't been web compatible for all 5 years) |
| 18:27 | <Bakkot> | and it is my strong belief that far more websites will beak in the latter case |
| 18:27 | <ljharb> | don't break the space jam movie website |
| 18:29 | <bradleymeck> | jackworks: we are actively crawling the sites like those in https://www.chromestatus.com/metrics/feature/timeline/popularity and via http-archive audits to trap any actual usage of species |
| 18:29 | <bradleymeck> | and removing it doesn't actually break things / things are using @@species in ways that break the actual usage of it |
| 18:29 | <jackworks> | `class` hasn't been web compatible for all 5 years \n This can convince me, thanks @ljharb , but I'm still feeling not good in the inconsistency of treating delete IsHTMLDDA or subclassing builtins |
| 18:29 | <bradleymeck> | so thats why it doesn't appear to be so breaking |
| 18:30 | <Bakkot> | we can't remove every terrible thing, alas |
| 18:30 | <Bakkot> | but if we investigate and discover we can, great |
| 18:31 | <bradleymeck> | document.all is something like 20% of all sites https://www.chromestatus.com/metrics/feature/timeline/popularity/83 vs Array[@@species] which is at 0.006% |
| 18:31 | <jackworks> | that's surprising me, why over 25% sites are using document.all? |
| 18:31 | <bradleymeck> | who knows |
| 18:32 | <ljharb> | i'd bet more than 25% of all sites have barely been touched in 20 years |
| 18:32 | <jackworks> | is it hiding in a popular library like mootools 🤔 |
| 18:32 | <ljharb> | i'm sure it's hiding in old versions of many popular libraries |
| 18:32 | <ljharb> | i used it in the mid-2000s as part of browser detection code |
| 18:33 | <bradleymeck> | ljharb: yea but even then if they are accessed this year does it matter? |
| 18:33 | <rkirsling> | my passive aggression comment wasn't completely a joke btw |
| 18:34 | <ljharb> | bradleymeck: yes |
| 18:34 | <rkirsling> | if we wanted to *justify* the thing's existence we'd've called it MasqueradesAsUndefined or something |
| 18:35 | <jackworks> | curious, I thought most of the users are accessing modern sites like youtube twitter etc so the usage won't be too high |
| 18:37 | <ljharb> | jackworks: iirc it's not about usage, it's about sites |
| 18:37 | <ljharb> | or maybe both, i'm not sure how browsers analyze the data |
| 18:41 | <Bakkot> | chrome web stats is page loads |
| 18:41 | <Bakkot> | so more popular ones are counted more heavily |
| 18:42 | <ljharb> | ah ok, gtk |
| 18:43 | <jackworks> | > if we investigate and discover we can, great \n that make sense 🎉 |