I have posted this same questions on the pyjaco thread as well. Part of this line questioning is to understand the fragmentation. There is tremendous interests in a pythong to javascript compiler, yet there are many many implementations non of which is optimal, complete or perfect. Yet instead of improving the ones already available we seem to be fragmenting the development effort
I read now in pyjaco they are reworking a good portion of the pyjaco compiler. So I am trying to understand what drove pyjaco to fork off and not build on the compiler that comes with pyjamas?? Sarvi On Friday, December 21, 2012 5:58:14 AM UTC-8, Lex Berezhny wrote: > > On Fri, Dec 21, 2012 at 7:20 AM, Sarvi Shanmugham > <[email protected]<javascript:> > > wrote: > >> In one of the threads on this list, someone mentioned that the latest GWT >> compiler generated javascript code that was about 200kb while the >> equivalent functionality writen in pyjamas and compiled to javascript was >> about 5Mb. >> Where is the bloat happenning in pyjamas? >> > > Java is a static language, emulating a static language in a dynamic > language is simpler than the reverse so there isn't much involved in the > GWT runtime. Also, GWT has optimization routines that will inline some code > and not include unused code, etc. > > Python is in some ways more dynamic than JavaScript and also is more > structured. Python has a pretty intricate class/inheritance system which > needs to be emulated among other things. And because it's part of the > runtime it will always get sucked into your compiled app (even if your > hello world example isn't using classes or other python features). > > Unlike the GWT compiler working on static Java, with Python there is no > way to know at compile time what features you will use since Python is so > dynamic. > > Having said that, Pyjs is still smart enough to pull in only modules you > have "import" statements for. This helps a lot. But there is always room > for improvement. This also means that you can't dynamically import code, > rather the compiler cannot figure out what you're importing. There is an > extensive list of command line arguments you can use to modify what will > get compiled or imported, so there is some room for customization. > > >> Is it the python-to-javascript compiler OR is it caused by an >> inefficient translation of the GWT widget set from Java to Python? >> > > I would say it's both. The GWT widgets are optimized for the > java-to-javascript compiler. You can do things in Python that you can't in > Java so if the widgets were rewritten to be more Pythonic it may be > possible to reduce their size. But it wouldn't make sense to rewrite the > widgets since someone would have to maintain them and we would lose the > automatic conversion (granted it's already half automatic/half manual). > Also, if you redo the widgets to be more Pythonic the GWT API documentation > would no longer be as useful when using pyjs. > > The solution to this in my opinion is to just make your own widgets as you > need them. Keep in mind that Pyjs is built on HTML/CSS. A widget is nothing > more than some HTML and CSS styling. A web designer can make your widgets > for you, then you add behavior to them with Pyjs. > > - lex > --
