> 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)" <[email protected]> wrote: > On Sat, Nov 7, 2009 at 4:18 PM, hawkett <[email protected]> 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. > > > > > > > > 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 > > -- > 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 -~----------~----~----~----~------~----~------~--~---
