On Fri, Dec 21, 2012 at 9:35 AM, Sarvi Shanmugham <[email protected]>wrote:
> So I am trying to understand what drove pyjaco to fork off and not build > on the compiler that comes with pyjamas?? > My hunch and something I've experienced myself is that the pyjs compiler / runtime has a lot of hacks and patches to make it work. This is partly because as I said, people are actually using pyjs in production systems. There is a lot of effort into making sure we don't brake existing APIs and functionality. It's very difficult to overhaul sections of the compiler/runtime without breaking that compatibility so instead of doing major rewrite/refactorings we end up patching things. It wouldn't surprise me (especially with the comments I saw on their mailing list regarding a rewrite) that they would rather start new and designed the system the way they want than to spend time trying to fix an older system. The race becomes between how quickly they can get their new, hopefully much better designed compiler, to the level of pyjs vs how quickly we can refactor and add new features to pyjs while maintaining backwards compatibility. It seems you have the following choice to make: 1) go with pyjs, which works right now, something people are already using in production but with a complex code base that needs refactoring or 2) jump on the pyjaco bandwagon and help to get their compiler and tools to a working state with better design and hopefuly this will happen within your required timeframe to start your own project. If you need something now, you don't have much of a choice, pyjs is used in production systems today. If you can put a few months of full time development towards either framework then you can decide between helping to refactor pyjs or working on a new pyjaco compiler. That's my estimation of this situation. - lex --
