flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Wasilewski <devudes...@gmail.com>
Subject Re: [FalconJx] New JavaScript runtime format prototype
Date Thu, 20 Dec 2012 22:00:37 GMT
On 12/20/2012 9:54 PM, Erik de Bruin wrote:
> *tool/vendor dependency:* The Google Closure Tools are Open Source,
> available under the Apache License 2.0.
> *separation of concerns:*
> 1) a matter of choice and convenience, I'm not married to "goog" here,
> but I haven't seen a good reason NOT to use it, so far.
> 2) you are probably correct from a purely language translation point
> of view. But the "ultimate" goal here is not only a language
> translation, but also a framework translation. And I'm sure "some
> polyfills" are not enough to create a cross browser UI framework.
> 3) I'm hearing "different", I'm not sure I hear "better". Why wouldn't
> we use the Closure Builder for this? I explain the virtue of this tool
> in an earlier email and you can see it in action in the Publisher tool
> I set up in the 'develop' branch of the "asjs" section of the SVN
> repo.
> 4) the Closure Builder does a bit more than linking. Please see my
> previous remark and email, as well as the documentation available
> online.
> 5) GCC is also more than just an minifier. And we can run it straight
> from the cross compiler, as Mike suggested. That leaves us with the
> option of keeping the intermediate JS code as an supplement output.
> *testing:* never implied that GCC or anything would free us from
> testing any part of the code. And creating optimised/minified code
> straight from the cross compiler - without using an external tool as
> you seem to imply - would mean that we'd have to write our own
> optimiser/minifier into it. I'm not familiar with creating such a
> tool, but that sounds like a lot of work.
> *source maps:* I don't know what you mean by this, so I can't argue
> either direction :-)
> Like I emphasised before, and I'll repeat it every time it comes up:
> there is, at least not at this point in the development, an absolutely
> right nor absolutely wrong approach. I think we should look for the
> best of both approaches. Our approaches are essentially similar (only
> the tools differ) and I think both have strengths and weaknesses.
> Let's work on this a bit and than revisit this discussion and decide
> on the merits which one fullfils which requirements best.
> Have a great holiday, and keep having fun!
> EdB

I am signing off under Erik post and his thoughts

View raw message