1. The web development community is desperately looking for an answer to it's problems.
2. No solution will be well received unless it involves real change across ALL the major browsers.

When confronted with these alternative language tools or even the new proposals for ES Harmony, people keep saying "syntax isn't the problem". I personally agree with that, but I'm also realizing it's the wrong mantra to respond with. Syntax is a problem. But it's not the most important one. It's not the one that's causing us the most pain right now. The real problem is browsers. Period.

We want to do more. We want to bring kickass apps to the web. But we can't because we don't have the capabilities. Dart doesn't solve that problem. Better languages will ensure that more people can work on the web in the style that they're comfortable with. Better tools will ensure that we can push our current capabilities to the limit, faster and easier. But it doesn't give us new capabilities. Only an agreement between all browser vendors to make their products *better* can do that. Anything else is just a band-aid.

I'm reminded of that twitter rant by Joe Hewitt a while back.

"I want desperately to be a web developer again, but if I have to wait until 2020 for browsers to do what Cocoa can do in 2010, I won’t wait."

That's the real issue. And meanwhile, introducing new languages has it's own challenges. We're fighting a big problem. But we're doing it by creating new ones. Maybe those new ones are preferable to some people. But as programmers, I think we can do better. Part of our job is to look for the most elegant solution to a set of problems. One that is simple, powerful, appeals to the widest range of people and is as forward thinking as possible. Why haven't we been able to do that in this situation?

To me, that solution is for browser vendors to improve the javascript standard and then improve their browsers. That's all anybody really needs. And by that I don't mean that it's the only solution or that it's what "everybody wants". I mean that it's the most elegant solution to the problems we're facing. It leaves the door open other ideas as well, but it's the minimum that we need to move forward. And I'm not sure why everybody hasn't caught on to that yet.

But with growth comes growing pains. Node has matured as a project. It has a direction and a vision. This has happened organically and not everyone is aware that things are different. And I think we need to start broadcasting that direction and protecting that vision. I got motivated to write this blog post to offer some suggestions that could help ease some of the pain points of the community.

Most of the node community is centered around the mailing lists (nodejs and nodejs-dev). I've been following the lists since the beginning. First as a lurker, then a more and more frequent contributor. There is lots of activity and some very smart people hang out there and respond frequently to questions. What's even nicer is that Ryan Dahl and other core members actually post frequently to give good info on what's happening with node. In short, it supports the growing node community pretty well in my opinion. At least until recently.

The most recent influx of newcomers is excited about node too. But they're not exactly satisfied with it's current state. They want to discuss possible "improvements", and they're pretty vocal about it. They want to make it "easier" to write asynchronous code. They start talking about threads and continuations and forking the v8 engine. But these things don't fit the current vision for node. And it's creating lots of static.

I think node is at a point where the community could really benefit from some light curation. The primary thing that is necessary for node to take over the world is adoption. But node is growing really fast and this means more time spent helping people get started or helping them understand why things are borked when they did it wrong. We should be making it as easy as possible to get into node and smooth any rough edges.

Right now one of those edges is lack of info about the project itself. When people get involved with node it starts their imagination going. This is partly because it's so different from other server environments. It's a joy to work with compared to others, like certain Pretty Horrible Palindrome languages we won't mention. And also because javascript doesn't come saddled with all of the baggage these other languages have. We can rethink I/O entirely because it has very few preconceived notions about it (XHR being a minor counterpoint). Couple that with the rapid pace of innovation in javascript engines and it's easy to get excited about "a better programming experience".

This is how node started. Ry was fed up with how slow other platforms were when it came to networking and I/O. So he set out to change things with some different ideas. But it feels like we're past that phase of innovation now. People want to rethink everything. Even stuff that ain't broken. These days the node team is focused on stability and completeness. And it doesn't pay to keep blue-skying about javascript features that don't exist. That time will come around again, but for now it's on the back burner.

This is NOT a bad thing. Node has a pretty solid foundation built on some really nice ideas. The next step to world domination is making sure you can rely on that foundation working correctly and consistently. And filling in the holes. But this needs to be made clear to folks early on. For example:

Most people are surprised to learn that SSL/TLS is still pretty spotty in the current branch of node. I think most would readily agree that this task trumps unnecessary things like exploring other concurrency models. But the point is, there's no way they could know because it's not written down anywhere. Or maybe it is and I just haven't seen it. That's telling in an of itself because I try to stay pretty abreast of node updates.

There are several things that could be done to help people learn about the state of the project:

A Roadmap

Nothing fancy, just a semi-linear list of things that Ry and the group are prioritizing for node development. Something like this only updated more frequently and not buried in the list. Or like this, but with more context and some notes about direction. Put "forking v8" way at the bottom right after "Add support for making breakfast". Then at least people know where they stand if they want to propose that.

Maintain a site with more persistent info

The roadmap linked above shouldn't be a random post on the list. It could be linked there for sure. But it shoud be on the home page. Then when people wonder if "anyone has thought about adding threads", they can see that they shouldn't hold thier breath, because it's not on the roadmap. They can see what is on the list though. And they might even decide to help out :) Open source ftw.

Make resources more prominent

I went looking around for node info in anticipation of this post. I found a ton of stuff on the wiki that never gets mentioned to newcomers:

• [https://github.com/ry/node/wiki/Community]
• [https://github.com/ry/node/wiki/ECMA-5-Mozilla-Features-Implemented-in-V8]
• [https://github.com/ry/node/wiki/Hosting]
• [https://github.com/ry/node/wiki/Streams] (how current is this?)

These are not linked directly from the wiki home page. Instead when you go there, you get a long list of projects, many in various states of abandonment, and companies using node. Interesting, but only for a second. Then I want to know what it can do for me. I wanna know how to get started. Which leads to...

Embrace NPM

NPM is the default node package manager. That's a statement that some are reluctant to make. But it's true. There was a brief period where there were lots of options for getting node packages. They all had wildly different opinions and It was a glorious battle. But npm emerged victorious, and it is now ubiquitous. Except to newcomers. They hear about it pretty quickly, but it's not clear that they should be using it all the time. Instead it's relegated to third party modules and lumped in with a bunch of other "nice to haves". No sir. Put npm on the home page. Put it in the getting started tutorial. If something better comes along, we'll all promise to stay open to change. But for now, done deal.

Write a Getting Started Tutorial

Seriously, where is this? Oh it's buried somewhere on the unofficial blog and usually outdated. To be clear, the getting started tutorial should have installation, the module system, basic async conventions, npm and an http Hello World all in one place.

Talk About Why Node Is What It Is

Many people would like to know more about some of the design decisions made in node. There's been a lot of good talk about different concurrency models, how to handle I/O better, how to handle async code. There are lots of videos of tech talks and meetup discussions. Lots of slide presentations. But the fundamentals should be distilled down on a few pages for everyone to see. Kind of a mission statement for folks who can't catch up on all that stuff. The About section on the node home page is a good start but some of it could definitely be expanded upon.

Maintain an FAQ

This is related to the above, and perhaps a better alternative. Right now the only place to go to get answers is the list. Even for questions that have been asked and answered several times. No wonder certain core people are starting to go nuts. Some things to include:

• why node chose the event loop model
• explain the node callback convention
• the philosophy behind streams
• why we're sticking with standard v8

These are the questions that get rehashed on the list on average once a week. We should be able to link this and just move on.

Get a Handle on The Mailing Lists.

Node is only going to keep growing in popularity. The lists will get more and more traffic, and it will become impossible to keep the signal to noise ratio high. Unless we get out in front and plan for that. See the lists for rails, django, etc. Awful. It doesn't have to be the iron fist type of moderation. But give people multiple outlets and let them know what's appropriate. I propose something like:

• node-users - Questions and comments about using node, announcements and that type of thing. Most of what the nodejs list is now. This should stay focused on productivity in regards to producing working code. This is where newbs start and where gurus can do the most good spending time.

• node-discuss - Anything. Literally anything folks want to talk about. It can be about node, related to node, inspired by node. Who cares. The upside is that it still feels like part of the node community. And no one will tell you to Please Stop. Node enthusiasts can chat until they're blue in the face. And if you're overwhelmed by the volume of chatter, it's your own fault. You should probably block it from your mail client.

• node-dev - Concrete talk about development of node itself. This includes patches, bug reports, discussions of roadmap features, etc. The node core guys will hang out here a lot so it needs to stay pretty focused. That means actual moderation. It's not evil to restrict or moderate, and it's doesn't inherently restrict openness. It's just practical. Let's use it so Ry and company can get some work done.

The trick to all this is gently nudging folks to the right list. In my opinion this doesn't usually require being rude or laying the smackdown. And besides, that almost never works. It creates more noise as people start arguing about internet etiquette (guilty). It's simply a matter of pointing people to where they can read the list guidelines and then forwarding the post to the other list. No need to reply further. If someone decides to continue on that topic, they should be talking to themselves.

Note:I purposely haven't mentioned the irc channel before now, #node.js on irc.freenode.net. It's a great resource but not everyone is inclined to venture there. Plus the number of users has seemed to plateau which suggests that it's not growing as quickly as the mailing list.

Identify the Community Leaders

This is perhaps the most controversial suggestion I've pushed before. Ry has been crowned BDFL of node. And he's pretty awesome at guiding the development. But the man doesn't like to talk (no offense). I like to think he's a man of action and few words. His posts on the list are usually short, to the point and impactful (see here).

There are others who have been big promotors of node from the beginning. They have lots of influence on the way things go. They talk to Ry frequently and can often relay his thoughts. They make prodigious contributions in both code and knowledge. These people frequently try to guide the community even right now. They should be the ones doing the gentle nudging I mentioned before. But they can't do the best job of it because they haven't been given the authority. Or they won't accept it.

I won't say more on this topic because it's really something that should be discussed between the core guys. But I'd like to see it happen.

So ...

I hope at least some of this is helpful. I plan to try and do some of it, like the Tutorial or FAQ, myself in the coming weeks when I find time. Considering how long this post ended up being, I'm sure I can find a minute or two.

It's one of those books that keeps popping up when people give you advice on how to program better.  And here it is for free!  But due to my fear of a future that includes bad eyesight, I can't try and read this online.  What I really wanted was an ebook version for my handy dandy B&N Nook.

Alas, Barnes and Nobles wants to charge me for this and so does Amazon. And to add insult to injury, they don't even have the ebook version.  So I set about doing it myself.

The first obstacle was finding some utility that would convert the html version to a format that was compatible with my nook.  After some searching I settled on Calibre.  It's actually a full featured eBook manager, and it does a bunch of other stuff but I'm really just interested in the conversion tools, which are pretty extensive.

Obstacle #2, Calibre won't just take the url and pull in all of the pages.  It wants a downloaded local version of the html files.  Such a bother.  But this is also easily remedied.  I've used pavuk on several occasions in the past.  It's an awesome little web crawling utility with a ton of configuration options.  I just point this at the table of contents page and tell it to download all of the linked html pages.

pavuk -dont_leave_site -dont_leave_dir -asfx /
"html" http://mitpress.mit.edu/sicp/full-text/book/book.html

The only issue here is pavuk is a commandline utility.  This is a tech blog, so if that scares you, I officially don't care. If you're on a Mac you can get it from Macports and I recommend Porticus.  But you can substitute pavuk for whatever little app you can find that will download these files for you.  If you're on Windows you'll probably end up with a virus or malware of some kind.  You've been warned.

Now I have a nice folder called sicp_book that has all the html files in it.  It's easy to add this to Calibre as an eBook by selecting the table of contents file (the same one in the above link).  Calibre is smart enough to pull in all of the other files and create a cohesive ebook entry.  Why it couldn't just do this with a link to the online table of contents I can't say. If all software did what I wanted, I'd probably be an accountant or something.

Right now, in my Calibre Library folder, I have a zip file with the html in it that represents my ebook.  Calibre can read this just fine and I think the nook could too.  But what I really want is the open ePub format.  That's why I needed the converter.  So using the conversion tools in Calibre, I select the Structure ebook, select html to epub conversion and hit Go.  No fuss, no muss.

I end up with an ePub file right next to the original zip file.  I drop this on my nook over USB and I'm in business!

Total time, 20 minutes and total cost $5.  I donated that to the Calibre guys.  I try to pay for useful software.  It's hard work, and one day I'd like to ask people to pay me for some useful software I write.  It's all about Karma. I would pay $10-$15 for the ebook too, but I wasn't given that option.

Anyway, I'm not clear on the Fair Use rules of the license or I would just post a link to the file.  But seriously, this took 20 minutes.  If you're bothering to read this blog, you've probably got enough ingenuity to get this going.  I'll definitely be using it more often.  Need to find a way to automate things a little more first.

Debugging Segmentation Faults

Previous versions of libxmljs were rife with segfaults that would pop up without warning. There are lots of reasons for this, but the most common had to do with not following best practices with the v8 API. V8 has this notion of Handles that are used to hold references to javascript objects in C/C++ space. Among other things, this design decision gives v8 a nice way to keep track of js references and clean them up at the appropriate time. A contrived example (assume v8 namespace).

Handle<Number>
function Handle<Number>(int mynum) {
    Handle<Number> jsNum = Number::New(mynum);
    return jsNum;
}

But there's a problem with the above example, and there was a lot of this in earlier versions of libxmljs. How does this number get clean up when you're done with it? V8 recommends using a HandleScope to track local Handles within functions. That way you can be sure they get cleaned up along with the function scope.

Handle<Number>
function Handle<Number>(int mynum) {
    HandleScope scope;
    Handle<Number> jsNum = Number::New(mynum);
    return jsNum;
}

Ah, now your number will get cleaned up properly. But wait... your number will get cleaned up properly! That means that after this function exits, that Number is gone. Poof. Cleaned up by v8. And if you try to use it, you get a segfault. Version 0.3.x has this incomplete implementation and I got lots of awesome bugs from the nice folks in the node.js community.

So how do you properly use Handles but keep your returned object from getting freed? You close the scope on the object. Basically this causes the local scope to pass the Handle to the calling scope. Essentially let somebody else worry about it.

Handle<Number>
function getJSNumber(int mynum) {
    HandleScope scope;
    Handle<Number> jsNum = Number::New(mynum);
    return scope.Close(jsNum);
}

This ensures that your Handle will stay viable until you pass it back to javascript space and use it. And when you're done it'll get cleaned up as normal (e.g. when your script ends or you lose the reference to the number and it's garbage collected). I had to find every instance of these unclosed scopes and apply them properly throughout libxmljs. Pretty simple really, but if you're not aware of this, it'll cause you all sorts of headaches.

Lesson: Use HandleScope inside any function dealing with v8 Handles and Close every Handle that gets returned from the function. This includes just returning primitive constructors.

Handle<Number>
function getJSNumber(int mynum) {
    HandleScope scope;
    return Number::New(mynum);  // wrong! Number::New still
                                // returns a Handle!
}

Making Sure Libxmljs Doesn't Devour All of Your Memory

This is a bigger deal and the real reason 0.4.0 took so long. In earlier versions of libxmljs, the xml documents would never actually get cleaned up. I had people creating huge xml/html docs in tight loops over and over again. And they would watch the process memory climb until it was exhausted and then their app would crash. Bad juju. I know what you're thinking; "But javascript has garbage colleciton. What is this moron doing wrong". An excellent question. Let's explore.

V8 does in fact have a very nifty garbage collector and it works quite well. The first problem, however, is that it's pretty lazy. It doesn't run on a regular basis. In fact it only runs when it damn well feels like it. GC is expensive so the v8 team put in some fancy heuristics for determining when is a good time to do it. At a high level, this boils down to "only GC if needed". So unless v8 sees that you're using a lot of memory, the GC won't run.

So if I'm creating giant xml documents and then they're passing out of scope, why wouldn't v8 consider this a good time to take out the trash? Well that's because of the second problem. V8 has no idea that the xml document memory exists. You see libxmljs is literally a binding around the libxml2 library. The vast majority of the memory allocated by this library is done by libxml. The binding itself just provides a nice API for js to get at that xml memory. Now's a good time for a diagram:

Conceptual illustration of separate memory spaces in a node process running libxmljs.

Hopefully this diagram illustrates the problem. Only the memory in the orange and green boxes are managed by v8. But these are just lightweight pointer classes around the c structs managed by libxml. So even when you're building up 100's of MBs or even GBs or memory, v8 was only seeing a small percentage of that.

The way to fix this was fairly straight-foward. V8 gives you away to tell the GC to take that outside memory into account. The function is called V8::AdjustAmountOfExternalAllocatedMemory, and just like it sounds, it gives us the ability to increment or decrement the amount of external memory that v8 is tracking. Libxmljs now uses this function whenever new nodes are allocated or deallocated. And the result is that the GC runs more often and cleans out your memory.

The great thing about this upgrade is that it works within the v8 garbage collection heuristics. If you're not usuing a lot of memory, you won't see much GC overhead. If you are, and libxmljs is devouring your RAM, v8 will kick in and get it back to you.

One Annoyance To Be Aware Of

I hope this info is useful to folks having trouble with node addons. For those using libxmljs, there are a few side effects that look worrying but really aren't. I had to enable the custom memory management functions in libxml2 in order to be aware of how much memory is being used at any given time. For some reason this causes some random error messages to be printed whe the node process exits. It looks something like this:

Memory tag error occurs :0x100701788 
     bye
xmlMemFree(1007017B0) error
xmlMallocBreakpoint reached on block 0
Memory tag error occurs :0x100701798 
     bye
xmlMemFree(1007017C0) error
xmlMallocBreakpoint reached on block 0
Memory tag error occurs :0x100701418 
     bye
xmlMemFree(100701440) error
xmlMallocBreakpoint reached on block 0

It's annoying, but can be safely ignored.

When I do get the urge to write, nothing derails it faster than getting irritated with the actual writing process.  Getting your thoughts onto paper should be the easy part.  The hard part is ensuring that those thoughts don't make you look like and idiot.

So this blog post serves 2 purposes.

1. Announcing that I'm going to be putting more time into blogging.
2. Starting to lay out a plan for making blogging less painful

First off, let's get a feel for why the current experience isn't working.  Here's what my current blog interface looks like.

Not too shabby looking right?  I'm running the blog app that comes with the Axiom Stack framework.  I've written about Axiom Stack before and I think it's pretty sweet.  I substituted the fckeditor for wymeditor, because it produces more standard xhtml.  This is a nice addition for Axiom Stack because it uses e4x to parse and manipulate xhtml on the back end.  But there loads of problems here (no offense to the axiom software guys, this is a free blog app that's really just meant to be an example).  The rest of this blog focuses on the most egregious offender.  The WYSIWYG editor.

WYSIWYeG: or What You See Is What You (eventually) Get

WYSIWYG editors are terrible for any significant writing.  The behavior is often inconsistent.  They're often buggy.  And you spend a lot of time fiddling with toolbars to get your content to look the way you want.  Or worse yet, you have to flip over to the dreaded HTML view to fix things.  However, they've become very popular on the web for 2 reasons.

1. They give the user lots of controls for doing other important things, like working with tables, links images, bulleted lists, etc.  All those other things that make up "content".  In short, wysiwyg's give us an environment similar to (or at least inspired by) Microsft Word and other desktop word processing software.
2. It's a hell of a lot better than writing HTML by hand.  HTML is the language of web content, but it's not what you want to be thinking about when you're writing.  For instance just making one word bold in that last sentence requires 17 extra keystrokes than normal (I prefer <strong> to <b>, don't you?)

There are good things about wysiwygs but my biggest complaint with the one's I've used is that none of them hide the HTML well enough.  There are always quirks that remind me that I'm dealing with code.  And that code needs to be formatted properly or I'm going to have issues.  What I want is a language that allows me more flexibility with my content without shoving HTML in my face.

As far as I can tell, that's Markdown.  Markdown is gaining a lot of traction as a language for facilitating written composition on the web.  You just write like you would normally, double newline for paragraphs, simple markers for formatting. So this:

This paragraph serves to *emphasize* some of the nicer features of markdown.  It is _not_ meant to be a full-fledged [tutorial](http://daringfireball.net/projects/markdown/basics)

Produces this:

This paragraph serves to emphasize some of the nicer features of markdown. It is not meant to be a full-fledged tutorial

The key feature with markdown is that you can write html if you need to.  But if you don't, you'll never see it, and you can still do the usual formatting of your content; bold, italic, lists and links.  99% of blog content is made up of words and these simple elements.  That should be easy.  And with markdown, it will be.

So my first goal is to replace wymeditor with a decent Markdown editor.  As it turns out, a cursory google search couldn't find any that do what I want.  Which is to provide a native markdown interface, syntax highlighted, with a function that will preview it in HTML.  So that's my first project on the road to a better blogging experience.

Other posts in this series follow the changes I'm making as well as touching on anything else I run into that's interesting.  Other stuff on my list include:

• Better integration and support for code snippets
• Easy dictionary look up
• Easy image inserts (uploaded to my server)
• Re-usable formatting elements

Most of this stuff can be easily accomplished with a few plugins in popular systems like Wordpress or Movable Type.  But this is my technology blog.  We're looking for something a little different here.  Hopefully future installments will be more interesting than what this post turned into.  But hey, give me a break, I haven't done this in like 5 months.

I don't write much Java.  I'm all about dynamic languages (hence the Uneducated tag).  But sometimes I have an opinion on things I don't know a whole lot about.  So here are my thoughts.

I ran across a proposal to eliminate checked exceptions in Google's experimental noop language.  I think this is a good forum to discuss the issue because the language doesn't have any baggage that comes with worries about backwards compatibility and that type of thing.  We can talk about the problem that checked exceptions try to solve and thus think of new ways to approach that problem.

Anyway, I left a comment there and I'm just going to reproduce it here for posterity and possible discussion:

I've been reading a lot about checked vs. unchecked exceptions lately. This isn't my field, but I'd just like to offer some questions/comments.

Quick question. With the above proposals (original and gabrielh), how would unhandled runtime exceptions propogate? Since they aren't explictly thrown, they're just set as scope variables.

Some people argue for specific exception types. But in my experience, most calling code trys to discern 1 thing. Is it a problem I can recover from or not? To try and clarify a little:

• The caller can't recover from a file not found error. You could suggest that the caller may be able to create the file, but that's probably giving the caller too much responsibility. Essentially another code path should be started that may eventually culminate in calling the function again. But the original path is essentially dead in terms of exception handling.

• A caller can recover from a Timeout exception in a network call. The method is idempotent in most cases, so it can just call again (and hope it was just a hiccup). Or it can pass a higher timeout. I think these are reasonable actions that are still within the caller's responsibility. If these don't work, it's time to execute another code path or propogate the exception.

So in my line of thinking, checked exceptions force a caller to consider whether it can handle any problems up front. You're more likely to include exception handling code because it's part of fulling the method signature. Only we've seen in practice that this is not the case. In many cases, the try/catch structure encourages programmers to treat all exceptions as "unfixable". Basically instead of handling the exception, most try/catches do one of the following.

• Clean up before re-throwing
• Wrap the exception in your own to throw down the stack
• Ignore It

So if you buy all of this (and I'm not sure i do, this is just a line of thought) it looks like checked exceptions aren't that helpful. But having a mechanism for explicitly specifying the exceptions that are possible is very helpful.

So this is my list of must-haves before I'll consider using another browser setup on a regular basis.  I'm a professional web developer, and like many people reading this, I'm also an internet junkie.  So this isn't going to be the typical feature set.

High Performance and Responsiveness

Obviously this is the biggest issue and the real reason I'm considering the switch.  My typical browsing session involves 8 or more tabs open to the most resource intensive sites you can think of.  Web applications that are on the cutting edge of browser capability, vendor products that provide massive functionality behind the scenes, huge multimedia sites choc full of giant images, audio, video, flash and javascript.

And that's just my day job.

The fact is that for whatever reason, Firefox can't handle this level of activity anymore.  It slows to a crawl.  It eats my RAM like candy (and I have a lot of RAM).  And on the days when I'm being particularly patient, it just calls it a day and crashes.  Unacceptable.

Fortunately, Firefox has some real competition these days.  Internet Explorer 8 isn't completey terrible.  But I'm on a Mac, plus there's no way I would use it for web development.  I've been using Safari 4 for the last week or so and it's zippy pretty much all the time.  When I was a Windows guy, using Google Chrome was a joy.  If they ever release a decent version for OS X, it'll definitely be in heavy rotation.  Opera has always been one of the better performing contenders from what I hear.  Firefox is easily beat in this category.

Web Developer Tools

This is pretty high on my priority list since I can't do my job without decent development tools built into the browser.  Sure, I used to build websites before Firebug came along.  But I now recognize that era as The Dark Ages of web development.  I'm as eager to go back there as I am to see what the Black Plague was like.  Fortunately, the other browsers have developed some nice tools as alternatives here.  Safari and Chrome offer a console that allows you to inspect the DOM, see some applied css rules and debug javascript.  The Chrome console is missing some key things though.  My guess is it comes pretty much out of the box from Webkit.  The Safari version is much more full-featured.  But on closer inspection, they both have deficiencies that can't stand up to the combo of Firefox with Firebug and Web Developer Toolbar.

• Edit in place: With Firebug I can inspect html and edit in place.  I can see tweak things in real time instead of the usual edit-save-reload cycle.  This goes for css too, which is really helpful.
• Full CSS view: Selecting a DOM element in Firebug shows the full cascade of css rules that apply to a given element rather than the truncated view in the Webkit console.  It excludes inherited styles (e.g. default from the body element)
• Network Profiling: The Net view in Firebug is great for getting a real sense for how your page loads and what the pain points are.  The Webkit console has a page load view, but it seems buggy and wrong a lot of times (reporting 0 byte files and 0 load times).
• View All Javascript/CSS: Not sure how many others use this feature.  But the Web Dev Toolbar has an option that will give you a page with all of the javascript or css for a page all stitched together.  This is awesome for searching for that one pesky line that's giving you trouble.  Especially if some of the code is loaded from external sources and you're not very familiar with it.  (To be fair, this can be replicated with a few bookmarklets though.)

Add YSlow and other Firebug extensions this list and that's a lot to give up.

Major Extensibility

This section pretty much covers the rest of my gripes with other browsers.  The greatest feature that Firefox brings to the table is that it is infinitely customizable.  All of the features of Firefox that make it so indispensible were developed by third party developers.  Over the last several years I've amassed a prodigious collection of add-ons that turn my firefox into exactly what I want it to be.  My first couple of days trying to use Safari or Chrome, I could barely get anything done.  I was missing the familiar environment that was tailored to my workflow. Here are my favorites features and add-ons:

Web Development

• Firebug and extensions plus Web Developer mentioned above.
• It's All Text.  Let me use emacs wherever possible.
• Tamper Data.  Cause sometimes HTTP can be a PITA.
• Not to mention MeasureIt, Colorzilla, Pixel Perfect,...

I don't use all of these all the time.  But when I need them, they make my life much easier.  And when I don't have them, it makes me contemplate finding a new profession.  I've been searching for replacements on the Mac and what I've found is that most of the good ones cost money.  Yes, I've paid for a few I thought were good.  But none of them are integrated into the browser very well.

Productivity

• Bookmark keywords:   This is actually built into Firefox and it may seem like a small thing. But Firefox lets you give any bookmark a keyword, which is more like an alias from the unix world.  When you type the keyword into the address bar it replaces it with that bookmark.  So for instance, to visit facebook I just type "fb".  No clicking, no googling, I'm immediately there.  And I never have to remember anything.  "What's that long stupid url for our dev wiki?" Type "devwiki".  Easy enough.
• OpenBook and XMarks.  Combined with the above, I'm much better at managing links and navigating to my most frequent sites.
• Tab Mix Plus.  Firefox has pretty decent defaults for getting navigating around and managing tabs.  But after I got used to my TMP settings, it felt like things were broken whenever I didn't have them.  Middle click on a tab to close it.  Double click on a tab to duplicate it (including the history.) Middle click on the tabbar to re-open the last closed tab.  If you aren't doing this, you are missing out.  Firefox saves your closed tab history by default, but this makes it much more accessible.
• Better Gmail.  Makes GMail... better.  CustomizeGoogle.  Makes the rest of the google products better.
• QuickRestart.  This is handy when you need to restart Firefox.  It used to be needed when you installed new add-ons.  But they have long since added a convenience button to do that.  Now it's useful when your Firefox has consumed all of your memory like some kind of black hole, and it needs to be restarted so you can keep working.  The reason this is notable is because QuickRestart gives you a button that can be added to your toolbar.  Just right-click and select Customize and you get a whole list of things that can be pulled onto the toolbar. Many other add-ons do this too, giving you very convenient access to their functionality.  This is a clutch feature in my opinion.

Web Surfing and Social Media

• Shareaholic.  A couple of clicks to share anything I want instantly on Reddit, Digg, Facebook, Twitter, Gmail and 50 other sites I've never heard of.  This is essential for minimizing my goofing off time.
• Search Cloudlet.  Adds tag clouds of relevant keywords to Google searches and Twitter.  I thought this was just a novelty at first, but it actually prompts you to add words to your searches that you may not have thought of. It can help refine your thoughts about what you're looking for.
• Xoopit for GMail.  This add-on crawls your emails and pulls out all of the media, making it organized and searchable.  You can see all the pictures or videos people have sent you in the last week, month or year.  Maybe not very useful in general.  But it is very cool to look over the entire history of the random stuff people wanted me to see over the years. That's how I found this nugget of joy.

Everything Else

Greasemonkey.  This is probably the clincher.  Userscripts.org has tons of scripts contributed by people who made the web work they wanted.  I can't even use Facebook anymore without the Fixer.  Many of the best add-ons started as greasemonkey scripts.

The bottom line is that in my version of Firefox, I can have things my way.  I've been trying to get other browsers to behave for a while now, and it's not working out very well.  So I guess it's back to slow performance, frequent crashes and even more frequent restarts.  I'm pretty confident that Mozilla is working on fixing these issues.  But they had better step things up.  The latest build of Chromium for Mac looks better every day.

There are several usable implementations of the early ServerJS standard available right now.  So I sat down this weekend to see if I could integrate one of them into Axiom Stack (the open source server-side javascript framework that powers this site.)  I chose Narwhal simply because the primary maintainer, Tom Robinson, is focusing on support for the Rhino JavaScript Engine.  Getting things up and running ended up being pretty straight forward, so I figured I'd outline things here.

On the surface Narwhal, and any other ServerJS compatible implementation, is just a library of javascript files that provide the standard APIs.  The underlying implementation relies on java packages though, which is why the Rhino engine is key.  Narwhal includes Rhino as a dependency and it also includes scripts for bootstraping the javascript environment in a JVM and loading the necessary js files.

That's all great for getting started with Narwhal, but Axiom Stack already provides the Rhino environment, and in fact it already provides a mechanism for loading js code into your application.  So my task was to find the merge point between Axiom modules and Narwhal packages.

Axiom Stack modules are pretty simple. Include your code in the modules folder under the Axiom install dir.  You need to follow a certain package structure that Axiom recognizes.  Then add the module name, which is just the name of the module folder, into your app.properties file.   It should look something like this:

AXIOM_R00T/
  modules/
     narwhal/
        Global/
           packages.js
            ...
            ...

And in your app.properties:

modules = narwhal

Now to figure out which Narwhal files to load.  Download the narwhal source from github.  Narwhal actually includes support for several javascript platforms including Rhino, Spidermonkey and v8.  Since I'm interested in the Rhino version, I'm checking things out in NARWHAL_ROOT/platforms/rhino/.  The lib/ folder has all kinds of good stuff, so I tried copying these files into my narwhal module Global/ folder.   That didn't work.  I got all kinds of awesome error messages about missing functions or variables.  So I read up a little and finally came across this helpful thread.

I think that for Jaxer and ASP, you can bypass bin/narwhal (which just finds itself and calls platforms/*/bin/narwhal-*), and you can bypass platforms/*/bin/narwhal-* (which just finds the engine and executes platforms/*/bootstrap.js) and go straight to platforms/*/bootstrap.js.

So it looks like we need to bootstrap the narwhal environment first.   But after that, the bootstrap file knows where everything else is.  So after some more futzing around and breaking things, I did what any self-respecting integration artist would do: I cheated.

All I needed was for Axiom Stack to load and execute that bootstrap file.  Axiom Stack loads whatever is in the modules/narwhal/Global/ folder.  So here's my setup:

AXIOM_ROOT/
   modules/
      narwhal/
         Global/
            bootstrap.js -> NARWHAL_ROOT/platforms/rhino/bootstrap.js

Yes, I simply symlinked the bootstrap file into the Axiom Stack file tree.  Almost there, but there's one more step.  The Narhwal loader looks for the "NARWHAL_HOME" environment variable to know where the install is.   So set this in your environment and restart Axiom Stack and you should be rocking and rolling.

Yeah, I know this is not ideal, and certainly wouldn't be acceptable for a production setup.  But hey, we're talking baby steps here.   This is pretty good for a couple of hours on a Saturday.  I've already got ideas on how make the integration a little more stable.  Hopefully in the future, Axiom Stack will be fully ServerJS compliant from the start.  Until then, check out Narwhal and make sure to give feedback to the group.

<!-- This is a comment. -->
<!--
        They can also span
        multiple lines.
-->

Pretty straight forward. And you would think it's easy to identify when rendering. Once you see the "<!--" then ignore everything until you see "-->".  Except Firefox doesn't do that exactly.  It turns out if you have 2 dashes or hyphens contained in the comment, Firefox will prematurely end the comment.  And probably break your page.  Example:

<!-- This is a fine looking comment--Until you get here. Now you're screwed! -->

The above comment Will break in all versions of Firefox up to the current stable version of 3.5.  Take a look (You are using Firefox right?)  This doesn't happen in any other modern browser including Internet Explorer.  But okay, so there's a rendering bug in Firefox.  It happens right?  No big deal.  I'll just fulfill my responsibility and go on over to the bug list and make sure it's there.  Sure enough, I found the bug, and that's when things got interesting.

Apparently people have been arguing about this bug for 6 years!  And it still isn't fixed!  Because, like all good stories about programming minutia, some really smart guys don't agree that it's a bug.  HTML is a tag-based language originally based on SGML, and apparently the spec for HTML relies on SGML to specify how comments should be handled.  Here's the choice excerpt from the spec.

White space is not permitted between the markup declaration open delimiter("<!") and the comment open delimiter ("--"), but is permitted between the comment close delimiter ("--") and the markup declaration close delimiter (">"). A common error is to include a string of hyphens ("---") within a comment. Authors should avoid putting two or more adjacent hyphens inside comments.

You see the issue here is that the end delimiter of a comment in SGML isn't "-->", it's just "--". After the double hyphen your text starts to mean something again. And you can include as much text as you want after that. But according to HTML you're still inside a tag, because it hasn't seen a closing ">" yet. Hence the weirdness. In fact it's even more complicated than that. Check out this more in-depth breakdown. Which explains why one set of double hyphens breaks comments while a second set will fix them. <!-- So something -- like this -- would work just fine. -->. Remember, if you're going to include double hyphens inside your HTML comments, make sure they come in multiples of 2.

Oh... well... fine then.  That's kind of stupid, but okay.  Bug closed as invalid.  And it was.  Until someone else realized it was stupid.  In fact, several people did.  Which is why it was successfully removed as a requirement for passing the Acid 2 compliance test.  And finally it was fixed where it should've originally been fixed, in the spec.  HTML5 addresses this issue.   Hooray!   Now the official end delimiter for comments is "-->".   Except you're still not supposed to use double hyphens... whatever.

So now the smart guys at Mozilla are listening to reason and plan to fix the bug in the next version of FF.  But only after the HTML spec supports it.  That's the most interesting thing to come out of all of this in my opinion.  It raises a few questions.  Is it good to hang on doggedly to a spec written years ago, when clearly it does more harm than good in modern practice?  And more importantly, when is it time to stop being pedantic and fix the damn bug already?  Apparently you can give it at least 6 years.

Update: Apparently the HTML Tidy validator plugin will warn you of this. Don't know how long this has been around. But it's handy at least.

While I do really like the ExtJS APIs the generated markup makes me cry. A button should not be made of multiple 's. #fail

I had this same gripe a while back when I was hacking facebook with greasemonkey.  I felt like facebook was flouting everything we've learned about web standards and structured content.  Everything is a <div> wrapped in multiple other <div>'s.  In fact, most of the content is generated with Javascript.  With their last major redesign, Facebook eliminated many of the explicit page reloads.  Now they literally pull in the entire page with ajax and regenerate the markup.  And a couple of weeks after I finished my greasemonkey script, they changed the interface again and broke it!

But then I started really considering what apps like Facebook are trying to accomplish.  They're task-oriented, not content oriented.  Most of Facebook requires a user to be authenticated.  fb is more concerned about people coming to the site, not robots.  And even considering that, the public pages still manage to rank pretty high in Google.  Search for marco rogers and you'll get my profile link as the first result.  Even though the page is pretty much entirely generated with javascript. Today's web apps put the application first and the web second. Many of them are basically meant to be portable desktop apps. When was the last time you cared how the visual elements in MS Outlook were put together?

Unless I miss my guess, the markup spit out by fb is probably tied pretty closely with some proprietary content framework they're using to generate the pages.  And generating semantic markup with javascript is no mean feat.  If you can get away with every element being a <div> or <span>, you're almost certainly doing yourself a favor.

That's how I read the promise of Ext JS.

Ext JS is a cross-browser JavaScript library for building rich internet applications.

Ext JS is offering to do you that favor. You can build those complex applications with an interface that will be consistent in functionality as well as look and feel. As long as you're not worried about search findability. And if you're building a web application, you should really ask yourself that question sooner rather than later.