'Flavors' of JS?

[Jim Witte]

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

[Richard Cornford]

Re: 'Flavors' of JS?

Jim Witte wrote:[color=blue]
> 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."[/color]

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.

[Robin Becker]

Re: 'Flavors' of JS?

Richard Cornford wrote:[color=blue]
> Jim Witte wrote:
>[color=green]
>> 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."[/color]
>
>
> 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[/color]
........[color=blue]
> 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.
>
>[/color]

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

[Richard Cornford]

Re: 'Flavors' of JS?

Robin Becker wrote:
<snip>[color=blue]
> I see the following statistics for the web site that I have
> data for. There are 8 browsers with some usage.[/color]

And this is relevant because?
[color=blue]
> We use javascript, but sparingly. It is pretty hard to even
> test against all these browsers.[/color]
<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.

[Robin Becker]

Re: 'Flavors' of JS?

Richard Cornford wrote:
[color=blue]
> Robin Becker wrote:
> <snip>
>[/color]
.......[color=blue]
> 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.[/color]

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

[Douglas Crockford]

Re: 'Flavors' of JS?

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

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

[Robin Becker]

Re: 'Flavors' of JS?

Douglas Crockford wrote:

......[color=blue]
> And finally, "flavour" is spelled "flavor".[/color]

In English it is spelt "flavour", the "flavor" variant is American. Probably
need some dynamic JS to detect the reader :)
[color=blue]
> http://www.crockford.com/javascript/javascript.html[/color]


--
Robin Becker

[Richard Cornford]

Re: 'Flavors' of JS?

Robin Becker wrote:
<snip>[color=blue]
> 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.[/color]

So every development mistake equals a disgruntled user?
[color=blue]
> Their brief is usually Mozilla latest, IE 5-6 on PC
> with Mac/Linux browsers a poor relation.[/color]

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.
[color=blue]
> 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.[/color]

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?
[color=blue]
> It is arguable, that by coping with all the horrors of the web,
> the experts just delay standards for JS and DOM.[/color]

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?
[color=blue]
> Differentiation is in the interest of the JS programmers
> and probably the browser suppliers.[/color]

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.

[Richard Cornford]

Re: 'Flavors' of JS?

Robin Becker wrote:[color=blue]
> Douglas Crockford wrote:
> .....[color=green]
>> And finally, "flavour" is spelled "flavor".[/color]
>
> In English it is spelt "flavour", the "flavor" variant is American.[/color]
<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.

[optimistx]

Re: 'Flavors' of JS?

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?

[Robin Becker]

Re: 'Flavors' of JS?

Richard Cornford wrote:

......
[color=blue]
> 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.[/color]

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.
.....
[color=blue]
>
> Cross-browser scripts do not have to be complex. Indeed K.I.S.S. is a
> very worthwhile design principle to follow.
>[/color]

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.
[color=blue]
> The economic relationship is not being meaningfully judged. It is always
> going to be relatively expensive to employ someone who doesn't know how[/color]

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.
[color=blue]
>
> Differentiation is not in the interests of JS programmers; we are not
> masochists. We are working without the certainty of a known environment,[/color]

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.
[color=blue]
>
> Richard.
>
>[/color]


--
Robin Becker

[Richard Cornford]

Re: 'Flavors' of JS?

Robin Becker wrote:[color=blue]
> Richard Cornford wrote:[/color]
<snip>[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

And the big potential client using Mac IE 5.2 (or Safari)? Doesn't
he/she go and look elsewhere?
[color=blue][color=green]
>> Cross-browser scripts do not have to be complex. Indeed K.I.S.S. is a
>> very worthwhile design principle to follow.
>>[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
>> The economic relationship is not being meaningfully judged. It is
>> always going to be relatively expensive to employ someone who
>> doesn't know how[/color]
>
> 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.[/color]

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.
[color=blue]
> 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.[/color]

Which is why it makes sense to hire a suitable specialist to do the job.
[color=blue][color=green]
>> Differentiation is not in the interests of JS programmers; we are not
>> masochists. We are working without the certainty of a known
>> environment,[/color]
>
> I believe earlier you said that companies should employ best
> qualified people.[/color]

Suitably qualified will do.
[color=blue]
> You assert as well that we can support cleanly all browsers.[/color]

Absolutely.
[color=blue]
> The conclusion is obvious. Differentiation certainly
> benefits expert js programmers.[/color]

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.
[color=blue]
> I assume they are masochists only if they really believe
> it's desirable to support 30-50 platforms.[/color]

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

Richard.

[Matt Kruse]

Re: 'Flavors' of JS?

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote:[color=blue]
> 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.[/color]

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/

[Richard Cornford]

Re: 'Flavors' of JS?

optimistx wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> 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).[/color]

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).
[color=blue]
> b) some frills, whistles, bells, which are completely
> unnecessary and even annoying for a serious customer?[/color]
<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.

[Richard Cornford]

Re: 'Flavors' of JS?

Matt Kruse wrote:
<snip>[color=blue]
> Richard, you write novels on this group every day,[/color]

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.
[color=blue]
> but I've never seen
> real-world examples of your work,[/color]

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.
[color=blue]
> or a web site of the libraries you've
> written, or anything.[/color]

Didn't I write one of those novels explaining to you why libraries are
in inappropriate concept for Internet browser scripting?
[color=blue]
> Do you have anything?[/color]

In what sense?
[color=blue]
> 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 :)[/color]

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.