Re: Re: The Case for Javascript

To comment on your (valid and important) points:
1. Client-side validation should be done in addition to server-side validation, not instead of it. The server should never trust any data from the client. The purpose of client-side validation is report on errors closer to the cause of it. To avoid a round trip to the server with data that is going to fail. And to make the reporting of errors simpler.
2. The lowest common denominator principle of browser support makes for tedious browsing on all but that lowest browser. A better approach is to support the best level of browsing on all the browsers you support. It is easy enough to detect the browser's capabilities and use them.

-pete
"Worry is like a rocking chair. It gives you something to do, but it doesn't get you anywhere."

Comment on Re: Re: The Case for Javascript

Replies are listed 'Best First'.
Re^3: The Case for Javascript by diotalevi (Canon) on Nov 18, 2002 at 16:29 UTC
Agreed on both points. The problem comes in when JS becomes a requirement for the application. I think the problem arises when people read BUU and your original posts and misunderstand that JS is like a condiment - you add it for flavor but the dish stands on it's own without it. `__SIG__ use B; printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B::svref_2object(sub{})->OUTSIDE;` [download]	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: The Case for Javascript
by diotalevi (Canon) on Nov 18, 2002 at 16:29 UTC

Agreed on both points. The problem comes in when JS becomes a requirement for the application. I think the problem arises when people read BUU and your original posts and misunderstand that JS is like a condiment - you add it for flavor but the dish stands on it's own without it.

__SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;
[download]

[reply]
[d/l]