In typical implementations, I don't think that's true, since all engines have Latin-1 and UTF-16 representations, but not UTF-8

I really like Mark’s thing of recording and posting his presentations. It’d be great if we can make this an option for presenters all the time, and post the presentations to a TC39 YouTube channel, for presenters who want it.

Is V8’s one-byte string Latin1? When I wrote the UTF-8 parser, it would create 2 byte strings once you went over 0x80

v8 has two types of strings, one-byte (latin1) and two-byte (not quite utf-16 but ucs... something... maybe ucs-2)

I don't know if WTF-16 is the right term for that (https://simonsapin.github.io/wtf-8/#ill-formed-utf-16)

a Latin-1 string representation is identical to a byte array, where the Unicode character values would just be the byte values

and interestingly, it also has an utf-8 decoder which is used during streaming parsing, it can do stuff like pause mid-character if we need to wait for more data from the network. so in that case we don't use chromium's utf-8 decoder but our own

Justin Ridgewell: no, not that one. maybe there is another one you wrote :)

we can unify these if your version can also pause mid-character to wait for more data

google says "UCS-2 is fixed width, UTF-16 is variable width with a minimum of two bytes and a maximum of four bytes." << what about this part? no idea what v8 does here

ok how did we end up here? what does "Strings will deoptimize pretty quickly once you store non-utf8 bytes" mean? one thing that's not great about onebyte vs twobyte is that if you have one non-onebyte character in your string, the whole string has to be stored as a twobyte and it's slightly unnecessary overhead.

(but i don't see a way around it in the current world unless we add utf-8 strings and... i don't think anyone wants to... strings are incredibly complex as is)

Isn't the clamping just value & 256?

if all those steps are just value & 255 then an editorial cleanup would certainly have helped :-)

right but what are we solving exactly rn?

Wait sorry it's not value & 255 lol I'm too tired it's if (number > 255) return 255; if (number < 0) return 0; return number;

is math.clamp more general than the dataview methods? i'm not opposed to it, would be good to see which everyday things are being improved

is math.clamp more general than the dataview methods? i'm not opposed to it, would be good to see which everyday things are being improved

written it at least a few times for webapps in the past

Yeah it doesn’t really have to do with data views, it’s just like you give a min and max and return one of those if you are out of bounds

there is a ~new math.clamp proposal that lacks a champion btw

https://github.com/Richienb/proposal-math-clamp which I may if no one else wants :^)

liquid volume remains solidly imperial for cooking, in the US

also gasoline and milk

you don't use volume in baking

wait what else would cake mix come in but a box

https://abcnews.go.com/Lifestyle/man-spends-months-1500-make-sandwich-scratch/story?id=33802231

What if the module exports then?

web compat, people were already relying on thenable modules in production

web compat, people were already relying on thenable modules in production

Is it a real production or just toy project?

where do you put this, inside step 9 of https://tc39.es/ecma262/#sec-promise-resolve-functions?

I don't know if that's true

web compat, people were already relying on thenable modules in production

I want to see a future where WASM module instantiation is handled transparently in the ESM universe. WASM source imports are a step in the right direction, but I want to see instantiation handled via import defer at some point. And dynamic loading of WASM sources is definitely a use case.

I assumed the idea was that you'd know the names before triggering evaluation

Import source + import() covers some of these cases though

Well, also const wasm = import.source(...) + WebAssembly.instantiate(wasm) covers it in a sync way

It was briefly mentioned.

I want to see a future where WASM module instantiation is handled transparently in the ESM universe. WASM source imports are a step in the right direction, but I want to see instantiation handled via import defer at some point. And dynamic loading of WASM sources is definitely a use case.

I assumed the idea was that you'd know the names before triggering evaluation

The problem is the function coloring…

This exactly. My understanding is that all exported names of a module are known without evaluating the module. That means technically we could model this as an object with known props and the first access (get, gOPD) on one of these props would trigger the evaluation of the module. That way the import.defer of a non thenable module does not trigger the evaluation of the module. But if the module is thenable, then of course the regular promise logic will trigger evaluation when it does a get of then

I was discussing with Yulia last night that you could import + from ‘js:operators’, and have that perform the left + right -> left.add(right) change

but yea ast rewriting, ill talk about it when my thing comes up

if you haven't read rewriting the technical interview you really should, but thats a digression

Someone is attributuing @justingrant's comments on JS0 to me in the notes

Maybe because I forgot to add myself (JGT) to the attendees list in the notes? I'll fix that now. Want me to fix up the notes too?

Does JSSugar open doors for a "blessed" type system? Or rather, would type annotations likely become a JSSugar feature?

Does JSSugar open doors for a "blessed" type system? Or rather, would type annotations likely become a JSSugar feature?

which file systems allow emoji in file names?

DOS?

I meant FATTTTT :((((

index.es2021

classes and TDZ are the most prominent ones

Profiling classes is my hobby. I have not seen any lingering issues.

How much slower are classes these days, after those optimizations you mentioned?

gotta ask a more specific question

class NewSkol { field = 1 }
vs
function OldSkol() { this.field = 1 }

I assume these are very close in performance these days? Assuming Object.prototype hasn't been patched

Side note: Do we know which old features are slow? I only know of the TDZ issue. We run most of our production code using very modern untranspiled ES2023/ES2024. Performance has not been problematic, and is obviously is much faster than if we downlevelled private field usage or async usage.

and we've chatted about this before, but we should have designed it to be more static so the elision optiimzation can still apply

no, the super() can't be elided thing is actually directly shown by a transpiler optimization that can no longer apply to ES6 classes that used to apply to ES5 classes

Omitting this checks after super() is probably one of the most complex optimizations we have to do in Babel due to the performance cost, and indeed there I'd expect engines to not be able to do it on-the-fly.

I'd be curious to see though if a Babel-transpiled subclass constructor is indeed faster than the same code running natively.

when i was looking into it, i noticed that one thing classes can't do is omitting super ctors. some tools, when they notice the super ctor doesn't do anything interesting, just omit it when doing old-style classes. or they inline the super ctor workload into the subclass ctor and then omit it.

early prototypes of TypeScript experimented with a class syntax like class C(a, b) { } prior to the actual class syntax being standardized, which combined the constructor with the class name. C# actually has that now too.

Could structs just be "class V2"? Is there any good reason to use classes if we get structs? (assuming that they'll support private state)

what's the concrete thing you're thinking of? a different keyword than struct? or the messaging?

We could always introduce slight alternatives to the class syntax that would make super() invocation implied, such as class C(a, b) extends Super() {}

This is difficult to square with this: should references to an and b be spelled as this.a or just a? If bare, does it follow lexical scoping semantics or this semantics?

IMO, we should have had something like constructor() : super() { } akin to C++ or C#

idk the exact overhead but i assume it's non-zero

i was referring to TS, littledan

restricting things to ast transform would reduce complexity. right now you have free reign in what you can do, and that can introduce new bytecode operations etc. if its an AST transform, it is quite literally sugar as it can be rewritten

good luck designing, getting consensus, and getting people to adopt given TS :)

it's baking time with the world

can you elaborate? not familiar with the wasm usecase so well, so i don't know how import.defer solves this better than import source + import()

Is it a real production or just toy project?

i wish they were better funded too and it's a structural issue the ecosystem needs to solve with incentives, not TC39, but it also doesn't follow from that fact that browsers need to do it