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?
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
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:
> 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
On Sat, Nov 7, 2009 at 12:38 PM, hawkett <hawk...@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.
> 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
-- Nick Johnson, Developer Programs Engineer, App Engine
Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number:
368047
> 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
'...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:
> On Sat, Nov 7, 2009 at 12:38 PM, hawkett <hawk...@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?
>> 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.
On Sat, Nov 7, 2009 at 4:18 PM, hawkett <hawk...@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?).
> '...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.
> > 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:
> > On Sat, Nov 7, 2009 at 12:38 PM, hawkett <hawk...@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?
> 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:
> >> 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.
> 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:
> On Sat, Nov 7, 2009 at 4:18 PM, hawkett <hawk...@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
> > '...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.
> > > 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:
> > > On Sat, Nov 7, 2009 at 12:38 PM, hawkett <hawk...@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?
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.
|
