[thrwawy74]

I still use coffeescript over javascript because I feel like I can be as expressive as I want. I understand why most left for typescript (type safety), but I feel like everyone just gave up on reducing boilerplate for things in javascript. Switch statements, list comprehensions, array slicing, better equality operators... a lot of things that made coffeescript a great experience have never carried over.

[giancarlostoro]

I never tried CoffeeScript since nobody pays me for it, though I am curious about ReasonML as an alternative, there's a Neovim front-end[0] coded in Reason that compiles natively[1], and supports existing VS Code plugins from the VSCodium plugin repository[2] which I still have yet to look at how the heck they pulled that bit off, but it is pretty interesting.

My thinking is, not only can I do amazing front-end stuff on the web, but I can do front-end GUI applications that aren't reliant on Electron thanks to OCaml magic.

[0]: https://github.com/onivim/oni2#introduction

[1]: https://github.com/revery-ui/revery

[2]: https://open-vsx.org/

[faichai]

I loved it to. I'd love to make a typed coffeescript variant, which transpiles to TypeScript rather than JavaScript. My pet name for this is `tycoscript`.

[anon_123g987]

I like the idea, but I'd recommend the name "ToffeeScript".

[phil294]

This already exists, see [1]. Development has a bit stalled, but afaik the author wants to keep pursuing it. There's even a Discord server for this kind of project, see also this GitHub thread [2] where CS+TS is being discussed in general. Alternatively, you can code in Coffee with JSDoc type annotations, yielding a near-TypeScript experience in both IDE and output, albeit the annotation syntax can be a bit annoying, ironically.

[1] https://github.com/edemaine/coffeescript/blob/typescript/tes... [2] https://github.com/jashkenas/coffeescript/issues/5307

[k__]

I used LiveScript for some time, but I went with the crowd eventually.

[WorldMaker]

> Switch statements

JS has had switch statements for a long time. Do you mean switch "expressions" that can be used inline? It's not pretty but JS has long supported that too using either eval() "hacks" or IIFEs: https://stackoverflow.com/questions/32451049/is-eval-the-onl...

Do you mean pattern matching? There are two Stage 1 TC39 proposals with different approaches to it:

More hands-on/direct: https://github.com/tc39/proposal-pattern-matching

More indirect: https://github.com/tc39/proposal-do-expressions

> list comprehensions

There are several libraries with strong Iterator support today that while not syntactically gorgeous do great jobs at allowing you to write simple list operations. Off the top of my head are IxJS and iter-tools, but also classic mainstays like up to date versions of lodash and Ramda.

There's a Stage 2 proposal to bring more of them into "the standard library": https://github.com/tc39/proposal-iterator-helpers

There's also a Stage 2 proposal for an operator to make the syntax generally nicer no matter the library: https://github.com/tc39/proposal-pipeline-operator

> array slicing

Array.prototype.slice() was added back in ES2015: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Array.prototype.at() was "just added" in ES2022 for unary (single argument) "slice" (ability to use negative indexes): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

If you prefer syntax to function calls, there's a Stage 1 proposal still live for that: https://github.com/tc39/proposal-slice-notation

> better equality operators

That ship has probably sailed. Most projects at this point just have linter rules to standardize everything to the more reliable "triple equals" (===, and !==).

There are proposals for more structural equality functions in the standard library, though, for instance: https://github.com/tc39/proposal-array-equality