Quite some time ago I had to decide for some technologies I'd like to use for one of my projects. It's quite a big project - with some fancy requirements like realtime components or being completely RESTified, backend and frontend independent from each other, etc..

I had a look at different technologies; for back- and frontend. I quickly found a neat solution on the server-side: NodeJS. It has good realtime capabilities, is extremely fast (as long as you're not doing math-heavy stuff) and JavaScript is pretty simple.

PHP wouldn't have fit this requirements; doing realtime stuff with PHP is still very hacky. Running infinite loops and polling... that's just really weird.

I've done some things in Java but didn't get used to it - and since most of my experiences were with GWT I'm kinda afraid of doing web stuff with Java.

The next thing I had to find out: which NodeJS framework to use? I could have gone the simple way of just taking ExpressJS and putting my API on top... but since I really like MVC I wanted something implementing this pattern.

Sadly (or gladly, I'm not sure yet) the NodeJS world is still very young and there aren't tons of frameworks out there. Back then the only real choice was SailsJS. It implements the MVC pattern, helps in developing realtime application by exposing some realtime stuff and is actively maintained.

I tried different frameworks for the client, for example Ember or Angular. Both are great frameworks - but in the end I chose Angular, since I had some experience with it and liked its approach of how things are developed.

Lastly I wanted some OOP - on either backend or frontend (preferably both). Just some classes and some inheritance and I would have been happy.

TypeScript was very young at this point and I didn't know much about Babel. So the only thing left was CoffeeScript. It looked a bit weird (and I really don't like this indent style) but it allowed me to write object oriented - which was everything I asked for!

As the project progressed tons of new technologies were born; if I could go back in time I'd probably wait for a component-based framework like Angular 2 or React. But it was important to stick to my decisions; due to the project size I couldn't afford going back that much by re-implementing the entire client. I'm already very vulnerable to one of the most basic rules of developing:

Premature optimization is the root of all evil.

I often catch myself refactoring stuff just because of _"This can be done better!" or "Just a slight change here...! (which most of the time resolves in rewriting entire modules)". This is bad (well, not really, but it's not economical) - but since it's my private project it is kinda acceptable. (When working for clients and knowing that I could have done some things better - but there's no budget or interest in it - it slowly kills me inside...)

But throughout the months (or even years by now) I've learned to somehow control my urge to go virtually back in time and do things again just because of having it done better. After some time I learned that I want to be done at some point - hence I always need to remember the wisdom from above.

But what if the technology you decided to use is becoming obsolet or - even worse - dying?

That's exactly what is happening to CoffeeScript.

Babel and TypeScript are "more familiar" to write (I like curly braces!), offer the same or even more features (especially TypeScript) and have a huge foundation;

Babel is basically just native JS - but it allows you to use features from future JavaScript standards. This means that at some point in the future the current Babel will be the same as native JS. It's safe to say at this point that this technology won't die in near future.

TypeScript is just a superset of Babel - it adds types (and some more features) to ES6. And what's also pretty important here: Microsoft stands behind it.

In the end using CoffeeScript just because of OOP isn't worth it anymore. If you want to have OOP you can just go with Babel or TypeScript. But is "having alternatives" really a reason not to use a technology? No, of course not. But...

CoffeeScript is dying. Big projects like GitLab or Atom are moving away from CoffeeScript. For the same reasons as this post stated: it used to be good, but now there are way better alternatives.

There's no official statement about "CoffeeScript is dead" - but just keep in mind that:

  1. as said above: seeing big projects moving away from a technology isn't good for the technology.
  2. it seems like it's already neglected by its creators. Just 7 releases this year, where four of them were just patches and the other three were minor releases.

According to this issue we might see something like CoffeeScript Version 2 - but I haven't found any decent information about this.

In the end the remaining question is: should I get rid of CoffeeScript and re-implement in ES6 (or TypeScript)? Yes. I'm already migrating to ES6.

There's a chance that CoffeeScript might disappear - or gets "forgotten" by its developers. I'm sure that it'll be around for a long time (since it's already used in a lot of projects), but I'm not sure if it's future-proof. Honestly I don't believe this at all. So migrating at this point made sense for me; at this stage of my project migration takes around one day, which is fine.

And migrating has one additional advantage: if someone joins the project he or she could easily start developing. No need to learn a new technology at all.

Conclusion

  • make sure the technologies you're going to use are future-proof as good as you can.
  • compare your technology. Don't be that silly kid who's like "technology XY is the best!".
  • stick to your technologies as good as possible. Don't swap them just because there's something newer or more fancy. Only swap if there's an urgent need (like the technology lost its maintainer, its going to be abadoned, whatever)
  • and always keep in mind that: Premature optimization is the root of all evil.

P.S. I will make use of ES6 or TypeScript in Sails as soon as v1 is released. Since I'm really interested in this there'll be a post about it for sure.