While my main area of expertise is backend development over the years I’ve found myself (willingly or not) writing more and more javascript code. Over the years it became more and more enjoyable. What used to be piecing together random jQuery plugins evolved into an ecosystem that can only be described as vast and rapidly evolving (sometimes too much so).

Recently I was tasked with creating a simple file inventory system, which was a nice change from maintaining and extending big, years-old codebases. Excitingly I had complete freedom in choosing the front-end technology stack so I set out to review available options.

The most “cutting edge” one at the moment is definitely elm-lang whose strength is advertised by the tagline “Generate JavaScript with great performance and no runtime exceptions.”. Elm is a functional language with a strict type system and a fantastic compiler (it’s suggestions are extremely helpful). Both those combined make it easy to be sure that app code covers all possible scenarios. The thing that made me disqualify Elm was that it definitely comes with a learning curve and I wanted to make sure that whoever maintains the project after me can get up to speed as soon as possible. Though I’ll definitely keep an eye on its further development.

Back in the JS-that-almost-looks-like-JS world it seemed that TypeScript was gaining massive popularity, and it definitely seemed like something I could use. The syntax was close enough to vanilla JS to make the learning curve almost nonexistent, while the language features still provided a lot of benefits. The thing I liked the most, that was a major improvement from the last time I read about the language was definitely the @types repository on npm. It contains type definitions for most of the most popular JS frameworks and libraries, allowing to take full advantage of the type system even if the original author didn’t use TypeScript. That then, combined with React was my final choice (if you’re interested in how to set this combo up, there’s a great guide in the official TS docs).

After delivering the project at the end of 2017 I’m really happy with my choice. All the IntelliSense features in VSCode made writing TypeScript extremely easy and didn’t make me miss the comforts of IntelliJs PyCharm I use for backend development, which was a first as far as working with frontend for me. There’s also all the tooling you may need for automated code quality control.

There are a couple of conclusions from this. First, TypeScript is an excellent choice to start writing an app today, for all the reasons mentioned above. But I still think Elm is extremely exciting. With a more complex application the payoff for having the whole team learn the language will definitely be there, which is why I’m eagerly awaiting 1.0 release.