guys, thanks to java gae, we already have javascript on appspot checkout ringojs , a ~commonjs framework. or you can go to a much lower level through rhino itself.
cheers On Mon, Oct 11, 2010 at 11:38 PM, nickmilon <[email protected]> wrote: > I think a new language should be out of the question, well until > current platform is stabilized. > But .... > then again who am I to tell big G what to do and what not. > ;-) > > > > On Oct 11, 10:06 pm, "Ikai Lan (Google)" <[email protected]> > wrote: >> Believe it or not, we've talked about this. There's a lot of interest in V8 >> and JavaScript. From a technical standpoint, there are still advances that >> need to be made in V8 (garbage collection comes to mind) - see for yourself >> by searching for articles about Node.js and GC. >> >> Ultimately, it comes down to resources, which is probably why we aren't >> working on this right away. It makes more sense for us to harden our Java >> and Python runtimes, allow more classes into the whitelist, and look into >> ways we can support versions of Python that are higher than 2.5. As much >> traction as Node.js has in the blogosphere and Hacker News, it's still hard >> to make a business case for a platform that has, at best, poor tooling and a >> small (albeit enthusiastic) core community. You have a gripe with Python >> being slow - I'm surprised this is an issue, as most of your time is spent >> blocking on RPC calls, not interpreter gotchas. It doesn't matter how fast >> your Ferrari is if there are stop signs on every block. >> >> I'd look into Heroku's experimental node.js support: >> >> http://blog.heroku.com/archives/2010/4/28/node_js_support_experimental/ >> >> Try building an application using node.js as your full application stack. >> I'd love to see more article content about the challenges/benefits of doing >> this. There isn't enough, as far as I am concerned. >> >> -- >> Ikai Lan >> Developer Programs Engineer, Google App Engine >> Blogger:http://googleappengine.blogspot.com >> Reddit:http://www.reddit.com/r/appengine >> Twitter:http://twitter.com/app_engine >> >> On Sun, Oct 10, 2010 at 8:46 PM, John McLaughlin < >> >> >> >> >> >> >> >> [email protected]> wrote: >> > Thanks for the info Demis, I alway like listening to Douglas >> > Crockford. I also checked out >> >http://developer.yahoo.com/yui/theater/video.php?v=glass-node. >> > Very interesting stuff, I can definitely see using it in the future. >> > In particular using JavaScript as the templating engine seems really >> > powerful. So you've changed my mind. However since I'm still worried >> > about the "plethora" part of "...plethora of well-tested JavaScript >> > frameworks and libraries available...", I'll say that if node.js, >> > YUI3, and JSLint are defined as best practices -- I'm on board -- >> > server-side JavaScript all the way. >> >> > - John >> >> > On Oct 10, 4:21 pm, Demis Bellot <[email protected]> wrote: >> > > Unless I'm mistaken about recent advancements, Python belongs in the same >> > > performance category as Ruby, Perl and PHP i.e. slow compared against >> > native >> > > or optimized managed languages. >> >> > > I understand there are a number efforts underway to improve performance >> > > (e.g. using an LLVM backend withhttp:// >> > code.google.com/p/unladen-swallow/), >> > > but I don't think this is actually being used yet? >> > > I'm sure with having Guido onboard Python has been heavily optimized for >> > GAE >> > > but there is only so much optimizations possible with CPython. The >> > library >> > > code may be fast (i.e. thin wrappers over C libs) but the users code is >> > > going to be interpreted and slow. >> >> > > Since it impacts the performance of Chrome (one of Google's most valuable >> > > assets) and its millions of end users, I would think that more of >> > Google's >> > > engineering effort is behind making JavaScript as fast as possible with >> > V8 >> > > which I believe shows in the computer language shoot-out benchmarks, >> > where >> > > it looks as if V8 is several times faster than any Python implementation >> > > available: >> >http://shootout.alioth.debian.org/u32/which-programming-languages-are... >> >> > > The GAE Python API's also exposes sync IO requests and encourages >> > buffering >> > > which I believe also contributes a significant performance penalty per >> > > request. >> > > This is only an educated guess and I'm not sure what these raw language >> > > numbers translates in GAE performance though it should be pretty >> > indicative >> > > of the perf advantages possible. With the lack of an actual V8 >> > > implementation, internal Google Engineers would have the best insight as >> > to >> > > the potential gains if any (which I encourage on this thread). >> >> > > As for the language impedance mismatch, I think that having code from the >> > > same application being able to run on both client and server is heavily >> > > underrated. >> > > YUI is show casing some exciting possibilities they're doing around >> > node.js >> > > today:http://www.slideshare.net/apmoore/running-yui-3-on-nodejs-bayjax >> >> > > Where currently a lot of their JavaScript libraries already run on >> > node.js, >> > > but even more impressive than that they have implemented a server-side >> > W3C >> > > DOM that enables the same code they use do generate their DHTML Calendar >> > > control can be run on the server and output rendered on clients that have >> > > JavaScript disabled. Much of Google's Closure Library and its optimized >> > > JavaScript compiler should be able re-used on the server as well. >> >> > > I think this is only touching the ice berg, and Douglas Crockford has an >> > > inspirational video presentation on using JavaScript and an event-loop >> > > architecture (like node.js) on the server: >> >http://developer.yahoo.com/yui/theater/video.php?v=crockford-loopage >> >> > > Before V8 and node.js I would not have considered it, however with the >> > > maturing of these technologies, the plethora of well-tested JavaScript >> > > frameworks and libraries available and what I believe is a rejuvenated >> > look >> > > back into JavaScript - I think there has never been a better time to >> > provide >> > > a server-side JavaScript option in GAE. >> >> > > - Demis >> >> > > On Sun, Oct 10, 2010 at 11:10 PM, John McLaughlin < >> >> > > [email protected]> wrote: >> > > > My gut reaction to this is that I'd rather have Python 3 over server >> > > > side JavaScript. The Python API is already comparable to (and >> > > > possibly faster than) the Java API. Seehttp://gaejava.appspot.com/ >> > > > and >> > > >http://stackoverflow.com/questions/1085898/choosing-java-vs-python-on. >> > .. >> > > > . >> > > > So the performance argument is arguable at best. Additionally I don't >> > > > think the value of a tight developer community can be underestimated. >> > > > In particular I find these forums to be a huge benefit for learning >> > > > best practices, tips, and tricks. But I fear that introducing another >> > > > language -- and especially JavaScript, with it's tower of babel of >> > > > libraries and coding styles -- would decrease the signal to noise >> > > > ratio of the forums and the developer community. And that would >> > > > affect my productivity more than "language impedance". >> >> > > > Don't get me wrong -- I really, really, like JavaScript. It's an >> > > > awesomely creative language for making highly functional user >> > > > interfaces. But I really, really like Python as well -- mostly >> > > > because it is so clear, readable, predictable, and mostly has only one >> > > > right way to do things. This seems like a better language choice for >> > > > server. At least until GO (http://golang.org/) catches on ;-) >> >> > > > John >> >> > > > On Oct 10, 1:16 pm, Demis Bellot <[email protected]> wrote: >> > > > > Thanks for the link, I just added a little excerpt from my post to >> > the >> > > > list. >> >> > > > > I think the fact that so many other devs are coming to the same >> > > > conclusion >> > > > > independently speaks of how favourable a JavaScript for GAE solution >> > is. >> >> > > > > I'm sure if Google released a poll to gauge public interest about it, >> > you >> > > > > would get an positive response from the dev community. >> >> > > > > Here's hoping for some positive steps in exploring the idea. >> >> > > > > - Demis >> >> > > > > On Sun, Oct 10, 2010 at 8:29 PM, Robert Kluin < >> > [email protected] >> > > > >wrote: >> >> > > > > > I think it would be interesting too. Star issue 35. >> > > > > >http://code.google.com/p/googleappengine/issues/detail?id=35 >> >> > > > > > Just please do not post a "+1" or "me too" type comment, a star is >> > > > > > sufficient. >> >> > > > > > Robert >> >> > > > > > On Sun, Oct 10, 2010 at 14:56, Demis Bellot < >> > [email protected]> >> > > > > > wrote: >> > > > > > > Hey All, >> > > > > > > Love what you guys have created with Google App Engine although >> > > > > > > I'm surprised that you haven't offered JavaScript as a target >> > > > language >> > > > > > yet. >> > > > > > > It's a ubiquitous language known by most web developers and is >> > one of >> > > > the >> > > > > > > primary languages engrained into Google's DNA as you already >> > provide >> > > > a >> > > > > > great >> > > > > > > runtime for it in V8. The success of node.js/expressjs should >> > prove >> > > > that >> > > > > > it >> > > > > > > is a viable server platform with a willing community. >> > > > > > > The way I see it a V8-powered JavaScript hits a sweet spot: I >> > imagine >> > > > it >> > > > > > > would be faster to run than Python (my major gripe against it) >> > and >> > > > more >> > > > > > > terse, expressive and functional than Java (my major dislike). As >> > > > most >> > > > > > gae >> > > > > > > apps are websites, JavaScript also reduces the impedance language >> > > > > > miss-match >> > > > > > > as it will allow you to use the one language for both client and >> > > > server. >> > > > > > I >> > > > > > > would imagine that the per-request model of gae would also be >> > better >> > > > > > suited >> > > > > > > for JavaScript as opposed to the high start-up cost and >> > long-running >> > > > > > nature >> > > > > > > of Java. >> > > > > > > What do you guys think? I'm sure it's not the first time this has >> > > > been >> > > > > > > suggested, as it seems like a natural choice. >> >> > > > > > > -- >> > > > > > > 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]<google-appengine%2Bunsubscrib >> > > > > > > [email protected]><google-appengine%2Bunsubscrib >> > [email protected]><google-appengine%2Bunsubscrib >> > > > [email protected]> >> > > > > > . >> >> ... >> >> read more » > > -- > 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. > > -- jgabios http://bash.editia.info -- 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.
