Introducing the Web Console

David Dahl has been leading the work on Firefox 4’s Web Console feature and has blogged about the work along the way. Over the past month, we’ve landed a whole bunch of improvements to the Web Console in Firefox 4 Beta, and I wanted to give my take on what the Web Console has to offer for web developers.

What is the Web Console?

I first learned to program a computer in BASIC on a TRS-80 Model III. I’m dating myself there, but oh well. Believe it or not, my first programs didn’t always work the way I intended them to and, surprisingly enough, they still don’t. I had two main tools to help me figure out what was going on: a “read eval print loop” (REPL) and “print”. Using the REPL, I could type in simple statements and get immediate results, as a way of testing that how I think an individual operation should work is actually how it does work. Using “print”, I could have my program display certain values along the way so that I could make sure that they met my expectations while the program was running.

Even today, REPL and print continue to be two simple and fundamental tools for learning how a system works and troubleshooting problems. The Web Console gives you these two features for web pages that appear in Firefox.

The Web Console atop a popular website

You can see the Web Console for yourself today by downloading the Firefox 4 beta.

The Log

When you open the Web Console from Firefox’s Tools menu (or using the ctrl-shift-K/cmd-shift-K keyboard shortcut), you’ll see a panel drop down from the top of the content area of the browser. In the current Firefox 4 beta release, the panel is empty when it first opens, but the Firefox 4 final release will collect up logging messages even while the console is closed.

If you open the Web Console and then go to a page, you’ll see a whole bunch of output. Typically, there will be many “Network” requests listed. Sometimes, you’ll see CSS or JavaScript errors displayed. It doesn’t take long for that output to quickly become overwhelming, so we’ve got a simple solution in place to deal with that: filtering. Just above the log output area, there are a number of controls that you can use to pare down the output and see just what you need to see.

  • The Net, CSS and JS controls determine which of those types of messages from the browser should appear in the output.
  • The Errors, Warnings, Info and Log controls determine which JavaScript-generated messages should appear in the output window (see “The console Object” below
  • Finally, there’s a search box to filter the output based on whatever you type there

Using these controls, you should be able to quickly zero in on the messages that will help you debug a problem with your page.

Network Details

The “Network” requests that appear in the log output show you the URL to which the request was made. But what do you do if your JavaScript made a request to the right URL, but the data that came back isn’t what you expected? If you click on a network log entry in the next beta of Firefox 4, you’ll get a panel with a bunch of details about the request:

The network request details panel.

With the request and response headers and body and the cookies from the request, you can dive deep into the requests made from your web pages.

The console Object

If you’ve used the excellent Firebug extension (more on Firebug below), you’ve quite possibly encountered its “console” object that is available to JavaScript. console provides a number of useful methods, including a set used for logging information: log, info, warn, error. All four methods work the same way and represent different levels of information logged from log as the lowest level to error as the highest. You can pass in multiple arguments and they will have their string representations glued together for the output. For example, if the variable food is “avocado”, then console.log(“My favorite food is”, food, “and its info is”, anObject) will output “My favorite food is avocado and its info is [object Object]“.

By strategically using the different logging levels, you can make it easy to focus on just the messages that matter to you using the filter controls.

One more note: for Firefox 4, we’re playing it conservatively with the console object. If one is already defined on the page, we won’t override it. As of this writing, there is a bug that prevents the console from working properly on sites that define their own console object, but you can bet we’ll have that bug resolved soon.

The JavaScript REPL

Read Eval Print Loops are fantastic for figuring out how a language or environment works and for testing things quickly. The Web Console features a REPL for JavaScript that gives you access to everything on your page. For every expression you type in, the Web Console will automatically output the result of that expression. That means you can use it as a simple calculator:

6*7=42, but you knew that

For your convenience, the Web Console will automatically try to fill in variable and function names that it knows about:

Automatic completion

By using the up and down arrow keys, you can also cycle through the history of commands that you’ve entered.

You can directly access variables that are on the page:

Here we see that jQuery is on the Reddit home page.

Note that variables that you define in the Web Console are not automatically exposed to the page. If you would like to change a variable on the page, you just need to put “window.” in front of the variable name. For example, if you enter the expression “window.foo = 1″, then the variable “foo” on the page will change to 1.

With access to jQuery and knowledge that Reddit has an element on the page with an id of “header”, it becomes a simple matter to remove the header from the page we’re looking at:

Reddit with the header hidden

One more note about using the REPL: if your expression returns an object, the console will just show [object Object] currently. However, you can click on [object Object] and see the object inspector:

The object inspector looking at a jQuery node list

One nice feature of the object inspector is that it shows you a snapshot in time of the object. You can click the “Update” button if you want to see the current contents of the object.

Firebug

The Firebug add-on has millions of users and has been making web development easier for years. If you’re one of those users, you’re probably wondering why the Web Console exists when Firebug already provides a console and much, much more. Back at the beginning of this post, I talked about how useful a REPL and print are in debugging, experimentation and learning. These things are so fundamental that we wanted them to exist in Firefox with no add-ons required.

Consider this case: you’re a web developer and you have a distant user of your application. They’re running into a problem with your app. They can tell you what’s on the screen, but they have no way of sharing a view of what the application has done to that point. If you have useful logging messages in your app, you can ask the user to copy the console output into an email message and send it to you, all without requiring them to install an add-on.

The Web Console is not a replacement for Firebug, but it will be a great tool to have in a pinch.

What’s Next for the Web Console?

We’re still in the middle of the Firefox 4 beta test cycle, so you can expect to see additional improvements and polish as the beta progresses and we head to the release of Firefox 4. If you’d like to get involved and help make the Firefox developer tools beyond awesome, talk to us! Discussion about the Firefox developer tools comes on the dev-apps-firefox mailing list/newsgroup and in realtime in the #devtools channel on irc.mozilla.org. I’m also happy to receive feedback by email.


Mozilla DevTools coming out of hiding

OK, we weren’t actually hiding, but we have been spending a lot of time learning, coding and figuring things out. We’ve been so busy creating things that we haven’t had much time to talk about the things we’ve been creating.

A little more than a month ago, I announced here that Mozilla officially has a Developer Tools group again, with tooling for both Firefox and the open web in general in our sights. Much of our group is new to Firefox development, and so the past few weeks have been quite an education in the processes used to ship a feature-filled, open source, stable browser to 400 million+ people. And that’s just the process. There’s the technology, too, and the Bespin team had to learn a lot there as well. The people who have been working on Firefox for a long time have been great mentors in getting us up to speed.

Now that we’re getting an idea of what the developer tools in Firefox 4 look like, the devtools team is going to be a lot more public about what we’re doing and invite the community to join in and help us make tools that make the web a better place. Keep on eye on Planet Mozilla or dev-apps-firefox (newsgroup/mailing list) in the coming weeks to learn more about what we’re up to and where we’re going next.

Also, one more word about Firefox 4 dev tools: Firebug 1.6b1 is out and is awesome. If you’re a web developer using Firefox 4 beta, you should definitely check it out.


MichiPUG’s 5th Birthday!

The Michigan Python Users Group turns 5 with the September meeting. Woohoo! Come and celebrate with food and lightning talks!

Thursday, September 2nd at 7pm at SRT Solutions.

RSVP today to save a spot! While you’re at it, pitch in with a lightning talk of interest to Python users.


A Renewed Developer Tools Focus at Mozilla

When I joined Mozilla at the beginning of 2009, I was a part of Ben and Dion’s “Developer Tools Lab”. As part of Mozilla Labs, the plan was basically that we’d try out a bunch of ideas for developers and see what we could learn from them. The biggest of those ideas was the Bespin project, into which we’ve put a good deal of effort. When Ben and Dion left to join Palm, the Bespin project was rolled into Labs directly and the various other bits of experimentation fell by the wayside.

Meanwhile, Mozilla has been gradually adding to developer tool support in Firefox through Jan Odvarko’s work on the amazing Firebug and, more recently, work that Rob Campbell and David Dahl have been doing on some new tools that are directly part of the Firefox product.

Bespin is a very interesting project on its own, but for quite a while I’ve viewed it as part of a bigger picture, which is why we’ve put so much effort into our “Embedded” releases which make it easy to make Bespin a part of many “bigger pictures”. Likewise, I think that developer tools and platform improvements that ship with Firefox will ultimately be part of a bigger picture that will help developers build the kinds of powerful apps that HTML5 makes possible.

I’ve taken on a new role at Mozilla as the manager of a unified Developer Tools group that lives within the Firefox product organization. Though we’ll likely do some experimentation that may show up under Mozilla Labs, our focus in this new group is much more on shipping great, real-world-ready developer tools. I’m really excited about this change, because we’ll be in a better position than before to make our big picture dreams for dev tools come true. I’m also really excited to be working with such a talented group of people including the Firefox/Firebug engineers mentioned earlier and the Bespin team (Joe Walker, Patrick Walton and our interns for the summer Julian Viereck and Mihai Sucan).


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.


Ending SlowNews Experiment #1

The great thing about experiments is that they teach you things. Trying something and having it not work is not a failure. It’s information.

I still believe in what I said in my “What is SlowNews?” post: the move toward real-time random links and news is a bad move, in general. That basic part of the experiment is not why I’m dropping my weekly SlowNews posts.

This blog is more than 8 years old, and I’ve always posted to it for myself. I’ve posted thoughts that I wanted to work out in writing. I’ve posted things that I wanted to share because I thought they could help people. I’ve posted about things that I thought were interesting and worthy of additional commentary. I thought these SlowNews postings would fit in that latter category.

But, I haven’t particularly enjoyed putting those posts together in the format I’ve been doing. While it is a chance to reflect on the happenings of the week, what I’ve done so far has felt too random. There’s too little narrative. So, for now, SlowNews goes back onto the idea shelf, waiting for a better implementation.


SlowNews: Declarative Events in JS, Redis, Mono, Facebook x2

Ending This SlowNews Experiment

This is the last issue of this SlowNews format. I may or may not try a new format. I’ve written a bit more about why.

Reactive JavaScript: Declarative Programming for Events

When a problem space is well understood, adding declarative forms can really save on a lot of work. Here’s an interesting look at the Reactive Extensions to JavaScript, created by the team at Microsoft that creative the Reactive Extensions for .NET. I didn’t find the syntax there appealing, but the ideas are interesting. The Flapjax project provides a nicer looking syntax, but requires a compilation step to pure JS (the compiler is written in JS and can run in the browser). I like the Flapjax tutorial reference to spreadsheets, because spreadsheets provide a great model for certain kinds of declarative work and tying declarative structures with additional imperative programming is very powerful. One of the reasons we chose SproutCore for Bespin is the ability to bind views directly to data so that the two automatically stay in sync.

A Collection of Redis Use Cases

Mathias Meyer’s Collection of Redis Use Cases provides a great collection of examples to give you an idea of where you might apply Redis in your own applications. In the “Not Only SQL” movement, Redis is a good tool to have in your toolbox.

Using node.js To Bootstrap a Server from Client Code

Dion Almaer wrote up the experience he and Ben Galbraith had in creating the Project Appetite site for Palm WebOS developers. Following the modern style of having the client do presentation and the web server just providing an API, they could work on client and server independently. It turns out that a quick way to get a server up and running was just to reuse client-side code on the server (in this case, using node.js).

Harmony: JavaScript Testing in Ruby

Harmony takes advantage of Johnson, a Ruby to JavaScript bridge and lets you write unit tests for your JavaScript code in Ruby. It’s not unreasonable to ask why, given that you can write the tests for your JavaScript code in, say, JavaScript… but, on first glance to me, the benefit here would seem to be that you can test server and client bits together conveniently.

Making Facebook 2x Faster

Jason Sobel gives the rundown on a 2009 project to make Facebook’s pages load twice as fast. This is a good account of what it can take to make a speedy site.

Thoughtworkers Subjective Impressions of VCS

Having trouble picking a version control system (VCS) for your next project? Martin Fowler has posted some general impressions that Thoughtworks people have picked up while working on client projects. I’ve worked on a variety of projects using a variety of tools (RCS, CVS, ClearCase, Subversion, Bazaar-NG, Mercurial, Git) and Martin’s roundup meshes pretty well with my own impressions.

Canviz: graphviz on Canvas

Need to produce a directed graph? Only care about the “modern” browsers? Then canviz is for you! Canviz is open source (MIT license) and lets you create a variety of graphs just as you can with the graphviz project, but entirely client side.

HTML5 Web Sockets Spec Reimagined

Tim Bray dove into the HTML5 spec and found a number of new features that he liked. He also went deep on the Web Sockets spec in particular, going so far as to produce an alternate version of the spec to make things clearer. Looking at Tim’s alternate, there’s a lot that he left alone.

State of Mono

Miguel de Icaza has written up an overview of what’s been going on with the Mono project. It looks to me like the Mono platform is still evolving quite nicely. If you happen to be near Ann Arbor on Thursday, February 25th, you can learn about the state of .NET web development at the a2

meeting.

10 Online Code Editors

There has been a lot of development in web-based code editors, and I think this space will just get busier as time goes on. Here’s a roundup of 10 online code editors, including screenshots. ObDisclaimer: I’m the project lead for Bespin.

Interesting Releases

> list
11 goto 11

Top 11 ways to deploy a website

11. rsync
10. Webistrano
1. Your foot!


SlowNews: IM in JS, XHP, ePub

Ajax IM: Open Source IM, Totally JavaScript

The MIT-licensed Ajax IM library lets you add instant messaging to your site and features a new node.js server side. This is certainly a good use for an async framework like node! The one thing I noticed while sitting on their site is that it has an unpleasant way of tacking things onto your browser’s history without actually going anywhere. Should you want to roll your own messaging, you could fire up Faye on node.js and use your favorite Bayeux client side library.

XHP: E4X for PHP

Did you know that some implementations of ECMAScript allow you to embed XML right in your JavaScript? I’d imagine many people don’t, because folks in the “real world” need to make sites that run on IE. Well, if you’ve been pining for the ability to embed XML right there in your code, or if you’ve been looking for a chance to turn PHP inside out, you’re going to love XHP, which Facebook recently open sourced. At the very least, you’ll go read about it and then learn about XHP’s implementation performance characteristics from none other than Rasmus himself.

wtfjs

OK, so I’m a well-known booster of JavaScript. But, you’ll never hear me say that it’s perfect. Every language has its warts, and wtfjs has an enjoyable collection of JavaScript’s.

LESS.app Now With Automatically More Less

LESS.app lets Mac users write their CSS in LESS and have that LESS automatically turned into valid CSS as they work. Languages like LESS are cool, because they have an opportunity to influence how the actual standards will evolve.

ePub in JavaScript

The ePub standard looks to be gaining serious momentum as an ebook format, albeit without the support of the top selling ebook reader to date. There has been a good bit of work done to create usable ePub readers in JavaScript, and Michael Mahemoff has a good roundup over at Ajaxian.

> list
11 goto 11

Top 11 JavaScript Features (from wtfjs)

11. "string" instanceof String; // false.
10. typeof NaN // number, of course.
1.

(function(){
  var x = y = 1;
})();
alert(x); // undefined
alert(y); // 1 -- oops, auto-global!


SlowNews: HipHop, Redis, Riak, Weave, Homebrew

HipHop Compiles PHP to C++

What do you do if you have to serve up 400 billion PHP page views a month? You don’t, because you’re not Facebook. But, for Facebook speeding things up can make a real difference on their compute costs. Their newly open sourced tool HipHop translates PHP to C++ and then compiles the result with g++. Net benefit? Apparently 50% less CPU usage. Nice!

Also, check out Paul Biggar’s take on PHP compilation and how HipHop impacts the phc project.

Mozilla Weave Hits 1.0, Adds Developer APIs

The Mozilla Weave project recently shipped 1.0 of their Firefox extension that synchronizes information (securely and privately) between your browsers. This week, the Weave team has announced Python and JavaScript client libraries and APIs in general for accessing this data. They have web-based and iPhone clients as prototypes, which is really cool. Personally, I find the identity aspects to Weave very interesting and hope to see more experimentation and implementation of identity directly in the browser (how many more username and password systems do you want to implement?)

Disclaimer: I work for Mozilla Labs.

Redis Goes Beyond RAM

Redis is a very useful disk-backed key/value store with lots of interesting atomic operations. It’s always had the limitation that the entire dataset needed to fit in memory. antirez explains how that limitation is removed in Redis 2.0. The concept of virtual memory is lifted straight from OS theory and practice, but the application-level implementation is a better fit for Redis’ needs.

Homebrew: OS X’s Missing Package Manager

Homebrew continues to be a fairly stealth project, I think. If you’re a Mac user, though, it’s worth looking at. It’s a super simple package management system that makes it easy to install many common packages and even makes it easy to manage packages that you download and build yourself. Andre Arko posted a nice introduction.

Removing Features

Lukas Mathis has written one of the best articles about removing features that I’ve seen. It’s always tempting to keep adding more, when really adding better is really what’s required.

More On The Use of h.264

The hubbub around h.264 that I talked about in the first SlowNews issue has a great new summary courtesy of Ben Schwartz. Ben took the actual license text from various pieces of software that produce h.264 videos, making it plain as day that people creating videos and posting them online are quite often in violation of the patents. Whatever people may think of Theora’s quality, at least it is unencumbered.

Mugtug Sketchpad: Fast Painting with Canvas

If you’ve doubted the growing ability of standards-based webapps to fully replace many desktop apps, Sketchpad should sway you. As long as you’re not using IE.

Detailed Riak Overview

Sean Cribbs insists that you should use Riak for your next Rails app. I’m not likely to be created a Rails app any time soon, but this was still a good overview of Riak. I’ve personally had a lot more exposure to MongoDB and Redis than Riak, so it’s nice to get a feel for what Riak’s all about. Also worth a look: Riak now supports JavaScript-based map/reduce jobs.

Rails 3 Beta Release

I don’t intend to include beta releases or vaporware here in general, but Rails 3 has been in development for a long time and is coming out from under its merger with Merb. So, in case you missed it, here’s DHH’s post about Rails 3.0’s beta.

Free F# Book

I’ve been impressed by some of the directions in which Microsoft has taken their development tools. The F# programming language, a functional language, seems like the kind of thing you wouldn’t see coming out of Microsoft (or, at least, beyond the research prototype stage). But, it’s certainly well beyond research prototype and now you can even get a feel for F# from a new, free book by John Puopolo with Sandy Squires.

> list
11 goto 11

Top 11 Reasons Why There Was No List Last Week

11. Perhaps every other SlowNews issue has no list?

10. There was no list?

1. I forgot.