The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

A New WWW for Online Services?

I find the www sucks for online services that require logging in and doing non-trivial data manipulation. For example online web services such as database managment, website management, forum management, checking email, online trading, etc.

I think the problem is that the http protocol was simply not designed for that kind of thing. I think what we need is a separate protocol with better state management and does a better job of communicating data (i.e. loading a new page every time you send data is inefficient). I know google has hacked something together with their javascript hidden frame technique, but that is just a workaround for the bigger problem in my mind.

Any thoughts or comments?
Christopher Diggins Send private email
Monday, February 28, 2005
 
 
Four years ago I built a control web application for power generation assets (monitoring as well as starting and stopping generators). The page never reloaded, instead continually loading small subsets of the data in the background, updating the GUI accordingly (using the DOM on the XML document(s)). Around the same time I made a data entry application that again used client side XML data islands, inserting nodes directly into the document when users added data, submitting it in the background and silently checking for data changes.

It all worked brilliantly, and didn't require the post-back/full page refresh nonsense that is so prevalent.

Of course, given the laugh that Mozilla was at the time, and the dearth of competition, it only worked in IE, but seeing the capabilities now in Mozilla I think it's broadly possible now, as Google suggests demonstrates.

The sorry state of most web apps says more about the laziness of most developers than anything else.
Dennis Forbes Send private email
Monday, February 28, 2005
 
 
I found gmail to be better than any of the rich-client email readers.

It's impressive what you can do with a little bit of clever JavaScript.
Colm O'Connor Send private email
Monday, February 28, 2005
 
 
I think I've learned to live with the way things work at present.
Pythonic Send private email
Monday, February 28, 2005
 
 
Inefficient data communications is bang on.  But since end users don't really 'pay' or care whether a 200 byte or a 20K byte transfer occurs, it's something that never gets a good looking at.
Crazy Old Guy
Monday, February 28, 2005
 
 
"I think the problem is that the http protocol was simply not designed for that kind of thing."

I don't think HTTP is the problem.  It's not like IM where you'd want to keep connections to the server open.  You can a quick request/response design and HTTP fits the bill.  A push-like protocol for events could be useful but we now have too many Firewalls and NAT to make that viable these days.

"I think what we need is a separate protocol with better state management"

I don't think there needs to be any better state management at the protocol level.

What we really need is not a better protocol but better clients.  HTTP might be the right protocol for data exchange but HTML/DOM/Javascript is pretty limited for the client interface.  We need a UI that can be built up from a description on the server and essentially run entirely on the client except to exchange data (via HTTP) or fetch more UI (again via HTTP) as needed.
Almost Anonymous Send private email
Monday, February 28, 2005
 
 
I've recently started my first ASP.NET app and found that to obtain desktop app like functionality there are all these "Tricks" going on in the background. 
i.e) Postbacks, Viewstates,Hidden textboxes.


It seems to me http just wasn't made for today's applications.
Doesn't it make more sense to design a new protocol rather  than keep coming up with new ways to rig things to work.
New_to_web_dev_guy Send private email
Monday, February 28, 2005
 
 
On private systems I create private protocols, the state is maintained behind the gatekeeper and so in that regard is no better than HTTP but if you think about it as TCP/IP is a somewhat hit and miss connection anyway you really have to go with the laissez faire 'oh here you are again, here's some data you didn't get last time' or 'oh so you say you're so and so, well prove it you insecture little connection you'.
Simon Lucy Send private email
Monday, February 28, 2005
 
 
Even I have no idea what the word insecture means, use insecure instead freely.
Simon Lucy Send private email
Monday, February 28, 2005
 
 
Sorry to be a bit self-promoting, but many of the reasons listed in this thread are exactly why the RIA software market space, and specifically Nexaweb http://www.nexaweb.com (the company I work for) exist.

HTML is great for some classes of applications (like publishing content) but misses the mark with applications that require a good bit of interaction with the end-user. Use of JavaScript can help, but as the UI gets more complex the maintenance of that JavaScript logic becomes impossible.

The Nexaweb platform has Java on both sides of the net, tunneling via HTTP. As was pointed out earlier on this thread, its not so much a problem with HTTP, but with the code surrounding it. With a small Java client (160 KB; JRE 1.1) dynamically downloaded into the browser, and JSP/Servlets deployed in the middle-tier, Nexaweb can provide a better messaging fabric.

Getting off the sales soapbox... My point is that the RIA marketplace has come into existence for exactly the reasons stated in this thread - to fill the need for those classes of applications that need a much more interactive user interface and provide access to live data.
Scott Cranton Send private email
Monday, February 28, 2005
 
 
New_to_web_dev_guy, asp.net is just about the worst place to start if you're trying to understand Web applications. As you noticed, asp.net tries to make web applications like programming desktop applications. The result is a framework that is IMHO overcomplicated and obscures a lot of what's actually going on.

Learning to develop web applications with asp.net is a bit like going to truck driver school when you really want to ride a bicycle. You'll spend a lot of time learning something very complicated which will eventually get you to your destination, but you still won't know how to ride a bicycle when you're done.

You're right that HTTP isn't designed for the sort of applications that we're building today. However, it's widely deployed and scales well and therefore is better than most possible alternatives.
comp.lang.c refugee
Monday, February 28, 2005
 
 
the web sucks and is dying...why...well, its structure...basically all websites or services need a central location...this is great for companies which want to control content; but sucks for real interaction desired by real people.

an this web-services crap...is crap. basically its RPC with xml. I built the first java-to/from xml webservice for a financial group...it was sooooo slow because of all the parsing that needed to take place before any of the actions could take place;

about http --- the protocol is nice, its simple and effective; but has been totally corrupted to allow/extend the protocol so companies like microsoft/apple/macromedia/sun/etc. can export crap technologies for the web. like who wants to wait for java applets or flash crap to load any more? http was nothing more than a simple test request/response protocol...this is why webservices or some other RPC over http sucks and is so slow...ITS NOT MADE TO DO THIS....you have to convert all binary to ascii (pain in the ass) and/or you have to parse XML into/from (from is easy) some DOM tree; then figure out and perform something...its like compiling and running the code direct except instead of using a computer language your using a file format language (XML).
Its just stupid. oh yeah...you're suppose to be happy about all this and want to use it in your application cause its IT standard...yeah...kick me in the head some more please.

anyway. i roll my own protocols and make sure the data transfer is fast as possible so my users feel no pain; but of course, i'm in a position to do that. i also

el
Lemon Obrien III Send private email
Monday, February 28, 2005
 
 
I think that the better route for your energy, Cdiggins, is to assume that it's too hard to push out a new type of client to fix the "broken" platform, but make a good application environment for stateless IFRAME/XMLHttpRequest/etc. web development.  Oh yeah, and do it without any Java, Flash, Acrobat, or other such plugins.

I also think that to create a post-HTTP protocol that would serve as a stateful, authenticated system is harder than you'd think.... because you need to also solve the problems that have prevented things like client-side HTTPS certificates and whatnot from working properly.

But... um...  I think that my first suggestion is more likely to be successful and would be functional faster.
Flamebait Sr.
Monday, February 28, 2005
 
 
First you have to figure out what cross-platform client technology you'd want to use.  You'd want rich presentation capabilities and enough local smarts to build fat client applications.

Then you need a server technology to talk to.  Conversational servers like Telnet and FTP servers tend to have severe scalability issues.  You actually DO want something transaction-oriented like a web server.  But what?

Then you need to glue the two together somehow.  Raw TCP connections won't hack it.  You need framing, a basic vocabulary of verbs and status, authentication, etc.  Then there is the payload to be serialized/parsed, a mechanism for encapsulation of binary data...

Before you know it you're back where we are now.  Maybe in different clothes, but functionally about what we have today.

So what are we talking about?  Some RAD environment that makes it all look like writing an MS Access application for a few users over a fast LAN?  Because that's what I think I'm hearing.
Dazed
Monday, February 28, 2005
 
 
"So what are we talking about?  Some RAD environment that makes it all look like writing an MS Access application for a few users over a fast LAN?  Because that's what I think I'm hearing."

I think that is what you're hearing in this thread. 

But go back and read Joel's "How Microsoft Lost the API War" article. 

His point there, if I recall correctly, is that regardless of what you think of them web applications (using HTML, of course) are taking over.  Not because they're better than what you could get with Rich Clients over the internet.  But because HTML is good enough (even if not great), the interfaces are good enough (even if not great), and the web apps have advantages in ease of deployment.
Herbert Sitz Send private email
Monday, February 28, 2005
 
 
Dazed said "Then there is the payload to be serialized/parsed, a mechanism for encapsulation of binary data...

Before you know it you're back where we are now. "

This is true except for a couple of things...I'm building peer-to-peer apps and i created all this; First, u can use udp a lot for neat things like chat...expecially if you have meesage routing built into the messaging system. I also have servlet like actions for request/response/events...and when the same message is encountered again, if the old thread is around, it is qued into the current thread...webservers have to get arond this
creating a static singleton of some sort; but at least one more thread is created...

second, and this is what most people don't understand...parsing the payload in binary is a factor of 10x more efficient...and compact. the only rule you need to obey is internet natural addressing....

the reason www is popular is basically everyone in silicon valley bought sun's java platform hook-line-an-shinker. thats it; that and the whole race in the 90s called the dot-com thing...everyone decided that was it, the basis of the internet's architecture; and then designed every hack-in-the-book to implement something best done on the desktop.

if your going to do truely collabortive software; you want native-face (as i call it)...fast reponse, and high quality....

Plus, the future of software is mass-distributive...i'm talking entertainment, games, person to person dating with live chat and quick cams; etc.

I think business' which rely on java may have a hard time if sun can't find a business model soon; if i was them i'd start making money off the platform; but they can't do that can they?
Lemon Obrien III Send private email
Monday, February 28, 2005
 
 
What matter's more to users?  That http is slow, bloated, and hard to write interactive programs for?  Or that they can use existing browsers to do most of what they want right now?

http://www.jwz.org/doc/worse-is-better.html
Scot Send private email
Monday, February 28, 2005
 
 
"First, u can use udp a lot for neat things like chat..."

Well your chat isn't going to work for me because it's not going to get through my NAT/Firewall.  It's also not going to work for 90% of the companies out there. 

"parsing the payload in binary is a factor of 10x more efficient...and compact."

Nobody is saying it isn't.  The problem XML solves has nothing to do with efficiency or compactness and has everything to do with interoperability.  What matters is not that it's slow or big but that everything and everyone will be able to grok it. 

The Internet is one big example of verbose text based formats triumphing over compact binary formats.  Hell I can even Telnet into my mail server, type a few commands, and download my mail.

"the reason www is popular is basically everyone in silicon valley bought sun's java platform hook-line-an-shinker."

What does Sun have to do with the www?  They didn't invent it and none of their technology has anything to do with most of it.  Ok, so they invented Java -- but it didn't quite do what they wanted (hey, anyone actually remember Java applets?)

"if your going to do truely collabortive software; you want native-face (as i call it)...fast reponse, and high quality..."

I develop nothing but web applications these days.  The only native applications I write are for cellphones, and you know what, my cellphone has a pretty responsive browser.

It's even very collabortive software.  We could do everything we need as a native app and it would probably work better BUT nobody would use it. 

"if i was them i'd start making money off the platform; but they can't do that can they?"

No they can't.  If Sun tried to profitize Java back in the day, it wouldn't have hit critical mass.  Now that it has critical mass they can't sell it; anybody can build a Java compiler (and do) and anyone can build a virtual machine (and do).  The only thing that they have control over is the name and Microsoft got around that no problem (C# anyone). 

There isn't any profit in programming languages anyways.  There's lots of money in tools (IDE's, profilers, installers, etc) but Sun, for whatever reason, didn't really do a good job there.  Everyone else beat them to the punch.
Almost Anonymous Send private email
Monday, February 28, 2005
 
 
>>>>
But go back and read Joel's "How Microsoft Lost the API War" article.

His point there, if I recall correctly, is that regardless of what you think of them web applications (using HTML, of course) are taking over.  Not because they're better than what you could get with Rich Clients over the internet.  But because HTML is good enough (even if not great), the interfaces are good enough (even if not great), and the web apps have advantages in ease of deployment.
<<<<

I don't really think that web applications are taking over. The only classic desktop application that I can think of that was replaced by a web application is the mail client. This was done 10 years ago with hotmail. Any other desktop application that got replaced? Word? Excel? Photoshop? We got a lot of new "applications" like search, e-commerce, electronic banking, auction etc. But a lot of them could actually be done nicer if they had a rich client that integrates with the operating system.
Joe
Tuesday, March 01, 2005
 
 
What I saw at the weekend at FOSDEM showed what was possible using XUL and Javascript, the words Excel, Powerpoint and Word were very prominent.
Simon Lucy Send private email
Tuesday, March 01, 2005
 
 
Almost Anonymous -- good points. maybe i'm totally wrong; but i think the web sucks and i think its java's fault. i don't know why, call it stupidity. i have no idea.
Lemon Obrien III Send private email
Tuesday, March 01, 2005
 
 
Here is a design for punching holes through Firewall/NAT withough the need for administrative access: http://midcom-p2p.sourceforge.net/

/And now back to the regulary schduled thread
Sidetracked
Tuesday, March 01, 2005
 
 
"I don't really think that web applications are taking over."

Clearly web applications are not replacing traditional desktop applications.  The spreadsheet is as old as personal computers themselves and certainly putting it on the web isn't going to improve it. 

A lot of in-house development is being done as web applications (and in-house development dwarfs the amount of shrink wrap applications).  My company is an application service provider -- we develop and run a calendaring/contacts/business management application that runs from the browser.  We do have competition in the form of a desktop application but everyone still prefers us.  There are many advantages to being an online application: no installation, no IT infastruction (servers) required, access-from-anywhere, and we give out clients web pages so their clients can interact with the application.

"But a lot of them could actually be done nicer if they had a rich client that integrates with the operating system."

Could you imagine the hell if every search engine required a downloadable client?  You'd loose the standard interface of the web; everybody knows how to use the back button and clients.  Do you think you'd be able to block popups?  Your add/remove programs list would be insanely huge.  Eventually what would search engines index if everything was a rich-client app?  E-commerce sites would have to have a web-based part to get search indexed and then an application part to puchase things?  Obviously it's better that the content and e-commerce part be smoothly integrated?  Is Amazon an e-commerce site or a provider of information/reviews on books? 

Web applications are not going to replace word or photoshop because they just can't improve on it.  But similarily, what real improvement would there be if google or amazon was a desktop client?
Almost Anonymous Send private email
Tuesday, March 01, 2005
 
 
"but i think the web sucks and i think its java's fault. i don't know why, call it stupidity. i have no idea."

Java has so little to do with the web in general, that I think you're a bit off base here.
Almost Anonymous Send private email
Tuesday, March 01, 2005
 
 
"It seems to me http just wasn't made for today's applications"

You're correct - it was made for HyperText, as the name suggests.
John Topley Send private email
Tuesday, March 01, 2005
 
 
Almost Anonymous  -- "Java has so little to do with the web in general, that I think you're a bit off base here."

Almost Anonymous  -- "I develop nothing but web applications these days.  The only native applications I write are for cellphones, and you know what, my cellphone has a pretty responsive browser."

I wonder what you use to develop all these "web applications" ?

el
Lemon Obrien III Send private email
Tuesday, March 01, 2005
 
 
"I wonder what you use to develop all these "web applications" ?"

Mostly LAMP.  Doing some maintance work right now in classic ASP.  Back in the day I even did some Perl.  I've never touched Java for web development.
Almost Anonymous Send private email
Tuesday, March 01, 2005
 
 
Almost Anonymous -- "I've never touched Java for web development."

oh silly me...i thought it was manditory for everyone working at a tech company doing web services/applications/etc. to use java.

i was forced to bare the lash of java for 4 years.
Lemon Obrien III Send private email
Tuesday, March 01, 2005
 
 
If you're doing boring corporate stuff than you pretty have to use Java irregardless of whether it has anything to do with the web.  Luckily, I generally get to do "fun" stuff (although my idea of fun isn't the same as everyone elses).
Almost Anonymous Send private email
Tuesday, March 01, 2005
 
 
Almost Anonymous,

I agree with you that not every web application benefits from a change to a rich client. I use ebay every couple of months therefore it might be more of a hassle for me to download a rich client than it is to put up with a clunky web user interface.

However if you talk about in house development (what you apparently do for a living) than rich clients are a real option. If your users have to use your application on a daily basis than a better user interface makes a big difference. A web application might be still much better than the legacy mainframe application you are replacing. A rich client however would be even better.

Your two examples google and amazon are by the way offering browser toolbars for downlad to enhance their browser based experience...
Joe
Tuesday, March 01, 2005
 
 
"However if you talk about in house development (what you apparently do for a living) than rich clients are a real option."

I don't do in-house development for a living -- I work for an application service provider.  We're alot like hotmail except providing more involved application than just email.

"A web application might be still much better than the legacy mainframe application you are replacing. A rich client however would be even better."

Most people claim that Gmail has one of the best interfaces for an email client -- web based or otherwise.  If you've seen Outlook Web Access, it looks and works like Outlook.  That is the level of user interface we are going for.  While each "screen" will be loaded fresh most operations on a screen are done without reloading.  We use DHTML for tabs and so on.  Our interface will be, when completed, similar to what we could have done with a rich client. 

We also sell a monthly subscription.  Most of our clients are nearly computer illiterate.  We also sell to companies who have little or no IT infastructure.  Given that, we have to make getting on the system as easy as possible and with as little overhead as possible.  Try doing that with a rich client.

Part of the future plans is to add a small desktop client component to augment the website and provided an interface away from the browser (for syncing and notifications).  But that's it!
Almost Anonymous Send private email
Tuesday, March 01, 2005
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz