Early Returns in JavaScript
Jennifer Lyn Parsons
Posted on July 29, 2018
A couple of articles related to how early returns work crossed my path recently, enough to pique my curiosity. Learning about early returns in JS has been not only a challenging technical exploration, but also pretty fun. In researching the concept, I remembered how much I enjoy learning something for it's own sake, not just as a means to an end. Sure, the information I gathered is useful and the technique is something I'll likely employ in the long run, but it was just as valuable enjoying following the trail of breadcrumbs that led to my final conclusion.
What is an early return?
In short, an early return provides functionality so the result of a conditional statement can be returned as soon as a result is available, rather than wait until the rest of the function is run.
Surprisingly, I hadn't seen this kind of pattern in JS before, though I'm used to seeing it in Ruby, where it's quite common. I was curious as to why that was. A bit of research showed me that returning only after the rest of the code had run, whether it was needed or not, was a holdover from older imperative programming languages where it was required to return at the end of a function to ensure the code ran in the correct order.
The only answer I could really find to why I hadn't run into this pattern before is that even now this is not taught nor talked about enough for folks to start using it regularly, dropping the imperative style. A few newer devs have started the conversation and argue quite strongly that it's clearer to read.
I still had questions
I was unsure about the readability of this style. I'm so used to reading if/else statements with a variable set at the top of the function that gets returned at the end. Having multiple returns or even multiple if statements (rather than if/else) felt like it would be more challenging to understand at a glance.
More important than readability, I wondered how performant it was versus the single point/end of function returns. My gut told me it was probably faster because, in theory, less code was being run. In researching this, I found a pre-2012 article hinting it might actually be less performant but didn't find any information after that supporting one style or the other.
It would be interesting to discover that a single return was faster and if it was, why that was so. I decided to run some benchmarks to see what our winner was.
Benchmarking early returns
Here are my benchmark tests: JavaScript benchmark playground
As you can see when you run the tests, there are only 10s of milliseconds difference in speed between the various options, fairly negligible. While I get slightly different results each time I run the benchmarks, with the old imperitive style comes out on top every time. Not what I was expecting! Generally, it looks like "early return within an if/else" comes in second to "early returns with single statements", though it's pretty much a wash between them.
Conclusion
In comparing these examples, I find I prefer a single if/else for readability, regardless of whether it's an early return or single return. While early returns feels less cumbersome than setting up a variable just to have a return value as in single return, knowing that there's a performance hit as well means I'll be likely sticking with the old style. Additionally, having a series of statements inside a function as in the "early returns with single statements" version abstracts the fact that they're consequentially connected to each other and to me, that's less readable.
All in all I feel like I've gained a deeper grasp on some of JavaScript's inner workings, with the bonus of trying out some benchmarking and learning a bit of programming history as well.
Resources
Posted on July 29, 2018
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.