Unfortunately, I don’t give TodaysMeet the attention it, and more importantly its users, deserve. This is because TodaysMeet has two fatal flaws that, if they haven’t crippled it yet, will someday.

• The UI is based on proof-of-concept JavaScript.
• The back-end is based on my own framework.

What follows is the sad history of TodaysMeet development.

Origin Story

TodaysMeet came out of a conversation between my father and I, but it’s origins are slightly older. In some downtime in late 2007 I was trying to familiarize myself with various JavaScript frameworks by writing a UI for the same back-end in each of them. It was a pretty basic Ajax comment system. I believe it polled the server every minute. If I remember correctly, I got busy and abandoned it after creating Prototype and jQuery versions.

Around the same time I was enamored of Rails, and trying to round out Maveric into a decent Rails-inspired PHP framework.

So when my father said he wanted something like Twitter for a single classroom, that he could project on a wall, and wouldn’t require signing up, I put these things together in my head. TodaysMeet is basically the proof-of-concept Prototype JS running on top of an old version of Maveric.

The Situation Now

Every developer should write a framework, I think it’s a fantastic learning experience. But they should never build a production website out of it.

Even though Maveric got a little better after I created TodaysMeet, it’s still based on an untested, unsupported framework with no support for basic things like storage back-ends or caching.

The UI is still based on Prototype, which I haven’t used in years, and the fundamental client-server interactions are still that original “learning the library” code.

Essentially, TodaysMeet is a prototype masquerading as a production-ready product.

The result is that working on it is slow, difficult, and frankly unpleasant. Adding features—like the long-promised password protected rooms—is painful and, with no test suite, dangerous. The one real feature I added, Twitter integration, barely works when it works at all.

But users don’t care about any of that. They see that it works, mostly. They might see that it doesn’t get much attention and the UI feels three years old (because it is, of course).

Where Do We Go From Here?

TodaysMeet could be awesome, but it needs to go all the way down to the basic stack and get rebuilt. TodaysMeet is an absolutely perfect candidate for all sorts of new, exciting tools and techniques. To use any of them means starting over.

This is the first of a two-part post. In the next part, I’m going to outline the architecture I want, instead of the architecture I have.

Hopefully, some social aspect of talking about this will lead to me actually doing something about it.

Last time, I introduced the technique of creating and immediately executing a function, using parentheses. I talked a little about returning a function and storing it in a variable.

There are a lot of things you can do with this trick, like create interesting bookmarklets. But let’s see how you can use it to protect information on the class level.

Here we’ll take advantage of JavaScript’s scope behavior. Remember that a function uses the variables where it is defined, not executed. Perhaps a better example…

We can see that the inner function (which is returned from the outer function and set to myFunc) uses the value of message from the block where it was defined, not executed.

Now you should be able to see where this is going. Let’s look at a more complex example, extended from the first part:

What’s the advantage here? The variable partNumRegex is not copied by the new operator. In a small example like this, there is not much benefit, but if you had hundreds of Product objects, you could save a significant amount of memory.

There are a few major drawbacks: a public static (class) method cannot access a private static method or variable. For example:

The class method validPartNum has no access to the private class variable partNumRegex, and so will throw an error at (1). Adding an accessor must be done on the instance, not the class, like so:

But then you cannot access the private variable without first creating an instance of the class, and the accessor function is copied with the new operator. New methods added to the Product.prototype object are likewise unable to access the private static variables. This is a limitation of JavaScript.

Even with these limitations, the ability to hide implementation behind an agreed-upon interface is powerful. (JavaScript doesn’t actually have interfaces, but you can just write it down.) Behind the scenes, you could load new data via Ajax, without ever exposing your Ajax method to that new guy down the hall who likes to misuse everything he can:

That’s it for now. I owe most of these three articles to the book Pro JavaScript Design Patterns, by Ross Harmes and Dustin Diaz. Those two are geniuses, and anyone who wants to be a better JavaScript programmer would do well to pick up their book.

Next up, I’ll argue why the <dl> tag is a good way to display forms semantically.

The complexity jumps significantly, though. So I’m dividing this half into two parts.

To get started, we need to forget about all this Object-Oriented Programming for a minute and look at some of the neat tricks you can do with functions in JavaScript.

Update: Part 2 is now available.

First, let’s take a look at a few ways to define a function in JavaScript:

The first example, oneFunction should be familiar to programmers from most languages. The second one is completely equivalent, but works slightly differently. In this case, the right-hand side, a function, is being assigned to the left-hand side, the var anotherFunction.

Remember that in JavaScript, functions are first-class objects, just like everything else, so can be declared with the var keyword. They can also be passed to other functions as arguments, or returned from functions.

Now let’s take a brief look at parentheses. What do parentheses really do? Essentially, they evaluate and return whatever expression is inside them. For example:

So parentheses are slightly more powerful than the simple grouping operation we associate with them. Sometimes we see examples like this, which may be more illustrative:

So what happens if we combine parentheses’ ability to evaluate and return code with our ability to define functions as an expression?

Of course, this is just the same as anotherFunction above, but you can see that the right-hand side “returns” a function. Let’s do something a little different now:

What’s going on here? The first set of parentheses [(function ... )] evaluate and return the code inside, creating a function. The last set [("World")] are then calling the function created by the first set. Immediately.

This is a powerful technique, but has certain limits. The interior function is executed immediately on creation, which means the DOM will probably not be loaded yet. Once the function is executed, it is lost. Trying to save it in the left-hand side of an equation will only save the return value of the function, not the function itself. For example:

But, remember what I said about functions as first-class objects? It means we can use one function as a return value from another function:

The outer function (1) is executed immediately (3), and the var bFunc stores its return value, which is the inner function (2). So now, bFunc is a function, and calling bFunc() will alert “Hello, World!”.

We’ll stop for now. If this technique is new to you, play with it for a while. If not, just hang tight and I’ll get to Part 2 soon enough.

One of my (few) gripes with Firefox is that bookmarks on the toolbar have no “open in blank tab” option. They have an “open in sidebar” option, but those uses are rare and esoteric at best. Personally, I never use the sidebar.

“Open in blank tab” should basically do this: if there is a blank tab, use it; if not, create a new tab. Frankly, it could just open in a new tab regardless, but it seems like such an easy thing to add.

But? It can’t be done directly in Firefox. Hence, I present this small script:

That’s it. Try dragging this link to GMail to your bookmark toolbar. Then click the link on your toolbar. Now, open a new tab, and click the link again.

This isn’t exactly what I asked for. It has no way of knowing if any blank tab exists, only if the current tab is blank. And, of course, it lacks the nice favicon support.

But it does the job. If you change the variable u to something other than ‘http://mail.google.com/mail’, you can make the link open any other page.

I love anonymous functions.

Update: If you want a bookmark for something besides GMail, you can create your own. Or you can drag this link to your toolbar, to make new ones whenever you want: Open in Blank Tab.

Update 2: Oops, fixed the “create your own” link. Tested it, then accidentally pasted in the results, instead of the actual script.

I have a love-hate relationship with JavaScript. I think anyone who works with it does. Sometimes it just doesn’t do what you expect, and it’s certainly different.

One trick, especially for people from real Object-Oriented languages like Java, Ruby, or let’s even say PHP 5, is the lack of access control. When everything is an object, the inability to hide certain values can become a problem.

Say, for example, you create an object that represents a product you sell, and you want to use one of your part numbers to identify the object. Let’s say the format for your part number is 1234-56. You might do something like…

You’re expecting the rest of your team to be respectful and use the Product.setPartNum() method, which should stop them from using an illegally formatted part number. (partNumRegex is left as an exercise to the reader.)

But what’s stopping them from doing this?

Now when they call your Ajax-driven getProductData() method, they’ll get an error. Had they used the setPartNum() method, they would’ve seen the error much earlier.

One trick to JavaScript is that variables are lexically scoped. Basically, functions use the value of a variable where they are defined, not where they’re executed, for example (or just read a better article):

So how does this help? Well, you can effectively hide values in a deeper scope. Instead of using the this keyword, just define new variables within your function:

This same thing can apply to private methods. Don’t want the new guy calling superSecretInternalMethod()? One common practice is to start private methods with an underscore, but a better way is to actually hide the method:

We can even go a step farther and define private class methods and variables, but this post is already long enough, and it’s rare I have material for two in a row, so I’ll save that for next time.

If you haven’t read it, go get Pro JavaScript Design Patterns. You won’t regret it.

Chrome certainly looks like a modern browser, with tabs along the top and an address bar and a “Most visited” home screen, it will seem familiar to anyone who’s moved past Internet Explorer 6.

And yet, my Twittersphere has been full of comments like “Nice, but not nice enough to make me drop Firefox/Safari.”

While there are some visual improvements, such as an extremely small “chrome” (the parts of the browser around the page area) footprint, the big changes are “under the hood.” Chrome is built for tabs—each tab is an isolated process; no one tab can take down the whole browser—and is built for JavaScript-heavy “web 2.0″ apps—Chrome’s new V8 JavaScript engine executes a full order of magnitude faster than the current browsers, in my experience.

And all of those “under the hood” changes are open source.

Chrome is not a browser.

Chrome is Google’s way of making a point: modern web browsers have not kept up with the web itself.

More and more, the web is becoming an interactive application, and most browsers are not built for it. They display pages, and running applications is an afterthought. While we’ve seen huge improvements in JavaScript execution in the past few years, speed is still a limitation for developers. Applications are also much more likely to crash than static pages (go ahead, just try to crash a browser with just malformed HTML) and isolating tabs will give necessary boosts to speed, stability, and security.

Kris Abel of CTV.ca said it best: “Google’s entire business takes place throughout the internet itself and so they see their interests served regardless of which company takes web browsing to the next level, in fact they see their interests served if all companies do exactly that.”

I’m not switching to Chrome. I doubt very many people will find it useful as a primary browser. I don’t expect many user-interface improvements, like Firefox’s vast add-on library or the accessibility features of Firefox 3, Opera or IE8.

I do expect any future version to have more “under the hood” improvements, and I hope that the makers of Firefox, Opera, Internet Explorer, and any new browsers that spring from this, will re-evaluate their own products and move in this direction.

Because when the browsers get better, the web gets better.