Re: Javascript on the client as an alternative to Perl/PHP/Python on the server

Peter Michaux wrote:
On Jun 1, 11:31 am, Thomas 'PointedEars' Lahn <PointedE...@xxxxxx> wrote:
Peter Michaux wrote:
On Jun 1, 3:56 am, Thomas 'PointedEars' Lahn <PointedE...@xxxxxx>
wrote:
Peter Michaux wrote:
Over the past while one of my work projects has amounted to an
HTML page that essentially looks like this: <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd";> <html> <head>
<title>one-page client-side app</title> <script src="library.js"
When one decides to publish information on the web only, one is
requiring a reader to have a computer,
For suitable values of "computer". Computers come in different forms
nowadays.

an internet connection
As much as it may surprise you, it is _not_ a necessity. Content can
be stored while the Internet connection is established and accessed
later offline.

So at some point an internet connection is required.

A network connection would be required at some point in most cases.

and web browser (or similar program to get content off the web).
I can accept that as an axiom of no greater value: You need a Web user
agent to access Web content.

That is setting the bar quite high
High for whom?

High for those without a computer, internet connection, and/or web
browser.

However, irrelevant to this discussion.

and expensive.
Not necessarily.

It certainly is expensive to own a computer, internet connection and web
browser. For some people going to a 10 peso/hour internet cafe in Mexico
is expensive.

It is not necessarily expensive for someone. Naming examples, public
libraries are providing inexpensive Internet access, too.

But talking about access costs for access now, you would deny the very
people that you talk above about the right to access to information if you
required them to have certain non-basic technologies available. Insofar
your "business constraints" argumentation is not only hypocritical but
proves to be contradictory in itself as you are excluding many potential
customers when following it. Have you ever thought about that?

If a publisher is willing to discard all potentially interested
readers that do not have an internet connection etc, then the publish
could subjectively decide that JavaScript is a requirement.
Which does not mean in any way that this decision is a reasonable one.

or an unreasonable one.

But your argument suggests it must be reasonable because of that, and I have
pointed out that this is dead wrong.

It has become quite clear over my time reading comp.lang.javascript
that you believe you know the right way to do things
At least I can *justify* my design decisions.

As can I.

But you do not. Instead you are arguing with nebulous business constraints.

I think that is a naive approach to assessing other's subjective
decisions without knowing all there decision making constraints.
I do not need to know the constraints to show that a decision is not
well-founded.

Then, in my opinion, your decision making process is broken. You cannot
engineer something unless you know the requirements. To believe that
there is one solution for all situations is naive.

See below.

We have also seen over time that you are doing some things
objectively wrong like serving XHTML as HTML.
Your fallacies are getting tiresome.

http://groups.google.com/group/comp.lang.javascript/msg/48e28a4ea7ec2903

Thanks, I know what I (have to) do. Yours is still a fallacy.

I'm interested in people's comments on this approach.
It works.
It does not.
It absolutely does work for many users.
But not for as many if that path would not have been followed.

True. That may not be a net loss, however, when counting profit.

If one has blinded themselves enough.

The document is empty.
That is not an argument about anything.
The value of the information in an empty document is zero and can
fulfill no purpose but to show that there is no information. I would
deem this to be a Bad Thing when the intent is to transport
information.

The intent may not be to transport information in a document-like format
even though that was the original intent of the web. The web is now being
used as an application platform as well.

Any software application transports information from the back end to the
user and vice-versa.

For a user with disabilities,
There are other strategies for supporting disabled users other than
just a single page gracefully degrading. I'm sure you can think of at
least five other strategies off the top of your head.
Yes, I can. However, I can also see the drawbacks that follow from
them and do weigh them against the greater advantages that follow from
not implementing them.

Do you agree that given certain business constraints perhaps you would
weight the advantages and disadvantages differently?

Perhaps. However, it is seldom necessary to bow down to short-term business
arguments if you know enough to stand your ground and point out the
immediate, mid-term and long-term (financial) advantages of not entirely
following the logic those arguments are based on.

a user behind a filtering proxy,
A business decision may be willing to sacrifice these users.
Which does not make this business decision a reasonable or economically
correct one.

It does not make it an incorrect one either.

It makes it an incorrect one if it is made to achieve short-term profit in
the face of mid-term or long-term losses.

In fact, it makes it a rather dubious one

maybe or maybe not.

if you consider that it is seldom the case that an Web application is
solely accessed from within a local area network.

A web application may be on the general internet with a notice it
requires CSS, image, JavaScript, Flash, Quicktime support etc.

Apples and oranges again.

These would all be reasonable requirements in some circumstances.

No, since HTML degrades gracefully by default, and server-side scripting is
readily available.

a user with a not so sophisticated mobile device
Not all pages need to work on a mobile device.
I included "not so sophisticated" for a reason.

They don't need to work on not so sophisticated mobile devices.

Maybe now, since mobile Internet devices are only emerging.

As I've established above, a web page will require some describable
set of technologies to access it. It could be that for a particular
page the reader must have a modern desktop computer with a web
browser that has been released in the past year with all the bells
and whistles turned on.
True. However, since that particular "page" would introduce a barrier
that all the other content does not, one has to reconsider whether it
is reasonable that this is the case or if it would instead be better if
this barrier would not be introduced.

You certainly are correct for some situations. For others the "wow
factor" that JavaScript provides may be the only reason a user decides to
use a particular website when others exist without JavaScript or with
JavaScript as progressive enhancements. In this situation using
JavaScript heavily may be exactly the reason a site is profitable.

Short-term profit does not balance increased long-term maintenance costs,
for example.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@xxxxxxxxxxxxxxxx>
.

Relevant Pages