Badass JavaScript

Joyent Relaunches Its No.de Hosting Service

Last night, Joyent relaunched its awesome No.de hosting service.  Besides having a sweet domain name, the service looks to be a really simple way to host node apps in the cloud.  It uses Git for deployment kinda like Heroku, which makes that really simple.  No more FTP!  Additionally, they are now supporting the latest stable versions of Node, 0.4 and 0.4.1.

They also announced a Cloud Analytics service that lets you see all kinds of performance data about your live production servers running on the No.de hosting platform.  You can see information about HTTP server/client operations, garbage collection operations, socket operations and filesystem operations with beautiful live interactive charts.  Check out the blog post to learn more about that!  Behind the scenes of all of this is DTrace and the DTrace probes that were added in Node 0.4.x.  Very cool!

Node.js is really getting big.  Its exciting to see it develop, and to see the community create such awesome stuff with it!  If you’ve got a Node app to host, be sure to check out No.de!

Streamie.org - A Hackable, Realtime Twitter Client In The Browser

Malte Ubl has announced Streamie.org, a realtime web based twitter client in the browser.  It is moving fast, with new features appearing almost daily.  Here are some of the features already in place:

1. Truly realtime.  When someone posts a new tweet, it will show up in your timeline in a matter of seconds - no refresh necessary!
2. When you scroll down, streamie maintains your scroll state as new tweets appear. I can’t use a Twitter client without this feature
3. Image uploading
4. Geolocation
5. Chrome notifications
6. Image previews without leaving the page
7. View all tweets in a conversation
8. Autocomplete of twitter names with creating a tweet
9. Direct messages and at-replies from people you don’t follow are interwoven with the main timeline
10. Hackable++

One of the most interesting aspects of Streamie is its hackability.  The entire project is opensource, including the node.js backend as well as the HTML5/CSS3/JS frontend.

Now if you want to build your own version of streamie, there are eight easy steps:

1. Fork Streamie on Github
2. git branch gh-pages
3. git checkout gh-pages
4. git pull origin gh-pages
5. edit something in ./public
6. git commit
7. git push origin gh-pages
8. Wait a little on the first time

Now go to YourGithubUserName.streamie.org and visit your new Twitter client.

Very neat!  You can check out Streamie at streamie.org, read a few blog posts by Malte about it, and check out the source code on Github!

Fun - A Programming Language for the Realtime Web

Marcus Westin has been working on a programming language called Fun that specifically targets the realtime web.

What if you could build realtime web apps with the same ease as you build static web pages in PHP today? Without long polling, event handling and state synchronization, the engineering complexity of realtime web applications would drop by an order of magnitude. There would be a fundamental shift in the way we build the realtime web. This is the future of Fun.

Fun, much like PHP, is a template language that merges markup and logic into a single file.  However, in Fun, unlike PHP, markup is a first class citizen that can be included in the file without quoting it or creating <?php ... ?> blocks.  Fun also automatically updates your UI when data changes, so:

In Fun, when you say “Hello ” user.name, you don’t mean just “render the value of user.name right now”. Rather, you mean “display the value of user.name here, and any time user.name changes update the UI.” In other words, when someone edits their name you see the changes keystroke by keystroke. And you don’t need to write any code for networking, event handling, state synchronization, or DOM manipulation! Fun takes care of all that for you, all you do is map state to UI. Fun, eh?

That realtime data synchronization works for lists as well.  When a new item is added, it will automatically appear in the UI as well!  If you bind an HTML input to a piece of data using the data attribute, it will be synchronized in real time with all other users on the site as well as the data storage layer if there is one keystroke by keystroke.

The Fun language is written in JavaScript on top of Node.js and the PEG.js parser generator.  Once the code has been parsed, pure JavaScript code is generated for both the server and client side.  Fun uses Fin and js.io to synchronize data between the browser and the server in realtime.

To show the simplicity of Fun, and how powerful it can be with only a few lines of code, here is the entirety of a chat app written using the new language.

<div class="compose">
    <input data=Local.newMessage />
    <button clickHandler=sendMessage>Send</button>
</div>

let sendMessage = handler() {
    Global.messages.push({ user: Session.User, text: Local.newMessage })
}

<div class="messages">
    for (message in Global.messages) {
        <div class="message">
            <img src=message.user.pictureURL />
            message.user.name " says:"
            <span class="text"> message.text </span>
        </div>
    }
</div>

Because of the realtime nature of the language, everything will stay in sync across all of the browsers connected!  If you’d like a breakdown on how that code works, you can read this entry on Marcus Westin’s blog.

Amazing work!  You can read an introduction to Fun here, how the chat demo works here, and the code on Github.  Have Fun!

Looking for Node.js Modules? Check out the NPM Repository!

With Node.js Knockout happening this weekend you might be looking for good modules for use in your great new application.  I was looking through the Modules page on the Node Wiki last night, and was overwhelmed by the sheer number of projects available.  How do you tell which projects are still active, and which ones are of high quality?  These questions need to be answered quickly, especially within the context of a time limited contest like Knockout.  

I posted my frustration to Twitter, and got a response from Chris Williams (of JSConf Fame) who pointed me to the NPM (Node Package Manager) Repository.  I had already heard about NPM, which is a command line tool for installing, updating and managing node packages.  It works much like Ruby gems does, and has become the defacto package manager for Node.js.

While NPM is nice in that it allows you to install packages very easily, it still did not solve the problem of finding and filtering projects.  Luckily, that is where the NPM Repository comes in.  NPM the command line tool works off of a huge JSON registry that keeps track of all the projects in the package manager.  Mathias Pettersson (aka @mape) used that JSON file to build a nice GUI that helps you find and see updates to Node.js packages: hence the NPM Repository app.

The application allows you to see all of the projects in the NPM repository in a nicely designed table that is sortable by Package Name, Time Updated, and Author.  It also has a search box in the top righthand corner that filters the table as you type, allowing you to filter by any of the fields in the table.  Each project has a “More Info” button that lets you see a long description of the project as well as download a tarball of the latest version.  Projects hosted on Github also have a link to their repository available.  It looks like a very nice way to filter through the noise to find active Node modules relevant to you.  Be sure to check it out!

UglifyJS: A Fast New JavaScript Compressor For Node.js That’s On Par With Closure

Mihai Bazon has written a new JavaScript compressor called UglifyJS that compresses code on par in size with the Google Closure Compiler, and at lightning speeds compared to YUI compressor or Closure.  The best thing about it, though, is that it is written in JavaScript on top of Node.js.

It works by parsing the inputted code using a hand-written parser ported from the parse-js Common Lisp library by Marijn Haverbeke.  Once parsed, the code is regenerated from the AST generated by the parser into compressed JavaScript.  There is also an option to pretty print the output.  Here are some of the optimizations that the compiler makes:

• Remove whitespace
• Shorten variable names (usually to single characters). Our mangler will analyze the code and generate proper variable names, depending on scope and usage, and is smart enough to deal with globals defined elsewhere, or with eval() calls or with{} statements.
• Join consecutive var declarations:

  var a = 10, b = 20;  ==>  var a = 10, b = 20;

• Remove block brackets {} where possible
• Transform foo[“bar”] into foo.bar
• Resolve simple constant expressions: 1 + 2 * 3 ==> 7. We only do the replacement if the result occupies less bytes; for example 1/3 would translate to 0.333333333333, so in this case we don’t replace it.
• Various optimizations for if statements:
  • Remove “else” where possible (when the last statement in an IF block is “return”, “throw”, “break” or “continue”)
  • Transform simple ifs like:

    if (foo) bar(); else baz();  ==>  foo?bar():baz();
    if (!foo) bar(); else baz();  ==>  foo?baz():bar();
    if (foo) bar();  ==>  foo&&bar();
    if (!foo) bar();  ==>  foo||bar();

UglifyJS compresses better than YUI Compressor and just about on par with the Google Closure Compiler.  For example, the compressed version of jQuery from the Google Closure Compiler is only 403 bytes smaller than the version produced by UglifyJS - impressive!  UglifyJS is also the fastest to run by a long shot, beating Closure by over 6 seconds!

Additionally, the code produced by UglifyJS is safer than the code that Closure generates.  For example, Closure doesn’t know how to deal with eval or with{} - it just logs an error and continues to rename variables anyway.  This, obviously, leads to broken code.  UglifyJS does not have this problem:

If eval() or with{} are used in some scope, then all variables in that scope and any variables in the parent scopes will remain unmangled, and any references to such variables remain unmangled as well.

UglifyJS looks like it could be the current winner of the JavaScript compression war.  While it is a close runner up to Google Closure Compiler in compiled output size, it runs the fastest by a long run and is the safer to use than Closure.  With a little more work, it could even beat Closure in compiled size!  What do you think?  Will you use UglifyJS to compress your JavaScript?

You can check out UglifyJS out on Github, and fork away to make the compiled size even smaller.  The code looks well written and hackable.  If you want to try out the compiler without installing it yourself, you can do so here.  Great work!

defer: Taming Asynchronous JavaScript with CoffeeScript

Tim Cuthbertson has written an extension to CoffeeScript called defer, which is a way of writing asynchronous javascript in a more straightforward and synchronous-looking way. It adds a language feature called Continuations, which are objects that represent “the rest of the currently executing program”. In other words, a continuation represents all of the code after an asynchronous operation like an AJAX request.

Basically, instead of writing code with callbacks as it is traditionally done in JavaScript which often lead to cluttered code, you can write it as if it were entirely synchronous, except with the new defer keyword.

For example, you would currently write code like this:

database.get("test", function(result) {
    //do stuff
})

And with the new defer keyword, it is simplified to this:

var result = defer database.get("test");
//do stuff

However, the call to the database actually remains asynchronous since the compiler generates the callbacks for you. This could really help to clean up a lot of the asynchronous code mess that we are dealing with more and more when using things like Node.js, which contains entirely asynchronous I/O. Since Tim has written this on top of CoffeeScript, you get additional awesome features like array comprehensions, and true classes for your code as well. If you haven’t checked out CoffeeScript yet, be sure to do so.

I think that with more and more asynchronous I/O going on, something like this will be necessary to try to deal with all of the callbacks and messy looking code that will inevitably be produced. This is just one implementation. We have seen things like NarrativeJS and JavaScript Strands before, which are entirely in JavaScript and take a different approach to the problem. Maybe at some point, JavaScript will have the feature baked right in, but until then, using a compiler to help work out the problem is perfectly valid.

Nice work, Tim! There is an extensive write up about this work on Tim’s blog for you to check out, as well as his CoffeeScript fork on Github. Be sure to follow this closely. I’m sure it will go great places!