> I wrote a bunch of CoffeeScript back in the day, and everyone I've spoken to about it feels the same, that it was a bad idea in hindsight

I don't think it was a bad idea in hindsight.

JS of the era was a pain to use; CoffeeScript made writing and reading things much easier, which is the reason it took off. Since then things changed and many "CoffeeScript features" are now "JavaScript features". Only with knowledge of that future would it be a "bad idea", but it was absolutely not clear that was going to happen back in 2010 and in alternative universes we're all writing CoffeeScript today.

I also think CoffeeScript was probably helpful in getting some of these features adopted in the first place.

The same applies to TypeScript – maybe typing will be added to JavaScript, and TypeScript will become redundant – I think there was some proposal and who knows what will happen. In 15 years we can say the same about TypeScript, but that doesn't mean TypeScript wasn't useful today, with the current state of JavaScript and uncertainty what the future may or may not bring.

CoffeeScript was not only a great idea but also successful beyond its adoption. It influenced and inspired many features that JavaScript later incorporated, such as arrow functions and destructuring assignments.

Over time, JavaScript evolved to the point where the few quality of life improvements offered by CoffeeScript no longer justified learning an entirely new syntax.

One of the Civet devs here. To me, the main benefit of Civet is the ability to rapidly add useful features to the language, while preserving all the benefits of TS (tooling, etc.). We're constantly coming up with ideas — from TC39 proposals, other languages, or general brainstorming — and implementing them quickly. For example, we recently added pattern matching when catching exceptions, which took just a couple of hours of development; or Python-style from ... import ... for better autocompletion of imports. All of these features are optional; you can write well-formed TypeScript as usual, and just choose to use the features you think are worth the learning curve for readers. The plugins for VSCode, Vite, esbuild, Webpack, eslint, etc. aren't perfect, but they let Civet code enjoy most of the tooling out there.

I personally use Civet for all my coding projects, as I'm devoted to it continuing to flourish. But if you ever don't like what Civet is offering you, you can eject at any time by replacing your code with the TypeScript compilation, which we make as close as we can to your input.

What happens if a TC39 proposal is rejected? That's actually the good case for us, because it means we can keep the feature as is. Civet already transpiles all features to TypeScript, so they can live here forever if we think they're good. The trickier part is when Java/TypeScript changes in a way that's incompatible with Civet. Then we plan to change Civet to match Java/TypeScript, so that we don't diverge (though compiler flags allow us to also support the older form with explicit opt-in if we think it's worth doing so).

JavaScript and TypeScript move slow. Largely that's a good thing; they're a stable foundation, and we don't want to mess them up. But it's also exciting to be on the bleeding edge, explore new ideas, and obtain new features as quickly as we can design them, instead of waiting a decade. Many features are also too niche / add to much complexity for the general JavaScript language, but they're still fair game for languages that transpile to JavaScript. See also the recent JS0 vs. JSSugar discussion.

CoffeeScript was great except for a few fatal mistakes. The biggest was implicit variable declarations, which meant that to write maintainable code, you had to reintroduce explicit declarations via iifes. Otherwise, you’d risk a future code change introducing shadowing which would have consequences that were super painful to debug.

The other big one, which unfortunately Civet seems to be doing too, is implicit return combined with “everything is an expression”. You can have one of those, but not both. With both, it’s far too easy to write loops intended to be statements, and which accidentally turn into gigantic multi-dimensional array returns which can’t easily be optimized out by the compiler. Fortunately, this would be only mildly inconvenient to work around with a lint rule that forces explicit return in all functions.

CoffeeScript was great. It was vastly more pleasant to code in than ES5-era JS. Once ES6 came out, we simply migrated to it and moved on.

I think everyone mostly agrees that CoffeeScript was a dead end, but I think it drove at lot of innovation at the time. Hopefully Civet can do the same, even if it ends up being another dead end.

Considering it's not just a grab-bag of TC39 proposals (e.g. removing braces), I suspect rejected TC39 proposals will just... linger.

I agree a research language feels potentially useful — and in fact that's what CoffeeScript's real legacy is (arrow functions, splats, destructuring assignments, and ES6 classes among others are direct ports of CoffeeScript syntax features, and many of the original JS class proposals that CoffeeScript-style classes replaced were quite bad) — but I'd be similarly leery of using this to ship much.

Something interesting I've found while designing Civet is that TypeScript actually mitigates in a lot of the downsides of CoffeeScript.

Types help quite a bit with implicit returns so you don't accidentally return an iteration results array from a void function.

They also help reduce the downsides of terse syntax, just hover over things in the IDE and see what they are. Missed a step in a pipeline? The IDE will warn you if there's a mismatch.

That's a really mean / uncharitable take. As others have pointed out, coffeescript did a great job of moving the language in a good direction, and that's presumably exactly what's intended here.

Some people don't code for the interns but to have fun. But I agree this isn't a very enterprise programming language, à la Java or Golang.

And in times of Copilot & others writing become less and less a problem, as code completion works very well.

Like this example: https://civet.dev/#everything-is-an-expression `items = for item of items`, in js you type `for`and copilot wrote nearly the full correct for-code. So you have to type not much and can read it easy.

Pretty much what I feel about Rust

I'll pass on the pipe operator, but it's not particularly objectionable.

Agree there's some good ideas. Pattern matching looks like a great idea with the wrong syntax - let's just get a match statement similar to the switch statement - if we can't reuse switch.

String dedent and chained comparisons look nice. Though I think the latter is a breaking change if it were done in js. I'd also be fine with default const for loop variables.

"Export convenience" is going to confuse people. The syntax looks different than named exports and looks closer to the export form of default imports which is begging for trouble.

For “everything is an expression” https://github.com/tc39/proposal-do-expressions may be of interest, though discussion seems to have paused.

The other thing that was hard to do with Lenient was to pass the thousands of tests in Babel to ensure the syntax handles every edge case.

The motivation is giving people a chance to try these features and thus ultimately helping move the language in a good direction. That's what coffeescript did also.

Languages like this don't make sense anymore. You can just pick a mature, feature-rich language you like (Rust, Kotlin, Python, probably many more) and transpile to JS.

Not a fan of YAML at all myself, but it's interesting that you like 'Yaml-like object structuring' yet then loathe 'Signifiant whitespace'? I mean that's basically YAML.

> It introduces an alternative and does so as a superset; which is not only dangerous to existing code bases...

How so?

C is syntactic sugar on top of assembly

You get used to it. It's really nice in Elixir. I'm not a fan of the fat pipe though.

I feel like there is a specific kind of person that likes all this, and there is very little overlap between those people and the people that choose to use Typescript.

Kinda feels like someone was forced to work in Typescript and really wanted to scratch their own itch.

Having worked in Rust I love the pattern matching proposal. Having dabbled in Swift I like the single argument function part (though keep the brackets, please)

Much of the rest I could take or leave… but then is that just because I’m not familiar with them? Stuff like the pipe operator makes sense to me but it reminds me of .reduce(): there are a few legitimate uses of it but the vast majority will be entirely-too-smart—for-its-own-good show off coding.

It appears to prioritize easier and faster typing over readability, which is a poor choice as programmers spend more time reading rather than writing code.

Nope! I'm also not convinced by it.

Note that the pipe operator is the rejected tacit pipes from TC-39. TC-39 made the (IMO) wrong choice of what they call hack style pipes (with a mandatory token) where instead of the pipe being a simple way to call unary functions. Civet seems to have picked the better pipes.

JSX has a spec. This thing they're doing... I don't know what it is, but it ain't JSX.

We're definitely looking for ways to improve ways to specify types! I think destructured typing [https://civet.dev/reference#destructured-typing] is already quite useful, especially for React. On the readability side, if/then/else [https://civet.dev/reference#conditional-types] seems easier to read than ?: ternaries, and "Partial Record Name, Info" seems easier to read than "Partial<Record<Name, Info>>" (implicit type arguments — https://civet.dev/reference#implicit-type-arguments). But we'd love to hear more ideas for features like branded types. Join us in Discord if you're interested!

Yes, Civet has taken a lot of syntactic inspiration from LiveScript. At this point, I think we have most of the good features, but we might be missing some. Let us know what you think!

The big difference, of course, is that Civet fully supports TypeScript, and is up-to-date with the latest JavaScript and TypeScript features.

I do not particularly like the lack of brackets everywhere. I think it is hard to know precedence perfectly and brackets ensure you do not make stupid mistakes.

Also there is the classic issue where you take an if statement that has a line one expression and you add a second line, but now because it didn't have brackets (and you are not using indentation style), you just introduced a bug. Or you have an if statement with an expression and you comment out the expression but not the if, then your next statement is now the if conditional expression, which is not obvious.

The linked page is pretty self explanatory. It’s TS with some extra features, many of which are already proposals for the language. Cool for an experiment, not good for a maintained codebase.

Depends on the framework. You can use class= in Preact.

It's doing a few things at once:

First line:

* `{min, max} := Math` is a destructuring declaration. It's similar to the destructuring assignment `{min, max} = Math` (i.e., `min = Math.min; max = Math.max`), but also declares min and max as const.

* The `operator` prefix means to treat min and max as new infix operators in the rest of the program.

Second line:

Given that min and max are infix operators, `value min ceiling max floor` is equivalent to `max(min(value, ceiling), floor)`. Yes, the latter is gross. That's why we like to write `value min ceiling max floor` instead. Think of it as "value minned with ceilling (i.e. capped at ceiling), then maxed with floor (i.e. prevented from going below floor)".

It looks like rubyist brainrot

Good question! I don't have hard numbers, but for larger files, I find that it can take on the order of a second to compile. It's still fast enough to get real-time feedback from TypeScript in VSCode, but it could definitely be faster. There's lots of optimization left to do; for now, we're focusing on features over speed, but we'll get to speed as well. (I am an algorithms guy after all!)

I feel like typescript would officially deprecate itself if that ever happened. But I also feel like that won't ever happen. It would be cool if ES would get optional type annotations or something, even if they were ignored at runtime. But someone would still want a static type checker. TS does that, and if there's nothing to replace that part, then TS still has a viable mission statement.

This is seriously triggering my CoffeeScript PTSD.