Closure and Google App Engine

[acuth]

The Closure library download is 149MB and 2,933 files. I don't really
want to have that as a static dir in GAE. Does Google host it anywhere
so it can be referenced from a GAE app?

[Nick Johnson (Google)]

Hi Adrian,

Are you referring to the recently-released Closure JavaScript library? The intention is that you use it with Closure Compiler, producing a single script you can include with your app, so there's no need to include the entire thing.

-Nick Johnson

--
Nick Johnson, Developer Programs Engineer, App Engine
Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047

[hawkett]

Hi Nick,

There are a certain class of applications that modify their code at
runtime - is the intention that these use the restful Closure
JavaScript compiler API? One of the downsides to GWT is the need for
compilation (there's no compiler on GAE) - also making this a
*requirement* of a straight javascript solution takes away the
'dynamic' part of a 'dynamic language', and turns it into, well, just
a language. The Closure JavaScript library does allow us to run
without compilation, so we can use it dynamically, but as the original
poster noted, it takes up some pretty serious space - it would be
great to see google host this on a CDN to support this alongside the
compiled scenario. Thanks,

colin

On Nov 7, 10:03 pm, "Nick Johnson (Google)" <nick.john...@google.com>
wrote:

> Hi Adrian,
>
> Are you referring to the recently-released Closure JavaScript library? The
> intention is that you use it with Closure Compiler, producing a single
> script you can include with your app, so there's no need to include the
> entire thing.
>
> -Nick Johnson
>

[Nick Johnson (Google)]

On Sat, Nov 7, 2009 at 12:38 PM, hawkett <haw...@gmail.com> wrote:

Hi Nick,

  There are a certain class of applications that modify their code at
runtime - is the intention that these use the restful Closure
JavaScript compiler API?

What sort of runtime modification are you talking about?

 

 One of the downsides to GWT is the need for
compilation (there's no compiler on GAE) - also making this a
*requirement* of a straight javascript solution takes away the
'dynamic' part of a 'dynamic language', and turns it into, well, just
a language.  

Not at all - all the dynamic features of Javascript are available to you, whether you use the Closure library compiled or not.

 

The Closure JavaScript library does allow us to run
without compilation, so we can use it dynamically, but as the original
poster noted, it takes up some pretty serious space - it would be
great to see google host this on a CDN to support this alongside the
compiled scenario.  Thanks,

Apart from any issues with hosting, serving a production webapp with the uncompiled closure code will substantially slow things down for your users, as they are required to load (potentially) tens of javascript files instead of just a single one.

-Nick Johnson

 

colin

On Nov 7, 10:03 pm, "Nick Johnson (Google)" <nick.john...@google.com>
wrote:

> Hi Adrian,
>
> Are you referring to the recently-released Closure JavaScript library? The
> intention is that you use it with Closure Compiler, producing a single
> script you can include with your app, so there's no need to include the
> entire thing.
>
> -Nick Johnson
>

> On Fri, Nov 6, 2009 at 6:18 PM, acuth <adrian.cuthb...@gmail.com> wrote:
>
> > The Closure library download is 149MB and 2,933 files. I don't really
> > want to have that as a static dir in GAE. Does Google host it anywhere
> > so it can be referenced from a GAE app?
>
> --

> Nick Johnson, Developer Programs Engineer, App Engine
> Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number:
> 368047

[hawkett]

> What sort of runtime modification are you talking about?

A user changes a piece of javascript, or adds a piece of javascript -
for the sake of the example lets assume the javascript is stored in
the GAE datastore. Something that you get from javascript, and
precisely because it doesn't require compilation, is the ability to
press refresh on your browser and see the changes take effect. The
only opportunity to compile here appears to be via the rest api - do
you know if this api is suitable for GAE (e.g. execution timeouts
could be a problem via URL Fetch?).

> Not at all - all the dynamic features of Javascript are available to you,
> whether you use the Closure library compiled or not.

Lets look at a widely available definition of a dynamic language

http://en.wikipedia.org/wiki/Dynamic_programming_language

'...that execute at runtime many common behaviors that other languages
might perform during compilation,...'

The first feature listed there is 'Extension of the program'. Lets
assume my extension requires a google closure api that has not been
compiled in. If I'm not hosting the closure library on GAE, and it's
not on a CDN, then I need some other hosting solution, or I need to
recompile everything.

Clearly requiring a compilation phase does not retain all of the
dynamic language features of javascript. From one perspective,
linking is performed by the closure compiler when traditionally it was
performed by the browser at runtime. Of course compilation offers
performance improvements, but in return you suffer a loss of dynamic
language flexibility - its a well understood trade-off. With
Closure, google is offering a solution that supports both static and
dynamic linking, but without the CDN, the latter option has (even
greater) performance problems.

Unless you're suggesting that there is no valid use case for retaining
dynamic linking (in production or otherwise), then there is a clear
benefit to a fast, reliable and free host for the google Closure
Library. I would argue that there are some valid, and highly valuable
use cases that *require* dynamic linking, at runtime, in production.

> Apart from any issues with hosting, serving a production webapp with the
> uncompiled closure code will substantially slow things down for your users,
> as they are required to load (potentially) tens of javascript files instead
> of just a single one.

No doubt, but this is exactly the reason a CDN would be a welcome
offering. This, combined with effective browser caching go a long way
to mitigating these performance issues in applications that need to
retain the dynamic linking capabilities of javascript.

Don't get me wrong, the release of the closure library is awesome, and
very much appreciated, but not all use cases are suited to compiled
javascript, while others would be suited to a combination of both.
Access to a CDN, (and to a compiler accessible and useable from GAE)
would be really helpful. Thanks,

colin

On Nov 8, 2:15 am, "Nick Johnson (Google)" <nick.john...@google.com>
wrote:

[Barry Hunter]

2009/11/7 hawkett <haw...@gmail.com>:

>
>> What sort of runtime modification are you talking about?
>
> A user changes a piece of javascript, or adds a piece of javascript -
> for the sake of the example lets assume the javascript is stored in
> the GAE datastore.  Something that you get from javascript, and
> precisely because it doesn't require compilation, is the ability to
> press refresh on your browser and see the changes take effect.  The
> only opportunity to compile here appears to be via the rest api - do
> you know if this api is suitable for GAE (e.g. execution timeouts
> could be a problem via URL Fetch?).

Surely you talking about the closure *compiler*, not the closure *library* here

Admittedly my java is rusty, so dont know if you can use the provided
jar directly from (java!) appengine code. But downloadable as a 4mb
jar file so I would think that can be used on appengine.

I don't know enough about the library to know if having it accessible
in a common location (like Django in python?), would actually be a
benefit.

[Nick Johnson (Google)]

On Sat, Nov 7, 2009 at 4:18 PM, hawkett <haw...@gmail.com> wrote:

> What sort of runtime modification are you talking about?

A user changes a piece of javascript, or adds a piece of javascript -
for the sake of the example lets assume the javascript is stored in
the GAE datastore.  Something that you get from javascript, and
precisely because it doesn't require compilation, is the ability to
press refresh on your browser and see the changes take effect.  

This is a property of Javascript - but it doesn't mean every library has to abide by that. Closure consciously makes a tradeoff - it abandons a little flexibility in favor of improved responsiveness and smaller downloads.

 

The
only opportunity to compile here appears to be via the rest api - do
you know if this api is suitable for GAE (e.g. execution timeouts
could be a problem via URL Fetch?).

I'm not familiar with it. Give it a try!

 

> Not at all - all the dynamic features of Javascript are available to you,
> whether you use the Closure library compiled or not.

Lets look at a widely available definition of a dynamic language

http://en.wikipedia.org/wiki/Dynamic_programming_language

'...that execute at runtime many common behaviors that other languages
might perform during compilation,...'

The first feature listed there is 'Extension of the program'.  Lets
assume my extension requires a google closure api that has not been
compiled in.  If I'm not hosting the closure library on GAE, and it's
not on a CDN, then I need some other hosting solution, or I need to
recompile everything.

Having to recompile a third-party library does not affect whether or not JavaScript is a dynamic language or not. Third-party libraries are certainly not part of the JavaScript language. I think you misunderstand the meaning of 'extend' in context, too - in the context of a dynamic language, this generally means changing the behaviour of the language itself.

 

Clearly requiring a compilation phase does not retain all of the
dynamic language features of javascript.  From one perspective,
linking is performed by the closure compiler when traditionally it was
performed by the browser at runtime.  Of course compilation offers
performance improvements, but in return you suffer a loss of dynamic
language flexibility - its a well understood trade-off.   With
Closure, google is offering a solution that supports both static and
dynamic linking, but without the CDN, the latter option has (even
greater) performance problems.

Unless you're suggesting that there is no valid use case for retaining
dynamic linking (in production or otherwise), then there is a clear
benefit to a fast, reliable and free host for the google Closure
Library.  I would argue that there are some valid, and highly valuable
use cases that *require* dynamic linking, at runtime, in production.

You pointed out yourself just how many files and what a large total size the Closure library is. Requiring users to download parts of it un-compiled and un-minified to run your app is likely to make it an extremely slow app. I don't think many people will be willing to make that tradeoff.

[hawkett]

> Surely you talking about the closure *compiler*, not the closure *library* here

Both. Nick's point (as I read it) is that you shouldn't be using one
without the other, at least not in production, and my point is that
there are valid situations in which you do want the library and not
the compiler, and thus the availability of a fast, reliable and free
host for the closure library files would be welcome.

On Nov 8, 4:05 am, Barry Hunter <barrybhun...@googlemail.com> wrote:
> 2009/11/7 hawkett <hawk...@gmail.com>:

[hawkett]

> Closure consciously makes a tradeoff - it abandons a little
> flexibility in favor of improved responsiveness and smaller downloads.

I think we've both made that point about compilation. Unfortunately it
could be a gazillion times faster, better, stronger, cooler, but it
still won't be suitable for all use cases - no matter how many times
you wish it otherwise. For those use cases the performance benefits
of compilation are irrelevant, because compilation is not suitable.
Here's an example of a production application for which it would not
be suitable - http://code.google.com/apis/ajax/playground/ - and,
what's more, the users of this application are probably okay to wait
the extra time to be able to use closure *dynamically*. I'm sure
they'd really appreciate getting it to load as fast as possible
though, by say, putting it on a fast, highly available server.

The problem is not always as simple as 'compilation is better so do
it'.

Perhaps you're saying - 'If you don't want to compile, don't use
closure', but then I guess we won't see it on the ajax playground.

> You pointed out yourself just how many files and what a large total size the
> Closure library is. Requiring users to download parts of it un-compiled and
> un-minified to run your app is likely to make it an extremely slow app. I
> don't think many people will be willing to make that tradeoff

Google could minify it on the CDN? Otherwise someone might think
you're against this whole CDN idea ;)

On Nov 8, 4:58 am, "Nick Johnson (Google)" <nick.john...@google.com>
wrote:

[acuth]

Just for the record... my initial post was just me wanting to explore
using Closure as cheaply as possible.

I certainly agree that one would expect to use the Closure Compiler
for a production system. But I would have thought that the goog.provide
()/goog.require() mechanism in combination with minified files on a
CDN would have been an acceptable model for developers exploring
Closure for the first time.

Currently everything I have that is publicly hosted is either on
Blogger or GAE and I don't think either of those is a natural home for
the Closure Library.