Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > 'Flavors' of JS?

Reply
Thread Tools

'Flavors' of JS?

 
 
Jim Witte
Guest
Posts: n/a
 
      04-15-2004
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
 
Reply With Quote
 
 
 
 
Richard Cornford
Guest
Posts: n/a
 
      04-15-2004
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.


 
Reply With Quote
 
 
 
 
Robin Becker
Guest
Posts: n/a
 
      04-15-2004
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
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      04-15-2004
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.


 
Reply With Quote
 
Robin Becker
Guest
Posts: n/a
 
      04-15-2004
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
 
Reply With Quote
 
Douglas Crockford
Guest
Posts: n/a
 
      04-15-2004
> 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
 
Reply With Quote
 
Robin Becker
Guest
Posts: n/a
 
      04-15-2004
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
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      04-15-2004
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.


 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      04-15-2004
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.


 
Reply With Quote
 
optimistx
Guest
Posts: n/a
 
      04-15-2004
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?




 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments