views:

95

answers:

4

Does anyone know or have an opinion on whether AppEngine will add javascript as a supported language/framework and in what timeframe?

+1  A: 

Given that JavaScript is rarely used as a server-side language, that seems very unlikely to me. It's not like doing so would add a lot of potential users.

(Disclaimer: I work for Google, but nothing I write here should be taken as Google's stance on things, and I don't know anything about the AppEngine team's plans :)

EDIT: To answer Pointy's point, I think there's a big difference between JavaScript being supported and it being something you can get working if you try hard enough via Rhino and Java. Put it this way: if some obscure change to the Java support made life better for most Java users but broke a bit of JavaScript via Rhino, I'd expect that to have a relatively low priority for the team.

Jon Skeet
Rhino is part of Java! Sort-of.
Pointy
Java 6 ships with a Javascript interpreter. Also, Node.js is becoming increasingly popular (but is still niche) for serverside Javascript.
cletus
@Jon Well true but there are Javascript server-side frameworks designed for Rhino (like Helma), and in my experience Rhino is very solid. I've had experience with using Rhino in a high-volume commercial web app and I know of no problems with it (like, no unexplained flakiness etc)
Pointy
@cletus: I think the "niche" bit is still the important bit. There are bigger fish to fry if the AppEngine team wanted to find the next most important platform to do full, official support for.
Jon Skeet
For my money, using Javascript server-side is *seriously* underrated. I find it's hugely useful to code up an object once and use it either client- or server-side (or both). But as Pointy points out (no pun), you can already use Javascript on GAE (via Rhino).
T.J. Crowder
@Pointy: I dare say Rhino is solid and there are server-side frameworks available - the same could be said for many other platforms though. I still stand by my use of the word "rarely". If you were to list the top 5 server-side development platforms, would you really put JS in there?
Jon Skeet
@TJ Javascript cops a lot of flak because of cross-browser issues but that's really nothing to do with JS and all about the DOM. JS is actually a reasonably elegant, very modern language (of course it isn't without issues).
cletus
@cletus: I think you misread my comment. I said it was seriously *under*rated -- e.g., people think less of it than I think they should. I use Javascript server-side all the time and love it.
T.J. Crowder
@Jon you're right of course, but Javascript is definitely appealing!
Pointy
@Jon: While I expect problems from such a change would be a low priority for the team, since Rhino compiles Javascript to bytecode, it seems a very unlikely scenario. Re *"try hard enough via Rhino and Java"* -- what's the "hard" part? 1. Use Rhino to compile your Javascript to bytecode. 2. Deploy. Am I missing something, not having actually tried it on GAE?
T.J. Crowder
@T.J. Crowder: From Pointy's own comment: "but the bridge to Java is actually kind-of clumsy (numbers, for example)". Maybe it really is simple, but involving three different aspects when you're only actually interested in the JavaScript bit doesn't sound ideal to me.
Jon Skeet
@Jon: I haven't found it clumsy, but I've only done a few things (selected it for a project coming soon, though). I find it dead easy. Ex: Getting a `FileReader` (maybe not an ideal GAE example) in JS: `var r = new java.io.FileReader(filename);` (and I could even import the package and drop the qualifiers if I wanted). Anyway. I just didn't want people to get the impression we're talking about some kind of middle layer or something bridging the two (in fact, Pointy's term "bridge" is misleading IMV). The result of compiling Javascript to bytecode is bytecode, just the same as compiled Java.
T.J. Crowder
@T.J. My point is that it's still unlikely to be as pleasant to work in as an environment which has explicit support and which the team has made as simple as possible. If it works well enough for the OP then that's great - but I wouldn't expect them to spend much extra time on it.
Jon Skeet
@TJ yes, perhaps I wasn't clear. I was supporting your point. :) And clarifying to separate Javascript the language from the DOM.
cletus
+3  A: 

See this: http://helma.org/wiki/Helma+NG/Running%20Rhino%20and%20Helma%20NG%20on%20Google%20App%20Engine/

Because Java now supports JavaScript as part of its standard runtime, you can do all sorts of cool stuff.

Pointy
+1 Rhino is *seriously* cool -- Javascript plus access to nearly all of the underlying Java libraries. I was (and remain) blown away by how easy it is to use on a JVM stack.
T.J. Crowder
Another useful link re Rhino support: http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1
T.J. Crowder
@TJ Yes Rhino is pretty cool, but the bridge to Java is actually kind-of clumsy (numbers, for example); my personal preference is Clojure, which is a little weird because it's Lisp but once you get used to it it's really, really awesome. I don't get to use it as much as I'd like, or even often enough to make it possible for me to read old code I've written :-)
Pointy
@Pointy: That's interesting, I didn't find it clumsy at all in what I've done so far, but that's not been a huge amount. I have a project coming where this will be the infrastructure, I'll keep an eye out, thanks.
T.J. Crowder
@TJ Yes it's not bad but once you start doing real stuff things can get messy - what we did was write a sort of mini-framework so that code in the Javascript domain could get at the rest of the Java stuff via some Javascript tools "injected" into the environment (debug logging, audit logging, persistence services, etc) and that made it OK
Pointy
A: 

I spoke to the Google team at Google I/O and native JavaScript on the server side is not on their near-term roadmap.

peritus
A: 

You might want to check out:

http://www.appenginejs.org/

I believe the short answer to direct JavaScript support by Google Apps Engine would be no.

sirhc