A few days ago, Joyent unveiled the public beta of their NodeJS-based platform-as-a-service contender. Well, this service rocks! From the great no.de domain name to the RESTful procurement/management API and the git-powered deployment, everything radiates coolness.
Even though I posted my hearts to the API end-point (/♥ !!), I haven't received any coupons in return. So there is no review for you. However, the elegant simplicity of the API (combined with the clean-slate design of the underlying NodeJS infrastructure) lights my geeky heart (pun intended).
I am not a NodeJS fan-boy. These days I am evaluating Java/GWT (so far I am positively surprised but I 'll reserve my final judgement for a future post). So, you understand, like everyone who feels overwhelmed by the complexity of the Java ecosystem, I can appreciate a refreshingly simple alternative.
Last year, Google released the Closure suite of tools for JavaScript development. It seemed too good to be true. A robust client-side JavaScript toolkit and UI framework was just what I missed in my stack.
I quickly downloaded the distribution and, like the rest of the world, was immediately disappointed: The source looked like Java, with long name spaces and getters/setters everywhere. The compiler looked interesting but difficult to setup and integrate in the build process. The templating engine looked ugly and required a compile step. I switched back to jQuery faster than you can say 'crap'.
The problem is I wasn't fond of jQuery either. It 's great for improving the interactivity of a page or adding special effects but leaves a lot to be desired when you are building a business-oriented Web application. As I am working on a series of Web applications for deployment through Google Apps Marketplace I decided to give Closure a second chance... more
AppengineJS is a port of the App Engine Python SDK to JavaScript. While we have taken great pains to closely emulate the Python APIs, given the fact that AppengineJS is actually powered by the App Engine Java SDK, it is difficult to emulate the directory structure of Python Web applications. The developer has to maintain a standard Servlet directory organization, with WEB-INF, web.xml, etc. That's a show-stopper for complexity-averse developers.
Not any more! The latest version of the Java SDK (1.3.5) introduces undocumented support for app.yaml, cron.yaml and the rest of the Python's SDK configuration files. The dev_appserver utility, automatically generates and maintains the WEB-INF directory from these configuration files, making simplified file organizations a reality.
I have updated the standard AppengineJS examples (appengine-example and appengine-blog-example) to demonstrate what is possible with app.yaml. I am sure you will find the updated examples much easier to understand. More information about app.yaml in the Java SDK can be found here.
During the initialization of a Web application, Nitro performs a scan of the src/root directory and constructs a sitemap. The Path middleware leverages this structure to intelligently split incoming request paths to the corresponding scriptName and pathInfo components.
The scriptName component is the path of the JSGI application that will handle the request. If the Render middleware is used, the template path is also derived from scriptName. The pathInfo component stores the extra postfix of the request. Let's use an example to demonstrate the concept:
Given the directory structure (sitemap):
/src/root/articles.js
/src/root/articles/view.js
Nitro automagically splits the request path:
/articles/12339
into:
scriptName: /articles
pathInfo: /12339
since /src/root/articles/12339.js does not exist.
We can use the pathInfo component to implement nice, RESTful URLs... more
Unless you 've been living in a cave for the last year, you know that server side (better: 'general purpose') JavaScript is all the rage. Everything started with CommonJS: the emerging standard spawned an ecosystem of compatible implementations competing against each other while advancing the JavaScript state of the art.
Then, NodeJS happened: An async only JavaScript platform, powered by V8, not really interested in CommonJS conformance. RY (the new DHH) managed to grab the attention of the developer community with cool marketing, leaving other implementations in the shadows. One such great implementation that deserves more attention is RingoJS.
Some time ago I switched from Narwhal to Ringo and never looked back. I strongly believe that Ringo is the preeminent CommonJS implementation. Here is why:
- Ringo is quite possibly the most conformant CommonJS implementation, certainly more conformant than Narwhal and Node.
- Ringo is *fast*. If you tried Narwhal/Rhino and found start up times lacking or module reloading unacceptably slow check out Ringo! You will be pleasantly surprised. And while v8 may be faster than Rhino, the JVM is still quite optimized for server side environments. (And btw, in a modern Web application, time spent running the server side script is a negligible percentage of the total request/response cycle. You should probably work on optimizing network issues, database interactions, client side rendering etc)
- Ringo is mature, stable and crash free. Ringo is the evolution of Helma, one of the first server side JavaScript platforms (more than 10 years in development). It's also based on the mature Java platform. Contrast this to reports of NodeJS crashes.
- Access to the gazillion of Java libraries. There is no merit in reinventing the wheel, just reuse code from the Java ecosystem. The integration between Java and JavaScript is seamless.
- Windows compatibility. OK, Windows sucks, but still, a lot of engineers use Windows as a development platform. Ringo apps work on Windows out of the box.
- Support for synchronous and asynchronous APIs. Use what's best for your application.
- Thanks to AppengineJS you can run your Ringo applications on Google's scalable infrastructure.
- The lead developer is extremely talented and friendly.
Stop drinking the Kool-Aid! Engineer your application on top of a mature, conformant and compatible platform: RingoJS.
Update: Removed a controversial link
As the lead (and lone) developer of an early Rails competitor, I am not particularly fond on DHH & Co. However, there is no denying that good ideas did emerge in the Rails ecosystem. One such idea is the use of inflection to replace configuration with convention.
Some time ago, I needed a simple code generator for one of my projects, thus I looked around for a JavaScript inflection library. After experimenting with a couple of ports of old ActiveSupport code, I decided to implement a subset of the latest ActiveSupport version and package it for CommonJS.
Download the JavaScript inflection library, and try some examples:
var pluralize = require("inflection").pluralize
pluralize("entry"); // "entries"
var singularize = require("inflection").singularize
singularize("words"); // "word"
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.
I read this post on Signal vs Noise with great interest. Ryan correctly identifies the problems with local variable declaration in Erb templates and offers a clever Ruby hack as a solution:
<% message.comments.last.tap do |comment| %>
<li><%= comment.creator %></li>
<% end %>
While .tap() introduces a scope it still smells as bad style. A more fundamental flaw lies underneath: the lack of true separation of data and presentation. Consider the following alternative using Normal Templates:
{:reduce comments}
<li>{=creator}</li>
{/:reduce}
or the equivalent shorter version: more
For some time now I was using a custom version of JSON-Template. I really like the simplicity of JSON-Template and the clean separation of data, logic and design. On the other hand I hate the syntax (repeated section, argh) and the 'cursor' paradigm employed has problems in practice.
In this vein, I designed a new template engine, called Normal Template. I consider this an evolution of JSON-Template concepts that works better in practice. Here are some benefits:
- Separate 'if' command (required in practice)
- Replaced {} interpolation with {=..}, safer in practice, more readable
- A subset of XPath is used to navigate the data dictionary along with a cursor model (select)
- Abbreviations for tags (s for select, r for reduce, etc)
- Meta templates and static includes
- Compiles to a javascript function for extra performance
- Improved syntax error checks and reporting
For more information, please consult the detailed docs. To wet your appetite, here is an example.. more
Old time readers of my blog know that I regularly change the platform that I use. Lately, I was using Google's Blogger, but I wasn't happy with the layout. Before that, I used a lovely, custom-made, Ruby-based CMS. But since I am fed up with Ruby (after 8 years, no less) it was difficult to maintain.
Therefore, I decided to utilise my AppengineJS and Nitro open source projects to create a new platform for my blog. This new version is implemented in JavaScript, the language of the Web, and one of the languages I dig these days (the other being Haskell). Even though I am relatively pleased with the result (and the clean code behind it), there is a lot of work to be done, when I find the time.
In the meantime, please subscribe to my feed and check this blog often for interesting content. Oh, and bug reports are always welcome ;-)
Update: This blog is not based on the blog-gae example source code. In fact, the blog-gae example is outdated and does not reflect the latest improvements in Nitro and AppengineJS. Perhaps, I will release the mini CMS behind this blog as an example if there is sufficient demand...
