Yesterday, a post in Hackernews generated considerable interest on AppengineJS, my port of the App Engine Python SDK to JavaScript. The interest was so intense that managed to drain the free quota of the project's site. I guess 'slashdotting' (or should I call this 'newhacking') is the price to pay for the extra publicity.

Some interesting questions were asked in the comments section, so I would like to address some issues and clarify some points:

1. Why use JavaScript instead of Python on App Engine?

If you already know Python, stick to the Python SDK. If you don't want to learn Python and know JavaScript (every single web developer is at least familiar with JavaScript) give AppengineJS a try.

2. Why is JavaScript a great language?

Let the master answer this one:

The World's Most Misunderstood Programming Language
Crockford on JavaScript

Personally, after about 8 years of Ruby programming I don't regret switching to JavaScript. I love the prototypal inheritance, the object literal notation, closures, the C syntax, etc.

3. Why is JavaScript especially suited for Web Applications

Like it or not, JavaScript is the language of the Web just like C is the language of Unix.

The fact that JavaScript is the only language that runs natively on browsers allows you to reuse code across server and client side. And I don't mean just simple form validation code. I use the same template engine at both sides, I use jquery/sizzle at server side for web scraping, I use same jsgi-client code to send http requests at both sides, I use a Canvas-API compatible renderer to generate SVG at server side, I render ajax content at server side for search engine robots and more.

Working exclusively with JavaScript across your app, eliminates the mental context switch required by two separate languages. Oh, did I mention it's much easier to find JavaScript developers (than Python or Ruby developers) for your team?

4. Why does App Engine rock?

Platform as a service changes everything. Of course, App Engine may have the occasional outage or technical problem, but I really dig the fact that Google developers (not my team) are fixing the issue. Quite incredibly, App Engine eliminates the need for system administration, database tuning, security updates, secondary servers setup (email, xmpp, memcache, nginx/apache, squid, etc), etc. When I used Amazon EC2, I almost lost my data twice due to hardware problems on my virtual server. Even though the heroic efforts of the support team saved my ass, I still had to spend a night setting up a new virtual server. There are no servers to fail in App Engine, I love that!

5. Yeah, but isn't Datastore slow?

Datastore is not a relational database, it's a different beast altogether. You have to design your app form scratch with the Datastore in mind. Here are some useful links:

Mastering the datastore
Building Scalable, Complex Apps on App Engine

The Datastore may be slower than, say, MySQL for toy applications (but this can be mitigated through memcache) but the massively distributed, scalable architecture will pay dividends when (eventually) your data explodes.

6. Why not use NodeJS?

Well, NodeJS is a valid, if over hyped, solution. But it only helps you come up with a toy application. With 'toy' I mean an application that runs on your laptop or your staging server. For a production app you need deployment processes, multi version processes, system setup, server tuning, database scaling, backup processes, security policies, monitoring, profiling, admin console etc, etc. App Engine is the easiest way to go from toy to production (though Heroku-Node may provide a viable alternative).

Be open minded and give AppengineJS a try, you may like what you 'll see.

9 comments App Engine Programming JavaScript Technology