Lambda the Ultimate

inactiveTopic Death of the client
started 1/28/2001; 7:26:20 PM - last post 2/6/2001; 4:30:15 AM
Chris Rathman - Death of the client  blueArrow
1/28/2001; 7:26:20 PM (reads: 1409, responses: 11)
Death of the client
As much as I dislike discussing programming languages as politics, those who try to roll out client software are constantly confronted with the issue. It seems that Java on the client is all but dead, what with MS being resistant and AWT/Swing being a dog when it comes to internet based clients. The .NET strategy from MS doesn't portend any relief either, since they seemed to be of the mind that the Trust Model is the one true way.

Count me as a pessimest, but I think that client software is advancing at a snail's pace. There's a plethora of programming languages available on the server side, but unless you want to use plugins like Flash, Dolphin Smalltalk, etc..., your options are rather limited. Interesting that the server side is getting standardized, when in fact the real need for standardization is on the client.
Posted to general by Chris Rathman on 1/28/01; 7:28:29 PM

andrew cooke - Re: Death of the client  blueArrow
1/29/2001; 12:27:49 AM (reads: 1433, responses: 0)
Maybe the Curl people aren't as daft as they look then ;-)

Ehud Lamm - Re: Death of the client  blueArrow
1/29/2001; 12:59:01 AM (reads: 1440, responses: 0)
It is a doubly absurd situation. Java's claim to fame was interoperability/portability. This was the reason a far from perfect language gained its market share. Now the feeling is that this portability still leaves something to be desired, even as compared to other languages (e.g., think Squeak). But beacuse of the market share, the language is to be use in areas where this is not important.

andrew cooke - Re: Death of the client  blueArrow
1/29/2001; 1:08:56 AM (reads: 1447, responses: 0)
That's what's happening with us - we write client and server-side stuff in Java. To be honest, I'm thankful for the hype. I doubt the company would have gone with anything other than C or C++ if Java hadn't been the next big thing when they first started. And if I had to choose one of those three languages I'd choose Java.

A decent native (W32) compiler would be nice - maybe they exist now, but when I tried some out a while back, they were too flakey and/or didn't support the GUI/latest language version.

Ehud Lamm - Re: Death of the client  blueArrow
1/29/2001; 2:53:50 AM (reads: 1442, responses: 0)
Great endorsment: C++ is worse...

Adam Vandenberg - Re: Death of the client  blueArrow
1/29/2001; 11:40:33 AM (reads: 1414, responses: 0)
Call me something-something, but I'm really tired of doing server-side programming. Granted the language I've been using at work for the past 3 years is Not My Favorite (TM), but no matter what language you use it's just talking to databases here and outputting HTML there.


Well, actually, it's not always boring. I've had a lot of fun co-writing a side project in Python, a project that has absolutely nothing to do with money. But now that the back-end is as good as it needs to be the thought of working on it is... you guessed it... boring.

There are some client-side programs I've been meaning to write, mostly for my own personal use. I'd like to write them in Python (current language of choice) but up until a week ago I didn't know any good widget libraries.

Then I found wxPython. Pretty slick, and it even wraps up the rich controls that TK doesn't come anywhere near. I mean really, all my projects require tree controls, and the only tree controls I've found for TK crash.

If I had to write my client-side stuff in C++ (maybe with MFC?) or even Java it would have blahed me to tears by now.

Ehud Lamm - Re: Death of the client  blueArrow
1/30/2001; 3:20:57 AM (reads: 1420, responses: 0)
Do you find UI programming more interesting? I guess the question is where the logic is - and most often it is NOT in the client/UI.

What interesting client side programming tasks are you fond of?

Cameron Laird - Re: Death of the client  blueArrow
1/30/2001; 2:41:57 PM (reads: 1405, responses: 0)
I'm sure the problem of crashing Tk tree widgets is solvable.Let me know if you need help.

The part about Swing being too slow for "Internet" clients--areyou talking about what I call "Web" clients (browsers), or ... well,I'm confused. I quite agree that Swing is heavy, too much so formost of what I do. I don't get the connection to networking you'remaking, though.

My emotional response to this topic is that the current client-sideWIMP is good enough. I don't see a model for user-machine interactionthat I think will be more successful. Flash, for example, is exciting,but only to people who already understand it. I think in terms of end userswho are largely afraid to push the wrong button.

Adam Vandenberg - Re: Death of the client  blueArrow
1/31/2001; 12:54:48 AM (reads: 1371, responses: 0)
Well for instance, I'm writing a Windows tray applet that polls a website I co-write for and lets me know if there are any new posts waiting for replies.

It involves talking to the server (probably through some XML-RPC, an excuse to play with it), and present a simple UI.

Sure I can always check the site through the browser, but it's just more fun to have this dinky little notifier that pops up a list.

A big part of it all is that I'm tired of rendering everything into HTML, and having to come up with page-click-page interactions for everything.

Ehud Lamm - Re: Death of the client  blueArrow
1/31/2001; 9:18:16 AM (reads: 1382, responses: 0)
A big part of it all is that I'm tired of rendering everything into HTML, and having to come up with page-click-page interactions for everything

This is, of course, not a programming language issue. But I agree that this is a bad paradigm, both for users and for programmers.

tablizer - Re: Death of the client  blueArrow
2/6/2001; 1:24:03 AM (reads: 1347, responses: 0)
[HTML] is, of course, not a programming language issue. But I agree that this is a bad paradigm, both for users and for programmers.

I have kicked around ideas for an open "server controled GUI language" or semi-language where GUI definitions are sent to the client, but the logic is on the server. IOW, *no* IF or WHILE loops, etc. on the client side. Putting an exucutable language on the client opens up all kinds of worm-cans.

It would basically be commands to display and undisplay widgets and send their content when asked.

Existing stuff seems to want to send every fricken keystroke back-and-forth. I would rather see smarter widgets on the client side that only send stuff when explicitly asked to, or told to ahead of time, IOW, a syncronous and asynchronous mode.

However, based on the discussion, I will have to produce a prototype before anybody takes the idea seriously.

That way we can get back to regular GUI's and IDE's for web stuff and forget about HTML forms.

andrew cooke - Re: Death of the client  blueArrow
2/6/2001; 4:30:15 AM (reads: 1366, responses: 0)
#include apologies-for-MS-specific-info.h

I went to an MS developer conference a while back and one of the tools they demoed sounded very much like what people here are asking for. It supported web desing using high-level components which were implemented by the underlying system in a manner appropriate for the client. This included automatic handling of state. So, for example, you could define instantiate a form method with constraints, and call a method something like "interact with user" and the read the form values back from the method. The underlying system would generate pages in HTML, do verification using Javascript or post or whatever most suitable for the client, etc.

Cleints included HTML (different browsers, support for Javascript or not etc) and XML (WAP?).

Can't remember the name of the product.