You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Roland Zwaga <ro...@stackandheap.com> on 2013/01/25 20:37:26 UTC
[ASJS] Integration with existing JS libraries and components
Hi there,
to continue the discussion about AS->JS cross compilation, I'd like to add
another option which, I think, could
lead to better acceptance of Apache Flex in the HTML5/JS sphere.
The title of this message says exactly what I mean. Right now we're talking
about cross compiling the Flex SDK
itself, along with all of its components.
Which is great, I am not against this at all. But, it would definitely also
make sense for us to be able integrate with
the enormous wealth of JS components already out there. (Yes, this would
only make sense if you only plan to
cross compile your project to JS, not also to SWF, but I believe this is
could be a very common use-case in the future).
The way that TypeScript and Randori/SharpKit integrate with JS is by
declaring some sort of interface which has exactly
the same signatures of their JS counterparts. I think this will quite
probably make the most sense for Apache Flex as well.
And we could just use regular actionscript interfaces to do it. Probably
with a small bit of annotation, so, for example,
a JQuery AS3 integration could look like this:
[NativeAPI(path="/js/jquery-1.4.js")]
public interface IJQuery {
function Each():IJQuery;
function getJSON():IJQuery;
//etc, etc, etc
}
What we then would need is some sort of compiler support that recognizes
the annotation and automatically includes the
specified .js file. (instead of trying to cross compile the interface)
The same could be done for components, for instance, if we could figure out
an elegant way of integrating with the Sencha/ExtJS
components we could probably gain the attention of quite a few folks.
It would probably make sense to add some optional "glue" code as well. By
which I mean some code that might translate
API conventions between Flex and the referenced JS components. For example,
a property such as 'dataProvider' is common
in Flex, but quite probably not in a lot of JS component libraries.
If we want to gain some traction in the HTML world I strongly believe we
need to make friends out there :) And what better way of
making friends than through integrating with them :)
Obviously the code example I'm giving is very simple, and the exact
implementation will require some further discussion. But I believe
the implementation of this shouldn't be too elaborate and therefore could
act as a bit of low-hanging fruit which could give the whole
AS->JS situation another turbo-boost.
Please feel free to call me a fool and tell me my idea is crap, because I
might just be talking out of my ass as usual. :)
--
regards,
Roland
--
Roland Zwaga
Senior Consultant | Stack & Heap BVBA
+32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com
http://zwaga.blogspot.com
http://www.springactionscript.org
http://www.as3commons.org
Re: [ASJS] Integration with existing JS libraries and components
Posted by Roland Zwaga <ro...@stackandheap.com>.
Hi Alex,
I think you got my drift, comments are inline again:
On 25 January 2013 21:33, Alex Harui <ah...@adobe.com> wrote:
> While both Erik and I are using Goog, I think Roland is asking why we
> aren't
> use Jquery or ExtJS UI components.
>
Exactly, and I'm certainly NOT claiming that you and Erik should NOT be
doing what you're
doing. I really meant that we should look at ALSO providing integrations
with existing libraries.
>
> In my framework, I'm not right now because I had trouble getting my head
> around them and the ones I looked at seemed to come with application
> framework infrastructure, and I want to start with the basic built-ins.
>
This is indeed why I mentioned that we might need to provide some kind of
'adapter' code
which would mimic Flex conventions a little. That way it would be easier
for a Flex developer
to start using, for example, the Sencha/ExtJS stuff.
All I want us to provide is a way to create this mapping between an AS3 API
and a JS API,
I believe the TypeScript and Randori/SharpKit approaches have already
proven that such
a way is possible. We just have to discuss the most ideal way of
implementing it for Apache
Flex.
> One difference in API between my new framework and the Flex SDK is that the
> Flex SDK tried to have one button that did everything, whereas I want the
> new framework to have many buttons, some that are bare bones and then
> fancier ones. The ones I'm working on new wrap HTML button. Then I would
> like to see ones that wrap the built in HTML5 button. And someone else is
> welcome to wrap some other JS framework's button if they want.
I believe your new framework is definitely something you need to keep
pursuing. New ways
of going about things will always find an audience. My suggestion was
purely aimed at people
who are already using a lot of existing JS libs and might simply want to
move to Apache Flex
because they want to work in a compiled/statically typed language instead
of JS directly.
While moving to Apache Flex they might get introduced to your and Erik's
frameworks and
find a use for them in their projects, but if not, the integrations with
existing JS libs will keep them
happy nonetheless :)
cheers!
Roland
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Yes, the one in 'intermediate' is. The one in 'release' is the
'intermediate' version, but run through the Closure Compiler.
EdB
On Sun, Jan 27, 2013 at 1:48 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> Is Example.js a generated cross compile?
>
> Mike
>
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>>>> Please take a look at the proof of concept (both the intermediate and
>>>> release code) before making these kinds of statements.
>>>>
>>>> I'd like to, but you admitted yourself that it has quite an initial
>>>
>>> overhead to set up. Could you perhaps set up an online demo where one can
>>> observe a running system? Or a download of the compiled application? At
>>> least that's what I did for the AMD approach:
>>
>>
>> Excellent idea. Here is the full Flash version (+ view source) and
>> both the 'intermediate' and 'release' output of the proof of concept:
>>
>> http://people.apache.org/~erikdebruin/vanillasdk/
>>
>> A bit of view source will show you why I've been saying what I've been
>> saying. The 'getting started' page for the Closure Tools, as its name
>> implies, only covers the basics. There is, however, a bit more to the
>> story, as you can see ;-)
>>
>> 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.
>>
>> EdB
>>
>>
>>
>> --
>> 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
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Is Example.js a generated cross compile?
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>> Please take a look at the proof of concept (both the intermediate and
>>> release code) before making these kinds of statements.
>>>
>>> I'd like to, but you admitted yourself that it has quite an initial
>> overhead to set up. Could you perhaps set up an online demo where one can
>> observe a running system? Or a download of the compiled application? At
>> least that's what I did for the AMD approach:
>
> Excellent idea. Here is the full Flash version (+ view source) and
> both the 'intermediate' and 'release' output of the proof of concept:
>
> http://people.apache.org/~erikdebruin/vanillasdk/
>
> A bit of view source will show you why I've been saying what I've been
> saying. The 'getting started' page for the Closure Tools, as its name
> implies, only covers the basics. There is, however, a bit more to the
> story, as you can see ;-)
>
> 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.
>
> EdB
>
>
>
> --
> 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
Re: [ASJS] Integration with existing JS libraries and components
Posted by Omar Gonzalez <om...@gmail.com>.
Really.
On Sun, Jan 27, 2013 at 10:11 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> > Take a chill pill. ;)
>
> Really? Nice!
>
> I prefer contributing over "chillin", thank you.
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> Take a chill pill. ;)
Really? Nice!
I prefer contributing over "chillin", thank you.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Omar Gonzalez <om...@gmail.com>.
Not really sure what's offensive about what I said. I was just pointing out
the PMC doesn't veto commits.
Take a chill pill. ;)
-omar
On Sunday, January 27, 2013, Erik de Bruin wrote:
> No a very constructive comment, if you don't mind me saying.
>
> But while we're on the subject: you can only include something in the
> SDK if it's actually coded and contributed to the project.
>
> Just to be clear.
>
> EdB
>
>
>
> On Sun, Jan 27, 2013 at 6:00 PM, Omar Gonzalez
> <omarg.developer@gmail.com <javascript:;>> wrote:
> > Well the PMC would not veto commits.
> >
> > It would veto the notion o including something in the SDK that wasn't
> > agreed upon via consensus.
> >
> > Just to be clear. :)
> >
> > -omar
> >
> > On Sunday, January 27, 2013, Erik de Bruin wrote:
> >
> >> > But I don't want to force a decision right now;
> >>
> >> The beauty of the Apache Way is that you are free to do whatever you
> >> feel is best for the project. As am I. So, short of the PMC voting and
> >> veto-ing each and every commit made to the code we contribute, there
> >> is no way you or anyone else can "force" a decision, now or ever.
> >>
> >> EdB
> >>
> >>
> >>
> >> --
> >> Ix Multimedia Software
> >>
> >> Jan Luykenstraat 27
> >> 3521 VB Utrecht
> >>
> >> T. 06-51952295
> >> I. www.ixsoftware.nl
> >>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
No a very constructive comment, if you don't mind me saying.
But while we're on the subject: you can only include something in the
SDK if it's actually coded and contributed to the project.
Just to be clear.
EdB
On Sun, Jan 27, 2013 at 6:00 PM, Omar Gonzalez
<om...@gmail.com> wrote:
> Well the PMC would not veto commits.
>
> It would veto the notion o including something in the SDK that wasn't
> agreed upon via consensus.
>
> Just to be clear. :)
>
> -omar
>
> On Sunday, January 27, 2013, Erik de Bruin wrote:
>
>> > But I don't want to force a decision right now;
>>
>> The beauty of the Apache Way is that you are free to do whatever you
>> feel is best for the project. As am I. So, short of the PMC voting and
>> veto-ing each and every commit made to the code we contribute, there
>> is no way you or anyone else can "force" a decision, now or ever.
>>
>> EdB
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Omar Gonzalez <om...@gmail.com>.
Well the PMC would not veto commits.
It would veto the notion o including something in the SDK that wasn't
agreed upon via consensus.
Just to be clear. :)
-omar
On Sunday, January 27, 2013, Erik de Bruin wrote:
> > But I don't want to force a decision right now;
>
> The beauty of the Apache Way is that you are free to do whatever you
> feel is best for the project. As am I. So, short of the PMC voting and
> veto-ing each and every commit made to the code we contribute, there
> is no way you or anyone else can "force" a decision, now or ever.
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> But I don't want to force a decision right now;
The beauty of the Apache Way is that you are free to do whatever you
feel is best for the project. As am I. So, short of the PMC voting and
veto-ing each and every commit made to the code we contribute, there
is no way you or anyone else can "force" a decision, now or ever.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Roland Zwaga <ro...@stackandheap.com>.
On 27 January 2013 16:14, Frank Wienberg <fr...@jangaroo.net> wrote:
> That being said, I think both Erik and I "got the ball rolling". It is not
> as if we are just talking theory here. We both have a working demo
> everybody can look at, and have both posted our arguments. Maybe we should
> just start a new thread to get this to a decision.
>
Hey Frank,
please refer to my thread about extensibility and configuration of Falcon,
it is partly meant to avoid this whole decision between your and Erik's
solution.
cheers,
Roland
Re: [ASJS] Integration with existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
That being said, I think both Erik and I "got the ball rolling". It is not
as if we are just talking theory here. We both have a working demo
everybody can look at, and have both posted our arguments. Maybe we should
just start a new thread to get this to a decision.
But I don't want to force a decision right now; if you (Mike) are still
willing to implement the AMD approach in FalconJx, we can just continue in
parallel and see where it leads to. I have continued on the Wiki page,
renamed it and started with the "compilation unit" concept, which is
probably the other big difference between Erik's approach and mine:
https://cwiki.apache.org/confluence/display/FLEX/Simulating+AS3+language+features+in+JavaScript+using+AMD+and+ES5
The still empty headlines are all for minor topics which we can tackle
later. So from my side, you could start as soon as the flu's gone and MXML
is done... ;-)
Greetings
-Frank-
Re: [ASJS] Integration with existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
Mike, no harm done. I don't mind you being sarcastic, I always find
it refreshing! :-)
Re: [ASJS] Integration with existing JS libraries and components
Posted by Michael Schmalle <ap...@teotigraphix.com>.
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
> <ap...@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
Re: [ASJS] Integration with existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Sun, Jan 27, 2013 at 2:51 PM, Michael Schmalle
<ap...@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-
Re: [ASJS] Integration with existing JS libraries and components
Posted by Michael Schmalle <ap...@teotigraphix.com>.
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" ;-)
BTW, just getting over the flu. This is on my list, believe me, so we
can stop wasting time with these huge emails back and forth and just
compare and performance test. :)
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.
Mike
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Hi,
>> We're talking AS -> JS cross compilation. So changing one file would
>> be changing one AS file. To turn that AS file into a JS file needs a
>> compilation step. The generation of 'deps.js' is part of the
>> compilation step. So, in the scenario we're discussing, the
>> regeneration is of no consequence. Also, more importantly, 'deps.js'
>> is only needed for the 'intermediate' output, not in the release
>> output. I think if we're going to be comparing anything, we should be
>> comparing 'production/release' code, not 'convinience/intermediate'
>> code, right?
>>
>>
> No, I *do* talk about the "intermediate" code, as I see it as the *primary*
> compilation result, and the production/release code as a derived artifact.
> The former is the code developers see during debugging their application.
> Nobody cares about how the production code looks like as long as it works,
> it concise and performant.
That's where we differ in our approach, apparently: I think of the JS
code as a replacement for the bytecode that feeds the Flash VM. Nobody
but compiler/framework devs debug bytecode. And in my view, nobody but
compiler/framework devs should (need to) debug Flex JS. The framework
should "just work" for application devs. Their development (debugging)
is in AS (Flash Builder), JS is just an output format, like bytecode
if they choose to deploy in the Flash Player. This makes the release
js (calling that a "derived artifact" is a bit dismissive, as it is
the primary product of my effort).
While it was fun, I think we have been at this for long enough. I have
said all I possibly can on the subject and nothing you've said
convinced me that -- other than being "different" and "not what you
would choose" -- my approach is fundamentally wrong. I think I have
backed up my position with a solid proof on concept. I will be
spending my time improving and expanding that proof of concept and, in
time, ask the community if my (and hopefully other's!) contributions
are worthy to be included in the Flex SDK. Or, if someone does manage
to convince me that another approach is better (e.g. FlexJS, or a
tangible AMD implementation), I'll put my efforts into helping get
that out of the door.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Mon, Jan 28, 2013 at 8:36 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Hi,
>
> > entire library + application". My example was that you change a single
> > file, but change it in a way that you add a dependency. Without
> > re-generating deps.js, base.js could not know in advance that the newly
>
> We're talking AS -> JS cross compilation. So changing one file would
> be changing one AS file. To turn that AS file into a JS file needs a
> compilation step. The generation of 'deps.js' is part of the
> compilation step. So, in the scenario we're discussing, the
> regeneration is of no consequence. Also, more importantly, 'deps.js'
> is only needed for the 'intermediate' output, not in the release
> output. I think if we're going to be comparing anything, we should be
> comparing 'production/release' code, not 'convinience/intermediate'
> code, right?
>
>
No, I *do* talk about the "intermediate" code, as I see it as the *primary*
compilation result, and the production/release code as a derived artifact.
The former is the code developers see during debugging their application.
Nobody cares about how the production code looks like as long as it works,
it concise and performant.
Self-cite:
> I know that for some Flex folks, development turn-around to the browser
> is not such an important issue, as they see the JS output more like an
> alternative deployment format, so they'll test in Flash or AIR and only
> deploy and QA in HTML5. I see a different scenario, where Flex is
> used to develop primarily for HTML5, which makes fast development
> turn-around to the browser a necessity.
> >> > and compile it with Jangaroo 3 and also deploy the output. What do you
> >> > think?
> >>
> >> I enabled "View Source" on the Flash output, so you can grab the AS
> >> source and put it through Jangaroo if you please. You can also pick up
> >> Alex's FlexJS source and do the same with that.Might be interesting to
> >> see what comes out and compare the various approaches when using a
> >> different compiler.
> >>
> >
> > Yes, I'll try to do that, but except from the deps.js file discussed
> above
> > I expect the difference to be rather small.
>
> So, if 'deps.js' is not needed -- like it's not needed in the
> 'release' output of my proof of concept -- there really isn't any
> practical difference between our approaches?
>
I have some experience in building an incremental-compiling IDE plugin, and
believe me, it *does* make a practical difference. Generating one output
file
for each source input file was straight-forward, but generating additional
files
per compile run was introducing complexity and made things less reliable.
Sorry, I just don't like that deps.js file, it seems so monolithic and
redundant.
> > However, I still think it is better to consolidate than to offer too much
> > to chose from (where it brings no benefit). And I'd still like to hear
> your
>
> I'd love to consolidate, and I'm reading your Wiki pages with interest
> on how to tackle some of the language inconsistencies between AS and
> JS. I just wish that we could work together on code, instead of going
> round and round on theory and relative merits of two different but
> equal approaches.
>
I'd still like to, but Mike talked me out of it ;-)
He said currently it'd be more help if I continued on the Wiki spec, so I
did that.
I do think that features like compilation unit initialization (correct
static code execution time) are orthogonal to the goog vs. RequireJS
discussion and should make it into the goog solution as well.
> > opinion on my warning that the input language for GCC is a dialect of
> > JavaScript (restrictions, extensions), not standard JavaScript.
>
> If by GCC you are referring to the compiler, [1] should answer your
> question. The Google Tools (which include, but are not limited to, the
> compiler) like to have their JavaScript in a 'pseudo-classical'
> pattern, but that doesn't mean they won't gladly handle other
> patterns, like "AMD". The JSDoc annotations are only there to help the
> GCC do an even better job, but are not required for the code to
> function as coded. What about the "input language for GCC" do you
> regard as a dialect of "vanilla JS"?
>
> EdB
>
> 1: https://developers.google.com/closure/compiler/faq#restrictions
>
>
I am talking about this passage from my initial response on Closure:
> The problem I have is that Closure is not only a runtime library plus
> a build tool, but it defines *extensions and restrictions to the
> JavaScript language itself*. And because it defines extensions
> *and* restrictions, I consider the input Closure requires *another*
> *language* than JavaScript. This makes the decision for Closure
> much more than whether we want to use synchronous or asynchronous require.
>
> Look at the long list of restrictions<https://developers.google.com/closure/compiler/docs/limitations> the
Closure Compiler imposes
> on your JavaScript code. Especially when using ADVANCED_OPTIMIZATIONS
> (without which using Closure misses much of its value), you cannot
> expect your completely strict-mode, jslinted, cross-browser-compatible,
> fully-tested JavaScript code to still work.
> There are many annotations<https://developers.google.com/closure/compiler/docs/js-for-compiler> you
need to use and
patterns<https://developers.google.com/closure/compiler/docs/api-tutorial3>
you
need
> to follow to take advantage of ADVANCED_OPTIMIZATIONS mode.
> When you use a wrong annotation (or no annotation where one was
> needed), the optimized code works incorrectly, thus the annotations
> are not "just for better optimization", but actually part of the "goog"
> language semantics, at least if you use ADVANCED_OPTIMIZATIONS.
> That sounds to me like the JavaScript code Closure wants as input is
> a custom (proprietary) version of JavaScript, and not the JavaScript we
know.
Re: Tools vs Impl - Don't mix the two was [ASJS] Integration with
existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> Peace?
There was never anything else, as far as I'm concerned. Like you say,
questioning and challenging are part of the process. Your ideas and
questions forced me to take a second (and third) look at my solution
and convinced me that I'm on the right path to achieve what I set out
to do.
Don't worry about cultural problems communicating, us Dutch folk are
plenty used to talking to foreigners :-)
Onwards and upwards!
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Tools vs Impl - Don't mix the two was [ASJS] Integration with
existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Mon, Jan 28, 2013 at 10:44 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Mike,
>
> I was aleady afraid we were boring, or worse, bothering the community.
> I apologize for my part in it. Like you I'm more of a tool maker, as
> you know well. I do get distracted when I get the impression that my
> efforts (non-trivial, let me assure you!) are questioned and
> belittled.
Erik, in our company culture, and also at university, it is part of the
game that solutions are questioned and challenged by other solutions, in
order to end up with the best solution. This does not at all imply that a
solution is invalid, simple, stupid, and wasn't any effort to build.
> So I get on the defensive and try to educate people that
> I'm not making stuff up but actually think about and research stuff
> before I start. And I get carried away as well.
No-one is saying you didn't research, or you did a bad job. Again, I
respect your solution and find it completely valid.
But no single person can know and consider everything. That's why we work
in a community. At least that's what I thought communities are for.
So please don't take my criticism so personally. What I mainly criticize
are some of Google Closure's concepts, so there is really no reason to take
that personally, unless you work for Google and invented Closure.
Peace?
-Frank-
Re: Tools vs Impl - Don't mix the two was [ASJS] Integration with
existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Mike,
I was aleady afraid we were boring, or worse, bothering the community.
I apologize for my part in it. Like you I'm more of a tool maker, as
you know well. I do get distracted when I get the impression that my
efforts (non-trivial, let me assure you!) are questioned and
belittled. So I get on the defensive and try to educate people that
I'm not making stuff up but actually think about and research stuff
before I start. And I get carried away as well.
But, I think I'm done ranting now :-)
I've just updated the build files for the Publisher to also work on
Windows, will commit those soon. Then I'm off researching another one
of my wild an inappropriate ideas for our little project :-)
EdB
On Mon, Jan 28, 2013 at 10:36 AM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
>
> Quoting Frank Wienberg <fr...@jangaroo.net>:
>
>> Hi Alain,
>>
>> for Jangaroo, I answered this question here:
>> http://markmail.org/message/bwjwc7sxfbertu7f
>> For Flex / FalconJx, it seems nobody was extremely fond of the idea to
>> have
>> to keep all the white-space and take care of generating JS code in the
>> exact line of the source AS code.
>
>
> Ok, Do I have to start another thread with exclamation marks for everybody
> to tone the .... down!
>
> I cannot believe this conversation is taking the spin it is right now, some
> of the discussions the last two days have been ridiculous and serve no
> constructive purpose to any of these "initiatives".
>
> Frank, Being that I am about the only one working on FalconJx "innards" and
> conceived a way to even HAVE alternate outputs (just look at FalconJS's rats
> nest code), I would be offended by the above statement, if I was the type
> that actually get offended, which I'm not. (I left out the "doomed"
> statement)
>
> I SAID I would get you going on the output you need for "your" vision(with
> line numbers if need be) of the javascript emitter.
>
> I have put 100's of hours into this project and will be damned if it is
> doomed by squabbling over implementations. I'm a tool maker, Don't confuse
> the tool with the JOB! You and Erik are bickering about the Job, I am
> working on the tool, please do not confuse the two.
>
> Well, I guess I started another thread cause I don't want this buried.
>
> Mike
>
>
> --
> 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
Re: Tools vs Impl - Don't mix the two was [ASJS] Integration with
existing JS libraries and components
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Frank,
My comments below only were to echo the understanding of your
experience in the AS->JS.
When I said Job it is the emitter, the emitter is the Job, meaning the
tool(FalconJx) is used to do the Job(emit javascript). When I design
frameworks, I make sure there are clear dividing lines between what
does what.
So my point was, with my work on the compiler, the emitters have NO
bearing on my development of the tool(FalconJx). I designed the
emitters so thy are completely decouple from the compiler in that they
don't talk to it, it hands them the AST not the other way around.
So, stepping off on the new foot, my excitement when we first met was
real because I know how much time you have invested in this, and I
wanted you to understand that I am listening to what you say and value
those "dead ends". I also appriciate that you can enable us to avoid
them as well.
I am going to get that AMD stuff working, but like I said, I have to
understand the js before I get it. I'm putting the MXML on hold, to do
this as I see this is more important. Plus I have other projects in my
life that are about to light on fire as well. :)
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> On Mon, Jan 28, 2013 at 10:36 AM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>>
>> Quoting Frank Wienberg <fr...@jangaroo.net>:
>>
>> Hi Alain,
>>>
>>> for Jangaroo, I answered this question here:
>>> http://markmail.org/message/**bwjwc7sxfbertu7f<http://markmail.org/message/bwjwc7sxfbertu7f>
>>> For Flex / FalconJx, it seems nobody was extremely fond of the idea to
>>> have
>>> to keep all the white-space and take care of generating JS code in the
>>> exact line of the source AS code.
>>>
>>
>> Ok, Do I have to start another thread with exclamation marks for everybody
>> to tone the .... down!
>>
>> I cannot believe this conversation is taking the spin it is right now,
>> some of the discussions the last two days have been ridiculous and serve no
>> constructive purpose to any of these "initiatives".
>>
>> Frank, Being that I am about the only one working on FalconJx "innards"
>> and conceived a way to even HAVE alternate outputs (just look at FalconJS's
>> rats nest code), I would be offended by the above statement, if I was the
>> type that actually get offended, which I'm not. (I left out the "doomed"
>> statement)
>>
>
> Sorry, Mike, I surely didn't mean to offend you. If it sounded like that, I
> apologize. You probably know I am not a native speaker, so maybe this got
> across badly.
> I just wanted to say that I brought in the Jangaroo idea to keep the
> white-space, and the common reaction was that we should (at least for the
> first iteration) go without that feature, to keep things simple and focused
> on the main problems. I accepted that, while I admit I am still a bit
> disappointed that it seems the value of this feature is not shared by
> everyone. Sorry again if I got carried away.
>
> Talking about the "doomed" statement, please don't take this out of
> context. It was my reaction on Erik's answer that sounded to me like he
> thinks debugging in Flash suffices (he put that right later on). I thought
> you share the vision that Flex must be usable for (pure) HTML5 projects to
> have a bright future. This is the reason why I support this project,
> because I believe in the HTML5 platform, but it needs better development
> support, which Flex could offer! I never said anything like Flex should
> drop the Flash or AIR target, I just said if it does not also support
> JS/HTML5 as a first class target platform, I consider it doomed (and this
> is my personal judgement).
>
>
>> I SAID I would get you going on the output you need for "your" vision(with
>> line numbers if need be) of the javascript emitter.
>>
>
> What on earth made you think I doubt that you will do so? I marvel at your
> work on FalconJx and I'm sure you are the best person to get me into it!
>
>
>>
>> I have put 100's of hours into this project and will be damned if it is
>> doomed by squabbling over implementations. I'm a tool maker, Don't confuse
>> the tool with the JOB! You and Erik are bickering about the Job, I am
>> working on the tool, please do not confuse the two.
>>
>>
> I don't get exactly what you mean by the "Job". The Goal? Before building a
> tool, you have to know what it should be used for. Erik and I seem to have
> different views on what people will use the Apache Flex tool for. I feel it
> is important to at least find out that this is so, even if you cannot
> settle the differences.
>
>
>> Well, I guess I started another thread cause I don't want this buried.
>>
>> Mike
>
>
> No, I don't want this to be buried, either. I am still quite new in this
> community, so please forgive me if I stepped on your or somebody else's
> foot. It is really hard for me, having worked on the topic AS->JS for so
> many years, to not be biased toward a solution that has formed from that
> experience. So I am quite passionate about some points and I still hope I
> can help you (plural!) to not run into some of the dead-ends I already
> visited on my journey.
>
> Best,
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: Tools vs Impl - Don't mix the two was [ASJS] Integration with
existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Mon, Jan 28, 2013 at 10:36 AM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
>
> Quoting Frank Wienberg <fr...@jangaroo.net>:
>
> Hi Alain,
>>
>> for Jangaroo, I answered this question here:
>> http://markmail.org/message/**bwjwc7sxfbertu7f<http://markmail.org/message/bwjwc7sxfbertu7f>
>> For Flex / FalconJx, it seems nobody was extremely fond of the idea to
>> have
>> to keep all the white-space and take care of generating JS code in the
>> exact line of the source AS code.
>>
>
> Ok, Do I have to start another thread with exclamation marks for everybody
> to tone the .... down!
>
> I cannot believe this conversation is taking the spin it is right now,
> some of the discussions the last two days have been ridiculous and serve no
> constructive purpose to any of these "initiatives".
>
> Frank, Being that I am about the only one working on FalconJx "innards"
> and conceived a way to even HAVE alternate outputs (just look at FalconJS's
> rats nest code), I would be offended by the above statement, if I was the
> type that actually get offended, which I'm not. (I left out the "doomed"
> statement)
>
Sorry, Mike, I surely didn't mean to offend you. If it sounded like that, I
apologize. You probably know I am not a native speaker, so maybe this got
across badly.
I just wanted to say that I brought in the Jangaroo idea to keep the
white-space, and the common reaction was that we should (at least for the
first iteration) go without that feature, to keep things simple and focused
on the main problems. I accepted that, while I admit I am still a bit
disappointed that it seems the value of this feature is not shared by
everyone. Sorry again if I got carried away.
Talking about the "doomed" statement, please don't take this out of
context. It was my reaction on Erik's answer that sounded to me like he
thinks debugging in Flash suffices (he put that right later on). I thought
you share the vision that Flex must be usable for (pure) HTML5 projects to
have a bright future. This is the reason why I support this project,
because I believe in the HTML5 platform, but it needs better development
support, which Flex could offer! I never said anything like Flex should
drop the Flash or AIR target, I just said if it does not also support
JS/HTML5 as a first class target platform, I consider it doomed (and this
is my personal judgement).
> I SAID I would get you going on the output you need for "your" vision(with
> line numbers if need be) of the javascript emitter.
>
What on earth made you think I doubt that you will do so? I marvel at your
work on FalconJx and I'm sure you are the best person to get me into it!
>
> I have put 100's of hours into this project and will be damned if it is
> doomed by squabbling over implementations. I'm a tool maker, Don't confuse
> the tool with the JOB! You and Erik are bickering about the Job, I am
> working on the tool, please do not confuse the two.
>
>
I don't get exactly what you mean by the "Job". The Goal? Before building a
tool, you have to know what it should be used for. Erik and I seem to have
different views on what people will use the Apache Flex tool for. I feel it
is important to at least find out that this is so, even if you cannot
settle the differences.
> Well, I guess I started another thread cause I don't want this buried.
>
> Mike
No, I don't want this to be buried, either. I am still quite new in this
community, so please forgive me if I stepped on your or somebody else's
foot. It is really hard for me, having worked on the topic AS->JS for so
many years, to not be biased toward a solution that has formed from that
experience. So I am quite passionate about some points and I still hope I
can help you (plural!) to not run into some of the dead-ends I already
visited on my journey.
Best,
-Frank-
Tools vs Impl - Don't mix the two was [ASJS] Integration with
existing JS libraries and components
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Hi Alain,
>
> for Jangaroo, I answered this question here:
> http://markmail.org/message/bwjwc7sxfbertu7f
> For Flex / FalconJx, it seems nobody was extremely fond of the idea to have
> to keep all the white-space and take care of generating JS code in the
> exact line of the source AS code.
Ok, Do I have to start another thread with exclamation marks for
everybody to tone the .... down!
I cannot believe this conversation is taking the spin it is right now,
some of the discussions the last two days have been ridiculous and
serve no constructive purpose to any of these "initiatives".
Frank, Being that I am about the only one working on FalconJx
"innards" and conceived a way to even HAVE alternate outputs (just
look at FalconJS's rats nest code), I would be offended by the above
statement, if I was the type that actually get offended, which I'm
not. (I left out the "doomed" statement)
I SAID I would get you going on the output you need for "your"
vision(with line numbers if need be) of the javascript emitter.
I have put 100's of hours into this project and will be damned if it
is doomed by squabbling over implementations. I'm a tool maker, Don't
confuse the tool with the JOB! You and Erik are bickering about the
Job, I am working on the tool, please do not confuse the two.
Well, I guess I started another thread cause I don't want this buried.
Mike
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [ASJS] Integration with existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
Hi Alain,
for Jangaroo, I answered this question here:
http://markmail.org/message/bwjwc7sxfbertu7f
For Flex / FalconJx, it seems nobody was extremely fond of the idea to have
to keep all the white-space and take care of generating JS code in the
exact line of the source AS code. So we have to find another solution for
the problem.
One could be to use JavaScript source
maps<http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/>
to
provide a link from the generated code back to the original code.
Chrome's developer tools can already read source maps and display the
original source code in the debugger. When you set a breakpoint there, the
debugger knows where to break in the JS code and stops accordingly. It's
like magic! Firefox and IE are going to implement this feature, too, but it
is not there yet.
I implemented experimental support for source maps in Jangaroo, you can see
a screenshot of how it would feel here:
http://twitter.yfrog.com/z/odaebmp
Google Closure Compiler and Uglify2 can both generate source maps, but only
from the generated JavaScript to the minified JavaScript. We would have to
take care to create a source map from AS source code to our generated code.
Closure provides a Java API, which I successfully used for the Jangaroo
source maps prototype.
We could even chain both source maps into a direct mapping from AS code to
minified JavaScript. Note that minified JavaScript will still be harder to
debug, as local variables and other identifiers have been renamed,
functions may have been inlined and so on.
Greetings
-Frank-
On Mon, Jan 28, 2013 at 9:20 AM, Alain Ekambi <ja...@gmail.com>wrote:
> One thing I was thinking about. How would debugging work ? Let's say I set
> a break point in my as3 code how will debugging the js output look like
>
> Greets
>
> Alain
> On Jan 28, 2013 8:37 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> > Hi,
> >
> > > entire library + application". My example was that you change a single
> > > file, but change it in a way that you add a dependency. Without
> > > re-generating deps.js, base.js could not know in advance that the newly
> >
> > We're talking AS -> JS cross compilation. So changing one file would
> > be changing one AS file. To turn that AS file into a JS file needs a
> > compilation step. The generation of 'deps.js' is part of the
> > compilation step. So, in the scenario we're discussing, the
> > regeneration is of no consequence. Also, more importantly, 'deps.js'
> > is only needed for the 'intermediate' output, not in the release
> > output. I think if we're going to be comparing anything, we should be
> > comparing 'production/release' code, not 'convinience/intermediate'
> > code, right?
> >
> > >> > and compile it with Jangaroo 3 and also deploy the output. What do
> you
> > >> > think?
> > >>
> > >> I enabled "View Source" on the Flash output, so you can grab the AS
> > >> source and put it through Jangaroo if you please. You can also pick up
> > >> Alex's FlexJS source and do the same with that.Might be interesting to
> > >> see what comes out and compare the various approaches when using a
> > >> different compiler.
> > >>
> > >
> > > Yes, I'll try to do that, but except from the deps.js file discussed
> > above
> > > I expect the difference to be rather small.
> >
> > So, if 'deps.js' is not needed -- like it's not needed in the
> > 'release' output of my proof of concept -- there really isn't any
> > practical difference between our approaches?
> >
> > > However, I still think it is better to consolidate than to offer too
> much
> > > to chose from (where it brings no benefit). And I'd still like to hear
> > your
> >
> > I'd love to consolidate, and I'm reading your Wiki pages with interest
> > on how to tackle some of the language inconsistencies between AS and
> > JS. I just wish that we could work together on code, instead of going
> > round and round on theory and relative merits of two different but
> > equal approaches.
> >
> > > opinion on my warning that the input language for GCC is a dialect of
> > > JavaScript (restrictions, extensions), not standard JavaScript.
> >
> > If by GCC you are referring to the compiler, [1] should answer your
> > question. The Google Tools (which include, but are not limited to, the
> > compiler) like to have their JavaScript in a 'pseudo-classical'
> > pattern, but that doesn't mean they won't gladly handle other
> > patterns, like "AMD". The JSDoc annotations are only there to help the
> > GCC do an even better job, but are not required for the code to
> > function as coded. What about the "input language for GCC" do you
> > regard as a dialect of "vanilla JS"?
> >
> > EdB
> >
> > 1: https://developers.google.com/closure/compiler/faq#restrictions
> >
> >
> >
> > --
> > Ix Multimedia Software
> >
> > Jan Luykenstraat 27
> > 3521 VB Utrecht
> >
> > T. 06-51952295
> > I. www.ixsoftware.nl
> >
>
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I think this a relevant and new discussion, so I moved it to a new
thread: "[ASJS] debugging output JS?"
EdB
On Mon, Jan 28, 2013 at 10:33 AM, Roland Zwaga <ro...@stackandheap.com> wrote:
> On 28 January 2013 10:29, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>> > This won't work for us (Jangaroo/Ext AS users). In our development
>> > workflow, JS/HTML5 is the one and only target platform. And I think this
>> is
>> > the future for Flex. If Flex will not support the full development
>> > lifecycle for HTML5 projects, it is of no interest for us and I guess for
>> > many others, and I'd even dare say it is doomed.
>>
>> And please: what might doom Flex is people talking about what will
>> doom Flex. All that does is feed the trolls that make a living of
>> writing negative stories about tech subjects. Like with the stock
>> markets, often all it takes is one rumor going viral...
>>
>
> I don't believe that is what Frank meant, what he meant was just debugging
> in AS
> is not enough and that the JS output ought to be viewed as bytecode and
> should
> "just work". While that goal might be admirable, I tend to agree with Frank
> that
> being able to dip into the JS parts is probably essential for the
> situations in which
> the JS doesn't "just work".
>
> Or did I also misunderstand?
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Roland Zwaga <ro...@stackandheap.com>.
On 28 January 2013 10:29, Erik de Bruin <er...@ixsoftware.nl> wrote:
> > This won't work for us (Jangaroo/Ext AS users). In our development
> > workflow, JS/HTML5 is the one and only target platform. And I think this
> is
> > the future for Flex. If Flex will not support the full development
> > lifecycle for HTML5 projects, it is of no interest for us and I guess for
> > many others, and I'd even dare say it is doomed.
>
> And please: what might doom Flex is people talking about what will
> doom Flex. All that does is feed the trolls that make a living of
> writing negative stories about tech subjects. Like with the stock
> markets, often all it takes is one rumor going viral...
>
I don't believe that is what Frank meant, what he meant was just debugging
in AS
is not enough and that the JS output ought to be viewed as bytecode and
should
"just work". While that goal might be admirable, I tend to agree with Frank
that
being able to dip into the JS parts is probably essential for the
situations in which
the JS doesn't "just work".
Or did I also misunderstand?
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> This won't work for us (Jangaroo/Ext AS users). In our development
> workflow, JS/HTML5 is the one and only target platform. And I think this is
> the future for Flex. If Flex will not support the full development
> lifecycle for HTML5 projects, it is of no interest for us and I guess for
> many others, and I'd even dare say it is doomed.
I'm not talking about what Flex in general supports or does not
support. That's up to the community and depends entirely on the
contributions you, me and others make to the project.
All I said is that in my view (the only one I have ;-)), JS is 'just'
another output format for projects built with the Flex SDK. The Flash
Player and AIR aren't going anywhere soon, dismissing them as a
delivery platforms for the Flex SDK is nonsense. FYI: the main
inspiration for my point of view about generated JS came from here:
http://blogs.adobe.com/bparadie/tag/actionscript/
And please: what might doom Flex is people talking about what will
doom Flex. All that does is feed the trolls that make a living of
writing negative stories about tech subjects. Like with the stock
markets, often all it takes is one rumor going viral...
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Mon, Jan 28, 2013 at 10:04 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Alain,
>
> In my view all development, including debugging, is done in AS. The JS
> output, like bytecode, should "just work".
>
> EdB
>
>
This won't work for us (Jangaroo/Ext AS users). In our development
workflow, JS/HTML5 is the one and only target platform. And I think this is
the future for Flex. If Flex will not support the full development
lifecycle for HTML5 projects, it is of no interest for us and I guess for
many others, and I'd even dare say it is doomed.
-Frank-
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Alain,
In my view all development, including debugging, is done in AS. The JS
output, like bytecode, should "just work".
EdB
On Mon, Jan 28, 2013 at 9:20 AM, Alain Ekambi <ja...@gmail.com> wrote:
> One thing I was thinking about. How would debugging work ? Let's say I set
> a break point in my as3 code how will debugging the js output look like
>
> Greets
>
> Alain
> On Jan 28, 2013 8:37 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> Hi,
>>
>> > entire library + application". My example was that you change a single
>> > file, but change it in a way that you add a dependency. Without
>> > re-generating deps.js, base.js could not know in advance that the newly
>>
>> We're talking AS -> JS cross compilation. So changing one file would
>> be changing one AS file. To turn that AS file into a JS file needs a
>> compilation step. The generation of 'deps.js' is part of the
>> compilation step. So, in the scenario we're discussing, the
>> regeneration is of no consequence. Also, more importantly, 'deps.js'
>> is only needed for the 'intermediate' output, not in the release
>> output. I think if we're going to be comparing anything, we should be
>> comparing 'production/release' code, not 'convinience/intermediate'
>> code, right?
>>
>> >> > and compile it with Jangaroo 3 and also deploy the output. What do you
>> >> > think?
>> >>
>> >> I enabled "View Source" on the Flash output, so you can grab the AS
>> >> source and put it through Jangaroo if you please. You can also pick up
>> >> Alex's FlexJS source and do the same with that.Might be interesting to
>> >> see what comes out and compare the various approaches when using a
>> >> different compiler.
>> >>
>> >
>> > Yes, I'll try to do that, but except from the deps.js file discussed
>> above
>> > I expect the difference to be rather small.
>>
>> So, if 'deps.js' is not needed -- like it's not needed in the
>> 'release' output of my proof of concept -- there really isn't any
>> practical difference between our approaches?
>>
>> > However, I still think it is better to consolidate than to offer too much
>> > to chose from (where it brings no benefit). And I'd still like to hear
>> your
>>
>> I'd love to consolidate, and I'm reading your Wiki pages with interest
>> on how to tackle some of the language inconsistencies between AS and
>> JS. I just wish that we could work together on code, instead of going
>> round and round on theory and relative merits of two different but
>> equal approaches.
>>
>> > opinion on my warning that the input language for GCC is a dialect of
>> > JavaScript (restrictions, extensions), not standard JavaScript.
>>
>> If by GCC you are referring to the compiler, [1] should answer your
>> question. The Google Tools (which include, but are not limited to, the
>> compiler) like to have their JavaScript in a 'pseudo-classical'
>> pattern, but that doesn't mean they won't gladly handle other
>> patterns, like "AMD". The JSDoc annotations are only there to help the
>> GCC do an even better job, but are not required for the code to
>> function as coded. What about the "input language for GCC" do you
>> regard as a dialect of "vanilla JS"?
>>
>> EdB
>>
>> 1: https://developers.google.com/closure/compiler/faq#restrictions
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Alain Ekambi <ja...@gmail.com>.
One thing I was thinking about. How would debugging work ? Let's say I set
a break point in my as3 code how will debugging the js output look like
Greets
Alain
On Jan 28, 2013 8:37 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Hi,
>
> > entire library + application". My example was that you change a single
> > file, but change it in a way that you add a dependency. Without
> > re-generating deps.js, base.js could not know in advance that the newly
>
> We're talking AS -> JS cross compilation. So changing one file would
> be changing one AS file. To turn that AS file into a JS file needs a
> compilation step. The generation of 'deps.js' is part of the
> compilation step. So, in the scenario we're discussing, the
> regeneration is of no consequence. Also, more importantly, 'deps.js'
> is only needed for the 'intermediate' output, not in the release
> output. I think if we're going to be comparing anything, we should be
> comparing 'production/release' code, not 'convinience/intermediate'
> code, right?
>
> >> > and compile it with Jangaroo 3 and also deploy the output. What do you
> >> > think?
> >>
> >> I enabled "View Source" on the Flash output, so you can grab the AS
> >> source and put it through Jangaroo if you please. You can also pick up
> >> Alex's FlexJS source and do the same with that.Might be interesting to
> >> see what comes out and compare the various approaches when using a
> >> different compiler.
> >>
> >
> > Yes, I'll try to do that, but except from the deps.js file discussed
> above
> > I expect the difference to be rather small.
>
> So, if 'deps.js' is not needed -- like it's not needed in the
> 'release' output of my proof of concept -- there really isn't any
> practical difference between our approaches?
>
> > However, I still think it is better to consolidate than to offer too much
> > to chose from (where it brings no benefit). And I'd still like to hear
> your
>
> I'd love to consolidate, and I'm reading your Wiki pages with interest
> on how to tackle some of the language inconsistencies between AS and
> JS. I just wish that we could work together on code, instead of going
> round and round on theory and relative merits of two different but
> equal approaches.
>
> > opinion on my warning that the input language for GCC is a dialect of
> > JavaScript (restrictions, extensions), not standard JavaScript.
>
> If by GCC you are referring to the compiler, [1] should answer your
> question. The Google Tools (which include, but are not limited to, the
> compiler) like to have their JavaScript in a 'pseudo-classical'
> pattern, but that doesn't mean they won't gladly handle other
> patterns, like "AMD". The JSDoc annotations are only there to help the
> GCC do an even better job, but are not required for the code to
> function as coded. What about the "input language for GCC" do you
> regard as a dialect of "vanilla JS"?
>
> EdB
>
> 1: https://developers.google.com/closure/compiler/faq#restrictions
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Hi,
> entire library + application". My example was that you change a single
> file, but change it in a way that you add a dependency. Without
> re-generating deps.js, base.js could not know in advance that the newly
We're talking AS -> JS cross compilation. So changing one file would
be changing one AS file. To turn that AS file into a JS file needs a
compilation step. The generation of 'deps.js' is part of the
compilation step. So, in the scenario we're discussing, the
regeneration is of no consequence. Also, more importantly, 'deps.js'
is only needed for the 'intermediate' output, not in the release
output. I think if we're going to be comparing anything, we should be
comparing 'production/release' code, not 'convinience/intermediate'
code, right?
>> > and compile it with Jangaroo 3 and also deploy the output. What do you
>> > think?
>>
>> I enabled "View Source" on the Flash output, so you can grab the AS
>> source and put it through Jangaroo if you please. You can also pick up
>> Alex's FlexJS source and do the same with that.Might be interesting to
>> see what comes out and compare the various approaches when using a
>> different compiler.
>>
>
> Yes, I'll try to do that, but except from the deps.js file discussed above
> I expect the difference to be rather small.
So, if 'deps.js' is not needed -- like it's not needed in the
'release' output of my proof of concept -- there really isn't any
practical difference between our approaches?
> However, I still think it is better to consolidate than to offer too much
> to chose from (where it brings no benefit). And I'd still like to hear your
I'd love to consolidate, and I'm reading your Wiki pages with interest
on how to tackle some of the language inconsistencies between AS and
JS. I just wish that we could work together on code, instead of going
round and round on theory and relative merits of two different but
equal approaches.
> opinion on my warning that the input language for GCC is a dialect of
> JavaScript (restrictions, extensions), not standard JavaScript.
If by GCC you are referring to the compiler, [1] should answer your
question. The Google Tools (which include, but are not limited to, the
compiler) like to have their JavaScript in a 'pseudo-classical'
pattern, but that doesn't mean they won't gladly handle other
patterns, like "AMD". The JSDoc annotations are only there to help the
GCC do an even better job, but are not required for the code to
function as coded. What about the "input language for GCC" do you
regard as a dialect of "vanilla JS"?
EdB
1: https://developers.google.com/closure/compiler/faq#restrictions
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Sun, Jan 27, 2013 at 5:52 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> > I think I can now pinpoint the difference to RequireJS: It is in the
> > existence of deps.js.
> > deps.js says it's generated, and seems to be the extracted dependencies
> of
> > all the other JS files, right? Aha, so this is how the necessary scripts
> > get loaded in advance. And this is where you need the build tool: To
> > extract the dependencies and generate this additional file deps.js.
>
> No, the deps.js is just a list of ALL the require statements in the
> entire library + application (indeed generate during the publish
> process. However, ONLY the files listed that are ACTUALLY USED are
> loaded dynamically by the code in 'base.js'. If you look in either
> Chrome or FF you can see which script files are actually loaded and
> compare that list agains the 'deps.js' list. You'll see that the only
> file hard-coded into the HTML is 'base.js', which is the equivalent of
> 'require.js' in your approach. All the other script files are loaded
> dynamically, in order, based on the dependencies as given in their
> contents, much like with Require.js.
>
> > With the AMD approach, you can re-generate exactly one file and reload in
> > the browser, and everything will work.
>
> Same with the 'goog' way.
> > One more thing, something I didn't find out is how deps.js gets loaded.
> It
> > has to be triggered by base.js somehow. Can you please explain?
>
> It's a kind of magic :-) As I explain above, 'base.js' uses it,
> together with the 'provide' and 'require' statements to figure out
> which other project files to load. Let me press that point, since it
> seems to be pivotal to the discussion: ONLY the files that are
> ACTUALLY needed to run the application are loaded into the browser.
> NOT all the files in 'deps.js' and certainly not all the files in the
> Closure Library.
>
>
To get one misunderstanding out of the way, I never claimed base.js would
load more scripts than required.
I just wonder all the time how base.js can know *in advance* which scripts
to load. And deps.js seems to be the answer to that question.
Believe me, I'm just trying to understand how it works and where it is
substantially different from RequireJS.
So deps.js is not only the list of all require statements starting at the
"main" class, but as you say a "list of ALL the require statements in the
entire library + application". My example was that you change a single
file, but change it in a way that you add a dependency. Without
re-generating deps.js, base.js could not know in advance that the newly
dependent module is needed, so just generating the class' own output file
would result in a non-working state. And (re-)generating deps.js is exactly
the pre-processing step AMD so elegantly avoids from the start.
> > 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?
>
> I enabled "View Source" on the Flash output, so you can grab the AS
> source and put it through Jangaroo if you please. You can also pick up
> Alex's FlexJS source and do the same with that.Might be interesting to
> see what comes out and compare the various approaches when using a
> different compiler.
>
Yes, I'll try to do that, but except from the deps.js file discussed above
I expect the difference to be rather small.
> I think you're not going to convince me to throw away all the work I
> did so far (and I strongly believe is at least as valid for our
> purpose as what you are suggesting) and start the whole process again
> based on your approach, only to do away with one step in the build
> process of the intermediate output (the 'deps.js' you object to plays
> no role in generating the 'release' code). I'll continue development
> of my proof of concept and I hope to find other contributors willing
> to help out.
>
Nobody asks you to throw away your work. We are discussing which library /
tool better supports the JS target of Apache Flex. From a code-generation
point of view, our approaches are fairly similar, and there are suggestions
(see Roland's thread) that it should be easy to switch between such similar
code output patterns. So we'll probably have both of them.
However, I still think it is better to consolidate than to offer too much
to chose from (where it brings no benefit). And I'd still like to hear your
opinion on my warning that the input language for GCC is a dialect of
JavaScript (restrictions, extensions), not standard JavaScript.
-Frank-
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> I think I can now pinpoint the difference to RequireJS: It is in the
> existence of deps.js.
> deps.js says it's generated, and seems to be the extracted dependencies of
> all the other JS files, right? Aha, so this is how the necessary scripts
> get loaded in advance. And this is where you need the build tool: To
> extract the dependencies and generate this additional file deps.js.
No, the deps.js is just a list of ALL the require statements in the
entire library + application (indeed generate during the publish
process. However, ONLY the files listed that are ACTUALLY USED are
loaded dynamically by the code in 'base.js'. If you look in either
Chrome or FF you can see which script files are actually loaded and
compare that list agains the 'deps.js' list. You'll see that the only
file hard-coded into the HTML is 'base.js', which is the equivalent of
'require.js' in your approach. All the other script files are loaded
dynamically, in order, based on the dependencies as given in their
contents, much like with Require.js.
> With the AMD approach, you can re-generate exactly one file and reload in
> the browser, and everything will work.
Same with the 'goog' way.
> One more thing, something I didn't find out is how deps.js gets loaded. It
> has to be triggered by base.js somehow. Can you please explain?
It's a kind of magic :-) As I explain above, 'base.js' uses it,
together with the 'provide' and 'require' statements to figure out
which other project files to load. Let me press that point, since it
seems to be pivotal to the discussion: ONLY the files that are
ACTUALLY needed to run the application are loaded into the browser.
NOT all the files in 'deps.js' and certainly not all the files in the
Closure Library.
> 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?
I enabled "View Source" on the Flash output, so you can grab the AS
source and put it through Jangaroo if you please. You can also pick up
Alex's FlexJS source and do the same with that.Might be interesting to
see what comes out and compare the various approaches when using a
different compiler.
I think you're not going to convince me to throw away all the work I
did so far (and I strongly believe is at least as valid for our
purpose as what you are suggesting) and start the whole process again
based on your approach, only to do away with one step in the build
process of the intermediate output (the 'deps.js' you object to plays
no role in generating the 'release' code). I'll continue development
of my proof of concept and I hope to find other contributors willing
to help out.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Sun, Jan 27, 2013 at 1:03 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> >> Please take a look at the proof of concept (both the intermediate and
> >> release code) before making these kinds of statements.
> >>
> >> I'd like to, but you admitted yourself that it has quite an initial
> > overhead to set up. Could you perhaps set up an online demo where one can
> > observe a running system? Or a download of the compiled application? At
> > least that's what I did for the AMD approach:
>
> Excellent idea. Here is the full Flash version (+ view source) and
> both the 'intermediate' and 'release' output of the proof of concept:
>
> http://people.apache.org/~erikdebruin/vanillasdk/
>
> A bit of view source will show you why I've been saying what I've been
> saying. The 'getting started' page for the Closure Tools, as its name
> implies, only covers the basics. There is, however, a bit more to the
> story, as you can see ;-)
>
Thank you Erik, for providing a running version so quickly. That really
helps!
I think I can now pinpoint the difference to RequireJS: It is in the
existence of deps.js.
deps.js says it's generated, and seems to be the extracted dependencies of
all the other JS files, right? Aha, so this is how the necessary scripts
get loaded in advance. And this is where you need the build tool: To
extract the dependencies and generate this additional file deps.js.
RequireJS has a similar mechanism, called "shims". You can "shim" any
JavaScript library that was not made for AMD by specifying dependencies in
an additional configuration file. See
http://requirejs.org/docs/api.html#config-shim But for modules written in
the AMD style, a "deps" file is not necessary.
What I criticize is that dependencies have to be specified twice. Granted,
the second occurrence is generated by a tool, but that means you have to
use the tool. It just makes things more complicated and more dependent. Why
should this be necessary, when there is another solution that works without
this redundancy and build step?
Especially in development mode, when I change a single AS source file, it
would be great if it would suffice to re-generate only the corresponding JS
file. But when you add a dependency to your AS code, deps.js would have to
re-generated, too, and as it looks quite monolithic, this operation might
be expensive.
With the AMD approach, you can re-generate exactly one file and reload in
the browser, and everything will work.
I know that for some Flex folks, development turn-around to the browser is
not such an important issue, as they see the JS output more like an
alternative deployment format, so they'll test in Flash or AIR and only
deploy and QA in HTML5. I see a different scenario, where Flex is used to
develop primarily for HTML5, which makes fast development turn-around to
the browser a necessity.
One more thing, something I didn't find out is how deps.js gets loaded. It
has to be triggered by base.js somehow. Can you please explain?
>
> 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-
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>> Please take a look at the proof of concept (both the intermediate and
>> release code) before making these kinds of statements.
>>
>> I'd like to, but you admitted yourself that it has quite an initial
> overhead to set up. Could you perhaps set up an online demo where one can
> observe a running system? Or a download of the compiled application? At
> least that's what I did for the AMD approach:
Excellent idea. Here is the full Flash version (+ view source) and
both the 'intermediate' and 'release' output of the proof of concept:
http://people.apache.org/~erikdebruin/vanillasdk/
A bit of view source will show you why I've been saying what I've been
saying. The 'getting started' page for the Closure Tools, as its name
implies, only covers the basics. There is, however, a bit more to the
story, as you can see ;-)
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.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Omar Gonzalez <om...@gmail.com>.
These are a lot of the reasons why I chose RequireJS over Google Closure
for my JavaScript work.
Just saying.
-omar
On Sunday, January 27, 2013, Frank Wienberg wrote:
> On Sat, Jan 26, 2013 at 7:55 AM, Erik de Bruin <erik@ixsoftware.nl<javascript:;>>
> wrote:
>
> > > code and vice versa. I still think that RequireJS is the better choice,
> > as
> > > Closure implements *synchronous* require() which does not work
> > dynamically
> > > in the browser, and the Closure Library comes with many many more
> > features,
> >
> > I really wish you would stop saying this. It is simply not true.
> > Please look at the 'js-intermediate' output to see how 'base.js'
> > dynamically loads only those files from the 'goog' library it actually
> > uses, in the order needed to allow proper instantiation. How is that
> > different from RequireJS?
> >
>
> No, I won't stop saying this. (I'm a bit stubborn, you know.) Maybe I'll
> stop saying it like above, as this is a very short and simplified form,
> which I just chose because I thought we had this discussion before. But I
> am willing to pick it up again, and I hope you are, too.
>
> That your prototype uses goog.require() and works in the browser is fine,
> but it is not a proof that this is the best approach.
>
> I am arguing from a conceptual viewpoint: how can a module loader that uses
> *synchronous* require load scripts dynamically, as needed, in the browser,
> where everything can only be loaded asynchronously? When looking at this
> Google Closure "Getting
> Started"<https://developers.google.com/closure/library/docs/gettingstarted
> >,
> I understand that
> goog.require("Foo");
> var foo = new Foo();
> can only work if you split it into two scripts (one doing the require, one
> using it) or, in your build process, apply the GoogleBuilder tool that
> analyzes the code so that the required script is loaded in advance. The
> only solution I can think of to make the above example work *as-is* in the
> browser would be to do it like Sencha Ext 4 and, in "development mode",
> load code via a *synchronous* XHR and then using eval() on the response
> text, both of which sounds evil to me.
>
> So to make JavaScript code written the "goog" way actually work in the
> browser, you need the GoogleBuilder / Google Closure Compiler tool, right?
>
> RequireJS is different in that it respects the browser's nature of loading
> things asynchronously. Thus, it is built into the concept of *Asynchronous*
> Module Definitions (AMD) that script loading needs a callback:
> require(["scriptA", "scriptB"], function() { ... }); Also see
> http://requirejs.org/docs/whyamd.html
>
>
> > Also, how is 'many, many more features' a bad thing?
> >
>
> That statement was too general, sorry. I wouldn't have a problem with
> Closure having many (optional) features. The problem I have is that Closure
> is not only a runtime library plus a build tool, but it defines *extensions
> and restrictions to the JavaScript language itself*. And because it defines
> extensions *and* restrictions, I consider the input Closure requires
> *another language* than JavaScript. This makes the decision for Closure
> much more than whether we want to use synchronous or asynchronous require.
>
> Look at the long list of
> restrictions<
> https://developers.google.com/closure/compiler/docs/limitations>
> the
> Closure Compiler imposes on your JavaScript code. Especially when using
> ADVANCED_OPTIMIZATIONS (without which using Closure misses much of its
> value), you cannot expect your completely strict-mode, jslinted,
> cross-browser-compatible, fully-tested JavaScript code to still work.
> There are many annotations<
> https://developers.google.com/closure/compiler/docs/js-for-compiler>
> you
> need to use and
> patterns<https://developers.google.com/closure/compiler/docs/api-tutorial3
> >
> you
> need to follow to take advantage of ADVANCED_OPTIMIZATIONS mode. When you
> use a wrong annotation (or no annotation where one was needed), the
> optimized code works incorrectly, thus the annotations are not "just for
> better optimization", but actually part of the "goog" language semantics,
> at least if you use ADVANCED_OPTIMIZATIONS.
> That sounds to me like the JavaScript code Closure wants as input is a
> custom (proprietary) version of JavaScript, and not the JavaScript we know.
>
> In contrast, RequireJS introduces its Domain-Specific Language for modules
> and module dependencies purely based on original JavaScript language
> constructs, namely functions. You need no annotations and no build tool to
> make the JavaScript code run in the browser as-is, only a library written
> in JavaScript, too (require.js or almond.js or any of the many other
> implementations). Only to optimize all module scripts into one or several
> larger chunks, you need to use the provided build tool (r.js). Even this
> build tool does not do much magic, but is only needed to allow the
> syntactic sugar to not repeat the module name in the module JS code (it
> deduces the module name from the file name when concatenating scripts).
> Since we generate the JS code and manage dependencies ourselves, we could
> easily add the module name and concatenate the needed scripts ourselves.
> Another advantage of AMD is that it does not rely on global variables, but
> hands over module references into the callback function's parameters:
> require(["com/acme/very/long/Foo"], function(Foo) { /* access
> com.acme.very.long.Foo as Foo */ }); These are more efficient to access
> without any optimization, and can easily be further optimized (e.g.
> abbreviate a long class name) by any JavaScript minifier that is capable of
> shortening local variables.
>
> Goggle Closure library + compiler work on many different conceptual levels,
> so you don't "buy" a module management system, but a complete JavaScript
> (and beyond) ecosystem. It's a matter of choice, but I am more the
> standards / modular / cherry-picking type and don't like to rely on an
> all-in-one solution by a specific vendor, especially in the JavaScript
> world where there are always many alternative libraries / frameworks to
> chose from. (So there we also have a connection to the original topic of
> this thread ;-)!)
>
>
> >
> > Please take a look at the proof of concept (both the intermediate and
> > release code) before making these kinds of statements.
> >
> > I'd like to, but you admitted yourself that it has quite an initial
> overhead to set up. Could you perhaps set up an online demo where one can
> observe a running system? Or a download of the compiled application? At
> least that's what I did for the AMD approach:
>
> * pure JavaScript prototype:
> http://fwienber.github.com/as-js-runtime-prototype/index.html
> * Open Flash Chart demo, compiled with Jangaroo 3:
> http://jangaron.net/ofc5/data-files/joo.html#joo.debug
>
> Greetings
> -Frank-
>
Re: [ASJS] Integration with existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Sat, Jan 26, 2013 at 7:55 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> > code and vice versa. I still think that RequireJS is the better choice,
> as
> > Closure implements *synchronous* require() which does not work
> dynamically
> > in the browser, and the Closure Library comes with many many more
> features,
>
> I really wish you would stop saying this. It is simply not true.
> Please look at the 'js-intermediate' output to see how 'base.js'
> dynamically loads only those files from the 'goog' library it actually
> uses, in the order needed to allow proper instantiation. How is that
> different from RequireJS?
>
No, I won't stop saying this. (I'm a bit stubborn, you know.) Maybe I'll
stop saying it like above, as this is a very short and simplified form,
which I just chose because I thought we had this discussion before. But I
am willing to pick it up again, and I hope you are, too.
That your prototype uses goog.require() and works in the browser is fine,
but it is not a proof that this is the best approach.
I am arguing from a conceptual viewpoint: how can a module loader that uses
*synchronous* require load scripts dynamically, as needed, in the browser,
where everything can only be loaded asynchronously? When looking at this
Google Closure "Getting
Started"<https://developers.google.com/closure/library/docs/gettingstarted>,
I understand that
goog.require("Foo");
var foo = new Foo();
can only work if you split it into two scripts (one doing the require, one
using it) or, in your build process, apply the GoogleBuilder tool that
analyzes the code so that the required script is loaded in advance. The
only solution I can think of to make the above example work *as-is* in the
browser would be to do it like Sencha Ext 4 and, in "development mode",
load code via a *synchronous* XHR and then using eval() on the response
text, both of which sounds evil to me.
So to make JavaScript code written the "goog" way actually work in the
browser, you need the GoogleBuilder / Google Closure Compiler tool, right?
RequireJS is different in that it respects the browser's nature of loading
things asynchronously. Thus, it is built into the concept of *Asynchronous*
Module Definitions (AMD) that script loading needs a callback:
require(["scriptA", "scriptB"], function() { ... }); Also see
http://requirejs.org/docs/whyamd.html
> Also, how is 'many, many more features' a bad thing?
>
That statement was too general, sorry. I wouldn't have a problem with
Closure having many (optional) features. The problem I have is that Closure
is not only a runtime library plus a build tool, but it defines *extensions
and restrictions to the JavaScript language itself*. And because it defines
extensions *and* restrictions, I consider the input Closure requires
*another language* than JavaScript. This makes the decision for Closure
much more than whether we want to use synchronous or asynchronous require.
Look at the long list of
restrictions<https://developers.google.com/closure/compiler/docs/limitations>
the
Closure Compiler imposes on your JavaScript code. Especially when using
ADVANCED_OPTIMIZATIONS (without which using Closure misses much of its
value), you cannot expect your completely strict-mode, jslinted,
cross-browser-compatible, fully-tested JavaScript code to still work.
There are many annotations<https://developers.google.com/closure/compiler/docs/js-for-compiler>
you
need to use and
patterns<https://developers.google.com/closure/compiler/docs/api-tutorial3>
you
need to follow to take advantage of ADVANCED_OPTIMIZATIONS mode. When you
use a wrong annotation (or no annotation where one was needed), the
optimized code works incorrectly, thus the annotations are not "just for
better optimization", but actually part of the "goog" language semantics,
at least if you use ADVANCED_OPTIMIZATIONS.
That sounds to me like the JavaScript code Closure wants as input is a
custom (proprietary) version of JavaScript, and not the JavaScript we know.
In contrast, RequireJS introduces its Domain-Specific Language for modules
and module dependencies purely based on original JavaScript language
constructs, namely functions. You need no annotations and no build tool to
make the JavaScript code run in the browser as-is, only a library written
in JavaScript, too (require.js or almond.js or any of the many other
implementations). Only to optimize all module scripts into one or several
larger chunks, you need to use the provided build tool (r.js). Even this
build tool does not do much magic, but is only needed to allow the
syntactic sugar to not repeat the module name in the module JS code (it
deduces the module name from the file name when concatenating scripts).
Since we generate the JS code and manage dependencies ourselves, we could
easily add the module name and concatenate the needed scripts ourselves.
Another advantage of AMD is that it does not rely on global variables, but
hands over module references into the callback function's parameters:
require(["com/acme/very/long/Foo"], function(Foo) { /* access
com.acme.very.long.Foo as Foo */ }); These are more efficient to access
without any optimization, and can easily be further optimized (e.g.
abbreviate a long class name) by any JavaScript minifier that is capable of
shortening local variables.
Goggle Closure library + compiler work on many different conceptual levels,
so you don't "buy" a module management system, but a complete JavaScript
(and beyond) ecosystem. It's a matter of choice, but I am more the
standards / modular / cherry-picking type and don't like to rely on an
all-in-one solution by a specific vendor, especially in the JavaScript
world where there are always many alternative libraries / frameworks to
chose from. (So there we also have a connection to the original topic of
this thread ;-)!)
>
> Please take a look at the proof of concept (both the intermediate and
> release code) before making these kinds of statements.
>
> I'd like to, but you admitted yourself that it has quite an initial
overhead to set up. Could you perhaps set up an online demo where one can
observe a running system? Or a download of the compiled application? At
least that's what I did for the AMD approach:
* pure JavaScript prototype:
http://fwienber.github.com/as-js-runtime-prototype/index.html
* Open Flash Chart demo, compiled with Jangaroo 3:
http://jangaron.net/ofc5/data-files/joo.html#joo.debug
Greetings
-Frank-
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> code and vice versa. I still think that RequireJS is the better choice, as
> Closure implements *synchronous* require() which does not work dynamically
> in the browser, and the Closure Library comes with many many more features,
I really wish you would stop saying this. It is simply not true.
Please look at the 'js-intermediate' output to see how 'base.js'
dynamically loads only those files from the 'goog' library it actually
uses, in the order needed to allow proper instantiation. How is that
different from RequireJS?
Also, how is 'many, many more features' a bad thing?
Please take a look at the proof of concept (both the intermediate and
release code) before making these kinds of statements.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Fri, Jan 25, 2013 at 11:56 PM, Alain Ekambi <ja...@gmail.com>wrote:
> @Roland
> For the SDK it s surely not a problem since it s all Apache.
> But anyone using the Apache Flex SDK to write an ExtJS application will
> need a commercial license from Sencha or will have to open source the code.
>
> This is worth mentioning.
> (I wrote an SDK around EXTJS, so i know for sure)
>
>
Yes, Alain, I can second that.
So it is not the perfect choice for every project, but since Flex targets
enterprise software, I think it is still a valid choice.
-Frank-
Re: [ASJS] Integration with existing JS libraries and components
Posted by Alain Ekambi <ja...@gmail.com>.
@Roland
For the SDK it s surely not a problem since it s all Apache.
But anyone using the Apache Flex SDK to write an ExtJS application will
need a commercial license from Sencha or will have to open source the code.
This is worth mentioning.
(I wrote an SDK around EXTJS, so i know for sure)
2013/1/25 Roland Zwaga <ro...@stackandheap.com>
> Hi Alain,
>
> I'm not sure if the license really comes into play here, all we're doing is
> integrate with an API,
> we don't fork or use their code in any way.
> We might have to look into the implications for crating an AS3 shim for
> their API's though,
> so you do make a valid point.
>
> Roland
>
> On 25 January 2013 23:41, Alain Ekambi <ja...@gmail.com> wrote:
>
> > Before going further with ExtJS make sure licensing is clear.
> > Cuz ExtJS is GPL/Commercial.
> >
> >
> > 2013/1/25 Frank Wienberg <fr...@jangaroo.net>
> >
> > > Hi Roland,
> > >
> > > thank you for bringing up this point, I think it is crucial for the
> > success
> > > of Apache Flex / JS!
> > > I Erik's latest thread, we just discussed the different approaches to
> > come
> > > up with a JS-enabled component library for Flex.
> > > I mentioned that we already have an ActionScript-API for Ext JS from
> the
> > > Jangaroo project.
> > > Using the original Ext JavaScript code for deployment and the "Ext AS"
> > API
> > > for IDE support and compilation, you can create Ext JS applications in
> > AS3
> > > and MXML.
> > > Jangaroo actually uses a [Native] annotation, but does not yet support
> > > referencing the script to load or alias the JavaScript identifier.
> > > Both Erik and I propose using a JavaScript module approach (Erik chose
> > > Google's Closure library / goog.require(), I use AMD / RequireJS). The
> > cool
> > > thing about generating JavaScript code that uses a require() API is
> that
> > is
> > > plays well with "native" JavaScript code. You can require() JS code
> from
> > AS
> > > code and vice versa. I still think that RequireJS is the better choice,
> > as
> > > Closure implements *synchronous* require() which does not work
> > dynamically
> > > in the browser, and the Closure Library comes with many many more
> > features,
> > > while RequireJS just focuses on (loading and linking) modules.
> > > In any case, a JavaScript module is defined by two things
> > > * which script to load
> > > * what to return as the "value" of the module
> > > The module loader takes care of every script being loaded exactly once,
> > > store the value, and return the (same) value on every subsequent
> > require()
> > > call.
> > > So I think your example [NativeAPI(path="/js/jquery-1.4.js")] is the
> way
> > to
> > > go, complemented by a way to specify what the module value is. For
> > example,
> > > [Native(path="/js/jquery-1.4.js", global="jquery")] could mean for the
> > > module loader, "load and evaluate the script /js/jquery-1.4.js once,
> and
> > > every time return the value of the global variable 'jquery'". So then,
> > the
> > > compiler would be able to generate require() calls to the right script
> > and
> > > retrieve the right member afterwards. For RequireJS, there is a shim!
> > > plugin<https://github.com/brettz9/shim/#readme>that does something
> > > similar. It is easy to write a custom plugin that would
> > > allow writing something like
> > >
> > > define(["global!jquery@js/jquery-1.4"], function(JQuery) {
> > > // use "class" JQuery...
> > > }
> > >
> > > Using this approach, we can define an API for a JavaScript file that
> > > defines several classes, which is quite typical.
> > >
> > > To generate the Ext AS API, I wrote a Java tool
> > > (ExtAsApiGenerator<
> > >
> >
> https://github.com/CoreMedia/jangaroo-tools/blob/master/exml/ext-as-api-generator/src/main/java/net/jangaroo/exml/tools/ExtAsApiGenerator.java
> > > >,
> > > part of jangaroo-tools on github) that imports the JSON format exported
> > by
> > > Sencha's JSDoc documentation tool
> > > jsduck<https://github.com/senchalabs/jsduck/wiki/Guide> and
> > > generates AS3 API wrappers. So updates of the original API can easily
> be
> > > taken up, and other JavaScript APIs that use or are compatible with
> > jsduck
> > > can be translated to AS3 APIs. Also, if you need a slightly different
> AS3
> > > API (e.g. different annotations), the tool is easy to adapt to your
> needs
> > > (after all, it is open source).
> > >
> > > All in all, I think there is great potential in combining Flex and
> > > JavaScript, and we need to provide good tool support to make it easy!
> > >
> > > Cheers,
> > > -Frank-
> > >
> >
>
>
>
> --
> regards,
> Roland
>
> --
> Roland Zwaga
> Senior Consultant | Stack & Heap BVBA
>
> +32 (0)486 16 12 62 | roland@stackandheap.com |
> http://www.stackandheap.com
>
> http://zwaga.blogspot.com
> http://www.springactionscript.org
> http://www.as3commons.org
>
Re: [ASJS] Integration with existing JS libraries and components
Posted by Roland Zwaga <ro...@stackandheap.com>.
Hi Alain,
I'm not sure if the license really comes into play here, all we're doing is
integrate with an API,
we don't fork or use their code in any way.
We might have to look into the implications for crating an AS3 shim for
their API's though,
so you do make a valid point.
Roland
On 25 January 2013 23:41, Alain Ekambi <ja...@gmail.com> wrote:
> Before going further with ExtJS make sure licensing is clear.
> Cuz ExtJS is GPL/Commercial.
>
>
> 2013/1/25 Frank Wienberg <fr...@jangaroo.net>
>
> > Hi Roland,
> >
> > thank you for bringing up this point, I think it is crucial for the
> success
> > of Apache Flex / JS!
> > I Erik's latest thread, we just discussed the different approaches to
> come
> > up with a JS-enabled component library for Flex.
> > I mentioned that we already have an ActionScript-API for Ext JS from the
> > Jangaroo project.
> > Using the original Ext JavaScript code for deployment and the "Ext AS"
> API
> > for IDE support and compilation, you can create Ext JS applications in
> AS3
> > and MXML.
> > Jangaroo actually uses a [Native] annotation, but does not yet support
> > referencing the script to load or alias the JavaScript identifier.
> > Both Erik and I propose using a JavaScript module approach (Erik chose
> > Google's Closure library / goog.require(), I use AMD / RequireJS). The
> cool
> > thing about generating JavaScript code that uses a require() API is that
> is
> > plays well with "native" JavaScript code. You can require() JS code from
> AS
> > code and vice versa. I still think that RequireJS is the better choice,
> as
> > Closure implements *synchronous* require() which does not work
> dynamically
> > in the browser, and the Closure Library comes with many many more
> features,
> > while RequireJS just focuses on (loading and linking) modules.
> > In any case, a JavaScript module is defined by two things
> > * which script to load
> > * what to return as the "value" of the module
> > The module loader takes care of every script being loaded exactly once,
> > store the value, and return the (same) value on every subsequent
> require()
> > call.
> > So I think your example [NativeAPI(path="/js/jquery-1.4.js")] is the way
> to
> > go, complemented by a way to specify what the module value is. For
> example,
> > [Native(path="/js/jquery-1.4.js", global="jquery")] could mean for the
> > module loader, "load and evaluate the script /js/jquery-1.4.js once, and
> > every time return the value of the global variable 'jquery'". So then,
> the
> > compiler would be able to generate require() calls to the right script
> and
> > retrieve the right member afterwards. For RequireJS, there is a shim!
> > plugin<https://github.com/brettz9/shim/#readme>that does something
> > similar. It is easy to write a custom plugin that would
> > allow writing something like
> >
> > define(["global!jquery@js/jquery-1.4"], function(JQuery) {
> > // use "class" JQuery...
> > }
> >
> > Using this approach, we can define an API for a JavaScript file that
> > defines several classes, which is quite typical.
> >
> > To generate the Ext AS API, I wrote a Java tool
> > (ExtAsApiGenerator<
> >
> https://github.com/CoreMedia/jangaroo-tools/blob/master/exml/ext-as-api-generator/src/main/java/net/jangaroo/exml/tools/ExtAsApiGenerator.java
> > >,
> > part of jangaroo-tools on github) that imports the JSON format exported
> by
> > Sencha's JSDoc documentation tool
> > jsduck<https://github.com/senchalabs/jsduck/wiki/Guide> and
> > generates AS3 API wrappers. So updates of the original API can easily be
> > taken up, and other JavaScript APIs that use or are compatible with
> jsduck
> > can be translated to AS3 APIs. Also, if you need a slightly different AS3
> > API (e.g. different annotations), the tool is easy to adapt to your needs
> > (after all, it is open source).
> >
> > All in all, I think there is great potential in combining Flex and
> > JavaScript, and we need to provide good tool support to make it easy!
> >
> > Cheers,
> > -Frank-
> >
>
--
regards,
Roland
--
Roland Zwaga
Senior Consultant | Stack & Heap BVBA
+32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com
http://zwaga.blogspot.com
http://www.springactionscript.org
http://www.as3commons.org
Re: [ASJS] Integration with existing JS libraries and components
Posted by Alain Ekambi <ja...@gmail.com>.
Before going further with ExtJS make sure licensing is clear.
Cuz ExtJS is GPL/Commercial.
2013/1/25 Frank Wienberg <fr...@jangaroo.net>
> Hi Roland,
>
> thank you for bringing up this point, I think it is crucial for the success
> of Apache Flex / JS!
> I Erik's latest thread, we just discussed the different approaches to come
> up with a JS-enabled component library for Flex.
> I mentioned that we already have an ActionScript-API for Ext JS from the
> Jangaroo project.
> Using the original Ext JavaScript code for deployment and the "Ext AS" API
> for IDE support and compilation, you can create Ext JS applications in AS3
> and MXML.
> Jangaroo actually uses a [Native] annotation, but does not yet support
> referencing the script to load or alias the JavaScript identifier.
> Both Erik and I propose using a JavaScript module approach (Erik chose
> Google's Closure library / goog.require(), I use AMD / RequireJS). The cool
> thing about generating JavaScript code that uses a require() API is that is
> plays well with "native" JavaScript code. You can require() JS code from AS
> code and vice versa. I still think that RequireJS is the better choice, as
> Closure implements *synchronous* require() which does not work dynamically
> in the browser, and the Closure Library comes with many many more features,
> while RequireJS just focuses on (loading and linking) modules.
> In any case, a JavaScript module is defined by two things
> * which script to load
> * what to return as the "value" of the module
> The module loader takes care of every script being loaded exactly once,
> store the value, and return the (same) value on every subsequent require()
> call.
> So I think your example [NativeAPI(path="/js/jquery-1.4.js")] is the way to
> go, complemented by a way to specify what the module value is. For example,
> [Native(path="/js/jquery-1.4.js", global="jquery")] could mean for the
> module loader, "load and evaluate the script /js/jquery-1.4.js once, and
> every time return the value of the global variable 'jquery'". So then, the
> compiler would be able to generate require() calls to the right script and
> retrieve the right member afterwards. For RequireJS, there is a shim!
> plugin<https://github.com/brettz9/shim/#readme>that does something
> similar. It is easy to write a custom plugin that would
> allow writing something like
>
> define(["global!jquery@js/jquery-1.4"], function(JQuery) {
> // use "class" JQuery...
> }
>
> Using this approach, we can define an API for a JavaScript file that
> defines several classes, which is quite typical.
>
> To generate the Ext AS API, I wrote a Java tool
> (ExtAsApiGenerator<
> https://github.com/CoreMedia/jangaroo-tools/blob/master/exml/ext-as-api-generator/src/main/java/net/jangaroo/exml/tools/ExtAsApiGenerator.java
> >,
> part of jangaroo-tools on github) that imports the JSON format exported by
> Sencha's JSDoc documentation tool
> jsduck<https://github.com/senchalabs/jsduck/wiki/Guide> and
> generates AS3 API wrappers. So updates of the original API can easily be
> taken up, and other JavaScript APIs that use or are compatible with jsduck
> can be translated to AS3 APIs. Also, if you need a slightly different AS3
> API (e.g. different annotations), the tool is easy to adapt to your needs
> (after all, it is open source).
>
> All in all, I think there is great potential in combining Flex and
> JavaScript, and we need to provide good tool support to make it easy!
>
> Cheers,
> -Frank-
>
Re: [ASJS] Integration with existing JS libraries and components
Posted by Roland Zwaga <ro...@stackandheap.com>.
Hey Erik,
comments inline as usual:
On 26 January 2013 08:28, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Hi,
>
> > My main problem with using Closure is that it introduces a second parsing
> > and manipulation
> > pass while, IMHO, all of the necessary work can be done inside Falcon
> since
> > all necessary
> > information is contained within the AST. Therefore implementing the whole
> > shebang inside
> > Falcon will be faster.
>
> The goal is to move the functionality that is currently in the ant
> script into FalconJx. After all, it's just 2 calls to a Python script
> and some file manipulation.
>
Ehm, does that mean that FalconJx will have a dependency on Python as well?
That would be another dependency then and also making the install process
quite a bit more complicated. Or am I misunderstanding?
> As to the 'second pass': that will always be needed, as the Falcons
> are compilers, not optimisers. It has been discussed and dismissed
> that we would write our own JS optimiser; there are so many excellent
> ones available all over the place. Using the Closure Compiler gives us
> the added advantage of doing an actual re-compile of the JS, instead
> of plain optimisation. This means that it can achieve incredibly
> efficient and small code. Please look at the 'release' output from my
> proof of concept.
>
Ok, I guess I missed that discussion, I thought eventually it would be a
better
idea to write our own optimizer. Since working straight off the original AST
sounded to me like a the most efficient choice. But whatever the group
decided, then
fine.
> > Plus it removes a dependency, which is always good,
> > again IMHO.
>
> How is replacing Closure for RequireJS removing a dependency?
>
The way I see it the generated JS will already have a dependency on one ore
more JS
libraries (such as your vanilla SDK), so adding requireJS is just another
JS lib.
While I saw Closure more as a dependency on a tool (a tool that,
potentially, has dependencies
on other libraries or tools as well). So I agree with you to a certain
extend that it is indeed
replacing one dependency with another, but requireJS seems to be more
lightweight, that is all.
> > The fact that your requireJS approach is also asynchronous is a big boon
> as
> > well. It means
> > an application could be loaded incrementally much easier, and from what I
> > understand
> > incredibly granular.
>
> The same goes for Closure. Please look at my previous email for more
> on this particular topic.
>
Yes, I saw the other email, so my apologies for that confusion. I was
relying on faulty info apparently.
> Again, I like the approach you mention as an excellent addition to the
> future of Flex. I don't mind (much ;-)) that you prefer one solution
> over another. What I do mind is when the choice is made based on
> faulty information. This email is merely intended to put to rest some
> of the FUD that seems to be going around about Closure.
Alright, thanks for clearing all of this up :)
Roland
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Hi,
> My main problem with using Closure is that it introduces a second parsing
> and manipulation
> pass while, IMHO, all of the necessary work can be done inside Falcon since
> all necessary
> information is contained within the AST. Therefore implementing the whole
> shebang inside
> Falcon will be faster.
The goal is to move the functionality that is currently in the ant
script into FalconJx. After all, it's just 2 calls to a Python script
and some file manipulation.
As to the 'second pass': that will always be needed, as the Falcons
are compilers, not optimisers. It has been discussed and dismissed
that we would write our own JS optimiser; there are so many excellent
ones available all over the place. Using the Closure Compiler gives us
the added advantage of doing an actual re-compile of the JS, instead
of plain optimisation. This means that it can achieve incredibly
efficient and small code. Please look at the 'release' output from my
proof of concept.
> Plus it removes a dependency, which is always good,
> again IMHO.
How is replacing Closure for RequireJS removing a dependency?
> The fact that your requireJS approach is also asynchronous is a big boon as
> well. It means
> an application could be loaded incrementally much easier, and from what I
> understand
> incredibly granular.
The same goes for Closure. Please look at my previous email for more
on this particular topic.
> Anyways, I have some thoughts about the actual implementation of all of
> this, but I'm gonna
Again, I like the approach you mention as an excellent addition to the
future of Flex. I don't mind (much ;-)) that you prefer one solution
over another. What I do mind is when the choice is made based on
faulty information. This email is merely intended to put to rest some
of the FUD that seems to be going around about Closure.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Roland Zwaga <ro...@stackandheap.com>.
Hey Frank,
thanks a lot for your elaborate answer (as usual). Basically everything I
had in mind
you pretty much described. So I'm pretty stoked that this could be
implemented rather
quickly.
Between your and Erik's approach I already prefered yours to be honest
(Erik, this is
no stab under water in your direction, its just my opinion, hehe).
My main problem with using Closure is that it introduces a second parsing
and manipulation
pass while, IMHO, all of the necessary work can be done inside Falcon since
all necessary
information is contained within the AST. Therefore implementing the whole
shebang inside
Falcon will be faster. Plus it removes a dependency, which is always good,
again IMHO.
The fact that your requireJS approach is also asynchronous is a big boon as
well. It means
an application could be loaded incrementally much easier, and from what I
understand
incredibly granular.
Its awesome to read that you already have a system in place to generate an
AS3 shim for the
extJS components, that'll definitely save some typing :)
Anyways, I have some thoughts about the actual implementation of all of
this, but I'm gonna
write those down tomorrow. For now I think I want to head to bed :)
cheers everyone,
Roland
On 25 January 2013 23:25, Frank Wienberg <fr...@jangaroo.net> wrote:
> Hi Roland,
>
> thank you for bringing up this point, I think it is crucial for the success
> of Apache Flex / JS!
> I Erik's latest thread, we just discussed the different approaches to come
> up with a JS-enabled component library for Flex.
> I mentioned that we already have an ActionScript-API for Ext JS from the
> Jangaroo project.
> Using the original Ext JavaScript code for deployment and the "Ext AS" API
> for IDE support and compilation, you can create Ext JS applications in AS3
> and MXML.
> Jangaroo actually uses a [Native] annotation, but does not yet support
> referencing the script to load or alias the JavaScript identifier.
> Both Erik and I propose using a JavaScript module approach (Erik chose
> Google's Closure library / goog.require(), I use AMD / RequireJS). The cool
> thing about generating JavaScript code that uses a require() API is that is
> plays well with "native" JavaScript code. You can require() JS code from AS
> code and vice versa. I still think that RequireJS is the better choice, as
> Closure implements *synchronous* require() which does not work dynamically
> in the browser, and the Closure Library comes with many many more features,
> while RequireJS just focuses on (loading and linking) modules.
> In any case, a JavaScript module is defined by two things
> * which script to load
> * what to return as the "value" of the module
> The module loader takes care of every script being loaded exactly once,
> store the value, and return the (same) value on every subsequent require()
> call.
> So I think your example [NativeAPI(path="/js/jquery-1.4.js")] is the way to
> go, complemented by a way to specify what the module value is. For example,
> [Native(path="/js/jquery-1.4.js", global="jquery")] could mean for the
> module loader, "load and evaluate the script /js/jquery-1.4.js once, and
> every time return the value of the global variable 'jquery'". So then, the
> compiler would be able to generate require() calls to the right script and
> retrieve the right member afterwards. For RequireJS, there is a shim!
> plugin<https://github.com/brettz9/shim/#readme>that does something
> similar. It is easy to write a custom plugin that would
> allow writing something like
>
> define(["global!jquery@js/jquery-1.4"], function(JQuery) {
> // use "class" JQuery...
> }
>
> Using this approach, we can define an API for a JavaScript file that
> defines several classes, which is quite typical.
>
> To generate the Ext AS API, I wrote a Java tool
> (ExtAsApiGenerator<
> https://github.com/CoreMedia/jangaroo-tools/blob/master/exml/ext-as-api-generator/src/main/java/net/jangaroo/exml/tools/ExtAsApiGenerator.java
> >,
> part of jangaroo-tools on github) that imports the JSON format exported by
> Sencha's JSDoc documentation tool
> jsduck<https://github.com/senchalabs/jsduck/wiki/Guide> and
> generates AS3 API wrappers. So updates of the original API can easily be
> taken up, and other JavaScript APIs that use or are compatible with jsduck
> can be translated to AS3 APIs. Also, if you need a slightly different AS3
> API (e.g. different annotations), the tool is easy to adapt to your needs
> (after all, it is open source).
>
> All in all, I think there is great potential in combining Flex and
> JavaScript, and we need to provide good tool support to make it easy!
>
> Cheers,
> -Frank-
>
--
regards,
Roland
--
Roland Zwaga
Senior Consultant | Stack & Heap BVBA
+32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com
http://zwaga.blogspot.com
http://www.springactionscript.org
http://www.as3commons.org
Re: [ASJS] Integration with existing JS libraries and components
Posted by Frank Wienberg <fr...@jangaroo.net>.
Hi Roland,
thank you for bringing up this point, I think it is crucial for the success
of Apache Flex / JS!
I Erik's latest thread, we just discussed the different approaches to come
up with a JS-enabled component library for Flex.
I mentioned that we already have an ActionScript-API for Ext JS from the
Jangaroo project.
Using the original Ext JavaScript code for deployment and the "Ext AS" API
for IDE support and compilation, you can create Ext JS applications in AS3
and MXML.
Jangaroo actually uses a [Native] annotation, but does not yet support
referencing the script to load or alias the JavaScript identifier.
Both Erik and I propose using a JavaScript module approach (Erik chose
Google's Closure library / goog.require(), I use AMD / RequireJS). The cool
thing about generating JavaScript code that uses a require() API is that is
plays well with "native" JavaScript code. You can require() JS code from AS
code and vice versa. I still think that RequireJS is the better choice, as
Closure implements *synchronous* require() which does not work dynamically
in the browser, and the Closure Library comes with many many more features,
while RequireJS just focuses on (loading and linking) modules.
In any case, a JavaScript module is defined by two things
* which script to load
* what to return as the "value" of the module
The module loader takes care of every script being loaded exactly once,
store the value, and return the (same) value on every subsequent require()
call.
So I think your example [NativeAPI(path="/js/jquery-1.4.js")] is the way to
go, complemented by a way to specify what the module value is. For example,
[Native(path="/js/jquery-1.4.js", global="jquery")] could mean for the
module loader, "load and evaluate the script /js/jquery-1.4.js once, and
every time return the value of the global variable 'jquery'". So then, the
compiler would be able to generate require() calls to the right script and
retrieve the right member afterwards. For RequireJS, there is a shim!
plugin<https://github.com/brettz9/shim/#readme>that does something
similar. It is easy to write a custom plugin that would
allow writing something like
define(["global!jquery@js/jquery-1.4"], function(JQuery) {
// use "class" JQuery...
}
Using this approach, we can define an API for a JavaScript file that
defines several classes, which is quite typical.
To generate the Ext AS API, I wrote a Java tool
(ExtAsApiGenerator<https://github.com/CoreMedia/jangaroo-tools/blob/master/exml/ext-as-api-generator/src/main/java/net/jangaroo/exml/tools/ExtAsApiGenerator.java>,
part of jangaroo-tools on github) that imports the JSON format exported by
Sencha's JSDoc documentation tool
jsduck<https://github.com/senchalabs/jsduck/wiki/Guide> and
generates AS3 API wrappers. So updates of the original API can easily be
taken up, and other JavaScript APIs that use or are compatible with jsduck
can be translated to AS3 APIs. Also, if you need a slightly different AS3
API (e.g. different annotations), the tool is easy to adapt to your needs
(after all, it is open source).
All in all, I think there is great potential in combining Flex and
JavaScript, and we need to provide good tool support to make it easy!
Cheers,
-Frank-
Re: [ASJS] Integration with existing JS libraries and components
Posted by Roland Zwaga <ro...@stackandheap.com>.
On 25 January 2013 22:03, Erik de Bruin <er...@ixsoftware.nl> wrote:
> > We most certainly will, once we get our misunderstandings out of the way
> :)
> > I think we both aim for the same things, we just need to find the same
> > wavelengths :)
>
> Your followup mails -- and me re-reading the original one, I know I
> was lazy reading it the first time :-) -- cleared things up a bit, and
> I must say I like what I think I now understand.
>
> I'd love to help out to get a demo of this idea going.
Alright, glad we're on the same page :) Only, it does involve some other
things I've been
thinking a bout concerning the compiler architecture.
I'm going to dump those into a new message to the list, since it doesn't
belong in this
particular thread :) Plus I need to get my own thought in order first,
since it'll probably be
a long email :)
cheers,
Roland
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> We most certainly will, once we get our misunderstandings out of the way :)
> I think we both aim for the same things, we just need to find the same
> wavelengths :)
Your followup mails -- and me re-reading the original one, I know I
was lazy reading it the first time :-) -- cleared things up a bit, and
I must say I like what I think I now understand.
I'd love to help out to get a demo of this idea going.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [ASJS] Integration with existing JS libraries and components
Posted by Roland Zwaga <ro...@stackandheap.com>.
Hey Erik,
comments are inline:
> The way that TypeScript and Randori/SharpKit integrate with JS is by
> > declaring some sort of interface which has exactly
> > the same signatures of their JS counterparts. I think this will quite
> > probably make the most sense for Apache Flex as well.
>
> That's what I'm doing, and what I understand from Alex's approach the
> same goes for him. I'm building a JS library with the same signature
> as the Flex SDK, Alex has started a new AS framework and is building a
> complementary JS framework with the same API.
>
I think you misread what I meant (or I explained it badly, very much
possible too).
What you're saying is that you're building a JS library that mimics and
existing AS3
library. What I meant was the other way around,
the use case where we reference an existing JS library from AS3 (therefore
my JQuery example).
> That's exactly what I've done for the Vanilla SDK: it's a Google
> Closure Library supported JS framework that uses a specific cross
> compilation implementation in the FalconJx compiler, the 'goog'
> emitter.
>
But that's referring to really cross-compiling a lot of the AS3 paradigms
to JS, very low-level
stuff which is now hard-coded into the JS emitter. What I was explaining
was a way of to
make a sort of configurable mapping between AS3 code signatures and an
existing JS library.
That way we won't have to change the compiler code when we want to support
a new JS library.
All that needs to be added is some sort of configuration.
Or I have totally misunderstood the FalconJx code and this is already
possible, if so, I apologize
for the confusion and kindly ask you to explain to me how its done exactly.
> If we want to gain some traction in the HTML world I strongly believe we
> > need to make friends out there :) And what better way of
> > making friends than through integrating with them :)
>
> The VanillaSDK approach does this for the Closure Library and the way
> Mike set up make this 'easy'. I've even set up the initial code needed
> to implement Frank W's "AMD/RequireJS" approach.
>
See my comments in the previous block. From what I understand until now
your two
approaches are both implementations of an emmitter, hence require a
change/addition
to the compiler framework.
> > Please feel free to call me a fool and tell me my idea is crap, because I
> > might just be talking out of my ass as usual. :)
>
> Not a fool at all, and I like your idea so much that I've already
> started work on one implementation :-)
>
> Hope we can work together to make this the future of Flex!
>
We most certainly will, once we get our misunderstandings out of the way :)
I think we both aim for the same things, we just need to find the same
wavelengths :)
Roland
Re: [ASJS] Integration with existing JS libraries and components
Posted by Alex Harui <ah...@adobe.com>.
While both Erik and I are using Goog, I think Roland is asking why we aren't
use Jquery or ExtJS UI components.
In my framework, I'm not right now because I had trouble getting my head
around them and the ones I looked at seemed to come with application
framework infrastructure, and I want to start with the basic built-ins.
One difference in API between my new framework and the Flex SDK is that the
Flex SDK tried to have one button that did everything, whereas I want the
new framework to have many buttons, some that are bare bones and then
fancier ones. The ones I'm working on new wrap HTML button. Then I would
like to see ones that wrap the built in HTML5 button. And someone else is
welcome to wrap some other JS framework's button if they want.
On 1/25/13 12:13 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> The title of this message says exactly what I mean. Right now we're talking
>> about cross compiling the Flex SDK
>> itself, along with all of its components.
>
> No, neither Alex nor I are taking that approach.
>
>> The way that TypeScript and Randori/SharpKit integrate with JS is by
>> declaring some sort of interface which has exactly
>> the same signatures of their JS counterparts. I think this will quite
>> probably make the most sense for Apache Flex as well.
>
> That's what I'm doing, and what I understand from Alex's approach the
> same goes for him. I'm building a JS library with the same signature
> as the Flex SDK, Alex has started a new AS framework and is building a
> complementary JS framework with the same API.
>
>> And we could just use regular actionscript interfaces to do it. Probably
>> with a small bit of annotation, so, for example,
>> ...
>> What we then would need is some sort of compiler support that recognizes
>> the annotation and automatically includes the
>> specified .js file. (instead of trying to cross compile the interface)
>
> That's exactly what I've done for the Vanilla SDK: it's a Google
> Closure Library supported JS framework that uses a specific cross
> compilation implementation in the FalconJx compiler, the 'goog'
> emitter.
>
>> If we want to gain some traction in the HTML world I strongly believe we
>> need to make friends out there :) And what better way of
>> making friends than through integrating with them :)
>
> The VanillaSDK approach does this for the Closure Library and the way
> Mike set up make this 'easy'. I've even set up the initial code needed
> to implement Frank W's "AMD/RequireJS" approach.
>
>> Please feel free to call me a fool and tell me my idea is crap, because I
>> might just be talking out of my ass as usual. :)
>
> Not a fool at all, and I like your idea so much that I've already
> started work on one implementation :-)
>
> Hope we can work together to make this the future of Flex!
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [ASJS] Integration with existing JS libraries and components
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> The title of this message says exactly what I mean. Right now we're talking
> about cross compiling the Flex SDK
> itself, along with all of its components.
No, neither Alex nor I are taking that approach.
> The way that TypeScript and Randori/SharpKit integrate with JS is by
> declaring some sort of interface which has exactly
> the same signatures of their JS counterparts. I think this will quite
> probably make the most sense for Apache Flex as well.
That's what I'm doing, and what I understand from Alex's approach the
same goes for him. I'm building a JS library with the same signature
as the Flex SDK, Alex has started a new AS framework and is building a
complementary JS framework with the same API.
> And we could just use regular actionscript interfaces to do it. Probably
> with a small bit of annotation, so, for example,
> ...
> What we then would need is some sort of compiler support that recognizes
> the annotation and automatically includes the
> specified .js file. (instead of trying to cross compile the interface)
That's exactly what I've done for the Vanilla SDK: it's a Google
Closure Library supported JS framework that uses a specific cross
compilation implementation in the FalconJx compiler, the 'goog'
emitter.
> If we want to gain some traction in the HTML world I strongly believe we
> need to make friends out there :) And what better way of
> making friends than through integrating with them :)
The VanillaSDK approach does this for the Closure Library and the way
Mike set up make this 'easy'. I've even set up the initial code needed
to implement Frank W's "AMD/RequireJS" approach.
> Please feel free to call me a fool and tell me my idea is crap, because I
> might just be talking out of my ass as usual. :)
Not a fool at all, and I like your idea so much that I've already
started work on one implementation :-)
Hope we can work together to make this the future of Flex!
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl