Javascript on the client as an alternative to Perl/PHP/Python on theserver

VK · Jun 1 '08, 05:25 PM

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

On Jun 1, 5:31 pm, Dan Rumney <danrum...@warp mail.netwrote:

VK, PointedEars,
>
Please don't hijack this thread to bicker about accessibility.

IMHO it is not hijacking but branching on a sub-topic within the same
main topic. But I have no problem with shifting to a new topic like
"Javascript and accessibility" if more on the sub-topic will be
posted.

It's abundantly clear that anyone using a UA that does not have
Javascript is not going to be able to access pages generated using the
model that I outlined in the original post.

They will if you properly design NOSCRIPT redirect and/or warning
blocks.

I think a more fruitful discussion would focus on other, less obvious
aspects, which is why I'm seeking the thoughts of others.

1) Search recents about Ruby in this group for one (the problem with
script inserting script inserting ...)

2) Another one is specific for charsets above US-ASCII in Javascript
strings, especially in document.write. Maybe it is not your case.

3) Browser screen update mechanics may make _very_ big delay before
any content will get visible unless you are using properly context
releases over setTimeout. By now and IMO it is the most common mistake
made in Javascript / XHR intensive solutions.

**Thomas 'PointedEars' Lahn** · Jun 1 '08, 06:35 PM

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

Peter Michaux wrote:

On Jun 1, 3:56 am, Thomas 'PointedEars' Lahn <PointedE...@we b.dewrote:

>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>o ne-page
>> client-side app</title<script src="library.js "
>>type="text/javascript"></script<script src="app.js"
>>type="text/javascript"></script</head<body</body</htmlThe
>>app.js file loads all the necessary data using Ajax and JSON. The
>>body is dynamically built based on this data.

>Very accessible. NOT.

>
I didn't claim it to be.

You claimed it to be working. Generally.

This architecture was not completely my choice. It was the result of
business requirements.

That does not make the result a good one.

This page is behind a login which changes the balance of pros and cons in
the decision making.

That statement is not true in itself. Even an application that requires a
login could be exposed to a not so common environment.

>>>It would be a lot simpler to ensure validity of the HTML (as the
>>>final product would always be available to me).
>>I don't understand this either. It should be easy to validate the
>>HTML either way.

>As the W3C Validator documentation explains already, Validation alone
>is not a mark of service quality. An empty document, a document that
>has no content without scripting, is FUBAR.

>
I know that acronym and that is simply your opinion about a subjective
topic.

Diminishing an opinion by stating that the topic it discusses is subjective
is fallacious because all opinions are subjective. What matters is if an
opinion is well-founded or not. I think mine is, as I think I have
presented conclusive non-fallacious arguments to support it in the process.

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.

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?

and expensive.

Not necessarily.

For a interested person without a computer the content completely
inaccessible to them.
>
This establishes that the interested reader requires some set of certain
technology to access the information. In general web content is
published as HTML. Raw HTML is completely unintelligible to the majority
of readers without training in HTML.

While that is true, it is entirely irrelevant to this discussion.

That means that for practical purposes, most readers require a computer,
internet connection and a web browser

See above.

like Firefox or Internet Explorer.

Naming examples to support an argument in an attempt to make believe that
there are no other examples that could contradict the argument is another
fallacy.

The point still being that a very specific set of technology is required
to access the information.

But that is entirely irrelevant to this discussion.

Adding CSS, JavaScript and cookie support to this list of requirements
follows the same path of logic.

A fallacious logic at that. The mere use of CSS, JavaScript or cookies does
not imply a necessity for support of these features. A document can be and
should be useful without CSS, client-side scripting and cookies.

If JavaScript is or is not required to access content, there is still
some describable set of requirements to access the content.

You are making conclusions based on false or irrelevant premises.

To say that requiring JavaScript for a page is a mistake is a subjective
remark.

Every remark is subjective.

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. We
are not discussing which decisions can be made but whether these decisions
are justified.

The later decision about JavaScript requirement will exclude less readers
then the former decision about requiring an internet connection.

Given that the latter requires the former in some way, that is a fallacy.

I cannot see how a logical person could say that I am objectively
incorrect.

That is because you do not see that your argumentation is filled with fallacies.

It has become quite clear over my time reading comp.lang.javas cript that
you believe you know the right way to do things

At least I can *justify* my design decisions.

and that anyone else doing it different is not just wrong but also an
idiot.

It may be *your* impression, but that does not constitute evidence that it
is objectively true. BTW, such ad-hominem attacks, another fallacy, are not
going to increase the credibility of an already fallacious argumentation.

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.

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

Your fallacies are getting tiresome.

[snip]
>

>>>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.

>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.

>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.

>a search engine,

>
not all pages are to be indexed or even accessible to a search engine.

The truth of this statement depends on how one defines a search engine.

>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. In fact, it makes it a rather dubious one if you consider that
it is seldom the case that an Web application is solely accessed from within
a local area network.

>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.

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.

>and so on. You are blinding yourself to the possibilities of access to
>a Web application if you call this nonsense working.

>
I think you are jumping to conclusions about my post and you have done
this with other posts of mine in the past. There is really no need to do
that. You could ask questions instead.

I don't need to ask questions about particularities in order to make general
statements or show arguments to be fallacious.

I also think you are missing the fact that I have pointed out here that
the necessary technology to read a web page is a far more prohibitive
restriction in terms of number of people that can read a page than
JavaScript off is. Even writing a page in only one human language
eliminates billions of potential readers.

Apples, oranges.

PointedEars
--
var bugRiddenCrashP ronePieceOfJunk = (
navigator.userA gent.indexOf('M SIE 5') != -1
&& navigator.userA gent.indexOf('M ac') != -1
) // Plone, register_functi on.js:16

**Michael Wojcik** · Jun 1 '08, 07:15 PM

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

Dan Rumney wrote:

>
By simple HTML editors, I mean things like Notepad, Crimson Editor,
HTML-Kit and the like. I'm not a big fan of Dreamweaver and other
'visual' editors, but I'd be the first to admit that I probably need
to get over that bias.

Your bias is well-founded. Dreamweaver and the like are nasty black
boxes that produce lousy, often non-compliant HTML that's difficult to
maintain. Use an editor (with syntax highlighting and that sort of
thing, if you find it helpful) and write well-structured, concise,
elegant HTML, then validate it.

The principles of good programming apply to HTML, even though it's
just a declarative markup language. Separate concerns: structure your
HTML into functional areas, and separate out presentation (CSS) and
behavior (Javascript) from content (HTML). Emphasize readability: use
whitespace and comments. Identifiers, like style class names and
element IDs, should be meaningful.

These are not things that most "visual" editors will accommodate well.
At best, you'll be switching between "code" and "visual" views; so why
not simply operate in the former, since you're comfortable with it
already?

Visual editors also encourage WYSIWYG thinking, which leads to
inflexible layouts and poor rendering for users whose environments
don't match the author's. Working directly with the abstractions of
HTML and CSS encourages liquid layouts, because you're not looking at
one renderer's opinion of your page.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

**Dan Rumney** · Jun 1 '08, 07:35 PM

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

[snip]

>

It's abundantly clear that anyone using a UA that does not have
Javascript is not going to be able to access pages generated using the
model that I outlined in the original post.

>
They will if you properly design NOSCRIPT redirect and/or warning
blocks.
>

Good point. I was taking a limited view as to what 'access' was.
Certainly, they won't be able to gain anything fruitful from the
specific page that they've pointed their UA at. However, if I use a
NOSCRIPT element, I can ensure that they are informed as to the state
of the page and, ideally, directed to a page that provides comparable
functionality without the need for Javascript.

I think a more fruitful discussion would focus on other, less obvious
aspects, which is why I'm seeking the thoughts of others.

>
1) Search recents about Ruby in this group for one (the problem with
script inserting script inserting ...)

Thanks for the suggestion. I'll take a look

2) Another one is specific for charsets above US-ASCII in Javascript
strings, especially in document.write. Maybe it is not your case.

Not for me, but perhaps useful to other readers.

3) Browser screen update mechanics may make _very_ big delay before
any content will get visible unless you are using properly context
releases over setTimeout. By now and IMO it is the most common mistake
made in Javascript / XHR intensive solutions.

TBH, I've never seen this. I'm not refuting the possibility; do you
know of any sites which demonstrate this behaviour?

**Peter Michaux** · Jun 1 '08, 07:55 PM

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

On Jun 1, 11:31 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

Peter Michaux wrote:

On Jun 1, 3:56 am, Thomas 'PointedEars' Lahn <PointedE...@we b.dewrote:

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>o ne-page
> client-side app</title<script src="library.js "
>type="text/javascript"></script<script src="app.js"
>type="text/javascript"></script</head<body</body</htmlThe
>app.js file loads all the necessary data using Ajax and JSON. The
>body is dynamically built based on this data.
Very accessible. NOT.

>

I didn't claim it to be.

>
You claimed it to be working. Generally.
>

This architecture was not completely my choice. It was the result of
business requirements.

>
That does not make the result a good one.

It may be the very best result under certain business requirements.

[snip]

Diminishing an opinion by stating that the topic it discusses is subjective
is fallacious because all opinions are subjective. What matters is if an
opinion is well-founded or not. I think mine is, as I think I have
presented conclusive non-fallacious arguments to support it in the process.

yours may be well founded under certain business requirements. You may
not be considering other situations which result in other decisions.

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.

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.

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.

[snip]

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.

[snip]

It has become quite clear over my time reading comp.lang.javas cript that
you believe you know the right way to do things

>
At least I can *justify* my design decisions.

As can I.

[snip]

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.

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

>>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.

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.

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?

[snip]

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.

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. These
would all be reasonable requirements in some circumstances.

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.

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.

[snip]

Peter

**Thomas 'PointedEars' Lahn** · Jun 1 '08, 08:25 PM

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

Dan Rumney wrote:

[snip]

>>It's abundantly clear that anyone using a UA that does not have
>>Javascript is not going to be able to access pages generated using the
>>model that I outlined in the original post.

>They will if you properly design NOSCRIPT redirect and/or warning
>blocks.

>
Good point. I was taking a limited view as to what 'access' was.
Certainly, they won't be able to gain anything fruitful from the
specific page that they've pointed their UA at. However, if I use a
NOSCRIPT element, I can ensure that they are informed as to the state
of the page and, ideally, directed to a page that provides comparable
functionality without the need for Javascript.

As a `noscript' element can only provide indirect redirection or not at all,
less experienced users will be annoyed at you forcing them to perform
another navigation step, while more experienced users will rightly call you
a script kiddie if you do this. Which is why I mentioned, but recommended
against, the better alternative of redirecting from a document that does not
require scripting to one that does instead of doing it vice-versa.

I strongly recommend not to listen to VK's recommendations for they have
been misleading in the past and there is no indication that this could ever
change.

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

**Thomas 'PointedEars' Lahn** · Jun 1 '08, 09:05 PM

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

Peter Michaux wrote:

On Jun 1, 11:31 am, Thomas 'PointedEars' Lahn <PointedE...@we b.dewrote:

>Peter Michaux wrote:

>>On Jun 1, 3:56 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
>>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>on e-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.javas cript
>>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....e28a4ea7ec2903

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$8 300dec7@news.de mon.co.uk>

**Peter Michaux** · Jun 1 '08, 11:45 PM

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

On Jun 1, 2:03 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

Peter Michaux wrote:

On Jun 1, 11:31 am, Thomas 'PointedEars' Lahn <PointedE...@we b.dewrote:

Peter Michaux wrote:
>On Jun 1, 3:56 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
>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.

I bring it up because of its complete relevance. The point is that a
lot of technology is required to view a static HTML page and, although
we routinely make a big fuss about it on c.l.js, it is only a tiny
step more to add JavaScript as a dependency. JavaScript as a
dependency is almost no barrier at all compared to the other
requirements.

[snip]

>It has become quite clear over my time reading comp.lang.javas cript
>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.

If you cannot clearly see that business constraints play a role then
suppose you were charged with the task of writing interactive video
games for the web. The business partners want these to be usable by
people with a relatively low barrier. That is, no Flash or Sliverlight
or other browser plugins. You are allowed to assume support for HTML,
images, cookies, CSS and JavaScript because these are on by default in
most browsers. You must support IE6+, FF2+, O9+, S3+. How would you do
that so it degrades gracefully without JavaScript support?

[snip]

>>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.

The way I read that is if your "if" clause does not hold then you are
admitting that sometimes it is ok or unavoidable to depend on
JavaScript.

[snip]

Peter

Javascript on the client as an alternative to Perl/PHP/Python on theserver

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment