incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <apa...@teotigraphix.com>
Subject Re: [FalconJS] concepts
Date Thu, 29 Nov 2012 13:22:44 GMT
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 <erik@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
> <apache@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.ctr@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:justinmclean@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


Mime
View raw message