5 ms·

Civet: The CoffeeScript of TypeScript

20 points by Yahivin 4y ago

Yahivin 4y ago
I created this new transpiled language to bridge the gap between CoffeeScript and TypeScript. It's getting really good these days!
- tmm84 4y ago
  I really like this idea. Brings back the good feeling I would get with CoffeeScript's syntax being shorthand for what I would write in JS but targeted at TS. I hope this stays around and gets some traction.
  - Yahivin 4y ago
    Me too! I've been porting over some of my Coffee projects into Civet and fixing issues as I encounter them. It's getting better all the time.
- graypegg 4y ago
  Cool project! It’s cool to read thru the list of what you’ve added from Coffeescripts behaviour and not. Reminds me of some things I still miss from Coffeescript!
- wdavidw 4y ago
  I have been searching in the past for such a project. Great initiative
solardev 4y ago
What is CoffeeScript and why would you use it in conjunction with TypeScript?
- graypegg 4y ago
  Coffeescript [1] was a flavour of JS syntax meant to look similar to Ruby [2] syntax. You just compiled it back to JS. It was nice for working on Rails [3] projects since it made everything feel more “cohesive”. I assume this project is here for older Coffeescript [1] projects who want to start using typescript, and need access to interfaces/types that were present in old CS files. [1] https://coffeescript.org/ https://coffeescript.org/ [2] https://www.ruby-lang.org/en/ https://www.ruby-lang.org/en/ [3] https://rubyonrails.org/ https://rubyonrails.org/
  - solardev 4y ago
    I see, thanks for the explanation!
lgas 4y ago
Amazing name.
- blacksmith_tb 4y ago
  Presumably a pun about kopi luwak[1]? 1:https://en.wikipedia.org/wiki/Kopi_luwak https://en.wikipedia.org/wiki/Kopi_luwak
DanielHB 4y ago
coffeescript fell out of use because ES6 brought like 90% of the benefits of cofeescript and added a few more things. One of the few things that coffeescript still had going for it was the different syntax that a lot of people like (identation-based blocks, no curly braces, etc) As always pragmatism won and ES6 thrived, but Coffeescript still had a few things that ES6 didn't have. My favourite feature is "everything is an expression" so you can do something like this: eldest = if 24 > 21 then "Liz" else "Ike" see: http://coffeescript.org/#expressions http://coffeescript.org/#expressions this comes from Lisp and makes a lot of things easier. Obviously this was not implemented in ES6 because it would break compatibility and there is also some problems with implicit returns that made the feature a bit weird I wonder if a syntax like this for JS would work: const eldest = if (24>41) { escape "Liz" } else { escape "Ike" } with "escape" working like a mix of "break" and "return". But even then this is likely to cause incompatibilities
- Yahivin 4y ago
  Hopefully I can fill in that last 10% of ES6 which is something I really missed from CoffeeScript. A lot of the features taken from Coffee were "almost as good" and that grinds me down after a while. Basically if I can get a reimagined successor to CoffeeScript making decisions based E20xx as it is today then I'd be quite happy.
- esperent 4y ago
  What about: const eldest = 24>41 ? "Liz" : "Ike";
  - flappyeagle 4y ago
    This is ugly and hard to read compared to trailing if. They’re about the same for a one-liner but if you have anything more complex, Ruby style trailing if is far superior.
    - esperent 4y ago
      > This is ugly and hard to read compared to trailing if. For short statements like the examples given here, it's not ugly and it's easy to read. Whether it's easier/harder to read than trailing if depends on how familiar you are with each syntax. I don't think either is superior in this example. I agree ternaries are not suitable for long complex statements. However, I don't think trailing if is suitable for long complex statements either. I've generally only seen it used in simple cases.
NoahTheDuke 4y ago
> don't mix and match words and symbols This is an interesting design decision. Why don’t you want to combine them?
- Yahivin 4y ago
  I'll probably have a compatibility option to enable them but my primary reason is that it is a less elegant design. If the benefit of `and` and `or` is linguistic comfort then that goes away with `and=` (at least for me).
deleted 4y ago
[deleted]

20 points by Yahivin 4y ago

I created this new transpiled language to bridge the gap between CoffeeScript and TypeScript. It's getting really good these days!

tmm84 4y ago
I really like this idea. Brings back the good feeling I would get with CoffeeScript's syntax being shorthand for what I would write in JS but targeted at TS. I hope this stays around and gets some traction.
- Yahivin 4y ago
  Me too! I've been porting over some of my Coffee projects into Civet and fixing issues as I encounter them. It's getting better all the time.
graypegg 4y ago
Cool project! It’s cool to read thru the list of what you’ve added from Coffeescripts behaviour and not. Reminds me of some things I still miss from Coffeescript!
wdavidw 4y ago
I have been searching in the past for such a project. Great initiative

solardev 4y ago

What is CoffeeScript and why would you use it in conjunction with TypeScript?

graypegg 4y ago
Coffeescript [1] was a flavour of JS syntax meant to look similar to Ruby [2] syntax. You just compiled it back to JS. It was nice for working on Rails [3] projects since it made everything feel more “cohesive”. I assume this project is here for older Coffeescript [1] projects who want to start using typescript, and need access to interfaces/types that were present in old CS files. [1] https://coffeescript.org/ https://coffeescript.org/ [2] https://www.ruby-lang.org/en/ https://www.ruby-lang.org/en/ [3] https://rubyonrails.org/ https://rubyonrails.org/
- solardev 4y ago
  I see, thanks for the explanation!

lgas 4y ago

Amazing name.

blacksmith_tb 4y ago
Presumably a pun about kopi luwak[1]? 1:https://en.wikipedia.org/wiki/Kopi_luwak https://en.wikipedia.org/wiki/Kopi_luwak

DanielHB 4y ago

coffeescript fell out of use because ES6 brought like 90% of the benefits of cofeescript and added a few more things. One of the few things that coffeescript still had going for it was the different syntax that a lot of people like (identation-based blocks, no curly braces, etc) As always pragmatism won and ES6 thrived, but Coffeescript still had a few things that ES6 didn't have. My favourite feature is "everything is an expression" so you can do something like this: eldest = if 24 > 21 then "Liz" else "Ike" see: http://coffeescript.org/#expressions http://coffeescript.org/#expressions this comes from Lisp and makes a lot of things easier. Obviously this was not implemented in ES6 because it would break compatibility and there is also some problems with implicit returns that made the feature a bit weird I wonder if a syntax like this for JS would work: const eldest = if (24>41) { escape "Liz" } else { escape "Ike" } with "escape" working like a mix of "break" and "return". But even then this is likely to cause incompatibilities

Yahivin 4y ago
Hopefully I can fill in that last 10% of ES6 which is something I really missed from CoffeeScript. A lot of the features taken from Coffee were "almost as good" and that grinds me down after a while. Basically if I can get a reimagined successor to CoffeeScript making decisions based E20xx as it is today then I'd be quite happy.
esperent 4y ago
What about: const eldest = 24>41 ? "Liz" : "Ike";
- flappyeagle 4y ago
  This is ugly and hard to read compared to trailing if. They’re about the same for a one-liner but if you have anything more complex, Ruby style trailing if is far superior.
  - esperent 4y ago
    > This is ugly and hard to read compared to trailing if. For short statements like the examples given here, it's not ugly and it's easy to read. Whether it's easier/harder to read than trailing if depends on how familiar you are with each syntax. I don't think either is superior in this example. I agree ternaries are not suitable for long complex statements. However, I don't think trailing if is suitable for long complex statements either. I've generally only seen it used in simple cases.

NoahTheDuke 4y ago

> don't mix and match words and symbols This is an interesting design decision. Why don’t you want to combine them?

Yahivin 4y ago
I'll probably have a compatibility option to enable them but my primary reason is that it is a less elegant design. If the benefit of `and` and `or` is linguistic comfort then that goes away with `and=` (at least for me).

deleted 4y ago

[deleted]