It includes a tutorial. I haven't finished reading through the article
and tutorial, but so far it has been interesting.

http://tinyurl.com/y7v26l

Enjoy!

-Bruce Holt (unafraid of identification)

Tate (author): 'Stuart Halloway, one of the foremost experts on Ajax, begins
a JavaScript class with a provocative statement: "By 2011, we will recognize
JavaScript as a language with a better set of features for developing modern
applications.'

Provocative?

You know what makes me both Sick and Glad about this article? It's that
feeling of deja vu all over again, compounded with the feeling that
basically all computer scientists are idiots, and overlaid with the I(we)
told you f***ing so over twenty years ago factor, with a final dollop of Who
let the inmates run the asylum.

It's a great article.

So javascript has been ridiculed as the "black sheep". Because of it
inconsistencies (forced by the DOM model). Because of its dynamic typing
which horrifies purists. Because of its ability to define attributes and
methods of objects on the fly. Well, slap the designers hard on the wrist
with a wet noodle.

Ok, to be semi-serious, which I'm having a hard time being:

Firstly, javascript is no more inconsistent than ANY language out there, bar
none. Every language starts out being consistent and beautiful and moral,
until it lands hard against the real world of designers (speaking loosely)
who want to tweak it here and there, who want to add just one more feature,
who can't put up with this one limit one more minute. And it gets added to.
And bastardized (not to be confused with design-level bastardization, which
is exhibited by those god-awful languages like php.)

Look at mv BASIC in all its glorious inconsistencies, for example. Would it
be better if it were completely consistent...Yes...but does it make it any
the less usable? Aside from purists (like me) who rail on about why jBASIC
or mvBASIC "uses that stupid construct instead of this one...," does it
really matter? No. It's fine.

Secondly, those of us weaned on Pick know all about dynamic typing, and,
barring some on this list, probably consider it a major boon. Check out
Tate's "However, static typing has several drawbacks"...
"Part of the power that you see -- which is also a great weakness -- is
the language's great malleability.
In fact, the object model in the language itself is just one example of
just how far you can bend JavaScript."

Wow. Can you imagine a normal computer scientist writing that?

Thirdly, Tate mentions that javascript is considered a "toy at worst". This
belies the fact that a vast number of web pages utilize *some* javascript,
and, as in the you-can't-be-a-little-bit-pregnant scenario, you can't have
it both ways...either javascript is useful and necessary or it's not. And if
it's not, you wouldn't see it so ubiquitously but I'll ignore that.

Finally by Listing 8 in the example, my eyes have glazed and my brain tuned
out. I rached my level of incompetence and wish someone would explain this
in words of one syllable.

Personally, I use javascript a Lot, and have the usual love-hate
relationship with it (as that Britisher said "you can hate your mistress and
serve her too" ).

Thanks, mvdbman...

Chandru Murthi

"mvdbman" <mvdbman (AT) yahoo (DOT) com> wrote

Decent article, thanks. I use javascript all the time in my web work,
there is a lot of real hatred out there about javascript itself and
indeed any ecma script running in a browser with regard security
concerns. I know on many of the web developer newsgroups i go on there
are numerous people who will not use it at all and always have it
turned off on their browser regardless of who the site is, and who
spout on about how stupid we are for using it at all ... I have to
admit to always having scripting turned on and i have never in how ever
many years had a problem with this.


rgds
Sym

mvdbman wrote:
Notice the use of brackets:
function swap() {
if(current == hot) {
current = cold
} else {
current = hot
}
}
Exactly the way I do it... which is to say,
exactly not how "real" JavaScript programmers
do it. Wonder if the author is old school?

--
frosty

"frosty" <frostyj (AT) bogus (DOT) tld> wrote

function swap()
{
if(current == hot)
{
current = cold;
} else {
current = hot;
}
}
Actually, I see the author's way more often. I MUCH prefer the
above...because you can viusalize the open-close brackets more easily if
they're in the same column. Also, I skip the {} on one-line if/for (you may
hate this):

if(current==hot)
current = cold;
else
current = hot;

And finally, I always add ";" at eol, though it's optional

Chandru

frosty wrote:
I led a non-credit seminar at the local college when I was also
teaching Java courses. In the Java classes, I felt compelled to teach
putting { and } braces in the same column, so they match and match
current "standards." In the seminar, I wrote the code on the board the
way I would typically write it the way I would if I were coding, as
above. I do understand that matching column approach, but it is so dog
ugly and uses too many lines, which I think makes it more difficult to
read.

Additionally, with the editors that will show you which brace matches
which other, it isn't all that hard to match the braces -- easier than
it once was. The other professors in the seminar would do an audible
tsk, tsk when I coded that way, but they also knew that I had been in
the field much longer than anyone else in the room, so they gave me a
"seasoned veteran" pass (or maybe I got a pass just 'cause I was a
girl).

cheers! --dawn

Chandru Murthi wrote:

I think people who put too much emphasis on curly braces are really
spending too much time on the wrong topic. As an example, they have
names for this stuff - a curly brace on the side is called "K&R style"
or "One True Brace Style" (1TBS or OTBS). Give me a break.
(http://en.wikipedia.org/wiki/Indent_style#K.26R_style)
That page also describes others styles - interesting reading for
geeks. My personal preference is to put the brace below the code
(BSD/Allman style for those who care).

With the quality of software these days at an all-time low I'm not
surprised when I see so much rhetoric focused on where the brace is,
rather than whether the code between the braces actually works.

VS2005 has an IDE flag that lets you toggle where the brace will go.
In that world the argument is over. Don't like the way someone wrote
their code? Hit a switch. The argument is over.

In the interest of portability and consistency, I personally like to
see JavaScript with semicolons - in many cases the exact same code can
be pasted into Java or C# and work with few changes - and I've been
able to paste C# code into a script block with very little syntactical
grief as well. In the argument about which is "better", I'd say the
more portable it is, the better it is.

[going off on a rant here, got yer coffee or other stiff beverage?]
Next to animations that can't be turned off, banners that roll in
front of content, and pages so full of ads that it's tough to even
find content, one of the top things that irritate me about scripted
websites is the number of sites that show script errors in the status
bar. (I recommend turning off popup notifications of script errors
unless you're diagnosing errors on your own site.) We see these
errors everywhere. Usually it's an "object is undefined" error,
occasionally there's all kinds of stuff messed up. Is software "good
enough" to go production when a new visitor's first connection to the
site reveals coding errors? How can someone walk away from a
production site and call it done when over 50% of the audience is
going to see errors?
http://www.w3schools.com/browsers/browsers_stats.asp

I've been told by many webmasters (yes, I report many script errors -
you're not surprised are you?) that script errors are the result of
issues with the brain-dead implementation of JS in IE, non-compliance
with ECMA, and bugs that Microsoft refuses to fix. Having written a
boat load of cross-browser code I know this is a lot of BS, and
failure to make code work properly is entirely politically motivated,
or pure incompetence. How can anyone justify a "var undefined" error
as being a platform issue? Why can't people acknowledge that failure
to initialize a variable is a coding error, not a platform-specific
defect? When did it become politically correct to dismiss coding
errors because the end-user is stupid enough to be using Internet
Explorer as the browser? Maybe we have a new corollary for modern
development: "The number of bugs you find in code when run over any
given platform is directly proportional to the disdain the developer
has for that platform."

Cutting these people a little slack, and getting back on-topic, one of
the reasons why we see so many JavaScript errors is that it's too easy
to make them. As a non-compiled, non-typed language, every line of JS
code is subject to runtime issues which would be found by modern
compilers but these days finding errors is often left to end-users.
Environments for pre-release testing are everywhere
(http://www.testingfaqs.org/t-unit.html and elsewhere) but the number
of developers who use them has to be tiny.

I've said it before but I think the overall problem with JavaScript
usage is over-use of a good thing. We wouldn't write an operating
system, compiler, database, or a server-side business application in a
script language, but somehow working in a browser is cool and hip and
in that environment it suddenly becomes OK to write massive utilities
in JS for a browser. I don't get that logic.

And now that Ajax is popular (even though it was unpopular before
someone gave it a name, sheesh) we find a resurgence in popularity for
JavaScript as well. Now wait a sec - because we have technology that
allows us to put more code on the server people are finding excuses to
write more code in the client? Personally I'd think Ajax should
encourage people to put LESS code in the browser.

If you want a thick app, get a thick client. People these days are
asking for thin clients that look just like a thick app. Some people
are resorting to creating very thick browser apps using ActiveX or
Java applets - all in the name of "ease of deployment" ... until they
actually try to deploy the stuff. And then the vision changes to
using the increasingly popular JavaScript with DHTML. That's great
too until you hear "oh yes, and we need to support IE, NS, FX, OP, MO,
KQ, ... and cell phones..."

Looking back at this thread, I'm sort of sorry that a lot of this
dove-tails with Chandru's comments. I realize I've just documented
exactly why JavaScript has been such a black sheep, which is exactly
what he was objecting to from that article. Oh well, too late now.

T

Dang, not another contender. I'm already taking a break from learning
Ruby on Rails to check out Python. If they're suggesting javascript is
getting beyond the browser I'm going to need to make time for more
evaluations. I hope javascript sticks to client side. Server-side I'm
beginning to think I like Python better than Ruby. I can't put my
finger on why yet, but it reminds me of Pick. It seems to have a few
other big pluses, not the least of which is the same sort of dynamic
typing and flexible object uses alluded to in the article. It also has:

- a significant set of server-side libraries
- an object-oriented focus
- a mature Java-based variant (Jython)
- a recently released .NET-based dialect (IronPython)
- similar productivity gains as you get in Pick development (is dynamic
typing the big win?)
- plenty of references in their docs to my favourite British comedy
troupe

Now if somebody were to make a new, dynamically typed, platform
independent, multi-dimensional language called BlackAdder I'd be in
real trouble.

JW

"Jeff" wrote:
If that's the impression I conveyed I apologise. Ajax calls to any
number of server-side languages and technologies, so I'd tend toward
using those on the server, as they are usually much better at resource
management, structured coding, etc. Leave JavaScript on the client
side, just less of it. I hope that position is more clear.

As far as the others, I feel yer pain. Having put Java on a back
burner, a while back I figured I was missing out on the OSS boat, so I
started studying Perl. Then when it seemed I couldn't protect my
software assets and Perl was getting less popular anyway, I got a
little turned off. Since then I've tried to pick up more PHP as time
goes on, my web site runs lots of PHP code. Now there's Ruby, Python,
and all the variants you've mentioned. As you say, enough with the
tools and forks and all of the other contenders already! I wish this
industry would spend more time on quality.
T