358 karma · joined March 8, 2016
I have one piece of feedback for him about the code itself, in case he's interested (of course the important part is the game, not the code, but I'm more qualified to give feedback on the JS): put `"use strict"` at the top of every <script>.
That's actually exactly what Figma is doing for their plugins. [1] Seems to be working ok, though not without some pain [2].
[1] https://www.figma.com/blog/an-update-on-plugin-security/
I appreciate that this is mostly just a generic rant, but it's not really suitable here, because this is a feature which is being added with the sole goal of improved performance.
There's only so much you can to optimize the extremely dynamic regular objects in JS, and there's no hope of using them for shared-memory multithreading. The purpose of this proposal is to have a less dynamic kind of object which can be made more performant and which can be made suitable for shared-memory multithreading.
I put it on npm primarily so I could send things to other JS developers an absolute minimum of fuss: one command, total, instead of installing a tool and then running the command.
I still cannot imagine why Apple decided that you shouldn't have a visible volume indicator in the menu bar when you have headphones connected. I mean, really?
> This reverts commit e0abdadcc6e1. [...] Its not clear to me why this commit was made.
Anyone dug up the history here?
[1] https://lore.kernel.org/all/20240120215012.129529-1-fw@strle...
https://www.phind.com/agent?cache=clsxs6doj000wl008yk8wb4k8
It pointed out the lack of alt-text as well as a couple other issues. Some of the suggestions aren't applicable, but it's not bad as a starting point.
In my experience the most common cause of breaking changes is accidentally breaking on older versions of the runtime, because the project is only running tests on the last version or two. Aside from that, the only notable example I can think of in the last year was a pretty subtle bug in what was supposed to be a pure performance optimization in a query language [1]. I think these are pretty representative, and not meaningfully worse than the experience in other languages.
And in a lot of cases it's not obvious that your code is going to be incompatible. For example the most recent case there was code which was like `function foo(x) { if (x.group) x = x.group; /.../}` where that function was being called with `foo({ group: [...] })` or `foo([...])`. That code breaks if `Array.prototype.group` is added. No one is going to figure that out themselves unless they test on a version of a browser which ships `Array.prototype.group`, and empirically no one does that.
Yes, we could find a way to break fewer pages than flash EOL broke. But even just a handful of pages people actually use is too much. No browser wants to ship an update which will break (to pick a relevant example) the website of the government of Brazil, even if they somehow "ought to have" updated their code before that update. Developers are empirically not going to do that update and browsers are not going to punish the users of the pages of those developers by breaking them.
As to versioning the language: languages like Rust and Go use editions, which allow them to making breaking changes to syntax but not to the standard library, which is what's being discussed here. Indeed Rust has several deprecated-but-unremovable things in their standard library. Python makes breaking changes to their standard library, and then people's code breaks. C++ requires you to specify the version for the entire program, which isn't viable for JS because pages mix scripts from dozens of authors, which all need to interact and to have a coherent view of the world. Not sure what other language you're thinking of.
The relatively unique object model in JS, and the fact that the standard library consists of ambient properties, also makes it special; it's harder in JS than it would be in a language like Rust to detect use of a particular feature of the standard library.
Regarding versioning, see the immediately preceding question in the FAQ.
But a method named `groupBy` on iterators traditionally means a different thing: https://github.com/tc39/proposal-array-grouping/issues/51#is...
Global iterable type it's too late for, since there's many extant iterables in the language and on the web which don't have it in their prototype chain and can't reasonably be changed.
Browsers aren't going to break old pages.
It might be better to have some other tool to do pluggable static analysis, but the fact is that there isn't one. And eschewing project-specific static analysis entirely would be giving up far too much.
> Input audio is split into 30-second chunks, converted into a log-Mel spectrogram, and then passed into an encoder.
Just needs another maintainer's stamp.
Just needs another maintainer's stamp.
> The Whisper v2-large model is currently available through our API with the whisper-1 model name.
For example, "replace an element" is
ele.parentNode.replaceChild(newEle, ele);
ele.replaceWith(newEle)
Similarly, "loop over a nodelist" wants you to use array spread and then forEach, instead of just
for (let ele of nodelist) ...The thing that I'd actually want for your case is either a TransformStream for byte stream <-> base64 stream (which I expect will come eventually, once the simple case gets done; it's also easy in userland [1]), or something which would let you read the entire stream into a single Uint8Array or ArrayBuffer, which is a long-standing suggestion [2].
---
> Why does de-chunking a byte array need to be complicated
Keep in mind the concat proposal is _very_ early. If you think it would be useful to be able to concat Uint8Arrays and have that implicitly concatenate the underlying buffers, [3] is the place to open an issue.
---
> You have made me realize I don't even know what the right venue is to vote on stuff. How should I signal to TC39 that e.g. Array.fromAsync is a good idea?
Unfortunately, it's different places for different things. Streams are not TC39 at all; the right place for suggestions there is in the WHATWG streams repo [4]. Usually there's already an existing issue and you can add your use case as a comment in the relevant issue. TC39 proposals all have their own Github repositories, and you can open a new issue with your use case.
Concrete use cases are much more helpful than just "this is a good idea". Though `fromAsync` in particular everyone agrees is good, and it mostly just needs implementations, which are ongoing; see e.g. [5]. If you _really_ want to advance a stage 3 proposal, you can contribute a PR to Chrome or Firefox with an implementation - but for nontrivial proposals that's usually hard. For TC39 in particular, use cases are only really valuable pre-stage-3 proposals.
[1] https://github.com/lucacasonato/base64_streams/blob/7c4ed815...
[2] https://github.com/whatwg/streams/issues/1019
[3] https://github.com/jasnell/proposal-zero-copy-arraybuffer-li...
return `data:application/octet-stream;base64,${(value as Uint8Array).toBase64()}`;
There is a _very_ early stage (as in, it's literally just an idea one person had, which may never happen) proposal [1] to do zero-copy ArrayBuffer concatenation, which would further simplify this - once you'd collected the chunks you could `value = new Uint8Array(ArrayBuffer.of(chunks.map(chunk => chunk.buffer))` instead of manual concatenation.
Finally, there's the Array.fromAsync proposal [2] and/or async iterator helpers proposal [3] (which I am also working on), which would make it easier to collect the chunks. Putting these together, you'd get something like
if (isReadableStream<Uint8Array>(value)) {
const chunks = await Array.fromAsync(value);
if (chunks[0].byteLength) {
value = new Uint8Array(ArrayBuffer.of(...chunks.map(chunk => chunk.buffer)));
} else {
throw new Error(`Unrecognized readable stream type: ${ chunks[0].constructor.name }`);
}
}
return `data:application/octet-stream;base64,${(value as Uint8Array).toBase64()}`;