Skip to main content

Chapter 5: The Other Road Ahead

16 replies [Last post]
jonathansimon
Offline
Joined: 2003-06-07

Let's start off the discussion with chapter 5.

Graham talks about web based software in this chapter from the context of ViaWeb -- the software startup he started and eventually sold to Yahoo.

He talks about several aspects of web applications and their superiority over rich client applications citing fast bug fixing, quick release cycles, and powerful server computers.

As a user interface and usability specialist, I have had a lot of time to think about these issues. I think the best model moving forward is going to be the hybrid -- webappps run locally -- something like WebStart, but better :)

Web apps rock for all of the reasons mentioned. Web apps definitely don't rock when it comes to user responsiveness and fidelity. I don't want to have to make a server roundtrip to filter a result set that is allready cached locally as an example. Granted there are ways around that with web programming, but I think the hybrid approach is going to win out --

* Allways get latest version from the web, unless disconnected
* Run locally, never install
* Store data on servers, locally when disconnected (and immediately transfered back up to servers on connection)

Thoughts?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rythos
Offline
Joined: 2004-08-31

Paul points out towards the end of this chapter that MS will have to cannibilize itself to make progress. As in, it will have to destroy it's OS market in order to continue to stay at the top. I also thought MS was moving towards this with Longhorn, and I _know_ they are moving towards this with .NET. What I wonder is why Paul didn't mention any of this? I think the guys at MS are reasonably smart, and appear to be able to recognize when it's time to move tactics around.

johnm
Offline
Joined: 2003-06-06

> I think the guys at MS are reasonably smart, and appear
> to be able to recognize when it's time to move
> tactics around.

But this sort of cannibalization is [b]not[/b] a tactical issue, it's a strategic issue. This sort of transformation is much more fundamental than just putting out an internal memo (aka press release :-) that says e.g., "Now we will make our software secure." It's roughly equivalent to changing your DNA and there's lots of potential negative outcomes relative to continuing to exploit their existing strengths.

rythos
Offline
Joined: 2004-08-31

Agreed. As has been pointed out, a web based approach in OS agnostic. And seeing as MS's wealth is based on Windows/Office, it could be considered equivalent to knawing your own arm off to fend off attackers with. ;)

Paul believes that MS will die if it doesn't do this. I'm not certain. I think the web based approach has many plus sides. But I also think that despite many attempts to fix it, the programming model isn't what I would consider "beautiful", or "easy to deal with". It seems like the only reason that web programming is coming out in strength is because the "perfect solution" wasn't standardized from the beginning, whereas HTTP is standardized ;). What do you think?

johnm
Offline
Joined: 2003-06-06

> As has been pointed out, a web based approach
> in OS agnostic.

Not necessarily -- but it certainly can be. For example, look at all of the hell created by sites built to the insanity of MS IE. Before too many folks start patting themselves on the back for following the web standards... have they actually tested their sites on cell phones and handhelds or, heaven forbid, with people who have bad eyesight (e.g., color blindness, near-/far-sightedness, completely blind), poor motor control, etc.?

> And seeing as MS's wealth is based on
> Windows/Office, it could be considered equivalent to
> knawing your own arm off to fend off attackers with.
> ;)

:-) But isn't the point to consider it that your first child has grown up and it's okay to have more children?

> Paul believes that MS will die if it doesn't do this.
> I'm not certain.

Well, $50 billion or so in cash and a desktop monopoly does go an awful long way.

> I think the web based approach has
> many plus sides. But I also think that despite many
> attempts to fix it, the programming model isn't what
> I would consider "beautiful", or "easy to deal with".
> It seems like the only reason that web programming is
> coming out in strength is because the "perfect
> solution" wasn't standardized from the beginning,
> whereas HTTP is standardized ;). What do you think?

One argument for this is given by Worse is Better (http://www.dreamsongs.com/WorseIsBetter.html). In terms of HTML and HTTP specifically, the freedom (and hence lowered barriers to entry, decentralized but potentially very low cost of gaining network externalities, etc.) on the publishing shouldn't be discounted. The relative standardization of web protocols certainly helps.

In the long term, neither the current web models nor the every desktop is an island models will survive as is. The spectrum of how most people really (need/want to) work is in between those two. The problem is that we as an industry don't have a grip on dynamic, distributed, decentralized, and disconnectable systems. Part of that problem is that playing at this level of complexity isn't a question of coming up with the one, "right" answer but is about things like incomplete context, systemic tradeoffs, and ecologies.

mardigrasboy
Offline
Joined: 2003-09-04

Isn't XFORMS going to take care of the initial part of this? My concern going forward is that the user and server can certify each other. Since we rely so much on JavaScript from the client how I can I verify that a event has really occured to my user on the browser. What I think is the browser could easily be a trojan horse or test program faking request and responses.

If the browser has simple but secure ways to verify client-based events we can rely on a contained environment with less posts to the server.

johnm
Offline
Joined: 2003-06-06

> Isn't XFORMS going to take care of the initial part
> of this? My concern going forward is that the user
> and server can certify each other. Since we rely so
> much on JavaScript from the client how I can I verify
> that a event has really occured to my user on the
> browser. What I think is the browser could easily be
> a trojan horse or test program faking request and
> responses.

Hm... XForms, JavaScript, DHTML, and the like are certainly not up to creating truly intelligent, stateful, disconnectable, etc. clients.

In terms of "certification", I'm not sure what problem you're trying to solve. You, from the server, cannot, a priori, have any objective confirmation that something sent actually came from a "user".

jonathansimon
Offline
Joined: 2003-06-07

Dig.

> Basically, over time, the "browser" will become, from a developer's perspective, a complete operating system

I think this is more true than people are letting on. I know MS is making some moves in this direction with Longhorn. On the downside, I know MS is trying to make is all proprietary with their backends.

I think this is actually really cool because app developers can choose how thick/think they want to be. The infrastucture is all there. That would rock.

Another interesting thing is the move towards being OS agnostic. Everything happening in a new thick/thin browser really minimizes the reliance on any OS.

-j

johnm
Offline
Joined: 2003-06-06

[...]
> Another interesting thing is the move towards being
> OS agnostic. Everything happening in a new thick/thin
> browser really minimizes the reliance on any OS.

Not necessarily. At one level, it's just moving the battle up one level of abstraction. One key is that there must be interoperable standards that are actually useful and usable.

jonathansimon
Offline
Joined: 2003-06-07

On this front, I just wanted to point out a9.com - a very cool middle ground. You have a locally running application with data stored remotely. You have all of the thick client benefits without any of the nteraction issues. If we can only get around installation!

-j

ljnelson
Offline
Joined: 2003-08-04

Quick question (not loaded): what would you have WebStart do better?

Cheers,
Laird

jonathansimon
Offline
Joined: 2003-06-07

This is a little off topic, but Ill get back to Chapter 5 in a second ... I don't want to have a huge web start discussion here, but if people are interested in discussing it, I can post a blog and we can chat about it there.

Now web start ...

I don't have issues with WebStart in general. I look at more the whole user experience -- especially with the initial JVM download.

Most users are turned away by the intial download size of the VM in one shot. In an ideal setting, Webstart would be 100% transparent (users would never have to interact with it once its there), any library would be downloaded seamlessly whether part of the VM or an extranel Jar, new versions (are parts of new versions) would be downloaded and used by Webstart apps without affecting other Java applications and so on. A user would have to install a 100k plugin or something and they're off.

Again, I think WebStart is going in the right direction. I just think more of a generic cross platform thick/thin hosting environment is in the future -- and I think its going to rock when it shows up.

There, I got back to Hackers and Painters. Does anyone know any projects moving towards this type of thin/thick hosting environment? In any language?

-jonathan

ljnelson
Offline
Joined: 2003-08-04

Good points, all. No more sidetracking from yours truly. :-)

L

rythos
Offline
Joined: 2004-08-31

When I did my first freelance project many years ago, the web based approach was the one I took. The reason I gave that client was all of the reasons given in this chapter.

There is another one that pleased me in particular and my business associates because I told them that they should be pleased by it. I found it much easier to write this project open-sourced because we could explain to the client that they were paying for a) our setup, b) our support of the program, and c) the web and database server we ran the program off of.

This project died an ignoble death, and looking back on it I'm glad it did. Applets were a good idea at the time, but are still not known for their "user-friendly" experience ;)

erikhatcher
Offline
Joined: 2003-06-08

I've been predominantly a web app developer for over a decade, beginning with Perl CGI, going through ASP, JSP, Struts, and now focusing on Tapestry. Paul's insistence that the only way to build an application is as a web application, though, is a bit over the top. It is the right way in some cases, but impractical in other scenarios.

I agree with Jonathan that hybrid approaches are great solutions. Consider Subversion, the new CVS replacement version control system. It takes a very nice hybrid approach allowing for offline status, diffs, reverts, and other operations, and then updates when connected quite nicely.

johnm
Offline
Joined: 2003-06-06

> He talks about several aspects of web applications
> and their superiority over rich client applications
> citing fast bug fixing, quick release cycles, and
> powerful server computers.

Moving forward, I think one of the keys is that people will start seeing the definition of those two extremes get closer and closer together. Things like applets and JWS are a start and some of the p2p folks are heading somewhat in this direction too. Basically, over time, the "browser" will become, from a developer's perspective, a complete operating system within which there will be a spectrum of ways to do things (as a programmer) from lightweight clients (i.e., everything except view on the server) to bloated clients (i.e., server? oh, I only use that to suck down the latest version of the bloated client).

Oh yeah... wasn't Boswell recently hyping tools, libraries, etc. for doing occacsionally connected software solutions for a company that he's no longer at? :-)

erikhatcher
Offline
Joined: 2003-06-08

> Basically, over time, the "browser" will become,
> , from a developer's perspective, a complete
> operating system within which there will be a
> spectrum of ways to do things (as a programmer) from
> lightweight clients (i.e., everything except view on
> the server) to bloated clients (i.e., server? oh, I
> only use that to suck down the latest version of the
> bloated client).

Let's give some credit to Microsoft on this front. Back in the day, Microsoft's DHTML, behaviors, and other capabilities were pushing the state of the art for this very thing (browser as an O/S). They got slapped down and many complained of them pushing their way as the standard instead of playing by the "rules". In my opinion, we need more rule breakers!

> Oh yeah... wasn't Boswell recently hyping tools,
> libraries, etc. for doing occacsionally connected
> software solutions for a company that he's no longer
> at? :-)

And I wonder what kinds of things his new company will be doing soon?! :))