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.
My point is that it kinda didn't. It looked prettier on the surface, but didn't actually solve any of the deeper problems of writing JavaScript. To write CoffeeScript you had to still know JavaScript and all its oddities.
TypeScript solved those problems, and that's why it has taken off and had a meteoric rise to the point that it's practically synonymous with JavaScript.
> I also think CoffeeScript was probably helpful in getting some of these features adopted in the first place.
This may be true, but if so that suggests a benefit as a research language not a production language.
And then it ruined us with implicit returns, optional parentheses and brackets, and the isnt vs is not fiasco.
I worked a lot with Python and coffeescript at the same time back in the day. In Python you mess up your whitespace and 95% of the time it's an indentation error. In coffeescript it's a valid program that means something completely different than what you intended. Combined with the optional punctuation, which the community encouraged leaning into, it was far too easy to write ambiguous code that you and the compiler would come to different interpretations of.
* `is not` is the textual equivalent of `!==`. You can use `isnt` if you turn on the feature explicitly (or even the weird CoffeeScript `is not` behavior if you want it, mainly for legacy code)
* Implicit returns are turned on by default. They are really useful, most of the time, and don't get in the way much if you use `void` return annotations (which turns them off). But if you don't like them, you can turn them off globally with a compiler flag.
* Civet's compiler is built on very different technology from CoffeeScript's (PEG parsing, similar to Python), and it is much more strict about indentation. None of those weird bugs anymore.
* We do have implicit parentheses and braces and such, but you're free to use explicit parentheses and braces as you like. We encourage people to rename their .ts files into .civet (which mostly just works without any converison) and just embrace the features/syntax they like.
I’ve been eying Civet and I quite like it so far, but I dislike having this option because it means I’ll have to see it in other peoples code. I prefer strict rules for readability.
Regardless, I like pretty much everything else.
Oh man, that brings memories. When I joined a coffee-shop (pun intended), and learnt about implicit returns, I was screaming internally until we got rid of all the coffee (which was massive long team-wide migration effort that took like 2y to finish).
Once the migration was finished, everyone was so tired, that at the mere proposal of using TypeScript instead of JS the whole team would just roll their eyes and silently say "nope" in terror. Which was a shame, because large JS codebases are difficult to maintain and explore.
So I think this has more to do with how people are used to thinking with the languages they are fluent in.
What was so ruinous about implicit returns? That's one of the things I missed most when leaving CoffeeScript. ECMAScript only partially adopted it (single statement fat arrow functions) which probably muddies the waters for people trying to learn and understand the language's behavior.
Since it's optional for the caller to use or assign the return value of a function, I don't see much problem with functions defaulting to returning something. Maybe it just fits with my personal preference of functions returning a value and not having side-effects..
easy enough to add an extra line with just 'undefined' as the last statement of the function of course. but then you do need to remember that.
People can adapt either way. You can write more concise code with implicit returns and "everything is an expression".
Convenience does matter. The less I have to think about nonsense like that, the more I can think about actually writing correct code.
CoffeeScript wasn't perfect in that sense either and had some nonsense of its own. That probably contributed to its demise as much as any thing else.
I don't think TS removed any peculiarities of JS. It just forced you to actually learn them which JS and CS didn't do.
Many times something would look perfectly reasonable in CoffeeScript but when you would actually read the JS it would be iterating the same dataset multiple times to grab individual items that could have and should have been a single loop.
It's also backed – nay, pushed – by one of the largest and most successful tech companies in the world. A company that also made a point of releasing a very capable IDE to go along with it. Surely this has had some impact on its meteoric rise? :o)
(Wait – aren't meteors falling?)
It didn't. Anything you learn / are familiar with will be easier to write - Coffescript was easier to write for people who learned Coffescript. Which in hindsight wasn't time well spent as they would've eventually had to bite the bullet anyway & just learn JavaScript like everyone else.
JavaScript is much much easier to write and read for a person who has chosen to learn JavaScript & has not had the occasion to learn Coffescript (i.e. most people) so you were also doing others a disservice if readability was one of your goals.
> which is the reason it took off
The reason it took off was the Ruby was going through a popularity trend & Rails devs wanted to work in a front-end language that felt syntactically familiar. It was purely aesthetic.
But you're right that you did have to know enough JS to understand what CoffeeScript was doing under the hood when things went wrong.
It probably died fueling the whole js build/transpiler landscape that is in use today.
Was it really?
Outside of arrow functions, I don't really think CoffeeScript had a single important idea. And even then, the aversion to the `function` keyword in the JavaScript community never fails to make me laugh. Sure, sometimes the implicit scoping of the arrow function is nice, but man.
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.
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.
Admittedly, I don't do much Android development, and that was a big driver of Kotlin's adoption early on. So maybe it has more of a foothold there than on the server.
The "systems" language of the platform, evolves with the platform, is designed alongside the platform.
The guest languages might be better than the platform's "systems" language, on the day of the release, eventually it is bound to diverge with its own library ecosystem built on top (because "ugh" we're not using the platform libraries directly), its own IDE tooling, its additional debugging layer due to platform interop, its own abstractions not native to the platform,.....
Eventually it naturally diverges as the platform takes incompatible decisions,...
C and C++ on UNIX, JavaScript and anything compiles to JS, Java vs Groovy/Scala/Clojure/Kotlin/jTCL/Beanshell/jython/...., C# vs VB.NET/F#/C++/CLI/IronPython/IronRuby,...
The guest languages that are survive, are those that move beyond the platform that gave them birth and create a platform of their own.
In Kotlin's case that is definitely Android, because Android team is doing everything at their disposal to make Java a 2nd class language on Android, rewriting Jetpack libraries in Kotlin, requiring Kotlin for Compose, showing off Kotlin code samples against Java 8 examples(!), I bet they only starting updating Java support, because Android was starting to lose too many Java libraries as the Java ecosystem adopts new versions.
Still, Android 15 being released one year later from Java 21 LTS, is still catching up with Java 17 LTS, introduced in Android 13 and not yet fully implemented, kind of proves the point of them not being in a hurry for proper Java support on the platform.
But JS moved faster and babel was made and eventually we could use JS-future even when browsers hadn't updated yet and CoffeeScript wasn't needed. But it was pretty easy to translate it to JS, commit that and keep rolling. CS was great at the time.
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.
I still have gripes about runtimes such as Nodejs, but I don't expect something like Civet to solve those.
The addition of quick things you whipped up in a couple of hours seems like it'll make the rate of changes impossible to handle. It's unlikely almost by definition that the change you whipped up quickly will stand the test of repeated use and further experience unmodified.
All that said, it's a super fun thing to do, and hats off for such an ambitious project. If nothing else, writing a parser, transpiler, etc. is impressive and fun work, and will undoubtedly enable/force you to learn all the javascript/TS quirks and details extremely well! :-)
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.
I agree it can be easy to make and throw away big arrays if you're not aware of what's going on. But it can also save a lot of time. For loops as arrays are super useful, integrating the equivalent of "map" into the language itself. We also recently added generator versions (for*). JSX is a nice example where for loops as expressions and implicit return are powerful; see e.g. https://civet.dev/reference#code-children
What might work well is a lint rule to error if a loop expression ends an actual function declaration (i.e. not an inline callback), and the function doesn’t explicitly define a return type. I think that catches almost every bad case, aside from the odd memory leak in really unusual edge cases.
For example, you might have an “x” in some inner loop within a function. Then later on, you’d add an “x” earlier in the function, not realizing that that name was used down below. Suddenly the inner loop is referencing that new variable, and there was no way to tell other than the surprising ways your code would suddenly malfunction.
Hang on, how can you have “everything is an expression” without implicit return? If I’m correctly understanding what you’re talking about, implicit return isn’t actually a thing—it’s just that the function body is an expression too.
(Never dealt with CoffeeScript, but I’ve been writing Rust for over a decade now, and learned to love expression-orientation there.)
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.
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 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, and a language dead end. The language was only syntactic sugar, and by not bringing anything else to the table, was unconvincing for ports and support in other ecosystems. It now seems that most codebases have been decaffeinated though.
Civet looks like it adds a little more, but the things that aren't just syntactic sugar are just a grab bag of TC39 proposals. I'm a big fan of language proposals in general, and having a language that adds all of them for research purposes seems like a nice thing to have. Haskell did this well with GHC language options. Is this a research language though? It seems not.
What's the benefit over Typescript? A few less characters? Faster TC39 proposal integrations? What happens if a proposal is rejected, does it get removed from Civet? What's the cost? What happens as Typescript and Civet diverge? What if the TS tooling doesn't support Civet features?