A+ Ajax

Shim was developed within the Boston Globe’s media lab as a way to study how Web sites look on various devices and browsers. A laptop intercepts all wifi traffic – this is redirected to a custom node.js server – which inserts a javascript, or “shim,” at the head of each web page that is visited.

The shim, once loaded in a device’s browser, opens and maintains a socket connection to the server, according to to Shim’s developers. Shim was written in 2011 by Chris Marstall, Creative Technologist at the Boston Globe. The software has been open sourced. Write the Shim originators on git.hub:

Whenever a new page is requested, the page’s URL is broadcast to all connected browsers, which then redirect themselves to that URL, keeping all devices in sync. Shim info is available on git.hub.

Continue reading »

pushState is a nifty way to manipulate browser history state without having to mess with the #hash value. You can use this to change the full path portion of the URL:

This would change the URL bar to http://example.com/bar.html without forcing the page to reload, allowing full JavaScript applications on the client-side. This is supported in Firefox 4, Safari, and Chrome.

Ben Nolan has been doing some interesting work exploring using pushState + JQuery but on the server-side using node.js in order to get the advantages of pushState while still being search-engine and accessibility friendly:

The number one downfall of javascript apps, is that there are now pages in your app that can’t be linked to – nor can they be crawled by google, or scraped by any other site that uses the http protocol. Building exciting new apps that ‘break the internet’ isn’t cool.

But if you can run your entire app on the server side – then if someone goes to http://yourapp.com/search/myterms – node.js can load your page on the server, recognize the url, run the correct javascript code to update the state as the browser would – then send it down the wire. So that non-javascript clients can access the same content that a desktop browser can.

Continue reading »

By Dion Almaer
webOS 2.0 SDK has just launched, and it has node.js built in (and more). The following is taken from my personal blog

At our last Palm Developer Day, Ben and I discussed future APIs for webOS including “JavaScript services” as a way to write code that runs on the other side of the device service bus using JavaScript.

If you think about it, node delivers a services platform for the cloud, so is there a way that we could work together? We got together with Ryan Dahl of Node to try this out, and it turns out that node works fantastically well on a mobile device! Major kudos should go to the V8 team for creating a great VM and to Ryan for writing efficient code that scaled down from the cloud to the device.

Today we announce that node is part of webOS 2.0:

The popular Node.js runtime environment is built into webOS 2.0, which means that you can now develop not just webOS apps but also services in JavaScript. The active Node ecosystem is on hand to provide community support and a rapidly growing library of modules that you can use in your webOS services.

Besides powering the new Synergy APIs, JavaScript services strengthen webOS’s support for background processing and add new capabilities—like low-level networking, file system access, and binary data processing—to the web technology stack.

I am really excited about this move for us. The node community is top class. I get to see this time and time again, most recently over the weekend and this week as I judge the node knockout. There is magic in the air with Node. It feels like the Rails days. I remember being so happy to jump to Rails and get away from the heavy world of Enterprise Java. It was a breath of fresh air to not have to argue with folks about every piece of the stack. “What about JSF with HiveMind and Commons-Logging and ….” Argh! Too. Much. Choice. And, a logging abstraction above Log4J was hilarious :)

Node is low level, yet simple. It is more like Sinatra than Rails. The event-based opinions keep you in good stead, and with cloud solutions such as Heroku and no.de you have great deployment stories, unlike Rails back in the day.

If you check out the modules that are growing daily, and the fun real-time hacks from the knockout you will get a good feel for node.

It feels great to have webOS as the first mobile device that embeds node. With db8 we offer a JSON store than can sync to the cloud (e.g. sync with CouchDB). This stack is starting to look pretty great.

Continue reading »

Heroku is known for its impressive Rails hosting, but on the heals of a post on how they decide their roadmap we see announced support for node.js in private beta.

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:

• Fancy building on a a trivial HTTP proxy server in node?
• How about Web Workers in node.js thanks to Malte Ubl himself
• Speaking of which, the latest Joose has node and CommonJS support

Continue reading »

Saikat Chakrabarti of Mockingbird is looking to make the tool collaborative. Along the way he wanted to test out tools to make this happen, and one test ended up with a collaborative drawing program using Node.js with WebSocket support from Socket.IO:

, the actual interesting parts that are doing anything other than serving static files start with the line “var listener = io.listen…”. On the client-side, I made a very simple Objective-J class that wraps the Socket.IO client called SCSocket (located in client/SCSocket.j). It’s up to you to simply set a delegate on this class and implement any of four methods (see setDelegate: on SCSocket) to handle notifications from the backend. To send notifications to the Node server, simple call [[SCSocket sharedSocket] sendMessage:].

Check out the code on GitHub.

Continue reading »

Dav Glass did some cool work YUI and the server when he got it running on Node.js and then got the DOM working.

The DOM is important as it allows you to do something very interesting. 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.

Continue reading »

James Coglan has ported a Ruby/EventMachine Comet server to offer a new Node.js server on the Bayeux protocol. The project is Faye and you can check out the code on GitHub.

On the client side:

And the backend….

Nice!

Continue reading »