Blue Sky On Mars

What is Bespin?

1. Bespin is a programming environment that you can include in your web applications that you create
2. Bespin is a programming environment for creating web applications

Frameworks vs. Libraries

Why use a library at all?

Why jQuery?

Not just jQuery

Summary

Additional Commentary

John-David Dalton commented via a gist.

He points out that unless we are using a compatible jQuery, people who already have jQuery on the page will not have any size advantage. Of course, if we have our own library no one will gain a size advantage.

With respect to Bespin users being able to use whatever library they wish without porting additional widgets, we (the Bespin team) want to be able to use things like trees and such without having to port them to our own library. Bespin users do remain free to use whatever they wish without porting anything.

Finally, regarding “fourth time’s a charm”, I’ll just note that the 0.8 version number of the next release of Bespin is actually significant. The client APIs are settling.

Thanks for the comment, jdalton!

ClassList API in HTML5

I was happy to hear from Thomas Bassetto that addClass has indeed been rendered redundant by HTML5’s ClassList API which looks great. element.classList is available today in Firefox 3.6 and, according to the Mozilla Hacks article, WebKit is planning to also support the API. The current version of Chrome does not have it yet.

I missed ScurvyConf entirely, much to my dismay. I got on the plane on time, but then they said they needed to swap out a computer. And then they swapped it out again. And then they gave up, hauled everyone off the plane, had us trudge across the airport and then loaded us up on another plane. I finally arrived at the hotel close to midnight, which is a drag given that I got up at 6:30am.

I started out on Track B. By the way, the notes below are mostly not going to be my opinions, but generally just what the speakers are saying. Sorry if this is a bit raw and unedited…

Chris Williams: How did I do JSConf?

Chris reported spending 200 hours to get JSConf going last year and 120 this year. He pointed out that conference tickets don’t sell out until they sell out… people need to feel like they’re going to be missing out on something and then they’ll sign up. JSConf 2009 was nearly canceled because of lack of interest and then they said “tickets have sold out” and instantly had a waiting list.

There was some additional discussion abiout how JavaScript needs a good website for the language. John Resig pointed out that MDC really has a lot of great information that is not Firefox-specific and is all available under a CC license. There was general agreement that MDC is a great resource, and Chris also mentioned it would be cool if there was a tool that cross-referenced between the JavaScript libraries (eg. $() in jQuery translates to dojo.query, etc…)

Chris is a fun speaker, and he gave us a great view of what goes into planning a conference.

Brian Mitchell: JavaScript’s Twin (Lua)

From a language perspective, Lua and JavaScript are so similar that there’s a temptation to just use JavaScript. But, there are times when Lua is a better choice.

LuaJIT, on some tests, is way faster than v8. It also has very good memory usage characteristics.

“Tables” in Lua are used for both array types and hash types. They’re very well optimized so that they perform like arrays when you use them like arrays. Warning: indexes start at 1.

Local variables need to be declared. Trailing semicolons are optional. Lua uses “end” rather than braces.

Lua has coroutines which makes asynchronous programming look a lot more synchronous.

Dion Almaer and Matt McNulty: web fragmentation on mobile

There’s a proliferation of internet-connected devices that all have SDKs, so it’s hard for developers to figure out how they’re going to support platforms. But, we’ve been there before. Back in the early 80s, you had to decide which computer you’d develop for, and that was it. Then came Windows, but there were still other platforms around… after that came the web, which enabled lots of new companies to grow up building software that could work on any number of devices.

Dion showed Quake II running in a browser using nothing other than HTML5 features. A lot of this is because of the huge speed increases in JavaScript.

There are a bunch of solutions for packaging up web applications for use on different devices. Titanium, Prism, Fluid, Palm’s webOS SDK, etc. all provide ways to provide native-like experiences using nothing other than web technology. jqTouch lets you use normal jQuery-style development for touch-based platforms.

When developing for mobile, these days you have a decision to make about your UI: do you want it to look native to the platform, or do you want to make an immersive experience that is tailored to your app. If you create a UI that is just there to serve your app, that could run nearly unchanged from platform to platform.

Palm’s mojo gives you a nice component model for HTML-based apps. Web apps have a low level model in some ways, compared to GUI components that you get in native platforms.

Matt McNulty announced that Ares is going 1.0 on Monday. Ares is Palm’s browser-based developer environment for webOS. 1.0 adds component APIs you can drag and drop, undo/redo, and a bunch of other features. Matt demoed Ares, and it’s really slick. Ares lets you preview the app in the browser (without the device services, obviously). It also lets you install to the device to see the actual app running.

Ares doesn’t work in IE, and no one really cares. Shockingly few people care about an offline version.

Matt also showed off mojo running in the browser. He had the native Palm mail app running in a normal browser window, which is cool indeed. Webkit browsers are no problem, but they’ve done some monkeypatching to make bits work on Firefox.

Francisco Tomalsky: Socratic documentation tool

We need to rethink how we do docs. Docs in source code are annoying because you have to scroll through them when using the code, you can’t localize them, you need specialized tools that may not yet exist for your language, it’s hard to include rich media (even when videos might make sense), and it increases the already large workload for committers.

Socratic uses the information in TextMate bundles to build up a DOM of your source. Once you do that, you have a query language that’s not unlike jQuery for querying that DOM and pulling out all of the matches.

The other piece is a wiki based on git (rather than docs in your comments). The wiki git repo tracks the branches of your code, so someone can get the docs for a specific version of your project. Socratic also has support for GitHub issues.

The project is not done (actually looks like it’s just getting started, based on the quick demo he gave) and Francisco is inviting people to help. He thinks that a great doc tool in CommonJS JavaScript will get a bunch of people using CommonJS servers.

Francisco then followed up with a demo of the latest Cappuccino release. He mentioned that it is now completely CommonJS-based. You no longer need Ruby at all to work with Cappuccino’s tooling. Also new is a CPTableView that was contributed by an outside contributor. He demoed using IB to create a table view and used nib2cib to convert for Cappuccino’s use.

A year ago today, I posted “What Server Side JavaScript Needs”, inviting people to come and turn JavaScript into a competitive platform for applications on the server. Quite a few people answered the call. While the focus of the group has been on JavaScript in non-browser contexts, we’re ultimately shooting for as much of a standard that can cross between server, browser, GUI and command line applications as possible. That’s why we changed the name to CommonJS in the second half of the year. Ironically, most of my own personal use of CommonJS so far has been in the browser. I’ll come back to the personal perspective, though.

The Original Goals

As laid out in my original blog post, we were seeking to create:

• A module system,
• A cross-interpreter standard library,
• A few standard interfaces,
• A package system, and
• A package repository

Note that the idea here is that this group creates specs, which will have multiple implementations.

The goal is to have these things working across as many operating systems and interpreters as possible. There are three major operating systems (Windows, Mac, Linux) and four major interpreters (SpiderMonkey, Rhino, v8, JavaScriptCore). Plus there’s “the browser”, which is a unique environment unto itself. That’s a fair bit of surface area to cover.

Oddly, I think the one of those eight “platforms” with the poorest implementation support is Windows. Most of the CommonJS developers are using Macs or Linux machines, so I’m not sure how much time has really been spent on Windows. I would imagine that JavaScriptCore on Windows is probably the least supported combination.

The good news, however, is that there are projects using all of those JavaScript interpreters and platform compatibility issues will ultimately be ironed out.

CommonJS and the ECMAScript Standard

The CommonJS group is a grassroots effort, and not some formal standards body. In some ways, however, it works like a standards body in that the people working on the standard are also implementing the standard-in-progress and using it to build real applications.

We have no control over the ECMAScript language, which is managed by the TC39 working group. However, there are a few people involved in CommonJS who are part of TC39, and I have firsthand knowledge of others who are keeping an eye on how things are going with CommonJS.

The CommonJS standard-in-progress is designed to work on a subset of ECMAScript 5 that can be made to work on today’s ECMAScript 3 interpreters. ECMAScript 3 is the standard that is running in all of the browsers. In other words, in a CommonJS application you can count on Array.prototype.forEach to be implemented. Obviously, applications can do whatever they want (array destructuring? knock yourself out, but your app will only work on SpiderMonkey and Rhino).

One certainty about CommonJS is that inventing new language syntax is out of scope.

The Module System

The CommonJS group has been remarkably good at avoiding bikeshedding. While there is discussion about names of things, there isn’t heated discussion about it. People are far more interested in issues of functionality and ease-of-use. This is a very good thing, and it allowed us to get modules out of the way early on.

Of course, the lack of bikeshedding doesn’t mean that everyone agrees on things. The CommonJS module system has its controversial aspects, but I think it does well given the constraints:

1. must work with ES3 syntax (destructuring could actually be useful, but we’re not going to do it)
2. modules should have self-contained namespaces and be explicit about data the want to export
3. it should be possible to make modules tamper-proof, though this is not a requirement
4. using a module should be competitive with using modules in languages like Python and Ruby

TC39 had considered adding modules to ECMAScript 4 and there are module proposals on the table for ECMAScript Harmony that would add some syntax to JavaScript that would look similar to CommonJS modules. Here’s a short module to give you an idea of what CommonJS modules look like:

var sillymath = require("extramath/silly");

exports.addTwo = function(num) {
    return sillymath.add(num, 2);
};

Personally, I find this to be reasonably concise with a nice level of explicitness. Some syntax sugar would be good, and I hope we get that in ES-Harmony. But, this syntax works fine today.

Of course, this syntax is not without controversy. The biggest controversy has been that require() is synchronous – the “extramath/silly” module has to be available as the module above is loaded. However, there are a couple of reasonable ways to deal with this problem and I am happily working with CommonJS modules in the browser which is the environment that is least tolerant to synchronous loading.

Controversy or not, this basic module system was ratified last winter and has been implemented on all target environments of CommonJS.

Discussion is ongoing for a tie-in to the module standard: the module transport standard. Without additional help from the browser or some additional scaffolding running in the page, the module syntax above doesn’t work via a <script> tag. By standardizing what that scaffolding would look like, it is possible for a variety of build tools, servers and client side libraries to come into existence to provide many options for loading modules in the browser. There have already been several implementations of CommonJS module loading in the browser, but a standard will make it much easier to mix-and-match client and server.

The Standard Library

I had hoped we’d get farther on the standard library than we have, but it can indeed be a long process. system and unit testing are the only ones that have been ratified at this point. We have come a long way on file access.

“What!?!?”, I hear you say, “there’s no standard for accessing files yet?” That’s right. And there are a couple of reasons that it’s been challenging to get there.

Consider that JavaScript does not even have a standard object to deal with binary data. That is a basic prerequisite to working with files. JavaScript strings are not the same as a binary data container. So, there’s binary data to handle, streams to figure out and then file functionality built on top of that. There’s also the consideration of whether file access is synchronous or asynchronous. We’ve made tons of headway on this, and there are certainly implementations of some of the specs. It’s just a matter of finishing them.

I’m hoping to see promises become a part of the standard, because some form of that interface is very convenient to use for asynchronous operations.

Standard Interfaces

We do have a very useful interface with implementations and people actively using it: the JavaScript Gateway Interface (JSGI). That spec has not yet been ratified, but it is getting closer and there are apps being built against it today.

Database access has not yet been standardized. It will be interesting to see if we can come up with a good interface that can usefully target SQL and NoSQL databases alike.

Package System

We have a recently ratified spec for packages of CommonJS code. I hope this will bring about a collection of good package managers with different focuses and targeting different environments. There have already been a couple of attempts to create package management systems, and the most fleshed out one that I’ve seen is Tusk, which is bundled with Narwhal. Once a few more specs are ratified, Tusk should be able to run on other CommonJS implementations.

Package Repository

Tusk is using GitHub as a package repository, and that is working okay for the time being. A couple weeks back, we got word that the jQuery plugin repository is going to provide a CommonJS package.json file for the ~5000 plugins in their database. This is exciting, because this infrastructure could prove to be very useful to us going forward.

JavaScript: Bubbling Up

2009 was a terrific year for JavaScript. In the browser, we’ve obviously seen tons of growth in increasingly sophisticated applications. I think the interest is steadily building to use JavaScript more and more outside of the browser. The two JSConf conferences (in Washington DC and Berlin) were great successes by all accounts I’ve seen. PhoneGap, Titanium and Palm’s WebOS have created ways for people to use web tech to create installable apps for mobile phones. node.js has been a huge driver for people to check out building scalable, asynchronous JavaScript apps on the server. And, of course, CommonJS is finding its way into more and more applications.

My Personal View

I had hoped to personally have more time to devote to CommonJS in 2009, but I am delighted at how a great collection of people have stepped in and carried the specifications and implementations forward through a lot of hard work and force of will. More than 5,100 messages have gone across the mailing list, and more than 10% of those have been from Kris Kowal. Kris has done a ton of work in ironing out many of the specs and deserves a good deal of credit for where CommonJS is today. He and Tom Robinson even stood in for me when I had to cancel my trip to JSConf.eu (thanks, guys!).

Taking a look at the top posters on the googlegroup, you can see how many people have put so much into CommonJS. More than 10 people have contributed more than 100 messages a piece and, for many of those people, there was a lot of time spent in the email discussions, IRC chats, spec writing and implementation of those specs. Plus, as early adopters, they have the joy of tweaking things as the specs have changed over time. Thanks to all of you for the dedication and the will to get it done.

Bespin’s client side JavaScript code is all CommonJS modules now, partly thanks to the efforts of Charles Jolley to migrate the SproutCore framework to CommonJS and creating the Tiki module loader. From that standpoint, I’m already using more CommonJS now than I did in 2009. I’m also hoping that 2010 will bring a Bespin server “reboot”, where we start migrating server functionality to CommonJS.

On the whole, I think that 2009 was a great year for JavaScript and CommonJS and I think 2010 is going to be even bigger. I hope to meet more enthusiastic JavaScript hackers at JSConf.us in April!

Comments?

You can direct them to the thread on the CommonJS googlegroup or email to editor@blueskyonmars.com.

Due to Thanksgiving falling on the same day as the normally scheduled date for a2 <div>’s monthly meeting, we decided to find a different date and possibly join up with another group for a complementary topic. And, indeed, that’s what we’ve done!

a2 <div> and the Google Technology User Group will have a joint meeting on Tuesday, November 17th. The meeting will be at the SRT Solutions office at 7PM. I realize that there are conflicts that day, but there is so much going on during the month that it’s hard to find a date without conflicts!

We have a hot topic: Google Closure. Sure, new JavaScript libraries appear every day, but not like this one. Closure has a maturity that comes from years of use within Google, on some of Google’s busiest properties. It has an amazing toolset (Firebug plugins, super squishy compiler), great docs and a nice collection of features. Of course, not many people outside of Google know much about Closure right now, so this meeting is a group exploration of Closure. Read more in the RSVP form below to see how it works.

I hope to see you there!

A few days back, I announced the creation of the a2 <div> group: devoted to learning new tools and techniques for building the best webapps. Meetings will be on the 4th Thursday of each month, so the first meeting is on September 24th at 7PM at the SRT Solutions office in downtown Ann Arbor. Meetings are free, so join us (please let us know that you’re coming using the form below — reason for that in a minute).

The general meeting flow that we’re going to start off with is:

1. A presentation/demo of something awesome (for about an hour with questions interspersed plus maybe a few extra minutes for questions afterward)
2. 5 minute lightning talks (proposed beforehand using the form below)
3. General discussion (either collectively or in groups. Individuals having discussions with themselves is not encouraged.)

This is a rough outline, and I expect a lot of flexing based on the topics du jour.

I’m asking for RSVPs because I’d like to encourage folks to give lightning talks and the form gives a space devoted to that. Lightning talks, for those unfamiliar with the term, are simply 5 minute or shorter talks to introduce people to a topic or to give a quick demo of something new and useful. They can also be a good way to spur new discussion. RSVPs are also good to ensure that a really hot topic doesn’t overwhelm the space we have.

For the first meeting, the main event will be Majd Taby showing off SproutCore. SproutCore, for those who have never seen it, is an amazing open source JavaScript UI toolkit that is highly optimized for speed and reduction of the amount of code you need to write. It borrows liberally from concepts in Apple’s Cocoa framework, and Apple themselves use it for their MobileMe service. If you’re building a “website”, you probably want to use something else. If you’re building something that is an honest-to-goodness app, you owe it to yourself to check out SproutCore.

There aren’t any lightning talks lined up yet, so be sure to toss your name into the hat if you want to give one.  Also, there’s a form online if you want to give a talk at a2div and another if you have a topic you’d like to hear about.

I’ve been interested in doing cool stuff with web technology for a long time. I still think that web development is harder than it should be, but new tools, processes and ideas come along all the time to make it easier and more fun.

Many people probably view me as a “Python guy”. Sure, I’ve done a good deal of work with Python over the past few years. But, there are many, many good ideas on the server side that come from places other than Python.

And, the browser as a platform is an entirely different thing than it was a few years ago, particularly when you restrict yourself to “modern browsers”, as we do on Bespin. The performance difference between today’s browsers and those from a couple years back is huge, and that new performance opens the door for all kinds of new applications and toolkits to help us build those apps.

I want to learn firsthand from people using modern tools to make development faster and more fun. I haven’t seen a group here in Ann Arbor that is devoted to the broad range of web development topics, so I decided to get one going. It turns out that Majd Taby sent a message to the a2geeks mailing list in April about starting a web dev group, but I somehow missed that. Majd and I exchanged some email this week and worked out the details of the new group.

The new group is called a2 <div> (or just a2div) because it has the same topic focus as cu <div> and I liked the idea of joining forces in some sense with a similarly minded group. cu <div> has a bit of a student focus that a2 <div> does not (it’s been a long time since I was a student). Thanks to Cameron from cu <div> for giving us the go-ahead to start an Ann Arbor offshoot. Thanks also to Dug Song for passing along the link to cu <div> and connecting me with Majd.

a2 <div> will be a loosely organized group as MichiPUG is… bringing the right people together for good discussion is far more important than creating a formal organization. Meetings are free. Our meeting format will likely be something along the lines of 1 hour presentation/demo followed by lightning talks and discussion.

An important aspect of a2 <div> is that’s non-denominational. Are you doing client and server in Java (for example, with GWT)? Neat. How about in Python (with Pyjamas)? Groovy. Doing the server in Lift and the client side with Cappuccino? How about PHP+Dojo? SproutCore+WebObjects? Using ASP.NET MVC with jQuery? Do you use Cucumber to test your apps? All are welcome, all are interesting.

Our meetings will be at the SRT Solutions office in downtown Ann Arbor. This is a great space to meet at (projector, whiteboards, flexible table arrangement), and the location is nice because it’s easy to walk out for drinks and food afterwards. Thanks to Dianne Marsh for letting us use their office!

Meetings will be on the 3rd Wednesday 4th Thursday of each month at 7pm. That means our first meeting will be on September 16th 24th (less than two weeks away). You can subscribe to our calendar in XML or ical formats.

The first meeting topic is not fully decided yet. Please join the a2div googlegroup and let us know what you might want to hear about or talk about!

If you’re near Ann Arbor on September 16th, join us at SRT Solutions for engaging discussion on all webdev-related topics! See you there!

I work in Mozilla’s Developer Tools Lab, where we’re working to make things easier for web developers and to explore what is possible using open web tools. It turns out there’s quite a bit that’s possible, and we’ve just scratched the surface with what we’ve done with Bespin so far.

I’m really happy with the team that I’m working with, both within Mozilla Labs and in the Bespin community. I’m also really happy to report that we’ve got an opening on our team! We’re looking for fantastic software engineer that will own the Canvas-based editor component that is at the heart of Bespin.

If being at the forefront of JavaScript technology (Canvas, local storage, web workers) sounds fun and exciting to you, drop us a line! We’d love to talk to you!

(sorry for the lack of links in here. I wrote this on a plane and haven’t had a chance to do anything else to it…)

I just returned from JSConf 2009, the first JSConf conference. It was possibly even the first conference to feature JavaScript as a general scripting language in the same vein as Python or Ruby.

Overall, it was a very good conference. The organizers did a terrific job and paid great attention to detail. The sponsored evening events were an awesome idea and well-executed. (At least, Friday night’s was, I flew home Saturday evening). It was a relatively small conference at 130 people. I think they can easily have double that number next year, if they want to. But, that would require a change of venue, because the Hotel Palomar’s meeting rooms were filled almost to overflowing. From talking with Chris Williams on Friday evening, it doesn’t sound like they’re interested in changing venues next year, which is a shame because a lot of people will have to miss out on a great conference.

Francisco Tolmasky from 280 North gave the perfect kind of talk to kick things off. I’ve been following Cappucino’s development, so I was not surprised in the least with what I saw. But, Francisco is a polished speaker and many people had not seen Apple’s Interface Builder used to create webapps (via Cappucino’s nib2cib tool). We didn’t get a demo of Atlas, which would certainly have wowed this audience.

One thing that pleased a great many people in the audience, myself included, was word that Safari’s debugger would start looking at a “displayName” on functions to determine what name to show in the debugger/profiler. JavaScript has many places where it’s impossible to guess a reasonable name, and it’s nice to have a way to give the debugger a hint like this. Let’s hope we get this in Firebug soon.

Toward the end of the second day, there was a talk about SproutCore, so we had a chance to two different ways to apply the style of Apple’s Cocoa to building webapps. As with anything, there are tradeoffs. Cappucino builds on Objective-J, which gives you a more concise syntax than straight JavaScript for things like Key Value Observing. If JavaScript today had getters and setters, then this particular benefit of Objective J would go away. For now, though, using SproutCore effectively means calling get* and set* methods to get variable values rather than just looking up the value directly.

There were two presentations on server side JavaScript, a topic that people who know me know that I am currently very into. Nick Campbell showed off the Axiom Stack, which builds on Helma. Axiom is presently AGPL-licensed, which means I won’t go anywhere near it. But, that’s just me. On the plus side, Nick has been peripherally following the activity on ServerJS and is quite in tune with our goals. Nick’s company, by the way, has a unique and useful sounding web marketing-related product coming out soon, so keep an eye on those folks if you’re a marketer.

The second Track A presentation about server side JS was James Duncan’s presentation about Joyent’s Smart platform. I must say that this looks like an excellent offering, and I’m looking forward to seeing a lot more of it as it hits general availability. The best parallel I can draw is “App Engine on JavaScript”, but that doesn’t really do it justice. They have a key-value store that they will scale transparently for you. No more manual sharding! Just start tossing data in. Of course, that’s the promise… and the devil’s in the details with such things. I came in a bit late to James’ presentation and I forgot to ask him afterwards about their data store’s indexing capabilities and whether it is eventual-consistency based or more immediate than that.

The Smart platform is SpiderMonkey-based, and they pull some interesting tricks to overcome the lack of a decent stack of libraries for SpiderMonkey. Their web server interface looked very much like Jack, which is a bonus. It would be nice if we can harmonize it with Jack in some fashion. Intriguingly, their web framework, which is apparently based on Sinatra, looks an awful lot like the home grown one that I made for Bespin in Python and then duplicated in JavaScript.

I didn’t lump my former SitePen colleague Kris Zyp’s talk in with the other server side JS talks, because Kris was talking a lot more about JS that spans from client to server and using standards such as JSON Path, JSON Query, Persistent JS, and JSON object referencing to move data around seamlessly. Of course, he used Dojo and Persevere as his demo platform, but the ideas he presented can be applied anywhere.

Brian LaRoux’s talk on PhoneGap was quite interesting and entertaining. Brian’s talk had a refreshing lack of gravity, while still providing useful content. For one, he mentioned that Dashcode actually offers good tools for making iPhone web apps. He talked about a variety of iPhone-related JS toolkits, and gave a demo of Nitobi’s iPhone “stimulator” which does a better job of representing how an iPhone app will behave than Apple’s own simulator.

I should note that there were probably 50% fewer bullet points than what I have seen at some other tech conferences I’ve been to. I think the message is sinking in that bullet points suck (except for actual lists of things).

My Mozilla colleague, John Resig gave a wide-ranging talk about JavaScript performance testing, games and his project of the moment, TestSwarm. TestSwarm looks fantastic and fills a gap: it will provide a way to do cross-browser continuous integration tests. People join the test swarm by opening their browser up to the TestSwarm page, and the server will send them test jobs as they come in. So, for example, a revision gets checked into jQuery, and the TestSwarm server will pull out the tests and send them down the wire to a collection of testers who are using different browsers. The results from all of the browsers will come back and get logged. This tool will be useful for a lot more than just jQuery, and John offered help connecting it up with, say, DOH for Dojo’s tests.

Another former SitePen colleague, Pete Higgins gave a Dojo roundup at the very end of the conference. I saw half of his talk before I had to go to the airport. There are lots of good things afoot in Dojo-land. The new conditional compilation stuff seems useful for a variety of things. For example, Dojo can be built in a super-slim variety (6K) that loads everything dynamically. Or you can dump all of the IE compatibility stuff. With the Bespin project, we have a plan to ship a variety of packagings, and I can see this being useful for that as well.

Pete’s Plugd (which he pronounces “plug-dee” as opposed to “plugged”) project provides a bunch of extra convenient ways to use Dojo and I do hope to see that stuff included in 1.4. Pete says that Plugd will likely add 4K to Dojo’s gzipped size, but I think it’s likely worth it.

Malte Ubi likely takes the prize for JSConf attendee who came the longest distance to attend, having flown in all the way from Hamburg, Germany. Malte has been doing some fantastic work on Bespin. Actually, the things he’s been doing go beyond the realm of fantastic and into “crazy”: using Narcissus (JavaScript parser in JavaScript) to read your JavaScript file in a web worker to provide completely client-based outline views and code completion. Awesome.

Malte did a Track B talk on Joose, his JS object system that is built on ideas from Perl’s Moose. It looks like a very powerful system that provides things like type coercion and traits (called roles here) that you don’t find in the type systems that typically come with JS toolkits. If I recall correctly, Joose weighs in at about 16K gzipped, so it’s not a small package.

Nick Carter gave a Track B talk on his JS ORM, JazzRecord It’s a direct descendant of Rails’ ActiveRecord. It looks like a nice enough package, but seeing his samples made me that much more convinced that Atul is right: SQL does not belong in the browser. The sqlite storage engine may very well, but SQL itself does not. TaffyDB, dojo.data, CouchDB, whatever… just as long as the principal form of expression, persistence and querying is JS. The needs of a typical web client are very different from the kinds of things to which we apply SQL on the server. And, even then, people are starting to realize that SQL is not the best tool for every job.

I spoke on Track B about ServerJS. I called the session “a standard library for JavaScript in non-browser contexts”, or something catchy like that, because it is clear that what we’re building applies just as much to command line tools and other kinds of non-browser programs as it does to the server side of web apps.

My talk came immediately after James Duncan spoke about dynamic loading of C code into a SpiderMonkey environment. I lamely brought up ctypes as one approach, but dynamic loading of binaries is not my strength. I suggested that James would get useful feedback for his idea on the ServerJS list, given the number of people who are linking C/C++ libraries up with SpiderMonkey and v8.

As for ServerJS itself, I spoke about the project in general and our biggest milestone to date: the “SecurableModule”. I had a simple “math.js” module with a fibonacci function in it. I picked a lovely O(n^2) function to show the performance difference between Rhino and v8 which is considerable. Since math.js is a “pure JavaScript” module, I was able to demo that module being loaded into: Narwhal on Rhino, Narwhal on k7, Persevere, Helma NG (as a Jack app, no less) and GPSEE. I also demonstrated how with Narwhal/Rhino, I could “forget” to put a “var” in and my variable would not suddenly leak into the global namespace.

I also mentioned that we’re working on binary objects and files and that Jack (the interface) has good prospects given how proven the technique is in Python and Ruby.

I hope that at JSConf 2010, we’ll be able to see some significant apps built on a fairly complete platform.

Conference co-organizer Chris Williams thanked me for my endorsement of the conference, saying that I pushed Mozilla over the edge on sponsoring the conference. I had no idea I had such pull . Anyhow, Mozilla’s sponsorship apparently had a direct impact on the conference food, which was quite beyond typical conference fare. Thanks to whomever it was at Mozilla who gave the a-ok on this.

As with any conference, the hallway track is among the most important, and I had a good time meeting new people and talking about a range of things. Community-driven conferences do bring in a good collection of people to meet.

I am doubtless leaving people out of this roundup, and I apologize for that. I am sure there are some other JSConf roundups that will provide additional insight. Also, the videos will be showing up online over time, so keep an eye out for that.

JSConf is coming up on Friday, and I’ll be there. I was too late to get a normal “track A” talk in, but I am scheduled in the “track B” room for Saturday at 1:45PM to talk about a standard library for JavaScript development outside of the browser. It’ll be a 30 minute session, and I’m hoping to have some cool stuff to show!

I hope to see you there!

For the week of February 23rd:

• Roberto Saccon ported Bespin to Dojo! Dojo leader Peter Higgins helped to clean things up a bit. This has significantly changed (and improved) the use of namespaces in the frontend code, which will make Bespin much easier to drop into other pages.
• For people keeping score at home, there is now a 0.1 branch in the Bespin repository that we will be using to update the server. The default branch has the Dojo work and all of the other forward-looking work going on. Until the trunk work stabilizes a bit, bespin.mozilla.com will be running a bit behind on the changes here.
• autoindent setting. When you hit return/enter you’re placed at the same indentation point on the next line.
• Select an area and hit TAB and it all indents. SHIFT+TAB and it unindents. Thanks to Jay Bird!
• Special support for certain keys so German keyboards etc can get in ‘{‘ and the like. Thanks to Julian Viereck  
• For people following the trunk/tip, the project build script has changed a bit. Be sure to follow the instructions in the top-level README file to get the Bespin server running.
• PHP, Java and Aduino syntax highlighting, thanks to Sean Burke and Olle Jonsson, respectively. The Arduino support is optional. Use include(“bespin.syntax.arduino”); in your config.js to load.
• Multithreaded development server, which speeds up page loads a bit now that there are more modules loading.
• Config work has short cuts now so you can simply use: include(file), execute(cmd), publish(), subscribe()