- From: Didier PH Martin <martind@netfolder.com>
- Date: Tue, 08 Jun 2004 16:02:11 -0400
Hi Preston, > 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 not see the incentive to switch to xforms id everything is handled on the server side. Developers have what they want on the server side with JSP, ASP, PHP and tutti quanti. And yes Longhorn + IIS + XAML will be faster than PHP + Apache + WebForms. Also the apps will be a lot richer, this, at least with the current state of web technologies. Without a client implementation that can compete against Microsoft, I wouldn't bet on the new specs at Las vegas.... > > 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. It depends Preston on how the apps is written, and the end browser. I have to say that with the latest incarnation of Mozilla I have been impressed. Personally, as a real programmer, I tend to use an XML base language to encode the model, associate it with a XSLT template to transform it into an assembly if XHTML and EcmaScript on the client side. Off course I do not send the whole model but a fragment of it. I also used a fragment of the model to be sent back to the server to update the collective model. In some ways the apps is model driven. The good point is: for intranets (not internets since I do not control the end browser) I use the power sitting on each desktop. I see an interest to new specs only if at least a browser implements it. Otherwise it's only talk without walk. Cheers Didier PH Martin
Received on Tuesday, 8 June 2004 13:02:11 UTC