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

Peter Michaux wrote:

Thomas 'PointedEars' Lahn 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

These are requirements.

You are allowed to assume support for HTML, images, cookies, CSS
and JavaScript because these are on by default in most browsers.

These are _not_ requirements, these are *allowances* (based on false
assumptions). You are *free* to implement something that meets these
without restricting yourself to them. Specifically, while you are
allowed to use JavaScript, you are not at all *required* to.

You must support IE6+, FF2+, O9+, S3+.

These are requirements again.

How would you do that so it degrades gracefully without JavaScript support?

As I already described.

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?

Not all of them, and in fact not the ones under discussion here, are
constraints.

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
[a]void
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
these, you could have known that already:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

*roll eyes*

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

I am not feature-testing all native objects I am using when the language
feature can be considered to be universally available. In order to make
that assessment and help others with makit it, I am maintaining the
ECMAScript Support Matrix. It is a well-founded informed design decision.

I should be feature-testing all host objects (including window.alert, as it
turned out) but I think probably I do not in all my code at the moment. As
you know my postings so well, could you please point me to the posting where
I said that not all host objects need to be feature-tested? Because I don't
remember saying it.

We also know that you are serving XHTML as HTML.

No, because of the server-side XML-based template engine the content
management system is based on that we are developing for, we are serving
XHTML 1.0 Transitional, "HTML-compatible" per The XHTML 1.0 Specification,
Appendix C, as text/html. If I am not developing for the CMS or templating
is not required to accomplish the task, I am writing and serving HTML 4.01
Transitional or Strict (as text/html) instead, and suggest this to my
colleagues instead.

Unfortunately you continue to berate others for similar types of
activities. [...]

I am not going to comment on this new ad-hominem attack-rant of yours. It
is a pity that you deem it necessary to resort to such things in order to
back up your argumentation.


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 (AT) news (DOT) demon.co.uk>

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

On Jun 2, 4:18 pm, Laurent vilday <mok... (AT) mokhet (DOT) com> wrote:

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

In comp.lang.javascript message <48445DB3.2050507 (AT) PointedEars (DOT) de>, Mon,
2 Jun 2008 22:53:07, Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de>
posted:

Peter Michaux wrote:

Unfortunately you continue to berate others for similar types of
activities. [...]

I am not going to comment on this new ad-hominem attack-rant of yours. It
is a pity that you deem it necessary to resort to such things in order to
back up your argumentation.

Don't misuse language. We do not use the fact that you are an obnoxious
hectoring bully as an argument against the technical validity of what
you say about JavaScript. Instead, we point out the unreasonable and
anti-social nature of your character, which is perfectly obvious of
itself to all bar you. If you were to get the appropriate psychiatric
treatment, and if it were to prove permanently successful, then you
might become a valued member of society. As it is, one can only wonder
whether there are still intact logs in Doorn.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

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.

For my particular needs, that's no good.

I did spend a little time toying with the idea of creating some
Javascript and server code that would result in the Javascript packing
up the newly generated page and all the generated Javascript
objects... essentially freezing the state of the page and then passing
it back to the server which would respond by returning a ZIP file
containing all the necessary elements needed to view the page offline.

I then realised that was barmy. Why go to all the effort of that in
order to implement a content creation model that I wasn't even sure
was worth implementing in the first place!

Thanks to all for their comments. There have been some insightful
ones. I hope others have found this thread edifying.

On Jun 3, 8:32 pm, The Magpie <use... (AT) pigsinspace (DOT) co.uk> wrote:

VK wrote:
On Jun 1, 5:31 pm, Dan Rumney <danrum... (AT) warpmail (DOT) net> wrote:
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.infosystems.www.authoring.html
because it gets pretty OT for clj( Follow-up to
comp.infosystems.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.

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$8300dec7 (AT) news (DOT) demon.co.uk>

Thomas 'PointedEars' Lahn wrote:

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.

I should have written "can't *readily* be saved", I suppose.

Certainly, saving the generated HTML wouldn't be too tricky. My concern
would be in persisting any arbitrary Javascript objects which had been
generated as part of the current representation of the dynamic page and
which would be necessary for ongoing offline functioning of the page.

For me, the complexity of putting this solution together is sufficient
that it ceases to be worth it. I'm better off generating the content
dynamically on the server.

Others may feel its worth persevering with. To them, I wish good luck.

On Jun 3, 9:28 am, Dr J R Stockton <j... (AT) merlyn (DOT) demon.co.uk> wrote:

In comp.lang.javascript message <48445DB3.2050... (AT) PointedEars (DOT) de>, Mon,
2 Jun 2008 22:53:07, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de
posted:

Peter Michaux wrote:
Unfortunately you continue to berate others for similar types of
activities. [...]

I am not going to comment on this new ad-hominem attack-rant of yours. It
is a pity that you deem it necessary to resort to such things in order to
back up your argumentation.

Don't misuse language. We do not use the fact that you are an obnoxious
hectoring bully as an argument against the technical validity of what
you say about JavaScript. Instead, we point out the unreasonable and
anti-social nature of your character, which is perfectly obvious of
itself to all bar you. If you were to get the appropriate psychiatric
treatment, and if it were to prove permanently successful, then you
might become a valued member of society. As it is, one can only wonder
whether there are still intact logs in Doorn.

--
(c) John Stockton, nr London, UK. ?... (AT) merlyn (DOT) demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

Cheers to that. It's a pity some people spend more time on petty
agendas (petty to the rest of us, anyway) and let their obvious
technical prowess get lost in the sound and fury.

Tyler

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.

Eh, don't listen to pointed ears. He likes to bicker about unrelated
shit.