Month: August 2007

It’s a Friday surprise! After reading this post by Dare Obasanjo,
I dutifully followed the links in the article. Upon stumbling on his Live Spaces friends page, I instinctively hit Ctrl+U to peek at the source code. Ow! Ow! My eyes! My tired bespectacled eyes!

Dear readers (yes, all 2 of you — Privet, Mom!), let’s all hold hands and stand in a circle. Let’s promise ourselves to never look at that pitiful, congealed elephant-man, malignant-growth of a code ever again. It’s just better that way. And you, Spaces developers… Well, shame on you. You should know better than dumping this crap on the Web. No wonder poor Dare can’t get screen-scraping out of his mind: he probably hasn’t even seen good semantic markup, much less realized its benefits. Have you?

Oh, and Dare, bad call on the friends.get example. You should probably use fql.query to get something more useful than a list of friend UIDs for any sort of social network portability. But I’ll leave you alone with your point of view on what can and cannot be an API.

I am trying something new here. Instead of blabbering and shaking wrinkled fists like a cranky old man, I’ll turn my lemon into something with a bit more kinetic oomph. Like a two-by-four. Kidding! Kidding…

If you’re like me, you’re fascinated with Web frameworks. You’ve dabbled in all of them, finding likes and quirks, but ultimately walking away wanting more. If you’re like me, you’ve kept a mental wishlist of what tomorrow’s Web framework should be like. Here’s mine, in no particular order:

• Framework for Tomorrow’s Web (FTW for short) Speaks Web natively. No extra work is needed by a developer to take advantage of the full HTTP spec potential. GETs are idempotent. POSTs are free of abuse. Etags are meaningful. Did I mention they just work?
• FTW is intentionally and unapologetically stateless. On the other end of a request, there is a representation of a resource whose change is strictly a function of time. Personalization and other shnazzy Web 2.Poo junk are accomplished by client-side composition.
• FTW is architected outside of a single server boundaries. Parallelism and massive scalability are part of the deal. Spreading your application across several nodes does not require redesign or even changing a line of code. Perhaps even, the framework does it automatically, expanding or contracting its physical machine span as a reaction to traffic.
• Just like we grew out mallocs and frees, with FTW, we no longer worry about caching. Caching is effective and completely behind the scenes. FTW developer does not know anything about dependencies, re-syncing, or sliding expiration scales. Caching just happens. No tinkering is necessary.
• FTW respects the markup. If asked to produce xHTML, it outputs minimalist semantic markup that is free of presentational dribble. It may actually prevent the developer from tossing crap onto the representation.
• In FTW, you develop using a a strongly, dynamically typed language. Ok, this one is not really a tomorrow’s feature by most accounts, but we .NET folks are still calling them futures.
• The framework consists of two integral parts: the server-side and the client-side. The client-side part is treated with the same respect as the server-side. They’re equals, except one manages content, and the other manages presentation. In this respect, FTW is not a hodge-podge of multiple technologies that spans several disparate projects.
• Layers of abstraction are drawn along, not across the separation of concern. In fact, FTW manages separation of concerns. It is developed to support best practices, unified into an intuitive, thorough methodology. You know, the one that doesn’t begin with ‘spose you want to build a Web form.
• Finally, the FTW‘s architects realize that Web is most naturally modeled as a graph. Instead of messing with tables and rows, the developer creates representations and establishes relationships between them, never departing from hypermedia to another the data abstraction. Dare I predict the end of reign for tabular data, my SQL homeboys? Meh. We’ll see.

I could probably list more items, but these seem to capture the spirit. Speaking of spirits, it’s Friday night. Enough writing. Thank you for reading. Y’all come back now, ya hear?

I must be a simple man, ‘cuz things like this in Javascript make me slap my sides, and go Hot damn!

		function Context(base) {
			if (base) {
				var c = function(base) {
					this.base = base;
				}
				c.prototype = base;
				return new c(base);
			}
			return new function() {
				// standard context functions
				this.get = function() {};
				// ...
			}
		}

		// then
		var a = Context();
		// do things with "a"
		var b = Context(a);
		// "b" inherits "a" as context:
		// * changes to "a" make it to "b"
		// * changes to "b" don't make it to "a"
		var c = Context(b);
		// you get the picture ...

I don’t know what’s more exciting here, the “no-much-to-it-ness” or the “bang-for-buck-ness”, but every time I get to work with Javascript, I am excited about the actual process of crafting code.

Let’s imagine there is a viable, publicly available ECMAScript4 (that’s Javascript 2.0, y’all) implementation that runs on the server (is there, by the way?), that can be used instead of Ruby, Python, PHP, C# etc. Wouldn’t it be great?

My first reaction is yes!. Actually more like you betcha, my goatee-chinned, mojito-drinking, flip-flop-wearing blog-buddy (that’s how I imagine you, anyway), as there would be one less language to learn for the developer.

But then, I am wondering if the developers would be more prone to get their wires crossed, switching from client to server context inside of the same language?

What do you think? Is less more in this particular case? Is having a separate language for the server side the right thing to do?

Send your answers with a self-addressed and stamped envelope. Or you can just use comments. Or your blog. Or Twitter. Or Facebook. Or Pownce. Whatever. Sheesh, this social networking thing is a full-time job.