[whatwg] about rich internat applications
Didier PH Martin
martind at netfolder.com
Tue Jun 8 13:02:11 PDT 2004
> 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
I see an interest to new specs only if at least a browser implements it.
Otherwise it's only talk without walk.
Didier PH Martin
More information about the whatwg