panyasan wrote: > Duh, I should read what I write before sending the "post" button, and have > more coffee. Sorry for the gibberish. What I meant was: > > "... if you write "native" javascript qooxdoo code, you will use all the > strengths that the architecture and logic of the language/library offers > you, resulting in compact and concise code, whereas the code resulting from > the translation of declarative/templating code will be suboptimal compared > to that. ..."
heh-heh, thx, the original did throw me but I had the context so I was able to unravel the intended meaning. > > Anyways, with javascript engines ever-increasing speed, this factor might > loose significance and we will see more compilers that translate into > javascript. I still think that compared to the load carried by qooxdoo internals and network latency and maybe things like jsMath we might use, we just are not writing a large enough fraction of the overall runtime code path to worry about this. And as with compilers, JS-generating hacks can get smarter and possibly end up generating superior code to hand-crafted. jsMath, for example, keeps a dictionary of TeX strings seen and re-uses translations where possible. Final thought: if we want handcrafted code, we should not be using qooxdoo. Have you ever navigated down into the DOM generated? But it works great and fast and makes us more productive overall. Let's get back to work! :) kt -- http://www.stuckonalgebra.com "The best Algebra tutorial program I have seen... in a class by itself." Macworld ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
