
The Great CoffeeScript to Typescript Migration of 2017 - dgoldstein0
https://dropbox.tech/frontend/the-great-coffeescript-to-typescript-migration-of-2017
======
jashkenas
I started reading through these comments expecting a tall wave of negativity,
and was surprised to see such a warm wash of mixed and fond memories from the
"bad old days" when ES3 and IE ruled the roost.

Full disclosure: I haven’t used it myself much since ~2012 or so, and modern
JavaScript now contains many of the most important features that CoffeeScript
offered at the time .... Although they did screw some things up (IMHO): null-
vs-undefined in default arguments, super as a parent reference instead of a
direct function call, optional parens for single-arguments arrow functions
(Prettier agrees!), no shared semantics between arrow and normal functions,
that class syntax only supports methods and not data as properties, and so
on...

When all is done and dusted, I hope that CoffeeScript can be looked back on
with affection as a little experiment that showed surprising vigor, one that —
with no corporate backing and zero financial support — spread by word of mouth
through the web community of the early 2010s, and helped fuel the fire to get
JavaScript moving and evolving as a language again.

As a side note — and I write this without bitterness — I do find it a bit
strange that extremely well-resourced companies like Dropbox, GitHub,
CircleCI, Trello, Airbnb (and many, many more) would write so many hundreds
and hundreds of thousands of lines of CoffeeScript without ever attempting to
contribute changes or fix the issues that they wanted to fix. It’s open
source! They probably would have been able to quickly and cheaply make most of
the changes they wanted.

Anyhow, cheers for the blast from the past!

~~~
preommr
> As a side note — and I write this without bitterness — I do find it a bit
> strange that extremely well-resourced companies like Dropbox, GitHub,
> CircleCI, Trello, Airbnb (and many, many more) would write so many hundreds
> and hundreds of thousands of lines of CoffeeScript without ever attempting
> to contribute changes or fix the issues that they wanted to fix. It’s open
> source! They probably would have been able to quickly and cheaply make most
> of the changes they wanted.

This is the heart of a really important issue in OSS that affects everything
good and bad about the scene.

There are companies that pretty much waste millions on poorly managed projects
but won't donate the few thousand needed to make a lot of OSS projects succeed
while still using the software.

It doesn't help that a lot of the culture just accepts fragile dependencies
(who cares if this semi-crucial dependency is managed by the equivalent of
newman from jurrasic park), and that a lot of the biggest OSS projects are
usually made by people working at some big company. Maybe copyleft licenses
would've prevented some of these issues, but I am not sure individual users
like those restrictions even if, in some ways, it would benefit the community
as a whole.

Its absolutely disgraceful how little financial support some really commonly
used libraries get.

~~~
dccoolgai
And "they don't contribute" is one of the _less_ harmful things. Look at what
Amazon did to Elastic/search.

~~~
wlll
What did Amazon do to Elasticsearch?

~~~
dccoolgai
Took Elastic's product (Elasticsearch), forked it and started selling it under
the same name. It's a cautionary tale for anyone thinking about running a
business based on OSS.
[https://www.google.com/amp/s/searchaws.techtarget.com/news/2...](https://www.google.com/amp/s/searchaws.techtarget.com/news/252471650/AWS-
faces-Elasticsearch-lawsuit-for-trademark-infringement%3famp=1)

~~~
wlll
Gotcha, thanks!

------
blitmap
I truly do not understand why so many jumped from Coffeescript. I still use it
and still believe I can be more concise and expressive in Coffeescript.
Typescript and ES2015 picked up a lot of wonderful things, but I find myself
writing a lot less boilerplate in Coffeescript. I will continue to "do me". I
dev in Coffeescript and publish in JS. The project even made it a focus to
transpile to readable/friendly JS. No biggie.

I would not publish things like this, though :)

console.log [ i if i % 3 and i % 5, 'fizz' unless i % 3, 'buzz' unless i % 5
].join '' for i in [ 1 .. 100 ]

Separately, I bought overpriced raspberry pi's instead of cheaper alternatives
because I knew the community was a strong source of support. Modern JS has a
much larger community than Coffeescript 2.

~~~
dgoldstein0
I recall when we first adopted Coffeescript, the engineers who did it touted
that we had about 20% fewer lines of code as an example of coffeescript being
better - a lot of which was probably just the removal of lines that only had
curly-braces. In hindsight, this wasn't a good metric to judge the language
on.

As a larger engineering organization, what we've definitely learned over time
is that we need to prioritize readability (and maintainability) over
writability - as our code is going to last a long time and the original
engineer who wrote it, will likely move on to another project, team, or even
company. And while maybe they train their replacement, after a second or third
iteration of that, the knowledge can easily end up lost.

Coffeescript, as a language, definitely prioritizes terseness, often at the
expense of readability. And we didn't have internal coding standards that
pushed back on this.

But even if we had done a better job using coffeescript, we're still better
off in typescript today, due to the stronger community and stronger set of
available open source tools to work with the language.

~~~
erikw
I see readability as a key advantage of TS. Once you are able to comfortably
read type signatures, it is trivial to see what a function is supposed to do,
or what a library is supposed to provide. When things don't work as expected,
then it's just a matter of hopping into the debugger to inspect data inflight
to find where the typings aren't matching up with reality.

~~~
dgoldstein0
yup, types are a huge advantage, especially in large codebases where you
probably don't know all the people who may write code to interact with your
code.

Readability of types can become an issue over time, but with the right naming
of interfaces and useful type aliases, that can be mitigated to some extent.
And as the typescript language and community evolve together, there are new
ways to make some types even more readable - I've seen generics for getting
the return type of a function, which seems potentially really useful (and some
people swear by; I haven't used them extensively, but it looks like a
promising idea).

~~~
momokoko
After ten years of JavaScript and after working on TypeScript apps that have
now been around for 5+ years, I can assure you TypeScript is less maintainable
long term than most languages.

Did you know that TypeScript’s type system is turing complete? Good luck
figuring out literal bespoke _type_ frameworks in TypeScript. Did you know you
can have a TypeScript application that takes more than 8GB of memory to
compile?

TypeScript is literally a Microsoft play to regain Visual Studio market share
they lost by creating a language that much like C# and Java, practically
speaking, requires a massive feature rich IDE for most developers to write
software efficiently with.

You all fell for it, and at this point it’s too late. Millions of extra
development hours will wasted maintaining legacy TypeScript apps for years due
to a Microsoft marketing stroke of genius.

~~~
d3nj4l
If genuine developer satisfaction from everyone I know IRL who's used
typescript is due to Microsoft's marketing, I say they deserve to win this
one.

------
ravenstine
I stopped using CoffeeScript just because JavaScript fixed most of the issues
that got me to use CoffeeScript back in 2014. Once ES2015+ became well
supported, I decided I'd rather write code in the language that the
interpreter understands, rather than something that precompiles. CoffeeScript
isn't bad... it's just not significantly better than JavaScript is today.

Also, I find it interesting how many people like the Python syntax but hate
CoffeeScript syntax. They have a lot of similarities.

~~~
eshyong
As someone who works with Python a lot, Coffeescript always looked more like
Ruby to me, especially with all the syntactic sugar (lack of parens, keywords
like `unless` or `isnt`, #{} for string interpolation, etc)

------
Jare
> it was absurd to expect anyone to want this as their full time job for even
> a month or two

That gave me a true 'kids these days' moment...

In my day within a spanish bank, as a team of 4 interns, we spent over 6
months reviewing/documenting an entire proprietary platform C codebase (full
of gotos, endian-dependent hacks, post-compile patches and every horrible
thing you could imagine), and then with a larger (~3x) team about 12 months
cleaning, porting and expanding that codebase to a clean platform (if you can
call SCO Unix 'clean').

What sort of dynamics prevent a product startup like Dropbox build an
engineering team that includes the capability to do such a task?

~~~
bcrosby95
Because startups tend to use how much you enjoy coding as a proxy for how good
of a coder you are. So if you purposefully hire a bunch of people because they
like coding, it's going to cause a shitload of problems once you unleash an
"unfun" job like this on them for such a long period of time.

~~~
whynotminot
Wait what? So you should hire coders who don't like coding to do coding?

~~~
nojito
People who "like" coding tend to prefer hot new tech as a way of
experimentation.

They often ignore the actual business problem that needs to be solved, because
it can be solved using "boring" technology.

~~~
hombre_fatal
Seems like an invention on your part. I also sense some condescension towards
this alleged group of people that you insist exists.

The reality is that people who like coding and thus trying new things are
limited by the stack their job uses. Simple as that.

I don't really understand your hypothetical scenario where this alleged person
is working on the new FooQux framework instead of getting work done. That's
just someone who isn't doing their job. That they enjoying writing code seems
irrelevant. Like trying to say people who like water skiing are awful
employees because they're on the lake all day.

We need a word for this kind of HN trope. Condescension roleplaying?

~~~
perl4ever
My last phone screen, I emphasized that I like solving business problems,
rather than tech for its own sake. They decided I "wasn't technical
enough"...without asking me a single technical question.

That's the culture clash people frequently reference, and it's very real. If
you don't perceive it, it's because you're swimming in it.

And I emphasize that the attitude, that the only good coders have tunnel
vision and just want to play obsessively with tech, but only the cool stuff,
goes far, far beyond the stereotypical SF startup environment or whatever.
Because a large number of companies have a vague idea that to be cool, they
should imitate what the trendy companies do, so even if you question the
stereotype, the stereotype influences reality.

------
CapriciousCptl
I fully remember picking up coffeescript because Dropbox had used it. I only
ever used it on one project. I try and remember that every time I have the
urge to go with Reason, Elm or even wasm compiling things. Long live JS.

~~~
Roboprog
If you are trying to build for a business, or something you yourself will have
to maintain for years to come, vanilla JS seems like the way to go.

Perhaps Typescript isn’t a fad to be abandoned, unlike say GWT, CoffeeScript,
et al, but why risk it?

Javascript doesn’t feel painful to me like Java does. I don’t have a lot of
problems with it that need solving with an alternate front end.

Long live JS!

~~~
karatestomp
AFAIK TS is pretty committed (at the expense of possibly-useful functionality)
to being very, very simple to strip out, leaving vanilla JS in its wake.
Unless you're minifying, the compiler output typically looks almost exactly
like the well-formatted, sane, and readable JS you'd have written instead.
That escape hatch is part of why I've not worried a bit about taking it up.
Turning a TS project into a JS project, should you ever need to, is
functionality that's essentially built-in, and you do it every time you run
"tsc".

~~~
Roboprog
But I don’t write “classes”, and don’t want to be lead down that path.

Allegedly TS has a solution for doing partial function application or
currying, such as in the Ramda.js library, but the example that was provided
to me a few weeks ago looked every bit as clumsy as the angle bracket stew in
Java 8. I don’t remember the details, other than “I hope I never have to read
that.”

PFA is like dependency injection for functions, without needing all the
“executioner” class trapping nonsense, and with higher order function
composition replacing much of the need for subclasses.

I guess deep down in my heart, I know that Typescript is coming to crush any
joy out of working with JS. The industry of enterprise design patterns will
demand it.

Some of you will understand this, but most will probably just hate on the
unenlightened developer who must simply be resisting The Future. A “future”
inspired by Simula67, with beans replacing copy books, and IoC provided
singletons replacing individual .COB programs. Meh.

P.S. nothing personal. I’m simply terrified of the perception that TS is an
unequivocal boon to programming-kind. It’s not, for all of us.

~~~
karatestomp
How does TypeScript push one toward classes any more than ES does? Does using
typescript keep a person from using ramda? They list typescript typings on the
ramda site.

~~~
Roboprog
[https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/ramda/index.d.ts)

“Fun” stuff to read. So if I want to write higher order functions, rather than
classes / interfaces, I have to write, and worse, READ, mass boiler plate like
the stuff in the link.

This feels like Java 8, to a large extent: you can use code that calls lambdas
(e.g. Stream) but you don’t want to have to wade through such HOF code that
has the needed cruft to use the callbacks. So in practice, people won’t create
higher order functions and the like, as it becomes too much trouble to read
and write.

~~~
karatestomp
What? Your tools do almost all the reading of types like that. It’s the
_entire point_ of using typescript: your tools tell you useful stuff with it.
You’d never need to look at that file unless you found a mistake (bug) in the
type definitions.

Though yes when defining your own functions you might need to take a second to
write down what you intend it to do in a machine-readable way, so the next
person who uses them can let their tools tell them what you intended, rather
than memorized convention or docs or a comment somewhere or (quite often) just
reading and experimenting with the code because that info is found no-where
else at all.

When you’re calling such functions the “cruft” is minimal or totally absent.
Definitions are where TS makes you put in a little extra work to get your
intentions out of your head and down in the codebase for the benefit of your
future self and anyone else who has to try to make sense of it.

~~~
Roboprog
Would I be correct in guessing that you are more likely to write an abstract
class in the next month than to write a higher order function?

Part of the problem in these discussions is that there are at least 2
populations with vastly different work flows. Which would be less of an issue
if I were part of the majority enjoying “mob rule”

~~~
karatestomp
> Would I be correct in guessing that you are more likely to write an abstract
> class in the next month than to write a higher order function?

I doubt it, because HOFs are hip in React-land right now and I don't really
give a shit, personally, so I usually do whatever my team-mates find idiomatic
in their current coding style and preferences, which means implementing and
using HOFs, for now. Plus React picked "awkwardly add state and object-like
functionality to functions by partially re-implementing objects" over "use
built-in object system better, but tie react more strongly to OO-style
programming" when they realized they had to pick one or the other to fix some
problems, so React's even more functional now than it was before and is only
heading farther that way as their chosen way forward continues to accrue
functionality that OO-style React doesn't have.

Regardless, I haven't found TS to impede the writing of HOFs, and certainly
not the use of them. I've been favoring them for a while even server-side just
because it's "the thing to do" and other JS devs are familiar and comfortable
with them these days and, again, I don't really care one way or the other. If
I find myself on a team that prefers classes and objects, I'll use those
instead in places where either would do.

Anyway, I'm more of a composition than inheritance guy when writing OO code.
And I'd be more likely to define an interface than an abstract class. Not that
I'd never, ever use the latter, it's just not something I reach for very
often, especially in TypeScript.

[EDIT] actually, TS is _part of_ why I no longer have significant preferences
for how I write Javascript. Before, the only Javascript style I found not to
be hair-pulling-out stressful and unproductive was about as C-like as
possible, favoring a procedural style and aiming for _zero_ indirection or
"cuteness". Of course this was a popular JS style approximately no-where so
this translated to my hating Javascript. TypeScript saves me from having to
care. I'll write whatever, just give me types so I don't have to go read (or,
god forbid, execute and poke around in) your code to figure out WTF you're
doing even at the most fundamental level.

------
xvilka
Instead of TypeScript which is very far from being all-typed, I hope there
will be wider adoption for proper Web languages like ReasonML[1],
BuckleScript[2], PureScript[3], Elm[4], etc. With a better WebAssembly
adoption and once they solve the garbage collection problem[5] and direct DOM
access[6] there will no even need in JavaScript "glue".

[1] [https://reasonml.github.io/](https://reasonml.github.io/)

[2] [https://bucklescript.github.io/](https://bucklescript.github.io/)

[3] [https://www.purescript.org/](https://www.purescript.org/)

[4] [https://elm-lang.org/](https://elm-lang.org/)

[5]
[https://github.com/WebAssembly/gc/issues/44#issuecomment-623...](https://github.com/WebAssembly/gc/issues/44#issuecomment-623912377)

[6] [https://stackoverflow.com/questions/42628328/wasm-access-
dom](https://stackoverflow.com/questions/42628328/wasm-access-dom)

~~~
Sebb767
Well, loose typing allows for far faster prototyping. I know some people will
debate me on this, but mixing int and string in an array or returning an
object or a string is far faster than going the 'proper' way. It's not great,
but it gets you started earlier and that's a big point.

Another thing is that it's extremely easy to migrate from vanilla JavaScript
to Typescript. You simply add a compile step at first, which breaks nothing,
and then you slowly move your js files to ts while still being able to cross
use them. I've migrated a ~10k LOC app and it was a breeze - whenever I needed
to touch a module, I simply took the 5 minutes to make it TS. Whenever I
touched a function, I added the type parameter. Being able to slowly convert a
big app without ever having a major breakage or a massive change is something
extremely valuable and rare (looking at you, `async`).

~~~
arkanciscan
TypeScript just moves all errors from runtime to compiletime, even the ones
nobody would ever realistically encounter. The user's browser is the only
typechecker that matters, and that's why end-to-end tests are more important
than type-linting.

------
neya
I use coffeescript in 2020. It's a great language of choice especially if you
come with a background of good programming languages like Ruby, Python,
Elixir, Etc.

Coffeescript makes code more succinct, readable and javascript tolerable. I
tried typescript, but, it's not my cup of tea and it has it's own quirks. I
work with large scale media companies and never has coffeescript been in my
way. If anything, it has made javascript bearable. These days, my choice is to
avoid Javascript if I can and use something like Phoenix LiveView if I can get
away with it.

I wish the coffeescript developers can ignore all the hipster noise and
continue to support the project for their effort has saved so much valuable
developer time.

~~~
lioeters
I used CoffeeScript for a few years, and I went in deep. I loved the succinct
and elegant syntax, it made coding in JavaScript a joy. I still think it's a
wonderfully designed language with merit and worth.

When I decided to move on to ES2015, one reason was that JavaScript grew up,
adopting some of the ideas of CoffeeScript, and the non-standard aspects of
the latter became incompatible. (I recall some ECMAScript features couldn't be
implemented in CoffeeScript, at least for a long time, due to existing
syntax.)

A bigger reason was the mindshare of the developer community. When the
majority adopted Babel and staying "future compatible", using modern language
features that are guaranteed to be in the standard.

I want the code I write to be accessible to the majority, so more people can
read, understand, and contribute to it. This is important for team work, such
as easier onboarding of new members, so they don't have to learn a new (flavor
of) language.

Choosing an "alternative" language also has long-term implications. When a
developer moves on to a different project or company, they leave behind the
code for others to maintain and develop. I realized that CoffeeScript would
become legacy code, that someone will have to convert back to "normal"
JavaScript eventually. I couldn't justify my developer convenience with that
associated cost to others.

Funny enough, these days I prefer to write in TypeScript, another alternative
flavor. I'm not "all in" yet, mainly because other developers at my work
haven't picked it up. I have the impression that TypeScript is more of a
standard than just a flavor, so I believe that writing it will not incur a
long-term cost, but rather be a benefit, as more maintainable, type-safe(r)
codebase.

Still, time will tell if that's true. Maybe I'm again contributing to legacy
code, this time in TypeScript.

------
d3nj4l
> In 2012, we were still a fairly scrappy startup of about 150 employees.

Perhaps it's just the changing definition of the word "startup", but the idea
of a 150-employee startup being described as "scrappy" made me chuckle.

------
fourseventy
I worry about the long term viability of using an offshoot language of
Javascript such as Coffeescript or Typescript. These types of languages have a
habit of falling out of vogue and basically becoming a dead language, which is
exactly what happened to coffeescript. If a company decided to write an app in
coffeescript in 2010, today they have a big pile of code written in a dead
language on their hands. If instead the company had chosen a mainstream
language with a guaranteed future such as JS, Java, or c# it wouldn't be an
issue.

~~~
ryanianian
Typescript is nice in that it's a superset (mostly) of js. That doesn't mean
it won't fall out of vogue, just that in a lot of cases converting from TS to
JS is mostly straightforward, so you can "just" remove some type information
and end up with valid JS.

~~~
city41
You should be able to let tsc do it for you with a properly configured
tsconfig file. Mostly just want it to not emit any polyfills.

------
nosefrog
I worked on this project, it was super fun. Open to answering any questions.

~~~
city41
I’m curious why not allow implicit anys instead of creating the tool that
inserted anys? Seems roughly the same outcome but implicit anys would take a
lot less work?

~~~
dgoldstein0
Because of the way we had type checking set up - our existing code already
used noImplicitAny, and we wanted to keep that, and we were typechecking it
all in one shot, together, so we couldn't have different typescript flags for
different files.

Now as to why to use noImplicitAny in the first place: mainly because implicit
anys are usually accidents - places where developers didn't realize they
should put a type. And the explicit `any` in many ways is sitting there for
anyone who cares to replace it with something better; whereas implicit anys
are much harder to notice.

------
bambataa
As someone who came into development after the Coffeescript wave I’m
interested to know: how much did it feel like the future?

Was it always an early adopter, “look how forward we are” kind of thing, or
was it just popular with Rubyists?

I’m trying to calibrate it with other possibly-next-big-thing front end
languages.

~~~
nevir
CoffeScript had quite a bit of influence on JavaScript and TypeScript today
(and/or really great timing w/ similar thinking). All of these were in early
releases of CoffeeScript, and showed up in modern JavaScript years later:

* fat arrow functions

* classes

* template strings, multiline strings

* destructuring and ...rest values (splatting)

* elvis operator (foo?.bar?.baz - in TypeScript)

honorable mention

* list/iterator comprehensions (made some good progress in the ES speccing process, but ultimately didn't land)

~~~
dugmartin
I agree with some of items on your list but a lot of those features were part
of ECMAScript 4 (ES4) which was largely abandoned in 2008 (with the exception
of it being the basis of ActionScript 3). CoffeeScript's first commit was
December 13, 2009.

From the Wikipedia entry (
[https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_(abando...](https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_\(abandoned\))
)

\---------------

By August 2008, the ECMAScript 4th edition proposal had been scaled back into
a project codenamed ECMAScript Harmony. Features under discussion for Harmony
at the time included:

\- classes, \- a module system, \- optional type annotations and static
typing, probably using a structural type system, \- generators and iterators,
\- destructuring assignment, and algebraic data types.

\---------------

I enjoy working in TypeScript in VSCode since it feels just like working in
ActionScript 3 in FlashDevelop. except a bit slower.

------
dzsekijo
[https://saagarjha.com/blog/2020/05/10/why-we-at-famous-
compa...](https://saagarjha.com/blog/2020/05/10/why-we-at-famous-company-
switched-to-hyped-technology/) :P

~~~
madmaniak
Awesome! Thank you for this article.

------
apatheticonion
Though I use it daily, my biggest criticism of TypeScript is that it's not
opinionated enough. From inception it was designed as sugar on top of
JavaScript but not a replacement, and therefor they decided not to make
decisions outside of the ECMAScript specification.

The advantage to this is developer buy in, the downside is how annoying it is
to work with at scale.

In a monorepo, running 10 compilers in watch mode because TS can only consume
external source which is compiled to JS. You can't consume TypeScript source
directly (which would be nice if you want to use github as a package
repository).

But it's fine. I'm happy paying the cost to not use JavaScript directly, but I
am disapointed because it could be so much more.

~~~
edjrage
Have you seen Deno? Would it help with your issues?

[https://news.ycombinator.com/item?id=23172483](https://news.ycombinator.com/item?id=23172483)

------
freedomben
CoffeeScript was an amazing companion to a Rails backend. While I did get bit
a few times by unexpected CoffeeScript behavior (implicit returns and
whitespace, ah!), it was substantially more beautiful and "developer
happiness" than the options at the time (2014-ish).

CoffeeScript will always have a warm place in my heart, tho I do use
TypeScript as much as possible now.

------
dgoldstein0
Author here, also willing to answer questions

~~~
pansa2
“Lack of delimiters“ is given as the most common complaint about CoffeeScript.

I’ve never written any CoffeeScript - Is this referring to the language’s
Python-like significant indentation, or something else?

~~~
dgoldstein0
something else. More that `()`, `[]`, `{}`, and `,` in a lot of places in the
language syntax were optional. And we embraced that... way too much.

E.g.

    
    
      foo: 1
      bar: 2
    

is the same as

    
    
      { 
        foo: 1,
        bar: 2,
      }
    

for basically no good reason. When you start combining a lot of these,
whitespace takes extra significance, and in extreme cases can easily change
what you think the meaning of your code is, and what it actually is.

------
jtth
This makes me miss CoffeeScript. Ah, well.

~~~
city41
Only thing I still miss is noop functions are two characters. Everything else
I liked is in JS now that nullish coalescing landed.

~~~
recursive
`_=>_` is technically more than two, but not by much.

~~~
hombre_fatal
Identity function is more confusing than just ()=>{} which is obviously noop
because it doesn't return the input.

~~~
recursive
If you don't provide an argument, it will use undefined, which is the same
thing yours returns. Maybe it's more clear, but it's about even for me.

------
d0m
That bit was interesting:

>> Manually convert a list of ~100 commonly edited files from Coffeescript to
TypeScript.

Seems obvious, but outlining it as a critical step probably helped in many
ways.

------
jondubois
CoffeeScript never made any sense. The drawbacks of having a build/bundling
step and having to run/debug transpiled code were never worth the tiny
benefits it offered.

I think the drawbacks of bundling are still not worthwhile even for
TypeScript, but I'm not surprised that people who liked CoffeeScript would
like TypeScript even more. It is unquestionably more useful; at least you get
some value in exchange for having to spend most of your development time
waiting for the build to finish.

What is mind boggling to me is just how popular CoffeeScript became. It makes
no sense at all. I guess it just got a lot of celebrity endorsements.

I think the problem is that 'real programmers' held such prejudiced and
condescending views of JavaScript that they were not willing to learn it and
figure out best practices. They were too proud for JavaScript but they still
needed to use it for their job so that's why they were prepared to use any
possible alternative; better or worse - At least their ego was protected.

Same thing with TypeScript; its main purpose is protecting developers' egos by
allowing them to leverage the power of JavaScript without actually having to
admit to themselves that they're using JavaScript.

IMO, it's self-deception. JavaScript has proven itself to be an amazingly
flexible, adaptable and backward-compatible language. It has flaws just like
any other language but it's an objectively amazing language. It has proven
itself.

Some developers will insist that it was because of JS's monopoly on browsers
that it was successful but you'd be surprised by how many set top boxes and
car navigation systems are powered by JavaScript (and they could have used any
other language).

JavaScript achieved this in spite of being constantly undermined - The fact
that it was able to grow and dominate in such adverse social environment
speaks to how truly great it is as a language.

~~~
ricardobeat
> the tiny benefits it offered

It allowed using language features that only now, nearly a decade later are
commonplace. It offered huge benefits.

------
29athrowaway
Coffeescript tried to simplify the syntax, but it went too far.

\- A statement such as f(g(x)) becomes absurd without parentheses.

\- Indentation has a meaning, but it is legal to have inconsistent
indentation.

Code is written once, read many times. Coffeescript got that backwards.

CoffeeScript is to JavaScript what Stenography is to Writing. Steno makes
sense when you have to write something being dictated to you in real-time, but
if you are not in a hurry, just write.

~~~
jhanschoo
\- A statement such as f(g(x)) becomes absurd without parentheses.

Y'all just aren't used to ML syntax.

~~~
29athrowaway
To me, having no parentheses is like driving on a 8 lane highway with no lane
delimiters.

~~~
mokanfar
you'd really love lisp!

------
erichurkman
My fond memory of CoffeeScript was an interview I did way back when at Olark.
It was a full day 'paid work along' interview that was popular at the time.
I'd never touched CoffeeScript prior. In less than the day, I was proficient
enough even navigating a foreign code base to build out a small feature within
the Olark platform. (I think it was managing chat operators as groups?)

Fond memories!

------
studentik
CoffeeScript rocks for functional programming. Less chars and more sense per
LoC, easier to learn than JavaScript and syntax sugar is sweet.

------
russellbeattie
Hmm. I wonder how much longer it'll be before they migrate from Typescript to
the next fad version of JavaScript that comes along?

------
k__
CoffeeScript? 2017?

I had the impression that CS was done when ES2015 came out in ... Well 2015

I personally prefered LiveScript, should have been.

~~~
bcrosby95
They started the project of looking for a replacement language in 2015. You
can't instantly rewrite all the code.

~~~
k__
-can't +shouldn't

My co-worker of that time did exactly that one week before I got hired.

Also, he told noone.

I just saw it one time, when I played around with a tool that would visualize
Git commits, years later. Thousands of lines of code.

Absolute mad lad.

------
thrower123
The only people I ever knew personally who used CoffeeScript also used Rails.
That was usually the combo then.

The shine has kind of come off Rails, and the cool kids followed the shiny to
the next thing, usually node, and so they moved to Typescript.

------
skilesare
Still use coffeescriot when I need to do something quick. It has added all the
async goodness of the more recent js implementations and it is still 10x
easier to read and makes me 10x more effective.

------
arkanciscan
I eagerly await the Typescript to SpoonScript (what have) migration of 2027.

------
root_axis
I loved CoffeeScript... I just loved types more. If CoffeeScript had a type
system akin to TS or Flow, I'd be in heaven.

------
eecc
I wonder what happened with the devs that started the tumble towards the
Coffeescript migration... still locked in the cellar?

~~~
szhu
I don't think the CoffeeScript advocates did anything wrong at all.
CoffeeScript was a popular solution with a healthy ecosystem, no one knew when
JS was going to get these features, and TypeScript was still an emerging
player (just like other typed JS variants like Flow).

Also, when I wrote in CoffeeScript, (1) I loved the JavaScript ecosystem more,
(2) I understood the code I wrote better and built and learned more quickly,
and (3) I understood the nuances of an JS-extension language, which helped me
quickly understand what TypeScript was when I heard of it. I'd assume that
other developers got some of these benefits as well, and these benefits may
have been well worth the cost of converting from CoffeeScript later.

------
lewis1028282
Is CoffeeScript all but dead? I use Ruby and Python a lot so the syntax of
CoffeeScript looks great to me!

~~~
jessaustin
Lots of people use it (I use it for all my personal stuff) and it sees regular
updates. [0] I think it coordinates well with modern client-side frameworks
like Mithril (... and experts agree [1]). It has kept up with the new stuff in
javascript, and it often does the new stuff better than JS. Example: in
coffeescript you don't need the goofy function declaration flags that JS
requires: "*" and "async". In coffeescript a generator is a function that
yields and an async function is a function that awaits. This is clearly
better.

Obviously, Typescript is more appealing to management. It may not be obvious
from this thread, but bragging about how old-n-busted coffeescript is compared
to... whatever was a lot cooler a couple of years ago than it is now. Nowadays
the cool kids complain about npm or rollup or something.

[0]
[https://github.com/jashkenas/coffeescript/commits/master](https://github.com/jashkenas/coffeescript/commits/master)

[1]
[https://mithril.js.org/signatures.html#splats](https://mithril.js.org/signatures.html#splats)

------
seemslegit
Cofeescript will always be remembered as peak code hipsterdom.

------
deanmkenzey
You can easily test your Coffeescript code with a dynamic type checker and be
perfectly type safe, even at runtime! Why for gods sake convert your code base
to another language primarily for imaginary type safety?

But for some strange reason entire armies of developers move to Microsoft's
Typescript, living their imaginary type save dream. Moving from a language as
Coffeecript to Typescript is like dropping at least 25% of your productivity.
Not only you'll have to write more code, which in itself increases the chance
for bugs, but you'll also be fighting countless compiler issues, installing
numerous @types modules, having intellectual discussions about types and
whatsoever to make it 'kind of work'. Oh, and almost none of the TS code bases
I've seen are without the 'any' keyword, which is actually an instant breach
of your type safe haven. IMAO 'any' should never pass a code review in a
Typescript project if you want to stay true to your religion. With such a
strict regime, like you are forced to with real strictly typed languages,
would completely eliminate TS. Without 'any' it's practically impossible to
write a large code base with it.

I wrote numerous relatively bug free applications in Coffeescript, small and
large as well. Just do good testing and you'll be fine, and as a bonus you'll
have type safety at runtime! The mine field is not types IMAO, there is so
much more to high quality code bases.

~~~
matchbok
Using 'any' is perfectly fine, you just don't understand how most companies
use TS.

~~~
deanmkenzey
Not using 'any' is also perfectly fine, as you can with Javascript, Python,
Ruby, etc.. And I guess that most companies just don't understand how I use
Coffeescript.

Besides, I am not against others using Typescript, it's a fun experiment and a
great opportunity for front-end developers to learn about static typing, enjoy
it if you can! For me it unfortunately doesn't work, I've never gained from it
because I generally don't have type issues. It's a pain in the ass that's
constantly bugging me, pulling me out of the flow. It's a monster of a tool
that tries to solve a problem I don't have.

