Do you remember being really impressed by the initial Aves game engine that uses Canvas and HTML5 technology to deliver a compelling social gaming platform on Web technology? Well, now the Dextrose crew are back in action having released their second prototype of their upcoming browser-game middleware at E3 2010 in Los Angeles:
The new prototype is shown live to interested licensees and magazine editors on the exhibition floor. Additionally, a video with six minutes of in-game footage has been released on YouTube. Compared to the medieval-styled prototype from some weeks ago, Dextrose introduces even more innovation and performance boosts not yet seen in the browsergames industry.
unbelievable performance in the browser: Aves Engine renders hundreds of players in realtime in one viewport
introduces innovative Action Surface-Technology which allows the integration of any Web 2.0 or custom widget into your game
high-scalable viewports to any screen resolution size with nearly no performance impact
very large optimizations towards the mobile market. Technical stunning games now possible on WebKit-based Smartphones and iPad
a refurbished and extended realtime world editor
sprite animation classes
I had a chance to play with the prototype, and man was it nice. The iPad is fairly underpowered when it comes to intensive tasks like this, and it works very well indeed. The team had to spend a lot of time optimizing the engine for that form factor, and they are now in good steed for other mobile devices.
Moving around the world with iPad and laptops alike showed how well the UI keeps up with goings-on. This is because good old Mr. NodeJS is behind the scenes scaling up nicely for the crew. The multiplayer engine is smart enough to gracefully failback from WebSockets to long polling to standard boring polling that the iPad requires. All seamless to the programmer. The developer just gets to riff on top of the simple to hack on game engine.
Since the engine is built on the Web, the team could create Web surfaces with ease. This enables you to create mashups of content to embed directly into the game. Walk up to a laptop monitor in the game and see that it has a real browser window embedded and play with it. The world is truly your oyster with this engine.
If you are interested in building up a large player world, and want to get across a myriad of devices thanks to the Web platform, look this up to give it a roll.
Tim Caswell has been doing awesome work, and his latest project is Connect, a high performance middleware framework for node.js. Ruby has Rack. Python has WSGI. Java has Servlets. Now, JavaScript has Node/Connect.
I was able to set it up in minutes and took the following screencast of a sample application in action:
Take a peak at the examples as they show you how easy it is to rack up the middleware. In the Raphael circle multi-touch collaborative dragging example shown, you get a nice set of filters:
This is sure to be the first of many chaps putting their hat in the ring. With Ryan Dahl himself at Joyent, you would be shocked if we didn't have a nice marriage of the Joyent SMART platform and Node.js.
I signed up for the beta and would love to give it a whirl and report back.
In other node.js news:
fanout.js is a simple and robust fanout pubsub messaging server for node.js by @jazzychad
Alexander Fritze has been working on some very interesting developments. We have talked about his Stratified JavaScript library in the past, and he has brought his model to the server with with Oni Rocket. He tells us more:
Earlier this year I teamed up with my ex-Joost colleague Tom Germeau to found Oni Labs (http://www.onilabs.com/), where we are pursuing the 'stratified' idea to build a complete platform for developing web apps.
Our product, "Oni Rocket", is an asynchronous web server similar to nodejs but programmable in the callback-less 'stratified' way enabled by SJS. Like nodejs, we use Google's V8 under the hood.
On top of the server we run the "Rocket Framework", which provides things like the CommonJS module system on both client and server and enables seamless bidirectional SJS calls between client and server. Among the modules is "Oni Surface", a small UI toolkit for cross-platform box layout a la Flex or XUL, but of course everything is also fully compatible with existing JS libraries and UI frameworks.
The current plan is to make a first release of Rocket sometime this summer, and at the moment it looks like we're pretty much on track.
Having the DOM available is important as it allows you to do interesting things. You can take the same code and render on either client OR server side. NoScript turned on? Still works.
Aptana Jaxer pioneered this (running on a headless Firefox, giving them ALL of the APIs of a browser.... including XUL etc). This time around we are on node, with jsdom++:
To support this work, I’ve created a new YUI 3 module called nodejs-dom. This module will include the proper libraries, if available, and set up the YUI instance with a document and window reference. Along with the configuration, it will create a new object on the instance called Browser. Since all YUI 3 module use Node and Node uses Y.config.doc, you shouldn’t need to do anything else to make YUI 3 code work on the server. But if you’re working with older JavaScript and need to access the document, window, location or navigator objects, they’re all available on the Browser object.
Try an example such as this calendar. View source, and it is just HTML. In practice some logic could detect behaviour and enable client side in some situations, server side in others.
Oh, and YUI3 is looking really nice these days. A nice balance between a nice API + really nice looking widgets + a crockfords-worth of security care.
if("WebSocket"in window){ var ws = new WebSocket("ws://example.com/service");
ws.onopen = function(){ // Web Socket is connected. You can send data by send() method.
ws.send("message to send"); .... };
ws.onmessage = function(evt){var received_msg = evt.data; ... };
ws.onclose = function(){// websocket is closed. }; }else{ // the browser doesn't support WebSocket. }
Although I curse at the weak support on Chrome Mac (coming by end of week though!), other Chromers can use the new beta extension system pioneered by the awesome Aaron Boodman and team:
Today, we're really happy to release a beta of extensions that begins to deliver on our initial vision. Extensions are as easy to create as webpages. Users can install and uninstall them quickly without restart, and extensions have a great polished look that fits in with Google Chrome's minimalist aesthetic. When developers upload an extension it is available to users immediately, with limited restrictions and manual reviews only in a few situations.
On the technical side, we've been able to use Google Chrome's multiprocess architecture to help keep extensions stable and safe. And Chromium's extensive performance monitoring infrastructure has helped us ensure extensions affect Google Chrome's speed as little as possible. You can learn more details about the internals of our system in the videos below.
I missed the fact that in Chrome you can opt-in to a new process from a link. This is important as every tab is NOT necessarily in its own process. People assume that is the case (a one to one mapping) but it isn't (and has interesting security implications):
In many cases, though, Google Chrome needs to keep pages from related tabs in the same process, since they may access each other's contents using JavaScript code. For example, clicking links that open in a new window will generally cause the new and old pages to share a process.
In practice, web developers may find situations where they would like links to other pages to open in a separate process. As one example, links from messages in your webmail client would be nice to isolate from the webmail client itself. This is easy to achieve now, thanks to new support in WebKit for HTML5's "noreferrer" link relation.
Node’s core APIs are pretty low level—it has HTTP client and server libraries, DNS handling, asynchronous file I/O etc, but it doesn’t give you much in the way of high level web framework APIs. Unsurprisingly, this has lead to a cambrian explosion of lightweight web frameworks based on top of Node—the projects using node page lists a bunch of them. Rolling a framework is a great way of learning a low-level API, so I’ve thrown together my own—djangode—which brings Django’s regex-based URL handling to Node along with a few handy utility functions.
Pretty simple, and gets a whole lot more interesting when he shows how to build a simple Comet server with this API. He also covers database access, where there's a good fit between server-side Javascript and the NOSQL servers that speak HTTP and JSON.
His article also provides a nice overview of Node itself, along with some straightforward install instructions.
At first glance, Node looks like yet another take on the idea of server-side JavaScript, but it’s a lot more interesting than that. It builds on JavaScript’s excellent support for event-based programming and uses it to create something that truly plays to the strengths of the language.
Node describes itself as “evented I/O for V8 javascript”. It’s a toolkit for writing extremely high performance non-blocking event driven network servers in JavaScript. Think similar to Twisted or EventMachine but for JavaScript instead of Python or Ruby.
Simon Willison snuck in a last-minute topic change, and is now going to give the server-side Javascript talk.
The news of the past 24 hours is ChromeOS. For the first time in years, someone's re-thinking how an OS should work. With Chrome, you turn on your computer and you're in the browser. What's really interesting is to contrast it to the introduction of the iPhone, where Apple's apps used native APIs while they expected developers to write web apps running in the browser with limited abilities. Here, Google's apps are using the same web platform...it's a level playing field.
Javascript combined with JSONP makes it real easy to write quick and dirty apps. An example of a quick app is Tweetersation Simon wrote with Natalie Downe. Simple app, 200 lines, written in an afternoon. At a larger system level, there's Google Moderator, which is essentially a pure-Javascript solution with a no-op in the noscript tag.
These pure Javascript apps are great for experimenting and prototyping. The problem with this style of development, though, is you're completely breaking web standards. The web Simon "felll in love with" is one where you point to a URL and you get content coming back.
With server-side Javascript, we can get the benefits of the things we like about Javascript, but without throwing away with the things we like about the web. Simon has been playing with node.js, and evidently the results were important enough to throw out the old talk and make this new one.
Take a step back and look at the interaction patterns with a web server. The conventional model is straightforward request-response, where the server tries to respond and disconnect as quickly as possible. But ... there's also the event loop model. As in Comet; it's generally considered to be more efficient, so why do web developers avoid it? Simon says traditional server-side languages aren't designed to deal with event-driven programming. It's more like "do A, do B, do C, exit". Javascript, on the other hand, is well suited to do callback-driven event programming.
Brave Simon now proceeds to live code with node.js. He shows a "Hello World" daemon, where the code looks like Ajax in reverse, and runs extremely fast. But where it gets really interesting - and useful - is with Comet. Another demo. The code is tiny and the benchmark looks good.
Simon's built his own framework on top of node.js: Djangode takes the best features from Django and sticks them on the server.
var dj = require('./djangode');
dj.serve(dj.makeApp([ ['^/$', function(req, res){ dj.respond(res, '<h1>Homepage</h1>'); }], ['^/other$', function(req, res){
dj.respond(res, '<h1>Other page</h1>'); }], ['^/page/(\\d+)$', function(req, res, page){
dj.respond(res, '<h1>Page ' + page + '</h1>'); }] ]), 8008); // Serves on port 8008
The more interesting example is Comet, which he's demo'd here.
Moving on to persistence, there's the NOSQL trend of the past 18 months, and he shows how simple it is to write CouchDB queries from node. It's easy to talk to CouchDB from Node.js apps. Redis is another interesting database, which could lead to pages being rendered very quickly, given its performance benchmarks.
Posted by Michael Mahemoff at 12:41 pmComments Off
2009 was a solid year. Progress was made in the depth and breadth of the platform as we saw:
Browsers
The IE6 frustration is far from gone, but the tide is moving and we now see fantastic browsers with decent share. We may get Firefox 4, Safari 5, Chrome 73 (they like to bump versions quickly don't they) and even IE 9 if we are lucky. All with rich standards support, fantastic performance that goes beyond the JS runtime to areas such as the DOM, network layer, and GPU acceleration throughout.
Folks got excited to hear Microsoft talking about Canvas, but it was limited. IE with Canvas support will be fantastic and we hope it happens. Silverlight team.... turn around and let the IE team do their thing.
Developer Tools
Firebug has done well for us, but we need more. This year we got a lot of great new tools. From fantastic add-ons to Firebug itself, to WebKit Inspector improvements, to Chrome developer tools. We finally get the ability to look at memory (in Chrome and Firefox) and the black box is broken. To top it off we get Speed Tracer which I expect to see supported in more than Chrome in 2010 (already in WebKit, and I wouldn't be surprised if it was working in IE).
Ubiquitous JavaScript
JavaScript is going everywhere. With efforts such as CommonJS we saw the server side JS community come together to make sure that we don't have 15 File APIs! Narwhal and Jack are doing well, but we then saw the explosion of the awesome node.js for event I/O. A community has grown around Node, and I expect 2010 to push hard in this area.
Mobile
How could I not mention mobile? There are more mobile SDKs than I have had hot dinners, yet many of the smart phones have something in common.... a Web stack. 2010 will push hard here too, and will be a turning point for the Web. It is our contention (which is why Ben and I are at Palm) that the Web can be a unifying platform for devices and platforms. As a consumer it is fun to think about all of the devices in the near future. I want my watch, my glasses, my mobile device, [insert every other device] to be connected... but how, as developers, are we going to program all of these? The Web has a way to go .... but a huge community with large companies are pushing hard, and I think that we will soon look down and say "oh wait, this is actually an awesome platform!"
"HTML5" may not fully be here in 2010, but it will be a lot closer and we will have many more APIs that we can start using as they are implemented by browsers. WebSockets. Canvas 3D. Keep it coming!
What are you excited for in 2010? The date feels futuristic, so we have to make that a reality. Above all of course, I hope you all had a great 2009, and look forward to a passionate, enjoyable, rewarding 2010. Cheers.
