3 ms·

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 f

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.

faichai 4y ago
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 4y ago
  I like the idea, but I'd recommend the name "ToffeeScript".
- phil294 4y ago
  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/test/typescript.coffee https://github.com/edemaine/coffeescript/blob/typescript/tes... [2] https://github.com/jashkenas/coffeescript/issues/5307 https://github.com/jashkenas/coffeescript/issues/5307
giancarlostoro 4y ago
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 https://github.com/onivim/oni2#introduction [1]: https://github.com/revery-ui/revery https://github.com/revery-ui/revery [2]: https://open-vsx.org/ https://open-vsx.org/
k__ 4y ago
I used LiveScript for some time, but I went with the crowd eventually.
WorldMaker 4y ago
> 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-only-way-to-use-js-switch-as-an-expression 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 https://github.com/tc39/proposal-pattern-matching More indirect: https://github.com/tc39/proposal-do-expressions 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 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 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/Reference/Global_Objects/Array/slice 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/Reference/Global_Objects/Array/at 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 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 https://github.com/tc39/proposal-array-equality

faichai 4y ago

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 4y ago
I like the idea, but I'd recommend the name "ToffeeScript".
phil294 4y ago
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/test/typescript.coffee https://github.com/edemaine/coffeescript/blob/typescript/tes... [2] https://github.com/jashkenas/coffeescript/issues/5307 https://github.com/jashkenas/coffeescript/issues/5307

giancarlostoro 4y ago

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 https://github.com/onivim/oni2#introduction [1]: https://github.com/revery-ui/revery https://github.com/revery-ui/revery [2]: https://open-vsx.org/ https://open-vsx.org/

k__ 4y ago

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

WorldMaker 4y ago

> 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-only-way-to-use-js-switch-as-an-expression 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 https://github.com/tc39/proposal-pattern-matching More indirect: https://github.com/tc39/proposal-do-expressions 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 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 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/Reference/Global_Objects/Array/slice 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/Reference/Global_Objects/Array/at 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 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 https://github.com/tc39/proposal-array-equality