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

Hi all,

I've been writing Javascript for quite a while now and have, of late,
been writing quite a lot of AJAX and AJAX-related code.

In the main, my dynamically generated pages are created using Perl on
the backend, with Javascript providing limited frontend functionality.
As an example, an expanding tree would be fully populated on the
server-side and then presented to the browser, with Javascript and CSS
being used to vary the visibility of elements of the tree as required.

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 understand that such an approach would mean that non-JS enabled
browsers would not be able to access the pages I create, but I'm not
concerned about that (my audience is internal to my company, so I can
stipulate browser requirements).

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?

Many thanks,

Dan

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

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.

Technically, I'm still a lurker in this domain, as I've yet to get
into a real Javascript project, but I think this approach has a lot of
potential (and I've been thinking a lot about this recently).

However, I would still approach this pragmatically. Respecting the
fact that you're probably more Perl-oriented, it's worthwhile to still
utilize some well-built frameworks as components of this, but in a
loosely coupled fashion (for instance, I would never use JSP custom
tags that encapsulate old versions of Dojo or YUI components). Using
YUI as the client framework and Struts2 to implement services for the
client would be a good combination. Adding DWR to this mix could be
useful also.

However, don't ignore the possibility of still doing some server-side
code generation. There may be situations where server-side generation
of the initial snapshot of data would be useful.

As other posters have pointed out, you have to pay attention to your
requirements. If accessibility is an issue, you'll have to think
carefully about that.

-- cut --

Thanks Peter,

You raise some good points there.

Some of them are less relevant to me, but useful for the wider
readership of this forum.

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.

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'd also be the first to admit that I'm not abreast of all the
framework choices that are out there.

The way I like to develop dynamic pages is to create a mockup of how
I'd like the final page to look , using purely static HTML (and making
up some arbitrary values for the dynamic bit).
The method I outlined in my original post makes the transition from
static to dynamic a lot simpler.

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

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

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

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.

-- cut --

Some more good points.

I need to learn more about YUI, Struts2 and DWR, clearly.

However, I was particularly struck by your suggestion of using server-
side code for the initial snapshot and, if I may infer your meaning,
using Javascript to update the snapshot as time goes on.

I agree, in principle, however, I'd like to present a counterpoint.

The framework above requires:

(SS: Server-side
CS: Client-side
)

1) SS to generate initial page
2) CS to present initial page
3) CS to handle ongoing requests
4) SS to generate responses to requests

Using Javascript built pages, you could avoid 1) altogether.

Question is: is this such a big saving after all? I think that the
answer to that may be purely application specific. However, you've
also given me some grist to add to my mental mill.

Thanks

On Jun 1, 2:56 pm, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
wrote:

It works.

It does not. The document is empty. For a user with disabilities, a search
engine, a user behind a filtering proxy, a user with a not so sophisticated
mobile device and so on. You are blinding yourself to the possibilities of
access to a Web application if you call this nonsense working.

For the users with disabilities I would highly suggest do not follow
the W3C's approach when a bunch of healthy people (possible mental
disabilities being disregarded) are getting together to decide what is
most needed for people with disabilities.

We could make a cross-group discussion on the sub-subject in c.l.j.,
comp.human-factors and alt.comp.blind-users.
I would exclude ciwah because from my previous experience similar
discussions in there are attracting side spoilers - thus people w/o
disabilities but pretending to be such to enforce their opinions on
the subject. alt.comp.blind-users is more reliable because the
regulars can easily detect a "black sheep" in the thread.

From the current topics I see that Javascript is the least of concerns
of blind users:
http://groups.google.com/group/alt.comp.blind-users/browse_frm/thread/12b21f70d38c8845
http://groups.google.com/group/alt.comp.blind-users/browse_frm/thread/9ec3f68a4ef803dc
http://groups.google.com/group/alt.comp.blind-users/msg/d56704254dc18bcb

Yet let's us ask them rather then guess? OP might make a demo page
using the new approach he is thinking of so it could be visited by
people with disabilities for their feedback. It is not the entire
problem - as already was pointed out - but at least the sub-subject
about "Javascript and blind users" could be investigated.

VK wrote:

On Jun 1, 2:56 pm, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de> wrote:
It works.
It does not. The document is empty. For a user with disabilities, a
search engine, a user behind a filtering proxy, a user with a not so
sophisticated mobile device and so on. You are blinding yourself to
the possibilities of access to a Web application if you call this
nonsense working.

For the users with disabilities I would highly suggest do not follow the
W3C's approach when a bunch of healthy people (possible mental
disabilities being disregarded) are getting together to decide what is
most needed for people with disabilities.

Please spare us your delusions about what the W3C is or is not. After
having read your W3C-related blog entry at <http://comvkmisc.blogspot.com/>,
nobody in their right mind would consider your statements to be relevant
anymore.

We could make a cross-group discussion on the sub-subject in c.l.j.,
comp.human-factors and alt.comp.blind-users.

Or we could simply call you an incompetent delusional troll.

I would exclude ciwah because from my previous experience similar
discussions in there are attracting side spoilers - thus people w/o
disabilities but pretending to be such to enforce their opinions on the
subject. alt.comp.blind-users is more reliable because the regulars can
easily detect a "black sheep" in the thread.

Talking about "black sheeps in the thread" is a joke when it comes from you,
and a bad one at that. You are evidently not capable of taking part in a
serious technical discussion; your inability or unwillingness to accept
proven facts as the truth, to break out from your little fantasy world is
too much of a hindrance for that.

From the current topics I see that Javascript is the least of concerns of
blind users:
http://groups.google.com/group/alt.comp.blind-users/browse_frm/thread/12b21f70d38c8845

http://groups.google.com/group/alt.comp.blind-users/browse_frm/thread/9ec3f68a4ef803dc
http://groups.google.com/group/alt.comp.blind-users/msg/d56704254dc18bcb

That blind users or users with impaired vision might not recognize this as a
problem constitutes no evidence that there is no problem with this.

Yet let's us ask them rather then guess?

No thanks, you may indulge in your fantasies and get yourself scored down
and killfiled all by yourself.

OP might make a demo page using the new approach he is thinking of so it
could be visited by people with disabilities for their feedback. It is
not the entire problem - as already was pointed out - but at least the
sub-subject about "Javascript and blind users" could be investigated.

There is nothing to investigate there as nothing was said about blind users
in particular. That said, that text browsers usually do not support
client-side ECMAScript-compliant scripting and the APIs under discussion
here should be indication enough that there is a problem with an empty
document filled through these techniques for users with impaired vision.

I strongly suggest again you stay silent about things you don't have the
slightest clue of.


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>

On Jun 1, 4:09 pm, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
wrote:

VK wrote:
On Jun 1, 2:56 pm, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de> wrote:
It works.
It does not. The document is empty. For a user with disabilities, a
search engine, a user behind a filtering proxy, a user with a not so
sophisticated mobile device and so on. You are blinding yourself to
the possibilities of access to a Web application if you call this
nonsense working.

For the users with disabilities I would highly suggest do not follow the
W3C's approach when a bunch of healthy people (possible mental
disabilities being disregarded) are getting together to decide what is
most needed for people with disabilities.

Please spare us your delusions about what the W3C is or is not. After
having read your W3C-related blog entry at <http://comvkmisc.blogspot.com/>,
nobody in their right mind would consider your statements to be relevant
anymore.

This blog post is my comment on http://www.w3.org/TR/2007/WD-html-design-principles-20071126
which indeed gave me at the moment a hope for W3C so I planned to
comment on the further development. Alas hardcoded ones won again with
4.01 updates never accepted and HTML 5 pushed into "somewhere in a few
years or so or better never". It is very misfortune because after W3C
being inevitably faded out of the Web authorities list we're coming
back to the old situation of non-intermediated browser producer wars
with IE still hugely dominating on the market. Maybe it was a
strategic mistake of WHATWG to join W3C and giving up their HTML 5
working base as some "initial membership fee". By keep their original
position of a group of reasonable thinking technical specialists being
in opposition to a group of fanatic pedants: by saving this position
they could try to transfer the standardization authority from W3C to
WHATWG. Such transfer would be supported by many IMO. And now
themselves and their HTML 5 are buried in the regular endless XHTML,
"informational objects" and other useless crap. That is IMO - and what
exactly connection does it have with a site accessibility or
usability?



6. Thomas 'PointedEars' Lahn
View profile
Hide options Jun 1, 4:09 pm
Newsgroups: comp.lang.javascript
From: Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
Date: Sun, 01 Jun 2008 14:09:16 +0200
Local: Sun, Jun 1 2008 4:09 pm
Subject: Re: Javascript on the client as an alternative to Perl/PHP/
Python on the server
Reply | Reply to author | Forward | Print | Individual message | Show
original | Report this message | Find messages by this author

VK wrote:

On Jun 1, 2:56 pm, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de> wrote:
It works.
It does not. The document is empty. For a user with disabilities, a
search engine, a user behind a filtering proxy, a user with a not so
sophisticated mobile device and so on. You are blinding yourself to
the possibilities of access to a Web application if you call this
nonsense working.

For the users with disabilities I would highly suggest do not follow the
W3C's approach when a bunch of healthy people (possible mental
disabilities being disregarded) are getting together to decide what is
most needed for people with disabilities.

Please spare us your delusions about what the W3C is or is not. After
having read your W3C-related blog entry at <http://
comvkmisc.blogspot.com/>,
nobody in their right mind would consider your statements to be
relevant
anymore.

We could make a cross-group discussion on the sub-subject in c.l.j.,
comp.human-factors and alt.comp.blind-users.

Or we could simply call you an incompetent delusional troll.

I would exclude ciwah because from my previous experience similar
discussions in there are attracting side spoilers - thus people w/o
disabilities but pretending to be such to enforce their opinions on the
subject. alt.comp.blind-users is more reliable because the regulars can
easily detect a "black sheep" in the thread.

Talking about "black sheeps in the thread" is a joke when it comes
from you,
and a bad one at that. You are evidently not capable of taking part
in a
serious technical discussion; your inability or unwillingness to
accept
proven facts as the truth, to break out from your little fantasy world
is
too much of a hindrance for that.

From the current topics I see that Javascript is the least of concerns of
blind users:
http://groups.google.com/group/alt.comp.blind-users/browse_frm/thread...
http://groups.google.com/group/alt.comp.blind-users/browse_frm/thread...
http://groups.google.com/group/alt.comp.blind-users/msg/d56704254dc18bcb

That blind users or users with impaired vision might not recognize this as a
problem constitutes no evidence that there is no problem with this.

That is just hilarious. So, who cares what actual accessibility
problems user with disabilities are experiencing, right? They will
experience only problems, defined by a set of selected people, any
other problems are not allowed. :-)
btw Amazon.com was always known for Javascript-independent design.
Turn the scripting off and try to shop - no problem. Yet it is a hate
target of visually impaired users. Anyone of "accessibility fighters"
here or at ciwah ever asked them why exactly? I didn't yet but in
these groups there are so many people who's heart is bleeding about
the accessibility, at least based on their posts. Did they ever
investigate the matter so do not repro it in their own solutions and
advises?

There is nothing to investigate there as nothing was said about blind users
in particular. That said, that text browsers usually do not support
client-side ECMAScript-compliant scripting and the APIs under discussion
here should be indication enough that there is a problem with an empty
document filled through these techniques for users with impaired vision.

For the starter one should investigate do such user consider
Javascript as an accessibility helper or an accessibility spoiler. A
link I gave suggests the first, but again: let's talk about it with
them. At least the idea that every one of them is on Lynx-like agent
is a nonsustaining urban legend INHO.

VK, PointedEars,

Please don't hijack this thread to bicker about accessibility.

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.

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

Dan Rumney wrote:

VK, PointedEars,

Please don't hijack this thread to bicker about accessibility.

You miss the point.

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.

If that is the case it would still not sufficient as you will also have to
make sure that the script-enabled user agent supports the method you are
filling the document you redirect to before you redirect to it. This is not
always possible. Where it is, it introduces double maintenance that you
could have spared yourself if you had created an accessible document, only
enhanced with client-side scripting, in the first place.

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

Usenet is not a right.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[Pardon my English in the message superseded by this one]

Dan Rumney wrote:

VK, PointedEars,

Please don't hijack this thread to bicker about accessibility.

You miss the point.

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.

If that would be the case it would still not be sufficient. You will also
have to make sure that the script-enabled user agent supports the exact
method you are filling the document with that you redirect to, before you
redirect to it. This is not always possible. Where it is, it introduces
double maintenance that you could have spared yourself if you had created an
accessible document, only enhanced with client-side scripting, in the first
place.

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

Usenet is not a right.


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