I’ve traditionally thought of myself as a backend developer: my career, before management, was in Java, C, Perl, Python and Ruby. I admit to scoffing at the idea of Javascript as a “real” language as late as 2011, even though some amazing work was being done with it in the previous decade.
Recently, I realised that I was really enjoying writing Javascript. This came as a complete surprise to me, which says a lot more about me than it does about Javascript.
I’m now going to tell you about four tools that make Javascript an actual joy to program with in 2017.
React
When I first heard about it, I wasn’t sold. “HTML in your Javascript? I thought we all decided that was a terrible idea!” It was this talk by Conrad Pankoff presented at CampJS IV in 2014 that brought me around.
What I love about React is the unidirectional information flow. I think that’s because I am a backend developer: in Rails, you load something from a database, muck with it a bit, and then render it in a view. Your view is entirely a product of a particular set of a data, rather than something that’s built up over time. React’s the same: the HTML that is generated by the JSX is entirely dependant on the component’s properties and state.
Effectively, this makes it much easier for the developer to reason through how the component will appear in response to different interactions.
Babel
For me, ES2015 and onward resolve many of the problems I had with Javascript back when I first started working with it in 2005. It adds language features that make it much easier to control flow, work with objects, and define classes.
Babel means that I can use those features today. The great thing about Babel when compared to tools that compile to Javascript and offer better constructs is that I can have the confidence that what I’m writing today will still be supported tomorrow — it’s just a newer version of Javascript, and eventually I might not even need Babel.
ESLint
ESLint is my favourite linter for one reason: its documentation. With other linters I quite often find that it’ll tell me off for doing something but not offer me a constructive way to resolve that problem.
ESLint, on the other hand, prints an easily-googlable rule name along with each warning, and the documentation for that rule often lists workarounds or conditions where the rule shouldn’t apply.
For example, I was recently hit by react/no-unescaped-entities as I added doesn't (note apostrophe) to some JSX I was writing. The documentation not only goes in to why that's a problem, but also gave me a workaround: use '.
Flow
This could have easily been TypeScript, but I learned Flow first, and it felt like a better fit for our existing project.
Flow was the last piece of the puzzle: on adding it to the stack, I suddenly realised I was really enjoying working with Javascript.
The obvious thing I love about Flow is that it gives me confidence when working with large projects in Javascript. I’d worked with statically typed languages before, so it wasn’t hard for me to immediately see the benefits. My team were convinced when I showed them a common mistake — changing the core type of an object attribute in one file and having it error on another — and how quickly Flow would let you see that you’d done something wrong.
The less obvious thing I love about Flow is that you can have the best of both worlds: by using the any type, you can effectively prototype code as you would dynamically, and then later treat the any typedefs as TODOs and correct them when you have more confidence in your architecture.