blobastorus: free storage for client side JS apps

blobastor.us is a free data storage service that is optimized for HTML5 web applications. The service is designed to be interfaced from javascript in the browser and to eliminate the need for a server component for most little HTML5 apps. Twitter is used to provide authentication and user identity.   

Lloyd amped up an idea that Atul put forth just a few days back. 20K per user per domain of free storage for JSON blobs. Basically zero effort to store a little bit of data for purely client driven apps. Makes serverless coding in the cloud seem a little more reasonable, no?

Brad’s Zoomy slide deck

Brad Neuberg on his new HTML5 slide deck:

I’ve created a 3D slide deck that uses HTML5, CSS3, and a bit of SVG (video). The main idea behind this deck is to be able to ‘zoom’ into topics to as deep a level as necessary. Slides are nested, like an outline.

The last presentation I did was also HTML5, using dzslides. The ability to dive deep into topics or skip over is a really cool feature of Brad’s slides.

JSConf.eu 2010: a weekend of awesome

Last year, I was disappointed to have to cancel my trip to JSConf.eu. This year, my luck was better, and I spent this past weekend in Berlin, along with two of my Mozilla Developer Tools colleagues, Joe Walker and Patrick Walton. Mozilla was out in force at the conference. Axel Hecht, who has been incredibly helpful bringing my team up to speed with localization, was in attendance. Oh yeah, and that guy from A Minute With Brendan was there. More seriously, I appreciated getting some good feedback from Brendan regarding where we’re heading with developer tools.

The conference organizers for JSConf.eu are fantastic, and I’ve got to thank Anja and Jan in particular for being exceedingly helpful. Jan even got us set up at co.up, which is a really nice coworking space that was easily reachible from our hotel.

You’re probably wondering if I’m just going to blather on about people… What about the conference? Seriously, the talking to people is what a conference is all about. The talks are great, but the hallway track is also fantastic in a small conference of enthusiastic people like JSConf.

JSConf is one of those conferences where you feel like everyone around is smarter than you are but, thankfully, also approachable, friendly and wanting to share.

Among JSConf goers, at least, the presence of Node is huge now. Even Peter Higgins was forced to mention Node in his talk after saying he wasn’t going to. There were several talks that presented solutions to the callback craziness that is a natural side effect of async programming in JS today. Jed Schmidt‘s (fab) talk was really entertaining and nicely done, though I fear that misplaced parens would lead to hard to debug problems. Tim Caswell‘s Step library looks like a more straightforward solution to the problem.

By the way, apparently Python 2.5-style generators have a decent shot at appearing in a future ECMAScript spec. These can provide a nice solution for making async code look synchronous without bad side effects.

Brendan’s talk about Proxy Objects (an ECMAScript Harmony spec that is already implemented and widely used within Firefox) was enlightening. This is an absolutely fantastic new feature. As a long time Python programmer, I’ve missed a number of Python’s features for altering the behavior of objects (all of those “__” methods). Proxy Objects will bring this to JavaScript in a fashion that is way more powerful than the getters/setters support we have an ECMAScript 5 and it does so without forcing objects to have specially named methods. Very clean and nicely done.

Funny story: Saturday morning, Joe, Patrick and I were talking about the feasibility of making a fast, DOM-based code editing component, and whether that would help with accessibility. Later that day, Fabian Jakobs showed off ACE, which is indeed a fast, DOM-based code editor. His presentation, which was overall nicely done, had a factual error about Mozilla Skywriter. He stated that Skywriter would be slow for a big canvas because it has to redraw every pixel for each character typed, which is rubbish. Skywriter does a saner job of painting than that… That said, his demo was very cool and their server has a lot in common with the server that we’re planning for Skywriter. Fabian and I agreed that it would be great to find ways for our projects to work together.

On Sunday, I spoke with Nick from Shopify who has also been working on code editing sorts of problems. He ended up with the Canvas approach rather than DOM DOM approach to editing also and his editor even uses Skywriter syntax highlighters. Nice!

As for Skywriter, I think our talk went reasonably well, albeit with a couple of technical glitches. My computer randomly decided to go to sleep early in the talk (huh?). After we got past that, we talked about how Skywriter is different from the original Bespin project and showed off the Bookmarklet and Embedded uses of Skywriter. We did a live coding portion of the talk in which we created a Skywriter plugin on the fly (a live version of a tutorial I wrote in June). We altered the script just before the talk to save a little typing by dropping the third parameter to window.open. It turns out that dropping the third parameter to window.open (at least in Firefox nightlies) results in a new window that doesn’t have a document body. Oops. Looks like a bug we need to report, or something. Pro Tip: don’t alter your live coding script by even a byte just before your talk!

I finally understand from Kris Kowal‘s talk why Q.when is sometimes nicer than promise.then() (you can treat synchronous and asynchronous calls the same way), but I still think that promise.then is a fine way to go for many cases.

The conference venue was neat and very different from the typical US conference venue. Overall, the conference was simply great. The after parties were fun. My group also had a good chance to have some wide ranging discussions and work through some designs for Skywriter.

I’ll finish my wrap up of JSConf.eu with a note about the final talk: Chris Williams‘ Community.js talk. Chris and his wife Laura organized the two JSConf.us conferences, superbly I should add. Chris showed his more serious side, encouraging the JavaScript community to:

1. show respect for other languages as well, since most of us started with others
2. not to become JS fanbois
3. to fix the fact that Google searches for things like “javascript”, “learn javascript” and “javascript array” take you to pages that aren’t so great

For this last one, he’s set up a page at promotejs.com that encourages links to boost the Mozilla Developer Network (formerly Mozilla Developer Center) site. Apparently, there are still quite a few people who haven’t encountered MDC, which has a huge amount of very clearly written documentation for JavaScript, CSS and the browser environment. I do know many who google things like “mdc array” instead of “javascript array“, but ultimately, reclaiming those keywords is a worthy goal.

JavaScript is a powerful, general purpose, dynamic programming language with several very fast, compatible, cross-platform implementations and a runtime that is already in the hands of more than 1.5 billion people. JSConf is the best conference around for those who appreciate JS for what it is.

Bespin and jQuery

Yesterday, we announced that the Bespin server is going to be rebuilt from the ground up in node.js with a decentralized model in mind. I’ve seen a lot of positive reaction to that, which is great because I think it’s an important step forward for Bespin. We also mentioned on bespin-core that we have changed from SproutCore, which we adopted during the “reboot” of the Bespin client side code, to jQuery. A handful of people have suggested that we should just build our own “framework”. Our decision to use jQuery came after much deliberation, so I thought I’d go into a little detail about that since this question has now come up many times.

What is Bespin?

It’s hard to say if something is a good choice for Bespin without actually being clear about what Bespin is. Bespin is a customizable programming environment for web applications. There are at least two correct ways to interpret that sentence:
  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
Early in Bespin’s life, people were embedding the editor in their own applications, but this wasn’t well supported. We made a decision to make that a well-supported use of our project and that change has major ramifications for the project.

Frameworks vs. Libraries

The best description of the difference between a framework and a library that I’ve seen is:
  • A library  is something you call from your code
  • A framework is something that calls your code
Note that this definition says nothing about the size (libraries could certainly be bigger than frameworks, and vice versa). This definition also makes no judgments about which is better or whether the code is loosely coupled or tightly coupled.
Frameworks can make building an application really fast. They do a great job of reducing the amount of code you need to write, as long as your application fits the framework’s design and intended applications well. The farther you stray from the path, the more resistance you’ll get as you try to add new things.
SproutCore is a framework. It attaches event handlers to the page and delegates those events to views that you create. Further, it has a powerful declarative binding/observation system that it updates automatically as part of a runloop that it maintains. It’s really quite a powerful GUI toolkit that runs entirely in your browser.
For Bespin “the application” (the software that runs at bespin.mozillalabs.com), SproutCore seemed like it would be a good fit because what we were doing was more like a desktop app than a website. On the other hand, for Bespin “the customizable, embeddable editor”, the tools we want and need are not such a great fit for a framework. Bespin needs to fit in well with what people are already doing on their pages.

Why use a library at all?

OK, so Bespin and frameworks are not a good match. But there are plenty of libraries out there (jQuery, YUI, Prototype, Mootools, Dojo, Closure, and even MochiKit about which I’ve written extensively in the past) Why not just build our own set of utilities, especially since Bespin exclusively targets modern browsers?
We wrestled a bit with that very question. Even with modern browsers, some conveniences are still handy. Here’s a simple case I can point to: addClass. A function that will add a CSS class to a DOM node. We all need to do that at times, but it’s not yet a method offered by the DOM, nor is it in any proposed standard that I’ve seen.
I believe that every JavaScript library offers addClass. Their APIs vary, but it’s in there somewhere. We could create our own library with our own version of addClass. But that has disadvantages:
  • we have to write it/test it ourselves or copy it from somewhere
  • we have to maintain it
  • for people extending Bespin, there’s that much more surface area that they need to learn
  • we need to write docs for it
  • we can’t use fancier things people create (overlays, trees, etc.) without porting them
  • if people already have a library on their page, our utilities will add additional size
There are probably other disadvantages as well. The only advantages I see to rolling our own are:
  • we get exactly the functionality we need and no more
  • we maintain our own release schedule for it
We are considering a “best of both worlds” approach as well, if we feel like slimming down Bespin Embedded “Drop In” (the prepackaged single .js file) even further: we take just the functionality we’re interested in from a library (jQuery) and create our own mini library that uses the exact same API. Our modules/build tooling can make it transparent to switch between the mini library, the full library and one that is already on the page.

Why jQuery?

As I mentioned earlier, when it comes to utilities the libraries all offer a very similar collection of functions. We don’t want to use a library that “leaks” onto the page, either through the creation of globals or the extension of built-in prototypes. That still leaves a number of choices. We evaluated some, but ultimately decided on jQuery because:
  • It’s very popular, which increases the chance that it’s already on the page (and decreases the size of Bespin)
  • many people are already familiar with it
  • there’s lots of good documentation available
  • there are many decent open source plugins that people can use when extending Bespin
It’s worth noting that these are not technical reasons to use jQuery, and these largely only matter because jQuery is popular and Bespin is intended to be used on other peoples’ pages. The choice of jQuery for Bespin is not a technical choice. We certainly like jQuery, but we like the other libraries as well.

Not just jQuery

One more important point: Bespin Embedded is still designed to be easily built into a self-contained .js file. The current code in our repository puts only one name on the page (bespin) and everything else is hidden away conveniently inside of there. The next release of Bespin Embedded will be less than half the size of the previous release, even with jQuery bundled in. So, Bespin will be a good addition to your application, regardless of which JavaScript library you might use for the rest of your code.

Summary

Bespin has had unusual and competing requirements along the way and as we’ve zeroed in on exactly what Bespin is and will become, we’ve changed our infrastructure to match the needs of the project. We’re really excited about how far we’ve come since “rebooting” the project and are looking forward to these next few releases that lead up to a “1.0” of the Bespin project.

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.

JSConf 2010 Day 1

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.

CommonJS: the First Year

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.

Exploring Google Closure: a2div, GTUG joint meeting

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!

a2div meeting #1: SproutCore with Majd Taby

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.

Introducing a2div web development user group

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!

Update: Date tentatively changed to the 4th Thursday based on conflicts on the 3rd Wednesday.

Project Bespin needs *you*

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!