[CLUE-Tech] JavScript and Standards (was Is this true?)

[Jed S. Baer]

On Fri, 26 Apr 2002 22:48:44 -0600
Jeffery Cann <fabian at jefferycann.com> wrote:

> On Friday 26 April 2002 09:21 pm, Jed S. Baer wrote:
> 
> > Regrettably, it is the authors who abuse scripting who ruin it for
> > sites which use it responsibly.
> 
> I agree.  It's always those few bad apples...
<snip>
> > haven't encountered any use of javascript (when I've turned it on)
> > that I couldn't think of a way to handle with regular HTML. 
> 
> I disagree.  Suppose you want to have a more complex application.  Such
> a beast is generally not used by the general public on public web sites,
> but for intranet applications.  Do you want to do round-trips on the
> network to figure out that after you clicked a radio button that some
> other field is no longer necessary (and can be disabled with a
> Javascript control?

Hey, I did say form validation was OK. Yes, these sorts of things are
great savers of time/bandwidth. I wish the W3C and whoever else does these
things would come up with a way to embed such things into the HTML form
methodology.

And, there's a big difference, IMHO, between a public website and an
intranet. Within the organization, you have (hopefully) more bandwidth;
you have control over the desktop. Yes, a geographically diverse
organization (especially a small one) can exist without the advantages of
a fat-pipe VPN, etc. You have to work towards what's appropriate for your
environment. You mention browser compatibility, and that's a very large
problem for public websites. 
> Having written HTML forms that use Javascript for validation and ones
> that do not, I definitely prefer server-side validation.  It's simpler,
> easier, and less problematic.  Especially if you're worried about
> browser compatability.

I'd always validate the data on the server side, regardless of how much
DHTML validation there were. Particularly in a public site, you never know
when someone is going to try and mung things up to hack you, or just
disrupt things. I run across lots of sites though, which use JavaScript
not just to validate the form, but to submit it as well. This is just
plain stoooopid. I've written a couple forms which use javascript to
validate/submit, but the plain CGI submit is there too.

> OTH - HTML is not an application language.  It's a markup language that
> has a lot of other limitations.  For example, folks want the power of a
> GUI (i.e., focus controls, mouse-overs, etc.) with the ease of
> deployment that comes with using a web browser.  HTML cannot do it --
> Netscape knew this way back in 1996 and hence they created javascript.

That goes to the root of the problem. The WWW was never intended, as
originally specified, to be an application platform. Couple that with
browser wars and you get a mess.

> The biggest problem with javascript is that (ironically) Netscape did
> not immediately submit it to W3C for validation (8 years ago!).   Had
> they not acted like a monopolist (90% of browsers were NS then) and had
> javacript become a standard 6 years ago (instead of 2 years ago), we web
> developers would not have suffered through the pain of trying to use it.

No I don't think so. The biggest problems are the ones I've mentioned. The
bad uses far outweigh the good. A fully standards-compliant, consistent
DOM/JavaScript model wouldn't prevent popunder ads.

> I guess the alternative is to write rich Java GUIs that are 'network
> aware', but run outside of the browser.  But why loose all of the
> features that come with a browser just to get some decent client-side
> application controls?
> 
> Another alternative is Java applets, but those were introduced 2 years
> before folks were ready to use them.  In 1997, I actually used an Oracle
> Forms utility that generated 3 MB applets from a single Oracle Form. 
> Oracle thought this was an acceptable way to 'web-enable' the Oracle
> Forms environment.  Sheesh.

Heh. I played with those, briefly. Their new implementation is much
cleaner, as I understand it. They were starting to look at it at Pinnacol
just before I left. I didn't get to play with it though. But, on the
corporate backbone, downloading the applet once and then reusing it
multiple times isn't terrible. No worse than using SSM to push updates
down to the client machines. Bandwidth is bandwidth. The new
implemenation, BTW, is a Java meta form-engine. I'd actually like to see
how it compares, from a network point of view, with running applications
in a citrix metaframe.

> > So, there's my little rant for the evening. Hope you enjoyed it as
> > much as I did! ;-)
> 
> I did.  Javascript is such a hot-button topic.  Almost as good as
> discussing the Convicted Monopolist (tm).

Who have, actually, a more feature-rich DOM than Netscape. I don't recall
that dvx article you pointed to mentioning Mozilla's DOM. I wonder how
long it will be before all the writers, etc., who are stuck on the
"Netscape 4" comparison shtick get around to catching up. Somewhere else,
somebody mentioned the AOL rollout - I suppose that's what it will take.
(Yes, I know some writers are Mozilla aware, but I still see way too many
NS4 references.)

I'm with Nielsen on this (IIRC). If you're site is non-functional without
scripting or flash, you've made a big mistake. (Well, OK, there are some
sites whose sole purpose is presenting that sort of content - but that's
an exception to the sort of public information type site which started
this whole thing.) You'd think a disablilty site would be keenly aware of
erecting "barriers to entry", even if they're virtual.

Later,
jed
-- 
Fight the CBDTPA: http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html

"Those who expect to reap the blessings of freedom must, like men,
 undergo the fatigue of supporting it." - Thomas Paine