Thursday, March 17th, 2005

GMail / Google Maps is hard?

Category: Ajax

>

“It is really, really, really hard to build something like Gmail and Google Maps,” said David Mendels, general manager of platform products for Macromedia. “Google hired rocket scientists–they hired Adam Bosworth, who invented DHTML when he was at Microsoft. Most companies can’t go and repeat what Google has done.”

Google has hired great people. However, I could be wrong, but I don’t think that Adam Bosworth was hacking away at the Google Maps JavaScript. Maybe Josh Block was testing in the different browsers?

I don’t think so :)

Ajax isn’t trivial, but it isn’t rocket science. And, it is only going to get a lot easier. As we look around and see the interesting work that is being done, we are more and more impressed.

Again: We are not trying to say that there isn’t a valid place for Flash, Lazlo, etc.

Related Content:

Posted by Dion Almaer at 12:45 pm
13 Comments

++++-
4.4 rating from 5 votes

13 Comments »

Comments feed

gmail and google maps *are* hard. sure you could hack something together that could support a few concurrent users, but try to do it so it scales and there are no bugs across a ton of platforms and when there are bugs you can maintain the code without a ton of effort.

Comment by Ron — March 17, 2005

Implementing rich Javascript UIs is a lot harder than rich Java UIs. The browser incompatibilities are a huge pain and the tools suck comparatively. I would only use Ajax for a public web site where it was absolutely crucial that I reach the largest audience possible.

Also, I seem to remember Netscape 4 with DHTML coming out long before IE 4.

Comment by Bob Lee — March 17, 2005

Writing an Ajax application seems easier than solving the problem of deploying the JRE to a bunch of different client platforms and working out the various versioning issues, etc.

The browser incompatibilities will be factored out into library-level abstractions; I don’t find that argument particularly compelling.

Comment by Ben Galbraith — March 17, 2005

For anyone who thinks this stuff isn’t hard, please get back to me when you’ve optimized a JS app for widescale deployment, esp in a bandwidth-limited environment.

The Google guys do a great job at optimization, and they use many of the same techniques that some of use have been using for years now, but what most people who take a cursory look at JS/DHTML don’t get is that doing it RIGHT is really, really hard. It’s not about how much code there is or what it’s doing, it’s about how much code there _isn’t_, and what kinds of newbie mistakes they’re NOT making.

Hard to the extent that someone pays me to do it. I’ll believe that this stuff isn’t hard just as soon as I stop making a living at it.

Regards

Comment by Alex Russell — March 17, 2005

Are you disagreeing for the sake of disagreeing? I get paid a lot of money to do client-side Java, too. Come to think of it, a lot of software developers get paid to solve a lot of hard problems.

The allegation was that Ajax was *especially* hard. That doesn’t ring true to me. Swing, SWT, win32, etc. all have their share of hard problems. Creating rich GUIs on any platform is difficult. The pain points change, but I’m not aware of any platform where companies expect folks to build their software for free.

Comment by Ben Galbraith — March 17, 2005

No, I’m not trying to be simply disagreeable (although I guess I am kinda grumpy), but here’s what I see coming down the pike: on the back of a new moniker (“ajax”), and a newly discovered set of old APIs (namely XMLHTTP), a lot of people are going to make a lot of very nasty messes with this stuff. Why? Because doing “ajax” right IS hard, and it IS non-obvious.

I’ve also done GUI programming in other environments, and from my perspective it’s much easier to wade through GTK’s crappy docs or deale with the Swing threading model than try to get things to “go” in DHTML. When we did the netWindows combo box that had to handle 30K rows w/ real-time filtering on the client side, it became pretty obvious how limited we really are in this environment. There are very few people that I know of that do this at a professional level (I’ve started tracking them at http://dojotoolkit.org/~alex/DHTML_universe.pdf), and I maintain my assertion that doing a DHTML GUI right is significantly harder than most other GUI programming. It’s not a commodity skill, and I don’t anticipate it being one until the tools get much, much better. We’re working to do that with Dojo, but there’s still a lot of work to be done there. And even then, I fear people will make truly gargantuan messes with this stuff.

Guess I’m just grumpy tonight. I should go back to fighting with the Adobe SVG viewer…

Regards

Comment by Alex Russell — March 17, 2005

Hey, anyone who tries to implement a *GUI toolkit* in DHTML is going to come away crying — no doubt about that. If folks think Ajax is about trying to do something as complex as you can do in Swing or GTK, they’re wrong. It’s going to be a world of tears with little results.

Ajax is about adding interactivity to web pages… not creating Microsoft Word in a browser.

Comment by Ben Galbraith — March 18, 2005

There seems to be a certain amount of FUD going on here. I’ve just implemented my first ‘ajax’ app and I’m no JS guru but it has turned out pretty good. I do come from a rich client background, mostly Swing apps, but having built webapps for a couple of years now, I’m rather liking the possibilities for the typical business app that an Ajax approach can provide.

A couple of arguments that I don’t by:
1) Bandwidth – Ajax works great here since you don’t have to refresh the entire page, and using other techniques such as TrimPaths javascript templates, you could even cache large portions of your apps UI on the client and render client side as needed. Same goes for user data. If the page doesn’t have to refresh, then you effectively have a light cache for data on the client. I will be experimenting with this pretty shortly where we will be caching data as XML and sending deltas of that data back as XUpdate statements to the server.

2) “anyone who tried to implement a GUI toolkit in DHTML is oign to coem away crying”. Well, I’ve seen quite a few commercial DHTML based gui toolkits and I’ve been pretty impressed with their features. Just about every widget can be had, to include internal windows ala MDI style app.

3) Ajax is ‘hard’. I certainly didn’t think so and my experience with javascript was simple client validation stuff with some DHTML (hiding and showing divs and that kind of thing). The API was easy enough and the hardest thing I had to do was account for multiple threads/instances of the XmlHTTPRequest object. Combined with a good ORielly book on DHTML for the DOM api stuff and I was good to go.

Macromedia’s comment was definately off base IMHO. I’ve tried building an app in Flash and IT was hard. As far as I’m concerned the client side of what GMail and Google Maps does is non-trivial, but once understood is actually quite impressive and pretty striaght forward. Gmaps is actually less complex than say Google Suggest, as far as the scripting goes, since suggest has caching features and such. Yes, it is non-obvious, but so is OOP to the average COBOL programmer…

I would agree with Alex’s statement that there are far fewer people doing serious GUI stuff in DHTML/javascript as opposed to other technologies, but the same could have been said regarding Swing a few years ago. If it continues to evolve and move along like it has, more and more people will become skilled in it.

Comment by Robert McIntosh — March 18, 2005

> Macromedia’s comment was definately off base IMHO.

Can we agree that it would be useful to examine the actual costs of producing, testing and maintaining various types of applications…?

Regards,
John Dowdell
Macromedia Support

Comment by John Dowdell — March 18, 2005

Ben, if your code is non-trival (30KLOC or more), then you’ve got bugs you don’t know about. Unless of course you tested your system on dozens of different platform combinations.

It’s not no much that it’s hard to get this stuff to work. It’s that it’s hard to get it to work in every browser/OS combo. And if you software is important/critical, it’s important that all your users can use it.

It’s also impossible to automate testing on all these combinations which makes QA a problem.

Comment by Michael Slattery — March 18, 2005

JSUnit helps (but doesn’t solve) the testing problem.

Comment by Jeremy Dunck — March 18, 2005

I agree with Robert and Ben, the attractiveness of Ajax and Ajax-style solutions is that they are *easy*. I’m a business person with very limited JavaSxcrip, HTMl and CGI programming experience and was able to learn XMLHTTP and create some stuff that I wanted in a day. I wouldn’t even know where to begin with Java and Flash. Noone said you need to create 30KLOC or have it work on every browser or have it scale like Gmail. You just need to be able to do things that you want to do.

Sure it might be hard to “do DHTML right” or “optimize for widescale deployment” but that’s not necessarily the question.

The one thing that’s hard is writing xmlhttp apps that cross-domains. I’m not really certain why this is prohibited by browsers.

Comment by pb — March 20, 2005

The first time I saw ‘AJAX’ is was called remote-scripting by Brent Ashley. He had a nice solution. There are ‘many’ types of ajax solutions which can handle the majority of browsers (ie, xmlhttp, hidden-frame). From a Cold Fusion developer stand-point, I created custom tag can be used as the controller and a different custom tag for the view (ie., all form elements,div,span,layer tags). Just the model is the ‘hard’ part since it can go against any database (ie., Oracle, SQL Server) and use any of its objects (ie., tables, views, sp). We use ‘ajax’ for our 2/3 selects instead of the typical custom tag which loads the data into a javascript array. We have too many rows of data for that solution. I personally look at ‘ajax’ as more of a mindset for create web applications.

Comment by Patrick Whittingham — March 21, 2005

Leave a comment

You must be logged in to post a comment.