> 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)" <[email protected]> wrote: > On Sat, Nov 7, 2009 at 12:38 PM, hawkett <[email protected]> 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)" <[email protected]> > > 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 <[email protected]> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
