Slashdot Mirror
Should JavaScript Get More Respect?
An anonymous reader points out an article in IBM's Crossing Borders series about the language features of JavaScript, surely the Rodney Dangerfield of scripting languages. But with increasing use in such technologies as Ajax, Apache Cocoon, ActionScript, and Rhino, some industry leaders are taking a fresh look at the language. From the article: "Nearly every Web developer has cursed JavaScript at one time or another. Until recently, many developers had all but written off JavaScript as a necessary evil at best or a toy at worst... But JavaScript is becoming increasingly important, and it remains the most broadly available scripting language for Web development."
it remains the most broadly available scripting language for Web development.
:)
As someone who has written applets with over 25,000 lines, I can easily agree. Out of the roughly two dozen languages (scripting, etc.) that I know, JS has been a cornerstone of both simple and solid applets and the quick & dirty prototype. Let's hope the future agrees
Since developers seem to code about the same number of lines of code/statement per unit time, regardless of language. 10 times as dense means the developers are 10 times as productive. Since programmers are reasonably expensive needing 1/10th as many is a good thing.
But Javascript is no where near 10x as "dense" as Java, http://www.theadvisors.com/langcomparison.htm while flawed in many many ways puts Perl at 2.5 times as "dense" as Java. There is no way in the world that Javascript is four times as "dense" Perl...
Javascript is a fine language with elements from functional and object-oriented programming. The problem with web development is the whole environment:
1) the coupling of the UI with the code that actually does stuff.
2) the non-efficient and error-prone methods of communication between client and server.
3) the non-existent security regarding JS code; anyone can see it.
4) the mixing of a tagged document language with a programming language.
Ideally, web applications should only consist of source code in one language which is clever enough to be able to provide all the necessary abstractions. In reality, such a language does not yet exist, making web applications development 10 times more difficult than what they should be: the minimum number of languages to use for a web app is 5: 1) html, 2) css, 3) javascript, 4) java/php/ruby/python/perl/whatever, 5) XML...and let's not count the various XML schemas required for various domains of the back end, because the number of 'languages' one needs to know will grow exponentially!
If you are sending information to the browser that you don't want to be known, then you're doing something wrong. This is the case for JS, as well as for AJAX, Flash or Java applets. Or client-side code in general.
Seriously, I've seen students faces turn white when I mention that I could log into and mess up their remote SQL database, thanks to them putting their (administrator!) username/password combinations in client-side Java bytecode. They would then try to obscure their passwords somehow, which leads to an arms-race with other teams trying to break in. Security can be loads of fun!
This sig is intentionally left blank
I've been using PHP and Perl server-side and, reluctantly, JavaScript client-side for years before I actually bothered learning JavaScript. When I finally did, I discovered a language which was similar to PHP and Perl in that it supported most, if not all of their language constructs and which in many ways was more elegant (IMHO). So my dream was to use JavaScript both server- and clientside. That can be done in .net/mono, I guess, but I prefer the lightweight nature of PHP, Perl, Python etc. So I started http://www.sf.net/projects/jsext - check it out! The plan is to support C libraries (done on Linux, Windows version under construction) and Python modules (not done). There are other, similar projects, too: http://en.wikipedia.org/wiki/Server-side_JavaScrip t
JavaScript has one really, really nasty flaw. It "recycles" the + operator (which usually is used for adding numbers) to concatenate strings. In some languages (e.g. BASIC), which treat numbers and strings as distinct data types, this is not a problem. But JavaScript is dynamically-typed -- in other words, you don't have to tell it what is a number and what is a string; it tries to work that out for itself. And this is the source of the error. When you innocently write
document.theform.hours.value += 1;
in a bit of form-munging code, what happens is that a figure "1" gets appended onto the end of the value in the "hours" box. If you want to increment it by one, you have to use something like
document.theform.hours.value -= -1;
which is mathematically sound, but looks very weird.
JavaScript really needs a dedicated string concatenation operator, in recognition of the fact that numeric addition and string concatenation are different operations. Unfortunately, the "dot", which would be the most obvious choice as it's already used for the concatenation operator in other languages, is already very much in use -- not to mention that changing an operator in this fashion is likely to break things. And the breakage will be even worse than register_globals in PHP, since JavaScript runs on the client side -- meaning no webmaster can ever know for sure what JavaScript engine is in use.
Je fume. Tu fumes. Nous fûmes!
You can do some pretty fun things with it, such as a true 3d engine, a raytracer, games (careful, robots is addicting!), out-of-order CPU simulators, and other stupid things without any plugins - all the user needs is a halfway decent browser.
My server