IssueTracker

Aptana Server ? Or something :)

[Comment deleted]

Wouldn't it be possible to use javascript just by going

print '<script> (script here) </script>'

so long as the ContentType header outputted is HTML?

[Comment deleted]

I'd be interested to hear about something like Aptana, but seems like print '<script>
(script here) </script>' should do all you need.

Please add server-side Java as a runtime for Google AppEngine.

Rhino (javascript on java) would be a great solution!

This issue is entirely about a javascript runtime on the server (if Aptana helps you
visualise that fair enough).

JavaScript is a lot better designed than PHP. Google could change the fate of
JavaScript and JavaScript developers by porting GAE to Rhino -- and it would rock!
Vote for Rhino!

+1 for Rhino on Rails
http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html

No need for something complex. Just a simple request/response processor would be fine. In fact, all Google
really needs to provide is a rough port of the python webapp framework (datastore, urlfetch, email, and some
templating support) and of course we can do the rest.

spidermonkey + env.js ( http://ejohn.org/blog/bringing-the-browser-to-the-server/ ) would suffice.

Add a full JVM and you automatically get Javascript support.

add support for phobos javascript framework (https://phobos.dev.java.net/) will be
perfect.

That will boost the future

@jchris: Agreed. Please just port the basic API's from python to Rhino and we'll do
the rest. RhoR is interesting, but not necessary.

Cheers,
PS

Jaxar, server side javascript with a full DOM

Someone could get into making PyPy work with GAE. That would solve a lot of language
requests ;)

http://codespeak.net/pypy/dist/pypy/lang/js/

I hope that I can use one language to develop web applicaton. Server side javascript
is good.

Yes add it, Like aptana but maybe using V8

Server side JavaScript would be great with a fast JIT (such as V8).

+1 for server-side javascript based on v8!
that's provide develop server and client on single language.

I just checked, Rhino is working fine on the new App Engine Java runtime. So unless
this is about some specific JS runtime I think the issue can be regarded as closed.

Of course, there's no native JS support for the various APIs yet, but it should be
straightforward to access the Java APIs, and we are determined to support native JS
APIs in Helma NG soon.

There truly would be NOTHING BETTER EVER!!!!

If you eventually support JS, please consider supporting a "native" toJSON() function for the models.

If you voted for this thread you may want to check out

http://claypooljs.com
http://github.com/thatcher/jquery-claypool-server
http://github.com/thatcher/rhino-for-webapps

they run fine in the dev server and i'm working on resolving some appengine issue
that seems unrelated to my code in production.

all run on env.js
http://github.com/thatcher/env-js

Best
Thatcher

I got my sample app running on appengine with jquery, envjs, and claypool.

http://jquery-claypool.appspot.com/

Best
Thatcher

You *can* create JavaScript web applications using GAE/Java.

Have a look here:

http://github.com/gmosx/nitro/tree/master
http://github.com/gmosx/appengine/tree/master
http://github.com/gmosx/blog-gae/tree/master

Server-side Javascript with V8, Google is leading the next web with websockets in
Chrome, now we need server-side javascript (V8) in GAE.

I'd like to have a node.js version of App Engine: http://nodejs.org/

I think jaxer would be great to see on GAE... but it might just be too much power for
the world to handle...

i guess javascript runs on user's mechine, but not on servers, just send the script to
users :)

We are asking for server side javascript support in equal footing with Java and
Python. Right now the only way I know to run JS in appengine is rhino (JS
interpreter/compiler implemented in Java).

node.js would be cool

V8 would rock!

Dont forget you can already run javascript on GAE with rhino.  Here is a project that
helps

http://rhino-for-webapps.appspot.com/

But you'll see if you look at how little code it took to create the little
rhino-for-webapp bridge, that you can even write your own.  Javascript is already on
GAE!  I do appreciate that folks would like a C engine like spidermonkey or V8 but
for those who want it today, it's already here!

Thatcher

rhino-for-webapp bridge - true - but that doesn't provide/have access to DOM like
Jaxer did :(

actually you can add env.rhino.js to provide DOM just like jaxer did.  Most of my
server side apps in GAE are written with jQuery which requires the DOM, the window
object, xmlhttprequest etc.

Its available here: http://github.com/thatcher/env-js

Whoa!  I thought env-js was just a way to fake a browser environment wile using jQuery (and other
frameworks) outside of the server.  By fake I mean it provided a stub environment with the standard browser
DOM global variables.

Is this an incorrect understanding?  I.e. does env-js actually mirror the browser's DOM completely while
running on the server?  Jaxer apparently did that .. in the sense you could perform DOM processing on either
side, and it would be reflected in the current browser view.

As I understand it, Aptana no longer supports jaxer, right?  Or at least their site does not mention it.

Actually Aptana was more like a dom was loaded on the server just like the browser,
the dom could then be manipulated with your favorite javascript library like jquery,
and finally you rendered it as the body of a html response.  So really Envjs provides
the same approach as Aptana when used in combination with something like
rhino-for-webapps, or other appengine javascript bridges.  Many folks have been
working on getting Envjs running on other platforms as well.

I'm not sure where jaxer support currently stands with Aptana.  It was ahead of its
time, but not by too much.  Hopefully it hasn't been abandoned.

Thatcher

So with EnvJS, is there a way you can start from some html document (like the browser
does)? And of course then alter the DOM by some javascript and return the output to
the client?

Maybe you could give us a small simple example.

-DotNetWise

node.js please!

Re: alonecomp (comment 43)

Sorry i didnt see this response. Sure here is an example that does just that:

http://rhino-for-webapps.appspot.com/examples/envjs/

Which is a very simple example of doing just that.

http://rhino-for-webapps.appspot.com/  covers more details, but in general I'll just
offer that right now I'm running much more complicated applications than this (see
for example the envjs website (just re-released)) at http://www.envjs.com/ even
backends to bigtable.  

I've also got a project which allows bigtable to be used as a json database like
couch db.  These are all also written in javascript and running on appengine (source
code here http://github.com/thatcher/bigtable-js )

http://bigtable-js.appspot.com/rest/
http://www.envjs.com/rest/

Basically, I'll repeat my main point though because what I'm trying to advocate is
not really my project which run on javascript in appengine, but the simple fact that
**javascript is already supported on appengine**.

Hope this helps.

Thatcher

A port of the Python API to JavaScript *is* available:

http://www.appenginejs.org

Seriously - Node.js !

Google's primary language, as a Web company, should be Javascript, over Java or Python.

Now that server-side Javascript is provided so well in Node, there's no excuse not to support it in GAE... !

:-)

Node.js-ers: doesn't Node.js work on GAE?  GAE supports Rhino.  Can't Rhino run Node.js?

   -- Owen

@ODensmore: Node.js is not a library but an actual runtime based on libev, V8 and a few other things. It's definitely not compatible with Rhino's runtime and certainly very hard to emulate at all on the JVM since much of what it does is hard (but probably not impossible) to optimize on the JVM to respectable levels (a byproduct of JVM design and some of the runtime libraries that deal with I/O).

Supporting Node.js as a native platform option on-par with Python and Java would be very exciting. Google is the natural choice to take the lead on hosting applications built with SSJS, and a good deal of the work is already done in the form of V8 and Node.js.

node.js appengine would be the hottest fastest greatest thing ever to happen to the planet.

no "+1 Me too!" please. Maybe node.js should be an explicit/seperate request. Till then: +1 for node.js.

my vote for node.js V8 on Google App Engine!!! Please Dear Google !!!!! :)

javascript everywhere!!

The way I see it a V8-powered JavaScript hits a sweet spot: Faster to run than Python and more terse, expressive and functional than Java. As most GAE apps are websites, JavaScript also reduces the impedance language miss-match as it will allow you to use one language for both client and server. I believe the per-request model of GAE would also be better suited for JavaScript opposed to the high start-up cost and long-running nature of Java.

I would weep with joy if node.js were supported on app engine.  I've tried all of the JVM based SSJS solutions (heck, I even wrote one myself on top of Rhino), but the solutions I tested paled in comparison to what would be possible if node.js ran on app engine.  Really does seem to be a match made in heaven!

server-side javascript really just makes a whole lot of sense for asynch. javascript web apps.

javascript + websockets saves bandwidth.

Speaking of sharing the code base in the server and browser:

Here is a project that shares the majority of code for both client and server implementations that demonstrates the beautiful power of architecture that makes progressive enhancement a primary architectural goal.

jquery-claypool runs this site in google appengine when you disable javascript in your browser.
jquery-claypool runs this site in your browser when you enable javascript in your browser (gae serves the app to you).
+ it looks like a native app in the iphone and andriod (blackberry coming soon)

The architectural patterns are the only big idea, and javascript is the only language that run in both places.

webite: http://www.recordsofexistence.com/
source: http://github.com/thatcher/recordsofexistence/

you wont have access to all admin features, but forms work as well for admin data management assuming you had access.

I still believe the Web is alive and well and think it's digging trenching in browser javascript that runs 'anywhere'.

Thatcher

I'd like to see Node.js on GAE also. I think it's the very best implementation of server-side JavaScript.

I'd like to see Node.js on GAE also. I think it's the very best implementation of server-side JavaScript.

Even though node.js is open source, it's creator now works for joyent, who use it for their Smart system.  It may be the reason Google is not using it.

Another is Google itself.  If you've attended a Google I/O, you'll know that each project is independent of the others.  Indeed they seemed to be confused as to why I should ask how they coordinate with each other! And they have had several projects that looked at the start fail recently: Wave is a good example, and Groups, although not dead, is morphing and pushing its users to use Pages and other parts of the Google ecology.

So I think it likely that the GAE folks simply do not understand JS as well as many other projects within Google, and I doubt they have heard of node.js at all.

This issue really should be renamed "Please add Node.js" rather than "Please add Javascript".  While you can use Rhino to do Javascript-language programming on the JVM, it's missing the key element of a JS-based GAE:

 * A JS-friendly asynchronous interface to all GAE services

GAE's backend seems to all be based on asynchronous rpc technology, but the Java and Python APIs both focus on synchronous operation.*  A Node.js system should include a new, 100% async API to all GAE services.  This is where a great deal of the value of a Javascript system would come from.

Node.js is really a perfect fit for the GAE platform.  Like the JVM, the JS environment is also becoming a platform for new language development - CoffeeScript, Joose3, and of course GWT all build down to JS.  As a single-threaded fully asynchronous platform, Node.js would make *very* efficient use of GAE's shared resources.

Normally I think the "Add language X!" issues are a joke; for example, native PHP wouldn't really bring anything to the table that Quercus PHP on the JVM doesn't already do.  However, an asynchronous javascript system based on Node.js really would be something new and bring much more value than just running Javascript on Rhino.

* Yes, there are async interfaces to *some* of the services, but not all.  And the ones that exist aren't JS-friendly.

I'd be interested in seeing node.js on appengine.

[Comment deleted]

"This issue really should be renamed "Please add Node.js" rather than "Please add Javascript"."

actually, I'd like to see env.js too.

Node.js would open up a whole new developer base to GAE, myself included.

With Crankshaft V8 outperforms Python and Ruby. And V8' RegEx engine outperforms even C and C++ code!

http://blog.chromium.org/2010/12/new-crankshaft-for-v8.html
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=gcc

node.js should theoretically allow me to develop several layers of service, In which case I could provide functionally via Chrome web store (JS) if the browser supports this, and then I not I could use back-end (node.js) for the functionality. Being able to run the same code on client side or server side is the holy grail of productivity.

Seems like it would be pretty easy to scale on GAE...just give us one thread!

[Comment deleted]

i am a gae developer since day one.
its really fun and we enjoy.

would love to have javascript, node.js on gae.

please

I'm a huge fan of google app engine and mostly play with Java. I also like Javascript and recently started playing with node.js. It would be great to have node.js support from thw owner of V8 and a great supporter of Javascript , Google.... add it please..

nodejs + google app engine = develop web app with pleasure

Google not having a JavaScript version of the GAE API is like peanut butter and no jelly, Kanye West without fishsticks, Redbull missing the vodka...you get the idea...

[Comment deleted]

onyxraven, I don't know where you  get that hint.

No, we are not currently working on a native JS runtime, and there are no current plans to do so.

[Comment deleted]

Hey, project member ikai, you might want to reconsider. When Heroku finalizes their Node.js support (http://blog.heroku.com/archives/2010/4/28/node_js_support_experimental/), I will begin to ask myself: "Why am I f'ing with Python and Django when I can just write in one language on the front and backend..."

From a product stance, this is a no brainer, though I must admit, I am not sure what technical limitations there are inherent to App Engine's architecture that might inhibit Node.js support.

 i...@google.com: Just to make sure -- are you saying that a javascript framework on appengine, node.js in particular, will not happen, at least for quite a while?

This is quite important for our group (http://sfcomplex.org), so it would help us a lot to know we should not wait for an AE JS framework.  We have used it in the past for a prototype in UK for green energy monitoring, and it worked well.  But we are fine with other solutions.

As others have said, we cannot expect our young engineers to use one language for the server, another for the browser, and a non-native communication pipe.  For us, SSJS, Browser/Desktop JS, and JSON is just too much a Good Thing to pass up.

So we'll pass on AE, as nice as it is, and move on, likely to Joyent.

Thanks for the info .. no worries about not supporting JS I really understand your business decisions are your own and unique.

   -- Owen

[Comment deleted]

Writing in the same language on both the front and back end is THE holy grail for anyone with a pulse who doesn't still code in Classic ASP or COBOL. JavaScript is a unique candidate for fulfilling this long-held desire because it is a standardized language that is already supported in all browsers.

For any of the Googlers on this thread, mark these words: You will be leaving huge market/mind share on the table going forward if you don't support an official JS API on GAE. If you want to advance the expansion and democratization of development on the open web, this would be one of the most significant ways to do so. Period.

- Daniel

PM, Firefox Add-ons Team

Rhino has run on JavaScript for some time now:

http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=rhino+javascript+app+engine

I'd love to say that we're working on it, but we're honestly not. At least not in a timeframe that any product team should block on. I suspect, however, that you're looking to run node.js, which invalidates the argument that you want JavaScript and not a specific JavaScript VM. For the record, I love JavaScript. My team lead worked on one of the first SSJS implementations at Netscape. We have team members who used to work on AppJet and are considering porting Etherpad to App Engine using Rhino on App Engine as their 20% project.

Daniel, I think JavaScript is important, but your statements about the democratization of the open web really do take it too far, especially since Rhino will work on App Engine.

And now - in the spirit of my comments on the PHP thread, I'm going to stop commenting on this thread until things change and we *do* plan on supporting a native JavaScript runtime such as V8 on App Engine. I've learned my lesson from that thread that anything I say seems to be interpreted as flamebait instead of a honest-to-goodness "this is how it is".

Well said, I've been biting my tongue for ages on this particular thread.  I
would definitely encourage anyone who is thinking about commenting on this
post to at least read back through the comments, see  comment 46 for
instance regarding appenginejs (http://www.appenginejs.org) and from my own
investigation's I can confirm that ringojs (http://ringojs.org/) offers some
great support for AppEngine right now:

https://github.com/ringo/ringojs/tree/master/apps/appengine

I'll write a blog post on how to make it all work at some stage, but it
really isn't that hard.

Please stop commenting on this thread which is "please add Javascript" when
really what you want is node.js and a V8 runtime.  Scalable server side
Javascript on AppEngine is available now, so get out and try it.

I know about Rhino on AE, I know about appenginejs.org, and I know a few other hacked together solutions. For the record I am not resigned to Node, though it runs on V8 (your js engine...) and has a huge community that is expanding at a rapid clip.

As far as this is concerned - "your statements about the democratization of the open web really do take it too far" - I really don't think so, here's why:

First - Your proposed solution, Rhino, is run on Java. The second, nay, the very instant, you force a single install step, code requirement, or barrier that requires interaction with a language other than JS, you lose a large portion of the potential ***client-side only*** developer audience. This demographic is composed of literally millions of people who would probably take a crack at developing server-side if it was really a click-and-code proposition. I define true democratization of the back end as a state in which I can create app using nothing but an open web technology stack.

Second - The most recent release of Rhino was nearly 2 years ago. When compared with the stability and assurance of an officially supported AE language SDK, suggesting an implementation that was last updated 2 years ago seems like a second-class citizen proposal.

Third - If you think that Rhino is the best solution, that it is so easy to install, use, and support on App Engine, why doesn't the AE team create a JavaScript SDK that has Rhino at its core and include the necessary wrapping? If you answer no to that, I sure would be confused as to why, after all, that was the solution ***you*** suggested...unless it isn't so easy, isn't so trivial, and isn't so stable that you'd consider supporting it officially. Hmm just something to think about.

- Daniel

Ikai,

Thanks for jumping on and clarify the state of JavaScript on App Engine. I've been following this thread forever and appreciate your comments.

- @dshaw

I just read what damon.oehlman wrote, didn't see it at first. I would caution against the assumption that what I, and others, are asking for, is "node.js and a V8 runtime".

What these people would be fine with, is an official language SDK wherein JS is all that is used.

I, and probably others, could care less if a supported JS SDK runs Node, Rhino, Ringo, Narwhal, Pegasus, or Unicorn. Hell, you can say it is powered by pixie dust for all I care, as long as in the left column of this page - http://code.google.com/appengine/docs/ - there is "JavaScript" under Python and all the same methods are documented.

That's my last try, please give us something official like a referee with a whistle!

Dear Google, please, please add node.js

Google Web Toolkit provides a way to write client side applications and communication with the server via RPC or RequestFactories.

On the other hand, writing server side Javascript with something like Node.JS is quite a pleasure. It appears natural for Google to support something like Node instead of writing something else entirely. Why? Well, why reinvent the wheel? Contribute to the OSS world.

Anyway, GWT does this already with the help of Java on the backend..

Thx ODensmore (Comment #62) for the Joynet advice and specifically https://no.de. It's the solution I was looking for: SSJS powered by the world's fastest JS VM — the V8! Performance is a major issue that speak against Java-based JS implementations like Rhino or RingoJS. I've got dozens of TimeExceded Exceptions trying to run Grails/Groovy on GAE although Groovy is a well-implemented dynamically-typed Java VM language whereas Rhino and RingoJS aren't.

And V8' RegExp implementation outperforms even C/C++ RegExp implementations http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=gpp ...because V8' RegExp was probably written in Assembler.

I would love to see a V8 JS runtime, but I'm nothing if not practical.  Node isn't going to work because its asynchronous programming paradigm doesn't mesh with App Engine's synchronous request and response nature.

Adding a new runtime doesn't allow you to do things that were previously impossible.  It lets you do the same things in a different language.  I would much, much rather see the App Engine team's resources put towards making GAE more stable and more performant as well as adding truly new capabilities.

If you really want to give us a present, add some full-time staff dedicated to working with the alternate JVM language implementers (I know you've done some of this already).  Rhino seems to be getting a kick-start.  Hannes (creator of Ringo) just created a new Rhino mailing list (https://groups.google.com/forum/#!forum/mozilla-rhino) and they're trying to figure out what needs doing.

JayDevFollower said: "Node isn't going to work because its asynchronous programming paradigm doesn't mesh with App Engine's synchronous request and response nature."

That's exactly why I would like to see Node in particular on AppEngine.  I agree with other comments that JavaScript is already available via Rhino, however that doesn't help you write asynchronous long-polling type apps.

A language runtime on AppEngine is just a layer on top of existing infrastructure with APIs into that infrastructure.  In order to support asynchronous long-polling type apps, AppEngine would require a huge reworking of a paradigm (synchronously returning web request handlers) that Google has optimized for and built all of the GAE APIs to work with.

There's nothing wrong with wanting this, but expecting or demanding such a shift is impractical at best.  Trying to square-peg-round-hole Node apps into AppEngine would result in your app being a muddied puddle of code designed for asynchronicity that just ends up being a series of synchronous function calls.  Asking for true NodeJS-style applications would be a LOT more work than just implementing a Node VM.

Don't get me wrong, I'd LOVE a V8 runtime.  It's just not practical on GAE and I'd rather Google put their efforts into making things that aren't currently possible possible.  In the meantime, I'll keep slugging along with Ringo/Rhino/AppengineJS, because it does work, it is easy to use, and Javascript rocks.

I'm staring a new thread here: http://code.google.com/p/googleappengine/issues/detail?id=4345

I believe the title and comments allowed for too much deviation. What we need is a JS SDK that covers the same methods and functionality as the Java and Python ones do. That is the heart of the request. If Node.js is not compatible with AE's architecture, then guess what: I understand Google's position, do we really expect them to rewire AE for a super specific implementation? Obviously not.

The goal should be to have an equivalent JS SDK on par with the Java and Python SDK variants. As long as it's official, and you write your apps in JS, I'm fine with it - who's with me?

Even without long-polling, GAE's underlying services and protocols are asynchronous and would seem to be a very good fit with javascript and Node.js.  The main problem I see is that this would require Google to come up with (and document) a whole new API.  Without a significant expansion of the team this doesn't seem likely.

A nice async javascripty interface would actually be pretty useful on the Java side too - right now there's no mechanism to do the equivalent of:

datastore.get(key, function(thing) {
    ...process thing....
});

...or in javaland:

datastore.get(key, new Result<Thing>() {
    public void result(Thing t) {
        ...process thing...
    }
});

danieljb2 sez: The goal should be to have an equivalent JS SDK on par with the Java and Python SDK variants. As long as it's official, and you write your apps in JS, I'm fine with it - who's with me?

I see your point, but I'd require one thing: that the SSJS .. or JS in general .. solution be available on any hosting system, not just GAE.  I don't want to paint myself into a corner.  And remember, GAE does have both limitations placed on "standard" platforms and google-only APIs.  Be very careful not to have a system that is not available on other hosting systems.

But, yes, I agree that node.js is not required for a nifty JS-Everywhere solution.

I'm hearing that GAE's underlying services and protocols do not fit the asynchronous requirements of V8 and node.js and that they do.  If it is in fact the latter, I wonder whether if it would be possible for a community driven node.js SDK.  I suppose GAE would still have to support V8 hosting and app initialization, etc.

[Comment deleted]

et's stay objective here, if you would like a JavaScript variant of the SDK, as there is for Python and Java, please star this ticket: http://code.google.com/p/googleappengine/issues/detail?id=4345.

I would ask that we keep the new thread free of suggestions of which specific SSJS stack the folks at Google should implement.

The whole point of creating another ticket was to frame the feature request correctly, as the current title is ambiguous, want proof? Here are a few of the "answers" to this request so far:

---

Comment 3 by davethew...@gmail.com, Apr 8, 2008

Wouldn't it be possible to use javascript just by going: print '<script> (script here) </script>', so long as the ContentType header outputted is HTML?

Comment 5 by kubasik.kevin, Apr 9, 2008

I'd be interested to hear about something like Aptana, but seems like print '<script>
(script here) </script>' should do all you need.

---

Can you change the title of this ticket please?

PS - I would love to hear a well reasoned answer at Google I/O when I ask this question in your Fireside Chat. Any answer that breaks down to "it's not something we're pursuing right now" implicitly means you believe Yahoo, Joyent, Heroku, Amazon EC2, Linode, Rackspace Cloud, Slicehost, Webbynode, WebFaction, no.de, etc are all just wasting their time.

Guess what? I just solved your Native Client team's distribution issues! Instead of fighting standards groups for the next 10 years on letting back-end code run in the browser, you can make it a reality right now! How you say?...Did you not hear the news? JavaScript is now a front and back end language, and it already runs in every browser on the planet, score, huge! Problem solved, Cha Ching, OK, that's all she wrote!

The title of this thread should be: "Add JavaScript as an officially supported SDK language"

You can use ApeJS: https://github.com/lmatteis/apejs/

@lmatteis

APE is a real-time push server, not a full-stack JavaScript language SDK for App Engine. I don't fault you for the input, mostly because the title of this thread is terrible - it makes people thing we want a way to get JavaScript to the client, when what is really being requested is version of the App Engine SDK in JavaScript on par with that of the Python and Java versions.

Please add server-side Java as a runtime for Google AppEngine.
It would be great to use only one scripting languaje to program both server and client code.

+1. I have tried Golang App Engine, IMHO is better than Java or Python, but definitively NodeJS is the best.
The implementations said above aren't native implementations of the AppEngine SDK, so don't expect the same speed.

#104 https://github.com/lmatteis/apejs/ != http://www.ape-project.org/

Microsoft is throwing money into NodeJS now to get a Windows port, wont it be embarrassing if Microsoft release a hosting solution for a product based on Google's Chrome browser and Google don't? It'll make me sad if I have to host on Micro$oft Azure because Google don't host NodeJS. (ToT)

[Comment deleted]

p...@mellmo.com, please keep it civil.

After more than 3 years of watching folks comment on this ticket with "answers" that are completely ignorant of the desired outcome, it might help if we remove the ambiguity of "Please add Javascript" and replace it with something that actually represents what is being requested: "Add an officially supported JavaScript runtime to the App Engine SDK"

[Comment deleted]

Updated the issue title.

Hooray!

[Comment deleted]

[Comment deleted]

It should be a great time to consider this after the Isolate and experimental GC enhancements landed in V8.

Microsoft has announced support for Node.JS in Azure, it seems almost certain that Node.JS is going to be bigger than Ben Hur now. Can the App Engine continue to compete without such an important language? Is there any movement on this yet at all?

Can we have hosted JavaScript, please? We don't need Eclipse.
Node.js is one of the best development products coming out of Google :)
The way you deploy and configure no.de is very smooth, the best I have seen. Build or buy?

Please add node.js!

Even MicroSoft is using node.js(powered by Google's V8 engine) on their cloud. What are you waiting for google??? We need node.js, we need websockets.. Come on Guys....

Issue #3745 specifically requests Node.JS support, should this issue be more specific and ask for Node given its rapid ascension to being the most popular JavaScript server? It would seem to make sense given this issue has 433 stars already and the new issue only has 73. Either that or will everyone on this list show support for the Node.JS request if they prefer Node, what do most people feel is the best approach to promote our needs to Google?

[Comment deleted]

[Comment deleted]

Server Side JavaScript is the future, no it's now. Doing it on Google's Rock Solid infrastructure would be a dream. Let's make it happen AppEngine Team!

Why is this still an issue while it's so obvious that nodejs fits really well in Googles strategie? Google IS the web, and javascript is everywhere (except on googles servers).

Why is Google ignoring the most revolutionary programming paradigms. It doesn't have to be Node.js and it doesn't have to async. Even a simple JavaScript runtime with full support for the Google service APIs would be a huge leaping start.

One language everywhere...it's a no-brainer! I'm just tired of switching between two languages all the time -- what a waste of brain resources!

if i could buy stars with money i would donate all my cigarette money to this issue :)

Is it possible to get an update from the Google team on this?

As a hobbyist developer the effort to learn multiple languages significantly raises the bar to entry. So having JavaScript in the client/browser and on the server would make my projects move forward much more quickly, and more likely to get finished which means more likely to get published and become paying apps that generate revenue for Google. No guarantee I'll raise your market capitalization beyond Apple's but I'll do my part - if I can! Thanks,

i want node! lol.. please and thank you

nodejs+express+angularjs that's what we wants.. thanks for considerations

Would love for AppEngine to support node.js I think it would round make a solid offering and potentially a great revenue maker as Node keeps garnering traction in the industry.

[Comment deleted]

Are you going to add Node.js support or not??

Considering how Nodejs itself interacts with the host OS, I doubt full Nodejs support is actually a viable option... Perhaps an API option to spawn a new instance of a Nodejs app, passing in an entire app init script would work.

In the mean time for anybody who's interested, there are quite a few interesting options listed in the answers here: http://stackoverflow.com/questions/3224341/server-side-javascript-on-google-app-engine

We're getting Dart before node? thats not right :(

If they just migrate to Java 8 with support for Nashorn Javascript engine then this will become a moot point.

has someone ever tried http://nodyn.io with GAE?

however i've voted up this post for official nodejs support on gae

This is currently supported using the custom runtime support in Managed VMs + the node.js runtime that is available at: https://github.com/GoogleCloudPlatform/appengine-nodejs

With the caveat that it runs on Managed VMs and not classic App Engine, JS is very well-supported: https://cloud.google.com/nodejs/

If there are specific use-cases which the Node.js solution does not deliver on, please open a feature request which goes into detail so we can track it separately.

That said, since Managed VMs are still in Beta, I'm leaving this issue marked "Started" and not "Fixed" for the time being.

I can see the sample uses 'runtime: nodejs' instead of 'custom'.

Does it mean nodejs will be one of the officially supported runtimes then?

Right now the documentation states: "Only two standard runtimes, Python and Go, are supported, the configuration is different for each."

I imagine once this leases beta the documentation will be updated right?

This looks awesome!

Can I deploy production code with runtime: nodejs already?

I see this feature says "Started".  Any estimated date of launch for NodeJS support?

Greetings folks!  This is available now on the App Engine Flexible environment.  You can learn more at https://cloud.google.com/nodejs/.

That's great, thanks Justin.

One question: At the bottom of the Quickstart guide (https://cloud.google.com/nodejs/getting-started/hello-world), it says "This package.json specifies that the application uses node 0.12.7", but there is no reference to any node version in package.json. How is the node version specified?

You can specify pretty much any version you want using the engines field in package.json:


https://cloud.google.com/appengine/docs/flexible/nodejs/runtime#engines

According to the documentation the flexible environment is in *beta*.

> This is a Beta release of the App Engine flexible environment. It is not covered by any SLA or deprecation policy and the implementation may change, possibly in backward-incompatible ways. It is not recommended for production use. [1]

Reply #145 held off marking this as fixed because the feature was in beta, now in #150 the feature is marked as fixed despite the beta status.

When can we use Nodejs in *production*, or is the documentation inaccurate and in need of an update?

[1] https://cloud.google.com/appengine/docs/flexible/nodejs/quickstart

Javascript using the Nodejs runtime is no longer in Beta.  This changed when the flexible environment in general went GA during Next '17.  As such, the platform now supports the Nodejs runtime[0].

For specific issues you may encounter with the runtime that you do not believe to be intended behavior, feel to file new issues on the Issue Tracker[1] using the component: Public Trackers > Cloud Platform > Compute > App Engine > Flexible.

[0]: https://cloud.google.com/nodejs/
[1]: https://issuetracker.google.com/issues/new