flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: [FalconJx] New JavaScript runtime format prototype
Date Thu, 20 Dec 2012 23:20:41 GMT
> This the overall impression I have with the GCC approach: it introduced
> complexity only to optimize it later on.
> I think we better avoid complexity in the first place!

Well, it introduces "complexity" in order to facilitate BETTER
optimisation later on. So, by avoiding that "complexity" - simply
because we like "simplicity" - we'd end up with an inferior product.

> For goog.provide and goog.require, RequireJS provides alternatives that
> better fit our needs: asynchronous module loading much better reflects the
> nature of script loading in the browser. Synchronous require calls were
> made for Node.js or other environments that allow to load scripts
> synchronously. RequireJS concentrates exactly on that task and does nothing
> else.

The point of the Closure Builder is that there are no modules. It's
all one file (and a small one at that). There is no need to manage the
loading of any modules (with the added overhead required to make it
work) at all.

> goog.inherits and goog.base are IMHO not needed at all. In JS code
> generated from ActionScript, what goog.base does can be expressed by a
> direct function call (see my prototype). goog.inherits is replaced by my
> defineClass() utility, which consists of just 60 lines of code and supports
> many more AS3 language features than just inheritance. I also had an
> alternative "VanillaJS" version that did not even use a helper method for
> inheritance (since it is so easy using ES5 API), but adding the other
> language feature, I found that this introduced too much repetitive, boiler
> plate code.

Again: personal preference, but I prefer the readability and
consistency that comes from using "goog" for this. And I don't see
(other than stepping into, instead of over the lines with "goog") any
real difference in using one utility method over another. Let's
revisit this when I have had the chance to mock up some more code so
we can compare "intermediate" JS formats.

> One thing I'd like to know: can you use the Closure Tools *completely
> without* using the goog library in your JS code and still achieve
> ADVANCED_OPTIMIZATIONS? If not, I think that is exactly where the
> vendor-lock-in comes into play.


> See above. When talking about 1500 lines of code, I don't worry about code
> size, but about complexity that shines through during debugging.

Step over?

>> *tool/vendor dependency:* The Google Closure Tools are Open Source,
>> available under the Apache License 2.0.
> I know that. Still, it is Google's own interpretation of modules,
> inheritance, ... for which there are at least partially standards in
> JavaScript (ECMAScript 5, AMD).

Well, all code is someones interpretation of a requirement. And I
think that for suppliers of frameworks (like Google and ourselves),
that "partially" that you so casually throw in there really makes a
difference. I'm sure no-one with a corporate client is willing to
ditch IE 8 support "just yet". As long as Windows XP still holds at
least a third of the total OS market share, that browser isn't going
anywhere soon.

> To make the UI framework run cross-browser, I have no objections against
> using an existing JavaScript framework. But this is my point when talking
> about "separations of concerns". I wouldn't hard-wire the pure language
> translation to "goog" just because it is a good base for a cross browser UI
> framework. And any UI framework should be compatible with VanillaJS!

A difference in approach, I guess. You focus on a single requirement
and select the best tool for that, ending up with lots of tools when
the number of requirements increase. I tend to look at the larger
picture and select a tool that is best for the overall job... And
knowing the kind of products Google has produced and maintained -
using large teams, many different coders on one project - with that
tool, I'm pretty confident it will serve this project very well

> What makes a difference to me is that to link with RequireJS, you do not
> have use a RequireJS-specific syntax, but an AMD-specific one. They
> separate syntax and implementation, which GCC apparently doesn't.

GCC does not need specific syntax. It offers you the ability to add
annotation (but doesn't require it!) in order to help it do a better
job, but it will do an excellent job on vanilla JS as well.

> Yes, that's my point. I argue that it does *too much* in one tool, so we
> don't have fine-grained control over the code generation process.

Actually, I'm talking about the complete set of Closure Tools: JSDoc
annotations, Library, Compiler and Builder. That's 4 tools tailored to
work together, but at least the Library and the Compiler are
separately and independently usable. However, used together they
complement each other in a way no other combination of tools I know of

> Yes, but the code is still generated (even if only in-memory) and parsed,
> which is an unnecessary overhead in any case.

So you suggest we build our own optimiser/minifier (not an easy task,
it seems to me) and loose the ability to output "intermediate" code
just because we want to shave of (maybe, at most) a couple of seconds
from the compile time?

> I'm talking about a new feature available so far in Chrome only to let the
> browser debugger map the JavaScript code to the original source code, see
> for example
> http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
> If this feature was present in all major browsers, there would no longer be
> a need for a debuggable JavaScript code format if we generated source maps.
> Firefox has published an implementation plan, but it may take a while. IE
> 10 will probably follow, now that Microsoft pushes TypeScript.

Waiting for a non-standard feature to be implemented across browser
and JS VMs might take "a while" :-P


Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

View raw message