In search of the perfect Front End Language
Beyond just the syntactic updates to the language, one of the major changes has come with the tooling that is now available. Using Webpack, we no longer need to load modules via script tags and are able to bundle up our code in such a way that is compatible with web-browsers. This has enabled Front End Engineers to think about UI application design in terms of components, making it simple to package up reusable interface component libraries.
I spent roughly 3–4 months reading books about Elm before I took the dive into using it for a project. I have to say that Elm is by far my favorite of the three and in fact might be one of my favorite languages of all time. First-class support for: static typing, persistent immutable data structures, auto-currying, ADTs, the Elm architecture, etc. The list goes on and on. Elm is a Front End Functional Programmer’s best friend and is right up my alley.
With all of this said, Elm is not my top choice for Front End languages. Elm is still very much a niche language without a terrible amount of widespread industry acceptance. My desire to be involved in a number of projects as an independent contractor keeps me motivated to use more mainstream technologies for the time being. Perhaps in a year or so, Elm will rank number 1 for me.
TypeScript is a blast to work with and is very easy to get setup with it. Using Webpack makes incorporating TypeScript as easy as installing a loader and saving files to a .ts(x) extension. Other than a few demonstration projects, the first real project that I made using TypeScript as the main language is the scalable-react-ts-boilerplate project. This project is a spin-off of another boilerplate micro-framework that I built as leader of the Udacity Alumni Web Team. It implements the same feature-first architectural pattern, but using TypeScript as the main language.
In building this project, the realization that I made is that TypeScript is very well fit for building UI component libraries. As part of this boilerplate, I built a dozen or so reusable UI components, which demonstrated the capacity of TypeScript to facilitate self-documenting APIs. This is also the case for GraphQL, a library that I am also incredibly fond of, as it also deploys a static type system which facilitates automatic documentation of your application’s data layer. Due to the fact that in 2017, I will be working as a core contributor on several UI Component libraries, TypeScript is starting to make a lot of sense for me.