> 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 amazing. It was only a dead-end because flow and subsequently typescript made an offer the ecosystem couldn't refuse. Unfortunately, I doubt that Civet will have much future momentum because even though typescript is the state of the art for front-end dev, it's a much less stable foundation to build on top of than ES was for CoffeeScript.

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.

> What's the benefit over Typescript? A few less characters? Faster TC39 proposal integrations?

Getting hands on experience with those proposals could be an argument, learning how they feel, learning how their availability changes the way people write code. Could this be called a research language? Sure, but that categorization would certainly influence the outcome of the observation.

I'm not disagreeing with any of your points though. Perhaps some mitigation could be provided by making their equivalent of decaffeinization a true first class citizen, intended to be run whenever a proposal gets rejected (or implicitly rejected by the language taking a different direction). This would have to be fine grained, and the language/tool would have to make "rolling preview of whatever proposals are currently in consideration" the code of its identity, not any particular set of language features.

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.

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.

CoffeeScript was very successful, the main win was that it could become irrelevant because so many constructs were adopted upstream.

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.

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.

It was a wonderful idea that got 90% assimilated by the underlying language thus becoming successfully obsolete.

I'm not convinced this is a good idea either, but abstractions and syntax are what makes people love or hate a language. I enjoy writing python over JS because of ergonomics. Its not really about productivity, its about being happy when writing and reading code.

That being said, stapling on a compile step maybe isn't the answer.

CoffeeScript immediately revolted me and Civet is giving me the same heebie jeebies. It's the kind of punctuation-as-code that the world rejected 10+ years ago when Perl faded away. Verbose code is better for readability and readability is 100X more valuable that faster typing. It's not more expressive, it's more obscure.

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 new intern or you in a year reviewing your own code.

I sure hope they see it and realize it is most likely in desperate need of refactor

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.

  foro
    for ($1 of $2) {
      $0
    }

  touc
    toUpperCase()

  le
    length

  map
    map(x => $0)

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.

yea this

i see it as moving physical abstraction into mental abstraction

save few lines of code but costs more mental ram

Pretty much what I feel about Rust

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.

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.

Yeah I agree, 'value min ceiling max floor' is a terrible example. Especially when making a case for improving readability.

That being said; regular written language (like in a book) has optimal readability. Therefore it makes sense for programming languages to lean towards that. If you could write code like: `draw 600 by 600 graph_of intersection_of data_set1 data_set2 in blue` it would be very easy for basically anybody to tell what the code does. This not only makes it easier for beginners and onboarding, it also reduces cognitive load, even for senior level engineers. In real terms this means less fatigue, less bugs, less time spent reviewing code, higher productivity.

That being said I also prefer the explicitness of parentheses, but I think that's because I'm used to needing that level of explicitness. But maybe there's some paradigm out there that makes it so we don't need that crutch

It would essentially involve changing the meaning of `: Type` and `as Type`. Basically, instead of ignoring type annotations at runtime, you'd have to throw when a cast fails.

This would also have other implications on the language design. Checking if an expression has a certain type at runtime would mean relying less on structural types to make these checks cheap.

I've been thinking about this exact language a lot recently, but it would not be the same as Typescript. A superset of JavaScript which can be statically optimized based on type information.

Fwiw, I don't think Assembly script is this language either. It's a completely different language than JavaScript with a superficially similar syntax.

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

How so?

I agree, Rescript is an actual language rather than syntactic sugar.

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.

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.

    value min ceiling max floor

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.

Nope! I'm also not convinced by it.

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

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.

C is syntactic sugar on top of assembly

The pipe operator just flips the order of execution. In my experience this doesn't really impact debugging at all.

without the pipe operator you would write ` fun1(fun2(fun3(fun4(fun5(x, y), z, w), u), v)) `

The order of operations in this line is actually from right to left. Also it's not immediately obvious to which function the u parameter belongs to.

With the pipe operate you would write it in the order that the functions are actually called and you have the arguments in the same location as the function they belong to. So this would be written something like

` fun5(x, y) |> fun4(z, w) |> fun3(u) |> fun2(v) |> fun1() `

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

[dead]

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.

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.

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!

I came to the same conclusion after the initial perl intoxication. Stable, regular constructs are much easier to parse and get back to than this pseudo-natural language. My worst confusion is python’s truly unreadable “x if cond else y” construct, especially when x and y are non-trivial. Putting a condition in between is not smart. Oh, now this gets me started on “is not”! Keeping calm…

You can use braces if you like

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

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.

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!)

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

Didn't they say it? If you turn on the react directive then it outputs the react prop.

Btw, you seem to have missed the new jsx transformer, className has been a thing of the past even in React.

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.

So imagine what already happens and makes no impact to how I write code? How exciting!

Like Haskell or F#? Already exist.

This is seriously triggering my CoffeeScript PTSD.