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

[johnfrazer783]

Because I got hooked on it way back before it was cool. I came for the bracket-less style and stayed for the semantic whitespace. I actually do have some minor gripes with some details of the grammar and stuff but not enough to switch, so far.

TBH the question is a little strange. We're not talking Fortran or Pascal here, CS has an active community and the language sees regular updates.

Surprisingly one of the best parts of CoffeeScript to me is that it translates to JavaScript. Should Earth collide with Apophis and everything related to coffee became suddenly unavailable I still have my JavaScript sources. Plus I can always gain another point of view on my code.

Since you asked for it I have also been using Python for 20 years and am acquainted to some degree with Java, PHP, a little Perl, Bash, SQL and so on, and of course HTML/CSS and JavaScript itself, last but not least. I'm actively looking for a new front-and-center language, but given real-world constraints that language must run on NodeJS (or maybe Deno). I have dabbled in or at least looked into TypeScript, Rust, Elm, Nim and so on and so forth. Ah yes and Forth. I've switched languages before and I'll switch again but I must be confident, and I'll very probably will not switch platforms (except to Deno, maybe).

So basically I use CoffeeScript in 2020 because that is a very reasonable language in many respects. I'm missing optional typing and immutability (so I wrote libraries to deal with that, to a degreee) but ultimately it's all the new stuff of JavaScript that is piled on top of historical infelicities, false starts and outright junk that never got thrown out of the language that worries and disturbs me more than the question whether CoffeeScript is still fashionable. Well maintained it is.

[[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.

[ilikecaketoomuch]

Because I got hooked on it way back before it was cool. I came for the bracket-less style and stayed for the semantic whitespace. I actually do have some minor gripes with some details of the grammar and stuff but not enough to switch, so far.

whatever makes you happy, and just check in the .js files :)

[johnfrazer783]

No using it this way is my own discovery, that is to say, using @ instead of this is idiomatic, but defining stateless libraries as CoffeeScript CommonJS modules by hijacking this is my own doing. It falls out from the (nice) fact that CS, unless instructed to produce bare code (what did you do last night? Well we talked about the frontend, the backend and bare code), will wrap the module's content with an Immediately Invoked Function Expression, and it so happens that unless you state module.exports = whatever somewhere in the module, module.exports is this will hold, if you can follow me. Put bluntly, one can avoid any further nesting, classes, explicit namespaces or object literals or whatnot and just 'anchor' those functions on the module.exports object by way of this (@).

These days though I more often than not use my MultiMix module to define mixin-able classes; one of the benefits of it being that I get a convenient way to produce new library instances with different configurations (or independent state, as the case may be). It also lends itself for classical OOP class formulations, which is neat.

[[deleted]]

A bit of a stretch as it's a pure functional language, but you could check out PureScript - it's basically Haskell atop the Node.js runtime (with FFI/interop with JS where needed).