Palomar tasting event.
Voodoo Tiki God |
I am Zero Cool |
As you may or may not know, this year we started out with a very risky web site concept. Hailed by some as crazy and others as "elitist BS", either way it was pretty good filter for speakers. Some found it, others needed a little treasure map. Charles Jolley actually emailed us, provided a fitting description of himself, and asked how he could propose to speak. All we needed to say was "use web inspector" to which we received his one line response: "lol. clever." At that point, I knew he was the kind of speaker we were looking for. Charles is the creator of the now famous and widely used SproutCore. SproutCore is the Rich Internet Application (RIA) framework at play in such applications as MobileMe from Apple and Bespin from Mozilla (also a JSConf Sponsor 2 years running). Charles currently works for Apple as a senior front end architect, which is without a doubt an impressive title.
Charles plans on demonstrating the HTML5 love that SproutCore 1.1 comes packed to the brim with. Taking RIA and binding it with HTML5 - Brilliant! Charles also has some great things he is planning on demonstrating that will really blow your socks (or boots as the case maybe) off. This is going to be quite the presentation especially for building complex and very rich internet applications. We might even have some buccaneers with contrarian view points strategically placed in the audience to heckle him... You will have to be there to find out more!
Posted on January 29th, 2010 by Kevin DangoorCommonJS: 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:
- must work with ES3 syntax (destructuring could actually be useful, but we’re not going to do it)
- modules should have self-contained namespaces and be explicit about data the want to export
- it should be possible to make modules tamper-proof, though this is not a requirement
- 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
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.
Comments are closed.
What a year for CommonJS and JavaScript in general. One has to wonder what 2010 holds for JavaScript and the JavaScript community!
Excellent overview of the metaprogramming capabilities of Ruby and JavaScript and how each relates to the other. Great for porting deep knowledge from one language to the other. Similar to a rosetta stone for metaprogramming, there should be more of these type of comparisons to ease language transitions.
Version 1.1 brings some substantial changes to jQuery BBQ. I reorganized the plugin code substantially, which allowed the core
window.onhashchangeevent functionality to be broken out into a separate jQuery hashchange event plugin.The end result is that while jQuery BBQ is still just as awesome as it’s always been, if you’ve wanted just a very basic, streamlined, normalized, cross-browser jQuery hashchange event without all the extra awesomeness that BBQ provides, it’s now available separately as jQuery hashchange event.
In addition, BBQ now has a new $.bbq.removeState method, which a few people have requested, as well as updated unit tests that utilize the most recent version of QUnit.
Check out the jQuery BBQ project page as well as the new jQuery hashchange event project page for more information, and let me know what you think!
Is there anything that the amazing Ben "Cowboy" Alman doesn't already have done? The judges think not.
JSpec is a extremely small, yet very powerful testing framework. Utilizing its own custom grammar and pre-processor, JSpec can operate in ways that no other JavaScript testing framework can. This includes many helpful shorthand literals, a very intuitive / readable syntax, as well as not polluting core object prototypes.
JSpec can also be run suites in a variety of ways, such as via the terminal with Rhino support, via browsers using the DOM or Console formatters, or finally by using the Ruby JavaScript server which runs browsers in the background, reporting back to the terminal.
Features
- Allows parens to be optional when using matchers to increase readability
- Assertion graphs displaying how many, and which assertions passed or failed
- Async support
- Envjs support
- Mock Ajax
- Fixture support
- Modular extensibility via Modules and hooks.
- Cascading before/after/before_each/after_each hooks
- Default / customizable evaluation contexts
- Does not pollute core object prototypes or global scope
- DOM sandbox support
- Extremely simple and intuitive matcher declaration
- Framework / DOM independent
- Grammar-less option (for those who dislike JSpec's syntax)
- Great looking default DOM theme
- Highly readable custom grammar
- Nested describes
- Optionally display failures only, speeding up development
- Over 45 core matchers
- Profiling
- Proxy assertion or 'spy' support
- Method Stubbing
- Rhino support
- Ruby JavaScript testing server
- Several helpful formatters (dom, console, terminal, ...)
- Shared behaviors
- Ruby on Rails Integration
- Tiny (15 kb compressed, 1600-ish LOC)
- `jspec` command-line utility for auto-running specs, and initializing project templates
Cheat Sheet
Using the bash cheat sheet library you can get quick terminal access to JSpec's cheat sheet and hundreds more.
cd /tmp && git clone git://github.com/visionmedia/ch.git && cd ch && sudo make installch jspecMore Information
- Google Group http://groups.google.com/group/jspec
- IRC Channel irc://irc.freenode.net#jspec
- Get the TextMate bundle
- View the Readme for more documentation
- Rails / JSpec Integration
- Drupal / JSpec Integration
- Featured JSpec Article in JSMag
- Env.js
Authors
TJ Holowaychuk (tj@vision-media.ca)
this mini site brought to you by : visionmedia/mini
Finally a BDD library I actually like.
Note: MailStyle was originally called Shemail but was changed due to a general negative response to the name from the public.
Background
Writing inline styles for HTML emails is dull and boring but unfortunately a necessary evil. Rather than do it by hand we thought it would be nicer to let our app do it for us. So we wrote MailStyle.
Enter MailStyle
MailStyle allows you to write the css for your html emails as you normally would, then writes the styles inline when you send your emails. It also makes sure that your image paths are absolute rather than relative.
First off, hilarious original name.
Second off, thank you to Jim Neath for making email styling less crappier than it actually is.
0votes0answers3views-3votes0answers27views0votes0answers6views2votes2answers60views0votes2answers14views0votes3answers22views2votes2answers31views1vote2answers16views0votes2answers25views2votes6answers56views3votes4answers33views0votes4answers47views0votes4answers74views2votes2answers32views2votes3answers25views3votes3answers42views3votes3answers51views0votes3answers94views0votes1answer30views1vote7answers71views1vote9answers106views3votes3answers62views2votes3answers59views0votes1answer17views0votes1answer33views2votes4answers64views1vote2answers50views3votes1answer45views3votes2answers26views1vote2answers30views0votes1answer33views-1votes1answer33views3votes3answers45views1vote2answers43views1vote5answers60views3votes11answers126views1vote5answers38views1vote4answers66views4votes13answers130views1vote1answer24views4votes6answers72views3votes3answers67views1vote3answers65views2votes3answers40views5votes3answers55views1vote3answers49views0votes3answers57views0votes2answers38views
Looking for more? Browse the complete list of questions, or popular tags. Help us answer unanswered questions.
Community driven home brewing advice. Absolutely awesome.
Curator of JSConf US
Co-Curator of NoSQL East
Polyglot developer at OurParents
President of Iterative Designs
Author of Naked JavaScript
Devoted beer geek
