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

Dan Rumney

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

May 31 '08 #1

Subscribe Reply

2943

Peter Michaux

On May 31, 4:53 pm, Dan Rumney <dancr...@gmail .comwrote:

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.

This is a good approach, the only viable approach, if you want your
pages on the general purpose web where old browsers and/or disabled
users are visiting the site. A fully functional HTML page is the only
way to start in this environment where the JavaScript merely enhances
the user experience. JavaScript can feel a bit like fluff or icing on
the cake in this situation. It can also add the necessary wow factor
for the marketing department. This is the most expensive form of
development for a front end as it needs to work under many sets of
circumstances.

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.

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 " type="text/javascript"></script>
<script src="app.js" type="text/javascript"></script>
</head>
<body>
</body>
</html>

The app.js file loads all the necessary data using Ajax and JSON. The
body is dynamically built based on this data.

An advantage to this would be that it would be a lot easier to
generate the pages using simple HTML editors.

I don't understand why it would be easier or what "simple HTML
editors" are and how they relate here. Generating pages server-side is
not a particular burden and actually there are more to read and
frameworks for doing page generation on the server-side.

It would be a lot
simpler to ensure validity of the HTML (as the final product would
always be available to me).

I don't understand this either. It should be easy to validate the HTML
either way.

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

Make sure the company will never hire a disabled user that requires a
browser that does not support JavaScript.

I'm interested in people's comments on this approach.

It works.

Does it provide
extra burden on the server?

Possibly less. It depends on how much code the server has to send to
the client so the client can generate the page. It also depends how
many times the page needs to be redrawn/refreshed without changing the
data. In my case the page is redrawn many times based on about 50k of
relatively constant data. By doing it all client-side it saves the
server going into the cache or db many times. It saves downloading
this 50k many times also.

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

I think the main ones are accessibility and that you will likely deal
with more browser bugs because the client is doing more. You will be
managing quite a bit of data on the client-side. Some sort of MVC
architecture in the JavaScript may help.

Does anyone know of any white papers
on this approach?

What exactly would a "white paper" for a topic like this? People toss
this phrase around all the time. I use Google, read blogs and
comp.lang.javas cript, of course.

Peter

Jun 1 '08 #2

david.karr

On May 31, 4:53 pm, Dan Rumney <dancr...@gmail .comwrote:

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.

Jun 1 '08 #3

Dan Rumney

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

Jun 1 '08 #4

Dan Rumney

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

Jun 1 '08 #5

Thomas 'PointedEars' Lahn

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

The app.js file loads all the necessary data using Ajax and JSON. The
body is dynamically built based on this data.

Very accessible. NOT.

>It would be a lot simpler to ensure validity of the HTML (as the final
product would always be available to me).

I don't understand this either. It should be easy to validate the HTML
either way.

As the W3C Validator documentation explains already, Validation alone is not
a mark of service quality. An empty document, a document that has no content
without scripting, is FUBAR. Unless, of course, it exists merely to
demonstrate a scripting feature or how FUBAR a such a document would be.

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

Make sure the company will never hire a disabled user that requires a
browser that does not support JavaScript.

But that is not it at all. Accessibility does accommodate users with
disabilities, but by far not only them.

>I'm interested in people's comments on this approach.

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

Jun 1 '08 #6

On Jun 1, 2:56 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.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.c...b21f70d38c8845
http://groups.google.com/group/alt.c...c3f68a4ef803dc
http://groups.google.com/group/alt.c...6704254dc18bcb

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.

Jun 1 '08 #7

Thomas 'PointedEars' Lahn

VK wrote:

On Jun 1, 2:56 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.dewrote:

>>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
sophisticate d 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.blogs pot.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.c...b21f70d38c8845

http://groups.google.com/group/alt.c...c3f68a4ef803dc
http://groups.google.com/group/alt.c...6704254dc18bcb

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, <f8************ *******@news.de mon.co.uk>

Jun 1 '08 #8

On Jun 1, 4:09 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

VK wrote:
On Jun 1, 2:56 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.dewrote:
>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.blogs pot.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-de...iples-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,
"informatio nal 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.javas cript
From: Thomas 'PointedEars' Lahn <PointedE...@we b.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...@we b.dewrote:

>>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
sophisticate d 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.blogs pot.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.c...wse_frm/thread...
http://groups.google.com/group/alt.c...wse_frm/thread...
http://groups.google.com/group/alt.c...6704254dc18bcb

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 "accessibil ity 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.

Jun 1 '08 #9

Dan Rumney

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.

Jun 1 '08 #10

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

Similar topics