Weblogs Forum - When the Browser is an Inadequate Interface

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
When the Browser is an Inadequate Interface

48 replies on 4 pages. Most recent reply: Mar 17, 2005 9:36 AM by Erik Neu

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 48 replies on 4 pages [ « | 1 2 3 4 | » ]

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: When the Browser is an Inadequate Interface

Posted: Mar 6, 2005 3:52 PM

"Most jobs are for server-side programming"

Most of that server-side programming is server-side UI programming - emitting HTML. Some of that has been componentized in some of the better frameworks.

As for the widgets I've shown being simple - yes they are (although measuring richness of behavior by lines of code is naive). We're right now at about the level of the 1984 Macintosh UI in the browser. Only we have color now too.

This summer, Safari will introduce vector drawing with fancy compositing. FireFox and IE will follow suit I'm sure. Within a couple years, the browser will become the UI server - a bit like the window server in NextStep.

Here's the kicker. The primary language used to do rich clients is going to be good old quick and dirty little language that could JavaScript. Not rigid over engineered Java.

I think we're stuck with the browser but that's OK, the browser is evolving. JavaScript is going to become a hot skill for awhile - until the component libraries get established and become commoditized.

If I were looking to stay cutting edge and still doing development, I'd be out learning JavaScript right now.

Joe

Posts: 24
Nickname: larson
Registered: Nov, 2004

Re: When the Browser is an Inadequate Interface

Posted: Mar 6, 2005 7:02 PM

Yes, measuring complexity in LOC is simplistic and gives at the most an indication of the maturity of code.

One of the issues not addressed here is security. In a J2EE contract earlier this year I was asked to investigate why a certain web application generated database entries that obviously violated some validation rules. The business people and original developers could not figure out why it happend and could not reproduce it. I was walked through the application and shown all the testing that was done. First thing I did was turning off JavaScript and guess what: Validation was done in JavaScript on client side but no validation was done on server side. Whoever had JavaScript disable could enter whatever they wanted. I ended up implementing all validation on the server side again.

I think a lot of security issues are better and easier dealt with in a rich (desktop) client application that communicates through single points of SOAP messages instead of the many points of communication a html UI mixed with a JavaScript UI opens up. I am sure an extremly exensive amount of time went into making GMail secure.

There is nothing wrong with the well understood paradigm of a stateless application. But emulating an event driven application on top of it is difficult. And it certainly does not help to try and do it with a sloppy programming language.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: When the Browser is an Inadequate Interface

Posted: Mar 7, 2005 10:41 AM

> Yes, measuring complexity in LOC is simplistic and gives
> at the most an indication of the maturity of code.
>
> One of the issues not addressed here is security. In a
> J2EE contract earlier this year I was asked to investigate
> why a certain web application generated database entries
> that obviously violated some validation rules.

That's obviously stupid. You define constraints in your database don't you? Why bother if your app enforces the constraints? Because other apps might not?

Data validation belongs in all 3 tiers - yes its redundant. But you never know when one tier will be bypassed.

> I think a lot of security issues are better and easier
> dealt with in a rich (desktop) client application that
> communicates through single points of SOAP messages
> instead of the many points of communication a html UI
> mixed with a JavaScript UI opens up.

No, security - the real stuff - belongs as far back in the application as possible. Typically in the database or the api just above it. All other checking is for UI reasons only (quicker feedback for the user).

> There is nothing wrong with the well understood paradigm
> of a stateless application. But emulating an event driven
> application on top of it is difficult.

If its a client/server kind of architecture, you have all the same problems with a desktop app as you have with the web based app in terms of data currency.

An example I've encountered is a naively written PowerBuilder 2 tier app that simply edits tables. Great, until two individuals fire up a copy and begin overwriting each other's changes.

> And it certainly does not help to try and do it with a
> sloppy programming language.

Completely orthogonal to the problem. However, I think it is cumbersome to express validations in multiple languages. Either we are going to end up using javascript on the server to make sharing logic easier, the browsers are going to get more language interpreters, or we will end up inventing a neutral language that can express data validation rules that can be used to render the logic in any of the other languages.

Joe

Posts: 24
Nickname: larson
Registered: Nov, 2004

Re: When the Browser is an Inadequate Interface

Posted: Mar 7, 2005 4:14 PM

> > In a J2EE contract earlier this year I was asked to
> investigate
> > why a certain web application generated database
> entries
> > that obviously violated some validation rules.
>
> That's obviously stupid. You define constraints in your
> database don't you? Why bother if your app enforces the
> constraints? Because other apps might not?
>
> Data validation belongs in all 3 tiers - yes its
> redundant. But you never know when one tier will be
> bypassed.

Some rules cannot be checked in your 3rd tier (the database). Say a rule in this insurance application was "a family policy is only valid if one or two but not more than two of the insured people are over 18". It's simply not possible to enforce this with constraints. Even if, it would be pretty difficult to pass back an error message that makes sense.

Redundancy is never desirable. It leads to lower quality and higher costs. The right choice here would be to have validation only in the second (lets call it application server) tier. However with a JavaScript frontend of a web application you will always be reimplementing the same rules.

> If its a client/server kind of architecture, you have all
> the same problems with a desktop app as you have with the
> web based app in terms of data currency.

You will have to deal with concurrency in stateless and stateful applications. And you can in both. But that wasn't what I was talking about. I was taling about emulating an event driven programming model on top of a stateless protocol.

> > And it certainly does not help to try and do it with a
> > sloppy programming language.
>
> Completely orthogonal to the problem. However, I think it
> is cumbersome to express validations in multiple
> languages. Either we are going to end up using javascript
> on the server to make sharing logic easier, the browsers
> are going to get more language interpreters, or we will
> end up inventing a neutral language that can express data
> validation rules that can be used to render the logic in
> any of the other languages.

I think it does matter what kind of language you use to implement your frontend and backend logic. I agree with you that it makes sense to use the same language but I disagree with your choice of language. I think the way to go is using rich clients and server components that are either written in java or c#. BTW there is JavaScript on the server side. It was implemented in the mid 90's in Netscapes web server, but it never really became popular.

Your idea of the neutral language is interesting. ASP.NET has some validation controls that are translated into JScript on the client side and at the same time implemented in VB or C# on the server side.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: When the Browser is an Inadequate Interface

Posted: Mar 7, 2005 10:38 PM

"I agree with you that it makes sense to use the same language but I disagree with your choice of language. I think the way to go is using rich clients and server components that are either written in java or c#."

I'm not nuts about javascript as languages go. But neither of the other ones you mention are viable. Java UI's blow. As soon as a java app starts up I can tell its Java and not native because its slow and the quality of the graphics are sub-par and the resizing behavior is quirky. So hear this app developers: I REFUSE TO PAY MONEY FOR JAVA APPS! Don't even bother to write one I will toss it immediately. Example: Quantrix has created a clone of Lotus Improv. Improve was great and I was thrilled to see it resurrected. I eagerly downloaded the app, fired it up, and was disgusted to see it was a Java program. I tossed it in the trash immediately and wrote the company to tell them why they just lost a sale.

C# isn't an option either as I REFUSE TO RUN MS SOFTWARE.

I have only Mac OS X. I will be interested to see what rich clients appear as a result of the new dashboard architecture.

Joe

Posts: 24
Nickname: larson
Registered: Nov, 2004

Re: When the Browser is an Inadequate Interface

Posted: Mar 7, 2005 10:58 PM

> C# isn't an option either as I REFUSE TO RUN MS SOFTWARE.

C# is an ECMA standard (as is ECMAScript, the-language-formerly-known-as-JavaScript). You can use Mono on Linux or MacOS X, the open source implementation of the .NET framework. If you want to be totally open source you might want to use GTK# for your user interface. If you want to be as close as possible to MacOS X check out Cocoa#.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: When the Browser is an Inadequate Interface

Posted: Mar 8, 2005 9:21 AM

> Java UI's blow. As soon as a java app starts up I can tell its
> Java and not native because its slow and the quality of
> the graphics are sub-par and the resizing behavior is
> quirky. So hear this app developers: I REFUSE TO PAY
> MONEY FOR JAVA APPS! Don't even bother to write one I
> will toss it immediately. Example: Quantrix has created a
> clone of Lotus Improv. Improve was great and I was
> thrilled to see it resurrected. I eagerly downloaded the
> app, fired it up, and was disgusted to see it was a Java
> program. I tossed it in the trash immediately and wrote
> the company to tell them why they just lost a sale.

You may not pay for Java apps, but plenty of people do. Certainly, we have plenty of customers who have, and they have never ever complained about the slowness of the app. Not to mentioned that Java-based UIs are fairy common on mobile devices, e.g., cell phones.

JDK 1.5 did fix the ugly font problem by providing an easy option to do anti-aliased font rendering as a default. That was, I think, the last dividing line between a Java/swing-based app and a native app.

Also, JDK 1.5 fixes the applet performance problem, because the applet plug-in and WebStart are now one and the same. Granted, it will take time for desktops to upgrade to JDK 1.5.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: When the Browser is an Inadequate Interface

Posted: Mar 9, 2005 7:10 AM

> I'm not nuts about javascript as languages go. But
> neither of the other ones you mention are viable. Java
> UI's blow. As soon as a java app starts up I can tell its
> Java and not native because its slow and the quality of
> the graphics are sub-par and the resizing behavior is
> quirky.

I find quite a few people saying this. But, things are improving, and I think Sun is starting to understand that this perceived performance/quality is a barrier. I've also noticed that many Swing applications still don't understand how to stay out of the way of the SwingEvent thread. Windows applications that do remote work exihibit this behavior too, if not properly threaded. At any rate, I have a rather large Java GUI application that I've developed over the past 7 years. It does make the whole desktop run slower.

I've watched many bugs go through the bug parade that indicate that the AWT team is still at odds with the microsoft DirectX services and are fighting numerous bugs and descrepencies with work arounds. They are talking about reworking the whole stack to use the opengl implementation by default instead of DirectX.

I think that they are using too many 'UI resources' which causes DirectX to have to do more work in rendering. I think that this is really the root cause of poor performance. The layers of drawing that are occuring neutralize a wide range of per platform issues. That is the value that I see in the Java platform from one perspective.

But, there are many other niceties that I use too which have maintained my interest in Java as the right answer for crossplatform applications.

Historically, the UN*X crowd have only been interested in server applications which don't have GUIs (in general). The windows crowd have been interested in fancy, empowering GUIs. Now, MS is racing to improve the quality of there services and their uptime as they learn more about the server side by hiring old UN*X guru's and researchers that they are putting into MS-Labs to educate their engineers and solve these problems.

Sun is apparently starting to pay a lot more attention to the GUI world. Hopefully, both will accomplish something beneficial to their user bases.

But, my feet are firmly planted in the Java camp.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: When the Browser is an Inadequate Interface

Posted: Mar 9, 2005 10:37 AM

"If you want to be totally open source you might want to use GTK# for your user interface."

Ick. First, C# and Java are the same language in the way the Pascal and C are. Close enough anyhow and I'm firmly in the dynamic typing camp. All that boilerplate adds too little value. IOW I'm of the opinion that the "int" in

int x = 5;

and

List aList = new ArrayList();

similarly so. Its just noise. That's another argument though.

Second, JavaScript support is much wider I think and the client libs are very widely distributed.

Third, were I to consider doing a platform neutral conventional GUI I would most likely choose VisualWorks for a corporate app or wxWindows for shrinkwrap.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: When the Browser is an Inadequate Interface

Posted: Mar 9, 2005 10:41 AM

"You may not pay for Java apps, but plenty of people do."

Lots of people eat at McDonalds too. I'm never that hungry.

"Certainly, we have plenty of customers who have, and they have never ever complained about the slowness of the app."

I suspect you are not listening hard enough.

"Not to mentioned that Java-based UIs are fairy common on mobile devices, e.g., cell phones."

Not relevant. Those are tiny little screens. The processing power required is miniscule. Admittedly the processing power available isn't so hot either, but its just not germane here.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: When the Browser is an Inadequate Interface

Posted: Mar 9, 2005 10:50 AM

(RE: Slow swing)

"I find quite a few people saying this. But, things are improving, and I think Sun is starting to understand that this perceived performance/quality is a barrier"

Only took them 10 years then? I guess dropping by the Swing developers booth every year at JavaOne is beginning to have an impact? Not particularly quick on the uptake I'd say.

Generally, I find lines drawn at oblique angles to be clumsily pixellated. Some stuff gets anti-aliased, some doesn't. The overall quality is sucky and I would be embarrased to release such a thing.

Rendering quality is a third of the problem, speed (and I mean both speed to launch as well as running speed) is the other third. The final third is really stupid default behavior by layout managers. If I create a scrolling list, and I don't put anything into it, the default width is something like 2 pixels wide. OTOH, if I put something into it, then it sizes to fit the widest thing.

The default empty list behavior is stupid and makes my app look like crap. So I spend a bunch of time running around setting minimum widths and stuff. Yes, I can eventually get it looking decent with a lot of work, but its a lot of work I could likely avoid with sane defaults.

But we digress - just to keep things on topic - yet another rich web client.

http://www.francisshanahan.com/zuggest.aspx

I'll shut up now.

Joe

Posts: 24
Nickname: larson
Registered: Nov, 2004

Re: When the Browser is an Inadequate Interface

Posted: Mar 9, 2005 2:10 PM

> Ick. First, C# and Java are the same language in the way
> the Pascal and C are. Close enough anyhow and I'm firmly
> in the dynamic typing camp. All that boilerplate adds too
> little value. IOW I'm of the opinion that the "int" in
>
> int x = 5;
>
> and
>
> List aList = new ArrayList();
>
> similarly so. Its just noise. That's another argument
> though.

This is another discussion but lets get on with it: I am definitely a "static type" programmer. Beside the old argument that defining types of a variable and the guarantee that they do not change during life time a new one has come up: Static typing allows newer IDE's to help you with code completition (called intellisense in Visual Studio). This really is a _big_ help. Of course programming in JavaScript you would never use an IDE...

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: When the Browser is an Inadequate Interface

Posted: Mar 9, 2005 4:24 PM

> Of course
> programming in JavaScript you would never use an IDE...

Or would you? OK, I'm curious - how do people develop with JavaScript? What IDEs are available? How do you test JavaScript code?

James F. Wanner

Posts: 1
Nickname: jwanner
Registered: Mar, 2005

Re: When the Browser is an Inadequate Interface

Posted: Mar 10, 2005 5:30 AM

A client browser is hardly a thin client, if you count all of the components it uses. What sets a browser apart from a fat client is that all of the content comes down the wire. I hope we will see a similar client interpreter designed specifically for applications, so we don't have to munge a web display tool to get it serve a different goal. I have been working on such a system (see http://www.campwoodsw.com/mentorwizard/index.html) and I know others are as well. In my opinion, an application delivery program on the client is a far better solution than applets or any other add-ons to a web browser.

Joshua Smith

Posts: 5
Nickname: jesmith
Registered: Jul, 2003

Re: When the Browser is an Inadequate Interface

Posted: Mar 10, 2005 6:57 AM

Our enterprise software solutions always use a blend of web technologies. HTML/CSS/JavaScript are great for navigating through lots of information, doing search, etc. When it comes time to do some real work, we use Java. Java 1.1, that is -- the really old stuff. For business applications, we use LwVCL, a lightweight UI toolkit, and for rich media we use Meson (http://www.kaon.com/software/swmeson.html -- our own UI-development language), both atop Java 1.1.

For enterprise applications, and for applications in the marketing space, there is no way to overstate the importance of zero-footprint deployment. That's why we use Java 1.1 -- "it just works". Everybody has Java, everybody has HTML/CSS/JavaScript.

I think it's really interesting that the conventional wisdom is that "Java applets failed." That certainly isn't borne out in the marketplace. Have a look at the 3D product models at dell.com, for example: they're using our Java applets. Millions of people have looked at those "applications" to learn about Dell's products over the years.

Recently, we've been working on some really cool marketing applications that have the slick feel of Flash, but the feature-richness (particularly 3D graphics) only possible in Java. The boost in CPU performance over the past few years, and the development of UI layers like LwVCL and Meson have breathed a whole new life into Applets, IMHO...

Flat View: This topic has 48 replies on 4 pages [ « | 1 2 3 4 | » ]

Previous Topic

Next Topic