Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Interview about Wallaby.js and Quokka.js JavaScript Productivity Tools

Interview about Wallaby.js and Quokka.js JavaScript Productivity Tools

Key Takeaways

  • Wallaby.js provides distraction-free JavaScript Testing within popular IDEs
  • Quokka.js supports rapid JavaScript prototyping within your IDE
  • Wallaby provides a variety of features including time-travel debugging
  • Both Quokka and Wallaby augment the developer experience as code gets authored, prior to running an application through various CI processes
  • The new Wallaby Test Story Viewer allows viewing all code executed by Wallaby in a single logical start to finish view rather than using a debugger to jump from file to file, function to function.


Wallaby.js and Quokka.js are JavaScript/TypeScript productivity tools that provide additional capabilities within IDEs such as VS Code, WebStorm, Sublime, or Atom. Quokka.js provides additional runtime value introspection information within context in an IDE, while Wallaby.js provides distraction free testing by providing test results within the IDE. Wallaby.js is a commercial product while Quokka.js is available in both a free and paid version. A trial is available for the paid version of both products.

Today we’re joined by Simon McEnlly, COO at Wallaby.

InfoQ: Thanks for joining us, Simon. Before we get into the real details, I have to ask about the project names. You and your team are based on the Gold Coast, Australia, so for the non-Australians reading along, what do Wallaby and Quokka mean and how did your team come up with these names for your products?

McEnlly: Thanks for having me with you today. Wallaby and Quokka are actually the names of two animals that are native to Australia. Coming up with internal project names is relatively simple in comparison to external product names. We knew we had to pick something that was unique and memorable. We also wanted something that embodied a little bit about who we are, so we decided to name our products after animals that are native to Australia. At the end of May, we released a third product, Dingo, which is named after a Canine that is native to Australia. Dingo is an open-source extension for VS Code that allows you to download, install and open git repos and the source code for npm packages from the comfort of your editor.

InfoQ: What came first, Wallaby or Quokka?

McEnlly: Wallaby came first. The first version of Wallaby was released at the beginning of 2015. After getting Wallaby to the point where we were happy with the base feature set, we saw the opportunity to re-use a lot of the same concepts (and even some of our source code) to create a stand-alone in-editor playground for JavaScript developers. We released the first version of Quokka in April 2017.

InfoQ: When and how did your team begin working on the problem of better JavaScript developer productivity?

McEnlly: As a company, our leadership team all have a history of creating developer productivity tools prior to Wallaby. The earliest foray into the JavaScript space started in 2013. Our founder and CEO, Artem Govorov, was doing a lot of front-end development work (he and I were actually working at the same company at the time). Artem saw first-hand the lack of developer productivity tooling and started working on a hobby project, Spy.js (a tool for debugging, tracing, and profiling JavaScript). Spy.js was later acquired by JetBrains and Artem worked as a part of the WebStorm team to integrate it with their editors before leaving JetBrains to start Wallaby.

InfoQ: Clearly your projects work well with a variety of JavaScript frameworks and testing frameworks. What would need to happen for other web and testing frameworks to work out of the box with Wallaby and Quokka?

McEnlly: Besides adding new features to our products, we’re constantly adding support for new versions of the existing technologies that we support. We’re very careful about supporting additional frameworks because after the initial integration/implementation, we know that supporting a new technology will take a lot of effort over time and we don’t want to ever be in a position where we can’t keep our existing users happy. We also try to make sure that there is enough demand before adding a new supported technology and that what we are working on aligns with what is going to help the largest number of our users. We consider user requests (+1 in our github issues), and other stats such as npm package downloads, github stars, State of JavaScript 2019. In terms of other frameworks, we look a lot at votes on open issues.

InfoQ: What’s the journey been like for your team to add support for a wide range of the JavaScript ecosystem.

McEnlly: In many cases, we find that when users report a problem with Wallaby, the problem actually stems from code in one of the technologies that we integrate with which we need either to work around or show users how the same problem exists outside of Wallaby. As a result, our team has to be experts in reading and debugging other people’s code (complex frameworks) as well as being experts in a wide range of technologies.

In the last 12-18 months, we have also seen a convergence of testing framework technologies for unit testing technologies (e.g. more people switching to use Jest), which has in some ways simplified things for us. Having said that, we’re always keeping up with TypeScript/JavaScript language changes to support those in our products and are already seeing how things may change over the coming year with Node.js native support for ECMAScript modules, and with Deno as a JavaScript/TypeScript runtime.

InfoQ: How does Wallaby compare to other testing environments such as Cypress?

McEnlly: It's a bit hard to compare Wallaby and Cypress because they are not competing products. Cypress specialises in running tests in browser environments and displaying rendered UI related results, such as app preview and command log, in its own UI. Wallaby specialises in running tests in the background as you type and displays execution results, such as code coverage and runtime values, in your IDE/editor.

Cypress is typically used for end-to-end tests running in browsers. Wallaby is typically used for tests that are faster than end-to-end tests, such as unit tests or integration tests running in the browser, or node.js, or node.js with browser environment emulation like Jest with JSDOM. I said "typically", because Cypress is not limited to running end-to-end tests only, and Wallaby is not limited to running unit or integration tests. Also, in the modern testing world the borders between types of tests are blurry.

The different technologies each have a place (even in a single project) and can and do work very well together. For example, by default a Create React Application uses Jest for unit tests and Cypress for end-to-end tests. Wallaby is a nice addition to the same project, providing real-time feedback in your editor while you're writing your code/tests. Jest CLI then runs the same unit tests that Wallaby was running for you when you build your production output or from your CI server on commit. On the same project, Cypress is nicely handling end-to-end tests ensuring everything is passing on multiple different types of browsers

InfoQ: Wallaby.js recently introduced Time-Travel Debugging, an approach the JavaScript ecosystem has discussed for several years including early efforts from the Microsoft Chakra and Mozilla teams, as well as various framework-specific solutions. Could you explain how Time-Travel Debugging works in Wallaby?

McEnlly: Before Wallaby runs your tests, Wallaby adds its own instrumentation instructions on top of your code. This allows code coverage reporting, error reporting, etc. without impacting your code.

When you debug a test using Wallaby’s Time-Travel Debugger, Wallaby adds additional instrumentation instructions to record and remember every step that was executed when your test ran. There was a lot of research and development that we performed to determine how to do this in the most efficient way from both a CPU and memory perspective. Because Wallaby is a test-runner and knows how to quickly re-execute a single test, we only store the steps that were taken and not the memory state, which allows users to explore runtime values by re-executing tests instead of storing complete memory state.

One of the coolest things about the time travel debugger is the ability to move forward and backwards, both into/over, and out of function calls. This is made possible by Wallaby’s instrumentation storing the current call depth. On top of the raw data that is captured, there is a lot of proprietary logic that was part of our R&D that allows us to provide a predictable and intuitive user experience even though we have incomplete information from the JavaScript runtime (e.g. async functions that don’t map back to a specific caller). This allows us to provide features like step out, step into, and edit-and-continue.

InfoQ: Another recent addition to Wallaby.js is Test Stories. Could you introduce us to this feature and its benefits?

McEnlly: A bit of background before answering this question. One of our guiding principles at Wallaby is to only create products that we ourselves will use on a daily basis. This allows us to truly understand and feel the same pains that our users do. For a long time, we’d felt the pain of working on an unfamiliar test that was breaking and not really knowing what it was doing. Our time-travel debugger made this a lot easier but didn’t fully eliminate the pain. We realized that the problem was that code is structured in a way that is best for editing and maintenance, but is not ideal for when you want to read the code to understand the sequence of executed steps.

Leveraging the work that we did to support Time Travel Debugging, we were able to create a new Test Story Viewer that allows you to see all of your code that was executed by Wallaby in a single logical start to finish view rather than using a debugger to jump from file to file, function to function. Our own experience using this feature is that the Test Story Viewer reduces the time to understand a medium complexity test by 5-10 times what it would take vs. desk checking, and is 2-3 times faster than using a traditional debugger.

InfoQ: For some of your introspection capabilities, it feels like there may be some overlap with TypeScript language service features. How have your products changed as TypeScript has emerged and improved? Do you leverage TypeScript’s language services or something similar for some of your capabilities?

McEnlly: TypeScript’s language services are very much in the world of static analysis that is facilitated due to TypeScript being a strongly typed language. In contrast, Wallaby’s introspection capabilities come from having actually run your code. We don’t actually need (or use) any of TypeScript’s language services to provide Wallaby’s features. However, we always stay current with upcoming TypeScript releases to ensure that new features in the latest version of TypeScript are supported by Wallaby/Quokka. In terms of our own code base, TypeScript changes do not really affect us.

InfoQ: How are Wallaby and Quokka created? Are they a mixture of JavaScript and whatever language is necessary to extend each IDE?

McEnlly: Wallaby and Quokka share a common runtime environment that is written entirely in JavaScript. We use TypeScript to transpile our JavaScript files so we can use the latest language features and still support earlier versions of Node.js (from v8.x+). Outside of the common runtime environment, we use a number of different programming languages, JavaScript, TypeScript, Java, Python, and C#. As you alluded to, each editor forces us to use a given programming language (e.g. JavaScript/TypeScript for VS Code, Java/Kotlin for JetBrains editors, Python for Sublime Text, .NET language for Visual Studio). The way that we structure our development, normally a team member is responsible for a specific new feature. This means that throughout the course of adding a feature, it’s not uncommon for someone to be working across 5 different programming languages.

InfoQ: Thanks Simon for making the time to speak with us about Wallaby and Quokka!

McEnlly: Thank you. If any of your readers are interested in contacting us, our contact details are on the Wallaby website. We also offer fully-functional 15-day trial licenses for both Wallaby and Quokka.

About the Interviewee

Simon McEnlly is the Chief Operating Officer at Wallaby. Simon has been creating software development tooling for other software developers since 2006. He is passionate about programming and software engineering and creating development tools that allow others to create their software in shorter time frames, with higher quality, and greater ease. Simon started programming at the age of 13 and has never stopped. He has 20 years commercial experience and in that time has performed a number of different roles (software engineer, software development manager, business development) working for a range of companies from start-ups (2-3 people) to much larger businesses (such as Amazon).

Rate this Article