App Engine JavaScript SDK

http://www.appenginejs.org/

by danh • 16 years ago

74 42 16 years ago

appenginejs.org

axiom4• 16 years ago

If you're thinking of using the App Engine read this first:

http://highscalability.com/blog/2010/5/26/end-to-end-perform...

koenbok• 16 years ago

But read it well. It seems AppEngine comes out very bad, but it was tested for db transaction speed in a way that every insert locks the entire db (one big entity group). Any AppEngine developer could tell you not to use it like this. More info: http://code.google.com/appengine/docs/python/datastore/keysa...

It would be very interesting to see what the results would be with some more realistic testing.

axiom4• 16 years ago

Well, maybe you're right, but I'll say the following:

1. Unless I'm missing something here the entity group thing is a red herring. Only if the authors of the paper explicitly setup all entities in the datastore as having the same root entity, then this would be an issue. However, since there isn't anything to suggest that they did this, all datastore entities are their own groups (and hence don't lock up the entire db,) so transactions on them would not have had any speed penalty. Please someone correct me if I'm wrong here.

2. Unfortunately their results are consistent with my experience over the last ~8 months running a startup on the App Engine (and now switching over to EC2 over the next few weeks.)

bad_user• 16 years ago

> Any AppEngine developer could tell you not to use it like this

I'd really wish for some AppEngine developer to tell me how's the proper way of designing entity groups. The only advice given is to not exceed a single user's data, otherwise it's too big.

Really, I want to see an example of a request handler that creates data in multiple entities and takes care to not create duplicates.

> It would be very interesting to see what the results would be with some more realistic testing.

IMHO, my experience with AppEngine's datastore has been pretty bad ... the performance varies greatly based on factors you can't control ... i.e. processing something that does well on slow Fridays, may throw the 30 secs timeout error on Mondays.

Also, I don't know how people deploy real-world apps on it ... a non-relational datastore requires custom indexes (i.e. precalculated queries done by building specialized entities out of your quasi-normalized data).

You can't do that easily because of the 30 secs limit that also applies to cron or queue jobs. I tried a workaround by having a queue task that processes 5 rows at a time and then reschedules itself. The stuff was so god-damn awful to debug, and the results so unpredictable (30 secs timeout for 5 rows / concurrency issues) that I felt like crying.

But yeah, it's fine for hosting a blog engine on top of it.

gmosx13• 16 years ago

You can't just port your application to App Engine. You have to start from scratch. Google enforces all the right constrains to force you to write scalable apps. The killer feature is that there is no need for system administration or maintenance. No need to setup dns rules to make your email go to the recipients, no need to update apache or linux, no need to setup an xmpp serrver, etc. Plus, you can leverage Google's battle tested infrastructure. The icing of the cake is that you can now use the internet programming language, ie JavaScript, while still having access to the vast collection of Java libraries. A match made in heaven if you ask me!

pmjordan3• 16 years ago

I'm always amazed at how popular Rhino is vs. how little active development effort it receives. I'm as guilty as anyone of course.

gmosx13• 16 years ago

Indeed, Rhino is such an important project but still it does not receive any attention.

boucher3• 16 years ago

It's unfortunate, but it's also the reason we wrote Narwhal, which now means we rarely need to use Rhino at all. A welcome change.

monos• 16 years ago

the thing about rhino is, that it already is a mature js implementation. it has the most modern js support of all the engines out there (the version shipping with java is sadly quiet old) and it's battle tested. we have it in production since 8+ years.

i can see how it might seem rhino has "little active development" because we are comparing it to js implementations that just started and of course have more "going on" then the old horse.

pmjordan3• 16 years ago

The general consensus seems to be that Rhino doesn't really exploit the performance potential of the JVM. Basically, it could probably be a lot faster.

gmosx13• 16 years ago

I would like to see support for "use strict" and some more aggressive optimizations. And hopefully, Java7 with support for invokedynamic will be released soon.

agentultra2• 16 years ago

Cool project. I'll never understand why anyone wants to program in JS though.

past2• 16 years ago

Besides being an incredibly powerful combination of a functional and an object-oriented language, I just adore the fast redeployment cycle during development. With appenginejs, I test every change in the backend code by simply refreshing my browser. Not jaw-droppping per se, but certainly a breath of fresh air for a long-time "enterprise" Java developer, like me.

sreque3• 16 years ago

Javascript's functional powers are equivalent to or worse than every other popular dynamic language in existence. Speaking of functions, I prefer not to do argument arity checking on every single function I write(I'm looking at you too, perl!), or accidentally assigning global variables through a simple misspelling. I also really hate it if I accidentally invoke a function on a primitive and it silenty fails by returning null. Use 'use strict', you say? How's the implementation of that feature coming these days? I know firefox still doesn't have it. Does v8 yet?

From what I've read, other Prototype-based languages treat Javascript as their ugly step cousin, and I would overall consider it a much inferior OO system to that found in Python, Ruby, CLOS, Perl's Moose, and PLT-Scheme, to name a few.

You can easily get rapid redeployment in any dynamic language. You can even get it on the JVM with Java, as the Play framework is showing us. See http://www.playframework.org/.

If Javascript is your first dynamic language after developing in Java for X years you might think it is neat, but it is really far behind just about every other language out there it directly competes with on the server-side level. It was never designed to be a scalable general purpose programming language and the latest incarnation is still far from reaching that lofty goal.

artlogic3• 16 years ago

I used to feel this way. The two people that changed my mind were John Resig and Douglas Crockford. Resig's jQuery project has been, for me, a guide to how JS should be written. Crockford's JS the Good Parts and JSLint have helped as well by providing some solid reference on what to do and, more importantly, what not to do.

Lots of folks only see the DOM and the bad parts when working with JS - these two projects have shown me there's so much more.

orangecat• 16 years ago

Lots of folks only see the DOM and the bad parts when working with JS

Agreed that you can't blame Javascript for the DOM, but there are lots of bad parts aside from that. Default global scope and semioptional semicolons are gigantic WTFs, the with statement should be nuked from orbit, and there are generally lots of ways to write code that appears to be correct but is just waiting to fail in bizarre ways. It's just annoying that we're stuck with Javascript because it's so entrenched, while Python and Ruby offer all of its strengths in much saner packages.

polgardy• 16 years ago

jQuery is a great project, but it's definitely NOT how JS should be written. Its goal is to be fast, unobtrusive, and work in most browsers at the expense of comprehensibility.

agentultra2• 16 years ago

Let me clarify: don't think JS is bad or anything. I just personally don't like it as a language.

With so many projects coming out using JS as the primary scripting language, I am probably going to have to suck it up and learn to love it methinks. Just not yet. ;)

gmosx13• 16 years ago

1. JS is a great language. 2. You can reuse code on the server and client side, no mental context-switch. 3. Javascript VM's are generally faster than Python VMS. 4. Rhino provides access to the vast collection of Java libraries 5. App Engine is the easiest way to go from a toy application to a industrial strength, production application

sreque3• 16 years ago

1. No it's not. It's mediocre at best. See my previous post.

2. No you can't, not anymore than you can reuse Java code between client and server with GWT. The difference between a browser and a client environment is just so great. NaCl will hopefully provide a way to bridge that gap, but that will work for every language, not just Javascript.

3. PyPy is starting to catch up to v8. This point is irrelevant for the AppEngine, by the way. I doubt Rhino is any faster than Jython.

4. Ever heard of Jython?

5. Ever heard of Jython?

Certain languages get way over-hyped on HN, and Javascript is one of them.

exit• 16 years ago

if you only dislike js syntax, check out coffee-script: http://jashkenas.github.com/coffee-script/

gmosx13• 16 years ago

In fact, the syntax is one of the things I prefer in JavaScript (vs for example Python), along with Prototypical inheritance...

AlexisT• 16 years ago

Great stuff!

gmosx13• 16 years ago

some more thoughts on appengineJS here: http://www.gmosx.com/blog/agVnbW9zeHIPCxIHQXJ0aWNsZRipwwEM/o...

App Engine JavaScript SDK

Related Stories