Live data from Hacker News

CoffeeScript for TypeScript

civet.dev

61–70 of 143 posts

Re: CoffeeScript for TypeScript

#61
post #55

I wrote this 10 years ago, it's made the rounds. I stand by it even if it's a little long in the tooth. I would word it a little differently these days, but it stands on it's own. I like to think I helped lead people away from CoffeeScript. https://donatstudios.com/CoffeeScript-Madness

Good news! Civet fixes several of the more contentious design decisions from CoffeeScript by trying to be more in line with ES semantics. You need to declare variables by default in Civet. You can opt in to CoffeeScript's automatic var if you need to migrate from a CoffeeScript codebase by using the "civet autoVar" directive.

More info: https://civet.dev/cheatsheet#variable-declaration

Re: CoffeeScript for TypeScript

#63

please just use rescript it addresses every problem with js/ts and is simpler and you get a sound type system please.

I took a look at rescript's facillities for migration from JS and at step 1 (https://rescript-lang.org/docs/manual/latest/converting-from...), it tells you:

> First, copy the entire file content over to a new file called src/Main.res by using our %%raw JS embedding trick: > %%raw(`const school = require('school'); etc. `)

I stopped reading there - I'm sorry but that is horrifying. Wrapping JS in in a big backtick string?! No. That's even worse that Dart-JS interop.

Re: CoffeeScript for TypeScript

#64

Very tastefully done. Every one of these items is a huge improvement. This one in particular drives me crazy: `x.map(($) => $.name)`, `x.map .name` is almost Haskell level terseness. Can this all not be done as experimental typescript though, rather than a new language?

Civet aims to be 99% compatible with existing TypeScript so it could be considered an experimental TypeScript. With any luck Civet catches on and does to TS what CoffeeScript did to ES and all the best features trickle into the standard eventually.

The difficult part for TS/JS is they can't easily opt into some of the more whitespace/context sensitive features without breaking changes to existing code or forcing people to opt in with a "jsNext" directive or something.

Re: CoffeeScript for TypeScript

#65
post #26

Way back in the early 2010s I was very "excited" about coffee script and similar projects. They sounded like they should be great for productivity. When I actually tried to write a project in coffee script, the results were the opposite of what I expected. The code was harder to read, harder to modify, harder to understand, harder to reason about. There's something about removing stuff from syntax that makes programm…

I think you're talking about two separate things here,

1) Having to learn an entirely new syntax just to save on a few characters (it "decompresses" directly to the original thing)

2) Explicitness vs implicitness/inference

I wholly agree with you about #1 (superficial brevity isn't a very important goal and doesn't justify a whole new language), but #2 is much more of an "it depends"

Re: CoffeeScript for TypeScript

#66

Earlier quoted context omitted.

My kingdom for "everything is an expression" in JS/TS, but that would likely require an entirely new language.

If you’re willing to accept a little bit of extra syntax/ceremony, the `do` expressions proposal[1] is pretty much this (but it’s only stage 1 so who knows when/if it’ll land). 1: https://github.com/tc39/proposal-do-expressions

Nice! Wasn't aware of that at all.

Re: CoffeeScript for TypeScript

#67
post #45

Hello! I created Civet ask me anything. Or just curse me for keeping the dream of CoffeeScript alive :P

I've got 99 problems but the tersity in TypeScript isn't one of them. Can't wait to groan that a random project we depend on uses this and I have to learn new syntax to make a 1 line change. Whenever I saw coffeescript I just felt like the developers fancied a change for change sake and doesn't have real problems to solve. It's clever though to create a new syntax, I'll give you that

I like the documentation that TypeScript types provide but I'm always running into lots of small quality of life issues that wear me down.

- Rest in any position

- Dedented block strings

- Default to const in for loops

- Lack of -> function shortand

- Everything is an expression

- Implicit returns

- Chained comparisons

- Nested unbraced object literals

- Optional trailing commas in arrays

- Optional trailing commas in objects

- x.map .name function shorthand

Each one is a fairly minor concern but they all add up. I'm sure different people will have a different list of favorite features as well. One of my goals in creating Civet was to fix my top 100 issues with TS syntax while being 99% backward compatible. The ultimate goal being: TS with my top 100 issues fixed will be the best language I have ever used.

Re: CoffeeScript for TypeScript

#68
post #42

If you don't want to make the same mistake as me: don't ever choose to use a language whose syntax doesn't distinguish between variable assignment and variable declaration. Yes this includes coffeescript. This seems optional in civet [1]. [1] https://civet.dev/cheatsheet#variable-declaration

We trust people to make their own mistakes :)

Re: CoffeeScript for TypeScript

#69
post #54

Just started using Civet and it's really impressive, works well with TypeScript, understands my tsconfig.json, & has a working language server.

That's awesome to hear! There's still a lot of improvements we want to add to the LSP so it's only going to get better from here.

Re: CoffeeScript for TypeScript

#70

Earlier quoted context omitted.

My kingdom for "everything is an expression" in JS/TS, but that would likely require an entirely new language.

If you’re willing to accept a little bit of extra syntax/ceremony, the `do` expressions proposal[1] is pretty much this (but it’s only stage 1 so who knows when/if it’ll land). 1: https://github.com/tc39/proposal-do-expressions

We often add promising TC39 proposals into Civet so people can experiment without waiting.

We've added https://github.com/tc39/proposal-pipeline-operator, a variant of https://github.com/tc39/proposal-pattern-matching, a variant of https://github.com/tc39/proposal-string-dedent and others.

Since our goal is to be 99% compatible with ES we'll need to accommodate any proposals that become standard and pick up anything TC39 leaves on the table (rest parameters in any position, etc.)

Post reply on HN