4 posts tagged “javascript”

This post has been brewing for a while, but I've been prompted to actually write it by seeing John Gruber's offhand remark on his most recent linked list entry, about CSS gradients in WebKit:

Just me, or is WebKit racing way ahead of Gecko in terms of support for cool new stuff?

No, it's not just him. WebKit, and Opera's layout engine Presto, raced towards Acid3 compliance in March, with both effectively reaching a photo finish on the 26th. Meanwhile, Microsoft hasn't even shipped a non-beta Acid2 passing browser¹; no surprise there. But where's Gecko, the Mozilla layout engine, the one that powers Firefox?

Well, to be blunt, it doesn't look as if they care much. We have one developer saying that Acid3 is basically worthless, and another (more diplomatically) stating that it's a missed opportunity and an exercise in making browsers jump hoops, rather than improve "real" functionality. As others (almost certainly more qualified than I am) have noted, this sounds a lot like the noises from Microsoft around the time of Acid2's release.

The thing is, I'm not here to kick Gecko, but to understand its problems, if it has them. Does the team's response to Acid3 mean it does? Possibly not on its own, but coupled with events like the move of Epiphany to WebKit², and the aforementioned speed of development on WebKit (and to a lesser extent Opera's Presto³) I have to wonder. Why is development there so slow?

One stated reason is that the Mozilla Foundation is on a rush to release Firefox 3, and it's certainly true that it is coming up for release. On the other hand, Apple certainly seem to be able to keep the open-source WebKit tree distinct from the version used in releases - Safari 3.1 shipped with an Acid3 score of 75 when nightlies were scoring 90-odd - so I should hope that's not the real reason. Maybe they're pulling people off the layout engine to work on the browser? That's not as stupid as it sounds for most apps, given the way the Firefox UI is set out using XUL, a markup language. Even so, it feels like a bad use of engineering. Maybe Gecko's reached that point where extending it's no fun. The language the team themselves uses, with talk of Gecko 2, makes me wonder if that's true.

I don't have answers, anyway, but I'd love to hear from people who do why Gecko is giving the appearance of stagnation, while WebKit seems full of life.

¹ Bafflingly, it seems that Microsoft develops not one, but four layout engines: Trident, for IE/Win, Tasman, originally for IE/Mac and now part of Office:Mac, and two unnamed engines, one in Word and Outlook 2007, and another in Expression Web Designer.
² Admittedly that's got contributing factors beyond merely Gecko; it sounds like the wrapper they were using to embed it (GTKMozEmbed) had some seriously nasty issues of its own.
³ I mentioned to Tom Insam that I was surprised I'd never heard of the name of this engine, but he sagely noted that, as it's not open source or embeddable, there's no reason I would have.

or, why I won't be migrating to Google Mashup Editor

Last winter I wrote a small web application called groupr which let you look at photos from your Flickr groups in one place. I did that partly because I thought it would be useful (it is, a bit) but also because I wanted to play with the platform the company I'd once worked for had released. That platform was called Zimki, and it was, in hindsight, a pretty ambitious thing for a small company to attempt.

Zimki is a hosted server-side Javascript application framework, complete with a data storage model and a templating engine (actually two). It makes it easy to quickly knock up a small web application, or at least it does once you wrap your head around it and get hold of tools to save you using the (frankly awful) web pages provided for editing your app. It's the closest I've seen to what Marc Andreessen has called level 3 platforms:

A Level 3 platform's apps run inside the platform itself -- the platform provides the "runtime environment" within which the app's code runs.

Indeed, this is exactly how Zimki works. Unfortunately, it's also closing by Christmas.

There's a big company out there who also have something that looks a bit like a level 3 platform. Google Mashup Editor also lets you run code in a hosted environment, build multi-page sites, and read and store data from the web. Unfortunately, there's no way I can port groupr to it.

Firstly, there's a very limited set of server-side computations allowed. If there's not a module or control for something, you can't do it. This is the first thing I ran across. groupr has a local config file with my Flickr API key and secret, and it uses MD5 to calculate the required parameter for the authentication step. It turns out that's impossible with GME.

Secondly, there seems to be no way to pass data in to the application other than by user interaction or feeds. Notably, you can't inspect HTTP query strings, the mainstay of web programming since 1994. Since Flickr's frob is returned in an HTTP parameter, this means it's impossible to ever use GME for a Flickr application that requires authentication. Well, actually, you could do everything on the client side, but then why use a hosted environment at all? I doubt I'd get enough use out of its templating language to justify the effort.

As with my complaints about Skitch, this is almost certainly a case of me wanting a product to be what it's not, but I can't help feeling that if Google aren't prepared to build a real Level 3 platform, nobody is. In the meantime, I suppose revert to writing my own apps with web frameworks that use SQL and which need work to scale, just like everyone else does.

There have been a couple of posts since Apple's press event on Tuesday, which saw the launch of the new .Mac Galleries - an online, read-only version of iPhoto, kind of - that state that "Apple doesn't get the web". Jeremy Keith says

in the fast-moving, messy world of online services I don’t think the genius-led design of Apple can compete with the truckloads of nimble young upstarts making snazzily addictive products on the Web

and Chris Heathcote writes

Whenever Apple strays towards software and the web recently, there’s a lot of flashy interfaces, and little substance.

I think there's a slight qualification to be made here. I think Apple are great at web publishing. Their site is one of the best product sites I've seen (despite the fact I dislike the new bigger-than-800-pixel width). I've been going on about the elegance of URLs - it's possible to guess that there's something at apple.com/keyboard, for example - since 2001 or something, and even when they drop in AJAX their pages still have usable permanent links.

When designing for consumers, Apple takes the same approach. They produce tools for publishing, using a one-to-many, one-direction mode of thinking. As James Duncan Davidson notes as he writes about the .Mac galleries, "It’s not Flickr, and comparing it to Flickr is probably pointless." Well, no. Flickr is the archetypal Web 2.0 application, being almost as much about community as about photographs themselves. The .Mac gallery, on the other hand, is all about putting your work online. There's no comments, no notes, no tags, but the people who it's aimed at don't want that. They're about publishing, not interaction, and while they pages are undoubtedly heavy, and probably scale badly, they're also slick enough that a lot of people will like them.

Similarly, iWeb-generated blogs have no comments, but well-designed templates (from which it's hard to stray.)* Again, it's designed for publishing. The problem for Apple is that it's not 1999 any more. People expect more from their sites now, and thankfully more and more of the sites I use are applications, not brochureware. So perhaps the statement needs to be refined, because despite the JavaScript libraries and slick visuals, Apple doesn't get Web 2.0.

* One point where iWeb fails is that it doesn't preserve Apple's nice URLs; the ones it generates are distinctly ugly. At least, they were in the first version.

One of the nice things about working on groupr in the first few weeks was getting involved in the object model and the underlying code, but there were a couple of hooks I left deliberately so that I could add some whizzy client-side effects later. One was the fact that the call to get the photos in a group pool had a couple of optional parameters; the number of images to fetch and the page number.

With the latest revision of groupr, which is now live, that's actually been made accessible to users. If there's more than nine images per group, you'll be able to page back and forwards through them. If you're not a member of many groups this probably makes the app vaguely interesting to you. If not, maybe you'll like the fade effect, for which I have to thank Gareth, for suggesting it, and jQuery, for making it easy.

Annoyingly, though, I've just realised that I can't use Flickr's group IDs as CSS IDs. @ is not a permitted character. (This is probably because it's used in the selector syntax; something I should have realised when jQuery was failing to select items based on ID. I ended up using an XPath selector instead, but that's not really such a useful discovery now.) Oh well, nothing like a big HTML refactor to get stuck into, is there?