Bruce Pascoe

I think he means just-in-time (JIT) compilation, which Duktape doesn't have--it's 100% bytecode-interpreted.

The biggest obstacle right now, as I understand it, is that the Duktape compiler has no AST or any kind of intermediate representation at all. It's all recursive-descent with very...

x86, x64 and ARM would probably be a good starting point. x86 is still relevant since it's the preferred target for Windows applications that don't need the full 64-bit address...

Keep in mind there may be some mobile ARM platforms (such as iOS) that won't benefit from this due to limitations/restrictions in the underlying platform. This is one of Duktape's...

I'm indifferent to the class support, but fat arrows would be one thing I'd _love_ to have in Duktape. :) I don't imagine this to be too difficult to implement...

There's no operator stack? How does that work? I would have thought there would have to be since for infix operators (as opposed to prefix or postfix, which are easy)...

It occurs to me that a lot of ES6 constructs like this could be implemented even in the current compiler, if the parser were reworked to be able to look...

For the test cases that fail due to stack overflow, you can probably work around it by increasing the stack size when compiling the test harness and/or Duktape. The default...

Semantically, `` `foo ${bar} quux` `` should be exactly equivalent to `"foo " + bar + " quux"`. I don't think that would be too difficult to parse?

> To be clear, there's nothing conceptually difficult with about any of the ES6 syntax constructs as such, they're pretty standard syntax constructs. I agree for the most part, with...