[wallabyjs]

These projects' focus is a bit different.

Karma was built to run all of your browsers tests in as many different browsers as possible.

Wallaby.js focuses on seamless integration with many code editors and on delivering instant feedback from your (both browser and node.js/io.js) tests.

[jdlshore]

So how does Wallaby run your front-end tests, if not in a real browser?

Even if it does run in a real browser, cross-browser issues are common enough in my work that my TDD loop always includes multiple browsers. I wouldn't be willing to give that up for what Wallaby offers.

Part of the reason I'm interested in something like Wallaby is that running in multiple browsers is slow--but if I could run just the right subset, it would be fast enough for my needs. (And Karma still runs about 200 tests / second on my mid-2002 MacBook Pro, across 10 browsers, including IE VMs, so it's not like Karma is that slow.)

[wallabyjs]

Wallaby.js supports PhantomJs. It also supports node.js/io.js for node tests, as well as for front-end tests with something like jsdom.

Karma is not slow, but some of our tests may be. Wallaby just allows not to run them if we are not editing anything that affects them.

Cross browser issues are always a pain, I know what you mean. However, I have realised that I can write the bulk of my code without worrying too much about them.

When I'm writing the bulk of logic, especially with TDD, I found that it's more efficient to run tests as fast as possible in the fastest engine and care about running across all browsers much less frequently. Especially if you run tests as you type.

Later on, closer to the end of the iteration, when preparing to commit my changes, I surely run all of the tests in all browsers/smartphones/tablets that I support. Typically it just works, especially when your codebase is mature, you already know the majority of cross-browser issue sources and have something in place to avoid them. Even if it doesn't work, the issues are normally easy to solve. Overall, less context switching, more focussed work.

Anyway, it's just my experience (you can read more about the motivation behind wallaby.js in my blog post - http://dm.gl/2015/01/30/wallaby/) and we are planning to support more browser runners, or even just karma as a runner for wallaby, in future. Please feel free to vote (https://github.com/wallabyjs/public/issues/29) or create new feature requests.

[jdlshore]

That's a reasonable perspective. For me, my thorniest issues have come from browser incompatibilities, so it's more important to catch and fix issues at the moment they're introduced rather than later. This isn't necessarily testing all browsers; just the ones that I know are likely to trigger differences. For example, I might run IE 8 + IE 11 + Firefox + Chrome + Mobile Safari.

Fast tests (< 1-5s) have a lot of value to me (although "test when I press save" is as good or even better than "test as I type," as far as I'm concerned), so Wallaby is something I'm interested in. I'm more likely to do manual test sub-setting than give up my cross-browser tests, though.

One potential customer's perspective; you can take it or leave it. :-) I'm not necessarily a good example of the mainstream. I've voted on the issue.

[jdlshore]

erm... mid-2012 MacBook Pro.

[prayerslayer]

Then the obvious question is: Why not have both? :)

http://i0.kym-cdn.com/photos/images/newsfeed/000/538/731/0fc...

[wallabyjs]

Running affected tests as fast as possible and running all of them in a variety of different browsers to make sure your code works everywhere - are two different tasks. Not like they are completely mutually exclusive, but it's hard to run something very fast, as you type your code, if you have to do it in multiple versions of IE/Chrome/FF and perhaps a smartphone/tablet at the same time. Easier to just use different tools at different stages - wallaby when you write code and tests, karma when you need to run them all in many browsers.