[whatwg] about rich internat applications

[Brad Neuberg]

If things are done on the server-side, then the question becomes what does 
this look like to the server-side programmer?  If the server-side 
programmer just does things by the Web App standards, then we would need a 
custom preprocessor that would intercept this and change it into what IE 
would need.  I am a JSP programmer so I know this is possible in JSP (you 
can intercept the HTTP response in a standard way and change things), but 
I'm not sure if it is possible in other popular environments in a standard 
way (PHP, Perl, ASP/ASP.Net, etc.).  Also, remember that there would be an 
adoption curve on the server side as well; would web hosting providers 
install these convertors?  If things are done on the client side then the 
server-side doesn't need to change.

I think there are three metrics that are very important for this working 
group to consider.  First, what will be the reliability of using these web 
app standards?  Will it be a pain because things work slightly different 
across the different browsers, so much so that it is just easier for me to 
just use Flash or another standard?  Second, is it easy to use? Were so 
many compromises made in creating it that it is extremely difficult to 
use?  Finally, what is the performance?  Is it fast enough for users to 
actually enjoy?

To summarize, these three metrics are Reliability, Ease of Programmer Use, 
and Performance.  The reason I brought these up in a discussion of whether 
to put the emulation layer on the client or server sides is because if we 
can't achieve these three important metrics on the client side then we may 
have to do it on the server-side.

Brad Neuberg

At 12:35 PM 6/8/2004, Preston St. Pierre wrote:
>Hey guys, just a few comments:
>
> > 1) do everything in the client
> > pros: simple installation of web forms (plug & play)
> > cons: performance in the client is degraded (is this a bad thing? we are
> > talking about explorer)
>
>If we do everything client side, we need the support of people. People, 
>essentially, are idiots. They do what Microsoft tells them (for the most 
>part, of course). If Microsoft has goals that lie in other directions, it 
>would be easy for them to break compatibility. This standards group is 
>partially here to block the proprietary MS stuff from becoming a standard. 
>When 90% of the population is governed by one body, and that body is 
>against what we are doing, suddenly we fail. Yes, everyone has proposed 
>work-arounds. But do we really want to be designing standards based on 
>work-arounds? If so, it will eventually be "Well we'd like to do it this 
>way, but it would be 10x easier to implement on IE if we did it this other 
>way, so we'll do that." The first way may have been much better, but 
>client side and IE crushes it.
>
> > 2) introduce server-side solutions (xsl, jsp etc)
> > pros & cons: the reverse of the above
> > another con, do we want to say:
> > "to implement web forms 2 you will need php version 4.x...?"
>
>In response to your second con... what do you honestly think is better: A 
>company that can install a (free, btw) server mod (php) and have their 
>site work on all clients, or a company that makes all their clients 
>install a plugin of their own? The obvious answer is that it is better to 
>be on the server side. There are other things to consider, too. It is much 
>easier for a company to have freedom of open/closed source when the 
>technology is server side. Everything suddenly becomes more secure. Yes, 
>there is more overhead on the server, granted. Do you think that Linux + 
>PHP + Apache + WebForms is going to be slower than Longhorn + IIS + XAML? 
>I doubt it. I doubt it highly.
>
>I do a lot of web applications programming, and server side technologies 
>have done nothing but make it easier. I joined this mailing list to be 
>sure that a "regular" programmer is around. Too many times standards 
>groups get lost in speculation and end up with something that isn't 
>usable. As far as I'm concerned, client side technology is too insecure. 
>When the user's browser chooses how to interpret my code, it may come up 
>with a different result than I had intended. Server side, I know the worst 
>it can do is morph how my page looks.
>
>Just some thoughts.