473,327 Members | 2,016 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,327 software developers and data experts.

'Flavors' of JS?

What do people feel about this statement: "JS exists in so many
flavours across so many browsers (and across the html/xhtml/xml divides)
that it is becoming undesirable to include any on a site."

Jim
Jul 23 '05 #1
40 2251
Jim Witte wrote:
What do people feel about this statement: "JS exists in so many
flavours across so many browsers (and across the html/xhtml/xml
divides) that it is becoming undesirable to include any on a site."


It demonstrates as much understanding of browser scripting as your
proposition yesterday of 'making a "Scheme" version of JS'.

Javascript does not exist in "so many flavours", all current browsers
implement javascript based on ECMA 262, at least fully implementing the
2nd edition, with the majority implementing the 3rd. Having a formal
specification for the language provides a clear standard against which
implementations can be judged, and non-conforming implementations can be
identified and corrected so that they do conform. The result is that
there is ever less diversity in implementations, and already a
sufficiently consistent/reliable language core for any practical
purpose.

Browser DOMs have never been consistent so the current state of affairs
does not differ from anything that has gone before, but browsers are now
converging around the W3C DOM standards, providing an ever more
consistent core of functionality.

It has been demonstrated (often) that it is possible to create browser
scripts that exhibit planed behaviour in the face of all of the
permutations of environments that they may encounter on the Internet,
and provide a valuable enhancement when they encounters any environment
that is sufficiently supportive. It may not be a trivial design task to
create such a script but there is no reason for not using it once
created.

So, insofar as anything is "becoming", the task is becoming easier. The
desirability of the use of javascript is not related to the diversity of
environments that can be scripted. It can only be related to the
suitability of the implementation of the script for its environment(s).

In a browser script failure is inevitable (as it is always possible for
the user to disable scripting) so a suitable script must be designed so
it will not cripple (or even harm) a web page when it fails, but once
the design makes sense in the face of total failure there is always a
path of clean depredation to be followed when the browser does not
support the specific features required by the script.

Richard.
Jul 23 '05 #2
Richard Cornford wrote:
Jim Witte wrote:
What do people feel about this statement: "JS exists in so many
flavours across so many browsers (and across the html/xhtml/xml
divides) that it is becoming undesirable to include any on a site."

It demonstrates as much understanding of browser scripting as your
proposition yesterday of 'making a "Scheme" version of JS'.

Javascript does not exist in "so many flavours", all current browsers
implement javascript based on ECMA 262, at least fully implementing the
2nd edition, with the majority implementing the 3rd. Having a formal

........ In a browser script failure is inevitable (as it is always possible for
the user to disable scripting) so a suitable script must be designed so
it will not cripple (or even harm) a web page when it fails, but once
the design makes sense in the face of total failure there is always a
path of clean depredation to be followed when the browser does not
support the specific features required by the script.

Richard.


I see the following statistics for the web site that I have data for.
There are 8 browsers with some usage.
We use javascript, but sparingly. It is pretty hard to even
test against all these browsers.

46.79% MSIE 6.0
33.45% Mozilla/5.0
3.00% MSIE 5.5
2.22% MSIE 5.0
1.95% Googlebot/2.1 (+http://www.googlebot.com/bot.html)
1.88% Konqueror/3.2
1.55% libwww-perl/5.63
1.41% Python-urllib/2.0a1
0.81% Mozilla/3.01 (compatible;)
0.72% Konqueror/3.1
0.72% Yahoo! Slurp
0.60% Opera/7.2
0.50% Python-urllib/1.15
4.40% Other/unknown

--
Robin Becker
Jul 23 '05 #3
Robin Becker wrote:
<snip>
I see the following statistics for the web site that I have
data for. There are 8 browsers with some usage.
And this is relevant because?
We use javascript, but sparingly. It is pretty hard to even
test against all these browsers.

<snip>

It always was impossible to test against all browsers, there are just to
many, and always some you have never heard of. That doesn't mean it is
impossible to author for all browsers.

But finding it difficult to test with 8 browsers doesn't sound like you
are trying very hard. The computer I as currently sitting at has 24
installed web browsers on the partition it is currently booted from, and
two more bootable partitions with 30-odd more, and that is only one of
the computers I use for browser testing.

Richard.
Jul 23 '05 #4
Richard Cornford wrote:
Robin Becker wrote:
<snip>
....... It always was impossible to test against all browsers, there are just to
many, and always some you have never heard of. That doesn't mean it is
impossible to author for all browsers.

But finding it difficult to test with 8 browsers doesn't sound like you
are trying very hard. The computer I as currently sitting at has 24
installed web browsers on the partition it is currently booted from, and
two more bootable partitions with 30-odd more, and that is only one of
the computers I use for browser testing.

Richard.


Unfortunately I don't get paid to do this full time. Like many our company has
no real webmaster and certainly no javascript experts. Most of the forms we
produce are tested by the end user. Their brief is usually Mozilla latest, IE
5-6 on PC with Mac/Linux browsers a poor relation. The argument against using
complex javascript is not whether it's feasible, but if it is economic. It's
just not easy/cheap enough for most producers. It is arguable, that by coping
with all the horrors of the web, the experts just delay standards for JS and
DOM. Differentiation is in the interest of the JS programmers and probably the
browser suppliers.
--
Robin Becker
Jul 23 '05 #5
> What do people feel about this statement: "JS exists in so many
flavours across so many browsers (and across the html/xhtml/xml divides)
that it is becoming undesirable to include any on a site."


It is false in many ways.

The JavaScript language processors in browsers are remarkably
consistent. Microsoft's JScript is far more compliant with its official
language standard than Microsoft's C++ is.

HTML/XHTML/XML are independent of the scripting language.

Browsers are horribly inconsistent in their interpretation of HTML and
especially in the interfaces they present to the scripting language.
This is the source of the difficulty. We are still suffering from
mistakes made in the browser wars and the inadequacy of web standards.

In spite of that, it is possible to design scripts that can run in a
wide variety of browsers. It requires knowledge and discipline.

The functionality provided by local computational resources is very
desirable.

And finally, "flavour" is spelled "flavor".

http://www.crockford.com/javascript/javascript.html
Jul 23 '05 #6
Douglas Crockford wrote:

......
And finally, "flavour" is spelled "flavor".
In English it is spelt "flavour", the "flavor" variant is American. Probably
need some dynamic JS to detect the reader :)
http://www.crockford.com/javascript/javascript.html

--
Robin Becker
Jul 23 '05 #7
Robin Becker wrote:
<snip>
Unfortunately I don't get paid to do this full time. Like many our
company has no real webmaster and certainly no javascript experts.
Most of the forms we produce are tested by the end user.
So every development mistake equals a disgruntled user?
Their brief is usually Mozilla latest, IE 5-6 on PC
with Mac/Linux browsers a poor relation.
Which explains you log statistics, you design for a limited set of
browsers/configurations, the users of other browsers/configurations
don't hang around clocking up log entries (because they rapidly realise
they are wasting their time), and then you use the log entries to
justify designing for the browsers that your visitors appear to use.
It's a chicken and egg relationship that becomes a vicious circle.
The argument against using complex javascript is not
whether it's feasible, but if it is economic. It's just not
easy/cheap enough for most producers.
Cross-browser scripts do not have to be complex. Indeed K.I.S.S. is a
very worthwhile design principle to follow.

The economic relationship is not being meaningfully judged. It is always
going to be relatively expensive to employ someone who doesn't know how
to do something to carry out that task. Suppose someone wanted to employ
me to repair a car engine. Given suitable tools/equipment and reference
material I probably could carry out that task, but I would be learning
as I went, and that would be expensive in terms of an hourly rate
because it would take many additional hours form me to learn enough to
succeed at that task (and probably expensive in terms of parts as I
broke things making mistakes).

But I can complete a properly specified browser script as quickly as
anyone else could write a browser specific version, so why would the
cross-browser alternative be more expensive. The economic consideration
arises from employing people for the task who lack the skill to do it
better; basically just the consequences of an initial false economy.

However, it comes down to the question of whether a web site is a
revenue source or not. If it isn't then why would any company bother? If
it is a revenue source then why *unnecessarily* restrict its potential
to produce revenue?
It is arguable, that by coping with all the horrors of the web,
the experts just delay standards for JS and DOM.
Those standards state very clearly that client-side scripting is an
optional extra (just as CSS is). So the universal adoption of DOM
standards wouldn't preclude the need to design for the consequences of
total script failure (as the users of any browsers will always be at
liberty to turn scripting off). And once that possibility has been
covered a script that exclusively employs DOM standard methods is
cross-browser, because if the browser doesn't support those standards it
only needs to detect that fact and cleanly degrade to the underlying
HTML (and back-end systems) that would be all that was available to the
users with scripting disabled/unavailable. That is, an exclusively DOM
standard script should still exhibit planed behaviour in the face of any
browser environment it encounters regardless of whether that browsers
supports the required standard (and/or scripting).

But if it tuns out that the browser actually supports a non-standard
feature (possibly as an alternative to an unsupported DOM method) then
there is no good reason for a script not to take advantage of it when
available.

However, in a commercial context, what sort of argument goes "It is the
user's choice of browser that justifies our not doing business with
them", when all browsers are capable of supporting HTTP and HTML (and
particularly HTML forms) and that is all that is needed to actually
carry out business transactions over the Internet?
Differentiation is in the interest of the JS programmers
and probably the browser suppliers.


Differentiation is not in the interests of JS programmers; we are not
masochists. We are working without the certainty of a known environment,
and that is not going to change even with the universal adoption of DOM
standards because the top of the range desktop browsers will always have
additional non-standard features that are not available to all browsers
(on all platforms) and new revisions of (and extensions to) those
standards will continue to be produced. There will also always be a
desire to exploit the available features of any browser to the maximum
extent possible, and the techniques that allow viable scripting in an
unknown environment will still be capable of meaningfully accommodating
that desire (just as they are now).

Richard.
Jul 23 '05 #8
Robin Becker wrote:
Douglas Crockford wrote:
.....
And finally, "flavour" is spelled "flavor".


In English it is spelt "flavour", the "flavor" variant is American.

<snip>

The distinction should probably be between British English and American
English (I wonder how Australians normally spell it?). English is no
longer exclusively the native language of England (and hasn't been for
some considerable time).

But the OP appears to be in the USA so may appreciate the correction for
future use.

Richard.
Jul 23 '05 #9
What about this strategy:

Project1. Construct the application with pure html, no javascript. Cost is
C1, calendar time T1

Project2. When the project P1 has been completed, everything is working
well, customers are satisfied, boss is happy,
make a new proposal to the management .

Probaly cost C2 is about the same order of magnitude as C1, and the duration
T2 about the same as T1.

Which advantages can I show to the management in order to persuade to accept
project P2?

a) some seconds in access speeds sometimes ? (when checking form input,
mainly).

b) some frills, whistles, bells, which are completely unnecessary and even
annoying for a serious customer?

The future for me as an enthusiastic javascript programmer does not look
very bright, if this is true. Toy language, amusement park for teenagers?


Jul 23 '05 #10
Richard Cornford wrote:

......
Which explains you log statistics, you design for a limited set of
browsers/configurations, the users of other browsers/configurations
don't hang around clocking up log entries (because they rapidly realise
they are wasting their time), and then you use the log entries to
justify designing for the browsers that your visitors appear to use.
It's a chicken and egg relationship that becomes a vicious circle.
I think actually they specify their desires against a larger
set of statistics. In practice they're doing 90-10% rules of thumb. The first
90% takes half the total development. Somewhere along the path to 100% browser
acceptance is a cut-off point where the additional work cannot be justified.

If a big client rings up our end user saying that something's amiss with his MAC
IE 5.2 then we fix it.
.....

Cross-browser scripts do not have to be complex. Indeed K.I.S.S. is a
very worthwhile design principle to follow.

I agree totally, but their complexity is in the knowledge base that I or any one
else needs to have to get 90, 95 or 100% usability. If I look at any of the web
sites devoted to listing the foibles of the various browsers there are probably
thousands of differences. That is complexity.
The economic relationship is not being meaningfully judged. It is always
going to be relatively expensive to employ someone who doesn't know how
No matter who is employed to do web programming there will be bugs. The cost of
an expert such as yourself may not be low enough to justify the additional 4% of
browsers that might be supportable. The testing costs alone of supporting an
additional 30 browsers would be considerable.

The mechanic argument is relevant. Average cars are now a job for specialists only.

Differentiation is not in the interests of JS programmers; we are not
masochists. We are working without the certainty of a known environment,
I believe earlier you said that companies should employ best qualified people.
You assert as well that we can support cleanly all browsers. The conclusion is
obvious. Differentiation certainly benefits expert js programmers. I assume they
are masochists only if they really believe it's desirable to support 30-50
platforms.

Richard.

--
Robin Becker
Jul 23 '05 #11
Robin Becker wrote:
Richard Cornford wrote: <snip>
Which explains you log statistics, you design for a limited set of
browsers/configurations, the users of other browsers/configurations
don't hang around clocking up log entries (because they rapidly
realise they are wasting their time), and then you use the log
entries to justify designing for the browsers that your visitors
appear to use. It's a chicken and egg relationship that becomes a
vicious circle.


I think actually they specify their desires against a larger
set of statistics. In practice they're doing 90-10% rules of thumb.
The first 90% takes half the total development. Somewhere along the
path to 100% browser acceptance is a cut-off point where the
additional work cannot be justified.

If a big client rings up our end user saying that something's amiss
with his MAC IE 5.2 then we fix it.


And the big potential client using Mac IE 5.2 (or Safari)? Doesn't
he/she go and look elsewhere?
Cross-browser scripts do not have to be complex. Indeed K.I.S.S. is a
very worthwhile design principle to follow.


I agree totally, but their complexity is in the knowledge base that I
or any one else needs to have to get 90, 95 or 100% usability. If I
look at any of the web sites devoted to listing the foibles of the
various browsers there are probably thousands of differences. That is
complexity.


You are looking at the details and missing the design issue. For any
script there are just two possibilities, the browser fully supports the
features required by the script, or it doesn't (with all javascript
incapable browsers falling into the latter category). To support 100% of
browsers (without even knowing anything about all of those browsers) it
is only necessary to design the HTML so it makes sense when the script
fails and write the script so the it detects the availability of the
features that it needs prior to attempting to use them and only acts
when they have been verified as being available.

That simple design pattern covers 100% of browsers from the outset, the
work is in maximising the number of browsers that fall into the
supporting category for each individual script. But now it doesn't
matter if script development cannot push that past 90% of javascript
capable browsers because the remaining 10% are still supported by the
site (along with all javascript incapable browsers) as the underlying
HTML makes sense without the script.
The economic relationship is not being meaningfully judged. It is
always going to be relatively expensive to employ someone who
doesn't know how


No matter who is employed to do web programming there will be bugs.
The cost of
an expert such as yourself may not be low enough to justify the
additional 4% of browsers that might be supportable.


Where does 4% come form? The most often quoted figure for javascript
disabled/incapable browsers is 8-12% (so the javascript capable browsers
that lack the required features would be on top of that).

And it would be a mistake to assume that any expertise in browser
scripting carries a premium, it doesn't. Most of the IT world regard
javascript as a toy language that any fool can write (and are usually
happy to assign the task to the nearest fool available, with the
consequences that we observe on the Internet).

But the numbers game is a little more complex than just getting back the
potential customers lost through failing to support their browsers. Lets
say that is 5%, and lets say that 20 competitors are doing the same and
turning away 5% of their potential customers as well (and they are). Now
the first of those sites to welcome all customers regardless of their
browser is not just regaining the 5% they had been turning away but is
potentially picking up the 5% that each of those competitors is still
turning away (5*20 == 100).

Coincidentally, I have just been reading an article reporting a
£50,000.00 out of court settlement of a case brought using the UK
disability discrimination act against a web site for denying access to
its services to the users of the types of browsers/browser
configurations favoured by some groups covered by that act.
The testing costs alone of supporting an
additional 30 browsers would be considerable.

The mechanic argument is relevant. Average cars are now a job for
specialists only.
Which is why it makes sense to hire a suitable specialist to do the job.
Differentiation is not in the interests of JS programmers; we are not
masochists. We are working without the certainty of a known
environment,


I believe earlier you said that companies should employ best
qualified people.


Suitably qualified will do.
You assert as well that we can support cleanly all browsers.
Absolutely.
The conclusion is obvious. Differentiation certainly
benefits expert js programmers.
Differentiation might necessitate browser scripting expertise, but you
won't find many javascript programmers who wouldn't have preferred
complete standardisation of browsers from the outset. Unfortunately we
have to deal with the world as it is rather than as we would like it to
be, and at lest the resulting design challenge is a worthy application
for the intellect.
I assume they are masochists only if they really believe
it's desirable to support 30-50 platforms.


There are something in the order of 130 existing web browsers, and new
ones all the time.

Richard.
Jul 23 '05 #12
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote:
That simple design pattern covers 100% of browsers from the outset, the
work is in maximising the number of browsers that fall into the
supporting category for each individual script. But now it doesn't
matter if script development cannot push that past 90% of javascript
capable browsers because the remaining 10% are still supported by the
site (along with all javascript incapable browsers) as the underlying
HTML makes sense without the script.


Richard, you write novels on this group every day, but I've never seen
real-world examples of your work, or a web site of the libraries you've
written, or anything. Do you have anything?

I mean, if you actually have time to write all the stuff you do here every
day, and create great reusable code to the standards you push, and put that
into practice in a real-world setting with a project manager hounding you
and clients making ridiculous requests, then more power to you. I'd like to
see the results. I mean, is it all talk and wishful thinking, or do you
actually manage to practice what you preach? The real world is not always as
ideal as you make it sound :)

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/
Jul 23 '05 #13
optimistx wrote:
What about this strategy:

Project1. Construct the application with pure html, no
javascript. Cost is C1, calendar time T1

Project2. When the project P1 has been completed, everything
is working well, customers are satisfied, boss is happy,
make a new proposal to the management .

Probaly cost C2 is about the same order of magnitude as
C1, and the duration T2 about the same as T1.
You haven't actually stated what Project 2 is, which makes judging what
it would cost and how long it would take extremely speculative.

If it is a complete replacement for Project 1 then it probably will cost
much the same (aided only by the fact that the back-end programmers will
be able to lift most of the logic directly from Project 1). But that
also renders much of the cost of Project 1 wasted.

If it is a layering of client-side scripting over Project 1 then there
is no reason to expect it to be nearly as expensive or time consuming.
Granted if your proposed design strategy is to be taken literally and
Project 1 has been implemented with no consideration of it's suitability
for client-side manipulation the results will be more expensive and time
consuming than they need to be.

The best of both worlds would be most effectively achieved by planning
for the layering of client-side scripting over a 100% reliable
server-side fall-back from the outset, but then you don't have two
projects any more, and most of the design work for what was project 2
now happens in parallel with the designing of the back-end.

Or were you thinking in terms of that stupid "lets deal with disabled
users by having two web sites, one with the full presentation and a text
only version for anyone who can't use the first", with its consequent
ongoing maintenance burden, and the eventual divergence of the content
as the text version gets a low priority and is eventually forgotten.
Which advantages can I show to the management in order to
persuade to accept project P2?

a) some seconds in access speeds sometimes ? (when
checking form input, mainly).
If that is the only client-side functionality then your cost estimate is
way over the top. At this stage the validation algorithms have been
specified and Project 1 already contains a reference implementation (and
if the back-end was in JScript ASP the validation can virtually be cut
and pasted into the client-side).
b) some frills, whistles, bells, which are completely
unnecessary and even annoying for a serious customer?

<snip>

A strange thing with management (especially marketing management) is
that they are the ones who wanted those bells and whistles in the first
place.

In practice any new project will probably start form the position of an
existing site that is already dependent on a limited range of javascript
capable browsers, and has no shortage of bells and whistles that
somebody in the decision making process thought were a good idea. If
they are going to fund a replacement they are going to want it to be
just as capable as its predecessor was.

So the question is, can a replacement be designed that exploits the
capabilities of the browsers that the old version directly supported to
the same (or greater) extent and still be 100% usable and reliable for
the users of any other browsers browser (or unusual configuration of
those browsers)?

And the answer is yes, they can have just as much dynamic front end
stuff on at least as many browsers as it ever worked with, and they can
have 100% reliability for all through back-end fall-back, and they can
have it all in the same site. With the resulting maximised customer base
(and potential to avoid falling foul of national accessibility
legislation, where applicable).

Richard.
Jul 23 '05 #14
Matt Kruse wrote:
<snip>
Richard, you write novels on this group every day,
The hour a day for two months I spent training myself to touch type has
proved one of the most productive things I have ever done over the
intervening years.

But are you complaining? What sort of discussion form would c.l.j. be if
everyone followed your example and contributed no more than references
to dubious javascript libraries? That is hardly going to contribute to
anyone's understanding and skills, a more universally functional
Internet, or the already tarnished reputation of javascript.
but I've never seen
real-world examples of your work,
If you are failing to find examples of scripts written by me that
demonstrate the application of the principles under discussion here then
I don't think you can be trying very hard.
or a web site of the libraries you've
written, or anything.
Didn't I write one of those novels explaining to you why libraries are
in inappropriate concept for Internet browser scripting?
Do you have anything?
In what sense?
I mean, if you actually have time to write all the stuff you do here
every day, and create great reusable code to the standards you push,
and put that into practice in a real-world setting with a project
manager hounding you and clients making ridiculous requests, then
more power to you. I'd like to see the results. I mean, is it all
talk and wishful thinking, or do you actually manage to practice what
you preach? The real world is not always as ideal as you make it
sound :)


Why do you think that would have any baring? It either is possible to
create scripts that match their execution to the browser's ability to
support them, and cleanly degrade to viable underlying HTML when not
supported, avoiding introducing a dependency on client-side scripting
into a system that is otherwise 100% reliable, or it is not.

As it has been demonstrated that it in fact is possible to create
scripts to that standard it makes sense that this group should promote
that standard and disseminate an understanding of the techniques needed
to achieve it. Particularly baring in mind that on the occasions that a
particular proposed action is identified as not amenable to satisfactory
clean degradation the javascript dependent alternatives are always
demonstrably worse, as anyone viewing any page employing any of your
libraries with a javascript disabled browsers would rapidly discover.

Richard.
Jul 23 '05 #15
Richard Cornford wrote:
I don't think we have to reply!
--
Robin Becker
Jul 23 '05 #16
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote:
But are you complaining? What sort of discussion form would c.l.j. be if
everyone followed your example and contributed no more than references
to dubious javascript libraries?
Dubious? Any specific criticisms are welcome.

There are various types of discussions on this group. One type is "Is there
a solution for X?" in which case I post my solution if I have one. My code
is fairly well-tested by thousands of users, and I get many thanks from
users of this group for directing them to a solution they can immediately
implement with success, rather than preaching about why they shouldn't be
doing what they need to do.
That is hardly going to contribute to
anyone's understanding and skills, a more universally functional
Internet, or the already tarnished reputation of javascript.
I disagree. There is a lot to be learned by using and inspecting pre-written
libraries which solve the exact problem you are facing.
If you are failing to find examples of scripts written by me that
demonstrate the application of the principles under discussion here then
I don't think you can be trying very hard.
A search for "Richard Cornford" +javascript returns few results :)
And IMO, snippets of example code are useful and great for discussing the
finer points of the language and its use, but they aren't solutions.
Writing small snippets to do very specific low-level tasks is one thing, but
writing solutions which solve real problems on real web sites using a wide
range of browsers and supporting features that would be needed by a wide
range of users is quite another.

In many cases, the "right way to do things" simply doesn't work in
real-world situations, because of browser bugs and quirks, or because it's
not generalized enough to be widely useful.
Didn't I write one of those novels explaining to you why libraries are
in inappropriate concept for Internet browser scripting?
Yes, and I still think you represent about 2% of javascript developers with
that opinion :)
Do you have anything?

In what sense?


An example. A finished product. I'm not being facetious. I've learned from
your posts and your articles, and I would find it interesting to see a
finished site which degraded nicely for all browsers and implemented complex
functionality in the ways that you recommend. Or multiple sites.
It either is possible to
create scripts that match their execution to the browser's ability to
support them, and cleanly degrade to viable underlying HTML when not
supported, avoiding introducing a dependency on client-side scripting
into a system that is otherwise 100% reliable, or it is not.
And in any given situation, it's either worth the effort, or it is not.
Just because something can be done perfectly doesn't mean it justifies the
time or expense to do so. The 80/20 rule.
If everyone waited for perfect solutions before releasing software, we would
never have any software!
As it has been demonstrated that it in fact is possible to create
scripts to that standard it makes sense that this group should promote
that standard and disseminate an understanding of the techniques needed
to achieve it.
I think it's always best to promote the best solution to any given problem.
But a bunch of "code-perfect" snippets still require subtantial effort and
knowledge to assemble into a working solution. If someone comes here with a
question about how to achieve X, we can either point out 25 ways to code
correctly and write clean code which degrades perfectly and leave them with
nothing but pieces to glue together, or we can offer them a packaged
solution which will solve their problem in 10 minutes with 5 lines of code.
I prefer the latter, which they can dig into and learn from.
Particularly baring in mind that on the occasions that a
particular proposed action is identified as not amenable to satisfactory
clean degradation the javascript dependent alternatives are always
demonstrably worse, as anyone viewing any page employing any of your
libraries with a javascript disabled browsers would rapidly discover.


Anyone viewing my pages containing _javascript libraries_ without javascript
enabled is surely missing the point, and I don't care if the page is broken
for them. I have a limited amount of time in my day, and I can't cater to
everyone, nor do I try :)

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/

Jul 23 '05 #17
On Thu, 15 Apr 2004 20:12:22 +0300, "optimistx"
<op*************@hotmail.com> wrote:
Project1. Construct the application with pure html, no javascript. Cost is
C1, calendar time T1

Project2. When the project P1 has been completed, everything is working
well, customers are satisfied, boss is happy,
make a new proposal to the management .

Probaly cost C2 is about the same order of magnitude as C1, and the duration
T2 about the same as T1.

Which advantages can I show to the management in order to persuade to accept
project P2?
User experience, get the management out of the office (or use their
GPRS connection or something back to the system, and they'll see how
long each page navigation takes, see how long each stupid mistake on a
form takes, and how much server resources are used (make sure you do
it on a roaming GPRS at 10 GBP per MB)

Get some test users in - the tea lady, the pizza delivery guy,
whoever, show how frustating and how many mistakes the users make as
they're not getting enough help, or the navigation is
counter-intuitive etc.

Show them how good JS can improve all those situations, resulting in
more sales or whatever
The future for me as an enthusiastic javascript programmer does not look
very bright, if this is true. Toy language, amusement park for teenagers?


Nope, there's money in JS, it's what I do for a crust.

Also remember we're in a particularly boring time of web-authoring,
there's been nothing new in ages. However XBL * is a very nice
looking technology and that relies on javascript to do anything
interesting, and who knows even XHTML 2.0 might have something
interesting?

Jim.

* The forthcoming W3 version, not the orginal Mozilla one.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #18
On Fri, 16 Apr 2004 17:52:21 -0500, "Matt Kruse"
<ne********@mattkruse.com> wrote:
Didn't I write one of those novels explaining to you why libraries are
in inappropriate concept for Internet browser scripting?


Yes, and I still think you represent about 2% of javascript developers with
that opinion :)


None of the large commercial projects I've worked on use libraries,
yet many are in the thousands of lines of JS situation. Even the ones
where I've had no input at all to the system design.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #19
Matt Kruse wrote:
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote:
But are you complaining? What sort of discussion form would c.l.j.
be if everyone followed your example and contributed no more than
references to dubious javascript libraries?
Dubious? Any specific criticisms are welcome.


What would be the point of enumerating the many specific implementation
flaws in your code when you refuse to even recognise the fundamental
design flaw?

<snip>
That is hardly going to contribute to
anyone's understanding and skills, a more universally functional
Internet, or the already tarnished reputation of javascript.


I disagree. There is a lot to be learned by using and inspecting
pre-written libraries which solve the exact problem you are facing.


There may be something to be learnt about language use, or the
employment of DOM features, but there won't be much to be learnt about
script design. But then you argue that your libraries "solve" the
problem with 10 minutes work, so they may never be subject to
examination by individuals employing them. And an attitude that it is
better to refer people to copy and paste scripts, rather than assisting
them in better understanding the task and its issues, will not assist
them in untangling the code within those libraries.
If you are failing to find examples of scripts written by me that
demonstrate the application of the principles under discussion here
then I don't think you can be trying very hard.


A search for "Richard Cornford" +javascript returns few results :)


That doesn't seem like a search combination calculated to locate code.
And IMO, snippets of example code are useful and great for discussing
the finer points of the language and its use, but they aren't
solutions.
You have a very personal definition of "solution". To my mind a solution
modifies a situation such that there are no problems remaining. In you
definition a solution modifies the problem into something you are willin
g to ignore.
Writing small snippets to do very specific low-level tasks
is one thing,
Encapsulating commonly needed and specific (usually low level) tasks
into efficient small components is a viable way of authoring re-usable
code. The individual components are not a solution to anything (except
not having to worry about how that particular aspect of the larger
problems is going to be handled), but they are the building blocks of
larger applications. And once any individual component has been
rigorously tested in isolation its behaviour can be relied upon to
contribute towards the creation of a reliable larger application.

Any sufficiently large collection of such components become the tools
with which anything can be built, and the nearest thing to a library
that is viable with browser scripting. Though such a collection would
never be imported complete into a web page, it would just be the source
form which suitable components were acquired for a specific application.

But there is no point trying to create and distribute such a collection
of components, the individuals using them need to understand what they
do and how they work in order to choose the correct component for any
situation, and employ it effectively. And any author may prefer to
choose a level of abstraction that suited their individual style. It is
also more practical to build such a collection in a response to
requirements, so a new requirement may require the creation of a new
component but, if suitably designed, that component becomes available
for re-use in future similar situations.

To that end the greatest good can be done for the prospective browser
scripter by teaching them to build their own components.
but writing solutions which solve real problems on real web
sites using a wide range of browsers and supporting features that
would be needed by a wide range of users is quite another.
This has no baring. In the development of most things there will be a
stage where viability has been demonstrated (objectively) but no actual
application exists. What sort of progress would be possible if a
demonstration of viability was routinely dismissed because it preceded
its applications?
In many cases, the "right way to do things" simply doesn't work in
real-world situations, because of browser bugs and quirks, or because
it's not generalized enough to be widely useful.
When the "right thing to do" has been demonstrated to be the only way of
handling all browsers (regardless of quirks and bugs) how can that not
be sufficiently general?
Didn't I write one of those novels explaining to you why libraries
are in inappropriate concept for Internet browser scripting?


Yes, and I still think you represent about 2% of javascript
developers with that opinion :)


You do like to throw numbers about don't you. The implication of that
statement is that on the occasions when the suitability of libraries for
use in a browser scripting context has been debated on this group 98% of
the readers of (and participators in) those debates have disagreed with
the proposition that they are unsuitable, but not one of them has
managed to think up a single viable counter argument to post. So if
there is such a widespread belief in the suitability of libraries in
that context then it doesn't appear to have any rational basis.

<snip>
It either is possible to
create scripts that match their execution to the browser's ability to
support them, and cleanly degrade to viable underlying HTML when not
supported, avoiding introducing a dependency on client-side scripting
into a system that is otherwise 100% reliable, or it is not.


And in any given situation, it's either worth the effort, or it is
not.


That is a running theme in these discussions, the people who can't do it
believe that there is more effort involved, the people who can do it
don't see much difference. But the latter group must be better qualified
to judge.
Just because something can be done perfectly doesn't mean it
justifies the time or expense to do so.
And if there is no significant difference in time or expense?
The 80/20 rule.
And last week we were discussing the consequences of needlessly
designing out 5% of turnover.

But who's 80/20 rule is this? What does it actually state? Do your
commercial clients know that, as a software developer, you feel entitled
to design them out of up to 20% of their turnover based on some spurious
"rule" when that is demonstrably avoidable?
If everyone waited for perfect solutions before releasing software,
we would never have any software!
Software houses seem very interested in maximising the reliability of
their output. Running QA departments, investigating in and implementing
design, testing and project management practices intended to minimise
problems, and rapidly identify and rectify any that remain. They care
very much that what they release is of the highest achievable quality,
if they could identify perfection prior to releasing software then they
would. QA is there specifically to identify things that need to be fixed
prior to relaese.
As it has been demonstrated that it in fact is possible to create
scripts to that standard it makes sense that this group should
promote that standard and disseminate an understanding of the
techniques needed to achieve it.


I think it's always best to promote the best solution to any given
problem. But a bunch of "code-perfect" snippets still require
subtantial effort and knowledge to assemble into a working solution.
If someone comes here with a question about how to achieve X, we can
either point out 25 ways to code correctly and write clean code which
degrades perfectly and leave them with nothing but pieces to glue
together, or we can offer them a packaged solution which will solve
their problem in 10 minutes with 5 lines of code. I prefer the
latter, which they can dig into and learn from.


Again you are applying your unusual definition of "solution". Take you
table sorting library, someone wants to sort the contents of a table by
clicking on column headers, a common enough desire. You direct them to
your table sorting library and 10 minutes later the have a web page in
which they can sort a table by clicking on the column headers (at least
on the sub-set of javascript capable browsers that fulfil your criteria
of suitability). You would say they have a "solution", they may also say
they have a solution, but what they actually have is a different
problem. Because now they have introduced a javascript dependency that
means no client-side scripting equals no table contents. (They may also
have rendered themselves subject to prosecution under some nation's
accessibility legislation, which may also be considered a problem.)

Now contrast that with the DOM table sorting scripts. OK, they only work
on javascript capable dynamic DOM browsers (but those fall on the
acceptable side of your 80/20 criteria anyway), so they detect the
required dynamic DOM support and only act when it is available, but the
table is defined in the HTML and only manipulated by the script. A worst
case failure may leave the user unable to sort the table (at least on
the client as this process is very amenable to direct server-side
fall-back) but whatever happens the user can still read the contents of
the table. The script provides a useful enhancement to the page, but
does not detract from its usability.

You library solves one problem by introducing another, the DOM version
solves the same problem (to the same criteria of acceptability) but does
not introduce any other problems into the situation.

Indeed the DOM version can be layered over a system that displayed and
sorted tables on the server in a way that enabled it to short-circuit
requests for server-side sorting and do that locally whenever the
browser supported dynamic DOM manipulation. Your library would
necessitate two distinct back end processes to achieve similar
reliability, and the transition to the servers-side backup in the event
of failure on the client side would be less that transparent. It is
maybe the way that the inappropriateness of the fundamental design of
your libraries would require you to jump through hoops to create a
reliable system that is contributing to your impression that creating a
reliable system is difficult, time-consuming and expensive.
Particularly baring in mind that on the occasions that a
particular proposed action is identified as not amenable to
satisfactory clean degradation the javascript dependent alternatives
are always demonstrably worse, as anyone viewing any page employing
any of your libraries with a javascript disabled browsers would
rapidly discover.


Anyone viewing my pages containing _javascript libraries_ without
javascript enabled is surely missing the point,


I would say that visiting a demonstration of any javascript code with a
javascript disabled browser is a very obvious test for the acceptability
of its degradation strategy (though the author may simplify the test
process by providing a means of directly disabling the script without
necessitating the disabling of javascript).
and I don't care if the page is broken
for them. I have a limited amount of time in my
day, and I can't cater to everyone, nor do I try :)


You can cater for everyone, but not caring to try is guaranteed to mean
that you never will.

Richard.
Jul 23 '05 #20
Richard, I believe that you are being intentionally obtuse, so I won't
respond to everything you've written.
I believe we have different views of the world, and maybe both of our views
are correct in their owns ways, I don't know. I do know that I have
thousands of sites who have benefitted from my approach, and thousands of
users who have thanked me or donated money to me. And some emails in
response to this thread and others expressing disgust with your attitude in
this group. So it's clear to me that I'm not nearly as "wrong" you wish to
imply. But I'll address a couple of your points...

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote:
What would be the point of enumerating the many specific implementation
flaws in your code when you refuse to even recognise the fundamental
design flaw?
Obviously the world is black and white to you, either people agree with you
or they are wrong.
But your willingness to write over 100 lines of response, yet not point out
a single technical criticism of code, says to me that you'd rather argue
endlessly and prove your correctness than actually accomplish anything.
That's a bummer.
(and, btw, I certainly never claim that my code is perfect - I'm always
working to improve it, as time permits. In many cases, I already know how to
improve it, I just don't have time to do so.)
And an attitude that it is
better to refer people to copy and paste scripts, rather than assisting
them in better understanding the task and its issues, will not assist
them in untangling the code within those libraries.
Not everyone wants or needs to understand javascript in order to use it.
I don't subscribe to such elitist attitudes.
A search for "Richard Cornford" +javascript returns few results :)

That doesn't seem like a search combination calculated to locate code.


Yet no other suggestions or url's are posted?
Again, you're more interesting in arguing than anything else.
You apparently have no real-world sites or libraries to put forward as
examples of successful implementations of your views?
You have a very personal definition of "solution". To my mind a solution
modifies a situation such that there are no problems remaining.
I think that's a highly flawed definition.
I think a solution accomplishes a goal given a set of requirements.
If supporting non-javascript-enabled browsers isn't a requirement, for
example, then the set of available solutions may change.
Furthermore, I don't think a javascript solution needs to also hold the hand
of the developer and instruct them on how to degrade gracefully, or decide
if they really want to use javascript at all. That's outside the scope of a
javascript library. The user should understand and decide on those issues
before deciding on the javascript solution needed to solve its part.
Encapsulating commonly needed and specific (usually low level) tasks
into efficient small components is a viable way of authoring re-usable
code.
True, but it's also useless by itself, and requires javascript knowledge to
assemble anything that actually accomplishes a goal.
I build small, efficient components also. They exist in my libraries. I just
choose to assemble them into larger scripts which solve a bigger problem.
And once any individual component has been
rigorously tested in isolation its behaviour can be relied upon to
contribute towards the creation of a reliable larger application.
Exactly. And that's the purpose of a library of functions, of course.
But, you hate libraries. You want to re-write everything all the time.
It is
also more practical to build such a collection in a response to
requirements
There are some requirements which are very basic and very common. Creating
libraries for these functions is very practical.

For example, having a "popup date picker" for a date input field is a common
requirement. Yet, it's a pretty complex task to actually implement. Why
would a person who is not interesting in learning or writing javascript
build it from scratch with low-level components, rather than using a
pre-packaged solution like mine or others?

Even though the size of my library is nearly 35k, it provides a lot of
functionality out-of-the-box. Most people can have it working very quickly,
have all the features they need, and have all major browsers supported, with
very little effort. If used in many pages, it's probably cached anyway, so
it wouldn't impact speed much at all.

If they built it from scratch to have the same functionality as you would
propose, they may spend 50 or more hours of coding and testing, and spend a
large amount of money to get exactly the same result - or something that
isn't as complete without them even realizing it.

To me, the first option is clearly superior for _most_ people.
Again you are applying your unusual definition of "solution". Take you
table sorting library...
Well, you can certainly find flaws in that library given the current state
of web browsers. I've debated about whether to leave it up there anymore,
but I do still find people who need it, so I've left it up.

It was written way back when 4.x was the most current Netscape browser, and
using DOM methods wasn't even an option yet. Way back then, if you wanted
client-side table sorting, it was a tough, tricky thing to implement.
_Especially_ if you wanted to support Netscape 4. Can you point me to
another client-side table-sorting script which supports Netscape4? They
might exist, but they are rare indeed.

That specific library exists for people writing web apps where javascript is
enabled, and users might be using Netscape 4. Believe it or not, that
situation exists more than any of us would like! And for developers in this
situation, looking for a client-side table sorting script, my library offers
a very unique and functional solution for them, when writing it from scratch
might cost them considerable time and cost.
Now contrast that with the DOM table sorting scripts. OK, they only work
on javascript capable dynamic DOM browsers (but those fall on the
acceptable side of your 80/20 criteria anyway)
In a wide-open internet situation, perhaps.
I recently had an email exchange with a user whose client still had
Netscape4.78 as their standard browser. All of your fancy DOM stuff simply
didn't apply to him at all, and he was thankful that there were solutions
out there that still supported ancient browsers. Clearly, not all peoples'
requirements are as simple as you would like to believe.
You library solves one problem by introducing another, the DOM version
solves the same problem (to the same criteria of acceptability) but does
not introduce any other problems into the situation.
I certainly understand your point. Look at my dhtml tree:
http://www.mattkruse.com/javascript/mktree/
That's an approach to adding javascript functionality to plain html content,
and I love the idea quite a bit. But it simply doesn't work in all
situations.
maybe the way that the inappropriateness of the fundamental design of
your libraries would require you to jump through hoops to create a
reliable system that is contributing to your impression that creating a
reliable system is difficult, time-consuming and expensive.
No, I understand exactly what you're saying, and I've done plenty of things
implemented in the ways you describe. However, NOT ALL SITUATIONS ARE THE
SAME, despite your insistence that everything fit into your pre-defined box.
I would say that visiting a demonstration of any javascript code with a
javascript disabled browser is a very obvious test for the acceptability
of its degradation strategy
Degredation strategy is up the person implementing the library, not up to
the library itself.
You can cater for everyone, but not caring to try is guaranteed to mean
that you never will.


You are very wrong, sir Richard.
It means that I have 24 hours in a day, and I use them in the ways that are
most beneficial to users of my code, and profitable to me.
If that doesn't please YOU, I simply do not care. :)

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/
Jul 23 '05 #21
Jim Witte <js*****@spam.bloomington.nospam.in.spam.us> wrote in message news:<c5**********@hood.uits.indiana.edu>...
What do people feel about this statement: "JS exists in so many
flavours across so many browsers (and across the html/xhtml/xml divides)
that it is becoming undesirable to include any on a site."

Jim


When talking about the main browsers, IE5.5sp2+ and Mozilla 1.1+ are
quite similar browsers that are capable of handling similar JavaScript
Needs as long as you use the standard compliant Mozilla as your
development bed. With all the other browsers (non-IE and non-moz), you
can set up the pages to have less features to ensure minimal errors to
users.

Mozilla is an awesome development platform. And as long as you follow
the standards, all of your code should work in IE with mild x-browser
tweaking. The biggest problem for JS developers is that they learn the
"simplified" black hole methods offered in IE and ignore the standard
based methods in Mozilla (document.all[] vs
document.getElementById()). They then end up banging their heads on
all cases where they entered IE black holes and need to re-think most
of their code.

If the other (Non IE) browsers don't follow compatiblity with
Mozilla's compatibilities, then too bad give those users less
features.

Mozilla and IE will be the dominant browsers in the future with the
preceeding gaining ground by the hour.
Jul 23 '05 #22
Matt Kruse wrote:
Richard, I believe that you are being intentionally obtuse, so I won't
respond to everything you've written.
I believe we have different views of the world, and maybe both of our views
are correct in their owns ways, I don't know. I do know that I have
thousands of sites who have benefitted from my approach, and thousands of
users who have thanked me or donated money to me. And some emails in
response to this thread and others expressing disgust with your attitude in
this group. So it's clear to me that I'm not nearly as "wrong" you wish to
imply. But I'll address a couple of your points...

I need to play the devil's side for a bit. I once developed a full
corporate site using the JSAPI library set, which seemed pretty cool at
the time. Everything looked really great... until we posted to the
public server. I cannot tell you how many complaints I got from people
about "I cant see page X", "I cannot see the text in the third column of
page Y", "My Browser locks up when I click on Z".

There was not much I could do, aside from debugging the libraries. At
the time, that was out of scope, and JSAPI had no plans to support IE 6,
in which my pages would not load at all. It was a real mess.

I got so frustrated, that when I did a page redesign, we decided that we
would no longer use something like a JS library. Any scripting would be
done by us, and we would do as much standardization on the server side
(using PHP includes).

I feel real confident with the new site design. I was left feeling that
the concept of a JS library is great in theory, but slow, buggy and
unreliable in practice.

I am not saying "All Libraries are bad". I am saying that I dont think
they are necessarially a good solution in most situations... which
brings me to the next point I feel I need to chime in on...
You have a very personal definition of "solution". To my mind a solution
modifies a situation such that there are no problems remaining.

I think that's a highly flawed definition.
I think a solution accomplishes a goal given a set of requirements.
If supporting non-javascript-enabled browsers isn't a requirement, for
example, then the set of available solutions may change.
Furthermore, I don't think a javascript solution needs to also hold the hand
of the developer and instruct them on how to degrade gracefully, or decide
if they really want to use javascript at all. That's outside the scope of a
javascript library. The user should understand and decide on those issues
before deciding on the javascript solution needed to solve its part.


Boom! Hit it right on the head. To say that "a solution modifies a
situation such that there are no problems remaining" is incorrect. A
perfect, or complete solution makes it so there are no problems
remaining. This is very, VERY rarely the case in software development.

A solution is something that meets the requiements.

A good solution is something that meets the requiements, has a solid
design, facilitates reuse, is maintainable, runs effiently, and has a
solid user interface. ( I know there are more attributes, but you get
my point)

A perfect solution "modifies a situation such that there are no problems
remaining."

It is, indeed, an ivory tower concept to believe that a perfect solution
exists, without writing all components of a solution with the end goal
in mind.

Brian
Jul 23 '05 #23
"Matt Kruse" wrote:
<snip>
... . I do know that I have thousands of sites who have
benefitted from my approach, and thousands of users who
have thanked me or donated money to me.
Hmm, and maybe it is that donated money that motivates you to direct
anyone with an even vaguely related problem to one of your libraries and
to deprecate the people proposing alternative design strategies and
generally authoring javascript to standards suitable for the Internet.
Because you scripts do not approach those standards the implication that
they are not suited to Internet use would, if widely accepted, directly
impact on your revenue stream.

I can understand how financial self interest can motivate you to argue
against people promoting best practices in web authoring in the way that
you do. On the other hand, the most valuable contributors to the group
are not even asking for anything in return, just trying to contribute to
a generally better application of javascript, and on a purely voluntary
basis. My general experience is that you are most likely to hear what
you need to know from someone who has nothing to gain from telling you.
And some emails in response to this thread and others
expressing disgust with your attitude in this group.
So it's clear to me that I'm not nearly as "wrong" you wish to
imply.
A hearsay straw pole of people whose javascript authoring abilities
leaves them feeling unqualified to comment to the group directly.
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote:
What would be the point of enumerating the many specific
implementation flaws in your code when you refuse to even
recognise the fundamental design flaw?
Obviously the world is black and white to you,
either people agree with you or they are wrong.


It probably comforts you to think that. In practice I am a believer in
reasoned argument as a route to decision making. I can be convinced by a
valid counter argument, and have been (as could be verified through
google as I have engaged in many public debates on newsgroups). And the
fact that my opinions have chanced over time stands witness to an
absence of mental rigidity on my part.
But your willingness to write over 100 lines of response, yet
not point out a single technical criticism of code,
What would be the point, if I spend my time enumerating the problems,
and you spend your time correcting them, what is the result? A bad
concept well implemented; really just a waste of both of our efforts.
You may not see it yet but in the long run my time is better spent
encouraging you to see the design issue.
says to me that you'd rather argue endlessly and prove
your correctness than actually accomplish anything.
Considering the validity of your counter arguments, and responding to
them, is progressing the debate. It accomplishes a better understanding
of the argument.

<snip> Not everyone wants or needs to understand javascript in order
to use it. I don't subscribe to such elitist attitudes.
So you actively oppose others attempting to promote an understanding of
the language and the issues related to its application? Well you may
have a motivation for adopting that position, but what is
comp.lang.javascript for if not that? A vending machine for cut and
paste scripts?

<snip>
You have a very personal definition of "solution". To my mind a solution modifies a situation such that there are no problems remaining.


I think that's a highly flawed definition.
I think a solution accomplishes a goal given a set of requirements.
If supporting non-javascript-enabled browsers isn't a requirement, for
example, then the set of available solutions may change.


Did anyone ever say that a javascript dependency wouldn't be acceptable
on an Intranet? (Though there are valid arguments for designing Intranet
scripts to Internet standards.) In an Intranet context a "solution" that
introduces a javascript dependency is not necessarily introducing an
alternative problem because it is possible to know in advance that all
of the browsers that will be exposed to the script will be javascript
capable, that is what you get with an Intranet. You can know that there
are no problems remaining it the end result because the javascript
dependence is not a problem.

On the Internet you know in advance that some of the browsers will be
javascript incapable, so you know that javascript will be a problem for
some. That problem is there whether you choose to ignore it or not, and
if its introduction was not necessary that is an important factor in the
assessment of "solutions".
Furthermore, I don't think a javascript solution needs to also hold the hand of the developer and instruct them on how to degrade gracefully, or decide if they really want to use javascript at all. That's outside the scope of a javascript library. The user should understand and decide on those issues before deciding on the javascript solution needed to solve its part.
If the point of a generalised library is to reduce the effort of
developers using it then it fails at that task if it leaves the problem
of deciding when it is necessary to degrade to the developer using it.
The library should, at minimum, be in a position to be queried about its
viability in whatever environment it may find itself, else the developer
using it is left with the need to test the environment themselves to see
if the library is going to be functional. But if the library hasn't been
designed with paths of clean degradation any degradation handling has to
be implemented entirely by the developer, which hardly contributes to
the proposition that library use is convenient and inexpensive. It is
more likely to encourage an attitude in that developer that making
provision for the javascript incapable is more work than it is worth.

There is also your suggestion that the users of such a library don't
need to understand javascript authoring issues. But then you are
expecting these individuals without that understanding to recognise the
contexts in which they should be providing fall-back, how (and what) to
test for those conditions, how to integrate any alternative content and
how to implement the scripts needed to do that.
Encapsulating commonly needed and specific (usually low level) tasks
into efficient small components is a viable way of authoring re-usable code.


True, but it's also useless by itself, and requires javascript
knowledge to assemble anything that actually accomplishes a goal.


Programming and not programming are mutually exclusive. To program
javascript you need javascript knowledge, you also need to understand,
for example, boolean logic. These aren't cruel impositions intended to
keep the uninitiated from scripting web browsers they are just the
obvious fundamental requirements for the task. A desire to program
without learning how to program is at best unrealistic.
I build small, efficient components also. They exist in my libraries. I just choose to assemble them into larger scripts which solve a bigger problem.

Where do you think those small components come from? They initially get
created to handle aspects of bigger problems, once created they get
re-used when another problem needs that same facility.
And once any individual component has been
rigorously tested in isolation its behaviour can be relied upon to
contribute towards the creation of a reliable larger application.


Exactly. And that's the purpose of a library of functions, of course.
But, you hate libraries. You want to re-write everything all the time.


What makes you think I re-write everything. In practice the only part of
a process that I write for most scripts is the application specific
control logic, and the user of any library has no choice but write that
anyway. The difference is that I get to include only the functionality
that is needed by a script, while the user of a library has little
choice but include the entire library for each and every task they want
to use a library for.
It is
also more practical to build such a collection in a response to
requirements


There are some requirements which are very basic and very common.
Creating libraries for these functions is very practical.


And the lower the level of the task the more common it becomes.
For example, having a "popup date picker" for a date input field is a common requirement. Yet, it's a pretty complex task to actually implement.
More complex a task to implement in a truly general way, suddenly you
need to accommodate any possible presentation, any date range, interact
with arbitrary form controls and combinations of forms, deal with any
possible HTML structures and content and so on. Leaving any general
solution bloated with code needed to handle the possibilities, most of
which will not apply to any actual application, and then the general
version may still have overlooked some possibilities (often the subject
of questions on the group).
Why would a person who is not interesting in learning
or writing javascript build it from scratch with low-level
components, rather than using a pre-packaged solution like
mine or others?
Someone not interested in learning or writing javascript is probably
being unrealistic in having a desire to use javascript (and weren't
these the people you just suggested should be capable of identifying and
handling degradation issues for themselves?).

But primary reasons for site specific implementations are the ability to
match the implementation code to the specific situation, maximising
efficiency and minimising the associated download, and the considerably
reduced complexity when clean degradation specific to the situation is
implemented directly in the code used
Even though the size of my library is nearly 35k, it provides a lot of
functionality out-of-the-box. Most people can have it working very quickly, have all the features they need, and have all major browsers supported, with very little effort.
But at the end of that process they have a system that will not work for
all potential users (at least on the Internet) where they could have a
system that is usable by all. Unless they are now going to set about
adding a degradation strategy, which will probably take as much effort
to do reliably as it would have taken to implement as task specific
script with integrated fall-back from the outset.
If used in many pages, it's probably cached anyway, so
it wouldn't impact speed much at all.
Nothing gets cached unless it is downloaded at least once.
If they built it from scratch to have the same functionality as you would propose, they may spend 50 or more hours of coding and testing, and spend a large amount of money to get exactly the same result -
50 hours? Not for someone who knew what they were doing. But the result
wouldn't be exactly the same result, it would be a result tailored to
the situation of its use, potentially with the paths of degradation
designed in from the outset and so requiring no additional work in order
to achieve 100% reliability.
or something that isn't as complete
without them even realizing it.
When completeness exceeds need then it is only contributing to code
bloat.
To me, the first option is clearly superior for _most_ people.
Again you are applying your unusual definition of "solution". Take you table sorting library...
Well, you can certainly find flaws in that library given the current

state of web browsers. I've debated about whether to leave it up there anymore, but I do still find people who need it, so I've left it up.

It was written way back when 4.x was the most current Netscape browser,

I can see that it is accommodating Netscape 4 that results in that
script being the way it is. But table sorting is still easy to fall-back
to server-side sorting so that approach would accommodate Netscape 4's
shortcomings, while the dynamic DOM browsers achieve your 80/20
criteria.

<snip> That specific library exists for people writing web apps where
javascript is enabled, and users might be using Netscape 4. ...

<snip>

That's fine, so long as you make it clear that it would be a poor choice
in any other context.

<snip>
I would say that visiting a demonstration of any javascript code with a javascript disabled browser is a very obvious test for the acceptability of its degradation strategy


Degredation strategy is up the person implementing the library,
not up to the library itself.

<snip>

And you make this requirement of the "person who is not interesting in
learning or writing javascript"? But isn't demonstration of a library an
application of that library? It will still demonstrate its potential for
degradation in that application.

Richard.
Jul 23 '05 #24
Brian Genisio wrote:
<snip>
A perfect solution "modifies a situation such that there are no
problems remaining."

It is, indeed, an ivory tower concept to believe that a perfect
solution exists, ...

<snip>

By any reasonable criteria when no problems remain a solution has been
achieved. The limitation is that it may be so difficult to identify
residual problems that it would be impossible to achieve certainty that
an outcome qualified as a solution.

That problem has a direct parallel in epistemology; it is impossible to
know when something (say a scientific theory) is true. But that doesn't
hinder the growth of knowledge, scientific or technical progress. It
doesn't hinder progress because while truth is an ideal concept and
cannot be attributed to knowledge, not-true can easily be identified. So
progress is achieved by the invention of new ideas and the elimination
of ideas identified as not-true. Resulting in a movement toward truth,
regardless of the theoretically unknowable nature of truth.

A similar state applies to "solution", it may not be possible to be
certain of one when you have it, and it may not actually be practical to
achieve it, but that doesn't prevent it from being a target that can be
moved towards.

An obvious strategy in moving towards an ideal solution would be follow
the logic that allows progress towards truth, identifying and
eliminating anything that qualifies as not-a-solution.

So, in an Internet context, a proposition that removes the original
problem but introduces an alternative problem that was not inherent in
the system is not moving towards the elimination of problems from the
system, it hasn't even reduced the number of problems, just modified
one. Such that proposition can be identified as not-a-solution.

It doesn't matter how idealistic and unachievable (or unknowable) a goal
is if you can tell when you are moving towards it, and that movement is
objectively progress. The elimination of not-true is a movement towards
truth, the elimination of not-a-solution is a movement towards a
solution, and any sufficiently extended sequence of movements
exclusively towards a destination will eventually result in arrival at
that destination [1], even if it is impossible to identify arrival.

Richard.

[1] Zeno would not necessarily have agreed.
Jul 23 '05 #25
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote:
Hmm, and maybe it is that donated money that motivates you to direct
anyone with an even vaguely related problem to one of your libraries and
to deprecate the people proposing alternative design strategies and
generally authoring javascript to standards suitable for the Internet.
I direct people to my code if I have a solution which directly solves their
problem, and gives them example code to inspect if they want to see how it
is done. I certainly do not deprecate people proposing alternatives.
Donations are not a driving force for me. Giving people higher-quality
solutions than are available at most of the cut-n-paste javascript sites is
the motivation, and getting many users of my scripts so that I can improve
them, which also directly benefits me and my private work.
So you actively oppose others attempting to promote an understanding of
the language and the issues related to its application?
Not at all. Ideally, in my mind, a poster would get both a quick answer with
a library or function to solve their requirement, and possibly more posts
which discuss the issue in more detail which they can learn from.
Programming and not programming are mutually exclusive. To program
javascript you need javascript knowledge, you also need to understand,
for example, boolean logic. These aren't cruel impositions intended to
keep the uninitiated from scripting web browsers they are just the
obvious fundamental requirements for the task.
You're confusing "programming" javascript with "using" javascript.
You don't have to know how a car works to drive one, do you?
You don't have to understand the fundamentals of electronics or operating
systems to use a computer, do you?
At some point, the lower levels must be hidden to people operating at higher
levels. I do not think that it's unreasonable to be a web developer and want
javascript functionality without fully understanding everything needed to
make it work. If the javascript coder can sufficiently hide enough from you,
then you just need to deal with an interface, not with the implementation.

A developer can understand enough about javascript to know when it is
appropriate to use it, and how to degrade gracefully in case users don't
have it enabled - but NOT understand it enough to implement a popup div
which is positioned correctly in all browsers (even old ones) and interacts
with the user. There's no reason those details can't be hidden from the
person implementing the library.

For example, if a user wants to have an expandable tree structure, they can
use mine and give their <ul> structure a certain class, and instantly have a
tree implemented. They don't need to know how it works, and they don't need
to have any javascript knowledge. Yet it solves their problem in an elegant
and robust way. In cases where this is possible (obviously not every
situation can be this clean) then this is a great solution for users who
want extended javascript-based functionality, but don't have any programming
knowledge.
Where do you think those small components come from? They initially get
created to handle aspects of bigger problems, once created they get
re-used when another problem needs that same facility.
Do you make these functions available anywhere?
I've long been wanting to get together a solid, robust collection of very
low-level functions that perform certain tasks, which developers can then
either use directly in their pages or incorporate into higher-level scripts.
I don't like the idea of things like full APIs which handle events and
positioning and dhtml and all that - they are too bloated for my tastes.
But, if there was a single function which gave the position of an element,
for example, and it worked in every browser that could possibly be tested,
that would be a very valuable thing to share.

Typically, these low-level functions are re-written by a number of
developers for their own libraries, and very few of them are as complete and
robust as they could be if everyone combined their knowledge and talents.

If you have any ideas about how the users of this group could assemble such
a collection of developer tools, I'd like to hear it.
More complex a task to implement in a truly general way, suddenly you
need to accommodate any possible presentation, any date range, interact
with arbitrary form controls and combinations of forms, deal with any
possible HTML structures and content and so on. Leaving any general
solution bloated with code needed to handle the possibilities, most of
which will not apply to any actual application
Requirements change. Why re-code, when you could have handled the general
cases from the beginning?
Adding an additional 5k to a library to solve a number of general cases is a
_GOOD THING_. IMO.
If they built it from scratch to have the same functionality as you

would propose, they may spend 50 or more hours of coding and testing, and
spend a large amount of money to get exactly the same result -
50 hours? Not for someone who knew what they were doing.


Unless you have implemented a generalized popup date-picker (if you have,
where is it?), I don't think you understand.
I can see that it is accommodating Netscape 4 that results in that
script being the way it is. But table sorting is still easy to fall-back
to server-side sorting so that approach would accommodate Netscape 4's
shortcomings, while the dynamic DOM browsers achieve your 80/20
criteria.


Not when the client says "we use netscape4, and want client-side table
sorting!" :)

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/
Jul 23 '05 #26
Richard Cornford wrote:
Brian Genisio wrote:
<snip>
A perfect solution "modifies a situation such that there are no
problems remaining."

It is, indeed, an ivory tower concept to believe that a perfect
solution exists, ...


<snip>

By any reasonable criteria when no problems remain a solution has been
achieved. The limitation is that it may be so difficult to identify
residual problems that it would be impossible to achieve certainty that
an outcome qualified as a solution.

That problem has a direct parallel in epistemology; it is impossible to
know when something (say a scientific theory) is true. But that doesn't
hinder the growth of knowledge, scientific or technical progress. It
doesn't hinder progress because while truth is an ideal concept and
cannot be attributed to knowledge, not-true can easily be identified. So
progress is achieved by the invention of new ideas and the elimination
of ideas identified as not-true. Resulting in a movement toward truth,
regardless of the theoretically unknowable nature of truth.

A similar state applies to "solution", it may not be possible to be
certain of one when you have it, and it may not actually be practical to
achieve it, but that doesn't prevent it from being a target that can be
moved towards.

An obvious strategy in moving towards an ideal solution would be follow
the logic that allows progress towards truth, identifying and
eliminating anything that qualifies as not-a-solution.

So, in an Internet context, a proposition that removes the original
problem but introduces an alternative problem that was not inherent in
the system is not moving towards the elimination of problems from the
system, it hasn't even reduced the number of problems, just modified
one. Such that proposition can be identified as not-a-solution.


Just because a solution A' to problem A creates another problem B, it
does not mean that A' is not a solution to A. Problem B may be less
significant, and unrelated to problem A. Does this mean that A' is not
a solution to A?

For instance, if Problem A is that "It doesnt Work", and Solution A' is
"Use X method", new problem B might be "It is somewhat slow
(inefficient)".

In this case, Problem B is not a critical problem (as viewed by the
requirements developers), where Problem A is. Now, assume that Solution
A" fixes problem A, and it's new Problem C is solved by C' "An Admin
needs to log in every x hours to do something". Problem C can be
solved, through automation, but a new problem D exists "The system is
complicated, and difficult to maintain".

At this point, the only problem that exists any more, is problem D.
Problem A was solved through A"xC', which is what causes problem D.

I know this is a long and boring example, but I am trying to illustrate
a practice that happens in out-the-door products on a regular basis...
Solving one problem, but creating a smaller, unrelated problem that is
managable.

Ideally, there should be a final solution to A that will be a perfect
solution. This solution may be unrealistic in budget/schedule, and
concessions are made for the A"xC' solution.

Dont get me wrong, I absolutely understand that virtue in speaking
ideally, but I must say that there is a difference between a perfect
solution and a solution. You can talk all the "theory vs proof"
metaphores you want (which I agree with), but in a system like this, a
perfect solution is sometimes practically unatainable. (For example...
having a standards board change something that they dont want to change)

I digress,
Brian
Jul 23 '05 #27
Matt Kruse wrote:
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote:
More complex a task to implement in a truly general way, suddenly you
need to accommodate any possible presentation, any date range, interact
with arbitrary form controls and combinations of forms, deal with any
possible HTML structures and content and so on. Leaving any general
solution bloated with code needed to handle the possibilities, most of
which will not apply to any actual application

Requirements change. Why re-code, when you could have handled the general
cases from the beginning?
Adding an additional 5k to a library to solve a number of general cases is a
_GOOD THING_. IMO.


The only problem I see with that, is that 5K of javascript code in
library form is compiled on the first pass of the JS interpeter, if it
is executed or not. If you are only using one function from that
library, there is a lot of extra processing to include code that is not
being used.

Brian

Jul 23 '05 #28
"Brian Genisio" <Br**********@yahoo.com> wrote:
The only problem I see with that, is that 5K of javascript code in
library form is compiled on the first pass of the JS interpeter, if it
is executed or not. If you are only using one function from that
library, there is a lot of extra processing to include code that is not
being used.


In theory, yes. But I've had pages with over 200k of javascript (literally -
and no, I didn't design them) which executed in 2 seconds. Computers are
very fast. Compiling 5k of javascript takes such little time that it becomes
completely negligible.

I'm not in the crowd of people who optimizes code so that, when executed in
a loop 10,000 times, it performs 1 second faster. I think that kind of
optimization is a huge waste of time, and more of a "fun" exercise in
programming rather than a practical one :)

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/
Jul 23 '05 #29
Matt Kruse wrote:
In theory, yes. But I've had pages with over 200k of javascript
(literally - and no, I didn't design them) which executed in 2
seconds. Computers are very fast. Compiling 5k of javascript
takes such little time that it becomes completely negligible.

This assumes you have a fast computer. I suppose it all depends on your
audience, but the average computer user these days does not have
anything better than a 300 Mhz PC with 64 MB of memory. Many people
have much slower machines yet.
I'm not in the crowd of people who optimizes code so that, when executed in
a loop 10,000 times, it performs 1 second faster. I think that kind of
optimization is a huge waste of time, and more of a "fun" exercise in
programming rather than a practical one :)


Hmmm... maybe you should. By always thinking about efficiency,
optimization is rarely necessary. Of course, 1 second faster seems
silly, but what if is a 1 second improvement from something that takes
1.1 seconds? If you are improving from 2 seconds to 1 second, the
improvement is probably not good enough.

The "fun" exercises you are talking about change the speed by orders of
magnitude (not just linear changes). O(nln) is MUCH faster than O(n^2)
for instance. In the example of 1.1 seconds, versus 0.1 seconds for
10,000 items, what happens if you increase to 20,000 items? You are
likely looking at 2.2 vs 0.2 seconds. We are not talking about being 1
second slower, we are talking about being 1100% slower! And what about
the memory considerations? Memory optimizations are often as important
as speed. What happens if you are using up all of your systems memory?

If you really think that speed optimizations are a huge waste of time,
then you have never written an application of any substance. I would
recommend _ALWAYS_ thinking about the correct algorithm to use for a
given situation. It will become so "second nature" that it will not
take any extra time to implement it. The result: Effiency every time.

I am not talking about theory here... I am not talking about "fun"
exercises. I am talking about real, out-the-door products used by real
customers. Effiency always matters.

Ok, I will get off my high horse... It is just that I get sick of having
to find effiency problems in code after the fact (From me, or from other
developers).

Have a good day,
Brian

Jul 23 '05 #30
"Brian Genisio" <Br**********@yahoo.com> wrote:
This assumes you have a fast computer. I suppose it all depends on your
audience, but the average computer user these days does not have
anything better than a 300 Mhz PC with 64 MB of memory. Many people
have much slower machines yet.
Even still, a difference of 5k in library size is negligible. I have some
200mhz machines here I can test with, I should run some comparisons, just to
see for sure what the difference is.
By always thinking about efficiency,
optimization is rarely necessary.
I agree, and I do consider efficiency (caching objects and references to
objects, etc). My point is, when a script runs fine and there are no
complaints, spending an hour to squeeze out .0001s better speed is not time
well spent.
Of course, 1 second faster seems
silly, but what if is a 1 second improvement from something that takes
1.1 seconds?
Over 10,000 iterations?
That's a speed increase for a single iteration (typical) from .0011 seconds
to .00001 seconds, which is completely unrecognizable. If the code is
actually going to be executed 10,000 times, then that's a different story
(and probably a design flaw ;)

I doubt anything is going to actually be executed 10,000 times in
javascript. If it is, there's probably something wrong. But many people who
I see tweaking for speed increases actually have to run something thousands
of times in a loop to even measure the difference in execution time. If it's
only going to run oncec or twice, and you need to run it 10,000 times to see
a speed increase, then it's not a practical exercise.
If you really think that speed optimizations are a huge waste of time,
then you have never written an application of any substance.
I never say the former, and I certainly have done the latter!
My belief is that speed optimizations are not the best use of a develoepers
time if the speed increase is so small so as to not even be noticed, and if
a block of code needs to be executed 10,000 times in order to notice a 1
second speed increase, then the time spent optimizing could be better spent
somewhere else.
Ok, I will get off my high horse... It is just that I get sick of having
to find effiency problems in code after the fact (From me, or from other
developers).


I'd much rather deal with slightly inefficient code than code that isn't
commented and is poorly designed to begin with. I'll gladly sacrifice .1
seconds of speed in exchange for code clarity :)

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/


Jul 23 '05 #31
Matt Kruse wrote:
If you really think that speed optimizations are a huge waste of time,
then you have never written an application of any substance.

I never say the former, and I certainly have done the latter!
My belief is that speed optimizations are not the best use of a develoepers
time if the speed increase is so small so as to not even be noticed, and if
a block of code needs to be executed 10,000 times in order to notice a 1
second speed increase, then the time spent optimizing could be better spent
somewhere else.


Ok, I thought you were talking globally, as opposed to locally (to
Javascript programming). There are still things you can do in
Javascript to make it faster, but I agree... it is rare to do something
10,000 times.

Of course, in other languages, this type of thing happens all the time.
For instance, the web brower will do this often. Immagine a page with
three frames (4 DOM models in all), and each page is somewhat complex.
Since all attributes are nodes, the node tree can easilly make it to
10,000 items. The tree algorithms must be efficient in this matter.

Database searches... could be billions of times.

Also, when I say 10,000 items, that doesnt mean 10,000 times that code
is run. It means a function being executed on 10,000 items. Though, it
is rare you want to run an algorithm on 10,000 items, and have a worst
case that is better than 10,000 items. (There are not many O(c)
algorithms on n items out there)

In my original post, I was saying that if you make something faster,
from 1.1 seconds to 1.0 seconds, this is not a speed increase. You are
likely only changing a constant in the Big O characterization. If,
instead, you can bring something from 1.1 seconds to 0.1 seconds... now
we're talking. This is likely orders of magnitude faster. More than
just a constant change.

I digress,
Brian

Jul 23 '05 #32
JRS: In article <40**************@yahoo.com>, seen in
news:comp.lang.javascript, Brian Genisio <Br**********@yahoo.com> posted
at Mon, 19 Apr 2004 13:15:03 :
Matt Kruse wrote:

Requirements change. Why re-code, when you could have handled the general
cases from the beginning?
Adding an additional 5k to a library to solve a number of general cases is a
_GOOD THING_. IMO.


The only problem I see with that, is that 5K of javascript code in
library form is compiled on the first pass of the JS interpeter, if it
is executed or not. If you are only using one function from that
library, there is a lot of extra processing to include code that is not
being used.


Those on dial-up or radio links will prefer not to receive an
unnecessary 5K of code.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 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)
Jul 23 '05 #33
"Dr John Stockton" <sp**@merlyn.demon.co.uk> wrote:
Those on dial-up or radio links will prefer not to receive an
unnecessary 5K of code.


They may prefer not to receive an unnecessary 5k of site-wide CSS rules,
too, but do you recommend against using global CSS files? Would you rather
have a separate CSS file for every page on your site, containing only the
definitions required by that page?

hell, there may be HTML pages with 1k of whitespace! Should everyone start
compressing all of their HTML source so as to not send unnecessary
whitespace characters???

If a user objects to an extra 5k of javascript code, they are surely
browsing without images on, and probably have javascript turned off to begin
with.

It's kind of a ridiculous argument you're trying to make, isn't it?

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/
Jul 23 '05 #34
Matt Kruse wrote:
<snip>
Programming and not programming are mutually exclusive. To program
javascript you need javascript knowledge, you also need to
understand, for example, boolean logic. These aren't cruel
impositions intended to keep the uninitiated from scripting web
browsers they are just the obvious fundamental requirements for the
task.
You're confusing "programming" javascript with "using" javascript.


Javascript is a programming language, using javascript is programming.
Using a program written in javascript is might be considered distinct,
but there aren't that many programs written in javascript that can be
used without writing at least some additional code to control them.
You don't have to know how a car works to drive one, do you?
You cannot drive a car and know nothing about how it works, such as the
fact that it consumes fuel, oil, water, etc, as it operates. Where
understanding how they actually work becomes most valuable is when they
stop working properly.
You don't have to understand the fundamentals of electronics or
operating systems to use a computer, do you?
I have met one or two people who use computers without any understanding
of how they work. They seem to operate on the basis of inventing their
own superstitions about what the computer is doing; it isn't an approach
that allows them to be very productive.

<snip> I do not think that it's unreasonable to be a web
developer and want javascript functionality without fully
understanding everything needed to make it work.
A web developer should understand the issues surrounding the use of
javascript prior to using it, and consider those issues when specifying
3rd party scripts to be used. And if they intend to create javascript
themselves then the are trying to be a programmer and should expect to
have to acquire suitable understanding.
If the javascript coder can
sufficiently hide enough from you, then you just need to
deal with an interface, not with the implementation.
That would depend a lot on the interface. It is certainly possible for
an HTML author to create a suitable HTML structure, give it an ID and
then pass that ID as a string parameter to a javascript function that
then handles everything else, including the degradation (as that would
be just not acting, leaving the HTML unmodified in the page). Such a
script could be used by someone with no javascript knowledge, just clear
documentation, and would be well suited to situations where a javascript
author was writing scripts to be used by HTML and server script writing
colleges who needed to do as little work as possible to deploy their
scripts.

On the other hand, a library providing an interface as an API (or
requiring complex configuration details in the form of javascript
structures) needs considerably more understanding to be usefully
employed.
A developer can understand enough about javascript to know when it is
appropriate to use it, and how to degrade gracefully in case users
don't have it enabled - but NOT understand it enough to implement a
popup div which is positioned correctly in all browsers (even old
ones) and interacts with the user.
How would it be possible for a developer to not know enough to be able
to position a DIV and also know enough to be able to respond usefully
when a browser was not going to be able to position a DIV?
There's no reason those details
can't be hidden from the person implementing the library.
They could be, a script can be inherently cleanly degrading (by
manipulating structures defined in the HTML and not acting on browsers
that cannot support it), and a library could be written to flag its
inability to act usefully (or be queried on the subject) , though that
still leaves the person employing such a library with the problem of
doing something useful in respons.
For example, if a user wants to have an expandable tree structure,
they can use mine and give their <ul> structure a certain class, and
instantly have a tree implemented. They don't need to know how it
works, and they don't need to have any javascript knowledge. Yet it
solves their problem in an elegant and robust way.
Because that script is based on CSS and manipulating HTML defined
structures it is relatively robust. It is the type of script that is
easy to employ without much understanding of its mechanism. It is also
the type of script that is easy to cleanly degrade, because the list is
in the HTML and the script could detect browser support for the required
features and not act whenever they are not available. It does not
introduce a dependency on javascript.

However, I would not describe your implementation as cleanly degrading
because its response to some unsupporting environment may be to error
out (lacking much in the way of feature detecting), fortunately before
it has done anything to the HTML it is acting on so the page would
remain usable. The worst it will do is show the user an error message
(generally not considered a good thing in itself).

<snip> Do you make these functions available anywhere?
Some.

<snip> ... . But, if there was a single function which
gave the position of an element, for example, and it worked in every
browser that could possibly be tested, that would be a very valuable
thing to share.
Some browsers do not make any element positioning information available
(except maybe the old Netscape 4 info for A, IMG and layers), so a good
element position interface would also have to be able to signal its
inability to provide useful information.

But you still would not want a general method because a general method
might have to take into account possibilities such as an element being
contained within a scrolling DIV that was scrolled to some extent at the
time. That is a lot of extra work in doing the calculations, but would
not apply in most situations. A range of methods would be better, so the
one best suited to the situation of its use could be used.

<snip> If you have any ideas about how the users of this group could
assemble such a collection of developer tools, I'd like to hear it.
When contributors to this group provide detailed explanations, or
examples of cross browser scripts they often feature components that
could be usefully employed in broader contexts. Any sufficiently regular
reader of the group will be exposed to pretty much everything they are
likely to need (and then there are the archives).
More complex a task to implement in a truly general way, suddenly you
need to accommodate any possible presentation, any date range,
interact with arbitrary form controls and combinations of forms,
deal with any possible HTML structures and content and so on.
Leaving any general solution bloated with code needed to handle the
possibilities, most of which will not apply to any actual application


Requirements change.
Why re-code, when you could have handled the
general cases from the beginning?


Requirements can change, but they may not, so equally: why code for the
generality when you have a specification to work from?

But in practice a changed requirement would only necessitate changing
parts of a script, probably just replacing a couple of functions (and
maybe just swapping them for others that already exist, maybe with a
little modification to suite).
Adding an additional 5k to a library to solve a number of
general cases is a _GOOD THING_. IMO.


As I said before, you have a theoretical 80k maximum window in which to
serve a page, preferably nearer 40. Every chink taken needlessly in
script is eating away at the user's willingness to wait. 5k may not
sound like much, if the difference between covering all of the potential
for changes in requirements can be accommodated in 5k, and it may not
swing the balance in itself, but it could be 5k better spent.
If they built it from scratch to have the same functionality
as you would propose, they may spend 50 or more hours of
coding and testing, and spend a large amount of money to
get exactly the same result

50 hours? Not for someone who knew what they were doing.


Unless you have implemented a generalized popup date-picker (if you
have, where is it?), I don't think you understand.

<snip>

What is this about? I explain to you why I don't think libraries are
suited to browser scripting and you ask me where you can find libraries
that I have written. I explain to you why I don't think broad
generalised scripts are suited to browser scripting, but apparently I
cannot "understand" unless I have spent my time doing something that my
experience tells me is a fundamentally flawed approach.

OK, if you wanted a script that could interact with all of the various
types and combinations of form control to which a date selection
mechanism could be applied then maybe it would take 50 hours (there are
a lot of possibilities to cover). But in reality reasonable site design
would use a consistent style of form control (or control combination)
for the entering of dates wherever it was required (it would be bad UI
design to do otherwise), making accommodating all of the possible
permutations pointless and certainly reducing the task to considerably
less that 50 hours.

Richard.
Jul 23 '05 #35
Brian Genisio wrote:
<snip>
I know this is a long and boring example, but I am trying to
illustrate a practice that happens in out-the-door products on a
regular basis... Solving one problem, but creating a smaller,
unrelated problem that is managable.
It is reasonable to be pragmatic, but I can't see needlessly introducing
a javascript dependency as a smaller and manageable problem. It can only
look that way if you adopt a position of not caring.
Ideally, there should be a final solution to A that will be a perfect
solution. This solution may be unrealistic in budget/schedule, and
concessions are made for the A"xC' solution.

<snip>

Your example is rather frightening. I would not be happy to categorise
it as a solution at all, at least without the qualification "temporary".
Schedule constraints may necessitate it, but budget considerations are
never aided by an increased maintenance burden (that becomes a bit open
ended), and you know full well that problem D will manifest itself at
the worst moment possible.

Richard.
Jul 23 '05 #36
Richard Cornford wrote:
Brian Genisio wrote:
<snip>
I know this is a long and boring example, but I am trying to
illustrate a practice that happens in out-the-door products on a
regular basis... Solving one problem, but creating a smaller,
unrelated problem that is managable.

It is reasonable to be pragmatic, but I can't see needlessly introducing
a javascript dependency as a smaller and manageable problem. It can only
look that way if you adopt a position of not caring.


Are you talking about a solution in Javascript? Or a solution in
general? The scope of Javascript in a browser is very small compared to
the general practice of software development. It is real easy in
Javascript to say that a perfect solution exists for many problems you
encouter. This is because for the most part, Javascript programming is
a trivial exercise, in a small, descrete environment.

How about when your development solution spans multiple operating
systems and multiple languages?
Ideally, there should be a final solution to A that will be a perfect
solution. This solution may be unrealistic in budget/schedule, and
concessions are made for the A"xC' solution.


<snip>

Your example is rather frightening. I would not be happy to categorise
it as a solution at all, at least without the qualification "temporary".
Schedule constraints may necessitate it, but budget considerations are
never aided by an increased maintenance burden (that becomes a bit open
ended), and you know full well that problem D will manifest itself at
the worst moment possible.

Richard.


I once worked on a system that integrated four operating systems on over
6 computers, and ran software in about 12 different programming
languages and communicated over 6 communication standards to come up
with a solution that worked well.

When it finally worked, there was one glaring problem... it was
extremely complex. The solution solved the problem, and did it well,
but was difficult to debug and had a steep learning curve. I am
convinced that this solution was as good as anyone could have come up
with.

This is an example of a real-world software project with thousands of
requirements, and it met every one. Is this not a solution?

Brian

Jul 23 '05 #37
JRS: In article <c6*********@news2.newsguy.com>, seen in
news:comp.lang.javascript, Matt Kruse <ne********@mattkruse.com> posted
at Tue, 20 Apr 2004 13:33:50 :
"Dr John Stockton" <sp**@merlyn.demon.co.uk> wrote:
Those on dial-up or radio links will prefer not to receive an
unnecessary 5K of code.
They may prefer not to receive an unnecessary 5k of site-wide CSS rules,
too, but do you recommend against using global CSS files? Would you rather
have a separate CSS file for every page on your site, containing only the
definitions required by that page?


If the nature of the site was such that I was likely to visit only one
page, then as a user I would naturally prefer only the definitions
needed on that page. But if I was likely to visit many pages, so that
definitions were multiply used, I would prefer collected definitions.

hell, there may be HTML pages with 1k of whitespace! Should everyone start
compressing all of their HTML source so as to not send unnecessary
whitespace characters???
Yes, they should, at least for popular professional sites; and comment
should also be removed. It is in the interests of their readers, after
all. That assumes, of course, that the HTML is intended to be read only
by browsers and not by people.

There are two common classes of unnecessary whitespace; spaces at the
ends of lines, and indentation. The former can very easily be removed
automatically; removing the former needs an understanding of <pre>, but
is equally trivial if it is known to be absent.

However, recognise that size reduction is most important for those on
slow links, which are likely to have hardware compression which will be
effective on leading whitespace. Code bloat is far more important.

If a user objects to an extra 5k of javascript code, they are surely
browsing without images on, and probably have javascript turned off to begin
with.

It's kind of a ridiculous argument you're trying to make, isn't it?


You need to be sensible about it. A large all-purpose routine of which
only a small part is likely to be used within a site is not sensible; it
is merely showing-off on the part of its author.
Authors should recognise that there is a difference in the use of code
libraries between (Web) javascript and, say, Delphi. A Delphi
programmer can freely use many library units, because the units stay on
the local machine and only the needed parts go into the distributed EXE
(but needs to think a bit more when writing DLLs). But a Web author
with many library files available should be selective about which parts
he puts in Web pages or include files, and hoe they should be
distributed among those.

Full optimisation is impractical; but a little thought on such matters
should enable avoidance of full pessimisation.
H'mmm - there's another reason for removing redundancy; it diminishes
the load on the server. In particular, it diminishes the download for
an individual author. Large authors will pay directly for the amount of
service provided; small authors may have a fixed allowance, so that more
compact pages means more readers.
Eschew surplusage !

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 23 '05 #38
On Mon, 19 Apr 2004 14:32:47 -0500, "Matt Kruse"
<ne********@mattkruse.com> wrote:
"Brian Genisio" <Br**********@yahoo.com> wrote:
The only problem I see with that, is that 5K of javascript code in
library form is compiled on the first pass of the JS interpeter, if it
is executed or not. If you are only using one function from that
library, there is a lot of extra processing to include code that is not
being used.


In theory, yes. But I've had pages with over 200k of javascript (literally -
and no, I didn't design them) which executed in 2 seconds. Computers are
very fast. Compiling 5k of javascript takes such little time that it becomes
completely negligible.


That's fast, initial hit time for a current project of mine which
involves 200 JS load, is around 14 seconds on a 2Ghz P4 not under
load, it's not all compilation, but it's a significant part of it.

Was the 200k something particularly simple?

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #39
On Tue, 20 Apr 2004 08:37:13 -0500, "Matt Kruse"
<ne********@mattkruse.com> wrote
I doubt anything is going to actually be executed 10,000 times in
javascript. If it is, there's probably something wrong.
you've never done something onmousemove, or using css properties with
JS, they are processed a lot... but yes, there's often no point, but
you're talking about seconds, even 1/10th of a second is often too
long in UI's users notice it.
I'd much rather deal with slightly inefficient code than code that isn't
commented and is poorly designed to begin with. I'll gladly sacrifice .1
seconds of speed in exchange for code clarity :)


I'd be amazed if your users will, a second is an age.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 23 '05 #40
"Jim Ley" <ji*@jibbering.com> wrote:
I'd much rather deal with slightly inefficient code than code that isn't
commented and is poorly designed to begin with. I'll gladly sacrifice .1
seconds of speed in exchange for code clarity :)

I'd be amazed if your users will, a second is an age.


I said .1 seconds. :)

But, it depends entirely on the application. For some things, 1 second isn't
an age.
In a current project I'm working on, I'm filtering 500-1000 rows of data on
the client side using DOM, and it can take several seconds on fast machines.
But the users _expect_ that, so there are no complaints!!

--
Matt Kruse
Javascript Toolbox: http://www.mattkruse.com/javascript/
Jul 23 '05 #41

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Michael Olea | last post by:
Hiya. Frequently (as in at least twice now) I find that when I write some sort of container I want at least two out of three possible versions: o fixed max size known at compile time o fixed...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.