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

[Thomas 'PointedEars' Lahn]

[snip]

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

 

[Thomas 'PointedEars' Lahn]

So at some point an internet connection is required.

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

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

However, irrelevant to this discussion.

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?

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.

As can I.

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

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.

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

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

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

If one has blinded themselves enough.

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.

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.

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.

maybe or maybe not.


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.

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

Maybe now, since mobile Internet devices are only emerging.

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

 

[Peter Michaux]

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



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]

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]

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

 

[Logos]

VK and Lahn do seem to enjoy generating a lot of sound & fury around a
topic, eh? <grin>

The critical point is that the page is "pre-built" on the server.

I've been thinking about an alternative approach, whereby the page is
built on the fly with various AJAX calls to the server to pull in the
necessary components. In the extreme, I could visualize doing away
with Perl generated pages entirely. All pages are HTML, with AJAX
calls to the server. The responding scripts would return JSON or XML
data which would be interpreted on the client side as required.

An advantage to this would be that it would be a lot easier to
generate the pages using simple HTML editors. It would be a lot
simpler to ensure validity of the HTML (as the final product would
always be available to me).

I'm interested in people's comments on this approach. Does it provide
extra burden on the server? Are there any hidden advantages or
disadvantages I may be aware of? Does anyone know of any white papers
on this approach?

My 2 cents:

For me, the big consideration in deciding whether to load data all at
once or in subsets on demand is the size of the data set that users
are pulling down. If it is very large, then AJAX would likely be a
huge savings on bandwidth and load time of pages. I do this with
sales statistics, myself. There is a lot of data that is POTENTIALLY
relevant to the user, but downloading all sales data down to the
individual order level for six months would be prohibitive! In this
case, I pull down data sets on demand.

For things like an user's profile, tho, I load all the data on the
server side by embedding it in the page directly. This is much faster
than loading the page and then sending a request for the data and then
decoding the data and inserting into the HTML dynamically.

Security may also be an issue...I often send the user's credentials in
the form of a session ID (stored in our DB or by your server side
framework like ASP or PHP) in order to validate the request.
Otherwise you might easily pipe sensitive data to anyone who can
figure out how to create a request.

Tyler

 

[Thomas 'PointedEars' Lahn]

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,

No, in order to discuss and decide whether an additional technology
is reasonable to use it is completely irrelevant to consider what this
technology is based on because the basic stakes are the same whether
you use it or not. What is relevant is instead how well the additional
technology is supported, and what *additional* effort is necessary in
order to have that support.

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.

That is a fallacy.

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.

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.

However, that would be another fallacy.


PointedEars

 

[Peter Michaux]

On Jun 2, 11:57 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:

[snip]

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]

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

 

[Peter Michaux]

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?

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

 

[Thomas 'PointedEars' Lahn]

These are requirements.

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.

These are requirements again.

As I already described.

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

 

[Laurent vilday]

Thomas 'PointedEars' Lahn a écrit :

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 ?

 

[Peter Michaux]

Thomas 'PointedEars' Lahn a écrit :



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

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>, Mon,

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.

 

[The Magpie]

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?

 

[The Magpie]

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.

Is it reasonable to depend on Javascript in some conditions? Yes.
Is it reasonable to do so for a web page? No.

Why the difference (a question you did not ask)?

Answer:-
Javascript is a processing language and should be relied on where it
is the appropriate language for the intended location (client or
server) to carry out functions to be performed by a specific
application or process task. In these circumstances, Javascript
interpretation, any support software and specific sandbox settings or
activation on the target system should be part of the installation of
the process software or task set-up.

However, HTML is not a specific application (it is a general one) nor
process task (again, it is general). A particular web page may be
*intended* to be used as either or both an application or task but, if
so, it must specify the location, requirement and provision of
Javascript *PRIOR_TO* its use and must itself provide all those
requirements also prior to use. This is quite impractical for a web
page and so should not be relied upon.

 

[Dan Rumney]

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.

 

[Thomas 'PointedEars' Lahn]

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

 

[Logos]

In comp.lang.javascript message <[email protected]>, Mon,

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

 

[dudemeister]

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.

 

[schettino72]

I've been thinking about an alternative approach, whereby the page is
built on the fly with various AJAX calls to the server to pull in the
necessary components. In the extreme, I could visualize doing away
with Perl generated pages entirely. All pages are HTML, with AJAX
calls to the server. The responding scripts would return JSON or XML
data which would be interpreted on the client side as required.

Hi Dan,

I also started playing with this idea some months back. i wrote a
post on this subject: http://schettino72.wordpress.com/2008/05/04/designing-a-javascript-widget/

I am successfully using this approach to design js widgets.

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.

Note that you dont need necessarilly to get your json(or whatever
data) from an AJAX call. I am passing the initial data data on div
with display set to none. this way it is possible to save the page and
see the content again offline.
of course this would work only if the data is not modified
dynamically. not sure your requirements ... but thats an idea.

cheers,
Eduardo

 

[Thomas 'PointedEars' Lahn]

I've been thinking about an alternative approach, whereby the page is
built on the fly with various AJAX calls to the server to pull in the
necessary components. In the extreme, I could visualize doing away
with Perl generated pages entirely. All pages are HTML, with AJAX
calls to the server. The responding scripts would return JSON or XML
data which would be interpreted on the client side as required.

[...]
I also started playing with this idea some months back. i wrote a
post on this subject: http://schettino72.wordpress.com/2008/05/04/designing-a-javascript-widget/

The script is junk, or as you would put it, bullshit, as it does not degrade
gracefully. (I wonder why people who want to build widgets don't start with
something obvious and simple, say, form controls.)

I am successfully using this approach to design js widgets.

Self-delusion comes in small packages.

Next, please.


PointedEars

P.S.
Since Dan is a Google Groups user and does not post with only e-mail address
in the From header, he must have subscribed to this newsgroup (as you
probably have). Therefore I doubt he appreciates your Cc:ing him unsolicited.