Well you may have missed it since this thread is going forever but I
did write something [0]
There was one concept I screwed up and that is in the end the loop and
write doesn't happen on the monolithic SWF, I think it's for external
files that were not linked into the main SWF.
Basically, the compiler loads like MXMLC, using configuration files
and args passed to it.
It the parses all files and then creates an SWF of those files with
dependencies.
The SWF file is then used to write out the js using a JBurg bottom up
reducer/emitter. I am sure these were the classes you were looking at.
The JSEmitter is something that probably could be hacked into but, I
would make sure you have a baseline before you do.
The thing is, everytime I write about this framework I am learning
more. It seems to me the IBackend interface could be golden.
If you look the Only time JSEmitter is created is in a call to;
- JSBackend.createEmitter(ICompilationUnit.Operation, ICompilerProject)
This means we could swap out emitters at runtime! I still need to
investigate this further and don't take anything I say as gold right
now, I'm still learning myself.
NOTE: The first thing I am going to experiement with is "how modular"
the IBackend really is and what it would enable us todo as far as
creating different implementations of emitters.
Mike
- [0]
http://markmail.org/message/e3szly6i6ejq56eg?q=+list:org%2Eapache%2Eincubator%2Eflex-dev&page=6
Quoting Erik de Bruin <e...@ixsoftware.nl>:
Mike,
Can you explain a little bit (maybe in pseudo-code or whatever) about
how the AS3 -> Falcon -> FalsonJS -> JS 'compilation' process works?
What I'm looking for is an idea of how the JS output is put together,
if you will. Example: how easy (or difficult) is it to exchange one JS
"class" creation method for another? Right now it's "Class =
adobe.extend(arg, arg, { theClassBody })". Is it a lot of effort to
change that output to something like "function Class() { theClassBody
}"?
I did look at some of the Java classes that seemed relevant, but soon
realised that without first having some idea of the concepts involved,
"use the Force, read the source" wasn't going to be a useful way to
spend my time ;-)
EdB
On Thu, Nov 29, 2012 at 1:47 PM, Michael Schmalle
<apa...@teotigraphix.com> wrote:
It's not that you can't use a framework and "vanilla" js, it's that it has
been shown that these candy frameworks that hide vanilla method calls to the
DOM severely kill performance. ... For the sake of just entering a $()
dollar sign? That's a crazy tradeoff but thousands do it everyday. For
alittle dev time saved, you kill the actual applications performance.
I was just saying that using AS, you can already have a "framework" you use
that is light, but the compiler would transcode it to the fastest possible
js implementation, since it's now hands off.
Mike
Quoting Kessler CTR Mark J <mark.kessler....@usmc.mil>:
Funniest site I've been to today. It's a good point, but it's prob pretty
difficult to not use a framework at all.
-----Original Message-----
From: Justin Mclean [mailto:justinmcl...@gmail.com] On Behalf Of Justin
Mclean
Sent: Wednesday, November 28, 2012 18:21
To: flex-dev@incubator.apache.org
Subject: Re: [FalconJS] concepts
Hi,
And to eliminate the 'IF' from your conditional statement, just a quick
one:
http://jsperf.com/jqury-vs-plainjs
Slightly off topic but amusing all the same:
http://vanilla-js.com
Reinforces the point that if you want pure performance don't use a
framework and as we're generating the JS there's probably no need to use
one, especially one as heavy as jQuery.
Justin
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
