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
-~----------~----~----~----~------~----~------~--~---

Reply via email to