> Adding the additional translation layer increases the potential of bugs > the implementation has information that could be used to generate better bytecode

> Adding the additional translation layer increases the potential of bugs > the implementation has information that could be used to generate better bytecode These are theoreticals. Let me analogize. Some algorithms have a worst-case big O that is significantly worse than the average case. So even though the algorithm could have very poor performance in certain situations, it's better for the "real-world" cases that it gets used in. Most of the existing Haxe targets have similar external semantics(Algol-derived, GC, dynamic types), so we're in an average-case situation of both reliability and performance; the Q probability is close to zero because the code we input isn't that drastically different from human source input, and the input we pass in from Haxe can be a bit more optimized in most respects, because we don't have to make it maintainable. If we were targeting a really bad compiler, it would blow up. But in practice, it doesn't and we gain more than we lose, even when considering areas where there's an impedance mismatch and we have to, for example, add dynamic types on top. Bytecode output is more sensible within a short-term view - a single project with known specifications. But it's ultimately the need for flexibility that drives Haxe, and you aren't gaining additional flexibility from bytecode.