It’s not a secret that Javascript is interpreted and not statically compiled. Personally I find this an advantage that is not used often enough. If you look around the Web you can find plenty of cases to prove this, but I’d like to add another example.

A few months ago I was developing a library which had a goal of providing an improved Javascript experience for standardized components without requiring any knowledge of the language to use. I also wanted to support different load scenarios so library could be smaller when needed.

Sadly I ran out of time before I ended my work to my satisfaction. Still, I’d like to discuss one approach that also demonstrates aspects that I’d like to see used more in the wild.

Let’s start with a demo. I created two almost identical pages. Can you spot the difference between first and second ?

First one simply toggles visibility of the text, while second one does the same with a bit more style. If you look at files, you’ll notice that the only difference is that first calls switch.js and second uses rswitch.js . Both files look the same because they are. In fact, it’s really just one file. Hard link to the rescue for us, Unixheads.

But first a small warning. This code is not production ready. I simplified it to keep example clear and concise. In that capacity I think it will do.

Javascript basically consists of two functions. A window.onload handler that’s triggered when page is loaded and an animation function attached to button. A window.onload handler is a one trick pony. Its main idea is to find Javascript file in DOM and based on the name with which it was loaded set up the execution environment. This is just a fancy name (to make me look smart) for setting a global variable that is private to this name space and possibly loading a few additional resources, like YUI animation support in our case. It is also the first case where not being static helps. We can decide at run time what’s necessary and load only what we need.

However, I find toggleVisible a tad bit more interesting and the reason is its if statement. What happens when we include switch.js in a page?

Well, variable rich remains set to false and YUI components don’t get loaded. This means YAHOO.util and its descendants aren’t defined. Yet as we’ve seen from first demo page script works just fine. Reason for this is that if statement in toggleVisible evaluates to false and those undefined statements never get reached. This wouldn’t work in a language like Java, which would notice a call to undefined methods at compile time and refuse to finish compile, but it works perfectly fine in Javascript.

Of course if rich was set true, then we load YUI files. It might happen with this code that we press button before they get loaded, which is one of the reasons why this isn’t a production quality code, but if we assume for a moment that they did, then those same lines in toggleVisible are perfectly fine and it works as hopefully seen on second page.

We therefore have a page where we control its behavior and size only by the way we call javascript file. There’s literally only one letter of difference. With dynamic loading of resources and cordoning potentially nonexistent methods we could fairly easily create a spectrum of possibilities where our users could choose their own compromise between functionality and its price in terms of page size and speed or better handle differences between mobile and desktop browsers.

I’ve returned from @media ajax a few days ago, a fantastic event I hope to be able to visit next year. This post is not about what happened there. There are better summaries published, easily accessible by search engine of your choice. Well, good ones anyhow. Besides, I have a cold so I’m even less coherent than usual, so those who’ll continue, beware.

I was however reminded again of a premise I’ve been thinking about every since Andy Clarke’s talk at @media 2006. Should websites look and behave the same way in all mainstream browsers or not?

I’ve been flipping my opinion on this through time, but it seems to me striving for same experience everywhere is not only tiresome, time consuming but also strategically counter-productive.

If a site works the same in all browsers, what incentives do browser laggards have to upgrade their browser?

Not many if any. I think same experience for everyone approach has other downsides as well. New features should be tested before they can be standardized and by tested I mean used. Otherwise we’re left to perpetually build to the lower common denominator. Just like we do now and it simply sucks.

There are arguments in favor of same experience everywhere. In my opinion most sensible one is that a significantly different experience between browsers can be confusing to users. I do, however, think this is not worth worrying about. In my experience, which is what I use when lacking better source of data, people in general don’t use multiple browsers. Those who do, will cope by either sticking to one browser per site or adjusting to differences. We’re not as dumb as we behave.

I used to despise “best seen on” or “optimized for” signs on websites and I still do when they mean they only work with a specified browser. I don’t think there’s anything wrong if website doesn’t shut out anyone, but it’s a bit nicer to some. In fact it’s what we already profess and do. We certainly don’t test all browsers that we used to even though there are still people using them. Not only don’t we test, we KNOW our sites don’t work the same in them. And if we already know and do this, why not also promote a better choice if we think there is one?

So what I’m trying to say without getting too deep into why is that I’ll try to build sites open to users of all browsers, but won’t be too timid to offer improved features when consistency is too difficult or impossible.

I’ve recently read couple of posts that left an impression on me. First one was Brad Neuberg’s about personal research agenda . I haven’t completed list of my problems yet, but I came far enough to know I’m not working on any of them.

The other one was about Blog 2.0 . I’m more interested in content manipulation than social interactions as Pownce and Marela are only two social networking applications I use. Still, ideas contained are intriguing and couple of days before Data Sharing Summit is the right time to shamelessly pimp my views.

Build a social application and you will likely, sooner or later, encounter a dilemma in what your members will be building. Are their creations mainly personal, an expression of their creativity, or are they more of a place where people meet and engage?

Most websites don’t fall squarely into one or the other. My blog feels personal not only because I picked the look and topics, but also because my voice is elevated above others. I doubt I would feel the same if comments could look like my posts. I like my place and freedom it offers me.

That’s why I don’t care all that much about most networks and degrees of their openness. Really open social network would be interwoven into the fabric of web. I already have my page, I don’t need yet another one. If buddy list is desired, I can use FOAF. Sharing of my stuff? Feeds. Same answer for getting other people’s stuff. Starting a new network would mean creating a widget or a few that can be easily integrated in our sites, maybe some sort of a pinging service if expediency is important and offering a space for personal page for those, who don’t have it yet.

It’s amazing how little would need to be changed to implement ideas in Blog 2.0. Basic technology is already here, it’s just not used widely enough yet. Sure there are a few issues that need to be thought through, mainly to do with handling privacy correctly, but they are neither big nor really technological. And price for all this?

Maybe a bit less expediency in content propagation and a bit more work for network operators, who might need to learn to live with the same limitations that search engine developers do already. And I’m not even sure that is really necessary.

Update: Thinking a bit more about this I would be happy enough if social network were just more inclusive. It’s fine that you can create an account and be busy on their platform, but it would be better if you could join and interact with a social network with your own node for as long as that met your needs.