The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Javascript-heavy interfaces - why now?

After GMail, Amazon's A9 is the second Javascript-heavy web application rivaling desktop counterparts with richness of interface and responsiveness. (Well, GMail is faster, but probably Google have thrown more servers at it.)

Come to think of it, I've seen this earlier, in the Blogger authoring interface.

Why didn't this happen sooner? My IE About box says copyright 2001, so this same thing was possible three years ago? Did nobody try it? Was it too slow, in terms of CPU, or in terms of net speed?

I think a lot of web applications can benefit greatly from "gmailification" - removal of all excessive images, hiding a lot of features behind dynamic links to minimize roundtrips to the server, mass use of collapse/expand of parts of the interface. Forum software - the typical freeware PHP stuff like phpBB - are the worst offenders - they are slow, they produce huge HTMLs, with very little functionality per screen estate.

Bug trackers can probably also benefit. Any type of web application which presents complex, mostly textual information on the screen, and provides many ways to manipulate it, can benefit.

People have already reverse-engineered GMail to the point of writing client-side APIs to manipulate (some would say abuse) the message store. So there is no "secret Javascript juice" - so where are the open-source reimplementations, and the infusion of these ideas into high-profile open-source web applications?
Ivan-Assen Ivanov Send private email
Monday, September 20, 2004
I think it's mostly a matter of not believing it was possible. I built a little javascript-based app that allowed the user to drag stuff around the screen and resize objects using the mouse. ( All sizes and positions were posted back to the server with PHP, but the real work was all javascript. Anytime I tried to explain to other programmers what I was up to, I was always told either "Not possible", or "Too slow", when in fact it was possible, was more than fast enough, and was actually far easier to do than the equivalent VB program.

Now, Google et al are demonstrating what can be done, so everybody will be jumping on the bandwagon.
Ron Porter Send private email
Monday, September 20, 2004
I think only recently (last couple of years) was there a decent core support of W3C DOM and XmlHttpRequest from all the common browsers.
Matthew Lock Send private email
Monday, September 20, 2004
I suspect that this kind of development is only cost-effective for a very limited group of companies - those with more money that average to throw at the task.  Why, because I suspect that for the "rest of us", this is not a cost-effective way to develop an app.

See this link, and the paragraph about ducks...
John Rusk Send private email
Tuesday, September 21, 2004
I built an IE-only pseudo-MDI/rich client app in 2001 that made extremely heavy use of DHTML for browser-based windowing and dynamic postback (using the XHTML control, to achieve what Microsoft's older Remote Scripting applet used to be used for).  It wasn't slow, but there were some memory leak (or perhaps, lack of GC) problems due to IFrames and we'd often see the IE process take up over 200mb of memory and/or take several minutes to shut down when the user exited.  The app dealt with very large sets of data in the browser, so lack of memory cleanup was obviously an issue. 

Anyway, regardless of these problems it was a pretty cool app if I do say so myself :)
Tuesday, September 21, 2004
Probably because the installed base of Mozilla/Firefox/IE5.5+ browsers is pretty large now, whereas you'd have to work around older IE or Netscape bugs 3 years ago.
Flamebait Sr.
Tuesday, September 21, 2004
For a long time we kept hearing from our customers that they wanted support for older browsers. Our application was often used by the general public and they were afraid that a significant portion of their customer base may be using older browsers. I'm not sure how accurate their position was but it was what they wanted and they wrote the checks. With the newer generation of browsers starting to see some market penetration I'm sure that this will be much less of an issue. I will say that it still takes a lot of effort to make a rich-client interface in a browser. The tools don't really exist yet to make this stuff easy.
craig Send private email
Wednesday, September 22, 2004
Because it's a mature, supported, needed, understood, technology.
Wednesday, September 22, 2004
mature? supported? understood?

You've got to be kidding. I mean - I consider myself a dhtml guy - and I won't even go so far as to claim either of those three.
Aaron Send private email
Sunday, September 26, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz