Peeking in on a Portland User Group: Portland JavaScript Admirers

When I first started Silicon Florist, I was hoping to shine some light on startups and events that might not be getting the attention they so richly deserved. I don’t know that I’ve succeeded. But I feel like I’ve at least made a dent.

Now, I’d like to make the same attempt with another under-served and under-recognized population: Portland’s rich and varied user group scene. I mean, there’s a ton of great stuff happening in our user groups. But—unless you’re at every single user group meeting—you can’t really get a feel for just how awesome it is.

So, I’m starting a new series of posts. We’ll be peeking in on user groups in Portland. Taking a look at what they’re mucking with. Listening in our their discussions. And hopefully introducing you to a few groups about which you might not know.

Up first? Portland JavaScript Admirers.

Portland JavaScript Admirers is a group that meets monthly to discuss topics on JavaScript and ECMAscript ranging from client-side web frameworks, to functional and prototypal programming theory. Meetings take place on the fourth Wednesday of every month from 7-9pm at Jive Software.

Notes from the last pdxJS meeting

We had a good discussion of several of the topics presented at JSConf and NodeConf.

Bytes and Blobs by David Flanagan

There are lots of new APIs for accessing binary data from a variety of sources and for manipulating binary data in JavaScript code in the browser. The last slide in the deck has a summary of the sources and sinks that are available. This makes stuff like reading and uploading multiple files without Flash possible.

Binary data that is available to JavaScript code can be sent to APIs that take URLs using blob URIs. These do not embed data like data URIs do – instead they point to cached binary data in memory or on disk.

Using a webkit-specific API you can construct binary data in JavaScript. You can use this for stuff like audio synthesis. With the right know-how or libraries you can synthesize binary WAV data and send that data to the HTML5 audio API as a blob URI.

There is another webkit API that creates a local filesystem that your web app has access to. From what I understand this API does not give the browser access to your real filesystem. Instead it creates space for files to be saved on disk just for that web page. There is a flag that switches between a transient filesystem, which goes away when the browser window closes, and a persistent filesystem, which will keep those files on disk indefinitely until the web app or the user removes them.

Everything is Permitted – Extending Natives by Andrew Dupont

In this talk Andrew Dupont argued that extending built-in types in JavaScript can be a good thing, provided certain precautions are taken. He pointed out that core extensions are common practice in Ruby. And he suggested using the ECMAScript 1.5 Object.defineProperty() method for creating non-enumerable object properties as a safe way to extend the Object prototype without breaking code that iterates over object properties using for…in loops. Other ways to work around that problem are to put hasOwnProperty() checks in loops or to use the ECMAScript 1.5 Object.keys() for iterating properties. Object.keys() has the advantage that it can be implemented in earlier versions of JavaScript using a polyfill.

This discussion of ECMAScript 1.5 features resulted in a request that I repost slides from a talk that I gave a while ago on that topic. Those slides are available here.

The group was not entirely in agreement that extending core types is a good practice. Though I did not hear objections to the idea of using core extensions to port newer, standardized, language features to JavaScript implementations that do not support them. As I learned from JSConf, the kind of library that adds language features that you expect to a language implementation that lacks said features is called a polyfill.

The Future Is Modules Not Frameworks by John Hann

John Hann argued that distributing JavaScript libraries as small, single-purpose modules offers sufficient advantages to make modules preferable to monolithic frameworks like jQuery, Prototype, and so on. With small modules you can mix and match different implementations and pare down your application footprint to just the dependencies that you really need.

Small modules could benefit from the use of something like the CommonJS module specification, which makes it easier to work with lots of libraries in one application without scope pollution. Though that brings up a question of exactly what a browser module should look like. A straight translation of the module definition that is intended for server-side code may not be the best option.

• Ender.js is a recently-created tool for building collections of small modules into frameworks. Ender offers a convention for organizing a module so that it can be easily included in lots of projects.
• microjs is a list small, focused JavaScript
  modules. It organizes modules by use case.

Node v0.5 Roadmap – Ryan Dahl

The node team is hard at work on porting node to Windows. In the process they are abstracting the under-the-hood components to make the platform-specific portion of node as small as possible. Some choice quotes from the slides:

Why is porting to Windows a priority?

The goal of Node, as with any programming platform, is total world domination.

and:

If we can’t get at least gigabit throughput from a TCP pair over loopback on every OS, we’ve failed.

If we can’t have 10,000 idle sockets connected to a server and use less than 100mb RSS on every OS, we’ve failed.

The slides discuss some of the hurdles and nice bits of writing non-blocking code in Windows.

A point came up in our discussion that a common comment on Node is, “why would I need that many connections open at once?” The answer is that that kind of question stems from the traditional approach to web applications where a client connects, is served a response as fast as possible, and disconnects. Node is aimed at a new style of application – or at least a style that is new to high-scale web applications – where clients are constantly connected to the server via websockets or comet.

dnode: freestyle rpc – James Halliday

dnode is a new RPC protocol. It is built on JSON and has implementations in Node and in some other languages. The particular advantage of dnode is that it allows clients to serialize procedures to be executed on the other side of a connection. That process can be arbitrarily nested: a service receiving a serialized procedure can pass that procedure as an argument to another serialized procedure that is passed to another endpoint.

Creating Node Addons – Marco Rogers

This talk introduces some of the details of implementing Node addons at the C/C++ layer. Writing addons in C instead of in pure JavaScript lets you add new capabilities that are not provided by the core modules. It also lets you reuse code from the vast repositories of existing C and C++ libraries that exist. For example, instead of rewriting AES in JavaScript you could pull an existing AES implementation into a Node addon.

npm supports packages that include C and C++ code. Currently that involves packaging up the source code; when a user installs the package the binary component is built from source. In the interest of bringing Node to Windows, and since Windows users are less likely than *nix users to have access to a decent compiler toolchain, work is underway to support precompiled binary components in npm packages.

We also talked a bit about Google Chrome OS. Specifically, the ability that Chrome and Chrome OS have to run web applications that include binary components. If a web app is installed from the Chrome store – that is, if the user has accepted the app manifest that grants the app permission to run binary code – then the app can download and run binary code. The binary code is still limited by the restrictions of the page sandbox. And the browser does perform a verification step to make sure that the binary code does not contain any dangerous instructions that could break sandbox isolation.

Next up for Portland JavaScript Admirers (pdxjs)

The next meeting will be held Wednesday, June 22 from 7 PM to 9 PM. For more information, visit Portland JavaScript Admirers or join the Portland JavaScript Admirers Google Group.

Interested in having your Portland User Group featured in Silicon Florist? Drop me a line at siliconflorist@gmail.com with your notes, and I’ll be happy to post them.