The main challenge we're facing is keeping the QtScript API behave 100% as it does today; it's not acceptable that the behavior changes just because us speed freaks decide to replace the back-end, of course. The main aid we have in this regard is the set of QtScript autotests; assuming the tests are all-encompassing (which, let's face it, is hard to guarantee, but let's pretend...), after completing the back-end swap, all the tests should still pass. Once this goal is reached, some brave soul would step forward, brown paper bag in hand, asserting that except for performance improvements, it's not possible for the application developer to tell that the QtScript runtime was replaced. OK, so we'll probably have to do some real-world testing as well.
Work on the back-end had been put on hold for some time due to various other projects, but now we're slowly getting back in business again. And the best news is that the ongoing work is now out in the open (qtscript-jsc-backend branch)! Now before you start doing the Qt dance, just keep in mind that the branch is not currently in a state where it can be used to run new or existing apps against the back-end, because not all the API and/or behavior is implemented yet. Currently we're working on bringing it up-to-date with the last few months of changes in WebKit trunk, then we can focus on remaining API. In case you're interested in helping out hardcore hacker-style, though, there's an easy recipe that we all follow: Run one of the qscript* autotests, look for failures or asserts that say "Implement me", and hack on the implementation until the test passes. :-) Test statement by test statement, the compatibility will get there. Happy hacking!