Here we go again,
I have to say from my stand point, thumbs up for the Erik approach. I
also believe and think about JS output as optimised result of whatever
compiler can do with source code written in AS3.
I can't see any benefit in having mimic of AS3 in JS to the accuracy of
every single line of original code. The only reason to use Flex for this
kind of job would be to have a better tools for debugging and developing
my application.
I don't care how ugly the output code will be as long as it just works
and performs with acceptable performance level.
Otherwise I would forget about AS3, Flex, all tooghether and pick one of
hundreds JS frameworks that are closer to vanilla JS, will produce
understandable and debug-able output for me.
That very scenario is a Flex Doomed for me. If Flex will output slow,
over-bloated stuff, I already have lists of JS frameworks as my
candidates to do the job.
I am not saying that disregard with any effort being made by Alex or
Frank here.
I think you both doing great job. I do understand that Frank might have
personal interest in getting Flex close to Jangaroo for compatibility
purposes, or maybe I am wrong and this just came from experience
building that very tool. But is always like that, there is bunch of
developers who cares and those who doesn't. Within those who do, the do
care about different things sometimes.
We have 2 camps now, performance vs debugging features.
Don't forget this is Flex, not JS people but AS people counting on this
project to stay relevant on the market.
And we have to give them a reason for that. Creating
Yet-Another-Framework/Interpreter will not make it different from all
(put your favourite language here and bunch of new coming up by this
occasion like DART) -> JS solutions that we already have plenty on the
market. And when comes to Flex more challenges are on the way with MXML.
Nobody want to realise after all that effort that after months of
development you can't move a box around smooth enough that even jQuery
looks like a rocket next to it.
I will repeat myself from the very beginning of that conversation, do it
right or don't even start it.
What is already done right is what Michael have done on AST level, it is
abstract enough to try out many concepts for JS output.
I would love to compare Alex and Frank results or anybody who can join
and take it to another level, see how it works in practice, what
advantages are and let community and market decide.
See in practice if my Flex/AS tools are sufficient enough to rely on, if
I can trust output doing a job without diving deep into the language
that by nature, every single person on Earth may create his own way of
doing the same thing. But hey! Some people love it for that freedom of
expression!
Sorry for that wall of text, but I limited myself to just one post per
month by now :)
On 1/28/2013 10:08 AM, Erik de Bruin wrote:
What I don't see in the 'debug JS' approach is what do you do with the
bugs you find in JS? Any changes you make in the JS will get
overwritten the next time you compile the AS, correct? Or am I missing
something?
Oh no, changing the generated JS would be futile, but having clear access to
through, for example, source maps would be really important for being able
to
pinpoint what is going wrong. I'm sure that once Apache Flex starts
churning out
projects that are being cross-compiled we're going to run into edge cases
where the
generated JS doesn't work, or doesn't work as expected. And especially in
the latter
case you'd probably want to be able to play around with the JS to see what
the problem
is exactly.
Certainly, which is why I 'keep' the intermediate JS, which is not
optimised or minified at all. I think the JS output I create is very
readable and matches the original AS structure reasonably well. Not
line for line, to be sure, but close enough to be able to match it
back to the AS code.
In case you missed it in the flood of emails I sent the last couple of
days: I've uploaded the output of my concept so everyone can view the
results without having to set up the whole project. Please look at:
http://people.apache.org/~erikdebruin/vanillasdk/
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
