Slashdot Mirror

In most ways (no explicit integer type being an exception) Javascript is a remarkable and beautiful language. It has libraries available on a server near you through Dojo, among others. Javascript is one of the best things about browsers.

What browsers need is a workable CSS and DOM interface (although the DOM interface has improved in recent years). But these are not issues with Javascript per se. Cleaning up the browser programming environment is not about getting rid of Javascript.

From TFA: """
anyway, just thought there might be people who would be intrigued (or
horrified enough to care what's being done in the name of computer
science) by either of these projects.
"""

Not horrified, but I wonder if W3C politics is creating unforeseen consequences.

I was referring to XPCOM, which allows many languages (including C++) to have the same kind of dynamic binding as objective-c. It is used by firefox to implement plugins for example. Of course in C++ it looks messy as the management of XPCOM objects is exposed. In Javascript this management is hidden. There is nothing wrong with implementing the computationally heavy parts of an application in C++, and then using Javascript as the toplevel. Besides, Javascript is a proper object oriented language. Javascript is both object oriented (using the object prototype model) and supports closures (something neither C, C++, and objective C cannot manage). See: http://javascript.crockford.com/javascript.html

A hardcore, hard-hitting, take-no-prisoners storyline on a 360 or PS3 console would have a hard time making it past the nintendo comitees unscathed. See the Expurgation of Maniac Mansion for a famous case of this self-censorship that nobody really asked for: http://www.crockford.com/wrrrld/maniac.html

implemented differently across browsers

Not significantly. Certainly not more so than any other language with multiple implementations.

You might be confusing Javascript with the DOM and various other APIs. I'll admit, that has sucked in the past, but modern browsers tend to at least support standard ways of accessing the DOM, and libraries like jQuery hide that away.

In fact, this "WebGL" is precisely the kind of standardization that's meant to ease that pain.

it's loose type system playing havoc with math meaning you have to explicitly declare types anyway if you want things to work without suffering obscure bugs

I honestly cannot remember the last time I had a bug related to this.

the fact many important features like namespaces are pretty much just a hack

A pretty elegant "hack" -- I'm going to chalk that up to you not understanding the language.

the fact there's no decent tools for building and debugging Javascript apps?

Firebug.

At least those languages are well known, solid, and can be implemented well.

Javascript isn't well known? And if you're claiming it can't be implemented well, citation needed.

Or are you referring to the bytecode interpreters commonly used with those languages?

Javascript has several good VMs now, so no, that's pretty irrelevant.

There's no reason we can't have things run in the browser directly but with a better language and set of libraries to go with that.

Except that brings us to forcing people to download a new browser, or browser plugin, to support those languages and libraries -- thus removing a major draw of browser-based apps.

There's some irony in your argument in that you suggest we don't want to take steps back, whilst defending an outdated language.

If I was defending C, or even COBOL, you might have a point.

Like say, Java then?

Java is easily twice as verbose as Javascript, probably a bit more. Java is not only strictly typed, but explicitly typed, down to what kinds of exceptions a method might raise.

I prefer to write my app, not ream after ream of declaration.

Now, if you're arguing that the Java VM should be used, I'd say there are probably better choices, but that's at least a possibility -- I don't know what the state of Jython is, but JRuby is pretty solid. But the language itself is an abomination. It's like someone took C++ and asked themselves, "How can we remove features to make this even more annoying?"

Oh, and just for fun, some things Javascript can do that Java can't:

• Lambda Closures
• Function references (see above)
• Prototypal inheritance
• eval()
• singleton methods (foo.some_method = function(){...})
• monkeypatching (var old_method = Foo.prototype.some_method; Foo.prototype.some_method = function(){... old_method.call(this); ...})
• inheritance/reuse pretty much any way you want (see above two examples)

you're giving Javascript far more credit than it's due, it really is a crap language,

Here, go read.

I'll agree it could be improved. But I don't agree that it's a "crap" language, especially when compared to Java.

Reminds me of Nintendo's lock-down policies during the NES era.

Browser incompatibilities are not the fault of javascript. And no, it's not Java or C and that's a good thing. Get yourself a javascript library and quit complaining.

...and it will continue to fall until IE can get its act together. Browsers have evolved far past where they just need to render pretty CSS pages properly.

IE 8's Javascript may be faster, but it's still broken. When coupled with its garbage-quality garbage collector, this just means modern sites that use things like jQuery and Prototype crash sooner. IE has had trouble with their garbage for years now: JScript Memory Leaks, QuirksBlog: IE 7 and Javascript

Now this may all seem trivial to those who visit traditional sites and regularly restart their IE, but sites such as BattleCell can cause memory starvation issues within 30 minutes or less on IE.

Some people are initially surprised when we tell them to use any browser other than IE. Though, after a few months, their own conclusions of what this all means creates an effort barrier that Microsoft must overcome in order to bring people back...

I like C++ better than Javascript anyway :P

I can't remember if you're the one I talked to about this...

There are real reasons to prefer C++ to Javascript. The most common reason, though, is not knowing it well enough.

There are other languages I much prefer to Javascript, but C++ is not one of them.

no real this binding construct

Is there something wrong with "MyObject.prototype.mymethod = function() {};"? Or are you referring to the fact that a function can always be reapplied to a different object context? This is actually a feature, not a bug. It makes functions highly portable across your code. Yes, this means that passing a function as a parameter can create some issues, but that is what closures are for. Rather than creating entire objects to implement interfaces, you can create a very [i]private[/i] communication channel at any time with a closure. Doing this in a structured language like Java is a pain and a half and generally leads to the practice of exposed, but undocumented APIs.

Ever wondered where why your this in your function suddenly is something else?

Not since I understood Javascript scoping. Once that was done, my issues with what "this" is disappeared.

No scopes of visibility

This is a myth. A popular myth, but a myth none the less. Javascript works by implicit visibility rather than explicit visibility. Thus:

function MyObject() { var value = 0; /*private*/ this.pubvalue = 0; //public
this.getValue = function() { return value; };
this.setValue = function(newValue) { value = newValue; };
}

More info here.

no namespacing

There are more ways to do namespacing in Javascript than Carter has little pills. e.g.:

var com = {mypackage: {stuff: function MyObject() { } } }

Which can then be instantiated with:

new com.mypackage.stuff.MyObject();

Some people even use a helper function to reduce the vulnerability that a package will get overwritten:

function namespace(space) { var spaces = space.split("."); var index = 0;
function createSpace(parent, child) {
if(!parent[child]) parent[child] = {};
index++;
if(index < spaces.length) return createSpace(parent[child], spaces[index]);

return parent[child];
}

return createSpace(this, spaces[0]);
}

namespace("com.mypackage.stuff").MyObject = function() {};

But I don't recommend it. Usually you want to reduce your footprint to as little as possible. Zero is ideal. e.g.:

(function() {
var myvar;
function myFunction() {}
alert("I can put code here willy-nilly and it will never impact the parent context unless I specify. Weee!");
})();

Unless you need to share out public APIs:

var MyAPI = (function() {
function myFunc() {};
//Create a proxy object to expose only the public parts of this inner sanctuary.
return {myFunc: myFunc};
})();

If I were to sum up your complaints (and those of 95%+ of people programming Javascript) I would do it like this: You're trying to write C-Style code in a LISP-style language. Stop it. Things get better after that. :-P

Go watch this video series: http://video.yahoo.com/watch/111593/1710507 I guarantee you'll have a few "aha!" moments. Especially when it comes to scoping. Once you understand how to make JS scoping work for you rather than against you, life gets a lot easier.

The following text is garbage to make Slashdot's stupid filters happy. Ignore it. Apologi

And your own appeal to authority would work better if you had a little more respect for the most popular LISP dialect in the world. Seriously.

But consider two things: First, the storage is JSON (not JavaScript), and I don't actually know that it's the on-disk format (I doubt it), only that it's the format exposed to developers. What would you use in place of it, for a schema-free database? XML? ASN.1? Serialized objects in $my_favorite_language?

And for what it's worth, JSON is not just Javascript -- it's also valid notation (as in, you can pipe it through eval, if you really want to) for Python, Ruby 1.9, and probably others I don't know about.

The only better candidate I can think of is YAML, which is more complex to parse, and a superset of JSON anyway.

Second, the views (sort of a query language) aren't necessarily Javascript. It's true, Javascript is the default view format, but it can actually be any language that can operate on text sent via a Unix pipe. I hear Python developers are using it with some success.

But given the choice, would you rather write SQL than JavaScript? Really?

Of course, it also has the nice side effect that you can write an entire application in JavaScript, using AJAX, talking directly to the CouchDB server. But I'm guessing that's a side effect, not the real reason Javascript was chosen.

A good book, as mentioned earlier, is the O'Reilly book with the imaginative title "JavaScript". Other books I have seen are just downright wrong in places; there probably are other good ones out there, but that's the only one I've seen first-hand. Once familiar with the language, read all of this site: http://javascript.crockford.com/ He's got an O'Reilly book out too, linked from the page (I've never read it, but the guy knows his stuff).

And for the love of God, install Firebug.

Please keep me informed whenever anyone else makes it to level 80, I really don't want to miss any of their important in game breakthroughs.

Stuff that matters, indeed.

This actually represents a very important (albeit not new) lesson to MMO developers: you can spend months designing new content, but players will grind through much of it in hours or days, regardless.

It's *very* important for fledgling MMO designers to understand that. Many times, single-player and small-scale multiplayer game designers have built elaborate quests that would have taken a week to solve in a single player game, only to find that players solve them in hours. When you design content for an MMO, it's not you, the designer, versus 10,000 individuals, it's you the designer versus a few large and relatively well coordinated mobs.

Failure to understand that is grounds for major disappointment for all involved.

Of course, massively multiplayer gaming has been around in one form or another for at least two decades now (if you define "massively" as more than about 100), so this lesson is not a new one, but it never hurts to reinforce it, especially as the MMO market continues to grow, and this particular lesson continues to prove true for larger and larger games.

Reminds me of this article about releasing Maniac Mansion for the NES

http://www.crockford.com/wrrrld/maniac.html

I had a feeling someone would use this as a JavaScript-bashing opportunity. After all, JavaScript is the world's most misunderstood programming language.

I strongly suggest Douglas Crockford's articles on Javascript. He shows some neat tricks, good style, and deep understanding.

Of course read the official documentation and reference material; but to become a better JavaScript programmer, get a copy of the The Little Schemer and check out Douglas Crockford's The Little JavaScripter. You may also like to read some of the other stuff Crockford has to say about it.

Of course read the official documentation and reference material; but to become a better JavaScript programmer, get a copy of the The Little Schemer and check out Douglas Crockford's The Little JavaScripter. You may also like to read some of the other stuff Crockford has to say about it.

Though they were the logical starting point, I am grateful to be mainly past my reliance on books. However, based on how good his videos (e.g. http://javascript.crockford.com/, http://yuiblog.com/blog/2007/01/24/video-crockford-tjpl/) are, I would consider checking this one out.

Crockford's website has a bunch of great articles about JavaScript. I've learned quite a bit from there.

http://www.crockford.com/javascript/

• Cappuccino and Objective-J aim to completely abstract away the inconsistencies of the browser DOM (JavaScript the language itself is fairly consistent across browsers)
• Objective-J brings classical inheritance to JavaScript, which has much more familiar semantics to most people than JavaScript's prototypal inheritance
• Regardless of Objective-C's syntax, have you seen some of the syntactical hoops JavaScript programmers jump through to get pseudo-classical inheritance? Just check out Crockford's JavaScript pages and his new book. There's about a half dozen different ways to do it, none of which I find particularly elegant.

It's not a claim:

JavaScript Programming Language: The language everyone loves to hate

Javascript and LISP

Douglas Crockford's page on Javascript

As far as your last point regarding how Javascript is being widely taught and used, all it states is a major problem with the way the language is understood. Just because a language is taught a certain way doesn't mean that the language IS that way. If you delve deeper into Javascript you'll see that it's more like lisp and less like C or Java.

If you consider what these guys are doing with JavaScript 1, then can anyone tell me why we need JavaScript 2?

(Hint: We *don't*.)

You're Too late (sort of - just an interpreter)

That's funny.

Maybe you should actually look up the very history of Javascript -- the programmer wanted an embedded LISP. Some PHB-type wanted it to look like C, so it would be more approachable. So he took his embedded LISP and gave it a C-like syntax.

Or maybe you should've Googled about Lisp and Javascript. Here, go read.

Thanks so much for all the great information about Javascript. As Doug Crockford says, it's The World's Most Misunderstood Programming Language Just a few months ago I started a project (in my spare time of course) to see how I could push my knowledge of the language, and I came up with this: Track Attack. It's far from complete, but uses Javascript for everything except sound (which uses an API to flash to handle it). The browser isn't taxed too much (after some tweaking on the music) and it was a fun experiment. All the code is in-line so that you can view the source quite easily. Kind of off-topic, but I thought I'd throw it out there. Javascript can be useful in the right hands.

You're going to be really glad you bought that Definitive Guide in a year or two. It's (IMHO) the best reference for javascript out there.

I recommend reading up on the work of Douglas Crockford and John Resig when you want to get into more advanced javascript.

Which is why Douglas Crockford calls it the world's most misunderstood programming language.

You can read his proposal in full over here: http://www.crockford.com/html/

That's the first link in the summary, moron.

You can read his proposal in full over here: http://www.crockford.com/html/

Make sure you have about 2 minutes to spare. You're going to need about that long to read it from beginning to end. What you'll probably find is that he hasn't really solved any of the major issues plaguing HTML or even thought through many of the problems and use-cases that HTML 5 is trying to solve. In fact, his entire "design" can be summed up with the following sentence: "Let's get rid of HTML features that I believe cause problems."

Meanwhile, he still leaves the problems of consistent parsing, semantic meaning, multimedia presentation, and a whole host of other issues unaddressed. Which means that his "design" fails to compete with the intended purpose of HTML 5 at even the most basic level.

I have the highest respect for Mr. Crockford, but my opinion is that he should study the reasons behind HTML 5 a bit more carefully, as well as solicit a bit more feedback from the community before attempting to push a non-solution to their problems. Best of luck to him. :-)

Javascript is an ugly, inconsistent (in and of itself as a language let alone the browser differences) beast, and I don't know of too many people who enjoy dealing with it

Yes and no. Nintendo used to gaurentee that the game's content met certain standards for one. In the days before the ESRB, Nintendo policed content on their consoles. Remember the Mortal Kombat fiasco? Or perhaps read up on the story from one of the developers who ported Maniac Mansion to the NES.

Secondly, the seal was a licensing gimick. Basicly during at least the early NES days, maybe all of the NES days, Nintendo would only license a certain number of titles for release withing a certain time period. Let's say for the sake of argument that it was one per month. The idea was to ensure that developers weren't producing shovel-ware, which was critical in the days after the video game collapse at the end of the Atari era. (Some developers got around it however via spin-off companies. Ultra, for instance was a subsidiary of Konomi, which allowed them to double the one per month rule. I'm sure there were others as well.) The seal was also a way in those early days of reassuring consumers who felt burned by the last years of Atari.

Wait...So console makers do the whole "morality police" thing regarding what games are released on their consoles? WTF?

Thank You!!

I was just about to say all those things until I read your comment. JavaScript is actually quite nice once you actually learn it beyond using alert.

Check out http://javascript.crockford.com/javascript.html for info on why JavaScript is so misunderstood.

The fact that functions are objects is cool but I have many complaints about JavaScript. The implementation of object orientation as a hash table with a dot notation is a far cry from object orientation.

You could come up with a fine case for type safety issues, but I'm just not seeing your Far Cry from Object Orientation here.

http://www.crockford.com/javascript/private.html

Of course, you'll need a decent library like MooTools or Prototype or such if you want to keep your programming sane, and especially if you want to do good stuff in a web browser (they abstract away an enormous swath of the IE vs Mozilla-type vs Opera/etc compatibility issues).

Here're some really good links about JavaScript:

http://www.crockford.com/javascript/

http://javascript.crockford.com/javascript.html

Clubbing server-side Java and client-side JavaScript is also something interesting:

http://getahead.ltd.uk/dwr/

Here're some really good links about JavaScript:

http://www.crockford.com/javascript/

http://javascript.crockford.com/javascript.html

Clubbing server-side Java and client-side JavaScript is also something interesting:

http://getahead.ltd.uk/dwr/

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.

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.

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

Despite its popularity, few know that JavaScript is a very nice dynamic object-oriented general-purpose programming language. How can this be a secret? Why is this language so misunderstood? ...

JavaScript's C-like syntax, including curly braces and the clunky for statement, makes it appear to be an ordinary procedural language. This is misleading because JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java. It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures. You get lambdas without having to balance all those parens. ...

Never in my wildest pre-crash dreams did I ever think that Javascript would become a respectable programming language.

Despite its popularity, few know that JavaScript is a very nice dynamic object-oriented general-purpose programming language. How can this be a secret? Why is this language so misunderstood? ...

...JavaScript's C-like syntax, including curly braces and the clunky for statement, makes it appear to be an ordinary procedural language. This is misleading because JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java. It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures. You get lambdas without having to balance all those parens.

Ah, yes. The NES version which was famously RAPED by Nintendo's stupid censorship rules.

Almost makes me not want to support Nintendo, still.

Javascript would be a great language for teaching, it shares a lot of syntax with other popular languages (c, java, c++), but avoids the low-level details that would intimidate a beginning student. The big disadvantage to using javascript is that people only think of it in relationship to a web browser. Most javascript tutorials are about how to acheive some lame text-blinking effect, and aren't really about the language itself. A noteable exception is Douglas Crocford's Javascript page: http://www.crockford.com/javascript/, but that is really advanced stuff that would make a beginner's head spin.

Why is it so important to you?

Because, as I already said, JavaScript is not a compiled language. Convience methods are strictly convenient for the programmer, not for the person on the other end of the pipe who's actually using the program. They couldn't give two shits if you saved yourself from future RSI. Because it's not a compiled langauge, convenience methods come at a cost of execution speed. Which means every cutesy $() or A() function is slowing down your user's environment. A lot? No, of course not. But it adds up. And that's the problem with these libraries: a series of steps to make JavaScript appear--at least to the programmer--like a real programming langauge (getters and setters, classical inheritance, etc.). But these are abstractions that offer no real benefit, just useless cycle overhead on the client's machine.

Anyway, if you're manipulating hundreds of elements every second and are concerned about the overhead of the $ method, perhaps javascript or even a web app is not for you. In fact, maybe it isn't regardless.

One doesn't have to be manipulating hundreds of elements every second to see a performance hit. And I don't even understand the last part--why wouldn't a web app be for me because I care about performance? You wouldn't happen to work in Redmond, would you?

I'm a linguist and an English teacher in Japan and frequently have to deal with the irregularities of English spelling, however apart from the occasional problems with 'l' and 'r' and 'b' and 'v' most of my students master English spelling fairly quickly.

While researching for material for my Masters a few years ago I came across this: Yntrodxkshxn tu Nuspelynh

While the writer seems to have an understanding of the topic is is writing about he has missed a very important point; not all English speakers sound like Americans. Hell, not even all Americans sound like Americans; there is significant regional variation in pronunciation throughout that country. To simplify spelling so that pronunciation and spelling matched we would either have to force EVERYONE to pronounce words the same way or all English speaking countries will have a different way of spelling.

When doing undergrad Anthropology I learnt that one's way of speaking is central to one's culture. Early researchers in Australia came upon cases of groups that intentionally changed the way they spoke. As I recall (and it was a bloody long time ago, so don't quote me on this) a group from the Gold Coast area split into two tribes, one moving to Stradbroke Island. The group that moved changed the way they spoke to clearly differenciate between themselves and the former tribe they were a part of. Enforcing the idea of 'us' vs 'not us'.

So, if we standardise and simplify spelling, who is going to give up their way of speaking? I know that I have no intention of EVER sounding like an American, nor do I want to sound like a New Zealander, or a Canadian. No offence intended to people of those countries, but I am NOT one of you and don't wish to be thought of as one of you. Of course if this were to happen there would no longer be a case of 'us' vs 'them'.

What we have no may be difficult for some people to learn, but that is the point. It demonstrate the diffeerence between those who put in the effort to learn and those who don't. For those who can't (surely a minority), we shouldn't lower the bar to help accommodate the weakest, we should find ways of enabling everyone to achieve the same level.

The best example is Infocom's Sorceror. There are a few complicated Time Travel puzzles in that game, one occuring almost at the very start of the game. If you don't solve it, the game lets you blithely go on, and get very far, never realizing that if you don't have the item from the first time travel puzzle, you'll never, ever beat the game! It won't tell you, "You lose!" either, you'll just wander around until you give up.