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

On May 31, 11:22 pm, Dan Rumney <danrum... (AT) warpmail (DOT) net> wrote:

Any solution that is dependent on Javascript for content generation
and manipulation will cause problems to those with old browser, text-
only browser, or those using screen readers. I wholly acknowledge this
fact, but I'm not going to dwell on it further as I feel that this has
probably been touched on by various other posters.

The danger isn't deciding that it is ok to depend on JavaScript. It is
*mistakenly* deciding it is ok to depend on JavaScript. I'm not saying
it is a bad decision but making a mistake in this area could be costly
later. Make sure the boss officially makes this decision because it is
basically a decision about investment vs accessibility.

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. I like to be able to understand the link
between what I'm seeing and the HTML that's being created.

I only use a text editor to do any work, either client or server side.
I would not consider using anything else which may be leading to my
confusion about your concern. This doesn't really affect this
discussion about software architecture. Different people use different
tools and the vi and emacs folks try to kill each other.

[snip]

I think your comments about browser bugs is a *very* useful one.
Server generated HTML will never be exposed to that. So long as it
generates good HTML, it will produce a sensible page. Writing
Javascript that is cross-browser compliant is a major pain (this I
know!)

In general, innerHTML works well and for generating complex bits of
page is faster and less buggy than using the standardized DOM methods
like document.createElement.

Not to diminish your comments, but I think I can summarise them as:
1) Javascript page building results in pages that are not widely
accessible

They are widely accessible because generally JavaScript is "on" in
browsers. They are not *as* widely accessible. This distinction
somewhat softens the blow but for a single user that is left out then
it makes no difference to that user.

2) Javascript page building is prone to web bugs

I think it's important to all readers to be aware of 1) and understand
its relevance to their solution (and, most of all, not underestimate
that importance)
I think that 2) is a good point, but can be solved with an appropriate
client-side framework.

Don't put too much blind faith in the "appropriate client-side
framework". The quality of the available mainstream JavaScript
libraries has been called into question here many times. Various basic
errors from not understanding how JavaScript works to using browser
sniffing when at least unnecessary (which may be always) have been
pointed out about these libraries on comp.lang.javascript. Some of
these libraries are labeled version 1+ which should be an
embarrassment to the authors. They would be better labeled version
0.0.1.

Which brings us back to one of your first points, albeit an implicit
point: find the right server-side framework.

client-side or server-side?

Many of the regulars on comp.lang.javascript do not believe you will
find a client-side library ready and appropriate to your project.

Great food for thought; thanks!

For the record: a white paper is broadly understood to be a relatively
short treatise or report aimed to educate people on a certain point or
to present a solution to an industry problem. The phrase may be tossed
around widely, but I think I was using it in its appropriate context
here.

I don't think you will find white papers on JavaScript. I just read
web pages, books and participate on comp.lang.javascript.

Peter

The danger isn't deciding that it is ok to depend on JavaScript. It is
*mistakenly* deciding it is ok to depend on JavaScript. I'm not saying
it is a bad decision but making a mistake in this area could be costly
later. Make sure the boss officially makes this decision because it is
basically a decision about investment vs accessibility.

For the record, the specific tool that I own is an internal one. It is
designed to take the textual representation of a system's
configuration and present it in a graphical manner to allow for more
ready identification of configuration errors. I have no budget and no
time allowance for this.

Intellectually, I would love to address the issue of making this tool
available to screen-reader users, but as there is no current demand
for a solution to the problem and no resources for finding that
solution, I'm going to have to let it slide... investment 1
accessibility 0

[snip]

I think your comments about browser bugs is a *very* useful one.
Server generated HTML will never be exposed to that. So long as it
generates good HTML, it will produce a sensible page. Writing
Javascript that is cross-browser compliant is a major pain (this I
know!)

In general, innerHTML works well and for generating complex bits of
page is faster and less buggy than using the standardized DOM methods
like document.createElement.

I've come to that realisation myself. I've taken to generating HTML
via code less and less and now tend to pull data from the server in
XML format, run it through an XSL transformation to HTML and stick use
innerHTML to put it into the page... so much so, in fact, that I've
written a javascript object to do just that.

1) Javascript page building results in pages that are not widely
accessible

They are widely accessible because generally JavaScript is "on" in
browsers. They are not *as* widely accessible. This distinction
somewhat softens the blow but for a single user that is left out then
it makes no difference to that user.

Good point

I think that 2) is a good point, but can be solved with an appropriate
client-side framework.

Don't put too much blind faith in the "appropriate client-side
framework". The quality of the available mainstream JavaScript
libraries has been called into question here many times.

[snip]

So it would seem. I currently use one library downloaded from the
internet (zXML) for convenience. At the moment, I'd rather write my
own framework and fix the inevitable bugs than download someone else's
and have to decipher it before fixing the inevitable bugs

Which brings us back to one of your first points, albeit an implicit
point: find the right server-side framework.

client-side or server-side?

I did mean server-side, here.

On of the advantages that I felt my model had was that the server-side
data processing is decoupled from its presentation. In your garde
variety Perl script, you have data processing mixed up with data
presentation to one degree or another.
Having static HTML pages and calling in the data via AJAX allows you
to develop your presentation pages in pure HTML-CSS-JS, with no Perl/
PHP/Python involved.

However, I see now that a well chosen server-side framework can
provide this functionality too. That was the point I didn't make very
well

However, this does bring me back to the point I made in an earlier
post. All the server frameworks that I know of require you to put
'magic tags' inside the HTML so that the server can process it and
replace those tags with data.
This means that your 'template' HTML files will never validate. You
can only test the results of the framework which are naturally
dynamic.

That's not to say that that's an insoluble problem.

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.

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.

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

[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?

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

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

On May 31, 4:53 pm, Dan Rumney <dancr... (AT) gmail (DOT) com> wrote:

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

On Jun 2, 11:57 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
wrote:

[snip]

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

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

On Jun 2, 12:29 pm, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) 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.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