dynamically generating html vs using html scaffolding?

[Faisal Vali]

Are there any guidelines people use that help them decide when it is
better to dynamically generate all html elements using javascript
versus actually writing some html and using it as scaffolding?
I have been using the extjs framework ( I haven't see this library
critiqued much on this forum - unlike prototype, jquery and dojo which
the regulars here tend to eviscerate - unless i've missed some
threads, which is quite possible) and it allows both mechanisms for
all its widgets and layouts. But i'm not sure what the pros and cons
are to either approach. Obviously if you don't have access to the
html page then your options are limited.

Anyway, I was planning on posting this within the extjs forums (and I
still might if it doesn't spark much of a response here), but then
thought that this was more of a general javascript/style question and
so have posted this here.

Would really appreciate your thoughts.

Thanks,
Faisal Vali, MD, MSc
Loyola Radiation Oncology
Chicago, IL

 

[SAM]

Faisal Vali a écrit :

Are there any guidelines people use that help them decide when it is
better to dynamically generate all html elements using javascript
versus actually writing some html and using it as scaffolding?

The only way is to code :
- all in html,
eventually with css,
exceptionally with few images
- adding JS for some non really useful dynamism, not more

I have been using the extjs framework ( I haven't see this library

and what is this marvelous extjs ?
where does it leave ?

ie : seen that
<http://www.extendersamples.qsh.eu/>
-> 886 KB (1252 KB uncompressed) just for a table :-(
or ... what is supposed to be a impla example of a kind of plugin :
http://www.siteartwork.de/livegrid_demo/
--> 1154 KB :-( :-( (just to sort a table ?)

critiqued much on this forum - unlike prototype, jquery and dojo

Perhaps because it is less well known or used ?

Would really appreciate your thoughts.

As I start from principle that a page must be displayed and readable
without JS ... :-(

 

[Thomas 'PointedEars' Lahn]

Perhaps not the *only* way to code, but certainly a sensible set of
principles to begin with.

I second that.

There is no TABLE element, it is composed of DIV elements.

[...] I went to the site and saw 962KB (as reported by
Firebug).

I thought: well it must be mainly in the graphics... not so:

HTML: 22KB
CSS: 207KB
JS: 705KB
Images: 15KB
XHR: 15KB

Jinkies!

or ... what is supposed to be a impla example of a kind of plugin :
http://www.siteartwork.de/livegrid_demo/
--> 1154 KB :-( :-( (just to sort a table ?)

And, if I may: Yowser!

However, as for the scripts the footprint could have been considerably
smaller if a competent person would have written it (or the code generating
it). For example, the code in the ExtJs example includes

function Sys$WebForms$EndRequestEventArgs$get_dataItems() {
// ...
if (arguments.length !== 0) throw Error.parameterCount();
return this._dataItems;
}

[...]

Sys.WebForms.EndRequestEventArgs.prototype = {
get_dataItems: Sys$WebForms$EndRequestEventArgs$get_dataItems,
get_error: Sys$WebForms$EndRequestEventArgs$get_error,
get_errorHandled: Sys$WebForms$EndRequestEventArgs$get_errorHandled,
set_errorHandled: Sys$WebForms$EndRequestEventArgs$set_errorHandled,
get_response: Sys$WebForms$EndRequestEventArgs$get_response
}

With `Sys$WebForms$EndRequestEventArgs$get_dataItems' aso. being references
to previously declared local functions. A function expression would have
gotten rid of this bloat and could have probably been used without regret,
being supported since JavaScript 1.3 (NN3), JScript 3.0 (IE 4), ECMAScript
Ed. 3. Especially for an application which uses Object initializers and
`throw', without fallback each, which are supported only since JavaScript
1.3/1.4, JScript 3.0/5.5 (IE 5.5), ECMAScript Ed. 3:

Sys.WebForms.EndRequestEventArgs.prototype = {
get_dataItems: function() {
// ...
if (arguments.length !== 0) throw Error.parameterCount();
return this._dataItems;
}

...
};

See also <http://PointedEars.de/es-matrix>.


PointedEars

 

[Thomas 'PointedEars' Lahn]

However, as for the scripts the footprint could have been considerably
smaller if a competent person would have written it (or the code generating
it). For example, the code in the ExtJs example includes

[...]
Sys.WebForms.EndRequestEventArgs.prototype = {
get_dataItems: Sys$WebForms$EndRequestEventArgs$get_dataItems,
get_error: Sys$WebForms$EndRequestEventArgs$get_error,
get_errorHandled: Sys$WebForms$EndRequestEventArgs$get_errorHandled,
set_errorHandled: Sys$WebForms$EndRequestEventArgs$set_errorHandled,
get_response: Sys$WebForms$EndRequestEventArgs$get_response
}

With `Sys$WebForms$EndRequestEventArgs$get_dataItems' aso. being references
to previously declared local functions. A function expression would have
gotten rid of this bloat and could have probably been used without regret,
being supported since JavaScript 1.3 (NN3), JScript 3.0 (IE 4), [...]

^^^[1] ^^^^[2]

[1] Netscape Navigator _4.06+_ (see the ES Matrix)
[2] ... *and* other UAs based on Trident I (MSHTML.dll v4.0.x)
<http://en.wikipedia.org/wiki/Trident_(layout_engine)>


PointedEars

 

[Peter]

While I second that JS *normally* should only be used sparce, non
obtrusive, etc and all, I really think there is a place for a
comprehensive framework like ExtJS and others. It is, IMHO, a fairly
extensive framework that allows making responsive, webbased
*programs*.
What I mean, is that one should not rely on JS for frontend
*websites*, but 'ajaxified' websites go beyond HTML and become more or
less *programs*. I wouldn't mind using these tools on an intranet.
Heck, I'm currently building one. I know my target users, and am in
control of their OS and Browser. It is even build using standard HTML/
CSS/JS, so *any* other programmer that comes after me, can work on it
and I can be pretty sure of the 'future-proofness' of it.
ExtJS just gives me the controls and widgets, that I can use to build
a webbased administration program, that works fast and it costs me
just weeks instead of months, using something like C++/Java.
The problem is: know where to use JS and where not. Things like Google
Maps and Google Docs are extremely helpfull tools. Should these be
done in just HTML?! No ofcourse not, it just wouldn't even be possible
to do so! But http://www.google.com obviously should not ;-)

Websites / DOM based programs that run in a browser: 2 different
things!

Just my 2 cents.

P.

 

[VK]

Websites / DOM based programs that run in a browser: 2 different
things!

Absolutely. By rephrasing it in the "commercial lingo": Web 1.0 and
Web 2.0 are two different things.

Web 1.0 one started and remains as information represented in a
particular format (HTML markup) delivered to a viewer able to render
such format (browser). In the context of Web 1.0 styling and scripting
are additional tools intended to facilitate the process of perceiving
and navigating withing the delivered information. At the same time
they are not required to use the delivered information.

Web 2.0 is a client-side interface to handle different information.
This interface is programmed using Javascript and DOM and usable over
capable framework application (browser). Other words Web 2.0 content
and a browser are in the same relations as Javascript and HTML page or
Java applet and JVM. This interface is not intended and doesn't have
to operate without a capable framework application, in the same way as
Java applet is not intended nor has to run without JVM installed.

Web 1.0 and Web 2.0 are _not_ in XOR relation. The one doesn't exclude
other nor one has to replace other (though it will most probably
happen in some amount of time).

It is just not appropriate to mechanically apply the same set of
demands to two completely different concepts - but many old thinkers
are still trying to do it, and not in this NG only.

 

[Thomas 'PointedEars' Lahn]

While I second that JS *normally* should only be used sparce, non
obtrusive, etc and all, I really think there is a place for a
comprehensive framework like ExtJS and others. It is, IMHO, a fairly
extensive framework that allows making responsive, webbased
*programs*.

What I mean, is that one should not rely on JS for frontend
*websites*, but 'ajaxified' websites go beyond HTML and become more or
less *programs*. I wouldn't mind using these tools on an intranet.

Whatever your curious way of emphasizing words, you seem to have missed the
point of this subthread and specifically of my posting entirely (to which
you posted a followup, after all), which was how to write code so that it
does not require this much of data to be downloaded and still does what it
is supposed to do.

This includes, but is not limited to, client-side script code. Because all
code and data (e.g. images) used client-side always needs to be downloaded
to the equivalent of a cache beforehand, whether it is with a Web
application running on the Internet or one running in an intranet (I presume
you meant Local Area Network instead which is not the same thing) or on the
local host.

Obviously, the more data needs to be transferred, stored, and interpreted,
the slower and more unresponsive the Web application will be (even with
XHR). For a LAN with a rather limited data rate as compared to its supposed
number of users this also means: the greater the overall network load will
be, therefore the slower the overall network response will be. For the
local host this also means: the more system resources are consumed by the
Web application and the user agent it must run in, and the more unresponsive
other applications will become.

You really don't want to support that. Which does not mean in any way that
dynamic technologies like XHR (which some call by the misnomer "AJAX")
should not be used. But they should be used wisely, to *reduce* the total
amount of data to be transferred. That label certainly cannot be attached
to an application that requires an about one MiB download to do what could
have been done with only a tiny fraction of that. And it is almost certain
that it could have been done easily, as I have showed.

Please take heed of <http://jibbering.com/faq/#FAQ2_3> next time.


PointedEars

 

[Peter]

Whatever your curious way of emphasizing words,

Just wanted to make a difference between *websites* and *programs*

you seem to have missed the
point of this subthread and specifically of my posting entirely (to which
you posted a followup, after all), which was how to write code so that it
does not require this much of data to be downloaded and still does what it
is supposed to do.

No, I did not. I think many people define download size as html + js +
css. They completely forget that most of the traffic is caused by
images and other media. I personally think that any framework used for
*programs* is small enough to be 'bundled' with them.

(I presume you meant Local Area Network instead which is not the same thing) or on the
local host.

No, an intranet is a *collection of LAN's*, with local (non internet)
domain names, which from a users point of view acts like a small
'internet'.

Obviously, the more data needs to be transferred, stored, and interpreted,
the slower and more unresponsive the Web application will be (even with
XHR). For a LAN with a rather limited data rate as compared to its supposed
number of users this also means: the greater the overall network load will
be, therefore the slower the overall network response will be.

To have a client-side framework downloaded *once* (have it cached for
next visits) is a trivial non-issue in my opinion. Again: images are
way bigger.

For the local host this also means: the more system resources are consumed by the
Web application and the user agent it must run in, and the more unresponsive
other applications will become.

I wonder if you've ever used a framework like ExtJS/DoJo e.o., because
it definitely is *not* unresponsive, slow or anything like that. It is
a convenient way to quickly build 'web 2.0' a.k.a. AJAX programs. From
my point of view, these frameworks can really offer a great commercial
value for businesses and organisations that all of a sudden can
'update' their programs without having a network administrator doing
all sorts of tests and roll-outs. They can extend their intranets to
the internet.
After all: lots of programs that are used by businesses and
organisations do simple things that can really easily be ported to web
2.0 apps. But the need for a good and consistent UI raises the need
for a framework.
Are you going to build everything these frameworks offer (sortable-
live grids/tree's/form validation/resizable frames/etc) from scratch,
just to squeeze out a few kB's?

 

[John G Harris]

On Mon, 16 Jun 2008 at 08:19:24, in comp.lang.javascript, Peter wrote:

No, I did not. I think many people define download size as html + js +
css. They completely forget that most of the traffic is caused by
images and other media. I personally think that any framework used for
*programs* is small enough to be 'bundled' with them.

Using a 200kB .js file to display a 1kB news article is madness. Even on
an intranet it would be madness.

If you look in your browser's cache you'll see that framework .js files
are over 100kB. Image files are rarely over 30kB except when they are
the main point of the page.

To have a client-side framework downloaded *once* (have it cached for
next visits) is a trivial non-issue in my opinion. Again: images are
way bigger.

<snip>

You can say this about an intranet application that is used many times a
day at each desk.

For general web sites it's very dubious. When nothing useful is
displayed after 10 seconds people can use the back button and go to the
next link in the search results. Anyone selling consumer goods needs to
remember this : you're only two clicks away from a rival shop.

Also you have to remember that cache entries expire, caches are cleared,
and people don't re-visit web sites that annoy them.

John

 

[Peter]

  <snip>

You can say this about an intranet application that is used many times a
day at each desk.

That's what I'm saying ;-)

For general web sites it's very dubious. When nothing useful is
displayed after 10 seconds people can use the back button and go to the
next link in the search results. Anyone selling consumer goods needs to
remember this : you're only two clicks away from a rival shop.

True, but that doesn't say there's not a place for an extensive
framework. Both ways: small, compact coded, fast, frontend websites on
the one hand, and (slightly bigger) *programs* on the other, backend
or intranet side.


Peter

 

[Thomas 'PointedEars' Lahn]

Just wanted to make a difference between *websites* and *programs*

There should be no difference with regard to code quality.

No, I did not. I think many people define download size as html + js +
css. They completely forget that most of the traffic is caused by images
and other media. I personally think that any framework used for
*programs* is small enough to be 'bundled' with them.

This discussion was about how to reduce the total amount of data to be
transferred from the server to the client and how to achieve this best.
Obviously, although the download size of the plain document would be minimal
to have an empty document that is only filled with client-side scripting is
not the best approach.

No, an intranet is a *collection of LAN's*, with local (non internet)
domain names, which from a users point of view acts like a small
'internet'.

I know what an intranet is. Obviously you don't, for you assume homogenity
where none exists which leads to wrong design decisions.

I wonder if you've ever used a framework like ExtJS/DoJo e.o., because it
definitely is *not* unresponsive, slow or anything like that.

I did not attempt to assess the responsiveness of ExtJS/DoJo.

[Web 2.0 marketing speech]

Please don't insult the intelligence of your readers.

Are you going to build everything these frameworks offer (sortable- live
grids/tree's/form validation/resizable frames/etc) from scratch, just to
squeeze out a few kB's?

I never had the need for live grids or trees in my professional field of Web
applications because those were never a requirement in the field I am
working in. However, if I had to fulfill those requirements and other ones,
as always I would carefully weigh advantages and disadvantages of
prepackaged libraries like those you mention before I make the decision
whether to use them or not. Quick deployment is not everything, and they do
have a number of disadvantages, some of them already discussed before. Only
an incompetent fool would ignore that.


PointedEars