CoffeeScript

Stitch’s frontend is used to configure data sources and destinations and monitor the status of each. Although we have been using AngularJS since its early days, we recently introduced React components into our front end, which many of our developers find easier to work with. We started using CoffeeScript when it was one of the few options for a more expressive alternative to vanilla JavaScript, but today we opt to instead write new code in ES6, which we feel is a more mature alternative.

We chose TypeScript at Codecov when undergoing a recent rewrite of a legacy front end. Our previous front end was a mishmash of vanilla JavaScript and CoffeeScript , and was expanded upon haphazardly as the need arose. Without a unifying set of paradigms and patterns, the CoffeeScript and JavaScript setup was proving hard to maintain and expand upon by an engineering team. During a move to Vue.js , we decided to also make the move to TypeScript. Integrating TypeScript and Vue.js is fairly well understood at this point, so the setup wasn't all that difficult, and we felt that the benefits of incorporating TypeScript would outweigh the required time to set it up and get our engineering team up to speed.

Choosing to add TypeScript has given us one more layer to rely on to help enforce code quality, good standards, and best practices within our engineering organization. One of the biggest benefits for us as an engineering team has been how well our IDEs and editors (e.g., Visual Studio Code ) integrate with and understand TypeScript . This allows developers to catch many more errors at development time instead of relying on run time. The end result is safer (from a type perspective) code and a more efficient coding experience that helps to catch and remove errors with less developer effort.

In 2014, PagerDuty struggled with safely releasing reliable mobile applications to users due to some issues with how the code was being packaged and handled.

PagerDuty’s mobile apps are hybrid and used Cordova to share code between platforms. Coding was straightforward but packaging was not, as a separated Gulp-based build process was also being used. The PagerDuty team took a page from Java and started creating software artifacts.

Rather than checking in transformed code or publishing modules to NPM, the team started creating zipped-up build artifacts, which coincided perfectly with GitHub's Releases feature which arrived in 2013. So despite JavaScript lacking a standard packaged app format like a JAR, PagerDuty was still able to improve the build times and sizes of their mobile apps.

Long ago when Angular 2 evolved I had to decide between the new #Angular and TypeScript or React. I really love typing my code, but forced to use TypeScript was a bit too much. I prefer the new #ECMA standard and the evolution of the old and reliable JavaScript. So finding Flow (JS) was an incredible milestone in my career as a developer. Finally, I could use types in my code, and JavaScript with the new standard. I already had the experience of CoffeeScript, so TypeScript was not an option.

All front-end / back-end is driven by Coffeescript. For the main ReactJS functionality JSX is embedded with coffee in .cjsx files / handled by Browserify. CoffeeScript

All of our Javascript code is first written in CoffeeScript for ease of reading / writing. It is compiled to Javascript before being minified and served to the client. CoffeeScript