Frank,
Definitely a cultural difference here with my writing below.
Basically, the point was, you CAN compare right now but, I think Erik
was or just missed that fact you CAN compare right now.
As far as your comments about how things should be compared, my point
was, start comparing! :) Enough of the emails, like you said, you have
the two outputs, go to town.
Again, I guess I should have just kept my mouth shut here as I have
previously stated, I will never have an opinion about this stuff,
since I will never know enough to give an opinion. :)
Frank, a lot of what I said below was from a more sarcastic, lets just
get the ball rolling point of view.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
On Sun, Jan 27, 2013 at 2:51 PM, Michael Schmalle
<apa...@teotigraphix.com>wrote:
Quoting Frank Wienberg <fr...@jangaroo.net>:
I'm looking forward to seeing the Falcon implementation of your
AMD/RequireJS ideas and it's output, so we can compare the various
suggested approaches on their technical merits as well as their
theoretical underpinnings.
Okay, we can wait for that, but since Michael says what I did with
Jangaroo
3 is easily re-implemented in Falcon, why not compare now? The output
will/should be very very similar to what the Jangaroo 3 output looks like
now, e.g. the one of the Open Flash Chart example.
Another idea would be I take your example code (or any other code you
want)
and compile it with Jangaroo 3 and also deploy the output. What do you
think?
Greetings
-Frank-
I am pretty sure he means, "When Mike implements this in FalconJx, we con
compare" ;-)
Sorry if I missed a joke, but I was saying the opposite, why not compare
now? Why does it have to be implemented in FalconJx when we discuss/compare
the output format, not the compile process?
MXML is going to wait, I did a bit bit, put some hooks in but there is
more pressing things I want to spend my time on, this is one and the other
is what Roland just announced for discussion with the compiler.
So do we really only compare the approaches by the resulting performance?
That would be sad.
There are many other factors:
* Code size
* Modularity (= do you have to re-compile class B if class A changed?)
* Development turn-around effort
* Complexity of solution
* ...
These should all be regarded before a final decision for one or the other.
Greetings
-Frank-
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
