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.

RCP revisited

For a long time I've been a proponent of thin clients.  Any browser, zero admin, and all that.  Might it be time to rethink this approach?

Every company for whom I've worked or contracted has their target users inside the company.  To certain extent, they control their clients.  There has been many times that a rich client (fatter than a browser) would have solved a particular UI issue, yet usability has been sacrificed because of the browser limitations.  Ajax solves some of that but at a cost of complexity.

I've been thinking about this a lot for the past month.  Much of the material that I've Googled is about a year old.  As I write this in the first few days of 2007 so much has changed in the past year.  We have the new version of Eclipse, Vista is ready to ship, IE 7, Spring RCP is coming along...etc.

Am I alone here?  Is anyone else reconsidering their client platform strategy?  If so, how?
OneMist8k Send private email
Thursday, January 04, 2007
 
 
The same issues exist on the intranet as on the internet. People want to just point and use. They don't want to install and you want them to have to upgrade to use new features. Even something like Web Start can be too much overhead for getting an application adopted.
son of parnas
Thursday, January 04, 2007
 
 
I get your point but I prefer, BY FAR, web clients. They are easier to code (at least for me), easier to update for every user, and users are starting to get used to web applications. We are not there yet but we will reach a point where all this kind of stuff will be done over web clients. I have created other kind of clients in the past, and although it was funny to create a communication protocol I expect that to be a once-in-a-lifetime experience. Since sometime ago I always prefer to leverage the simplicity of HTTP.
Roberto Alamos Moreno Send private email
Thursday, January 04, 2007
 
 
I don't know why we have to keep going over this same argument all the time.

Some apps are better as web apps and some are better as thick clients. And some are better as a combination of the two.

Can we just move on now?
I'll be the pest
Thursday, January 04, 2007
 
 
I have to agree with the previous poster, there is no (and probably never will be) one silver bullet technology that is appropriate in all situations. Every technology has trade offs which need to be weighed before selecting the best option.

I do in-house development for my company and I do a lot of web apps, but there are certain projects where thick clients still make more sense.
Dan Boris Send private email
Thursday, January 04, 2007
 
 
A big factor is the introduction of Vista, because it has the .NET framework pre-installed.  So, once Vista becomes as widespread as XP is now, ClickOnce .NET clients will become very easy for intranet apps.  ClickOnce is the .NET equivalent of Java WebStart, and it's built into .NET and ships in Vista.

For internet apps, for use by the general public, web apps will still be the way to go because for public apps you cannot control the user's platform.

Has my view changed?  No, I was already in favour of rich clients :-), with .NET code running on the client.

Roberto, ease of coding is partly about what we're accustomed to, and how we go about designing our apps.  IMHO, with an appropriate design, rich clients are easier to write - if you are trying to implement similar functionality to what a web app would do. In reality, rich clients often do _more_ than what a web app could do, so they give more value but they don't necessarily cost less money. And, you don't have to write your own comms protocol.  My rich clients talk to the server via HTTP, with .NET taking care of all the "plumbing" for me.
John Rusk Send private email
Thursday, January 04, 2007
 
 
Ahh, but *which* .Net Framework?

I suspect that even if there is a window of opportunity for this in Vista's 1st year of release it won't last long.  Isn't the Framework 3.0 (the *real* 3.0, or is that 3.5? 4.0?) getting close to release just post-Vista?

Then consider the Vista adoption timeframe, ...

I think .Net on the desktop is doomed to the same fate as Java on the desktop: niche applications.


The sweet spot has always been DHTML pages hosting ActiveX controls, at least if we're talking about Windows.  Rich client look, feel, and capabilities with web-based deployment.  Of course there is the obvious issue of security that brought it all crashing down.  Too bad the whole concept of code signing is so useless.
Imagine!
Thursday, January 04, 2007
 
 
Interesting, John.  But isn't ClickOnce dependent on Windows?  We have a lot of Mac users at my current company. (A lot of artistsy types that insist on it *sigh*)  It seems like the Eclipse RCP has many of the same advantages, plus being cross platform.

We have a project starting up at the end of 2007 to integrate screen pops in our new VOIP phone system.  There is some, not alot, of information on how to do that in a browser.  Much of it is proprietary. 

The automatic on-line software updates using eRCP is appealing, the Mac & Win compatability is appealing, the richness of the UI is appealing.  I have no experience with it and don't want to be lured into a minefield of unknown issues.
OneMist8k Send private email
Thursday, January 04, 2007
 
 
I haven't touched Java for years (went down the Delphi and .NET route instead) so I can't really comment on the Eclipse RCP approach.

Yes, ClickOnce is Windows-only.  For the vast majority of businesses (those I deal with at least) that's not a problem, because they have standardised on Windows anyway.

If you need to support Macs your choices include Eclipse RCP as you mention, or maybe Citrix/Terminal Services (again, I haven't tried that with Macs, and I'm not sure whether it would meet your requirements for your VOIP project, but I suspect its a viable option for many organisations with a minority of users on Macs and a desire to write rich clients in Windows-only technology).

Hopefully, someone reading this thread will have experience with the Eclipse approach.

BTW, it is the official, real, .NET 3.0 that is in Vista.  The version due later this year is 3.5. I wonder if adoption of 3.5 will lag someway behind 3.0, simply because 3.0 is the one in Vista.
John Rusk Send private email
Thursday, January 04, 2007
 
 
> Ajax solves some of that but at a cost of complexity.

Yes: I find it amazing how much functionality people can implement using Ajax; the problem (I find) being how difficult it is to implement.

> Is anyone else reconsidering their client platform strategy?

As mentioned in http://discuss.joelonsoftware.com/default.asp?biz.5.428037.13 I'm thinking of a ClickOnce application now, instead of an application implemented using Ajax-in-a-browser.

It seems a bit crazy (!), but what I'm trying is to write an application, starting by implementing the functionality of a web browser ... but less complicated only in that it only needs to be able to browse the XHTML that can come from my web site (it doesn't need to browse mal-formed HTML, or other features/content such as JavaScript if these aren't emitted by my web site).

To that basic browser functionality, I would then add the extra functionality that I would otherwise (if I were running i a standard browser) have needed to implement using Ajax: instead of implementing it in JavaScript to be emitted by the web site to run in a browser, I can use the HLL with which I implement my application (e.g. C#).

It seems like a terrible decision:

* Using Ajax means using an environment that has evolved: JavaScript+DOM+CSS+browser does not add up to a great language+API+widgetset+O/S.

* On the other hand, not using Ajax (and starting by writing a browser from scratch as above, begining with a custom control to render HTML because the .NET framework's built-in WebBrowser control requires the FullTrust security permission) sets off the wheel-reinvention alarm bell.

> I have no experience with it and don't want to be lured into a minefield of unknown issues.

That's my fear of choosing run-using-Ajax-in-a-browser: the possibility that I might hit a limitation of the browser's built-in functionality and not be able to work-around it.
Christopher Wells Send private email
Friday, January 05, 2007
 
 
Maybe you would find the Yahoo's UI library handy:
http://yuiblog.com/

It has support of CSS, DHTML, JavaScript, and even some graphics. :-) It's very well implemented, following the way some desktop libraries would work, but without forgetting the dependency of the HTML/web browser. Also they have that awesome blog to keep the buzz rolling. I'm using it and I like it.
Lostacular
Friday, January 05, 2007
 
 
There are several UI libraries, including Dojo and Atlas.

One piece of functionality that I want is WYSIWYG editing of HTML. There are scripts for that too, but the Dojo script for example is so large that I fear not being able to understand/extend/support it; and, it relies on the browser's built-in implementation of editing, which may not let me have all the strict control over the HTML editing that I want to have.

Another piece of functionality that I may want eventually is the ability to edit diagrams (like UML diagrams for example); which is easy to do with GDI as an API, but which in a browser might require something like using in-browser Javascript to edit SVG data (with SVG not being well-supported by the browser, and so on).

It is remarkable and impressive how far people have been able to push the envelope of what it's possible to do in a standard browser.

However if your reusing a browser is just an implementation detail and not an actual up-front end-user requirement, it might be the wrong choice of implementation strategy: analogous to customizing a car, when instead you should have started with a airplane or a bicycle?
Christopher Wells Send private email
Friday, January 05, 2007
 
 
Great link, Lostacular.  I just perused the site.  There are very good posts by very intelligent developers.  Excellent resource for thin client development.  Thank you!

I wonder if we'll ever see the end of this debate.  Every evolutionary step of the browser and RCP technology will reserect this discussion.  Sometimes it reminds me of the stimulating Buggs and Daffy debates of my childhood:

"Duck season!"
"Rabbit season!"
"Duck season!"
"Rabbit season!"

And poor Elmer tries to click his way through the rhetoric.  :)
OneMist8k Send private email
Friday, January 05, 2007
 
 
Yes, there are shortcomings, but I think the line should be drawn somewhere to separate the Web/Internet from the Desktop application. To me, the Sandbox is one hint -- if you to run untrusted code, then you might want a Desktop application. That's the security that the Web guarantees, and one shouldn't try to break it if possible. If you break it, you may become subject to security breaches, for instance.

Then you have all the problem of updates; for example, security patches. Even if you just wrap some HTML rendering component. And the problem is two fold: client and server.

I think eventually Firefox will be used in some incompatible fashion, and might become the main competition to the WPF alternative, with the bonus of being really cross-platform. Maybe one will be able to harness the features of Firefox without the need to distribute a personalized copy of it? :-)

Anyway, I have taken a look on Dojo, and they are doing a good job, but I think their eyes aren't on the ball necessarily. Their "engineering process" might be superb, with lots of tests and whatnot, but the idea is to create optimized and easy to reuse code, or not? If not, then one might be better using YUI, which I am doing. This YUI user has some cool open source extensions for instance: http://www.jackslocum.com/blog/index.php

Personally I am eyeing his Grid. :-)
Lostacular
Friday, January 05, 2007
 
 
If Microsoft has its way this will all be cleared up by the use of XAML. You will deliver the exact same application either through a browser or installed as a thick client application. Well, that's the theory anyway. The technical details show that this is not really the case. But I think that it is a big step in the right direction.
dood mcdoogle
Friday, January 05, 2007
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz