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."

Comments

JS

[djupedal]

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 :)

Re:JS

[Schraegstrichpunkt]

And yet you don't seem to know the difference between an embedded Java applet and integrated JavaScript code.

Re:JS

[CmdrGravy]

25,000 lines of Javascript ? What could you possibly be doing which requires that level of Javascript interaction ?????

Re:JS

[ignavus]

"25,000 lines of Javascript ? What could you possibly be doing which requires that level of Javascript interaction ?????"

document.write('25,000 bottles of beer on the wall, 25,000 bottles of beer. Take one down and pass it around - 24,999 bottles of beer on the wall');
document.write('24,999 bottles of beer on the wall, 24,999 bottles of beer. Take one down and pass it around - 24,998 bottles of beer on the wall');
document.write('24,998 bottles of beer on the wall, 24,998 bottles of beer. Take one down and pass it around - 24,997 bottles of beer on the wall');

etc ...

Re:JS

[djupedal]

'integrated JavaScript code'

...as opposed to what? JS that isn't integrated...? I knew someone would complain. A rose by any other string of characters...

The uppercase 'A' should be enough of a hint as to why I went with that particular label :) - No? Since when is 25,000 lines small...?

For the grammar goons among us:
applet ['aplit ] noun - Computing A very small application, esp. a utility program performing one or a few simple functions.

And a utility program it was. Put up to accomplish a temporary (9 month), semi-automated process of data gathering, consolidation and PDF summary reporting via email...yes, 25k lines is nuts. Would I ever do it again? Not likely. And if you think this was crazy, you should have seen the process it replaced.

In this case it was easy enough to do, which meant we were providing the reports that senior management needed right away, giving us time to relax and build a proper & full scale SQL replacement. In the end, the recipients never knew when we migrated from the stop-gap to the final - all of the routine post-deployment feature requests went in and were tested long before it went public, with bonuses all around :) Thank you JavaScript!!!

Re:JS

[HxBro]

After writing javascript for the past 6 years on digital tv platforms, I can say I've seen EPG's, Games, Apps running on liberate based set-top boxes and various IPTV set-top boxes could be running apps of similar size at time too.

Granted you do try keep the sizes down but in some cases especially and EPG you do end up writing lots of code.

Re:JS

[mikek3332002]

document.write('25,000 bottles of beer on the wall, 25,000 bottles of beer. Take one down and pass it around - 24,999 bottles of beer on the wall');

A much better form for 25000 lines would be having, 12499 bottles of beer on the wall lines, an initlization statment, and a decremeant function after every write line. That way you can easily modify the code to start off with what ever number you want.

Re:JS

[h2g2bob]

How about Mozilla firefox (or any of it's extensions).

Re:JS

[Anonymous Coward]

Also, it's a good idea to Write and Save your JavaScript a Word document (eg in an editor like Notepad), not scrawled in Paintbrush and saved as a Bitmap File. It's funny how the Internet can't compile my Paintbrush Javascripts lol! My fried says thats how all the best programmers do it, but I can't get it work. maybe I don't get something? something vital? I think that must be it

Re:JS

[datadriven]

for (i=25000;i=1;i--) {
    document.write((i + ' bottles of beer on the wall,' + i + ' bottles of beer. Take one down and pass it around ' + (i-1) + ' bottles of beer on the wall\n');
}

I only had 3 lines.

Re:JS

[pla]

In this case it was easy enough to do, which meant we were providing the reports that senior management needed right away, giving us time to relax and build a proper & full scale SQL replacement.

It strains credibility to claim that, after producing something functional, management would give you the time to replace it with something such that, "the recipients never knew when we migrated from the stop-gap to the final".

And I don't mean that as a typical geek management-slam - If they can't tell the difference, why should they approve the team spending twice as long on the cleanup as on the prototype? Yeah, the engineers might know the difference, but the aesthetics of the underlying code rarely counts as making for a better a business case.

Re:JS

[Schraegstrichpunkt]

'integrated JavaScript code'
...as opposed to what? JS that isn't integrated...?

Perhaps I chose my phrasing poorly. The JavaScript interpreter is integrated into the browser, and has direct access to the web page's content. As opposed to Java applets, which are mostly isolated from the browser and the surrounding page content.

For the grammar goons among us:
applet ['aplit ] noun - Computing A very small application, esp. a utility program performing one or a few simple functions.

I don't get my computing vocabulary from some unnamed dictionary. I get it from usage, and I've never heard anyone who isn't confused use "applet" in reference to JavaScript code. You wouldn't use it either, if you actually cared to communicate your thoughts clearly.

Re:JS

[Anonymous Coward]

My sarcasm detector exploded. ow.

Re:JS

[walt-sjc]

25,000 lines of Javascript ? What could you possibly be doing which requires that level of Javascript interaction ?????

1000 lines of application code, and 24,000 lines of browser compatibility code.

Re:JS

[TheNinjaroach]

Maybe you could write a few more to catch the joke for you as well. =)

Re:JS

[orasio]

Cut the guy some slack.
Only because Sun trademarked "Applet" it doesn't mean they invented it, or that they own it.
An applet is a small app. More often, it's a web, client side app. Much more often, it's a "Sun Java Applet".
In the context of this discussion, the second meaning was obvious. All of your responses were too pedant. There _are_ applets that are not "Sun Java Applets". In the context of _this_ discussion, it was clear what he was talking about.

Re:JS

[julesh]

A CMS with a relatively advanced JS UI that my company's currently working on has around 7,000 lines of JS. That's not a particularly complex application, either. I could easily imagine something like a webmail system reaching five times that.

Re:JS

[CastrTroy]

try{
tellJoke();
}
catch(JokeException e)
{
printf("joke wasn't funny");
}

Re:JS

[foniksonik]

How about Dreamweaver? Have you ever looked at it's WYSIWYG code? All Javascript. In fact the entire UI is 90% Javascript.... you can customize the whole app by editing, you guessed it Javascript.

Re:JS

[hobo sapiens]

I only had 3 lines.

Yeah, 3 lines and an endless loop. You meant:

for(var i=25000;i>0;i--)
document.write((i + ' bottles of beer on the wall,' + i + ' bottles of beer. Take one down and pass it around ' + (i-1) + ' bottles of beer on the wall\n');

Dude, this is slashdot. You can't be posting endless loops like that, that could be dangerous! Have you any idea how many geeks will be frozen in front of their computers until they involuntarily fall asleep?

Re:JS

[dlim]

dude. you're putting the bottles back on the wall. that makes no sense at all...

Re:JS

[budgenator]

From what I've seen, 25, 000 lines of javascript has only one linefeed :-)

Re:JS

[rjshields]

The only reason some people thought about Sun Java Applets is that Sun promoted that term a lot back in the day. As someone else said, this is supposed to be "news for marketdroids", it's news for nerds, and nerds are supposed to know the difference between a JS powered applet, and a Sun Java Applet.

Of course everyone should know that Sun didn't invent the term "applet", no one is disputing that. However, when you start talking about applets in the context of web pages and web development, it's only logical to assume you're talking about Java applets, and certainly not bits of JavaScript. You don't use the term "applet" to describe bits of JavaScript unless you're very confused. To quote wikipedia :-

An applet is a software component that runs in the context of another program, for example a web browser...An applet is written in a language that is different from the scripting or HTML language which invokes it. The applet is written in a compiled language, while the scripting language of the container is an interpreted language, hence the greater performance or functionality of the applet.

I'm sure you can see why confusion should arise over incorrect use of the term "applet".

Dense != Good

[Marcus Green]

According to the article

"My friend and colleague 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." He then says that JavaScript programs are often 10 times as dense as similar Java programs and goes on to show the language features that make it so."

The author seems to equate dense with good, not an association I make

Re:Dense != Good

[MichaelSmith]

The author seems to equate dense with good, not an association I make

By that standard APL would be hard to beat.

Re:Dense != Good

[Anonymous Coward]

He then says that JavaScript programs are often 10 times as dense as similar Java programs

So are the javascript developers in my experience. I kid, I kid...

I agree with parent poster that there seems that a lot of people take lines of code as the only measure of how good a language is. Something like 80% of developer time for an average project is spent on maintenance, and often there are new developers doing it. So in my opinion clarity is at least as important.

I admit that fewer lines of code can make code more readable, but brevity does not automatically mean clarity. Witness many perl based apps, especially those that make heavy use of regexp. I have also seen some pretty unreadable Ruby code where the programmer was clearly in love with all the clever things you can do. Metaprogramming, activerecord magic, method_missing stuff, runtime changes of objects where it was just more convenient than thinking through the model, and so on. Probably fun to write, nightmare to maintain.

Re:Dense != Good

[sholden]

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...

Re:Dense != Good

[D-Cypell]

The author seems to equate dense with good

The irony of this is so elegantly compact I am concern a singularity may form around the vacinity of this article.

Re:Dense != Good

[Eivind Eklund]

I consider the numbers in that comparison so deeply flawed that they can't be used for comparing density of two languages like this.

In my experience, Ruby is about twice as dense as Perl *in direct translation* (I have taken Perl libraries and translated directly to Ruby). It is even more dense when the code is idiomatic Ruby - that might be up to 10x. Idiomatic Common Lisp is about as dense as Ruby.

Yet, Perl comes out at 15 and Common Lisp comes out at 5 in that "programming languages comparison", and Java comes out above Common Lisp at 6. These results are completely ridicilous. They probably have some statistical correlation with reality for some kinds of programming with some kind of developers - they're just far from exact enough to be useful for specific language comparison, like you do above. (They're also a decade out of date.)

Eivind.

Re:Dense != Good

[CaymanIslandCarpedie]

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.

That sounds great for little one-off scripts. However, if you are working on an application with any decent expected lifespan, well than that is just wrong. Say your average application will be in production use for 5 years (I'd think this is a pretty low estimate). In that case I'd guess your intial development costs would be a fraction of your support costs over the life of the product.

By your logic whenever designing a database you should always just name tables as A, B, C, D, E, ... and the columns within those tables as a, b, c, d, etc. Also, any comments in code are just a frivilous waste of money.

As much of a pain as writing verbose code can seem at times, it certainly does have its merits.

Re:Dense != Good

[marcosdumay]

"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."

Maybe, but writting the program is fast. What is slow is writting a program that works.

Now, How does Javascript helps you to wite code that works at the first try, or maintanable code, or code that is easier to debug? Well, the answer is that without sane objects, a workable type system, some rules that prohibit bad patterns of code, and most of the other things that make Java verbhose Javascript simply doesn't help you.

Re:Dense != Good

[Rufty]

Dense *is* good. Suck all the bugs out of your code, you just need a perl regex with an event horizon.

Re:Dense != Good

[x2A]

Absolutely. Everytime I need a new variable, I use the md5 checksum of the file at its current point. If I ever forget a variable name, I simple undo until the first time I put the variable in (I keep vim open ALL the time, and never exit) and run md5 on it again. Simple.

Re:Dense != Good

[dwarfking]

Of course this is a humorous post, but I have to ask, what does a namespace construct provide that you don't have with JavaScript already?

to quote Wikipedia a namespace is an abstract container providing context for the items (names, or technical terms, or words) it holds and allows disambiguation of items having the same name (residing in different namespaces)

Couldn't you achieve the same thing by grouping variables (or functions) as attributes of an object prototype since JavaScript allows dynamically adding variables (or functions) to objects?

Wouldn't something like

namespace TopLevel {
int count = 0;
};
int count = 5;
TopLevel::count = 1;
cout << TopLevel::count << " is not " << count << eol;

be equivalent to

TopLevel = new function() {
this.count = 0;
}
count = 5;
TopLevel.count = 1;
alert(' ' + TopLevel.count + ' is not ' + count);

Now granted, a namespace usually exists only once in a running context where as a JavaScript object can have multiple instantiations, but nothing would prevent the program from only creating and using one copy of the object to simulate the same environment.

Basically all this is syntactic sugar anyway. Object Orientation, Namespaces, Classes vs Prototypes, just different high level means of segregating data and grouping functions which are byte arrays in memory.

Re:Dense != Good

[MemoryDragon]

one word check out the dojo toolkit www.dojotoolkit.org, then you can see which codesizes we are already dealing with. The dojo toolkit is not the only javascript codebase of significant size already outside in the wild, the more interactive the applications become the more you see toolkits of that size becoming the norm not the exception.

Re:Dense != Good

[iluvcapra]

Well.... just an observation:

Inside your function "TopLevel" block, you still have to qualify your variable assignment of "count" as being a member of "self." In a language with a proper namespace, this qualification is automatic if you use a variable name that is not declared in any parent namespace.

Also, languages with namespaces almost always have a way of "importing" a namespace permanently into the top scope, so you can say:

using namespace TopLevel;
count = 1;

Thus, TopLevel::count is assigned, and if you wanted to keep a separate one in the top namespace, you do main::count (er words to that effect, I am not a C++ coder). If you wanted to declare a buncha functions in a scope, using your technique, you'd have to state them in long form every time you wanted to use them, which is equivalent to just giving them a long prefix-name.

You're absolutely right, it's syntactic sugar, and namespaces and objects and execution contexts are similar things, but programmers use them in different ways, and syntax should fit use hand-in-glove.

Re:Why the pressure ?

[tpwch]

Java and Javascript? Why would anyone do that, since those two are not related other than the name. Sun developed Java, and Netscape developed Javascript. Totally independent of each other. I'm starting to get tired of people thinking that they have something to do with each other.

Security is a problem

[Anonymous Coward]

Hey guys. I'm an online gamemaker, so 'toy' languages are right up my alley.

The main problem with writing games with some of the most applicable web tools out there (Javascript, Flash) is that once it hits the web anyone with access to the View Source command can steal your work and throw it on their own site as theirs. This is highly discouraging.

Nowadays I do use Javascript and Flash extensively, but the most significant part of any game machinery is always on the backend somewhere, usually in PHP.

Re:Security is a problem

[vadim_t]

Oh, bullshit.

No obfuscation will make it very different from what it is. A code indenter, a variable name replacement, and it'll be already understandable to pretty much any programmer.

Re:Security is a problem

[uradu]

> anyone with access to the View Source command can steal your work and throw it on their own site as theirs

Don't flatter yourself. As any halfway experienced developer will realize, that would only be true of the most trivial code, or perhaps some fancy algorithm that calculates the meaning of life in five lines of code or less. Most larger real world applications that do something useful are more tedium than brilliance, and are so problem domain specific that code "stolen" from them would be all but useless to most people or projects. You're welcome to all the thousands of lines of JS code our company produces, where would you like me to mail it to?

Re:Security is a problem

[chudnall]

You're welcome to all the thousands of lines of JS code our company produces, where would you like me to mail it to? darlmcbryde@sco.com

Re:Yes, but Javascript is a bad language.

[Myen]

Every function has a variable number of arguments. You can access it via the keyword arguments - it's an array. So yes.

function foo() {
  alert(arguments[0])
}

I love the autopointerage & hate the scope iss

[cyclomedia]

Would be nice to have everything my way, the sheer built in extensibility of the language is in my opinion nothing short of beautiful, and something other languages could do well to imitate (check out D, for example).

allow me to elaborate, suppose you want to know if the version of the language on your platform supports an intrinsic array push function, and if not, attatch your own:

if( !Array.push )
  Array.prototype.push = function( item ){ ... }

firstly the reference to .push in the if has no brackets, so it becomes a pointer to the function within the intrinsic Array class. you can then create a function and assign it to that pointer. Sheer magic and gorgeously intuitive.

sticking with arrays you can grow and shrink them with little to zero fuss:

function array_push( arr , item )
  arr[arr.length] = item;

magically the array is one index longer. you can just set arr.length and it will append or delete indexes for you.

you can also use this to assign functions to other object's handlers, most notibly events

someObject.onclick = myFunction

But this has brought up the thing that really really needs fixing, suppose i want that onclick function to pass some info to myFunction when i call it i have to do this

someObject.onclick = function(){ myFunction( this.someAttribute ) }

so instead i've created a function inline to hold my custom function, firstly it's not immediatley obvious to what object the "this" applies. if i'm running this code in a class does the this mean the class or someObject, one hopes it means the someObject.

next is the scope issue i've talked about suppose i'm dynamically creating objects on the fly and want the callback to reflect the id thus

for( i=0 ; i<10 ; i++ )
{
  someObject[i] = new SomeObject();
  someObject[i].onclick = function(){ myFunction( i ) }
}

every single object will pass the value of 10 to myFunction, because after the function has finished the instance of i in memory that was used is still sat there and every myFunction has been given a pointer to it, not the value it was when it was initialised!

so some oversights still exist, if only there were ways you could explicitly state "pointer to" or "value of" like in, oh, every other language including visual basic

The language is fine, but it's got baggage

[Radium Eyes]

JavaScript/ECMAScript really is an interesting language; the way objects work takes some getting used to, but it's powerful, and definitely definitely not a toy language. It's when you bring the HTML DOM and browser inconsistencies into the equation that things start to get painful.

Re:Yes, but Javascript is a bad language.

[masklinn]

It is not possible to have two methods with the same name and different parameters (only one of those will ever be called).

Because Javascript has no ways of dispatching: all functions (remember that Javascript methods are exactly like functions) use varags, and the arguments you ask for are but pointers to vararg cells.

Example:

1. function foo(a, b, c) {
2. return [a, b, c, arguments]; // `arguments` holds every single argument of your function no matter what
3. }
4. foo() // -> [null, null, null, []]
5. foo(1) // -> [1, null, null, [1]]
6. foo("foo","bar","baz","buzz","bon") // -> ["foo","bar","baz",["foo","bar","baz","buzz","bon" ]]

On the other hand methods behave like objects. One can have arrays of methods and then call mymethods[2](param);!

It's not that JS functions "behave" like objects, JS function are objects, period. Callable objects maybe, but objects nonetheless, they're no different from strings, integers or lists in that aspect.

And this is one of the nicest features of the language (along with lexical scoping and complete closures)

Like Visual Basic ...

[Anonymous Coward]

... it's not because you have to use it, that it makes it a good language.

Only reason people are using it, is because it's the only thing that let you manipulate a web page and will work more or less for 99% of the people out on the internet. Would all browsers ship with only COBOL people would be using it. Would I have the coice between JS and let's say Python or Ruby, I wouldn't even have a look at it.

What interpreters are available?

[Myen]

Sadly, when Javascript gets mentioned most people think of browser scripting. That's like thinking of MFC every time C++ gets mentioned... :(

What sorts of shells interpret JS? I know of Mozilla's js shell, and they also have a xpcshell (which adds XPCOM things to make it fully Mozilla-y). Sadly js shell has no built-in file access (it's a compile-time option you have to jump through hoops to enable, and buggy), and xpcshell has lots of XPCOM baggage.

Are there any others using different engines? Anything from Adobe (ActionScript) maybe?

Javascript is nice... the problem is...

[vhogemann]

The inconsistence between the two major implementations, Mozilla and IE. And the huge amount of annoying bugs that IE has.

I don't hate JS, its a rather nice language, but I tend to keep minimal use of it on my applications because I really hate to lost one entire day fighting against IE.

Too Hard to unit test

[Anonymous Coward]

javascript is too hard to unittest but most of that has to do with the web browser container . javascript is a victim of its environment.

Re:Too Hard to unit test

[Zardoz44]

How so?

25000 lines:

[hummassa]

Any serious Ajax application.

Me too

[Jens de Smit]

I am one of those people that cursed JavaScript (after being enthusiastic about it when I was 14). I am just now beginning to turn around and think "well, it IS pretty nice". One of the things that has changed is that it does not "[mutate] faster than a fruit fly in an X-ray machine" (bonus points if you know who wrote this) anymore, with support becoming more standard over different interpreters, and incompatibilities becoming better documented and workaround libraries that unify the differences all over the place. Debuggers also become more widely available, helping the people when they exclaim "WHY the HECK doesn't it work this time!". It's still easy to shoot yourself in the foot with it, but hey, the same goes for C. At least it generally does not blow your leg up like C++. This behaviour is caused by the extreme felxibility of the language, which also allows for interesting constructions, as long as you're careful as a programmer. In other words: you have to know what you're doing to keep the code organized and understanable, something that is lacking with most starting web developers. Still, the availability and functionalty of JavaScript allows rich, interactive web applications to be developed, which is a good thing if you ask me.

Re:I love the autopointerage & hate the scope

[Shano]

That isn't really an oversight, it's the way closures work. Most functional languages let you create closures explicitly so the problem doesn't arise. Javascript does it automatically, and usually when you don't expect it. In Javascript, you can do:

someObject[i].onClick = function(i) { return function() { myFunction(i) } } (i);

That creates a closure for each handler, with its own copy of i, so they will all get the values you want. I have no doubt there are other ways to do it, but this works for me.

Overlord

[Dude163299]

I for one Hate our new Javascript writing overlords.

And for the record im suppose to be writing various Javascript programs at this moment.

JS is not the problem, the whole environment is.

[master_p]

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!

Dear god no.

[el_womble]

My wish for web 3.0 is that Javascript is replaced entirely. The ONLY thing that Javascript has going for it is ubiquity (which I guess is down to its ease of implementation). Its not all Javascripts fault, in general, as in most things webby I blame Microsoft, but hte language itself seems to make everything you write look lke a dogs dinner.

Wouldn't the web be a nicer place if you could script the browser using Ruby or Python? Can you imagine the fun you could have working with constructs like:

@page.findById( "myID" ).each do |ajaxReturn| ... end

The web could be beautiful. Next on my hit list is an improved HTML / CSS. Should rounding corners, or drawing shapes / shadows really be done with gif/pngs?

Re:Dear god no.

[greyc]

Blargh. I should take a bit more time to think before posting. What I meant was:

class foo:
      def __init__(self, n):
              self.n = n
      def __call__(self, i):
              self.n += i
              return self.n

Daft story title...

[Aphrika]

Respect is earned, not given. As far as I'm concerned, AJAX has given JavaScript a new lease of life. Without it, there would be no Gmail, no Google Maps, or at least not in the way we've come to admire them. When you see the fantastic stuff Google (and Windows Live for that matter) produce, XMLHTTP was the catalyst that made that possible, but all the donkey work is done by JavaScript.

Thus I have a lot of respect for it as a client scripting language, in most cases it's the only way of getting something done in a browser.

Re:Dense != Good ==Wrong: It's not dense

[Gavin86]

Javascript is anything but dense. The most impressive part about the various flexible agents is that they are easily understandable programming patterns. That makes it very easy to make an assessment for which methodology you will employ.

Javascript might have a future, but..

[tacocat]

Look at the history of Javascript. It's not the history of a programming language. It's the history of a marketing battleground.

Programming Languages have a few key elements that Javascript lacks. For one, everyone who writes Perl, Ruby, Java, Python, even Bash expect it to have consistent behaviour where ever it might be. And for that behaviour to be well documented, reliable, and owned by the language itself.

Javascript has an evil dependency to run based on the Operating System and Browser that you are using. Mozilla on Windows works differently than Mozilla on Linux. Mozilla on anything works different than Opera or MSIE. MSIE6 works differently than MSie7. And some of these differences in javascript behaviour isn't really javascript. It's javascript trying to do CSS/DHTML stuff.

If you were to have something similar under a real programming language there would be an active development team working to resolve the differences and get consistency in the language. The finest example of this is the Java JVM. It tries to be write once run anywhere. I don't know that it actually accomplishes that -- but it's closer than javascript.

javascript has no such activities. I don't do much with Javascript but when you pull a 10 year old book off the shelf you find 1/2 of it is talking about MSIE vs Netscape in how to work around code differences. Then you get a new Javascript book and it's still talking about many of the same problems a decade later. That's a dead language lacking any real development.

AJAX is cute because Microsoft went ahead and implimented something on their own and didn't bother telling anyone about it. I'll assume that Mozilla implimented the exact same thing but under a different name because they were afraid of getting sued. Why they did it doesn't matter. The fact that they implimented the exact same thing under a different name is why Javascript must fail. It's not a real language. You won't find a language the does the exact same thing in two different commands and those two different commands only work on distinctly different machines.

If someone takes Javascript away from the companies and starts to impliment there own version of it there's no chance. Javascript needs a replacement.

Re:Javascript might have a future, but..

[Jens de Smit]

You are seriously confusing "language" with "library". One main problem with JavaScript as a programming environment is indeed that library support for it differs hugely among environments, with good examples indeed being the XMLHTTPRequest object, implemented with roughly the same interface by two completely different browsers, but accesible in different ways (because of the difference in library). What Sun does with Java is delivering the JRE (Java Runtime Environment), of which in important part is of course the JVM, which translates bytecode instructions into operating system and platform specific instructions. However, another very important aspect of the JRE is the Java API, which is also (almost) universally consistent amongst the different JRE's. That is what makes Java "compile once, run anywhere". Also, this is not entirely true. Many cell phones and other mobile devices nowadays are equipped with a JVM, but not with a full J2SE API. Therefore, a lot of those "compile once, run anywhere" Java programs will do nothing but generate errors on such a device.

Re:I love the autopointerage & hate the scope

[Anonymous Brave Guy]

While I agree that some of the concepts you mention could be useful, I don't see that Javascript's implementations are particularly powerful or elegant.

It's hard to comment on the function-attaching example you gave, since obviously any real implementation of most languages already has functions such as those you describe. In general, however, I've found these dynamic features to be overhyped, and usually no substitute for having a decent design in the first place. I don't miss them in languages where they aren't there.

As for the scoping and closure stuff, IMHO having first class functions in a language is a big plus. Javascript's version always seems a bit like Functional Programming Lite, though: in real functional programming languages, the rules on scoping and such tend to be absolutely clear, and the syntax clean and powerful. So-called scripting languages tend to try but fail on this count here; Javascript is certainly not alone in the field.

Re:Why the pressure ?

[Aqua OS X]

Developing interactive content for the web is a lot like building a house out of crap you find at the junk yard. None of the materials are great, you'll be forced to use a lot of jankie things you'd rather not use, and you may need to substitute sheet-rock for side panels from an '82 Corolla.

In the case of anything involved in web development, I use tools because they're the best thing for the job. Unfortunately, "best" for web dev tools usually means "only" or "no one will be able to view your page if you develop with something else."

Java Script / J Script is the devil. Development is a sloppy crap shoot, but we use it because it's there. It's now being used for ridiculous things that it was never really designed for.

On one hand, web 2.0 AJAX sites are cool, on the other hand, AJAX makes me throw-up a little bit in my mouth every time I type it's name.

Re:JavaScript is wonderful

[killjoe]

To be fair you use the library as much if not more then you use the language. If I can't interact with databases, if I can't download a library that scrapes web sites, connect to SOAP services easily, authenticate against a LDAP server then no matter how beautiful the language is I can't use it.

One lesson ruby learned early was that you don't get anywhere till you build your own version of CPAN (still the king!). Build your library, build a way to install, uninstall and upgrade your libraries smoothly and your language will take off.

In conclusion. It's the library stupid.

Re:JS is not the problem, the whole environment is

[AlXtreme]

3) the non-existent security regarding JS code; anyone can see it.

Repeat after me: Obscurity is not the same as Security

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!

Server-side JavaScript

[sveinb]

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

Re:JS is not the problem, the whole environment is

[Tim C]

I used to hang out on the , and questions about encrypting Java bytecode came up with surprising regularity. The number of people who simply didn't understand that what they wanted - to make it impossible to decompile the bytecode back to Java source - was impossible was quite staggering. All sorts of plausible-sounding solutions were mooted, but they are all ultimately worthless. As long as I control the hardware, there's nothing you can do to prevent me from seeing data processed by it, all you can do is try to make it difficult.

Needs a Concatenation Operator

[ajs318]

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.

Re:Needs a Concatenation Operator

[shutdown -p now]

Plenty of other mainstream languages reuse + for string concatenation (C++, C#, Java), including dynamic ones (Python, Ruby). I haven't really observed any problems with that so far, but if you're really worried, you can always declare something like: function strcat(s1, s2) { s1.toString() + s2.toString(); } And use that throughout your code.

All in all, it's really a very minor issue.

Re:Needs a Concatenation Operator

[ajs318]

It's not a "very minor" issue. It's fundamentally broken. Essentially, everytime you want to add numbers, you end up having to subtract a negative number instead, or use ParseInt() / ParseFloat() to force things to be numeric (concatenating strings seems to be the default behaviour of +). This just looks messy (and coming from someone who uses Perl, that's a damning indictment indeed).

Your strcat() example is nice, but it can only ever concatenate two strings -- a limitation of the language. (JavaScript insists for every function to have an exact number of parameters; Perl functions can take as many or as few parameters as you like). So it soon gets unwieldy; you need separate functions to concatenate three or four strings. Or, more likely, to add different numbers of numbers:
function sum2(n1, n2) { return (n1 - (-n2)); }
function sum3(n1, n2, n3) { return (n1 - (-n2-n3)); }
and so forth.

I think awk has the best syntax for string concatenation .....

Re:Needs a Concatenation Operator

[Scarblac]

Python and Ruby may be "dynamic" in some sense, but in both of them string += int will cause an exception. They're strictly typed, just with dynamic binding. Javascript really is a bit odd in allowing += for both addition and concatenation, and giving no warnings if you mix types. That's the sort of fuzzy thing that you'd only expect in PHP.

Personally I think it's a pretty cool language

[CTho9305]

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.

Re:Why the pressure ?

[Shaper_pmp]

"Java Script / J Script is the devil. Development is a sloppy crap shoot, but we use it because it's there. It's now being used for ridiculous things that it was never really designed for."

What exactly is wrong with the javascript language? Everything you're ranting about is the fault of browser manufacturers and faulty/incomplete/deliberately broken implementations of javascript. The DOM support of various browsers sucks

Some news: Lisp would be shit if there were three or four wildly-divergent implementations, each claiming to be "the" lisp. And especially if the dominant version was a bastardised Microsoft Lisp-alike which everyone who didn't know better coded-to.

Javascript the language is actually quite compact, elegant and usable.

Re:It's not the best.... but it's not bad, either.

[Randolpho]

It helps to actually preview your posts. Here's the fixed version: Javascript has some amazingly powerful functional features that make it rival some of the great languages. That said, it is hampered by a lack of true object orientation. There are syntactic hacks that allow you to *fake* private methods/properties and inheritance, but they are not really features of the language.

It strikes me, however, that one of the best scripting languages out there, python, took a similar path. Once python had no object orientation, and people faked it with syntactic hacks. Then the syntax changed slightly and it was slowly added over the years, even as compatibility was kept with previous versions.

Javascript could take such a route. It's not a bad languages; it could get better.

Re:Disagree

[arevos]

In what bizarro world do you live where having a DOM interface means "a very reach featureset"?

I said, "As a language". Javascript's standard library is small, but the functionality the language itself supports is quite advanced. Closures, prototyping, mutable objects, and consistent OO (i.e. everything is an object), make Javascript rather flexible; just look at the additions Prototype has added in.

Javascript has no threads, the lack of thread control structure therefore doesn't matter much.

Ah, you're quite correct; Javascript is singled threaded. However, considering the amount of asynchronous callbacks from setTimeout, setInterval and XMLHttpRequest, one has to wonder whether the very lack of threading could not be construed as a disadvantage on its own. Since each Javascript function is axiomic, one would have to split up complex functionality to run across several functions.

I strongly disagree: Javascript has no standard library.

What do you mean by "Javascript"? Are you referring to the ECMAScript dialect (which, so far as I'm aware, does have a standard library), or are you using "Javascript" to mean "Any ECMAScript browser implementation" (in which case you are technically correct)?

Regardless, the standard libraries of JScript and Javascript overlap considerably, so although you can point out, quite correctly, that ECMAScript does not define a standard library per se (so far as I am aware), from a practical standpoint the major browsers have a number of EMCAScript objects in common, which mounts to the same thing as a standard library in practise.

Re:simplicity and power

[arevos]

The thing that makes it messy in C is C's strong typing, you would have to pass and return everything as strings, but this is to be expected since the problem is contrived to demonstrate the brevity possible with weak-typing. The trade off is that you don't know exactly what your dealing with. In well written scripts that's no big deal, in a system with thousands of source files written by dozens of programmers it will quickly turn your brain to mush.

It used to be that weak typing in a language was a BadThing(TM), now it's a "feature".

You're confusing weak typing with dynamic typing. C is not strongly typed; it has static weak typing. Languages like Java have static strong typing, Python and Ruby have dynamic strong typing, and PHP and Javascript have dynamic weak typing.

Javascript is the BB gun of Christmas Toys.

[Twixter]

Man is it fun; and useful! But sooner or later, you end up shooting your eye out.

//Create new Human
var human = new Object();
var ass = new Object();
var head = new Object();

//Assign properties to human
human.ass = ass;
human.head = head;

//Elect human to office.
human.ass.head = head;

Perfectly valid in Javascript, and in the real world.

(Browser as development platform)!=AJAX

[bcrowell]

I have a hard time understanding why I hear so many people complaining about JS as a language. I think a lot of Java programmers don't like it because it's not Java (not strongly typed, ...), and a lot of C++ programmers don't like it because it's not C++.

The truth is that you can do some pretty amazing stuff with JavaScript. My favorite demo is here. It's a web-based calculator, and if your browser has MathML set up correctly, it'll display your equation on the fly, as you type it, in standard math notation. For instance, if you type 1/(2+pi), it displays a fraction bar, with 1 on top, and 2+pi on the bottom (pi rendered as a Greek letter). (I think recent versions of Firefox have MathML and its fonts set up correctly by default, but if not, you can download the necessary fonts (instructions). For IE, you need to install MathPlayer.) What I think this calculator app demonstrates pretty dramatically is how powerful a development platform the web browser can be, without messing with the ugliness of AJAX at all. WYSIWYG mathematics typesetting is the kind of application that people used to pay $100 for ca. 1995, and now it's not only free, it's open-source, and it's an app that you can just run in your browser, without having to install anything.

The Download and Cache issues

[bryanbrunton]

While developing an Ajax application called Grand Strategy, an implementation of the board game Risk, I have found one of my main gripes with Javascript to be the download times involved with using large amounts of it. There are things that you can do to mitigate: gzip compression, displaying progress bars, use short variable and function names, and then caching. There are ways to do dynamic downloading of portions of a library; you can see these in Dojo. However, these dictate that you radically structure your code to support it.

It would be very nice if the whole browser based development environment had mechanisms to deal with the dynamic loading of javascript.

Next we come to the next major javascript issue: the unreliable browser cache. Users of my game will occasionally not be able to log in, or a portion of the game becomes unusable, even after having played the game for weeks on end. Inevitably, some javascript in their browser's cache will have become corrupted, or seemingly partially downloaded.

prototype.js

[Lothar]

I have one word for all of you: "prototype.js" ( http://prototype.conio.net/ ). The day I discovered prototype.js I stopped hating javascript. It also made me appretiate the really cool ways javascript lets you do inheritance etc + reading the prototype.js code really gets you learning.

If you also use Firebug (make sure you get the latest beta) for debugging then programming web and javascript becomes fun!

With prototype.js the javascript code becomes probably 30-70% smaller. No self respecting javascript programmer should be without prototype.js. It rocks!

Built an entire business application platform...

[holophrastic]

...solely on JScript. 800K of JScript, to be exact. It's not as fast as C, and it's not as fun as Perl, but you get a free rendering engine, free networking engine, and free interface engine out of it. So now, new business applications can be built, from scratch, within a few days: copmletely custom for the client -- layout, navigation, business logic, features, functionality, and security.

But hey, when it comes to JScript, I've found some pretty obscure language bugs.

developing for a moving target

[freezin fat guy]

The problem with developing Javascript code is that you are shooting at a moving target.

Unless the use is restricted to a highly controlled intranet setting it will be executed on an indeterminate set of runtime environments. Different browser vendors, different versions, different sub-builds... where does the madness end?

Unless you are doing something trivial you can wind up with several times the code necessary to get the job done on any one Javascript runtime. And bug testing? Well that takes far longer than it should for exactly the same reason.

I don't have a problem with the language itself. Or any one interpretation of the language to be more precise. But give me some solid footing.

Beef #2 - is your Javascript accessible to disabled users? Standard response: "F*** the disabled; they're a minority and we all know minorities deserve to be shot and pissed on." As I lack the Satanic vitriol necessary to punish people for unfortunate circumstances I find myself at odds with the Web 2.0 community.

Hell No!

[h4ck7h3p14n37]

Hell no Javascript doesn't deserve more respect. Unlike, say Java applets, there's no security sandbox so rogue Javascript code can connect to the network and leak information from the client system.