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

[VK]

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.

[Michael Wojcik]

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]

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]

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]

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]

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]

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

[Peter Michaux]

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

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

[snip]

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

>
Just more hot smoke I am therefore going to ignore. If you named *your*
business constraints once, one could at least try to evaluate your design
decision.

You are ducking the issue. For the purpose of this discussion these
are my business constraints. This is a realistic, possible situation
in which a programmer may find himself.

I am not trying to suggest depending on JavaScript is good in many
situations. I am simply trying to determine if you agree that there
are some situations where a dependency on JavaScript may be either
necessary or acceptable.

[snip]

Peter

[Thomas 'PointedEars' Lahn]

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

Peter Michaux wrote:

Thomas 'PointedEars' Lahn wrote:

>>>>>>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
>>>constraint s.
>>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?

>Just more hot smoke I am therefore going to ignore. If you named *your*
>business constraints once, one could at least try to evaluate your design
>decision.

>
You are ducking the issue.

No. You are, hiding behind names when it is high time to put your money on
the table.

I am not trying to suggest depending on JavaScript is good in many
situations. I am simply trying to determine if you agree that there
are some situations where a dependency on JavaScript may be either
necessary or acceptable.

Knowing me to suggest frequently to use scripting to generate specific
elements that only work *with* client-side scripting, however to try to void
these, you could have known that already:

I know that there are certain special features in a Web application that are
not possible to implement without support for client-side scripting.
However, that does not mean client-side scripting needs to be a requirement
for the entire application nor that it is acceptable if it was defined as a
requirement for that. A good example are popup windows: It is OK if there
is no popup window on a hyperlink if client-side scripting is unavailable;
it is not OK if nothing happens then or the user is bothered with an error
message (that they are unlikely to understand).

Regarding your approach this means: It is OK if you use client-side
scripting and XHR to fill your document; it is not OK if your document
remains empty if one of them is not sufficiently supported. As there is
an alternative, conventional way to transport the information from the
server to the client.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Peter Michaux]

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

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

Peter Michaux wrote:

Thomas 'PointedEars' Lahn wrote:

>>>>>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 .
>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?
Just more hot smoke I am therefore going to ignore. If you named *your*
business constraints once, one could at least try to evaluate your design
decision.

>

You are ducking the issue.

>
No. You are, hiding behind names when it is high time to put your money on
the table.

I just gave you a realistic set of constraints. What more do you
want?

I am not trying to suggest depending on JavaScript is good in many
situations. I am simply trying to determine if you agree that there
are some situations where a dependency on JavaScript may be either
necessary or acceptable.

>
Knowing me to suggest frequently to use scripting to generate specific
elements that only work *with* client-side scripting, however to try to void
these, you could have known that already:
>
I know that there are certain special features in a Web application that are
not possible to implement without support for client-side scripting.
However, that does not mean client-side scripting needs to be a requirement
for the entire application nor that it is acceptable if it was defined as a
requirement for that. A good example are popup windows: It is OK if there
is no popup window on a hyperlink if client-side scripting is unavailable;
it is not OK if nothing happens then or the user is bothered with an error
message (that they are unlikely to understand).
>
Regarding your approach this means: It is OK if you use client-side
scripting and XHR to fill your document; it is not OK if your document
remains empty if one of them is not sufficiently supported. As there is
an alternative, conventional way to transport the information from the
server to the client.

So it seems you agree that there are at least some situations that
require JavaScript.

It also seems that you do not feature test all host or native objects
you use. That was made clear in late 2007.

We also know that you are serving XHTML as HTML.

Unfortunately you continue to berate others for similar types of
activities. Your criticism of others is contradictory to your own
actions. We are all engineering in grey areas of compromise yet you
portray this picture of right versus wrong. The standards you are
evangelizing are good and admirable, but even you cannot or do not
live up to them. You draw a line at one shade of grey while others
draw the line at a different shade. They do not need to be ridiculed
by you for that because both you and the others are in the grey. No
one is "right".

comp.lang.javas cript's reputation and usefulness suffers because
people are berated in an unfriendly way and that those doing the
berating are not saints themselves often holding others to standards
they do not uphold themselves. I hope you lighten up and realize that
sometimes people just don't know what they are doing but that
sometimes people are dealing with business constraints out of their
control. You are in the case of XHTML as HTML.

It would be better if newcomers to the group did not feel like the
sharks are attacking when they arrive.

Peter

[Laurent vilday]

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

Thomas 'PointedEars' Lahn a écrit :

Peter Michaux wrote:

>I am not trying to suggest depending on JavaScript is good in many
>situations. I am simply trying to determine if you agree that there
>are some situations where a dependency on JavaScript may be either
>necessary or acceptable.

>
Regarding your approach this means: It is OK if you use client-side
scripting and XHR to fill your document; it is not OK if your document
remains empty if one of them is not sufficiently supported. As there is
an alternative, conventional way to transport the information from the
server to the client.

Are you, both, talking about a static HTML document or a dynamic web
application ?

--
laurent

[Peter Michaux]

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

On Jun 2, 4:18 pm, Laurent vilday <mok...@mokhet. comwrote:

Thomas 'PointedEars' Lahn a écrit :
>

Peter Michaux wrote:

I am not trying to suggest depending on JavaScript is good in many
situations. I am simply trying to determine if you agree that there
are some situations where a dependency on JavaScript may be either
necessary or acceptable.

>

Regarding your approach this means: It is OK if you use client-side
scripting and XHR to fill your document; it is not OK if your document
remains empty if one of them is not sufficiently supported. As there is
an alternative, conventional way to transport the information from the
server to the client.

>
Are you, both, talking about a static HTML document or a dynamic web
application ?

At a minimum, I'm discussing HTML pages where JavaScript is being used
and whether or not it is acceptable to depend on JavaScript. If it is
acceptable then under which circumstances.

Peter

[The Magpie]

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

VK wrote:

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

Then may I suggest that you take it to a separate thread rather than
confuse this one. I shall be pleased to join you there and comment on
what I fear are your barking mad opinions about the W3C. Do you have
some sort of personal gripe?

[VK]

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

On Jun 3, 8:32 pm, The Magpie <use...@pigsins pace.co.ukwrote :

VK wrote:

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.

>
Then may I suggest that you take it to a separate thread rather than
confuse this one. I shall be pleased to join you there and comment on
what I fear are your barking mad opinions about the W3C. Do you have
some sort of personal gripe?

No, I don't any have personal gripe with W3C. If you think that
everything is just fine with both HTML standards and W3C then let's
talk about these illusions at comp.infosystem s.www.authoring.html
because it gets pretty OT for clj( Follow-up to
comp.infosystem s.www.authoring.html is set).

We just need to make a deal about some mouth control, so say opponents
will "saying" or "expressing an opinion" but not "barking" or making
other types of mis-articulated noise; and these will be "a different
opinion" or "an opinion I cannot agree with" but not "a mad idea" or
similar.

With such deal being set feel free to answer at ciwah.

[Thomas 'PointedEars' Lahn]

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

Dan Rumney wrote:

>Are there any hidden advantages or disadvantages I may be aware of?

>
After some consideration and experimentation , one thing did occur to
me.
>
If a webpage is created on the client with multiple requests back to
the server for content, then that webpage can't be saved for later
offline viewing.

Yes, a snaphot of it can be saved. However, the application needs to
provide means to generate a static document from the dynamically generated
one. A document tree serialization may be used to create it within another
container (e.g. a popup window); the proprietary XMLSerializer() ,
`outerHTML' and `innerHTML' features may be used for this.

Please don't remove the attribution line.


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>