Posted by ^reaper^ on 07/30/05 02:51

[ comp.lang.javascript added, followup set to
alt.html,comp.lang.javascript ]

Yep, I decided to sub to those two froups. Though I won't have much time to
participate... but anyway, more between and below. ^_~

While sipping absinthe, Michael Winter heard a loud sucking noise coming
from alt.2600, and hastily inscribed the following unintelligible Sanskrit
in <news:2KUFe.78398$G8.30684@text.news.blueyonder.co.uk>:

> On 25/07/2005 07:11, ^reaper^ wrote:
>
> Apologies for the delay. I never usually leave replies this late.

Heh. No worries. Most peeps tend to be busy with rl stuff (at least I hope
they are). So juicenet, while at times engaging, fun even, can generally
wait. ^_~

>> Even though Michael has some valid pts wrt feature detection (which
>> is certainly superior to browser detection), you're still req to
>> include addtional steps (e.g. if-feature det-then) if you're aiming
>> for xbrowser compat. And this, in and of itself xlates to needing
>> more than just a cursory knowledge of teh lang.
>
> Yes, but should you really expect much else? You wouldn't hire someone
> to write an application if they only had cursory knowledge of C++, would
> you?

C++ is not really an applicable analogy, Michael. For one, c++ is a core
technology, whereas ECMAScript is an adjunct technology. Furthermore, a
project requiring c++ knowledge usually involves fairly extensive c++ code
reqs (e.g., the whole project is written in c++ or major components have
been targeted for c++ impls). Therefore personnel reqs involve at the very
least one (though often multiple) software engineer(s) whose core expertise
will be c++. Even so, dep upon scale and reqs, the project will likely
include a range of expertise, rather than a concentration of expertise
(e.g., a couple of interns, a couple of experts, and a whole bunch of
intermeds). This in turn xlates to easily identifiable justification for
hiring various degrees of knowledge specific individuals (if there is a
long term necessity for concentrated expertise) or contracting teh work out
(if the necessity is short term). Simply bc you are dealing with a core
technology.

This however, is not the case with ECMAScript. The limitations that are
imposed by both browser impls (resulting in xbrowser compat issues) as well
as the client (e.g., disabling scripting) along with issues of ip (intel
prop) interests ensures design decisions will favor limited and simplistic
scripts (or no scripts at all) over implementing complex scripts. So you're
generally speaking of a few components with limited functionality, where
the resulting client side ops will be simplistic in nature and include
serverside fallback support where necessary (e.g., form validation, data
display/manip, etc). That or, features which, while potentially additive
for those with scripting enabled, will not detract from the site's primary
functionality, should scripting be disabled. And this directly xlates to
very little necessity for hiring personnel based solely upon ECMAScript
expertise, which in turn makes justification of hiring such an individual
(or even contracting out, for that matter) generally unsportable.

This does not mean you would not look for indivuals who also have
ECMAScript expertise. Simply that their knowledge would need extend well
beyond ECMAScript, to include a strong web technology protocol foundation,
as well as having a solid foundation in oo paradigm and programming lang
concepts.

> Browser scripting and ECMAScript have long been portrayed as simple
> tasks that (almost) anyone can do. In some cases, that may be true.

And there is certainly plenty of evidence to teh contrary. Just ask teh
scriddies! ^_~

>> That is, if you do not want to blindly use feature det which could
>> result in overuse thereby xlating to code bloat and unnecessary
>> compute overhead. Furthermore, if you're using it to generate a
>> content rich site, perform complex operations, etc. Teh result can be
>> a compute hog.
>
> Code size can certainly be a problem as it must require extra code to
> perform the tests. However, code speed isn't really an issue.
> What's more, the flexibility that is present in ECMAScript can allow
> tests to be performed once, and only once, and then skipped in subsequent
> runs. Unsurprisingly, this has been discussed on comp.lang.javascript
> before. Search the Google Groups archives for the phrase, "Russian doll".
> There are bound to be other threads, but I know that will lead to some
> detailed discussions.

Thanks for the info. I'll check it out.

[...]

>> And finally, I consider js to be a toy lang, and therefore lending
>> little, if any value to teh final result.
>
> I used to think that, too. It isn't an opinion that I hold now, though.
> The language itself is very powerful. What lets it down is usually the
> restricted environment in which it operates.

My view is primarily colored by teh fact that it is a scripting lang.
Regardless of teh environ, it's still interpreted at runtime, thus limiting
scalability. Furthermore, it was never designed for full-blown app devel,
regardless of how many people may wish to shove it into that envelope. It
was simply not designed for that task.

And there are companies who have attempted to do just that. Such as those
implementing severside xformation environs (e.g., 5250<=>x.12<=>dom). From
what I've seen, it fares quite poorly under any kind of load. For example,
teh initial testing of a single (yes, one) xaction of a (shall go unnamed)
vendor product resulted in 50% computes on a dual proc sun box with no
other concurrent apps.

Obviously, quite unacceptable. Even after teh vendor corrected their
problem, the best they were able to achieve was 50% computes @ 12tps,
before the thing started tanking, which often occurred around 28tps. Put
another way, teh ECMA components consistently bottelnecked, and in some
cases simply froze, under low xaction stress testing (e.g., 50tps).
Furthermore other vendor products, who were also employing an ECMAScript
soln, fared equally poorly.

None of these results were surprising. In fact, afaics, they were using the
wrong technology for the req job in teh first place. Which was also proved
out through testing of vendor apps that employed core technologies such as
c++ & c. Even those using java & c# fared far better than the ECMAScript
impls.

Again, no big surprise. Now, couple this with the more obscure, involving
the pseudo object environ, lax typing, lack of ip protection, along with
the fact that ECMAScript /was designed/ to be an adjunct for web
technologies, and what you basically have is a toy lang.

There is of course, nothing wrong with toys. They can be lots of fun and
can certainly add spice to what might otherwise be a droll existence.
Though I would not advise taking say, a toy motorcycle on teh freeway. o_O

--
"In handling a stinging insect, move very slowly." -- 'The Notebook of
Lazarus Long,' Robert Heinlein

[Back to original message]