[NTLUG:Discuss] Javascript and CSS == Usable WWW browser? was Re: [NTLUG:Discuss] BrowseX (FAST, small browser) is outinBETA!!

[Christopher Browne]

On Wed, 04 Oct 2000 16:58:20 CDT, the world broke into rejoicing as
Jeremy Blosser <jblosser at firinn.org>  said:
> Steve Baker [sjbaker1 at airmail.net] wrote:
> > Jeremy Blosser wrote:
> > > > Chris Browne wrote:
> > > > Using ECMAscript controls to link to stuff instead of <a href=3D
> > > > "whatever.html"> seems a false indicator of "eliteness."
> > >=20
> > > Yes, unless you have an audience that isn't going to be web savvy and y=
> ou
> > > want to give them options for a 'back' button on the page.  The best you
> > > can do in HTML is link back to a predefined page that may or may not be=
>  how
> > > they got where they are.  With a scripted link you can access the brows=
> er's
> > > history and work the same way the back button does.  There are other ca=
> ses
> > > where dynamically-generated links inline can save space/download
> > > time/hassle for the user.
> >=20
> > This is just typical of the 'fluff' that modern web pages accumulate.
> >=20
> > Why the heck do we need one or more 'back' buttons that use all this
> > Javascript gizmology simply to duplicate a prominently displayed and
> > clearly labelled button that every browser already has?  Then accompany
> > it with a few hundred bytes of graphics for the button itself and you
> > have a waste of bandwidth as well as needless screen clutter.
> >=20
> > Stoopid!
> 
> I was giving an example of a special case.  They happen.  Thinking one
> size fits all doesn't really work on the web.  And I didn't say anything
> about using a bloated image.  As I mentioned, using JS appropriately can
> actually make pages load and render faster, since actions that affect
> information the browser already has loaded don't require another trip
> to the server.

The problem is that your 'special case' was, as occurs distressingly
often, a pretty crummy example.  More anon...

> > Whilst JavaScript *can* be used for good - it's far more
> > common for it to be used to support unnecessary bloat.
> 
> Yep.

... And the developers are _PROUD_ of this bloat.  When we should
be rubbing their noses in the fact that this is _SHAMEFUL_.

> > The worst thing about all this generated-on-the-fly material
> > is the inability of search engines to index it and other pages
> > to link to it.  That is a VERY great evil for the future of
> > the Internet since it allows people to control our ability to
> > quote them by pointing at what they said.
> 
> It's an evil for the future of the people that do it that way, too, because
> it removes the ability for people to make normal use of their website.
> People that don't leave a way to link into their data are turning away
> users and shooting themselves in the foot.

... And parallelling the "crummy example" thing, if you ever criticize
someone's site for doing the things like what is described above (e.g. -
generating everything on the fly, thus making it all inaccessible to
search engines), they'll fire back with substantially the same arguments
you present, namely that:
 - Anyone that is so "backwards" as to think that JavaScript isn't
   greatly superior to "just plain HTML" must be a technical Luddite;
 - Using this K001 and elite stuff makes things work much better
   all the while skirting the issue that they can't really point to
   examples of things _actually_ being better when compared to
   attempts to use HTML and styling _intelligently_.

It's all well and good to suggest that somehow pushing validation
code out to the client "could be much more efficient."  I could
almost believe that, almost.  

When reality rears its ugly head, validation tends to be based on _data_,
not merely on a few simple static computations.  And if there needs
to be a significant body of data pushed out to the client, the network
traffic that is being avoided fades to being... not all that much less
than you'd have if the data all got kept on the server.

It's sort of like the typical academic explanations of object oriented
programming.  There are _SO MANY_ texts out there where they try to
justify OO based on flimsy excuses.  And contrived examples where
the "objects" are either:
  a) Colours, or
  b) Fruit.
You CANNOT convince me that OO is a "good thing" if the best example
you can come up with is that of building some methods that don't do
anything more useful than classifying vegetables.

Don't take this personally; my vitrol here is for the shameful quality
of a lot of the OO literature.

But I don't think you provide useful defense for the use of JavaScript
when you suggest examples that don't represent "defense."  

I suggest you try for another example, and if people pick at weaknesses
in examples, that's not necessarily a personal attack.  If they can
pick out substantial weaknesses, that may indicate that the example just
doesn't work.  A defensible position needs to be able to withstand attack.

Such a process can lead to learning what it is that a technology like
JavaScript truly _IS_ useful for, and THAT would be a valuable thing.
--
cbbrowne at ntlug.org - <http://www.ntlug.org/~cbbrowne/>
Let me control a planet's oxygen supply and I don't care who makes the
laws.