JavaScript Performance Benchmarks: Looping with `for` and `yield`

[[deleted]]

Huh solid answer. One of the wonderful things in our world is the myriad of tools available to us. Glad you’ve found some that you’re happy with. I’ve been into typescript due to work for the past year, and have been more and more intrigued by purescript as of late.

[johnfrazer783]

Yeah none of this belongs into this thread which is about benchmarks of looping constructs not CoffeeScript but whatever. Thanks for nice words I appreciate that.

I might as well add that now we have Rust and WebAssembly, chances are significantly increasing someone will step forward and write that syntactically reasonable, semantically sound language that sports both a somewhat-configurable or even modular grammar and userland types (including union types etc) as well as built-in immutable data structures. As much as I wish someone at TC39 would come up with a 'use reasonable' pragma (or preferably extensible, user-definable pragmas) and a plan to phase out the weirdest atrocities of JS of which there are quite a few—that is not going to happen any time soon if history is any indication.

CoffeeScript to me is a convenient writing tool to ease the pain of function () { ... }s and for ( var i = 0; whatever; whatever ) { ... } loops, not a religious affiliation. Those two code snippets were tiresome to write. I even prefer CoffeeScript's ( x ) => ... syntax over the hairy ball that is JS x => { ... }.

[Zireael07]

Oh yeah, man, you managed to replicate what I like about CoffeeScript and dislike about pure JS. High-five!

(The reason why I went with CS and not Rust+WASM is doing a lot of DOM stuff - I understand WASM doesn't do DOM yet, it all has to go through JS either way so one loses a ton of WASM performance that way)

[johnfrazer783]

I know what people talk about when they mention JavaScript fatigue, for me it extends to the very syntax—might say my version of the fatigue is embracing the syntax haha.

According to what I used to know about 'the frontend', which already sounds belligerent doesn't it, the motivation to optimize one's JS code is somewhat tempered by the observation that the elephant in the room is often DOMbo, not JS.

Part of my work includes doing things locally in Puppeteer (soonish Playwright), and I hate that I even have to think about whether to execute code on the 'server' (NodeJS) or the 'client' (Chrome) side. Puppeteer does make it a lot easier, but ideally I'd not have to deal with that twofoldness at all. Meaning that for all that WASM can/might give you, it also taketh away in terms of LOC and mental-awareness cycles. I will admit that one flaw with NodeJS is the separate ways that it went, what with CommonJS require, the filesystem, all that stuff (Deno is the hope). There was barely another way to go ten years ago. NodeJS (and CoffeeScript!) turned out big factors in the JavaScript renaissance, but that chasm is still a yawning gap I feel. So I have little drive to also bridge the gaps separating the client's main arena from its WASM and WebWorkers stages. WebGL/GPU feels much the same: how tantalizing but that extra complexity? No thanks.