Trying To Bust JavaScript Out of the Browser

eldavojohn writes "If you think JavaScript is a crime against humanity, you might want to skip this article, because Ars is reporting on efforts to take JavaScript to the next level. With the new ECMAScript 5 draft proposal, the article points out a lot of positive things that have happened in the world of JavaScript. The article does a good job of citing some of the major problems with JavaScript and how a reborn library called CommonJS (formerly ServerJS) is addressing each of those problems. No one can deny JavaScript's usefulness on the front end of the web, but if you're a developer do you support the efforts to move it beyond that?"

Comments

javascript is good

[runyonave]

it's just sometimes, it's a resource hog.

Re:javascript is good

[binarylarry]

"javascript" is essentially just a language specification, how it manages memory and other resources is implementation dependant.

A javascript program could be interpreted as has been in many web browsers, JIT compiled to native code like Java (which is getting more popular) or even be fully compiled to native code ahead of time.

Re:javascript is good

[s4m7]

I know I shouldn't feed the trolls but...

Whether or not current browser implementations of javascript are or are not a resource hog is not at issue here. This article, and thus the discussion, are about a new implementation for the server. Unless you have used and experienced this particular server-side implementation, you cannot say something like

when an app is written in JS it is more likely to be a resource hog than the same app written in compiled C

Because you don't know. I'm willing to bet that you haven't benchmarked it, and that you can write code in neither language, so in reality you have no idea what you're talking about. Maybe you can come to understand why and learn from that, if you so choose.

Re:javascript is good

[kbielefe]

so until and unless major browsers start implementing things like JIT compilation

Wish granted (at least for chrome).

Re:javascript is good

[parlancex]

How about those demos where Google was demonstrating V8, one of the "fastest" JS implementations available, which DOES use JIT to native machine code? They were PROUD to demo like a few hundred bouncing balls on a modern computer at not even 60 fps.

Written in C you could write an app to draw and compute the motion of tens of thousands of fucking balls at 60 fps on a modern computer.

Within 2 orders of magnitude is not "close" to C performance. Within 2 orders of magnitude is not "acceptable" performance.

Re:javascript is good

[onefriedrice]

... you cannot say something like

when an app is written in JS it is more likely to be a resource hog than the same app written in compiled C

Actually, that's a perfectly reasonable thing to say, albeit pointless because of the obviousness of it. It doesn't matter what runtime implementation you use, Javascript will always use more resources than an equivalent C program can, if only because of the overhead of the unused but still loaded runtime features. That doesn't mean Javascript is necessarily a resource hog, but the statement your quoted is not very outrageous, especially since he qualified the statement with "more likely."

Re:javascript is good

[GreyLurk]

It's true that probably the majority of the JavaScript apps built to this point are bad at memory management, from a percentage based view. I would also venture to guess that more programs have been written in JavaScript in the last 10 years than in C or Java, and more of those were written by developers with little or no training. That doesn't mean that the language is bad, just that the training level of the JavaScript community on average is low.

There are good JavaScript applications being built by skilled developers that are not resource hogs and which run very fast and efficiently on powerful JIT-based VMs. Just because there's a lot of bad JS written by a lot of bad developers doesn't mean that the language is inherently flawed... There are lots of bad C apps written by bad C developers too, they just don't have as wide an audience.

Re:javascript is good

[Toonol]

It's no more a memory hog than any number of other interpreted languages with garbage collection... and LESS of a hog than some JIT compiled languages. I certainly don't cringe when Javascript kicks in like I do when I happen across something written in Java.

The only real problem with Javascript was how it was historically integrated into webstandards... I think that the whole concept of autoexecuting scripts or embedded objects in web pages is flawed. THAT's the reason people hate javascript, flash, java applets, and so on. Too late to fix it now, I suppose.

By the way, you sound foolish accusing the GP of being a fanboy. That accusation makes you seem less rational and more biased than the poster you're accusing of being such.

Re:javascript is good

[Toonol]

You'd expect that, but it's often not the case. As I said in another post, compare Javascript to Java. Which of those tends to bring your browsing experience to a crashing halt? Yes, Java certainly outperforms Javascript... once it finally gets moving... and if you ignore the performance hit to your entire system caused by having the run-time engine active in memory.

JIT compilation may be overkill, when a large portion of scripts are often nothing more than three lines of code, doing a task like incrementing a counter or checking to make sure the value of a field falls between 0 and 100. Responsiveness is more important than actual execution speed.

Re:javascript is good

[Randomly]

Java Script requires so many additions you might as well revise the whole strategy. Along with the next release of the Java Script, defining a standard web virtual machine on which JavaScript is initially implemented could provide many advantages:

- Develop using the same language in the browser as you are at the server.

- Translate classes or assemblies to and from the web VM using technology similar to JNBridge http://www.jnbridge.com/, opening to the door to all Java and .NET languages.

- An XHTML element could specify the URL for a compiler or interpreter, providing complete compatibility initially and opening the door to many possibilities in future.

Re:javascript is good

[cfalcon]

Mod parlancex up.

Re:javascript is good

[Spliffster]

This is silly. The story is about a common Serverside Javascript implementation standard and not about whatnot is faster. For those who haven't RTFA it's about standardisation of JavaScript on the server side (JS has really only lived brightly in the browser so far with it's enormous install base on the client side). Cheers, -S

Re:javascript is good

[Toonol]

Interpreted code will certainly be slower than compiled code, but there are cases where it may be more space efficient. It usually isn't, and I don't think Javascript would ever be, but interpreted code CAN be.

As is usual, when comparing languages (or most anything else), saying one is better than another might be too vague... you should include WHAT they're better at. Interactive debugging is often better in interpreted languages, for instance.

Re:javascript is good

[Spliffster]

You have read the fine article, did you? This was about serverside javascript (not Java Script, it really isn't Java) concerning a common server side js framework.

Re:javascript is good

[binarylarry]

Java's big problems are a much too large standard library that has to be loaded on startup and an old bytecode verifier.

It has little to do with the JIT, as all applications runs in interpreted mode first anyway.

You're talking out of your ass.

Re:javascript is good

[Toonol]

You're talking out of your ass.

That's a childish comment, and you should refrain from those. It tends to make readers think there's not much substance to what you're saying.

It has little to do with the JIT, as all applications runs in interpreted mode first anyway.

Except that it proves that the details of the specific implementation, and the scenarios in which they'll typically be used, is FAR more important to quality and performance than whether a language is pre-complied, JIT, interpreted, or whatever.

Re:javascript is good

[parlancex]

The summary posed the question if this was something that should be perceived as a good thing; the evolution of JavaScript out of the browser and into more processing intense applications.

Summarily, no. It isn't.

Re:javascript is good

[Randomly]

Yes of course. I am assuming the only reason to refine Java Script on the server is to leverage revision across all platforms on the client side. After all, only a lunatic would choose Java Script as a server side language.

Re:javascript is good

[minister of funk]

It is a perfectly reasonable thing to say if you're compiling JavaScript to an executable, which you're not.

You could say, "When an app is written in JavaScript is it likely to [use more resources] than the same app written in PHP..."

You can say this because Server-side JavaScript and PHP operate in the same environment at the same level.

Statements like these require qualification to be valid. Server-side JavaScript may be more resource intensive than PHP because the library is younger.

Re:javascript is good

[Short Circuit]

If you thought the point of that demo was to show that JavaScript is suited for early-90s mass animation tasks, you're sorely mistaken. The point of a demonstration like that is to show that a language with a very complicated feature set, and normally without an optimizing compiler, can be made to execute at a much greater speed than generally assumed.

Animation just happens to be one of those problems that are known to be performance-sensitive while also having the benefit of serving as a visual aid. It's not the peak demonstrated value, it's the delta; Without their engine, how fast would have that animation code have run, otherwise?

Javascript is actually a great language

[BadAnalogyGuy]

Dynamically typed, object-oriented, with features like lexical closures that are usually only found in advanced programming languages like Lisp, Javascript is really a great language that has gotten a bad rap.

It reminds me of the lowly tomato, a member of the poisonous nightshade family of plants, which for years was considered to be inedible. These days you can't get a salad without it. Things change when you realize how useful something actually is.

Re:Javascript is actually a great language

[pasadena]

I never eat salad with tomatoes, and I avoid programming in JS where I can.

Re:Javascript is actually a great language

[iamacat]

Perhaps it's a great language, but it reduced modern Core i7 computers to performance of a 486, negating 15 years of computing revolution. Inability to perform CPU-intensive computations due to these dynamic types of yours, lack of threading or any other explicit or implicit parallelism support, no library facilities to modern 2D/3D graphics libraries. Javascript is a nice experimental language like so many others but it shouldn't be running 90% of mission-critical applications.

Re:Javascript is actually a great language

[OverlordQ]

Or maybe more like Oxygen, poisonous in high concentrations (re: pressures).

Re:Javascript is actually a great language

[XxtraLarGe]

It reminds me of the lowly tomato, a member of the poisonous nightshade family of plants, which for years was considered to be inedible. These days you can't get a salad without it.

Javascript reminds you of tomatoes? My favorite salad seldom seems to have tomatoes. I see how you got your nick name ;-)

Re:Javascript is actually a great language

[maraist]

With no feature-set testing capability coupled with the intent of handing off raw code to 3rd party virtual engines. With no 'reference' platform to validate code (with such simple things as which string functions are supported) and no useful error messages when making language library mistakes (nor any type-safety to determine it out of the box). And with respect to dynamicity, no equivalent 'perl -c foo.pl', 'use strict', or '-warn' pragma. No package namespaces. No legitimate mechanism of loading 3'rd party library files, much less a way of namespace collision resolution/isolation. No defined order of execution (some run in-line, others run on browser completely loaded, etc).

I'd instead say that Javascript is a frustrating language that's gotten too much rep. The fact that people migrate towards 3'rd party libraries to standardize simple programming operations (like jQuery / GWT) is a testament to how bad it's legacy has gotten - when trying to do 'real' work.

Sure a command-line javascript can define it's own standard and I'm confident that it can solve all these problems.. That's the great thing about standards - everybody's got one.

Re:Javascript is actually a great language

[Blakey Rat]

Most of Javascript's bad reputation come from the W3C's DOM. When the majority of programmers think "Javascript," they're actually thinking "Javascript + DOM," and since the DOM is so awful, they think Javascript is awful as well. Not so.

Pair Javascript with a decent library, and it's extremely powerful. Maybe not as suited for large projects as languages with namespaces, but its template system and introspection features are simply amazing. If anybody ever writes a program that evolves itself until it becomes super-intelligent and takes over the Earth, it'll probably be written in Javascript.

Correction to the parent, though: Javascript isn't an object-oriented language in the classic definition of the term... it lacks many features to make it truly OOP. Instead, it's based around object templating, which is nearly as powerful, but not the same thing.

Re:Javascript is actually a great language

[slug359]

Here's my three favourite language flaws, which make the language nearly unusable for non-trivial projects:

• Variables are global by default, leading to accidental memory leaks, conflicts and various other fun things.
• A lack of namespaces.
• Lack of block scope (despite the fact the language has blocks), i.e:

  function a() {
  var b = 1;
  {
  var b = 2;
  }
  alert(b);
  }

  will alert 2.

Re:Javascript is actually a great language

[TooMuchToDo]

Javascript is a nice experimental language like so many others but it shouldn't be running 90% of mission-critical applications.

But alas, it's driving a majority of the web.

Re:Javascript is actually a great language

[sproketboy]

Huh?

        var a = "false";
        if (a) {
                alert("a is true?");
        }

Evil type coercion is a foundation principle of this shitty language.

Re:Javascript is actually a great language

[mcrbids]

Javascript makes many hard things simple, and many simple things hard.

Need to find out what the user typed in box foo? While most client libraries require fairly detailed memory schemes in order to keep track of which box is which, Javascript reduces all that to getElementById(); - a win in any programmer's book!

But in the reverse, what about trimming that input? The offense to the mind that you have to use a USER DEFINED FUNCTION for trimming just boggles the mind. Sure, there are libraries for this, blah blah but still, the truth remains that there is no trim() function. The lack of any kind of meaningful class structure makes the special word "this" almost worthless because you can't be sure consistently what it's referring to. (yes, it is possible to figure it out, but why should you have to?) If you delete an array key directly with the delete command, eg: `delete myArray[4];` the length property doesn't get updated even though the number of elements in the array does. (WTF?!?!)

So javascript has its warts. Lots and lots of them. It is clearly a hacked-together language that is only successful because of its ubiquity, which is the same reason why it evolves so extremely slowly, which is why we still have to manually implement things like trim(), and why so many of us are doomed to deal with javascript with all of its warts.

Javascript, however, has been free of the browser for some time, due to the Mozilla's JS engine being modular. They call it spidermonkey, and I actually considered using it as a replacement for PHP on the server side in order to keep langauages consistent. Unfortunately, nobody's embedded it into Apache as a module (with any kind of stability) so this means that js scripts would have to run as separate executables, which causes all kinds of performance and security problems.

Re:Javascript is actually a great language

[Blakey Rat]

I'd instead say that Javascript is a frustrating language that's gotten too much rep. The fact that people migrate towards 3'rd party libraries to standardize simple programming operations (like jQuery / GWT) is a testament to how bad it's legacy has gotten - when trying to do 'real' work.

jQuery (prototype, mootools, etc) solves shitty DOM implementations, not shitty Javascript implementations. In fact, I don't think jQuery addresses a single "lack" in Javascript-- I could be mistaken-- virtually everything, if not everything, it does is fixing DOM's bad design and browser's inconsistent implementation of it.

This is why Javascript gets a bad rap: pair it with DOM, and *any* language would look awful, because DOM is awful.

Re:Javascript is actually a great language

[TheRaven64]

JavaScript is a Self dialect with ugly syntax, a broken model for unboxed numeric values, monumentally broken semantics for closure evaluation, and no sensible second-chance dispatch mechanism. Oh, and all current JavaScript implementations are slower than the Self VM from a decade ago.

Apart from that, it's a great language.

Re:Javascript is actually a great language

[sydneyfong]

- The speed issue is largely due to the crappy implementations of Javascript, which are improving due to competition among browsers. Javascript can be JIT-ed. What you probably can't do is compile it to native code and expect it to have the speed of C/C++. But then would *you* run arbitrary native binary code off the web? Sandboxing makes things slow again.

- I'll give you the lack of threading.

- 2D/3D libraries - C doesn't have one in its standard, C++ doesn't have one, in fact most don't. But you're free to implement one. It just doesn't make too much sense having a full fledged 2D/3D library in the browser, since that's where most javascript code are used in.

- experimental language, as in first appearing in 1995, used extensively for almost 15 years. Of course most people never really utilize its full power, but it's not the fault of the language

- And you use a "mission-critical application" written in Javascript running inside a web browser?

Don't ditch the language due to poor implementation and crappy users.

Re:Javascript is actually a great language

[gbjbaanb]

and I actually considered using it as a replacement for PHP on the server side in order to keep langauages consistent.

I always thought that would be a good thing - consistency in language means you don't have to learn 5 or so to do meaningful work. Unfortunately, whilst MS appears to agree with me (everything in C#), the rest of the world doesn't. So until we get a javascript world takeover, we'll be stuck with PHP, Perl, Python and Java server-side systems. I'd love for one to win, and JS may as well be the one as its used almost exclusively on the client side too.

(BTW, deleting an array element may reduce the number of elements in the array, but doesn't delete the storage allocated to it - that's probably an optimisation, and isn't such a bad thing).

Re:Javascript is actually a great language

[Blakey Rat]

Need to find out what the user typed in box foo? While most client libraries require fairly detailed memory schemes in order to keep track of which box is which, Javascript reduces all that to getElementById(); - a win in any programmer's book!

That's DOM, not Javascript.

But in the reverse, what about trimming that input? The offense to the mind that you have to use a USER DEFINED FUNCTION for trimming just boggles the mind.

That's a lack in DOM, not a lack in Javascript.

So javascript has its warts. Lots and lots of them. It is clearly a hacked-together language that is only successful because of its ubiquity, which is the same reason why it evolves so extremely slowly, which is why we still have to manually implement things like trim(), and why so many of us are doomed to deal with javascript with all of its warts.

No, Javascript is very nice. DOM is a piece of shit. Pair any language with DOM, and you'll think that language sucks.

What makes me sad is how many Slashdotters don't know the difference between the language and the libraries. DOM is nothing but a set of libraries-- you could code DOM in C#, Python, Java, whatever.

Saying DOM sucks says nothing about Javascript.

That said, this:

The lack of any kind of meaningful class structure makes the special word "this" almost worthless because you can't be sure consistently what it's referring to.

Is actually a language issue. Most people solve it by using the dumb workaround "var that = this" in their objects. That gives you a consistant "this", but it's kind of a retarded work-around.

If you delete an array key directly with the delete command, eg: `delete myArray[4];` the length property doesn't get updated even though the number of elements in the array does. (WTF?!?!)

That one I can't speak to... interesting if true.

Re:Javascript is actually a great language

[Rogerborg]

It reminds me of the lowly tomato, a member of the poisonous nightshade family of plants, which for years was considered to be inedible. These days you can't get a salad without it.

That's not even remotely true. When I'm driving a car load of drunken cheerleaders to the abortion clinic, and I stop off at McDonalds, I enjoy an unequivocal Constitutional right to shoot the McMonkey in the balls if he puts tomato in my salad after I've told him not to.

Re:Javascript is actually a great language

[Rayban]

All strings coerce to boolean true in JS, as they do in C (with the exception of the empty string):

char* a = "false";
if (a) {
    printf("a is true?\n");
}

In fact, most values coerce to true except integer zero, NaN, undefined, null and empty string.

Re:Javascript is actually a great language

[DoofusOfDeath]

Dynamically typed, object-oriented, with features like lexical closures that are usually only found in advanced programming languages like Lisp, Javascript is really a great language that has gotten a bad rap.

I for one wish JS have the same broad success as Lisp!

Re:Javascript is actually a great language

[Anonymous Coward]

Adding to performance issues comment: Javascript actually becomes *faster* if you make your variable names short... 'cause everytime you do a.x it actually does a['x'], or the fact that there are no "arrays"; a[1] does a['1'], or something similarly silly. Recently tried writing a 3d animation thingie [canvas], and it's painfully slow---stuff that shouldn't be slow [and isn't in something like plain-old Java].

I really really like Javascript itself [I'm a Perl coder, and *much* of javascript reminds me of Perl]; It's very flexible, and you can prototype and conceptualize anything in it with relative ease... but they've made quite a few stupid design decisions to make performance a major issue.

Re:Javascript is actually a great language

[Ed Avis]

1. Of course the CPU-intensive parts of an app (compression, encryption, database things like DBM or SQLite) are still in native code and Javascript is just a wrapper. 2. The new generation of Javascript engines (Google's V8, Mozilla's Tracemonkey, etc) are one or two orders of magnitude faster than the Javascript interpreters of a few years ago. Not nearly as fast as native code, of course, but certainly good enough for a lot of applications. 3. You're right that threading and parallelism is missing. And also it's true that there aren't enough language bindings to good graphics libraries, though of course the browser itself is a powerful 2D engine for many tasks. Also, have you looked at WebGL, a Javascript binding to OpenGL?

Re:Javascript is actually a great language

[FunkyELF]

Bad idea. The fact that you have to use different languages separates domains as they should be.
Django does something similar by using a templating language that is not Python and runs in a different context.
I feel that if you start putting JS on both client and server you'll start to blur the line between client and server and make the code much harder to read. You'll start using some of the same routines in both client and server. With separate languages you make sure that those types of things are only done once, in the correct place.

Re:Javascript is actually a great language

[Anonymous Coward]

Perhaps it's a great language, but it reduced modern Core i7 computers to performance of a 486, negating 15 years of computing revolution.

Actually of the scripting languages, JavaScript is one of the most optimizable. In particular everything-is-float lets interpreters and JITs have a simple fallback mode when they don't know if the value is an int or if it will overflow. They can also use fpu registers to store values, and interleave fpu and int operations.

For instance if you have like in Python an int32, unlimited precision decimals, complex, float that's 4 completely separate representations for 16 combinations of interactions for most math operators, which basically means a vtable-style indirect function call that can't be avoided unless all the types are known in advance. It also means in a complex formula changing any variable's type means the actual machine code has to change, whereas javascript can just convert the type to a float beforehand and use the same compiled code.

Re:Javascript is actually a great language

[shutdown -p now]

Dynamically typed, object-oriented, with features like lexical closures that are usually only found in advanced programming languages like Lisp, Javascript is really a great language that has gotten a bad rap.

Great language? Let's see:

function foo(x) {
    var y = 123;
    if (x > 0) {
        var y = 456;
    }
    write(y); // 456!
}

I think I see why it has gotten a bad rep now. And no, it's not all just about DOM (though that certainly played a part).

Don't get me wrong, some of the ideas in JS are great (though in all cases it wasn't the one to pioneer them). But their implementation in this wannabe C-style language is not. If you want to see a neat and really well designed language built on the same ideas, see Lua.

Re:Javascript is actually a great language

[fulldecent]

so when is dom2 coming out?

Re:Javascript is actually a great language

[shutdown -p now]

Correction to the parent, though: Javascript isn't an object-oriented language in the classic definition of the term... it lacks many features to make it truly OOP.

Today, OOP is generally considered to encompass prototype-based programming as well. If you mean "classic definition" as defined by Simula and Smalltalk, then it makes sense, but it hasn't been used as such for ages (since Self).

Re:Javascript is actually a great language

[MobyDisk]

Javascript is too dynamically typed. In my experience, testers constantly find bugs caused by type-mismatches, misspelled variable names, or other basic things that a compiler could have detected. The next most common set of problems is that Javascript generally doesn't report errors right away: they show up 200 lines later. Suppose a variable doesn't exist when it is referenced? It just makes one up right there on the spot, and assigns it a null value. That's terrible. Then there's the null -vs- undefined mess that constantly trips-up even experienced programmers.

Re:Javascript is actually a great language

[maxume]

Array(5000) will create an array with 5000 empty slots, so it isn't that surprising that deleting the object stored at a particular location doesn't alter the array.

Re:Javascript is actually a great language

[JasterBobaMereel]

Tomato - The only member of the Solanum family that has non-toxic fruit, used in almost every salad and sandwich simply because it is cheap and easy to get hold of and looks pretty... not because it is the best, or everyone likes it

Javascript - A fundamentally badly designed language that happens to have some nice features all of which are better implemented in nicer languages, which is only used in browsers because it is universally available, and is not used elsewhere simply because it is never the best option ....

It is not a good scripting language, not a good embedded language, not a good dynamic language, not a good language for closures, not a good object oriented language etc ... it is merely adequate

Re:Javascript is actually a great language

[Inda]

I used to love writing JS server side (ASP + IIS). I only stopped because of the lack of examples and documentation on the net. VBS became the norm - yuk.

Re:Javascript is actually a great language

[TheSunborn]

The problem with the array thing is that javascript don't really have arrays as a native type.

An array is really just an object with some fancy methods that allow you to use it array like. But their abstraction really sucks, because the length property don't give the number of elements in the array, instead it gives the index of the element with the highest index in the array.

This is done because an array which contain 4000 objects, really is just an object with 4000 data fields, and a few fancy methods. So the array don't really have a size as such. (Yes this sucks, and you can't just count number of fields in the object, because it also will have fields that the user have not added as members to the array).

An other and much bigger wtf is that the this reference is not always a reference to the object where the currently executing method
belong to. And this is by design, not just an implementation bug.

Re:Javascript is actually a great language

[Procasinator]

The absence of a trim method is not a DOM problem: I should be a method available on String.

As for the lack of this consistency, this is due how Javascript scopes references to methods. Being able to change this behaviour can be handy at times, but often not the expected behaviour.

Read http://www.alistapart.com/articles/getoutbindingsituations/ to see how apply/call can help set-up the correct binding for this and a method.

JavaScript behaves this way to support prototypal inheritance.

Re:Javascript is actually a great language

[Nadaka]

xhtml2 specifies precisely how DOM is to be structured. Unfortunately it looks like html5 is winning hearts and minds as the next markup language for the web (mostly because it is more backwards compatible and supports soft failure modes for non-compliant code).

Re:Javascript is actually a great language

[QuoteMstr]

Your comment is a decade out of date. No modern Javascript engine operates the way you describe. They cache object properties such that property access is fast, and independent of property name length.

Your 3D code is slow for other reasons. As a hunch, I bet you're doing a lot of unnecessary string-to-Number conversion.

Re:Javascript is actually a great language

[JasterBobaMereel]

...no it is easy to optimise because it is badly designed and mostly badly implemented, other scripting languages do not have so many ways to optimise them simply because they are a) not used so intensively where they should not be, and b) because where they need to be fast are fundamentally fast in the first place ....

Python should not be used for processor intensive applications (or the processor intensive part should be implemented in a "real" language), Javascript should not be used for processor intensive applications, it only is because it is available ... and it is optimised because there is no alternative ....

Re:Javascript is actually a great language

[rayharris]

DOM 3 has been out for a while. The DOM is also not the problem. It's the inconsistent implementation of the DOM by Microsoft that's the problem.

Re:Javascript is actually a great language

[Mystra_x64]

you have to use a USER DEFINED FUNCTION for trimming just boggles the mind.

That's a lack in DOM, not a lack in Javascript.

DOM has nothing to do with string manipulation.

Re:Javascript is actually a great language

[rycamor]

If you delete an array key directly with the delete command, eg: `delete myArray[4];` the length property doesn't get updated even though the number of elements in the array does. (WTF?!?!)

That one I can't speak to... interesting if true.

Yes, delete will mull the value of an array element but leave the index. To remove an array element, use splice(), which removes AND returns the indexed element in question:

js> arr = [4,5,6,7];
4,5,6,7
js> print(arr.splice(2));
6
js> print(arr);
4,5,7
js> delete arr[1];
true
js> print(arr);
4,,7

Re:Javascript is actually a great language

[Unequivocal]

I think you're referring JScript, which was Microsoft's look-alike to Javascript. It's been a while but I seem to recall that there were substantial differences in the languages, down in the weeds, which made porting some applications back and forth a pain.

Re:Javascript is actually a great language

[rycamor]

How is Javascript closure evaluation monumentally broken? (Not being sarcastic, just curious)

Re:Javascript is actually a great language

[Unequivocal]

I can't tell if you're complaining or praising? In my experience this is a feature and is a real bonus for programmers.

Re:Javascript is actually a great language

[Unequivocal]

Huh? This sounds like a bizarre argument of "don't make things too simple or people will get confused." Getting confused about whether something is running on the front-end or the back-end is a problem I think a lot of web programmers would like to have (including me). Using separate languages simply to indicate where the code is running doesn't sound like the right solution to the problem.

Re:Javascript is actually a great language

[Richy_T]

It reminds me of the lowly tomato, a member of the poisonous nightshade family of plants, which for years was considered to be inedible. These days you can't get a salad without it.

Or a pizza?

Re:Javascript is actually a great language

[Transfinite]

"CPU-intensive computations" + "lack of threading or any other explicit or implicit parallelism support" What like concurrency via WebWorkers? "no library facilities to modern 2D/3D graphics libraries" What like this :http://processingjs.org/ "Javascript is a nice experimental language like so many others but it shouldn't be running 90% of mission-critical applications" I'd hardly call it experimental after what 14-15 years. After all JAVA was designed for friggin fridges! So what you are trying to say is..... "I HAVE NO CLUE".

Re:Javascript is actually a great language

[gbjbaanb]

You'll start using some of the same routines in both client and server.

No, this is the point, you can reuse libraries and similar. With different languages you cannot do this, so have to implement the same thing twice. The biggest problem is that you have to learn 2 languages, you'll be an expert in 1 much sooner than if you have to become an expert in 2 (and to my mind, you never really become a true expert in the second)

Re:Javascript is actually a great language

[curunir]

In fact, I don't think jQuery addresses a single "lack" in Javascript

jQuery, like every other JavaScript library, gives you an extend function to address the lack of inheritance in JavaScript. It also offers functions like each that act on closures to iterate over a list/array...the language doesn't need these, but other languages offer them by default.

This is why Javascript gets a bad rap: pair it with DOM, and *any* language would look awful, because DOM is awful.

More than it being the DOM that makes JavaScript look bad, it's the fact that you have to target multiple implementations which are often incompatible. If there was just one JavaScript implementation that was shared between all browser vendors, things wouldn't be so bad. But JavaScript is lacking some basic functionality that it desperately needs. As mentioned above, native inheritance would be nice so that every library doesn't have to implement their own incompatible version. And namespaces and include, require, etc would be extremely helpful for larger projects where multiple team members work on the same codebase. And, as others have mentioned, JavaScript needs threading. The fact that developers are able to write responsive GUIs without threading is a minor miracle. Being able to have a dedicated UI thread is standard practice in other languages and it would make things easier in JavaScript as well.

However I just don't see the rationale for putting all this effort into making JavaScript a fully-featured modern language. There are quite a few languages that are already well established that need only have a DOM interface written for them. Life would be so much easier if browser vendors defined a language-neutral DOM abstraction and allowed scripting languages to be added as plug-ins. Then developers would be free to use <script language="python" src="script.py"... or <script language="java" src="script.jar"... and not only have the ability to code in their preferred language but also have the ability to leverage existing code in their applications.

Re:Javascript is actually a great language

[golgobot]

I love Javascript as well. In fact we use it as a scripting language for backend logic in our MMO.

Re:Javascript is actually a great language

[e2d2]

Yeah you'll find this with any language dynamically typed. The irony of modern popular languages, such as c#, is that they are now incorporating this same dynamic typing. So we see the same errors pop up at runtime instead of compile time.

For instance some c# "var" statements may cause a runtime error if not written properly, but you'll never know until it's run. The power is great, but with that power comes responsibility to make sure you write it correctly. But IMO I'd rather go the other way towards a more mathematically "provable" state where we can ensure future success by our proof, ie type checking.

Of course that's just my dumb opinion. Seems a lot of languages these days are either dynamically typed or incorporate it somehow.

Re:Javascript is actually a great language

[Idiomatick]

It isn't meant for huge projects. I thought /. was all about the right tool for the job? With javaSCRIPT I can paste a bit of code into my awesomebar and run it... hell I can save it as a bookmark... I can insert it randomly into the middle of some html. I can in very few words get something to occur (tinytiny code overhead).

The last point just looks like javascript has a bug lol. And that's pretty pathetic.

Re:Javascript is actually a great language

[TheRaven64]

Read the bit of the spec in relation to the return statement. Variables are bound at quite a surprising time.

Re:Javascript is actually a great language

[deanlandolt]

It just makes one up right there on the spot, and assigns it a null value.

Actually it assigns it a value of undefined.

Then there's the null -vs- undefined mess that constantly trips-up even experienced programmers.

Did that joke just go flying over my head?

Re:Javascript is actually a great language

[e2d2]

Sorry var is a bad example. Instead I should say something like a linq expression.

Re:Javascript is actually a great language

[aztracker1]

Actually, JScript 5.x was pretty much ECMAScript 3.x compatible, the only real thing it added was the support for ActiveXObject (for COM/ASP interaction) and an enumerator (since COM enumerations & recordsets weren't treated like Arrays). I used JScript with classic ASP a lot, since I could use the same scripts on both the client and server for some communications, and manipulations. The biggest issue with JScript server-side in classic ASP was in working with ADO recordsets.

Re:Javascript is actually a great language

[Transfinite]

What non-trivial like gMail, or what let me see about every other site you visit? You do know that javascript is a prototypical language? So you have treat it differently. Classical inheritance is not the way to do things. Namespaces?? What are you on about. I've been using NS in javascript for years!

Re:Javascript is actually a great language

[kripkenstein]

Perhaps it's a great language, but it reduced modern Core i7 computers to performance of a 486, negating 15 years of computing revolution.

• Some sort of interpreted language was needed for the web, to run untrusted code in a secure way. C couldn't be used for that. So it was a slow language or no language, back then. The only alternative at the time was Java, but it actually had worse performance in the way that most mattered to the web - startup times (not much use if it gets fast later on, if you need to wait an annoyingly long time for each page).
• New JavaScript engines are slower than C, but by less than an order of magnitude - and getting faster. There is no theoretical reason why they can't run fast ('dynamic types' isn't enough of a reason - modern tracing, hidden classes, etc. approaches can deal with that).

Re:Javascript is actually a great language

[gbjbaanb]

Perhaps you should have read TFA. The CommonJS spec is the solution to all (well, maybe) the problems you've highlighted.

for example:

Modules are a big deal. CommonJS modules represent the first time a JavaScript community has converged on a module system that is as good as (if not better than) the best of Python and Ruby's--supporting not only dependency management, but also scope isolation and relative module identifiers.

Maybe the spec will improve to remove some of the old Netscape-era incompatibilities, or the browsers will update themselves (like with CSS and HTML) to support only the modern, 'fixed' version. That'd be a good thing.

Re:Javascript is actually a great language

[Aqualung812]

I'll give you the lack of threading.

So, how does it get faster? I'm not sure you've noticed, but we're not getting faster clock speeds anymore. I had a 3 Ghz computer 7 years ago, now most computers are in the 2.5Ghz range. We're running more cores, and that needs threading.

Re:Javascript is actually a great language

[s_p_oneil]

Advanced features do not automatically make a language great. That's like saying advanced graphics techniques automatically make a game great. Actually, I just noticed your handle is BadAnalogyGuy. Did you do that on purpose? ;-)

Anyway, JavaScript is a horrible language (almost as bad as VBScript) and it needs to be phased out. I'd rather have client-side PHP than JavaScript, and I hate PHP. Ruby or Python would be the best IMO. From a language purist's viewpoint Ruby is more elegant, but Python has been around longer so it has a larger following.

Re:Javascript is actually a great language

[iamacat]

Some sort of interpreted language was needed for the web, to run untrusted code in a secure way. C couldn't be used for that.

Well, that sure hasn't worked out as planned. There is more malware written in Javascript than in any other language in existence. The only connection between language and security is performance of things like bounds checking, and Javascript is not exactly known for performance. C can easily be interpreted or compiled to verifiable code and still be faster than JS for CPU-intensive inner loops written without complicated pointer use. JVM is specially designed to allow more load-time verification rather than runtime checks, however this leads to long startup times and it is still not as efficient as hardware memory protection implemented by modern CPUs.

Re:Javascript is actually a great language

[Anonymous Coward]

what about trimming that input? The offense to the mind that you have to use a USER DEFINED FUNCTION for trimming just boggles the mind.

Maybe we're using different terminology, but how exactly is

mystring.replace(/^\s+|\s+$/g, '');

a user-defined function?

Sure, there are libraries for this, blah blah but still, the truth remains that there is no trim() function.

Why do you need a function to do it when another (well-defined and accepted) method exists?

Re:Javascript is actually a great language

[elnyka]

Here's my three favourite language flaws, which make the language nearly unusable for non-trivial projects:

• Variables are global by default, leading to accidental memory leaks, conflicts and various other fun things.
• A lack of namespaces.
• Lack of block scope (despite the fact the language has blocks), i.e:

  function a() { var b = 1; { var b = 2; } alert(b); }

  will alert 2.

Global variables, lack of namespaces and block scopes are nuances that can be worked around with proper coding practices and a good understanding of the language. This is orthogonal to pointers and memory allocation in C - you play them wrong and you'll get some funny results too. But, just as in C, in JavaScript (and in any programming language for that matter), the ultimate responsibility is on the programmer.

Re:Javascript is actually a great language

[multipartmixed]

> The absence of a trim method is not a DOM problem: I should be a method available on String.

IIRC it is in the ES5 draft, and implemented in at least TraceMonkey.

Re:Javascript is actually a great language

[Wdomburg]

More important than hearts and minds, the W3C let the charter for the xhtml2 working group expire earlier this year in favour of allocating resources to the (x)html5 effort.

Re:Javascript is actually a great language

[Anonymous Coward]

Well, I don't quite agree:
1. Sure, if you don't put var in front of the variable name, it will take the global variable, but isn't this what any language does? I mean, if I write a class in Java and use a variable without initialising it, it will use the parent's variable. It's quite normal behaviour, it's just that too many people don't use the var keyword.
2. Says who? Just look at the JQuery library. But here's an example of how simple it is:
a = {
        b: function(){
                alert(2);
        }
};
b = function(){
alert(1);
};

b();
a.b();

Will alert 1, then 2. Showing that namespaces DO exist.

3. That's what closures are for:
function a() {
var b = 1;
(function(){
var b = 2;
})();
alert(b);
}
Will alert 1, therefore, blocks DO exist, if used correctly.

Re:Javascript is actually a great language

[tixxit]

Javascript in the browser is single threaded. This is true of most GUI frameworks and should really not come as a surprise. I do not believe anyone think JS should be running 90% of mission critical applications any more then folk think that all data should be stored in XML files rather then a database. What they are saying is that, perhaps, JS has a life outside of the browser. This can be as a GUI scripting language, server-side templating, small scripts, etc.

Re:Javascript is actually a great language

[multipartmixed]

I tried your test program and the output was exactly as expected (456,123 for x=1,0).

So, what was your point? That you can use the var keyword twice in a scope block?

I think that might be addressed in ES5 "use strict", although that doesn't throw any warnings on current tracemonkey.

Re:Javascript is actually a great language

[Anonymous Coward]

"Variables are global by default, leading to accidental memory leaks, conflicts and various other fun things."

agreed.

"A lack of namespaces."

Unless our ideas of namespace are different, JS totally supports namespaces, i.e.

var com = {
        foo: {
                bar: {
                      baz: 1
                }
        }
};

var baz = 2;

alert(com.foo.bar.baz) // shows 1
alert(baz) // shows 2

"Lack of block scope (despite the fact the language has blocks),"

Again, totally doable:

function a() {
        var b = 1;
        var block = {
                b: 2
        };

        alert(b); // shows 1
        alert(block.b); // shows 2
}

It seems your last two arguments are gripes about syntax. That's fine. We all have our preferences.

Re:Javascript is actually a great language

[mcgrew]

Dynamically typed, object-oriented, with features like lexical closures

I hate dynamically typed object oriented languages! They're great for dummys who don't know better than to make infinite loops, but for those who have done low level programming (like assembler) they're hard to understand; with a low level language you have to understand the hardware to program. With a high level object oriented language you don't (theoretically) have to understand the hardware but you do have to understand how the language developers' minds worked.

And I never saw how lexical closures are better than non-lexical closures like a CR/LF. Nonetheless, I do manage to do javascript when necessary. Thankfully it hasn't been necesessary for years.

Re:Javascript is actually a great language

[multipartmixed]

You may have a point with Ruby or Python.

But PHP? Give me a freakin' break. It is far, far, far, far, far worse from a language design POV than JavaScript.

Re:Javascript is actually a great language

[Carewolf]

Lack of block scope (despite the fact the language has blocks).

If you want a scope for your block, then create a scope for your block. In most situationens you will have already have one, but if you suddenly feel the need for a pointless block with its own scope, that is possible as well:

function a() {
  var b = 1;
  function() {
      var b = 2;
  }();
  alert(b);
}

Will alert 1.

Re:Javascript is actually a great language

[TheNinjaroach]

In fact, most values coerce to true except integer zero, NaN, undefined, null and empty string.

Except in the DOM, as someone else has pointed out document.all which intentionally breaks Javascript specifications.

Re:Javascript is actually a great language

[shutdown -p now]

So, what was your point? That you can use the var keyword twice in a scope block?

The point is that variables are scoped to functions, not to blocks like in all other C-style family languages (and all other languages which permit variable declarations within blocks; the only other exception I'm aware of is VB6).

What's worse is that the second "var" looks like a variable redeclaration, but ends up being a simple assignment.

Compare with C++:

void foo(int n) {
    int y = 123;
    if (x > 0) {
        int y = 456; // shadows outer declaration
    }
    cout << y; // 123, as it should be
}

Java and C# go one step further, and prohibit shadowing of locals altogether. E.g. C#:

void foo(int n) {
    var y = 123;
    if (x > 0) {
        var y = 456; // error, y already declared in local scope
    }
    Console.WriteLine(y);
}

JavaScript approach is worst of all: it's inconsistent with conventional behavior, it lets you declare variables anywhere within the body even though it doesn't affect their scope (so no good reason to allow it), and it silently ignores the "var" declaration (treating it as plain assignment) rather than raising an explicit error.

Even VB6, which also scoped locals to the entire function body regardless of where inside it they were declared, would raise an error if it would see two declarations clash in the same scope.

Re:Javascript is actually a great language

[tixxit]

I would say jQuery extends standard DOM implementations and makes DOM manipulation/traversal easier. Most browsers actually support DOM pretty well and I would not call their implementations shitty, especially consider jQuery is merely an abstraction (ie. you can't polish a turd), not replacement for the DOM API. Also, IE, Firefox, Opera, etc all have very good documentation on their DOM implementation that so most "wtf?" moments are cleared up pretty quickly.

Re:Javascript is actually a great language

[jcaren]

Add: assignment is "copy" for all types except Object where copy by reference is used.

This makes "deep copy" code a nightmare and even versions of deep copy code in toolkits such as jquery do not work in all cases.

I have been working on a jquery based app using a modified Jquery based SOAP::Lite client and have hit this problem a number of times.

Jacqui

Re:Javascript is actually a great language

[tixxit]

1) Wrap your scripts in a function call:

(function(){
// stuff goes here.
global_var = 1;
var local_var = 2;
})();

2) You can easily impose your own namespacing (many projects do).

(function() {
my_ns = {};
my_ns.my_var = ...
})();

3) Wrap your blocks in a function call:

function a() {
var b = 1;
(function() {
var b =2;
})();
alert(b); // alerts 1
}

Re:Javascript is actually a great language

[multipartmixed]

Ah, I've gotten so used to block-scoped JS that I forgot that it was a problem. Hence, I looked at the code, knew what it did, and was not surprised.

You're right of course, especially w.r.t. the second var.

I really hope they make that an strict-mode warning in ES5. Unfortunately, they can't make it make an error because it would break (badly written) ES3 programs.

Re:Javascript is actually a great language

[TheDarkMaster]

Are you sure? For me, as language JavaScript is... terrible.
No proper types control (String, integer, etc);
Bizarre (for me at last) math control, like the NaN (Not a Number) and the strange effects on overflows or underflows;
Difficult to discover errors (you need to see the error log from browser, and if the error generates any message to see on then);
Painfull slow, even if you compare then with Java;

Re:Javascript is actually a great language

[Sloppy]

It isn't meant for huge projects

Small projects turn into huge projects. You use a cheesy tool for a job, it works, and then someone wants a feature, so you add it and feel a little uncomfortable about it. A few weeks later, it happens again. After a few years, all the little discomforts add up to a giant pain in the ass.

Look at how all these little languages (e.g. PHP) have evolved and tried to grow up, to varying degrees of success. Do you know why they did that? Because someone had legacy code investment and needed the language to grow up r at least half way grow up. Shit, I wrote a log analyzer in PHP not because it was a right tool for the job, but because I had some legacy code from a custom CMS that did what I needed, so I could just include it, call some old debugged fucntions, get the job done, and move on to my next TODO. It ain't pretty, and you can bet your ass that n years ago when someone started writing this stuff in PHP, they had no idea what size project it would become.

You just never know what projects will blow up into big deals and which ones can survive cheesy tools forever. So I'd say: go ahead and improve javascript implementations, but for fuck's sake, don't ever start a new project, no matter how small you think it is, using javascript (or PHP ;-), unless javascript is just the only choice you have (e.g. you need to run inside a web browser). Even if your project seems small enough -- will it always be? If you use a "grown up" language and then your project evolves/expands, maybe you won't be fucked.

Language designers need to think big from the get-go. When they don't, people suffer. And yes, that means namespaces (thank you, Python) and local scopes (good fucking grief, Javascript!!).

Re:Javascript is actually a great language

[TheDarkMaster]

Only because is implemented on major browsers and no one showed a better idea yet.

Re:Javascript is actually a great language

[ivucica]

It seems people enjoy mixing up low browser's DOM performance with low Javascript/ECMAScript performance.

Re:Javascript is actually a great language

[shutdown -p now]

I liked what Mozilla guys did in JS1.7, where they've added a new construct:

let (x = 1) {
  let (x = 2) {
    write(x); // 2
  }
  write(x); // 1
}
write(x); // undefined

I actually like this more than traditional C/C++ syntax inherited by Java and the likes, since it makes the scope of every variable an explicit block (rather than from implicit range point of declaration to the end of the enclosing block). Better yet, they've added let-expression too, which is something I sorely miss in imperative languages since first trying OCaml and seeing "let ... in ..." construct.

The problem is that this isn't standard EcmaScript, and is not understood by other browsers. ES4 was supposed to have it, but ES4 is dead.

Re:Javascript is actually a great language

[Ant P.]

The real question is "When will Microsoft's shitty browser either support DOM 2 or go crawl in a hole and die?"

The standard was finalised almost a decade ago. We're still waiting.

Re:Javascript is actually a great language

[TheDarkMaster]

Errr... JavaScript on the server side? OMG, RUN! WE ALL GONNA DIEEE!!

Re:Javascript is actually a great language

[TooMuchToDo]

I'm not saying it doesn't work, quite the contrary. It's working very well for what it's doing. I'm very interested in seeing in where it goes next.

Re:Javascript is actually a great language

[ivucica]

"Command-line" Javascript? If you're referring to the core language (already separated from browser) that's called ECMAScript.

While most of your complaints are legitimate and I suffer from them as well, a lot of stuff, like existence of functions, can be verified by punching it into a try/catch block. It's fugly, but it's possible.

Re:Javascript is actually a great language

[IamTheRealMike]

Uh, most languages provide a string type that has methods which could be implemented by the user. Many of them in only one line of code. The point is that foo.trim() is clear to everyone, whereas your construction looks like an ASCII table vomited all over your text editor. If I saw that without any comments, I'd have to take a moment to study what it did and figure out that it's a trim.

Re:Javascript is actually a great language

[maraist]

"jQuery (prototype, mootools, etc) solves shitty DOM implementations, not shitty Javascript implementations."

While that may be the primary/original goal, the browser-capabilities testing (of all libraries of this class) also extends to basic coding functions like string-utils - which are horribly incomplete in many browsers - and the fact that they differ on something so basic is mind boggling. To say nothing of trivial array/map operations.

Re:Javascript is actually a great language

[rp]

The problem is not lack of expressive power, it's excess. JavaScript was unmaintainable until jQuery came around. I'll start trusting JavaScript code as soon as we get a checker that enforces some sane coding conventions based on jQeury or something equivalent (if it exists).

Re:Javascript is actually a great language

[maraist]

Don't forget jQuery's fixing of on-page-load and timer screwyness.. IE/firefox also has massive memory-leaks with respect to dynamically assigned bind handlers, which jQuery fixes (albeit in painful ways).

Though in a system-language only timers would probably be relevant.

javascript + browser == necessary hurt

Re:Javascript is actually a great language

[ahabswhale]

Don't hide behind the DOM. JavaScript sucks because it's designed to be non-maintainable. To be fair, it was designed back in the day when JavaScript functions were just small little chunks sprinkled around here and there to do simple things. Now it's used for far more than it was ever designed to handle and it flat out sucks major balls. I can't think of a language that's less maintainable than JavaScript except for maybe MSBASIC but that may not be fair to MSBASIC. Seriously, it's truly atrocious and should be replaced ASAP with a real language. Like most JavaScript fans, I think you confuse the bells and whistles with quality while completely ignoring what's bad about it. I have yet to meet a developer that I respect that has an overall positive attitude about JavaScript.

Re:Javascript is actually a great language

[Late Adopter]

Yeah you'll find this with any language dynamically typed.

Python? Dynamic typing does not necessarily mean weak typing. You can have a language that carries type information with the variable but still loudly complains when non-sensical operations are attempted.

Re:Javascript is actually a great language

[mujadaddy]

Intriguing, newsletter, blah, blah, etc.

Re:Javascript is actually a great language

[wilsoniya]

YES. Most people can't differentiate between JavaScript and the underpowered/frustrating libraries (*cough* DOM) a user is generally exposed to via the browser.

Re:Javascript is actually a great language

[VGPowerlord]

This made me think of Classic ASP, where one of the options was to use JScript on the server-side... which is Microsoft's version of JavaScript.

Re:Javascript is actually a great language

[VGPowerlord]

The point is that variables are scoped to functions, not to blocks like in all other C-style family languages (and all other languages which permit variable declarations within blocks; the only other exception I'm aware of is VB6).

Add PHP to the list of exceptions.

Re:Javascript is actually a great language

[Sancho]

Define "flaw." The fact that it's different from other languages is not a flaw.

Variables are global by default, leading to accidental memory leaks, conflicts and various other fun things.

There's a mechanism for declaring variables with either global scope or functional scope. Without a var prefix, it has global scope. I'm not sure I'd consider that "default." If anything, in my opinion, the preferred behavior would be to only have explicit scope and not allow variables to be declared without a prefix. Something like "global b" or "local a" to declare the scope. That said, if you see a variable declared without var, you know that it's global, and you should treat it as such.

A lack of namespaces.

This is probably my single biggest gripe. I've also been disgusted with the same problem in PHP.

But it's not entirely true. You can simulate namespaces well enough. The real problem is people redefining Object and cluttering up the global namespace. This means that it can be impossible to use two libraries together if they both try to (re)define the same methods.

It would be nice if the language held our hands on this, but ultimately the real blame lies with the developers who don't know the language that they're coding in, or who don't care about interoperability.

Lack of block scope (despite the fact the language has blocks)

This is nothing more than a design decision. It's not a flaw. One of the biggest problem programmers have with Javascript is that it looks a lot like C, but it doesn't act very much like C. This causes a certain amount of cognitive dissonance, and leads to programming errors, such as assuming that Javascript has block scope.

A weirder example looks like this:

a = 1;
function f() {
alert (a);
var a = 2;
alert (a);
}

IIRC, the first alert will be undefined because the variable is declared somewhere in the function, even though it's declared after the first use. Most C programmers probably expect the value of the variable to only be overridden after the local declaration.

Re:Javascript is actually a great language

[LarryRiedel]

The point is that variables are scoped to functions, not to blocks like in all other C-style family languages (and all other languages which permit variable declarations within blocks; the only other exception I'm aware of is VB6).

Python. Combined with not requiring explicit variable declaration.

Re:Javascript is actually a great language

[Idiomatick]

Oh agreed, my brain was -1 offtopic. I was thinking about for things in the browser. I pretty much feel that any javascript longer than a page or two is just wrong and should be done another way. PHP seems to survive expansion pretty well, AND its not as terrible if you need to port it.

Anyways, programs in any language will end up being hell in any language you write them in if you have a natural growth like that. At best if we are thinking it might expand when we write it maybe we can compartmentalize it a bit, that's about it.

Re:Javascript is actually a great language

[Keeper Of Keys]

It just doesn't make too much sense having a full fledged 2D/3D library in the browser

Actually, it would be lovely. I would far rather code games in javascript than Flash or Silverlight.

Re:Javascript is actually a great language

[Sancho]

Javascript has a lot of neat little features, but some of the design leaves me wanting. I wish it were a little more C-like in its design. I'd like block-level scope. It's not a flaw or a problem, but it's definitely something I'd like. I can see people calling that a wart. 'typeof' is just plain broken. To quote Douglas Crockford:

typeof [] produces 'object' instead of 'array'. That isn't totally wrong since arrays in JavaScript inherit from objects, but it isn't very useful. typeof null produces 'object' instead of 'null'. That is totally wrong.

Further down, he explains how to differentiate between objects and arrays constructed in a different frame. That you need so much code for that is, in my opinion, a wart on an otherwise concise language.

Re:Javascript is actually a great language

[Rufty]

So javascript is a great language, but few people notice because all but the most recent implementations are resource hogs, and the most used API (the DOM) is hideous and causes aneurisms for multiplatform deployment. But it'a a great language.

Re:Javascript is actually a great language

[e2d2]

I really like Python typing. But then again Python makes a lot of sense where other languages stumble :-)

Re:Javascript is actually a great language

[ardor]

Then you better don't look at large Lisp codebases, because Javascript is Lisp with C syntax.
Also, your pointless rants will get you nowhere. Give us a list of things about Javascript you dislike. No "ohh JS sucks so bad because .... well it just sucks" nonsense.

Re:Javascript is actually a great language

[Doctor Faustus]

consistency in language means you don't have to learn 5 or so to do meaningful work. Unfortunately, whilst MS appears to agree with me (everything in C#), the rest of the world doesn't.
I don't mind learning several languages, but JavaScript on both the client and the server does give you the possibility of running the same input validation code both places.

Re:Javascript is actually a great language

[shutdown -p now]

Python. Combined with not requiring explicit variable declaration.

Python is different, precisely because it doesn't have any local variable declarations in the first place (ditto for Ruby, PHP etc). There's no way this is confusing:

def foo(x):
    y = 123
    if x > 0:
        y = 456
    print y

since here it's clear that the same variable "y" is reassigned. The problem with JS example I've posted earlier is that the second "var y" looks like a new variable declaration, same as the first one, but in fact it is just a plain assignment. That is confusing.

Re:Javascript is actually a great language

[QuestionsNotAnswers]

Amen. JavaScript is following Lisp's footsteps: no common community, incompatible libraries, incompatible implementations, and a lack of common goals. CommonJS is a perfect example.

Server side requirements are grossly incompatible with browser side requirements.

IMHO unless you have peculiar needs, preferring a serverside JavaScript framework over an existing server language and framework is for fools.

PS: disclaimer: I develop a browser based application using JavaScript (with an application server using JSON - not an HTML/CSS generating web server)

PPS: I would like to see HTML split into two standards: a static form for documents (zero script, no dynamic CSS3 etc), and a dynamic form for applications (JavaScript, DOM, Libraries). I hate the trend towards flash-like HTML documents. I do like browser deployed applications though.

Re:Javascript is actually a great language

[Martin Soto]

Global variables, lack of namespaces and block scopes are nuances that can be worked around with proper coding practices and a good understanding of the language.

Why would you go through all this work when there are languages that provide all of this and much more and are as flexible a JavaScript?

Re:Javascript is actually a great language

[mcrbids]

I'm not saying that removing an array element can't be done, and done easily.

I'm just asking you to justify the behavior of the "delete" command in Javascript. (No, I can't either) It's one of those WTF-ish moments. Logically, it's no different than

array[i]=null;

Which is just lame since it's called "delete".

Re:Javascript is actually a great language

[TheDarkMaster]

omg... TWICE!

Re:Javascript is actually a great language

[hobo sapiens]

You don't get it. Who would use javascript to do what you describe?

It's like calling a screwdriver a useless tool simply because it's not an arc welder.

Use javascript for what it's for and it excels. Attempts have been made to use javascript on the server (see Aptana's Jaxer) and if there was a good server for it, I would consider using instead of PHP.

Not everything needs to be Java, C#, or C++.

Re:Javascript is actually a great language

[sproketboy]

Evil type coercion is a bonus? WTF?

Re:Javascript is actually a great language

[emj]

Actually javascript is an order of a magnitude slower than C, but it is friggin fast nowdays.

Re:Javascript is actually a great language

[syousef]

Great language? Can I have some of what you're smoking? Trying to do something as basic as pause for a given number of seconds is phenomenally difficult in Javascript. Your options are a busy wait loop, or an event that calls another function after a given number of seconds. Both of which have downsides that aren't acceptable (Choking the CPU, or turning your code calling structure to mud).

Re:Javascript is actually a great language

[rycamor]

Your thoughtfulness should at least rate a 2 or a 3.

I actually like the idea of preserving 'document-oriented' HTML, which is an endangered species.

As for the server-side JS question, I am still on the fence; just trying to examine and evaluate.

Server-side and client-side have different needs, sure, but that's more a question of the interpreter infrastructure and libraries than the language itself. Although, I do like the idea of manipulating documents with jQuery or somesuch on both the client and server side. Building HTML documents by concatenating strings or outputting at random places in code (ex. 90% of the PHP code out there) is a horrendous idea that should have died in the 90s. For any PHP work these days I use phpQuery along with a good caching library, so I can work with document semantics on the server side. I get 100% valid HTML output and I can manipulate any part of the document I want before output without ridiculous regex acrobatics or other buggy half-baked HTML parsing libraries.

Re:Javascript is actually a great language

[QuestionsNotAnswers]

Building HTML documents by concatenating strings or outputting at random places in code (ex. 90% of the PHP code out there) is a horrendous idea that should have died in the 90s.

100% agree. We use browser side controls and all HTML rendering is done on the browser. We avoid manipulating strings except where required for performance (pure DOM is too slow and we have to support IE6. Easy to avoid script injection by careful design). Solves a bunch of problems - the biggest problem is the lack of good libraries and controls. It feels like programming for DOS.

Re:Javascript is actually a great language

[rycamor]

Yes, I've been considering moving all HTML rendering to the browser, but some apps that work that way tend to annoy me. A lot of the things that used to be taken for granted in web interaction start changing when you work that way. The back button won't work, you can't bookmark anything, and of course the inevitable memory leaks mean your browser memory footprint threatens to take over the desktop.

I really don't see what was so bad about the old per-page request/response model. For about 95% of what people need to do in web applications, it is just fine. Of course there are things that AJAX solves, but I try to solve everything I can before that. For example, all this fancy new stuff in Slashdot here doesn't seem to enhance usability more than a fraction over the old method.

I wrote a lightweight document management app and after thinking it through, rejected AJAX and went with a REST-ish approach. It was very nice to realize that anyone could bookmark a document, or send the URL to someone else (Of course, access controls made sure the recipient was logged in and had permission to view the document).

(In thinking about it, I realize that AJAX could work as a nice helper to a REST system, so you can send realtime feedback, such as "User [x] is trying update this document. Would you like to view the changes or save a copy?".)

-the biggest problem is the lack of good libraries and controls. It feels like programming for DOS.

Yes, too bad that Mozilla's XUL didn't take off. It was clunky and frustrating in some ways, but at least you had a real suite of widgets and controls with decent event-handling behavior.

Re:Javascript is actually a great language

[QuestionsNotAnswers]

Yes, I've been considering moving all HTML rendering to the browser, but some apps that work that way tend to annoy me.

Advantages:

• Fast response even on slow connection.
• Low bandwidth.
• Potentially off-line (we don't need that, but could do it).
• Low bandwidth.
• Offload rendering and UI work to client.

Dis-advantages

• Limited choice of components. Often need to rewrite or author your own. No single popular library - incompatible components.
• Much slower to develop - hard to build on top of other's work.
• Difficult to make user friendly (few common user experiences, incompatible with some normal browser user behaviours).
• Memory leaks: Ugggh. IEJSLeaksDetector v2 is great to detect them (and we wrote a custom tool to detect "deleted" Javascript components that were still referenced). Rules for component framework: must not use element.onxxx, must track all attachEvent calls, must detachEvent when component destroyed. On unload framework: must detach all events, must set all global window.xxx to null, must set any document.xxx variables to null. Elements must never reference javascript objects (Object, Function, or Array). Unfortunately most libraries don't get it right ( to prevent leaks we had to develop various custom memory leak prevention code, edit control code, and completely replace event registration code).
• XMLHttp communication issues - ugly.
• Cruftiness - dirty workarounds, reliability problems, usually must support IE6 so often limited to what that can do.

For us, the pain has been worth it. Our clients just buy our service with very low deployment issues, fast pilot and training, fast rollout, nasty dependencies are avoided, and political involvement by IT departments is minimised.

Re:Javascript is actually a great language

[QuestionsNotAnswers]

The last para is really the key point - we go through the pain, because the result is that client want our service enough to pay good money for it.

2nd "low bandwith" should be "low latency". UI can be made responsive and it is noticable.

Re:Javascript is actually a great language

[rycamor]

Yikes! But thanks for the info. You really don't use the onClick or other event handlers at all? Or do you just mean you don't reference them externally via element.onXXX?

Life would be so much better without IE6, but unfortunately it is still the standard rollout in a many large companies.

Re:Javascript is actually a great language

[kripkenstein]

Well, compare it to V8, and it is about by an order of magnitude by the Debian benchmarks. But I think their version of V8 is a little old, so it should be a little better than that by now.

Re:Javascript is actually a great language

[thirdender]

• You'll only have a problem with global variables conflicting if you treat Javascript as a procedural language. Variables created outside of any closure are created in the context of the global window object. However, in your example code, var "b" is never a global because it only exists inside function "a", and would never conflict with any other "b" variable in your code.
• No, but usually you can get away with a Javascript object just fine. Yes, it will be global, but you give it your unique name (just like you'd have to do for a namespace, except most languages that support namespaces will throw an error if some other code tries to write over an existing namespace). For example, all of the jQuery library functions are under the window.jQuery object. The variables and function names are all accessed from that object, e.g. "jQuery.map(...)".
• That's because you're not using a closure. Putting braces around something in Javascript does nothing, so essentially your example code just does "var b = ..." twice in a row. If you defined a function "c" inside function "a", and defined a separate value for variable "b" inside of that function, it would have a unique value. The cool thing is that Javascript does LISP-like passing down of the variables to called functions. If you defined function "c" inside of function "a", then called function "c", it would have access to read and modify the value of the variable "b". However, if you then define a new variable "b" inside of function "c", it becomes a different variable, which is then destroyed when function "c" ends. Just play with it man, it makes sense and allows for all manner of awesome things when you really, truly understand how it works.

Re:Javascript is actually a great language

[thirdender]

http://www.jslint.com/ or http://developer.yahoo.com/yui/compressor/ (with -v set) will pick up these types of bugs (in lieu of a compiler).

Re:Javascript is actually a great language

[failrate]

Re: 2D/3D libraries

-Binding SpiderMonkey to openGL took me about a week and a half as a hobby project, and I'm not a particularly good C programmer. The result was an easy to use 3D livecoding environment that performed good enough for games. I had plenty of places in the JavaScript engine choice, binding and openGL calls to improve performance as well, but given the advent of webGL, I assumed that the proof of concept had outlived its purpose.
-If you prefer 2D, it is just as easy to bind it to libSDL. I didn't make much use of the graphics, but I used the basic sound functions to create a 256 channel additive sine synthesis soft instrument. Again, plenty of room to optimize (didn't even use sdl_mixer), and it meant that I was able to tweak the instrument code while it was running.

Re:Javascript is actually a great language

[Toonol]

Coding games in Flash basically IS coding in Javascript. The languages are nearly identical. Is it the proprietary plug-in nature of Flash that you don't like? I can see that it would be nice to have that functionality built into the browser, but that also seems like it might cause even MORE annoyances than we already get with Flash.

Re:Javascript is actually a great language

[yuhong]

Don't forget Windows Scripting Host too, I once used it to program with VBS.

Re:Javascript is actually a great language

[Bodrius]

Then you better don't look at large Lisp codebases, because Javascript is Lisp with C syntax.

Do you mean Lisp without packages or any other language support for real modularity?

There are many neat things about javascript. Scaling to large codebases is not one of those things.

Re:Javascript is actually a great language

[Nitage]

You, like many other posters here, are confusing the javascript language with the implementations found in web browsers. Creating javascript bindings to C APIs and system level routines is as trivial as creating Python or C# bindings - web browsers just decline to provide this functionality for security purposes.

Re:Javascript is actually a great language

[Bodrius]

that's not surprising since iterating over a linq expression is a function evaluation - but how does that relate to dynamic typing?

afaik, both var and linq expressions are as statically typed as any ML function. just because it saves you some typing the obvious (or the inferable), doesn't mean things are not resolved at compile time.

Re:Javascript is actually a great language

[dkf]

But then would *you* run arbitrary native binary code off the web?

No, but lots of people do. Witness the vast numbers of idiots who get caught by trojans masquerading as cute cat screensavers or whatever the latest meme is.

Re:Javascript is actually a great language

[lcs]

That's not really fair, it all depends on the runtime. Server-side JavaScript is not the same as client-side JavaScript.

Take a project like ESXX as an example. It's using Mozilla Rhino, which means that

• The JS code is compiled into bytecode and then JIT'ed by the JVM.
• It has an awesome runtime environment (Java), including UI, 2D and 3D graphics.
• It's definitely multithreaded, either directly via Java's Thread objects or ESXX's fork/join and parallel array primitives.

When you add E4X (the ECMAscript XML extension that means you can get a list of all links in an XHTML document by referring to mydoc..a.@href) to the mix, the end result is pretty damn nice for rapid web development.

Re:Javascript is actually a great language

[maraist]

Why does everybody keep mentioning DOM? wtf does that have to do with with any of the complaints I listed? In fact, I think the DOM implementation of most browsers is sufficient. Just don't muck with table DOM elements and you're fine. DOM is just one of several libraries javascript + browser provides.

My complaint is stupid things like:

myinput = myinput.trim();

can work on some browsers no matter what, and on other browsers only if you've mutated the string 'class' by appending a trim function, AND if that compatibility function was loaded sufficiently early in the HTML.

Thus it's safer to just use
jQuery.trim(myinput)

Likewise with any other such basic operation.

The object system is horrible, the 'this' variable makes my head spin - it's almost impossible to know what object 'this' is in their event model.

Their 'undefined' and 'null' are insufficiently defined (AND you can override their definition!!)..
You actually stupidly have to say

if (myvar) { .. }
to truely/safely see if something is false. otherwise you'll mutate the variable! wtf???

Re:Javascript is actually a great language

[maraist]

"few people notice because all but the most recent implementations are resource hogs, and the most used API (the DOM) is hideous and causes aneurisms for multiplatform deployment"

Not quite sure where you're seeing people complaining about resources. Flash / java-applets still takes the cake there.

DOM isn't that bad. It's never been a problem for me. Though I prefer to concatenate an HTML string and set the innerHTML - but that's just me.

The offing of "aneurisms on multiplatform deployment", however is where I really take difference. How can the platform be legitimate if it doesn't work on anything but one version of one browser??? Thus you have to have if-statements for each browser (either explicitly or hidden via a library)??

Maybe you're use to being anally raped by "cross platform C/C++". But I've been spoiled over the past 20 years with standards at the language level and compensator's at the compiler level. (That or just using C for one targeted platform - which I know, makes me less of a Man; but the right-tool-for-the-job I always say)

For more, see my post above:
http://slashdot.org/comments.pl?sid=1462628&cid=30296518

Re:Javascript is actually a great language

[shiftless]

Some sort of interpreted language was needed for the web, to run untrusted code in a secure way.

And the real question is, why do we need this capability? The answer is simple. We are using Javascript to force HTTP and HTML into uses they were never designed for, and are not even close to being the ideal solution for modern needs. What we need is a new protocol that is designed specifically for implementing a user interface remotely, not a 15 year old standard that was designed to serve up simple text documents and only handle minimum data exchange between client and server. I'm thinking something along the lines of the X11 protocol in concept, but far simplified and built for the purpose at hand.

Re:Javascript is actually a great language

[QuestionsNotAnswers]

We use events, but only register them via DOM addEventListener or attachEvent. We don't use traditional style element."onxxx" event handlers.

From today I have decided that various non-essential (but desirable!) UI features will only be supported on IE8 to help our clients want to change. Also I have just spent more hours on an IE6 workaround, and I have had enough!

Re:Javascript is actually a great language

[LarryRiedel]

The point is that variables are scoped to functions, not to blocks like in all other C-style family languages (and all other languages which permit variable declarations within blocks; the only other exception I'm aware of is VB6).

Python. Combined with not requiring explicit variable declaration.

Python is different, precisely because it doesn't have any local variable declarations in the first place (ditto for Ruby, PHP etc). [...] There's no way this is confusing: [...]

"The point is that variables are scoped to functions, not to blocks"

Re:Javascript is actually a great language

[shutdown -p now]

Don't rip my quotes out of context:

The point is that variables are scoped to functions, not to blocks like in all other C-style family languages (and all other languages which permit variable declarations within blocks

JavaScript, syntactically, is a C-style ("curly braces") family language. It also has local variable declarations.

Re:Javascript is actually a great language

[MobyDisk]

Did that joke just go flying over my head?

Nope: the joke is on me. I'm rusty on Javascript since I haven't done web development in a while. I fully expected to come back to this and see it modded -1 Flamebait with 100 comments explaining why I don't know the language.

Fortunately, now I'll never forget it. :-)

Re:Javascript is actually a great language

[MobyDisk]

Yeah you'll find this with any language dynamically typed.

Yeah, I really don't like them for this reason. I'd like to see a nice statically-typed scripting language. It really doesn't make the code that much more difficult to write, and it can prevent so many bugs.

I worked on an app that used JSON and had this problem constantly. If someone changed the return of a web service, all the C#/Java code would get compile errors because they saw the change to the structure. But the Javascript would break at run time.

C# is introducing the "dynamic" keyword in .NET 4.0 which will introduce dynamically typed stuff. LINQ and the var keyword are still statically typed: the compiler just infers the type.

Namespace.LongComplicatedObject foo = new Namespace.LongComplicatedObject() -- lame!
var foo = new Namespace.LongComplicatedObject() -- better

IMHO, the dynamic keyword doesn't need to be added to C#. From the examples I've seen, they are using it in places where their implementation of Generics is too limiting.

Re:Javascript is actually a great language

[multipartmixed]

Is that that jslibs opengl binding, or something else?

Re:Javascript is actually a great language

[multipartmixed]

Incidentally, pretty much everything you said about JS engine implementation details is not really accurate, at least not on JS engine in modern versions of the firefox browser.

The backing storage of Arrays is now a C-style dynamically allocated array of jsvals. jsvals are pointer-sized and can encode either
  - bools
  - void
  - 31-bit signed integers
  - pointer to object|string|double

Additionally, variable references are tokenized with references and accesses to values are cached within a property cache. This is particularly import when your engine has a JIT; you can't go re-parsing the source code every time somebody uses a variable!

I've never used canvas (I live on the server-side), but I'd be willing to bet that your 3D code was either bounded by computation or DOM access to the canvas object (which is not a real JavaScript object, it is proxied from the DOM).

It would be interesting to measure performance of 2d/3d code backed by JS arrays and similar Perl data types in modern versions of JS (v8 or tracemonkey) and Perl.

And before you start in with a statement like "Well if the DOM is slow then JS speed doesn't matter", re-read the title of TFA.

Re:Javascript is actually a great language

[multipartmixed]

> There is more malware written in Javascript than in any other language in existence.

*ANY* language which can access poorly-written native types can expose bugs. This has nothing, whatsoever, to do with JavaScript.

Even Lord Java, High Falutin Emperor of the No-Mistakes in the Kingdom of Super-Special would have security vulnerabilities if you bundled it with buggy native code accessed via JNI. *DUH*

Re:Javascript is actually a great language

[multipartmixed]

That was an interesting link. The outlier, regex-dna is kind of funny -- regexes are compiled directly to native assembly code on tracemonkey. I'll bet the benchmarker's regex library compiles to an intermediary representation for processing through a state machine of some kind.

So, if I'm right, the inverted performance ratio is a result of the C code generating interpreted regex and the JS code generating native regex compilation. That's kind of hilarious.

Re:Javascript is actually a great language

[multipartmixed]

> The problem is not lack of expressive power, it's excess. JavaScript was
> unmaintainable until jQuery came around

Can you provide two small examples of unmaintainable JavaScript code, where the maintability problem is solvable by jQuery?

Please stick with JavaScript. No DOM, CSS, ActiveX, etc.

Re:Javascript is actually a great language

[multipartmixed]

Don't forget that on-page-load semantics and timers are not part of JavaScript. They are DOM semantics.

That said, timers *are* relevant in a systems language. I had to re-implement for server side JS (although I chose "sleep" rather than the setTimeout event loop paradigm because it suited by purposes better)

Re:Javascript is actually a great language

[multipartmixed]

Do you mean JavaScript without packages or any other language support for real modularity?

Or did you forget to RTFA?

Re:Javascript is actually a great language

[multipartmixed]

So let me summarize your complains:

re. String.prototype.trim
You are angry because Mozilla implemented an extension to the language before it was ratified by TC39/ECMA. I can see why this would make you angry, although, frankly, I find the extensions convenient myself. This has happened many times in the past. For example, Turbo C 1.0 had a conio library on MS-DOS that was not documented in the ANSI-C standard. This was confusing, but handy once I read about it.

this
You do not like how the DOM's event loop virtualized 'this' and you do not like prototypical inheritance. The first is not a language issue. The second is an idiomatic choice. I happen to like prototypical inheritance, I find it flexible and shallow. Other people like making big, complicated, deep hierarchies. These people are usually tempted to re-implement classical inheritance. That is a bad choice.

Observation: deep object hierarchies and templates seem to chew up a lot of needless developer-time in early-debug phase of C++ projects.

Most of the time, I don't care if a baseball player is a human is a mammal is a vertabrate is an animal. I just care if they can catch a ball. That is the difference between classical inheritance + strict types and prototypical inheritance + duck types.

undefined
You do not like how the environment provides a variable named undefined which has the value void 0, that (void 0).toString === "undefined" and that typeof(void 0) is "undefined".

Can't say I blame you, this is pretty warty. But if you understand it (and I have just explained it), it is perfectly safe.

null
I'm not sure what your problem is with null, unless you are confusing it with undefined. Assigning to null with throw a SyntaxError. null is a keyword and has specific meaning.

truthiness
null, undefined, 0, and NaN are falsy. Everything else is truthy. The if keyword coerces its expression argument to a boolean type. The values above coerce to false. Everything else coerces to true. There is no variable mutation, I do not know where you got this idea.

Re:Javascript is actually a great language

[multipartmixed]

Deep copy is perfectly doable in JavaScript, provided you have pure-JavaScript objects. I suspect that problem you are seeing is traversing DOM objects which are poorly reflected in JavaScript.

The W3C is not helping here, either, with idiotic things like document.all on the table.

Assignment-by-copy is also not unusual; all functional programming languages do this. JavaScript is a bit unusual in that it has object references.

Re:Javascript is actually a great language

[multipartmixed]

No, delete is not the same as assignment to null. It is more like assignment to void 0. The difference is that null has typeof object and value null, whereas void 0 has typeof undefined and no value.

Re:Javascript is actually a great language

[kodemunkee]

This post is regrettably a little late, since I felt the need to figure out how to implement a pull-down menu system based on CSS as a poster mentioned in an earlier thread (it now works beautifully, btw). But I felt the need to comment on this behavior, since it is understandably a little confusing.

If you delete an array key directly with the delete command, eg: `delete myArray[4];` the length property doesn't get updated even though the number of elements in the array does. (WTF?!?!)

This statement is a bit inaccurate, but the behavior that occurs makes sense once you realize that all objects in JavaScript (including arrays and functions) are really associative arrays--they are not conventional arrays like you would find in C and Java. As far as JavaScript is concerned, an array is just 1) an extended object with 2) a special literal syntax, 3) which accepts unsigned integers as member names (though you cannot use the dot syntax to select them) and 4) which has a length property that automatically updates when you do something with the object (as opposed to doing something to the object, which is what the delete operator does), In order to remove an index from an array and have it reflected in the length property you have to use an array method (shift, pop, or splice, depending upon whether you're removing items from the beginning, end, or middle of the array, respectively). In JavaScript, the delete operator is only used to deallocate hash keys from an object and remove links for garbage collection; and since myArray [4] is not really the fourth element of the array, but a property with a name whose value is not a string, it doesn't invoke any special array behaviors, as an array method would. The array's length property is just a hook to allow programmers loop through the construct using a conventional for loop without needing a sizeof operator (which wouldn't work that well, anyhow; since JavaScript arrays are untyped). In case anyone is still reading this (and actually cares), the following examples might shed some light on how this works: var myArray = new Array (10); // Create an uninitialized array with an initial length of ten. myArray [4] = 20; // Assign a value to index 4 (really just a member with a name of '4') for (var p in myArray) alert (p); // Loop through the object properties and display each one to the user, in sequence. delete myArray [4]; for (var p in myArray) alert (p); // Loop through a second time alert (myArray.length); // Display the length of the array (as understood by the interpreter) to the user. You'll notice in this example that the first loop only displays one property (4), the second loop never displays anything, and the final length is still ten. If you adjust it to the following: var myArray = new Array (10); // Create an uninitialized array with an initial length of ten. myArray [4] = 20; // Assign a value to index 4 (really just a member with a name of '4') for (var p in myArray) alert (p); // Loop through the object properties and display each one to the user, in sequence. myArray.splice (4, 1); for (var p in myArray) alert (p); // Loop through a second time alert (myArray.length); // Display the length of the array (as understood by JavaScript) to the user. The output is the same, except that this time around, the length actually changes to 9. This is the correct way to use arrays--the delete operator is a little bit too low-level in JavaScript to work the way you're trying to use it. It's a bit counter-intuitive, but the way JavaScript handles arrays can be useful if you're indexing objects on the client side based upon the table ids assigned by your database system of choice (assuming that you use some sort of integer-based record id scheme and none of your screens ever display too many items a

Re:Javascript is actually a great language

[maraist]

How is only FF 3.5 supporting trim useful to designing a web page? You still have to wrap it in a function to support other browsers don't you?

Your turbo C analogy doesn't work because that is compile once deploy everywhere with no consequence.

The best you can say is that trim will be more efficient in FF 3.5 via the library. But with JIT becoming more common, you'd get that anyway in newer browsers.

== this
while reading the documentation on which object is passed as the this in various contexts may sound easy - What happens when you have 3 or 4 layers of abstraction that may or may not effectively swap out the this object such that a given function can not guarantee what fields/methods exist on the this object.

Maybe I'm just use to methods being tied to their associated class - being an old foggie. But Ive had a lot of bugs in jQuery callbacks because the this variable was of an unexpected source.

I understand your point about prototype vs deep C++ inheritance though. But neither C++, Java, Perl nor JS feel right to me wrt OOP. They all have serious code-clarity problems when you fully leverage their capabilities as anything more than glorified hash-maps / c-structs.

== truthiness

http://saladwithsteve.com/2008/02/javascript-undefined-vs-null.html

feels to me like bad design. What is the usefulness of all these possible combinations of truthiness? Perl had similar degrees of type cooersion to easily compare unrelated datatypes, but they at least all seemed obvious to me - the principle of least surprise / similar things look similar, different things look different. But JS type-coersion/truthiness doesn't minimize surprise to me. Here replacing undefined with an exists operator would do the trick. You dramatically reduce the number of combinations of truthiness at the expense of some code verbosity.

Granted there is one known edge case in perl that can prevent proper type cooersion for string concatenation, and there isn't an equivalent Number(), String() type-cast. But I'd only ever encountered it twice in my whole life.

Re:Javascript is actually a great language

[Unequivocal]

It's not evil type coercion, at least in my opinion, and that of others I know (Matz for example). When everything that isn't specifically false/nil evals to true it makes a lot of business logic strategies a lot simpler to code. It might suck for lower level progs, dunno b/c I'm not one.

Ruby works like this also - if the var has gook in it, it's true. If it's deref'ed it's false.

Re:Javascript is actually a great language

[spongman]

yup JScript on the server is the same as JScript in the browser (they both use the same DLL). the environment is different, obviously.

Re:Javascript is actually a great language

[kaffiene]

Its a fucking awful language. The fact that it has one or two good features does not cover the fact that the other 90% is a pile of steaming shit.

Douglas Crockford in 'Javascript: The Good Parts' uses fairly similar language to describe JS: "more than it's share of bad parts", "a steaming pile of good intentions and blunders"

And this is from someone who *likes* the language.

JS has the C++ defense - if you only use a small subset of the language, it's very nice. But that's crap unless you never work with other programmers or use any other libraries or code snippets off the web. Because even if you are the *perfect* programmer (you are, aren't you?) noone else will share your dedication to excellence, and your code will end up polluted with the crap that infects the language (everything is global, no namespaces, no include/import!!!!, no block level scope, the array iterator busts array prototype extension and vice versa, no way to avoid prototype extension clashes)

As someone who uses JS a lot, I do agree that prototyping languages are intriguing and I'm really fond of JS's object literals - a feature I'd like in other languages. But JS has so many warts that it should just be shot. At least in it's current form.

If you could rewrite and come up with a JSNext or something which resolved all the flaws - properly! Then it would be worthwhile, but in insisting on continuing to support existing bad practices, these standards bodies ensure that web development will continue to be a pile of steaming crap.

I decent JS rewrite would be priceless to the future of web development, but like the stupid C++ backwards compatibility with C (especially retaining the same build model) , we are again sacrificing the sanity of future programmers to deal with a one off transition issue.

Never enough time to do it properly, always enough time to do it again.

*sigh*

Re:Javascript is actually a great language

[kaffiene]

Rubbish.

Everything is global
no namespaces
no include/import!!!!
no block level scope
  the array iterator busts array prototype extension and vice versa
no way to avoid prototype extension clashes
no packages / modules

None of those are anything to do with the DOM.

Re:Javascript is actually a great language

[kaffiene]

Yeah, this excuse that all JS's warts are actually to do with the DOM is a load of rubbish. It has a ton of issues that would concern any software engineer with half a brain (which makes me wonder about a lot of these comments in this thread)

Re:Javascript is actually a great language

[tepples]

Of course the CPU-intensive parts of an app (compression, encryption, database things like DBM or SQLite) are still in native code and Javascript is just a wrapper.

What would you recommend in the following situation?

• What I want to do is CPU-intensive, so pure client-side JavaScript is impractical.
• The app is latency-sensitive or needs to work away from a Wi-Fi access point, so server-side processing is impractical.
• The lowest common denominator of libraries installed on clients' machines happen not to do exactly what I want, such as 3D visualization or other forms of signal processing.
• The end users have web browsers on their devices, but I can't guarantee that they will have administrative permission to install native software.

Re:Javascript is actually a great language

[tepples]

hardware memory protection implemented by modern CPUs

Not all mobile or set-top devices have "modern CPUs".

Re:Javascript is actually a great language

[LarryRiedel]

I think it is fair to say Python is a C-Style family language.

Re:Javascript is actually a great language

[multipartmixed]

> How is only FF 3.5 supporting trim useful to designing a web page?

Part of the Mozilla Team's goal is to implement features from draft specifications so that upcoming features can be tried by the community, who can in turn provide feedback to the technical committee. I believe String.trim is ES5 track, and was in the last ES4 draft.

  > You still have to wrap it in a function to support other browsers don't you?

Imagine firefox *didn't* provide a native version of String.prototype.trim. Then you'd have to implement it in all browsers. In fact, if you are happy with the cross-browser implementation, you could simply ignore the Firefox's native .trim method and use your own.

This means that it is exactly as much work for the developer to pretend that Mozilla did not add this method as it is for him to not have it all (as is the case with the other browsers). Thus, the only drawback to adding the method is that it gives people something to whine about on slashdot.

The fellow writing the saladwithsteve.com article is on-point with respect to writing JavaScript programs. But the fact that people can write poor JavaScript programs because they didn't bother to learn the language is not the fault of JavaScript.

if (!a)
    print("a is falsey");

is perfectly clear, depending on the type of a:

string: ""
undefined: (undefined)
object: null
number: 0 or NaN
boolean: false

Which of the situations values do YOU think should be truthy?

JavaScript broke out a long time ago

[icepick72]

JavaScript is already out of the browser, but unofficially or rather unstandardized. Look at languages such as JavaScript in Flash, or the use of JavaScript in Acrobat PDF Reader, etc. Microsoft allowed their JScript (variant of JavaScript) to be used on the server side years ago in classic Active Server Pages - so I coded JavaScript on the server several years back.

However I am in support of a more official representation of JavaScript on the server.

Re:JavaScript broke out a long time ago

[dpilot]

> However I am in support of a more official representation of JavaScript on the server.

I suspect that part of the thrust here is migration of server CPU cycles to client CPU cycles. Server CPU cycles are typically planned, purchased, tracked, and constrained. Client CPU cycles are typically wasted. The "cheap box" today at the local big box retailer has more CPU power than a scientific mainframe of not that long ago. Most of that compute power is spent waiting for the user to press a key or move the mouse.

It's a classic case of "Somebody Else's Problem." Make my CPU cycle constraints into SEP, except that in this case Somebody Else isn't likely to notice - they'll even like it, assuming it improves their web experience.

Re:JavaScript broke out a long time ago

[bluesatin]

Look at languages such as JavaScript in Flash [..]

I wouldn't say JavaScript = Actionscript; they're both descendants of ECMAScript.

Re:JavaScript broke out a long time ago

[Blakey Rat]

Look at languages such as JavaScript in Flash,

Flash doesn't use Javascript, it uses Actionscript. Both are based on the ECMAScript standard, but Actionscript 3 is actually pretty far-removed from Javascript now. (Actionscript 2 is much closer.)

Anyway, I get what you're saying, it's just that Adobe's version is modified quite a bit.

Re:JavaScript broke out a long time ago

[maxume]

That makes Javascript its own grandfather!

Re:JavaScript broke out a long time ago

[Unequivocal]

I already notice the javascript cycle churn on my local workstation when browsing (ahem slashdot and gmail). Dumping more cycles on my client isn't a good idea unless someone finds a way to keep the utilization from lagging UI and other noticeable items..

Re:JavaScript broke out a long time ago

[dpilot]

You're obviously not doing your part to stimulate the economy. Run (don't walk) to your nearest Big Box retailer and buy a new computer. Help boost those Christmas season retail figures.

(I'm bad for the economy, too. My systems are all getting old, and I run a plan wm - no desktop stuff, so I can make do with older hardware. I also have Slashdot set to work the old way, in my profile.)

Re:JavaScript broke out a long time ago

[cheesybagel]

Cycles aren't "wasted". Power is saved. But yeah, if you are a service provider, you probably want to offload as much work (and expense) to the clients as possible.

Re:JavaScript broke out a long time ago

[cheesybagel]

Kind of more complex than that. Check out the initial date of release of JavaScript and ECMAScript. Netscape developed JavaScript initially and as browsers started implementing it in many incompatible fashions, standard ECMAScript was devised.

Re:JavaScript broke out a long time ago

[Unequivocal]

Yeah seriously. My phone I think is faster than my laptop (t43). OTOH, I got a work laptop recently (Toshiba) which is ostensibly modern but is a total POS and has the same JS UI lag as my trusty t43.

My thoughts

[davidbrit2]

As somebody who's attempted to write object-oriented Javascript code, my response would be GOD NO.

Re:My thoughts

[rayharris]

JavaScript uses a different type of object than you're used to. JavaScript uses prototype-based objects whereas most other languages use class-based objects. I've seen a lot of work put into developing "class-like" objects in JavaScript and I've wondered why they just didn't learn to write code using prototypes instead.

Re:My thoughts

[TheNinjaroach]

Umm, Javascript is great for object-oriented programming. I don't think you are using it properly..

Re:My thoughts

[ShieldW0lf]

JavaScript uses a different type of object than you're used to. JavaScript uses prototype-based objects whereas most other languages use class-based objects. I've seen a lot of work put into developing "class-like" objects in JavaScript and I've wondered why they just didn't learn to write code using prototypes instead.

Too educated to learn.

Re:My thoughts

[aztracker1]

One of the most difficult things that prototype based inheritance lacks is the support for implementing multiple interfaces out of the box. I find the original base.js takes care of a lot of this, but not a 100% cure all. One really nice thing with the prototype based objects is that you can easily duck-type extensions. Most of the extensions in Moz's JS 1.6 and ECMAScript 5 can be done via script itself (though not as effectient as an updated engine. I think the hardest one I've done is implement the new Date(ISO8601String) support, by overwriting the Date object, and prototyping against the original Date.

Beyond What?

[Monkeedude1212]

No one can deny JavaScript's usefulness on the front end of the web, but if you're a developer do you support the efforts to move it beyond that?"

If I've got Javascript on the front end, and say Java working the back end... How much more Java can I get? I'm a developer and I can't think of anything MORE front then the front end...

If you're talking about Taking Javascript and making it more integrated with the actual web page display, AJAX already handles most of that. We don't need Javascript to become like PHP, where you're using PHP to write your HTML inside of your PHP script tag inside of an HTML body.

Re:Beyond What?

[BiggerIsBetter]

If I've got Javascript on the front end, and say Java working the back end... How much more Java can I get? I'm a developer and I can't think of anything MORE front then the front end...

If you're talking about Taking Javascript and making it more integrated with the actual web page display, AJAX already handles most of that. We don't need Javascript to become like PHP, where you're using PHP to write your HTML inside of your PHP script tag inside of an HTML body.

1) JavaScript is not Java,despite the name.
2) You can get lots more Java if that's what you want.
3) Are you a developer, or a guy who makes web apps?
4) The OS desktop is MORE front than the front end of your web app running inside a browser.
5) PHP (and JSP among others) doesn't have to be written like that.

Re:Beyond What?

[Monkeedude1212]

1) There are enough similarities between the two to associate them together. Obviously one is a script and the other is not, so Java needs to be compiled and you have to watch your syntax more in Javascript. But the way I declare and use my variables is most similar to the way I would handle them in Java as opposed to VB.

2) Yes I've written a GUI in Java, wrote the back end in Java, etc etc, and no, thats not what I want. It's not fun.

3) I actually only maintain web apps on occaison, most of my hobbying is spent inside C++ or C#.

4) Dear God, the idea of an OS being built on Javascript (given its massive exploitation) is a terrible idea. I hope it never comes to that.

5) I know. But about 50% of "developers" out there aren't ever looking at their own code. So they have to be able to handle that kind of shit when it comes up. And believe me, SOMEONE WILL write it like that.

Re:Beyond What?

[BiggerIsBetter]

I have to disagree with 1. Granted it's not like a BASIC derivative, but other languages also use very similar syntax. My team deals with both daily, and the differences are significant.

I was actually thinking of JavaFX when I wrote 2...

3: Fair enough. I've met folks who can render a few rows from a DB into HTML via PHP and call themselves developers... Then they ask me how to submit a form, put data in a session... and worse, they don't ask about security, the architecture, etc...

Re 4, JavaScript at the OS level has already happened thanks to Windows Scripting and JScript, and of course we've had OS scripting for a very long time... AREXX, AppleScript, bat, sh, etc. The trick is to sandbox it appropriately (which often doesn't happen, and that's where the exploits come from...).

5: True enough, and debugging someone else's code is much more difficult that writing it in the first place.

Re:Beyond What?

[Anonymous Coward]

The only similarity between JavaScript and Java is the word "Java".

Re:Beyond What?

[leptons]

Using JavaScript on the back-end can be VERY powerful. I write very complex web applications (40,000+ lines of front-end javascript, similar back-end complexity). On some projects I am using JavaScript (JScript.Net) on the back-end, and some projects I use Java. I am constantly wishing I could use JavaScript for all back-end tasks, because I often do copy-and-paste front-end code to the back-end server running javascript, and it works perfectly. Not all script works, anything accessing the DOM will not work from the back-end so well (depending on which server-side javascript implementation you use).

It is useful to be able to share code between front-end and back-end. I just do not understand why so many people are so backwards on this simple concept. If you use one language for front-end and back-end, then your code re-use possibilities just doubled. I do this **all the time**. It works great. I code so much faster on the projects where I use javascript for both front-end and back-end. I don't have to constantly switch back-and-forth in my head depending on which language i'm using at the time. I know about 15 languages, but now all I want to do is JavaScript.

I'm also writing desktop apps in JScript.Net. Performance is faster since the JScript is compiled to byte-code. I get to leverage all of the .Net framework, WPF, etc, to write desktop apps, robotic control apps, you name it. JavaScript has been 'broken out' of the browser for a long, long time.

People who are hating on JavaScript just do not seem to understand it at all. It is a shame really, that so much negativity is hurled at javascript by people who either have no experience with it, or their experience is tempered by what they think a programming language should be. Dynamic typing is EASY. Just don't fuck it up and program things half-ass. Global variables are a bad way to code. Most people don't know what they are doing and they use global variables too much. Object Literal is the way to go with JavaScript, define all variables inside your object and you won't have to worry about globals. Also, using the window object to reference globals solves a lot of problems. window.foo will be undefined if it was never defined, but foo by itself will probably crash your code if it was undefined.

Sure, maybe it takes 15 years with JavaScript to master it, but I can't say that C++ or C# would be any easier to master.

Damn straight!

[ckaminski]

I've been a big user of BSH ever since it came out, and before that a hacked Rhino/Spidermonkey fan for building system automation components that were scriptable via javascript.

I say bring it on.

Re:Damn straight!

[Bauguss]

excuse the ignorance but BSH? googled it but too vague.

Re:Damn straight!

[aztracker1]

http://www.beanshell.org/

JavaScript should stay in its niche

[CodeBuster]

While JavaScript has a good thing going with the web scripting niche, it has a long road to catch up with established players in the heavyweight "everything and the kitchen sink" language category currently filled by C# and Java. It is very difficult to see mainstream platform developers selecting JavaScript as their general purpose language in favor of C#, Java, or even C or objective C (for the Linux and Mac developers respectively). JavaScript would do better to reduce its footprint and burnish its credentials as a web scripting language because that is what we need it to be; after all, we already have good languages in the general purpose category that are NOT suitable for web scripting.

Re:JavaScript should stay in its niche

[TheRaven64]

C or objective C (for the Linux and Mac developers respectively)

Some of us use Objective-C on Linux (or, in my case, FreeBSD) too. It even works on Windows...

Getting JS out of the browser is a *great* idea.

[Karellen]

Javascript is a beautiful, elegant, small and generally well-formed language. It has a couple of warts, but what language doesn't.

However, the way that Javascript interacts with web browsers, web pages and all other things web-like is a disgusting, crufty, bloated piece of shit. The DOM bindings are horrible, as far as they go, and they're woefully incomplete. The browser deficiencies in their implementations of the DOM bindings, and the browser-specific work-arounds needed to circumvent said deficiencies, are Lovecraftian nightmares.

(The willful violation of the javascript object model for document.all in HTML5 (see bottom of page) is one particularly nasty example of what the web has done/is doing to Javascript. If you know the JS object model well, think about what that violation really entails, and what it would take to write that special case into a JS engine, for one particular property, of one particular object, if you happen to be running in a particular environment (browser))

Getting Javascript out of the browser would be the best thing that could possibly happen to Javascript.

i'm not so sure about this.

[Overunderrated]

KILL IT WITH FIRE

Better Idea

[physicsphairy]

I think everyone can agree what we really need is web-executable COBOL.

Re:Better Idea

[dkleinsc]

You mean like this?

Re:Better Idea

[marqs]

There is COBOL on COGS
http://www.coboloncogs.org/INDEX.HTM

Javascript...

[spidercoz]

the Johnny Knoxville of programming languages

What what most sites use Javascript for...

[Viol8]

... the browser might just as well support GWBasic. However fancy javascript may be , it doesn't take the worlds most advanced scripting language to to do pop up windows ,mouseover events and selective loading.

Instead of trying to makd the browser a cut down OS as both MS and Firefox coders seem to be headed for, they should go back to basics and make the browser a simple reliable graphics display program with some user I/O thrown in. Not some bloated monstrosity that has all the reliability of a 20 year old unserviced Trabant. Having to support an ever more complex OO interpreted language doesn't help this reliability.

Re:What what most sites use Javascript for...

[Idiomatick]

You forgot "get off my lawn"
Seriously, that isn't what the web is anymore, deal with it. Nothing at all to do with javascript.

Re:What what most sites use Javascript for...

[elnyka]

... the browser might just as well support GWBasic. However fancy javascript may be , it doesn't take the worlds most advanced scripting language to to do pop up windows ,mouseover events and selective loading.

Instead of trying to makd the browser a cut down OS as both MS and Firefox coders seem to be headed for, they should go back to basics and make the browser a simple reliable graphics display program with some user I/O thrown in. Not some bloated monstrosity that has all the reliability of a 20 year old unserviced Trabant. Having to support an ever more complex OO interpreted language doesn't help this reliability.

The problem with this thinking is that the web, as it is utilized nowadays, requires more than a simple reliable graphics display program with some user I/O thrown in it. It is here, I sometimes don't like it either, but it is here. That's the modus operandi nowadays. So we suck it up and make it work. That's what they pay us for.

We have been running good (and bad) RIA with various degrees of JS for quite some time. I've seen some really good stuff, and some really bad stuff, both using the browser and javascript. This, and taking into account that good and bad code can be written in any language leads to conclude squarely that there is nothing intrinsic in the language and browser that can lead someone other than a shitty developer to create crappy software. And this is a truth for any software development system.

Re:What what most sites use Javascript for...

[ivucica]

There's too much web-based software out there to drop Javascript support now. A lot of stuff that was formerly done through Javascript is nowadays done through CSS (dropdown menus for example).

Far greater problem is enormous complexity that browser must have in order to produce correct layout based on combo of CSS, tables and all other elements in there. Frankly I'm amazed that it works with the speed that it does work with. Complexity is not only in Javascript, but more-so in rendering engine itself. Mozilla's Javascript is already a separate library; just go ahead and remove it and see what you get.

A huge pain

[mafian911]

I'm not sure why anyone would want JavaScript anywhere else. I believe that the only reason why JavaScript is "popular" in the first place is because it is the only option available for client-side processing on the web.

A lot of the pain of JS, like its inconsistent experience across browsers, can't really be held against it. Each browser has to implement JS according to its own interpretation of the standard, virtually guaranteeing a non-consistent experience across the board. I understand that. But what truly kills JavaScript for me is the lack of development tools and a solid reference. Debugging JS with an alert window is a horrible experience.

Again, why anyone would want this stuff everywhere is beyond me. I was shocked a long time ago when Palm Pre decided it was a good idea to use JavaScript for app development. Shocked I tell you. And look where that went. Like I said, the only reason I would consider JS "popular" on the web is because there is no other way to do client-side processing. It's literally our only choice (VBScript doesn't count).

Re:A huge pain

[jeti]

And I was under the impression that graphical JavaScript debuggers were provided with InternetExplorer and Chrome and available as an addon for Firefox. Silly me.

Re:A huge pain

[sydneyfong]

I think the problems you've described are (among other things) what the article proposes to fix.

Re:A huge pain

[mafian911]

Silly you indeed. I would hate to use 3 different debuggers for every bit of code I write, to make sure it works on every platform.

God forbid MORE browsers become popular. Oh wait, Safari? Opera? I wonder if they have 2 more debuggers you can heap onto your development checklist.

If you enjoy having to debug your JS using multiple different debuggers, silly silly you indeed.

Re:A huge pain

[jeti]

Pure JavaScript code performs the same in any modern browser. Only interactions with the DOM have to be tested separately for IE. In my experience, the more complex a JS application becomes, the less code deals with the DOM and has to be tested on two platforms.

Re:A huge pain

[ChefInnocent]

You are making the same fallacy many others have made: assuming the sins of the browser are the sins of JavaScript. Free your mind and see the ECMA standard for what it is, a beautifully simple language with a good deal of power behind it.

Also, before FireFox offered FireBug and a whole slew of other folks came out with other development tools, I realized I could create a message tab (a.k.a. div-tag) I could write debugging messages to. You could have a simple "button" located somewhere on your page that could hide or show this message tab and it would have all the run-time messages you wanted to see in it. It works just like a real debugging file would, leaving behind all that pesky alert crap.

As for the Palm Pre, it seems to work okay. Sure, it needs rebooting once a week, but I think that has more to do with bad programmers than the tool choice. When apps are going to run day after day all day long, the programmer needs to know all the places memory was allocated so that they can deallocate it.

I use C/C++ where I work every day, but would really like to get back to JS because I think the OO is better, functions are first class objects, named arrays, closure, and run-time modification of object structure.

Here's my only wishlist for JS:

• Optionally Typed Objects to force int/float/char types on variants
• Lockable values
• Lockable Object Members (i.e. can't add/delete any more)
• Multi-threading with Mutexes
• Ability to load compiled libraries

Re:A huge pain

[Daishiman]

You're confusing a variety of unrelated things here. Javascript works fine in every browser that implements standards accordingly (that is, every browser with the exception of IE 6, 7 and 8). The language is not only consistent across browser, it's actually implementing some really interesting features such as list comprehension, generators, and block scoping.

And I don't know where you get the idea that debugging Javascript is any more difficult than any other scripting language. You can't claim to be a professional JS dev and not have heard of some tools.

Oh, and as a scripting language, it is one of the fastest dynamically typed languages available, in the same league as SmallTalk and Lua. The fact that Palm developers obviously used the wrong tool for the wrong job does not in any way detract from the qualities of the language.

Methinks there's a lot of people that talk crap about Javascript but have never bothered to get the proper documentation and tools. Newsflash for everyone: anyone who does professional Python and Ruby development uses debuggers and text editors specifically for that job. Just because JS runs on the browser doesn't mean it doesn't need the same level of attention.

Re:A huge pain

[multipartmixed]

> Silly you indeed. I would hate to use 3 different debuggers for every bit of code I
> write, to make sure it works on every platform.

And I suppose you write your C code for Linux, and cross your fingers when you ship it to Solaris, AIX, Iris, and Windows customers?

Or do you maybe test it on all the platforms you support?

Re:A huge pain

[multipartmixed]

Optionally Typed Objects -- not here today, tried for ES4, failed in comitted

Lockable values - do you mean "const" instead of "var"? If so, here today in Tracemonkey

Locable Object Members - seal is here today in Tracemonkey

Multi-threading with Mutexes - No good way to do this nowadays. SpiderMonkey 1.7 supported this without mutexes (mutexes would be easy to graft on, including in pure script). Rhino (moz js on java) might be able to do this.

Ability to load compiled libraries - doable today, GPSEE, built on tracemonkey, implements this (both pre-compiled native JS, which is what I think what you want, and native-language modules. And mixed-mode FWIW)

Re:A huge pain

[DieByWire]

I'm not sure why anyone would want JavaScript anywhere else.

Well, there are a lot of other places someone might want it...

• The bottom of the Marianas Trench.... oh, wait. Submersibles can get there.
• Deep in the bowels of a volcano. Except that a volcano might spit it out. Scratch that one.
• Interstellar space. But if there's any intelligent life out there they'd think we were attacking them.

OK, you were right.

Re:A huge pain

[Quiet_Desperation]

They use this JS crap at my company for training materials. What could be simple HTML links are giant Javascript functions that frequently just sit there inert when you click them. Reload the page and suddenly they work. It's hit or miss, and the same code can act differently in the same browser from moment to moment. It's also a major reason this company is still shackled to IE6.

Re:A huge pain

[ChefInnocent]

By lockable values, I mean I want to avoid doing this stupid error:

if (i = 3)

I'll take a look at SpiderMonkey.

Re:A huge pain

[mafian911]

C code is different. It compiles. And it usually comes with powerful debugging tools. More powerful, I dare to say, than JS debugging tools. Not to mention the standard library and the STL are very well documented.

Also, when you develop C code for different platforms, you actually have different source trees. One for each platform. You can individually test and debug each set of code on each platform. On the net, the SAME JS code is run on EVERY browser. So not only do you need to discover the right solution for each platform, you have to discover an even more magical solution that works on every browser at the same time.

I can see the point you were trying to make, but it's not really the same. You do have to test your C code in a different debugger for every platform, except, like I mentioned above, a change that you need to make for one platform wont affect all the others. Separate source trees. This is not a luxury you get with JS.

Re:A huge pain

[leptons]

I wouldn't change a thing about JavaScript. It is not really as bad as you say. I doubt you've really used the language much at all.

Re:A huge pain

[Art3x]

Debugging JS with an alert window is a horrible experience.

http://getfirebug.com/. Then don't do it.

Re:A huge pain

[failrate]

I'm not sure why anyone would want JavaScript anywhere else. I believe that the only reason why JavaScript is "popular" in the first place is because it is the only option available for client-side processing on the web.

You are discounting the ubiquity of both Flash and Java. I could easily imagine you not taking seriously other plugins like Shockwave, Unity, etc., but if your argument is based on what a given person will have installed on their machine by default, you've still got Flash and Java.

But what truly kills JavaScript for me is the lack of development tools and a solid reference. Debugging JS with an alert window is a horrible experience.

Douglas Crockford's Javascript: The Good Parts is an excellent reference. If you go to crockford.com, you can find links to videos of the class where he goes over the content in the book. Mr. Crockford also provides the JSLint tool on his website. It compensates for JS's lack of a compiler. Additionally, debugging with the alert window is an exercise in torture.
If you need to work with JS for a website, I would strongly recommend using the FireBug plugin. If you can't install plugins, then the very flexibility of JavaScript allows you to override the alert function. I generally add a div with the id="alert_box", then add this to your script: function alert(txt) { var box = document.getElementById('alert_box'); box.innerHTML = txt + "br/>" + box.innerHTML; }
That's not perfect, but it definitely works in a pinch. Just add an opening angle bracket before br. I couldn't get the formatting correct ;)

Re:A huge pain

[jrumney]

Debugging JS with an alert window is a horrible experience.

Which is why you use a Javascript Debugger. Even if you're developing some IE specific abomination, Microsoft has the tools you need.

Re:A huge pain

[multipartmixed]

You can't avoid doing that, but strict mode should generate a warning.

Re:A huge pain

[DragonWriter]

You are discounting the ubiquity of both Flash and Java.

ActionScript is an ECMAScript implementation, so Flash isn't really an alternative to JavaScript in the browser so much as an alternative JavaScript environment in the browser.

Java is an alternative, but its a very different class of language (and, since its usually not implemented in the browser but via an external plug-in with its own start-up time, has implementation-based issues as well as language-based issues.)

JavaScript is the only common (as in, cross-browser) browser-embedded language available for client-side programming on the web, and the only (browser-embedded or not) dynamic scripting language that is widely available for that purpose.

So, yes, its the best available tool in its broad class from the perspective of a web developer trying to reach a wide audience, but only because there aren't any other tools available.

Re:A huge pain

[tepples]

if your argument is based on what a given person will have installed on their machine by default, you've still got Flash and Java.

Nintendo rejected Sun's plug-in. Apple rejected both Adobe's plug-in and Sun's plug-in.

Clueless

[TheNinjaroach]

If I've got Javascript on the front end, and say Java working the back end... How much more Java can I get?

Repeat after me: Javascript is not Java. Don't confuse the two, they are completely different technologies.

Re:Clueless

[Monkeedude1212]

I know that, everyone knows that. One is a scripting language where the other one needs to be compiled before running and blah blah blah yes we know. But there are obviously more similarities between Java and Javascript then say Javascript and C#.

Re:Clueless

[BiggerIsBetter]

But there are obviously more similarities between Java and Javascript then say Javascript and C#.

List some of them.

Re:Clueless

[riegel]

Woooosh

Re:Clueless

[digitalgiblet]

I would say that C# and Java are more alike that either is like Javascript.

Re:Clueless

[Monkeedude1212]

Syntax. Albeit, C# was a bad example to use since Java looks very much like C or C++ or C#. (In some cases, where you are just handed a sheet of paper, its impossible to distinguish the two)

But if we were talking VB, LISP, or Perl, then the differences would be very noticable. The only thing I was demonstrating with "How much more Java can you get" was a joke on how they are named similarily, meaning I don't need Java, Javascript, ServerJS or anything else "Java" to come about.

Why not call it something new so that it's NOT associated with Javascript's terrible image?

---
Javascript If statement:
if (x > 1)
{
    document.write("x > 1");
}
---

Java [ or C# ] If statement:
if(x > 1)
{
      System.out.println("x > 1");
      [ Console.WriteLine("x > 1"); ]

}
---

VB If Statement:
If x > 1 Then Print "x > 1"
---

Re:Clueless

[Monkeedude1212]

Agreed.

Re:Clueless

[Daishiman]

What are you talking about? Javascript's only similarity with Java and C comes in the form of its syntax, made to appease Java a C++ programmers. NOTHING else in the language is even remotely similar, and its developers have made that clear from day one.

Does Java have support for closures and first-class functions?

Does Javascript have support for namespaces?

Does Java support prototypical object orientation

Can Java use hashtables as objects?

Re:Clueless

[larry bagina]

My Javascript ifs look nothing like that.

(x > 1).If(function(){alert("x > 1"); });

Re:Clueless

[GreyLurk]

Not really.... Honestly JavaScript is more like Lisp than it is like C# or Java. The only thing that it vaguely shares with C# and Java are that it's got a roughly C-like syntax.

And i'll point out that Java doesn't need to be compiled before running. JSR-274 specifies an interpreter for the Java Language. BeanShell is the current reference implementation http://www.beanshell.org/

Lexical closures "advanced"?

[Anonymous Coward]

C'mon. Perl has them. Lua has them. Ruby has them. Sheesh -- even Python has them. I'd guess even PHP has lexical closures these days. Advanced? You just disqualified yourself. Under which kind of rock have you been living the last 30 years?

Besides, I'd rather compare Javascript to a Gingko fruit. The stink is similar ;-D

[wow: captcha was "discord". This slashcode is developing some prescient intelligence, I fear]

Re:Why bother?

[causality]

I actually wish JavaScript and other client-side browser scripting would be done away with completely, but JS is not a particularly 'good' language. The only advantage I can see is that thousands of Web developers can now write desktop applications. Is that necessarily a good thing? or will it just lead to more inefficient crapware?

I'm guessing there will be a few really good, well-written apps and all of the rest will either be blocked with NoScript or special tools/addons will be created for the sole purpose of selectively blocking (or whitelisting) them.

Good luck with that.

[ears_d]

As a Java coder who wants to go back to C++ I'm appalled. But, as a developer who gets beat up over the cost of my work, I can see that a scripting language could lower costs. It's not for me though.

Script Engine out of the Browser?

[decipher_saint]

Sure a JavaScript engine may have shipped on "every computer ever" but it's been embedded into a browser. So the next step is to decouple it from that browser-based engine and use it to create local apps?

What would you run this script engine in? A Virtual Machine? Some kind of embedded OS Framework? A behind-the-scenes browser instance (shudder).

Either way, I don't get it, what magical app could I write only with JavaScript that I couldn't write with something else? Actually I do kind of get it, there are probably a lot of JavaScript hackers out there that would want to write desktop apps but are afraid to jump into something like Java or .NET.

Re:Script Engine out of the Browser?

[decipher_saint]

Really? The lack of built-in DOM support is somewhat crippling.

I guess what I'm really getting at is this:

To decouple JavaScript from the browser it will need libraries, which is going to lead to many of the same foils/overhead/headaches any other platform has.

Re:Script Engine out of the Browser?

[Unequivocal]

Wow - yours is the first post that actually makes a good point. Mod parent up!

Moving JS out of the browser just means it loses all the competitive advantages is could possibly have. Moving it out of the browser means that it will suck for writing multi-OS client applications in the same way Ruby (or pick your scripted language) does.

Re:Script Engine out of the Browser?

[multipartmixed]

> Sure a JavaScript engine may have shipped on "every computer ever" but it's been embedded into a browser.
> So the next step is to decouple it from that browser-based engine and use it to create local apps?

Microsoft has been shipping the Windows Scripting Host, wsh, with Windows since like Windows 98 or something.

It can run JScript or VBScript, and automate ActiveX controls. You can create local apps with full Windows GUI, drag and drop, context menu on the desktop, blah-de-blah. It can even be made to talk DAO.

Re:Script Engine out of the Browser?

[GreyLurk]

If you read the OP, there's a link to the ServerJS specs that Mozilla has been working on standardizing. It's a set of standard DOM-ish APIs for the JavaScript language that allow it to work in a multi-platform way with local files, databases, TCP streams, etc.

Re:Script Engine out of the Browser?

[Unequivocal]

Which seems great - and is exactly the same solution that Ruby, Python, Perl and everyone is working on. Same game, different instrument.. What am I missing?

Difference?

[TheNinjaroach]

3) Are you a developer, or a guy who makes web apps?

Wait, since when is there a difference? I consider myself a developer, but my applications are only available on the web..

Re:Difference?

[BiggerIsBetter]

Wait, since when is there a difference? I consider myself a developer, but my applications are only available on the web..

The difference is really understanding the technologies you're using, the context you're using them in, and effective ways to use them. I didn't get the impression that the OP necessarily had that understanding.

Can your language do this

[asc99c]

A lot of the comments are pointing out the problems in Javascript, and ignoring the problems in the big heavyweight languages like Java and C#.

It's not really in praise of Javascript, but a very good read is Joel's article 'Can Your Programming Language Do This?' It accurately points out a number of ways in which Java development very quickly takes up a lot of lines of code compared to more lightweight approaches. I personally prefer the light weight approach for many applications.

http://www.joelonsoftware.com/items/2006/08/01.html

Re:Can your language do this

[pydev]

More features and more expressiveness don't automatically make a language better; they may make software harder to maintainn and they may cost performance.

And Joel doesn't know what he is talking about anyway. In the same article, he says:

"The very fact that Google invented MapReduce"

Google didn't invent MapReduce. Map-reduce has been around as a technique for massively parallel programming since the 1980's.

Re:Can your language do this

[eabrek]

Joel is referring to closures. You can find them in D (compiled), Python (interpreted), or Tcl (obscure, but cool).

Re:Can your language do this

[GreyLurk]

See the ServerJS specs at https://wiki.mozilla.org/ServerJS which are implemented by several of these projects. They provide a good solid library of Database, Network, and File IO abstractions,

Re:Can your language do this

[WarwickRyan]

What I love is the fact that Microsoft are taking many ideas from Javascript (and other dynamic/functional languages) and adding them to C#. Last time saw lambdas (notably used in LINQ) and the new version has dynamic objects.

All languages have their strong points:

Java's universal, and has the most logical structure (the super is super, interfaces are implemented.
C# has delegates, and now a load of dynamic features.
Javascript has anon functions.
VB has the With.. End With block.
Ruby's extremely concise.
Python has list comprehension.
Perl has top rate string handling.
C/C++ can get as close to the metal as any sane person'd ever need to be.
PHP has... erm..... hmm... it's... shit... but it does have character.

Re:Can your language do this

[asc99c]

Yeah I couldn't remember the name, 8 years now since I learnt functional programming stuff. My uni course was 99% Java, and I realised during that one course just how many features were lacking - until then I hadn't really appreciated how much could be gained from learning multiple languages.

The problem as I see it with Java is that it really isn't easy to hack something together quickly. It forces you to do everything properly. I'm sure as overall project size goes up, so do the problems caused by little hacks. I've no doubt Java is a good language for a big application project, or a platform.

Now I've seen problems using C with all kinds of horrible hacks to get stuff done quickly. But from a commercial point of view, I'm not sure if the effort spent on the occasional problems outweighs the effort saved by the quick hacks on projects the size that I'm working on (upto a few man-years of effort on a system).

The horrid problems with Javascript tend to be getting browser stuff working on Firefox and IE etc. at the same time. It looks like a neat solution to quick little programs that just aren't big enough to warrant a heavy architecture.

Re:Can your language do this

[kaffiene]

Lines of code is not how production languages should be judged. Generally, software engineers aren't trying to type a solution as quick as possible. There is usually some thinking going on, so the typing isn't the bottleneck anyway. And then you usually want it to work without side effects and be maintainable. Languages like Java deal very well with complexity, and when something does fail, it fails early and loudly.

JS creaks at the seams when you do anything more than a quick hack with it. The more layers your code has become more places for errors to occur silently - with a code failure happening somewhere else perhaps miles from the actual issue.

Software Engineers are not generally writing quick, one-off hacks, and this is why the whole idea of lines-of-code as an important software metric is not really all that important. We write large systems that must be maintainable, extensible, read well and perform well. Java does that very well, JavaScript does not.

Re:Can your language do this

[asc99c]

For smallish systems, I often find that fewer lines of code translates well to increased readability and maintainability.

While I agree that software engineers are not often writing quick one-off hacks, sometimes they are and Java isn't the best language.

My work mainly involves writing custom software to contract, not producing boxed software. I suspect many developers are doing this, or in-house development rather than working on boxed products.

I'm certainly not advocating that you should use Javascript if you're trying to write boxed software that will (hopefully) be sold to millions of people. But if you're trying to profitably knock out a little widget that someone's willing to pay $20,000 for it isn't automatically a bad choice.

Re:Can your language do this

[asc99c]

Disclaimer: neither me nor the company I work for are developing little $20,000 widgets in Javascript!

Crimes against humanity

[Mongoose Disciple]

I don't think it's fair to call JavaScript a crime against humanity -- most humans aren't software developers...

Re:Crimes against humanity

[Lord Ender]

Most humans do have to wait on javascript to load. And they have to deal with its popups.

Re:Crimes against humanity

[maxume]

No, not really. Probably not even half of us yet.

Re:Crimes against humanity

[GreyLurk]

You know, we all have to deal with Spam too, and that's all from C, Java, and Perl apps... Should C, Java, and Perl take the blame for that?

Just because people have used a language for evil doesn't mean that the language is inherently bad.

Re:Crimes against humanity

[zztong]

Oh phew. I'm glad you didn't say most software developers aren't human.

It has potential...

[LitelySalted]

I would say that JavaScript has potential, just like Luke Skywalker. Both had the ability to do great things and both had/have the ability to do terrible things.

Question is... who is.. Who's JavaScript's father? And will he lead him down the dark side?

Re:It has potential...

[PybusJ]

Brendan Eich is JavaScript's father, and there were those who considered his attempt at JavaScript 2.0 was leading it to the dark side. (Mind you that was mainly Microsoft)

Re:It has potential...

[eabrek]

No, Java is its father.

And it will bring balance to programming by killing all programmers!

Kill Java now! Before it kills us!

Re:Getting JS out of the browser is a *great* idea

[Anonymous Coward]

The idea of Javascript is nice. In practice it's hardly what you describe.

Consider how closures work in Javascript. It's totally retarded and the scoping doesn't work like you think it would.

Lua has basically the same semantics as Javascript but it much simpler, faster, and you get a better design (eg. closures work like they should). Lua is a better Javascript than Javascript.

Works for what it's supposed to do

[gestalt_n_pepper]

It's a tolerable front end language for browsers. It's not as flexible or as fast as C++, but here's a newsflash to the "I'm living in Mom's basement crowd." It doesn't have to be.

It can suck up resources and not be especially fast and not be able to manipulate pointers or be much good for creating new classes and....

(sing it with me now) IT DOESN'T MATTER AND 99.99% OF WEB DEVELOPERS DON'T CARE.

Not all languages are C++, or Ruby, or Java or anything. Nor should they be. Use the right tool for the right job.

Re:Works for what it's supposed to do

[mcgrew]

Use the right tool for the right job.

That's the trouble with javascript: most people don't. I don't know how many times I've right clicked to open page two in another tab to read while I'm reading page one, only to find that there's a blank page because the idiot who designed the page used a javascript link instead of an HTML link.

I do my best to avoid those sites, but unfortunately many of the slashdot articles are in them. One more reason not to RTFA.

Re:Works for what it's supposed to do

[yuhong]

I know, usually what I do to detect these is looking at the URL in the status bar.

Re:Works for what it's supposed to do

[kaffiene]

I absolutely agree.

BUT people *are* trying to write large systems with JavaScript now (applications on the web) and for those things, JS's deficiencies DO matter.

Re:Why bother?

[jellomizer]

Yes lets put all the work on the server. The server should handle all formatting and every single error check and lets wait for the server to respond and reload the entire page to say something is wrong. Lets not have the ability to hide or move objects, because we need to reload the page over and over and over again... Never mind CPUs are Really fast and the standard Desktop has ton of memory. Lets fill up the slower bandwidth with reloading the same information over again.

Sorry your post is screaming, I am not comfortable with JavaScript and it is effecting my 7337 status. So I will insult it so I can seem like I am skilled programmer.

Re:Getting JS out of the browser is a *great* idea

[plague3106]

I agree; JS should be taken out of the browser... but not how the article suggests. It should NOT be brought to the desktop, and it should be obsoleted in the browser.

Its a steaming pile who's replacement is long overdue.

Scripts are fine for small mundane tasks, they're NOT good for building applications.

No!!

[mafian911]

What have you done?! Put it back! Put it BACK!

Javascript: The Good Parts

[slim]

This is the book that'll make you realise Javascript is OK:
http://oreilly.com/catalog/9780596517748

It's not afraid to call out the bad parts, and to show you how to work around them. That's down to a rushed standardization process.

It doesn't deal with the DOM at all - after all, that's not part of JS.

It leaves you thinking JS is pretty neat, if you use it right.

Re:Javascript: The Good Parts

[MightyMartian]

It leaves you thinking JS is pretty neat, if you use it right.

Yes, but I have enough door stops and paper weights made out of THE NEXT REALLY GREAT LANGUAGE(tm)(known to cause cancer in California).

A really awesome language with shitty libraries and object architecture is, ultimately, a shitty language. Because the underlying platforms that JavaScript runs on are so variable, and even where they're relatively well supported, performance sucks so bad, ultimately JavaScript is a terrible language to develop in. It's used because it's the only universal client-side scripting language out there for browsers, not because people like it. That it has some hypothetical advantages, if only it was plugged into a sane object library is rather like saying "My new car would run really great if it didn't have square wheels".

Re:Javascript: The Good Parts

[kaffiene]

I have the book on my desk right now. I've read it page to page. It points out the good bits, true, but also some of the very bad things about the language. It's premise that you can just use the pretty bits and the other bits won't matter at all is a fallacy unless you code in a vacuum that doesn't include other people.

Re:Why bother?

[SanityInAnarchy]

I actually wish JavaScript and other client-side browser scripting would be done away with completely,

Why?

JS is not a particularly 'good' language.

People who say this very often don't know Javascript well at all. It's Lisp in C's clothing. It's actually a surprisingly elegant language -- it has a few warts, but they are almost certainly not what you're thinking of.

Google Douglas Crockford.

Re:Getting JS out of the browser is a *great* idea

[BradleyAndersen]

What is the difference between a 'script' and an 'application'?

Cross Compatibility

[Tarlus]

Just make the damn thing behave exactly the same way in every browser and I'll be sound as a pound!

I can't wait.

[NoYob]

I can't wait for when this language first moves out of the browser, then we'll get coders wanting to beef up their resumes with the "latest technology" and they'll be implementing everything in JavaScript.

System architect: "Here's my design. It will work in any language."

Coder wanting to add a notch to his belt: "I know just the thing for this distributed ERP system: JavaScript! It's the latest technology and we'll be cutting edge.

The architect - who hasn't been keeping up with languages and thinks Java and JavaScript are one in the same: "Sounds great."

Oh, yeah! There's a team I would want to contract on - billable hours gallor!

Re:I can't wait.

[Mikkeles]

Yeah, like writing a distributed ERP system in Java is any better.

Re:Getting JS out of the browser is a *great* idea

[lhoguin]

Javascript is already used for building desktop applications, the most popular probably being Firefox.

Many desktop applications already use scripting languages. For example see the following list of python gtk applications.

Nowadays you can easily write the parts of an application that requires high performance in C and the rest of the program, including the interface, in an interpreted language.

The problem Javascript has to face, though, is that it has very few libraries available for desktop or web applications. And the existing libraries are specifically written for one or the other task. CommonJS would be a common library for all environments and would allow porting code from one to another a lot more easily than it is today.

Re:Why bother?

[ThatMegathronDude]

A-friggin-men. JavaScript is one of the few popular languages with first-class functions. How many JS-bashers have actually written something more than document.write() rubbish?

wrong way of thinking about the issue

[circletimessquare]

the browser is the os. or rather, the browser will become the os. anything and everything of any value to 99% of us in the modern internet-centered world will be interacted with through the browser

so instead of talking about jailbreaking javascript, the more relevant subject should be jailbreaking the browser. such that when joe user turns on his computer in 2015, he gets a browser, and only a browser, and nothing but a browser. native javascript implementation then continues merrily chugging along in the browser, as it always has, otherwise completely oblivious to the fact that it is now the only game in town

note that i'm talking about the computer using experience for the average user. please don't object to my depiction of this scenario from the point of view of the exotic user blocks that plenty of slashdot readers belong to, but don't describe the reality of computer use for the average user

Re:Why bother?

[Anonymous Coward]

Mod parent up. Javascript, or ECMAscript gets a bad rap because a lot of code-pounders don't really know how to use it beyond defining a few c-style functions. It's a fairly powerful language once you understand the grammar. IE6 shoulders most of the blame for fucking it up - things that should work but need a bunch of ridiculous if(ie) incantations chase away most programmers from understanding the fundamentals of the language better. Once you realize that it's *even more* object oriented than Java(sun) then you begin to understand.

Your bias shows: You can't program shit!

[Hurricane78]

If you think JavaScript is a crime against humanity,

In other words “If you can’t program, or if you can’t tell JavaScript from Java or Python,”.

The new versions of JS are really sweet. But most “web-developers” can’t even write proper code in the old one. Which is quickly visible, if you enable strict warnings, and force the interpreter to the newest version. Most scripts throw warnings or fail after that.

I say JS and Python are on par with each other. But they use very different paradigms. JS uses prototypes. And that is what most people do not understand. See it like this: Everything is an object (including functions, which allows really powerful functional programming), everything can be written literally (including objects with functions), and everything has a prototype on which it is based and can be the prototype for other objects/prototypes.

So you build your object, and then use it as a prototype to create other objects with added functionality or changed data.
The elegance of this is, that inheriting and instantiation really becomes the same thing. And in my eyes, the less rules a language needs, while still having all the power, the better and more elegant it is.

It’s crazy how, with the newest version, I can write it nearly 1:1 like I would write it in Haskell! You can’t imagine how happy I was, when I noticed that I would practically a “scriptable Haskell in the browser”. Of course it does not have the type strictness of Haskell. But that is kinda the point.

It even has regular expression literals.

What’s a bit messy, is DOM. Perhaps because it’s a “design by committee with no own sense of reality” (= no leadership) API.

Then again, I’m all for more languages in the browser. Python, Ruby, Lua, Erlang, Haskell and Java are good candidates. C/C++ and Perl are not. (Perhaps Perl 6 in 2051. ^^)

Re:Your bias shows: You can't program shit!

[eabrek]

"Just like Haskell" is damning praise.

How many people can program? (well, not cargo cult scripting) - 1 in 100?

How many programmers can use a functional language like Lisp, or Haskell? - 1 in 20? 1 in 10?

Re:Your bias shows: You can't program shit!

[Hurricane78]

I think “x in y” does not mean what you think it means. ^^

And damn, if it is a great language, and if the language does not let those who can’t programs it create a running program (as is the case with Haskell), and that means that only 1% of those who write website scripts can continue to do so, then that is exactly how it’s supposed to be!

There’s no worse thing than dumbing your design down, because of some retards. Even if those are 99% of the users. It only means that 1. you got no spine to stand behind what you think is good, 2. you are telling nature to create “better” idiots, until the bell curve is in balance again, 3. your whole concept is futile, as there will always someone too dumb for it who will complain, 4. you revert the nice and clean plan of nature, to let him lose the game of natural selection if he does not wise up, and thereby 5. you will be one of those being responsible for pushing us into full-scale Idiocracy.

So I really hope I misunderstood you, and that was not what you were saying. :D

Re:Your bias shows: You can't program shit!

[eabrek]

I mean 1 in 1000 or 1 in 2000 from the general population might be able to understand a functional language really well (.01 * [.1 or .05]).

Is that really the best choice for a language used in writing web pages? (Which should be available to anyone with a little technical savvy)

We shouldn't be expanding the impact of JavaScript. We should be going about replacing it.

I haven't used Haskell. How similar is it to ML?

Re:Your bias shows: You can't program shit!

[kaffiene]

Utter rubbish. I don't like Python because I hate the significant white space thing. BUT Python is considerably better designed than JS. JS has a pile of huge warts to it that prevent its suitablility for large scale engineering. Python does not share any of those weaknesses:

Everything is global
no namespaces
no include/import!!!!
no block level scope
  the array iterator busts array prototype extension and vice versa
no way to avoid prototype extension clashes
no packages / modules

Re:Your bias shows: You can't program shit!

[Requiem18th]

I like Python better than JS for a lot of reasons, that it doesn't deal with undefined vs null vs NaN vs Infinity is a big one. That property access is throughly customizable, as well as item access and function calling customizations. And class definitions inside a class block are more clean and elegant than multiple Class.prototype assigments, the standard way of prototype customization in JS.

BUT, I admit JS has many nice tricks, Object notation makes returning records really easy to create and to use, a feature Python can only awkwardly emulate with namedtuple in recent versions. And I agree that merging the concept of inheritance and instantiation is elegant.

I wanted to share with you an anecdote of the most "eureka" moment I had in JS.

As I was debugging an ajax application, I found a piece of coude that failed under some circumstances because it tried to call abort() on an uninitialized XMLHttpRequest, what coul I do?

I could have changed the logic of the caller, at every call site, to make it test whether the return is a valid XMLHttpRequest before calling abort(),
I could have changed the callee and make it return a mock object, one that implemented abort(), the object was initialized inside an object definition so I didn't had the luxury of multiple statements, I had to write class somewhere else and instantiate it here, or maybe not somewhere else, I could have used a function to wrap multiple statements into an expression.

However, all I did was this:

return {
        foo: ...,
        request: {abort:function(){}},
        bar: ...
}

I didn't have to write and instantiate a class, I didn't even had to use a wrapper closure, just one short expression and I was mocking a core language feature. And the best part is that I did that instinctively, because it's so easy, it was only after the fact that I realized what I did was impossible in Python or any language I know! JS not only conflates inheritance and instantiation, it conflates definition with instantiation.

Spinal Tap coders

[ubrgeek]

> efforts to take JavaScript to the next level

This one goes to 11.

Re:Why bother?

[Alan Shutko]

It's a poor Lisp in C's clothing. Give me LET already!

Re:Why bother?

[Red Flayer]

I am not comfortable with JavaScript and it is effecting my 7337 status.

That's unfortunate... though perhaps now you could join the ranks of those with 1337 status?

OTOH, maybe you were referring to TEAT status, in which case... your ideas intrigue me and I wish to subscribe to your newsletter.

What for?

[Glabrezu]

We already have a good number of established scripting languages that fill the niche. What does Javascript brings into this world that makes it interesting to work again on compilers, module platforms, optimizers, etc.?

The arguments posted in the article about what changed to consider moving javascript out of the browser, are in my opinion, pretty weak:

* We discovered AJAX: besides doesn't having anything to do with the argument, we might say that more than AJAX, browsers started to be a *little* more standard compliant, so designing complex HTML application became less painful. AJAX is really a so simple thing that I really don't believe is the responsible for our buzzed web 2.0 (besides... we always had iframes). Heavy support for CSS, fixing of layout issues, etc., that's what probably brought our web interfaces as we know them today.
* Its included on every consumer computer: Yes, in the browser. You will not use the browser to run these javascript programs, since there are limitations, and for a reason, on what you can do from the browser. Probably, you will need to download a javascript runtime to execute this new javascript programs anyway.
* Designers know how to program javascript: And that is why it's in the browser and not running on your server or free on your computer. Have you ever looked at the average javascript source code? People program as if they needed to save every byte on their source code, avoiding white space and having tons of a,b,c variables. Have they never heard of minimizers? And if size is such a problem, standarize an optimized intermediate representation instead.

What remains is that javascript is cool. That's probably right if you feel cool when you write ugly hacks to make things work.

And regarding problems with javascript to be used on large applications and not as glue code, I would say prototype programming is one of my main concerns. Weakly typed languages already have the disadvantage of lacking compile time type checking, and the difficulties to perform automated refactoring since you don't know to what a variable will refer. But with prototype languages you also add the difficulty to know what's the structure of an object.. In other dynamic languages you can also do it (ie. changing the structure of a class during runtime), but, being there and doing that, it's a probable road to "WTF is going on" (with exceptions, of course).

Re:Why bother?

[pyrbrand]

I tend to go by the thickness of Crockford's book, vs the thickness of any "Complete Javascript" book when determining how much "good stuff" the language has. The truth is it's an accident of history, a tech demo that should never have been released, a baby not even its creator could love (and the Ecmascript 5 group had to tear out of his hands to ensure it remained a compatible language for the web).

Re:Why bother?

[kdemetter]

I agree , it's an extremely powerful language , but you have to know how to use it.

For example , the fact that you can create objects and alter their structure at runtime , is very powerful , but it can also lead to a major disaster if you are not careful.

Re:Getting JS out of the browser is a *great* idea

[brundlefly]

>> The willful violation of the javascript object model for document.all in HTML5 (see bottom of page) is one particularly nasty example...

Not really nasty to implement at all:

get document all() {
return document.getElementById.apply(document, arguments);
}

That's interpreted code, of course, not native code. But if you're in the business of writing parsers and compilers, rolling that into native code is about a 10-minute operation.

Now... I might agree with you that it's misleading to newbies to design a language such that a potentially ubiquitous and expensive call to an external technology (the DOM) is hidden behind a seemingly innocent property lookup. But there again, expensiveness of such a call is an artifact of how browsers are coded, not a deficiency in design.

In principle, there's nothing wrong with providing a associative-array-like API to an action which performs a flat lookup within a namespace of unique keys [albeit admittedly unenforced in this case]. Python, Ruby, JavaScript and most other functional languages offer this functionality as standard fare.

Pick a different example....

Re:JS needs threads

[Nadaka]

most implementations of JS have threads, its just that its transparent to the language.

Re:JS needs threads

[multipartmixed]

> most implementations of JS have threads, its just that its transparent to the language.

Really? Name two.

To the OP: Threads are not the only solution to concurrency. JS works will event loops.

Re:c++ is good

[ArcherB]

it's just sometimes, it's a resource hog.

A bad workman always blames his tools

When you are given a screw driver to drive a nail, blaming the tool makes sense!

JavaScript, the BOM, and the DOM

[rayharris]

In addition to all the other things JavaScript is, it is also a hosted language. "ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment." - ECMA-262 3rd Edition.

People seem to forget there is a distinction between JavaScript, the Browser Object Model (BOM), and the Document Object Model (DOM). JavaScript has no native input or output functionality. These capabilities must be provided by the host. When the host is the web browser, there is a fairly well followed standard for JavaScript, there is a partially followed standard for the DOM, and there is no standard for the BOM.

The reason that people still hate JavaScript is not because of the inconsistent implementations of JavaScript. In fact, JavaScript has been implemented fairly consistently. No, the reason people hate JavaScript is because of the inconsistent implementations of the BOM and the DOM.

If you look in the ECMAScript specification, there is no method named alert. Where does it come from? The host environment. If IE 9 changed the name of the alert method to displayMessage, there would be an uproar that Microsoft "broke" JavaScript. When, in fact, they would have broken an unwritten BOM standard that said the browser would provide a host-based method named alert. It's a subtle, but important distinction.

What is broken is the implementation of the DOM. Some parts of the DOM are implemented consistently. Some parts are horribly different. In IE 8, Microsoft (allegedly) worked on fixing problems with their implementation of CSS. Their implementation of the DOM, however, is basically unchanged from IE 6. This is why web developers still hate IE. Not JavaScript, but the DOM.

As mentioned in other posts above, JavaScript has already broken out of the browser. But is has landed in other hosted environments. ActionScript in Flash is just JavaScript with the "Flash Object Model" instead of the BOM/DOM. You can use JavaScript in Photoshop using the "PhotoShop Object Model" to script the manipulation of images.

The effort here is to provide a "System Object Model" to JavaScript so that JavaScript can interact with the OS more directly. The success of that effort will be based on how well they design the host objects for JavaScript to work with and how consistently those standards are followed. Not on the fact that they're using JavaScript.

And JavaScript on the server is nothing new. I've got an old copy of "Pure JavaScript" by Wyke, Gilliam, and Ting published in 1999 that discusses server-side JavaScript on the Netscape web server. It includes objects to work with form data, files, databases, and e-mail servers.

Am I condoning the efforts to expand the use of JavaScript? No. I just want people that "hate JavaScript" to understand a little better what it is they hate. And I want the proponents of breaking JavaScript out of the browser to realize there are people who went before them and if they stop and look around for a second, there are lessons to be learned before the repeat old mistakes.

Its a great idea! Both P and GP

[nten]

Do away with client side browser scripting entirely and replace it with applications written in Javascript. I like languages, more are better. I don't like the requirement that I have to allow most websites to run essentially arbitrary code on my machine in order to view them. I know I don't have to go to those websites, but it is increasingly required to view just about anything. I don't trust my browser to protect me, and I resent having to switch to my virtual machine to browse, and then always having that notion that my virtual machine is probably a pox ridden compromised bit bucket that I should really empty at least once a week.

Re:Its a great idea! Both P and GP

[Dog-Cow]

Please explain how an application is not running "arbitrary code on my machine".

Idiot.

Re:Its a great idea! Both P and GP

[SanityInAnarchy]

Do away with client side browser scripting entirely and replace it with applications written in Javascript.

Why?

I mean, the main reason people write client side browser applications isn't JavaScript, it's that they're browser applications.

I don't like the requirement that I have to allow most websites to run essentially arbitrary code on my machine in order to view them.

A valid complaint -- most websites should work with Javascript disabled, and noscript proves this. (Though, ironically... isn't noscript, as a Firefox extension, going to be at least partly written in Javascript?)

Also: How does replacing this with a Javascript desktop application improve things? At least the browser tries to sandbox things.

I don't trust my browser to protect me, and I resent having to switch to my virtual machine to browse,

Paranoid much?

But then, if you were to download a Javascript application, wouldn't you run that in a virtual machine, too?

always having that notion that my virtual machine is probably a pox ridden compromised bit bucket that I should really empty at least once a week.

So you're knowledgeable enough to be afraid of scripted web pages, but not enough to use Noscript, and certainly not enough to apply that same paranoia to an application you would download and run with full privileges.

And you're knowledgeable enough to operate a VM, but not to know about its snapshot capability, with which you could get a blank slate every boot.

I'm not sure how to put this nicely, but...

A little knowledge is a dangerous thing.

Already used on desktop

[zdzichu]

Gnome-shell, which will be GNOME 3.0 main UI, is written in JavaScript and works pretty well. JS is capable of much more than flashy web site.

Happened Before, will happen again - ServerSideJS

[Kagato]

I distinctly recall writing Server Side Java Script back when Netscape had a web server product. Netscape was really pushing it as the future. It was slow and lacked features in the Netscape implementation.

Re:Why bother?

[Idiomatick]

"Lets not have the ability to hide or move objects"
Could be CSS...

But yeah, I totally agree with you. The javascript hate probably isn't coming from people that have done web development. PHP is nice but there is a reason why pretty much everyone uses javascript AND php. Were javascript useless everyone would drop it, it would be silly to bother learning it and php.

Re:c++ is good

[Doug Neal]

it's just sometimes, it's a resource hog.

A bad workman always blames his tools

The logical fallacy in this cliche has always irritated me.

- If all bad workmen blame their tools, does it follow that all workmen that blame their tools are bad ones?
- If all dogs are animals with four legs*, does it follow that all animals with four legs are dogs?

* Excluding accidents and birth defects

uninformed masses

[Transfinite]

I find the nagative, un-informed, comments revealing. It reveals most of are unaware of current developments and about a decade out of step with modern techniques. Please all of you, do yourselvs a favour and actually get a clue before responding with general idiocy.

Re:Why bother?

[Anonymous Coward]

Commonly believed fallacy: "the standard desktop has tons of memory/CPU [to spare]"

Re:Why bother?

[Idiomatick]

Yeah, javascript isn't too bad. Looking at the syntax for html/xhtml makes me want to vomit though. No sane programmer today would design a markup language that remotely resembles it.
Random example: (input type="checkbox" checked="checked" /)

Why in the fuck would you have a string? I assume it isn't a string deep down but that doesn't really help the code itself. Another example could be things having names, IDs, classes seems amazingly redundant. Then there is anything to do with tables. And formatting has tons of stupid quirks. Only way it dodges being the worst language ever is the fact that it isn't really a language.

Really?

[ZipprHead]

This has already been done in a way: http://en.wikipedia.org/wiki/Server-side_JavaScript

I did an implementation with Netscape's LiveWire back in 2000 or so. It was a nightmare.

Javascript is elegant and IMHO a great language, I would love to see new features and performance improvements, but as far as moving this to the desktop? Why? Aren't there enough platforms already?

Re:Really?

[Transfinite]

so you'll be aware of this then: http://nodejs.org/

Re:Why bother?

[FreakyGreenLeaky]

Doesn't matter. Inevitably it will provide more work for professionals to fix the abominations.

Re:Why bother?

[aztracker1]

Back in the day (mid-late 90's, even up through 2003 or so) document.write was pretty effective. I used to utilize framesets for client-server communications, and used document.write to rewrite certain navigation frames client side for interactions. Though for some things, after the v4 browsers there were alternative methods, but dealing with IE vs Netscape differences it was pretty painful. Not a fault of the language though. The JS5 (ECMAScript 3.x) spec is pretty nice, and I appreciate ES5 a lot more than where ES4 was going. With the Mozilla enhancements to JS1.7/1.8 I can honestly say I don't miss much at all compared to other languages.

Re:Why bother?

[lainproliant]

A reason that some people feel JavaScript "isn't a good language" is because of the hurdles in developing cross-platform client-side web solutions. Most of this can be blamed on IE not following W3C standards for things like XML DOM (XMLHttpRequest). These hurdles are becoming less and less with IE's slowly waining market share. I used to have a similar opinion of JavaScript: that it was bloated and/or unnecessary. This changed when I actually began to learn JavaScript, and realized that it was a very elegant and capable language. Many APIs and toolkits already offer JavaScript scripting. Qt4 in particular, with its support of CSS style sheets and JavaScript scripting, is a fine example of how web programming paradigms can be used to enhance desktop applications. I think it would be nice to see JavaScript emerge as a ubiquitous "application scripting language".

Re:Why bother?

[Glabrezu]

You mean the Douglas Crockford that wrote http://www.crockford.com/javascript/private.html?

When I talk about an object oriented programming language I'm referring to a language that allows you to use the concepts of OOP in a *natural* and *homogeneous* way. I don't want to write a library and helper methods to write an OO program, I want to use the language.

It's OK if it doesn't has classes, and therefore inheritance does not have a place in Javascript, just stop trying to force it to be something that it was not meant to be (that is a general purpose language to write medium to large scale applications).

Re:Why bother?

[Transfinite]

"I actually wish JavaScript and other client-side browser scripting would be done away with completely" Really? no more facebook, twitter, etc, ect.. for you then. So you'd do everything server side eh? where it belongs? I don't think you have thought about that have you. Go on think about what you have just said, really think about the implications. Or perhaps you actually think the web is about as efficient as it can get, everything on the server.

Re:Why bother?

[Carewolf]

It's a poor Lisp in C's clothing. Give me LET already!

Okay... let a equal 3 in javascript:

a = 3;

JavaScript has real problems

[pydev]

Scripting languages are not interchangeable. While JavaScript hackers may hate me for this and while JavaScript has some nice features, I think prototype-based OOP and JavaScript scoping have turned out to be bad ideas. There are worse languages than JavaScript out there, but I won't be switching if I can help it.

Re:Getting JS out of the browser is a *great* idea

[plague3106]

That people are doing it doesn't mean its a good idea. Also, I use exactly zero of the applications, and 99% of the i never even heard of.

As for writing applications, I've always found myself to be way more productive with compilied code instead of scripting, which always seems fragile to begin with.

The problem JS has is that it sucks. When I can do: myDom.madeUpProperty = 'bleh'; and things chug along just fine, that's a problem.

Re:Why bother?

[outZider]

You don't actually create web pages, do you?

Re:Why bother?

[slim]

I tend to go by the thickness of Crockford's book, vs the thickness of any "Complete Javascript" book when determining how much "good stuff" the language has.

I believe there are two reasons for this:
  1. Crockford's writing is concise and to the point. It assumes prior programming knowledge.
  2. Crockford's book does not concern itself with the DOM

So I believe a good chunk of the extra stuff in the fatter books is "here's what a loop is", "here's what if() does", and a bigger chunk yet is about HTML and CSS.

Re:c++ is good

[dgatwood]

The logical fallacy is only because the quote has gotten distorted severely over the years. The original saying, translated to English from Old French, reads "Bad workers will never find a good tool." This version makes much more sense.

Source: http://www.answers.com/topic/a-bad-workman-blames-his-tools.

Re:Getting JS out of the browser is a *great* idea

[maxume]

You haven't addressed the part where document.all needs to return a special collection type that breaks the object model in several different contexts (when passed to toBoolean, it should evaluate to false, which breaks the object model, and there are a couple of contexts where it should evaluate to undefined...).

Understand the example...

Re:Why bother?

[Glabrezu]

"One of the few popular languages with first-class functions"? Allow me to disagree but almost every dynamic language I know of has first-class functions.

Other languages, like C, C++, C#, also allow you to use functions as a data type.

I agree that, in some of them, their syntax does not make it easy to define functions as, for example, an argument, but you can define the function first, and pass it as an argument later if needed.

Closures are another thing altogether, but they are supported on many dynamic languages.

Re:Why bother?

[elnyka]

I actually wish JavaScript and other client-side browser scripting would be done away with completely, but JS is not a particularly 'good' language. The only advantage I can see is that thousands of Web developers can now write desktop applications. Is that necessarily a good thing? or will it just lead to more inefficient crapware?

Dude, we get crapware in any language. Have you see the average code churned out in Java, C# or C? What exactly is wrong with JS? It is a good tool for what it does. That people suck at it is another thing. In the last three large projects I've been involved (my tasks on those three have always been back-end work mind you except for Swing work at the present time), three different teams have produced phenomenal work on complex, rich UIs in JavaScript.

I wouldn't want to have done that work on Swing. Can be done, but it can really turn into a PITA to get it right and clean. That JS work I've seen has been far more superior in quality that a lot of the back-end and JSP shit that I've had to fix or integrate with in Java. Some of those javascript "web developers" you refer to can give a lesson or two on software engineering principles to many Java/C#/C++ dilettante wannabes who think JavaScript is good for nothing.

I mean seriously, I don't even work on JavaScript, but I've seen enough good work on it to really wonder what the hell some of you guys are babbling about. Not a single objective explanation of it, just pure soapbox opera. Furthermore, anyone with enough work experience knows that good software and bad software can (and is written) in any language. Suckage is language independent.

Re:Why bother?

[Anonymous Coward]

> Why in the fuck would you have a string?

Because SGML, that's why. It's a really generic language (a markup language, not a programming language), and having one builtin type (strings) for attributes seems to fit. Anyway what it is is a delimiter syntax for the values of attributes. Leaving them out doesn't really help the situation either.

id is a unique id in the HTML namespace, name describes the name of a field in a form object. You can and do reuse those. Blame IE for the confusion, it's the only one that treats "name" as special on any other elements.

HTML a pile of half-baked hacks, but not everything they did was stupid. There's a reason alternatives didn't catch on.

Re:Why bother?

[MattPat]

Oh dear, oh dear. Where to begin.

Yeah, javascript isn't too bad. Looking at the syntax for html/xhtml makes me want to vomit though. No sane programmer today would design a markup language that remotely resembles it.

You are, of course, correct. That's why no one uses XML-based dialects anywhere, ever.

Random example: (input type="checkbox" checked="checked" /) Why in the fuck would you have a string?

The fact that all attributes in XML (and thereby, XHTML) are quoted removes ambiguity, and avoids any issues with attribute values that have spaces.

Another example could be things having names, IDs, classes seems amazingly redundant.

IDs and classes serve totally different semantic purposes, and names aren't even a part of the standard anymore except when it comes to form elements. Any redundancy that exists is necessary to allow flexibility and semantic correctness.

Then there is anything to do with tables.

Tell me when working with tables is ever fun.

And formatting has tons of stupid quirks.

Well then it's a good thing that Good Web Developers(TM) don't use XHTML for formatting.

Only way it dodges being the worst language ever is the fact that it isn't really a language.

Well no, it's a language, just not a programming language; XHTML is a dialect of XML, a mark-up language, and a very good one at that. Name me one other mark-up language that's as flexible, powerful, and with as much potential to be extended.

Good platform BUT one-size-fits-all language.

[boorack]

If we talk about languages, I prefer real LISP over JS. Not that JS is bad, but I still have to see language that matches LISP in many areas (see LISP macros). Most of today apps use JS in browser and something other on server. This is BAD, no matter how cool JS itself is.

While using Java Script on server is (some) option, there is also other way around - see GWT or Pyjamas. As browser is becoming a full-fledged platform, it is screaming for support of other languages along side with JS. While it is possible to compile other languages into JS, it's a kludge. The whole situation screams for splitting JS into lower level instruction set (along with object model implementing cool JavaScript features, like first class functions, prototypes and functional programming features) and JS language implementation on top of that. Other languages would compile to this intermediate representation as well. I would like to use my LISP for implementing in-browser code (Scriptjure does it but it is still in its infancy and it will become kludge, like GWT anyway)

Re:Good platform BUT one-size-fits-all language.

[SanityInAnarchy]

Most of today apps use JS in browser and something other on server. This is BAD, no matter how cool JS itself is.

Why is this bad?

I mean, I don't entirely disagree, but it seems a minor issue, really. After all, unless you're using CouchDB, your database queries are written in some query language (probably SQL), which is entirely different than the language your server-side app is developed in.

As browser is becoming a full-fledged platform, it is screaming for support of other languages along side with JS.

And some browsers support this. There are also other ways of doing it -- for example, JRuby as an applet, or various Silverlight bastardizations.

Re:JS needs threads

[binarylarry]

Rhino and JScript.NET

Re:JS needs threads

[elnyka]

It needs threads. I know the unwashed masses don't know what to do with them, but if you *do* know, then they can really be used to make much simpler code.

Explain to me what kind of client-side, browser-running work requires explicit usage of threads and how this will actually and definitely will lead to much simpler client-side, browser-running code? ***

I'm looking forward to see some examples of this.

*** not to mention that out of all concurrency models possible, the things you ask for client-side code is threads. Fantastic.

Re:Driving 90% of the web into 99% of the malware

[elnyka]

See subject-line, because that is what javascript also entails, since it is typically the delivery mechanism utilized by malicious website or ads that cause malware infestations today.

Is is a language problem, or a security engineering problem? Don't bother answering it, it is a rhetorical question.

I remember...

[hesaigo999ca]

I remember a long time ago, I used to use javascript within the browser with useless home pages that did pretty much all my coding formatting for me. I would use a template type schema for building my sql queries, or even try to filter text returns based on entry in the textbox, because it was just quicker to code then opening a full visual studio interface etc...etc..

It definitely has its uses, and is by far a very effective language to do what you want with, with regular expressions as advanced as perl, and object oriented model within the dom that is way further advanced then some other languages ....I have to say I am interested in what will develop from this.

Re:Why bother?

[Wizel603]

The javascript hate probably isn't coming from people that have done web development.

It's probably coming from people that have done web browsing.

Re:Why bother?

[nobodylocalhost]

Yes, lets give control of the client to the server, nothing ever could go wrong. It's not like making JS into a common service on all clients can potentially open the flood gates for malware like activex did... oh wait...

Re:Getting JS out of the browser is a *great* idea

[aztracker1]

Tell that to all the Python developers... This is not meant as flame-bait, only pointing out the fact that yes, interpreted languages are perfectly suited to developing applications.

Re:JS needs threads

[tixxit]

What goes on in the back-end is irrelevant. What matters is that your script is single threaded. All functions are atomic and busy waits will prevent any other JS from executing. If an event happens, the browser will wait until the current function is done executing before notifying the callback for the event. This actually makes programming for JS very easy and does not really hinder the event-driven nature of client-side browser scripting at all. At best, I think you can think of callbacks to the server as worker threads (work is being done by the server), though when your client-side code is called back, it will be sequential and it won't execute concurrently with any of your other code.

Well, I used javascript for a game

[roguegramma]

Well, I used javascript for a puzzle game when there was no Ajax; I used an iframe for loading data instead of xmlhttprequest, and things were called dhtml for dynamic html. Game is still essentially working without modifications in modern browsers: http://hylzee.sourceforge.net/hylZee/
(Preview; The full version is meant to be downloaded and hacked.)

On the other hand, somehow, in ff+addons the victory advancement to next level doesn't work and the loss message is hidden/misplaced.

Re:Why bother?

[multipartmixed]

Apples and Oranges.

"Complete" JavaScript includes way too much browser-specific shit. Take out stuff that is not core JavaScript, and suddenly the two books are of the same order of magnitude.

Re:JS needs threads

[tixxit]

Also, most event-driven GUI frameworks work with a single event thread as well (eg. GTK+, Swing and most others). Yeah, you can do work in the back ground in other threads, but if you have to modify the GUI or you get notified of an event, it all happens in the same big thread.

Most of you don't know what you are talking about

[elnyka]

A lot of the "JS sux" crowd seem stuck in the Netscape era, recalling the horrors of javascript coding on geocities-look-alike websites that bloomed and died (like red tides) during the dot-com boom.

RIAs that work well on IE and FireFox (the predominant browsers used in commercial sectors) are being developed today in JavaScript with jquery, gwt or dojo. And crappy client-side applications are being written as well. But anyone with a modicum of work experience knows that the responsibility of writing shitty applications rest squarely on the developer.

Some of the crappiest, worst code I've seen had been written on Java, C# and C++. And also, some of the clearest, most maintainable and elegant pieces of code I've seen were written in FoxPro and JavaScript. Every single language sucks in one aspect or another.

A good software professional, a pragmatic one, he looks at the language, at the tool, works around the problems and gets the stuff done with it in a clean manner.

Shitty programmer OTOH will screw it up no matter what.

And coding divas will get all emotionally attached to a given language, throwing subjective infantile rants towards whatever language they don't like recalling anecdotal memories mixed with technical impressions too superficial to be called "first-hand educated knowledge".

I don't like JS global scoping and lack of namespaces, but I do love it's object prototyping capabilities and support for functional programming. You can write some really complex client-side, browser-running systems with a brevity and clarity you cannot match with Java or C#.

That is the reality. It is a perfect tool? Nope. It is a good tool for what it is intended to? Yes. You can't get emotional against a tool, specially if you have never been able (or are incapable or have never assigned) to create a good NON-TRIVIAL application with it.

Re:Why bother?

[FictionPimp]

How do you hide or move a DOM object in real time with css? For example how do you do this with css
(jquery example)

$("p").click(function () { $("p").fadeOut("slow"); });

I'm not a javascript fan, but I have to use it daily for the tasks given to me.

It's already being used outside the browser

[SCHecklerX]

Palm's WebOS. I'd prefer perl there, but it is what it is.

Re:JS needs threads

[deanlandolt]

Threads are not the only solution to concurrency. JS works will event loops.

And Promises make event loops even nicer.

But don't forget about Web Workers which gives us feeble javascript programmers true shared-nothing concurrency.

See http://cappuccino.org/ Objective-J

[Anonymous Coward]

See http://cappuccino.org/ Objective-J

That is an indication of the power and elegance that Javascript might have outside the browser.

Re:Why bother?

[Ash Vince]

Yes, lets give control of the client to the server, nothing ever could go wrong. It's not like making JS into a common service on all clients can potentially open the flood gates for malware like activex did... oh wait...

Please do not compare JavaScript to ActiveX. Firstly, ActiveX code had unrestricted access to your entire local machine. This was such a godawful idea that many people screamed how stupid it was almost as soon as it was announced. Javascript on the other has much more limited access. It is not able to access my local machine, and nobody is talking about changing this.

What they are talking about is making you able to write JS code that would be executed on the server side and maybe other places too. There is no indication that they intend to drop all the security restrictions ala ActiveX so code that was embedded in a web page would still run with a different level of access to JS code I executed myself as part of a local file saved to my desktop. If I am stupid enough to download a file to my desktop then execute it without it coming from a trusted source then I am going to run into trouble sooner or later anyway, regardless of if the file is written in JavaScript.

Really they are just talking about making JavaScript more like .NET which may or may not be a good idea depending on your point of view. I know it can be executed as both a server-side scripting language to control dynamic websites and a client side language to provide desktop applications and as part of the browser in the form of silverlight. I do not know enough about .NET security policies to know the inherent problems this may cause or if the code has to be structured differently for each context.

Any .NET gurus care to add about its pitfalls in this regard?

Re:Why bother?

[Steauengeglase]

I'm inclined to agree. There are some folks who need to lose the "Haha, javascript has no java, its just a marketing term for retards!" mindset. Because I've seen plenty of them working an extra 9 hours a week trying to make a hammer operate like a jig saw.

Re:JS needs threads

[multipartmixed]

Hmm, Didn't think about JScript.NET.

Seems like it's about as popular as Rhino.

Which still doesn't get all the way to "most engines". :)

Re:Why bother?

[multipartmixed]

NO, you idiot, take out the stuff that's not JavaScript before comparing against a book that is about JavaScript.

Christ Almighty, the trolls are stupid today.

Re:Why bother?

[physburn]

If client-side scripting went away, we'd lose a lot of functionality from websites. For example, editors for blogs and many forums, need javascript to work they link buttons. Widgets and many interactive website can dynamically update parts of a page using Ajax again javascript based. The web would be a poorer place without JS. Yes I agree that JS is a rather poor language, it grew into the browser, without any great design thoughts, and has many annoying language faults, i particular don't like declaring everything as 'var' instead of give a type for it, it leads to errors and hurts readability.

---

JavaScript Programming Feed @ Feed Distiller

Re:Why bother?

[Carewolf]

I know exactly what a let form is. The code was not scoped so it was already on global level, declaring variables local in global scope doesn't do much. This did on global level exactly what let would in a procedural language. That is define the value for all following statements (for functional languages, all embedded statements). If you need let-embedding add a lamba expression (called function() in js), and you get nice scoped variables.

Of course I would have gone for something a little more complex than a LET form...

Sure.. but given JS expressive power, I dare you.. Especially compared to LISP.

If you ask for threading though, I yield ;)

Re:Why bother?

[Tim C]

The server should handle ... every single error check

Yes it should. Perhaps as well as the browser, to reduce round-trips and bandwidth use, etc, but the server must check its inputs, otherwise it will accept whatever rubbish a browser without JavaScript support chooses to submit to it.

I'm not arguing against your main point, but nevertheless the server must *also* perform error checking.

Re:Why bother?

[Captain Segfault]

a language that allows you to use the concepts of OOP in a *natural* and *homogeneous* way.

Closures are a natural way to implement private variables.

A private variable is one whose scope is limited to the members of that object. The natural way to do that is to define the member functions in the same private scope as the caller. Assuming you want multiple objects you need a separate scope for each object, so you use the scope of the constructor.

It's OK if it doesn't has classes, and therefore inheritance does not have a place in Javascript

But it does have classes. You just don't need explicit syntax to call them out; they're duck typed.

Re:Why bother?

[mujadaddy]

How do you hide or move a DOM object in real time with css? For example how do you do this with css (jquery example)

$("p").click(function () { $("p").fadeOut("slow"); });

I'm not a javascript fan, but I have to use it daily for the tasks given to me.

Congratulations, you've just loaded 50-300kb of javascript (depending on your jQuery version) to fade out an element.

The "fading slowly" part is the ONLY bit that can't be accomplished with CSS. Hiding and moving is trivial, even cross-browser. Trust me.

I'm the lead programmer for a Fortune 300 site, and we're handed third-party content forced onto us by Marketing, et al, that uses Jquery, et al, to accomplish the SIMPLEST of tasks. I have yet to see something implemented in jQuery that would require more than 20 lines of javascript.

jQuery is NOT for programmers, it's for tools who think they're coding when they lay out HTML.

Re:Getting JS out of the browser is a *great* idea

[brundlefly]

I do understand the example. They want document.all for *only* two reasons. 1) So old code can check "if (document.all)" and proceed accordingly, as a form of poor man's browser sniffing, and 2) So old code written against document.all can still run.

Neither one of those reasons is violated by my posting, which in essence says that there's nothing wrong with the spirit of document.all, just the implementation(s).

Cheers....

Re:Why bother?

[Idiomatick]

He just said hide/move ... didn't say fade...

Re:Why bother?

[ShieldW0lf]

How do you hide or move a DOM object in real time with css? For example how do you do this with css
(jquery example)

$("p").click(function () { $("p").fadeOut("slow"); });

I wondered that myself when attempting to put dynamic effects in a myspace page.  They strip out any script you put in, but they leave css alone.  This is what I used:

< style >

.leftthumbnail span{
position: absolute;
top: 0px;
left: -1000px;
visibility: hidden;
text-decoration: none;
}

.leftthumbnail span img{
border-width: 0;
padding: 2px;
}

.leftthumbnail:hover span{
visibility: visible;
left: 120px;
}

.rightthumbnail span{
position: absolute;
top: 0px;
right: 10000px;
visibility: hidden;
text-decoration: none;
}

.rightthumbnail span img{
border-width: 0;
padding: 2px;
}

.rightthumbnail:hover span{
visibility: visible;
right: 120px;
}

< / style >

< div style="position: absolute; top: 200px; left: 10px; width: 100px;" >
< a class="leftthumbnail" href="http://www.myspace.com" >
< img width="100" src="http://path.to.your.first/pic.jpg" border="0"  />
< span >< img width="400" src="http://path.to.your.first/pic.jpg" />< / span >
< / a>
< a class="leftthumbnail" href="http://www.myspace.com" >
< img width="100" src="http://path.to.your.second/pic.jpg" border="0"  />
< span >< img width="400" src="http://path.to.your.second/pic.jpg" />< / span >
< / a>
< / div>

< div style="position: absolute; top: 200px; right: 10px; width: 100px;" >
< a class="rightthumbnail" href="http://www.myspace.com" >
< img width="100" src="http://path.to.your.third/pic.jpg" border="0"  />
< span >< img width="400" src="http://path.to.your.third/pic.jpg" />< / span >
< / a>
< a class="rightthumbnail" href="http://www.myspace.com" >
< img width="100" src="http://path.to.your.fourth/pic.jpg" border="0"  />
< span >< img width="400" src="http://path.to.your.fourth/pic.jpg" />< / span >
< / a>
< / div>

What this is doing is taking advantage of the CSS hover selector for the anchor (link) tag to adjust the style of the span tag contained within.  That span contains our large images, which are shunted way off to the left of the screen out of sight when you're not hovering over the link and are positioned on screen when you are hovering over the link.  You can use this to generate quite a selection of effects if you're creative.

Re:Why bother?

[znu]

How do you hide or move a DOM object in real time with css?

Right now? You don't. In the future? Maybe CSS animation (already implemented in WebKit).

Re:Why bother?

[enderjsv]

You kiddin' me? Granted, using jquery for one line of code is a bit much. Luckily I don't know anyone who does that. Usually jquery is used throughout the page. If you consider the amount of memory saved by turning multiple 20 lines javascript code segments into single jquery calls, I bet a lot of that memory is given back. But wtf am I saying? Who gives a shit about 50-300kb of space nowadays. It's not a 56kb/sec world anymore. Get over yourself.

Re:JS needs threads

[Nadaka]

I spoke without verifying my facts. Some of the guys I worked with at my previous job were definitely javascript fanboi's, I probably wasn't listening to them very well as they described how awesome javascript was.

Re:Getting JS out of the browser is a *great* idea

[maxume]

Yes, but your implementation completely fails to address the html5 specification, which is the issue, not that the lookup hides an expensive call.

Re:Why bother?

[drx]

jQuery is NOT for programmers, it's for tools who think they're coding when they lay out HTML.

So what? Who cares about 50 kilobytes of extra data coming down the wire? Probably the logo graphic of your Fortune 300 company uses more bytes.

If your only diffenrentiation from "amateurs" working with jQuery is that you can spare a 50kb download then probably your skillset is not adequate for today's world, dude!

Re:Why bother?

[Keeper Of Keys]

No, for that you need Python,

Re:Why bother?

[Keeper Of Keys]

You can still make document.write() work, but it tends to be avoided nowadays because it's not unobtrusive.

Re:Why bother?

[rated-r]

and while you're at it, you can add the missing close bracket in your sig... that certainly would not compile....

Re:Why bother?

[Idiomatick]

Oh, I like xml...

"checked" could still have been 0/1 even as a string, having a whole word seems longwinded, it isn't like web designers don't know what boolean is.

I like xhtml, it helps... I just wish they made it a little bit more geared towards programmers rather than ordinary joes. And didn't feel like they had to follow html, seems redundant since it is really just strict html. And there are still issues in implementation anyways... but that'd be IEs fault.

ID could have been reused for names automatically with no issues. IDs have no real requirement to be unique, could have had them replace classes as well with no issues. Perhaps allow for multiple IDs even (more like tags).

Point taken on tables, I still think htmls implementation is extra borked, the way css styles are applied is strange though that may be css' fault.

Agreed, html isn't to be used for formatting or so the theory goes but it is available... And people use it. Unless webpages are all div/span tags with a link to the css then people are using html for formatting. (yes, even header tags count since they change font sizes)

Re:JS needs threads

[elnyka]

Come on. I know nobody RTFAs, but the word "server" is in the fucking summary.

How funny that you mentioned that no one RTFA - the first sentence that reads on the CommonJS' page reads as follows: Welcome to CommonJS, a group with a goal of building up the JavaScript ecosystem for web servers, desktop and command line apps and in the browser. It is not specific to server development.

But let's play your line of argument. I know that the word "server" is in the summary. So what? Ever heard of "separation of concerns"?

Just because it runs on the server, it does not mean it has to have access to thread functionality. Most application-specific Java code that runs on a web server/JEE container does. not. ever. ever. spawns. a. thread. Doesn't have to. The container is the one that managers concurrency, with app-specific code being executed in a thread to handle incoming requests.

App-specific code running on a web server is, from an architectural point of view, to be treated as managed code Every time you see managed code spawning a thread (except in initialization servlets), you should see that as a sign of a code snafu, something that can be better replaced (in most instances) with some sort of message-driven plumbing.

In a similar manner, you can have managed code on groovy, clojure or, why not, javascript, running on top of a server that does concurrency management for you.

None of the things CommonJS strives for are for building multi-threading servers, but to build managed code that runs on the server side of things.

And assuming that there was a valid initiative to include a concurrency mechanism on JavaScript, an actor/messaging/rendezvous mechanism would be more appropriate for app-specific concurrency as opposed to bare-bones threading.

Re:Why bother?

[kdemetter]

I know, the commas in my sentences make no sense at all.
I just type them automatically, without thinking about it. It's a bad habit which is hard to lose.

Anyway, thanks for reminding me.

Re:Most of you don't know what you are talking abo

[VinB]

"You can't get emotional against a tool,..."

Not so sure about that. I've known many a tool in my day and it is very difficult not get emotional if not down-right pissed.

Actually...

[weston]

Inability to perform CPU-intensive computations due to these dynamic types of yours

The dynamic types really don't slow it down that much, and it depends on your implementation. Google's V8 does well enough to run an NES Emulator at comfortable speeds.

lack of threading or any other explicit or implicit parallelism support

Parallel execution is actually pretty easy in a browser context using setTimeout and setInterval, though synchronization is a bit of an issue. But if you really want threads, hop on Rhino and pull from Java.

no library facilities to modern 2D/3D graphics libraries

In the context of a browser, Canvas actually gives you a lot. But outside of that, Rhino gives you everything Java's got.

Re:Actually...

[iamacat]

The dynamic types really don't slow it down that much, and it depends on your implementation. Google's V8 does well enough to run an NES Emulator at comfortable speeds.

You do realize that NES is 25 year old technology designed to be dirt cheap rather than fast even at it's time? When I want real-time video augmentation in my app, I think I will take static typing and threads rather than being slowed down "not that much".

Re:Why bother?

[FictionPimp]

You would rather I wrote 20 lines of javascript to get my point across? I've used prototype, jquery, dojo, etc for a variety of things depending on the requirements. Most web developers can understand jquery quickly so it made a good choice for the example. If that was the only 'animated' event on my page, then yes I probably would not use jquery. Lately I'm doing a lot of complex table/datagrid manipulation with tons of silly animations (I create the page, I don't make the requirements, my customers do). Jquery handles the ajax, the datagrid, the animations, the dialog windows, the modal windows, etc with just two fairly small libraries. Life is easy, customers are happy, I'm paid.

Re:Why bother?

[FictionPimp]

That's great for a hover, but can you say make a parapgraph disappear when it's clicked and stay gone? As far as I know, it can't yet be done.

Re:Why bother?

[FictionPimp]

Now if only we can get everyone onboard the same standard.

Or You Learn To Use The Language

[weston]

Language designers need to think big from the get-go. When they don't, people suffer.

Or they learn to use the language.

Namespacing in Javascript isn't hard, you define a global object that becomes your namespace and everything else you implement becomes a property of that object.

Block scoping? Easy-peasy, if you really need it. Make an instantly-called anonymous function.

Global variables? Know your scoping rules and use them appropriately. This is the same solution as one has to apply in most of the languages out there, from C to Python.

Javascript has some warts, but these aren't it.

Re:Most of you don't know what you are talking abo

[eabrek]

All IMNSHO (I don't know JS, but I do know a lot of other languages)

• C# is a bad Java clone (tainted by MS)
• Java is a dumbed down version of C++
• C++ tries to be a better C (and largely fails)
• C is 30 years old, and shows it

How does JS compare to a good, modern language - like Python or D?

Re:Why bother?

[Toonol]

That's good to know... but I'm not sure, at that point, that it's any better than Javascript. Except, of course, when Javascript is blocked.

Threading and 2D/3D

[weston]

I'll give you the lack of threading.

Why? For many uses, the asynchronous/parallel execution you get from setTimeout and setInterval work great. And if you're working on Mozilla's Rhino, you can use Java's threads.

2D/3D libraries

I think your larger point that many languages don't have this built in by default is a good one, but I wanted to point out there's some great stuff emerging on top of the canvas tag and SVG, and again, if you're not working in the browser, you're welcome to help yourself to anything Java's got by using Rhino.

Re:Threading and 2D/3D

[tepples]

For many uses, the asynchronous/parallel execution you get from setTimeout and setInterval work great.

And for other uses, it does not. If I discover that something in my JavaScript application takes too long on a dual-core Atom, how do I take advantage of that other core?

I think your larger point that many languages don't have this built in by default is a good one

C doesn't have OpenGL, but all three major desktop operating systems have OpenGL. Likewise, ECMAScript alone doesn't have the HTML DOM, but all four major web browser engines have the HTML DOM because they implement "JavaScript" (the combination of ECMAScript with the HTML and CSS DOM).

Re:Why bother?

[Toonol]

Adobe Flash uses a slightly modified/enhanced version of Javascript ("Actionscript") for its backend. It's actually a pretty nice language... it's not very fast, but it's very quick and easy to work with.

Anyway, they have basically two models for programming in flash... the typical flash applet that you come across online, and 'flex' applications, which are intended to be stand-alone programs. The former have a very restrictive security model, but can be executed in-browser across domains. The latter has much lighter restrictions (it can access your file system, for instance), but can only be executed from the local machine. In other words, the 'flex' program is basically like any other stand-alone program.

I haven't seen many stand-alone flash programs, but I think that it is used for some small games. It's basically a pretty slow and simple language, although with some advanced OO features, and a very nice graphics API.

Re:JS needs threads

[jsebrech]

They're called web workers, in the process of being W3C standardized, with shipping code in Firefox 3.5, Safari 4 and Chrome, with fallbacks possible to google gears on other browsers. Basically they're threads with no shared memory model, relying only on message passing / event mechanisms for synchronization.

With web workers you can do stuff like ray tracing or interactive video processing in the browser. If you can't see the potential for that in client-side code then nothing I say further will convince you otherwise.

Re:c++ is good

[soliptic]

Awesome. I wish I had mod points for you.

ObjectCloud

[GWBasic]

Shameless plug

I've been working on a web server that exposes a file manipulation API via AJAX with an automatically-generated JavaScript wrapper. What I found is that some kinds of operations really need some form of server-side business logic; so I added server-side JavaScript with automatic generation of an AJAX wrapper. In essence, I have a form of server-side JavaScript with a transparent RPC system for in-browser JavaScript.

http://objectcloud.com

What I've found is that server-side JavaScript is still in its infancy. (My Alpha Server likes crash a bit too much...) The point, however, is that server-side JavaScript allows for rapid development of applications because it lends itself naturally to a JSON-based RPC system that practically eliminates the complexities of serialization from languages like C, C#, Java, PHP, ect. This is especially useful because things like database queries can be pumped directly to the browser without having to write lots of data access code. Likewise, server-side JavaScript lets me quickly write glue code where my server's API would require too many back-and-forth calls; or where extending my server's API is a poor design choice.

Rhino

[skeeto]

It's what they did with Rhino.

Re:Most of you don't know what you are talking abo

[^_^x]

Personally I'm less concerned with its elegance as a language, or what a capable programmer can do with it, and more concerned about what a malicious programmer might do - like the vast ocean of exploits for everything - not just Netscape and IE, but Firefox, Opera, Safari/OSX, Adobe Acrobat, and so on... Virtually any language will have its abuses, but I think they'd be better served by dumping Javascript and starting from scratch - it's a toss-up whether it or ActiveX is the more dangerous scripting language to allow...

Re:Why bother?

[hobo sapiens]

"I actually wish JavaScript and other client-side browser scripting would be done away with completely, but JS is not a particularly 'good' language."

Most people who have this opinion are people who don't actually know how to write javascript or understand its power. Are you one of them? My bet is on yes. Oh, and as cool as jQuery is, knowing how to write jQuery is not the same as knowing how to write javascript.

Re:Why bother?

[hobo sapiens]

yes, forget judging a book by its cover. Let's judge a programming language by the thickness of a (very good) textbook about it. Your rubric makes a ton of sense. I'll apply it to your short post.

Re:Why bother?

[pyrbrand]

You're right, I was making a rhetorical point, not a logical one.

The main thing I dislike about Javascript is that it's not a designed language. What I mean by this is that the most basic way of doing things should be the correct way. By this metric, Javascript fails miserably. There's so much broken - scope, the this keyword, scope for eval'd code, the hoops you have to jump through to make "private" functions and variables, etc. I also have a strong bias against untyped languages and those whose syntactical correctness you can only test by running it with complete code coverage. Even tools like jslint are miserable compared to the compile errors, warnings and other static analysis info you get from a well tooled, typed, compiled language. On at least part of this last part, Brendan Eich agrees with me, although the rest of the world managed to convince him it didn't belong in Ecmascript. http://www.infoworld.com/d/developer-world/javascript-creator-ponders-past-future-704?page=0,3

Re:Why bother?

[rgo]

I agree wih most of your post, but you are wrong about XMLHttpRequest, which was introduced by Microsoft.

Re:JS needs threads

[Quantumstate]

Try looking up web workers. It is pretty new but is is definitely implemented in Firefox 3.5 and the latest version of Chrome. I have not used them personally so I can't comment on how well they implement threading but the feature is there.

Re:Why bother?

[Anonymous Coward]

It's been my observation that most PHP programmers can't be bothered to learn PHP.

Re:WELL

[easyTree]

tldr squared!

Re:JS needs threads

[microbox]

JS works will event loops.

Event loops are awesome for some problems, and a PITA for others.

Simpler?

[SanityInAnarchy]

Bullshit.

If you do know what you're doing with threads, I'll grant that you can mostly avoid making things worse than unthreaded code. But I'm sorry, I don't buy that threading makes things simpler -- race conditions, deadlocks, corruption due to forgetting to lock, synchronization in general is a bitch.

Now, if you mean better performing code, I agree -- if you've got multiple cores. Even then, processes are generally a better model -- and certainly in an imperative Algol-derivative like Javascript, it's going to be much simpler to go with some form of cooperative multitasking.

Re:Why bother?

[SanityInAnarchy]

There's so much broken - scope,

Example, please.

the this keyword,

Yeah, it only does exactly what I'd expect, in a fairly predictable way.

scope for eval'd code,

Eh, maybe. I'm letting this one slide because I can't remember the last time I used eval directly.

the hoops you have to jump through to make "private" functions and variables, etc.

I'd call that a feature. If you're relying on the language to make something "private", you're Doing It Wrong.

I also have a strong bias against untyped languages

Thanks for admitting that -- but this is a bias, and it's also not, by itself, justification for calling a language "bad".

those whose syntactical correctness you can only test by running it with complete code coverage.

I'm skeptical of this -- if you said "correctness", I'd agree, but that is true everywhere. Syntax? If you're not using eval, isn't parsing it enough to show syntactical correctness?

Even tools like jslint are miserable compared to the compile errors, warnings and other static analysis info you get from a well tooled, typed, compiled language.

This is, again, a matter of opinion.

I am of the opinion that compile errors and warnings are, ultimately, a kind of unit test. In particular, typing is a kind of unit test -- you are saying, "This method should only receive arguments of this type." It's just a very limited and highly specialized kind of test, which becomes irrelevant when you're already testing "This object should behave in this way."

These are also unrelated to it being "compiled" or not, which is ultimately an implementation detail. I find it much harder to learn a language without an interactive prompt.

On at least part of this last part, Brendan Eich agrees with me, although the rest of the world managed to convince him it didn't belong in Ecmascript.

Following your link, I found this snippet especially enlightening:

We’d like to be flexible about this and not make things painfully static in a fixed way like Java does.

It's also a stunningly fluff article, at least that page of it.

snapshot

[nten]

I did not know about snapshot, thanks! I do use noscript, but who to allow? Even fortune 500 are getting compromised left and right. The VM is so I can allow pages I don't really trust (like gamespot for instance), and still check my balance if I want outside the sandbox. As far as running the javascript applications outside the VM, it would depend on the level of trust. Part of the problem is using code for things that could be done using a document format. My paranoia is justified I think. And its not that I have anything I'm worried about losing, I just hate the thought of becoming the cause of another annoyance in a few thousand people's day as they click delete on the spam my machine sent them.

Re:snapshot

[SanityInAnarchy]

who to allow? Even fortune 500 are getting compromised left and right.

I think you're being a bit overly-dramatic, but to answer your question, allow the ones you want to. You still get the added benefit that not every Slashdotted article or Google search is a potential vulnerability.

My paranoia is justified I think.

I really don't agree. If you run a decent browser, and keep it patched, it just doesn't seem likely to me. Besides, all you're doing is adding another layer -- if you can't keep your browser patched/secured, what makes you think you can do the same to a VM? They're both just sandboxes.

Besides, if you're willing to go to those extremes, might I suggest a sandboxing browser? On Linux, Chrome seems to be chrooting parts of itself, thus a Javascript vulnerability would only affect one or two tabs, and would need to exploit an additional Linux vulnerability to reach outside of that.

I just hate the thought of becoming the cause of another annoyance in a few thousand people's day as they click delete on the spam my machine sent them.

Good for you! That is admirable.

I'm just questioning whether your approach is warranted. As an example, wouldn't it make more sense to install a firewall -- best way would be as a separate machine, maybe configure your router, etc -- to both block outbound SMTP, and notify you if anything tries?

In other words, be scientific about it. Instead of getting paranoid by reading a lot of security research, actually find out whether either your VM or your host has become a "pox riddencompromised bit bucket", or how often that happens.

Re:Why bother?

[SanityInAnarchy]

Oh, I like xml...

I don't. Think about it -- every opening tag must have a corresponding closing tag, which is at least as long as the opening tag name. I mean, I could pretty easily rant about stuff like that -- you could pretty easily make a much more readable markup language, and people have.

But really, just look at JSON or YAML sometime -- they are much better at representing structured data -- they're smaller, lighter, and easier for humans to edit and understand. XML is good for markup, but even here, tools like markdown tend to be better, at least at being human-editable.

"checked" could still have been 0/1 even as a string, having a whole word seems longwinded, it isn't like web designers don't know what boolean is.

Actually, yes, it would've been annoying as hell to have to look that up every time. I know I'd be wondering if that is in fact a boolean, or if it's a count of some kind -- what would it mean to set checked=2?

Never mind that not all programming languages use 0 and 1 as boolean values. The better ones have a separate concept of true and false.

Now, maybe checked='checked' is a bad idea, and it should've been checked='true', but wasting an extra few characters in something that's going to be gzipped anyway, where you're already automatically wasting a ton of characters on every document just by using closing tags?

Go try Haml. Actually learn it and use it for a few pages. See if you don't like working with it a lot better than raw HTML -- or XML, even.

ID could have been reused for names automatically with no issues. IDs have no real requirement to be unique, could have had them replace classes as well with no issues.

document.getElementById is a lot nicer when you have a unique ID.

Yes, IDs do have a requirement to be unique. Try running your document without unique IDs through the W3C Validator, see what you get.

And no, you can't re-use IDs as names, as then you can't have multiple forms on the page with duplicate names. That is, right now, I can have two separate forms which submit to the same place, with mostly different options but some overlap -- say, "search" and "advanced search". Or I could have forms that submit to completely different servers, and there happens to be some overlap of field names.

So the only thing you're left with is re-using classes as names. That doesn't work either, because you can have multiple classes per form element (what would that mean?), and it also means that the behavior of the form is now tightly coupled to its visual representation.

That is, say you had a bright read style called "urgent". And say you had a form with a checkbox called "urgent". Can you see why it might be confusing if you had some other form element you wanted to style as urgent?

Now, you could make a valid case that if you're using a nice library like jQuery, there isn't really an advantage to IDs -- you could just use classes for everything, with a convention that certain classes be unique. I'd disagree -- the fact that IDs are unique, and that you're applying them to things which actually are guaranteed to be unique on a page, gives you a very simple tool (any HTML validator will do) to ensure that you don't have any duplicate IDs.

the way css styles are applied is strange though that may be css' fault.

Citation needed.

It seems to me that the biggest issue with CSS is browser implementation. Easily 90% of that goes away if you stop supporting IE. The rest of it is useful if you

And people use it. Unless webpages are all div/span tags with a link to the css then people are using html for formatting. (yes, even header tags count since they change font sizes)

*facepalm*

If you use header tags just to change the font size, then sure. Maybe.

But that's not the point, and it's also not necessarily what happens. Just

Re:Why bother?

[SanityInAnarchy]

When I talk about an object oriented programming language I'm referring to a language that allows you to use the concepts of OOP in a *natural* and *homogeneous* way.

Please provide an example of how Javascript doesn't do this.

I'm aware that it isn't completely homogeneous in the same way that, say, Ruby is. I challenge you to show me an example of this that actually matters.

I don't want to write a library and helper methods to write an OO program, I want to use the language.

So when you write C++, do you never use the std namespace? When you write Perl, do you completely ignore the existence of CPAN?

People have already written libraries that implement many of the ideas of "traditional" OOP, though if you talk to the person who actually coined the term, most of those "traditional" ideas really aren't.

I think it speaks to the power of a language when whole paradigms like that can be written as libraries. It means that the language is multiparadigm without even trying. And it's always nice to see something you'd think of as a core language feature, even a keyword, but it's possible to express it naturally as library code.

It's OK if it doesn't has classes, and therefore inheritance does not have a place in Javascript,

This is a non-sequitur. Javascript is built on prototypical inheritance, which does not rely on classes.

I'm guessing you found that "private" page -- and enforced-private stuff is not a requirement of OOP, by the way -- but you probably found it here, right? Shortly after that link is another -- this explanation of inheritance in Javascript.

just stop trying to force it to be something that it was not meant to be (that is a general purpose language to write medium to large scale applications).

The fact that it wasn't "meant" to be isn't entirely relevant. It does explain some of the problems we see with it -- I certainly won't claim it's perfect -- but can you explain why Javascript isn't suitable for medium to large scale applications?

Re:Why bother?

[Nitage]

Exactly true. All the crap that gets blamed on javascript is only down to its position as the scripting language of the web. People would hate Lisp, Python or C just as much if one of those languages was used to power every epilepsy inducing geocites page.

Re:Why bother?

[Idiomatick]

Pretty sure you could make the paragraph a link to nothing then have the clicked style be hidden. Never tried though. I mean use the right tool for the job. I was being difficult when I said you CAN do it with css.

Javascript as a scripting language

[Anonymous Coward]

Javascript was designed to be a scripting language, using it as a host language is quite possible.
I am using Google V8 implementation as a scripting language for C++ application. It's like using SQLite, it's VM read SQL language and run it while the database engine is C. There are many things you can do with it:

1. You can easily expose C++ functions to Javascript, since the host C++ application already build and compiled, using Javascript can customize the app behavior, such as combining several functions into one batch.

2. You can save app settings and options directly to Javascript and just run it, you don't even need a parser to read config file this way. I have not found a way to let Javascript do heavy lifting, for example here is a CRC function expose to Javascript, the file reading and calculation threads are C++, Javascript just feed in the filenames and wait for the result. The only namespace concerns me is C++ namespace. I am not side-stepping the performance issue, scripting is just the way it is.

3. If you expose variables, you can access them inside Javascript space as well. With it's simple, no non-sense and concise syntax, you can write an entire test suite for your application in Javascript with ease.

4. You can modify the language: say I have a tokens() function in C++ which can be called in C++ and Javascript with tokens( "a string", delimiter ). Now I can modify the Javascript language like the following:

String.prototype.tokens = function( delimiter )
{
        if ( typeof( delimiter ) == "string" )
                return tokens( this, delimiter );
        else return tokens( this, " .,;:-_/\\|\n\r" );
}

Running this from RC file, I can now do something like "hello how are you?".tokens() in Javascript. I am no Javascript expert, but this is quite flexible.

5. There is NO DOM.
You app is the DOM, or whatever you design it to be.

6. There is no access to the outside world. You cannot even read/write a file, I have to provide my own library for it, but then I am in total control. While in C++, you use fopen, iostream or even boost::filesystem access anyway. You can just bind a fopen()/fread()/fclose() or iostreams to a Javascript function and then you have all the access you need. You have access to anthing the host language or external libraries provides, with a simple binding you can access them inside Javascript as well.

The combination of Javascript and C++ is very light weight and very fast ( at least with V8 ). I imagine doing the save with pure Java would cost 3 times more memory and no scripting capability, but of course I have no proof. But if you Java GUI it will certainly consume much much more memory.

Either you add features to your application, or using Javascript as a job-control language, sometimes scripts are one-time throwaway. Sure you can do most of the above mentioned with some other language, but Javascript syntax is clear, concise, no "let's just do something different" syntax like using "\" in path kind of thing. For newbie, a clearly structured language is MUCH easier to learn. For C/C++ or Java programmer, Javascript is dead easy to lean. Big companies like Adobe are using it on all their apps, or some variations of Javascript. Why shouldn't you?

Sure, there are no "standard" libraries in 2D/3D, OpenGL, GUI or what's not, but if you can connect them to C/C++, you can expose them to Javascript. But you should think about if using Javascript as a host-language is really what you want in the first place. I have no prior programming experience in Javascript, just looking for a concise, simple language for scripting applications, preferably C-like. All the duct-tape shell scripting languages are less flexible, there are a few C-like scripting languages but too slow and development are slow. Newer languages suffer from weird syntax and structureand pure bad tastes. I choose Javascript for what it provides, not because it is being used in browsers.

Re:Getting JS out of the browser is a *great* idea

[dkf]

Scripts are fine for small mundane tasks, they're NOT good for building applications.

A lot of the very largest applications are scripted (in various languages). If you've got a choice between writing a million lines of script or a hundred million lines of C, it's a real no-brainer.

Well, in fact the massive apps use a mix of different languages, typically crafting components in a low-level language that the high-level scripting language composes to create the overall application. That tends to be the most productive approach; the alternative "One True Language" method is silly.

Please dont

[jdc18]

Javascript is much fun to debug. Even with firebug it is so hard to find errors sometimes.

On static analysis of dynamic languages

[jonaskoelker]

Javascript is too dynamically typed. In my experience, testers constantly find bugs caused by [...], misspelled variable names, or other basic things that a compiler could have detected.

It's not impossible to do static analysis of code written in interpreted, dynamically typed languages. (There's such a thing for python.)

Or rather, it's not more impossible---see Rice's theorem---than it is for compiled, statically typed languages.

It's just that (apparently) nobody knows or uses a good static javascript analysis tool. Maybe because it doesn't exist; I don't know.

The real problem

[jonaskoelker]

Use the right tool for the right job.

Okay. Let's see. I want to deliver rich applications over the web (with all the good properties of universal accessibility and no user administration) that do heavy client-side processing. I have to write in a programming language that virtually all browsers will run.

For that, javascript is the right tool because it's the only tool. It doesn't matter how ill-suited it is for the task at hand, it's all I got.

When you have to get that nail punched in, every tool looks like a hammer.

Re:Why bother?

[Transfinite]

I'm betting we'll see browsers at some point not being able disable javascript entirely. I dare you to dissable JS for a day, see how you actually get on. here's an example: "There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead." Pfff! Javascrip tis such a hassle eh?

Re:Why bother?

[ShieldW0lf]

I think you would need to use the visited property together with some random salt in the link that prevents the visited pseudo-class from being true the next time they load the page. JS would definitely be easier...

Re:c++ is good

[jhantin]

When you are given a screw driver to drive a nail, blaming the tool makes sense!

If I was given a screwdriver to drive a nail, I'd be more apt to blame the tool that handed me the screwdriver, or perhaps the one that neglected to ensure a hammer was available for the task.

Mod parent up

[davegaramond]

I too hate variable scoping in Javascript, even PHP is slightly better in that variables are local inside functions. There are other small annoyances too. But the biggest is: Javascript has been given monopoly on the client side for too long. I wonder how much better can the Web be if there were more competition on the client-side browser language.

Re:Getting JS out of the browser is a *great* idea

[kaffiene]

JS does not have 'a couple of warts', it's mostly warts with a few nice ideas buried under them.

Re:Why bother?

[kaffiene]

I use JS every damn day - it's my bread and butter. The language is awful. Plenty of people have offered detailed arguments here as to the language's deficiencies (including me. look through the comments to see them, I won't repeat them here)

How the fuck did you get modded 5 insightful for casting all JS's detractors as bad programmers? An ad-hominem attack is +5 insightful?

For fuck's sake, what a fucking popularity contest!

Re:c++ is good

[kaffiene]

It clashes with "the right tool for the job". A professional would use the right tools, but if you have the wrong tools you can't point out their inappropriateness?

Some of your points will be address in ECMAScript5

[Sits]

Brendan Eich's notes about an early draft and "Programming in the large" and a blog post about ECMAScript 5's strict mode (which does far more checking) talk of features that will hopefully give people a better change at dealing with the issues you raised.

OK not so useful to you now but hey...

Why not 2D/3D in the browser?

[tepples]

The speed issue is largely due to the crappy implementations of Javascript

A language is only as fast as its implementations unless you lead a company that is willing to spend millions on a new implementation.

What you probably can't do is compile it to native code and expect it to have the speed of C/C++.

In ECMAScript, as in Lua, the only numeric type is a double-precision floating point number, and the only data structure is an associative array. An associative array from doubles to doubles takes 16 times as much space in the data cache, in RAM, and in the swap file compared to a linear array of tiny integers ("bytes"). At some point, switching from ECMAScript to Java, which provides a richer selection of efficient types, becomes a good idea.

2D/3D libraries - C doesn't have one in its standard, C++ doesn't have one

ECMAScript alone doesn't have the HTML and CSS DOM; that's the job of the web browser that adds libraries to ECMAScript to make JavaScript. Likewise, all three major PC operating systems add OpenGL and GLUT libraries to C++ to make C++-With-OpenGL-Support.

It just doesn't make too much sense having a full fledged 2D/3D library in the browser

Why does it just not make too much sense? What is the appropriate way to provide client-side visualization of information retrieved from a web service without requiring each user to seek administrative approval to install a native app?

And you use a "mission-critical application" written in Javascript running inside a web browser?

Our mission is to make money by providing a desirable product to customers. The step of deploying our application to our consumers is critical to our mission, and this step needs an appropriate platform.

Because haXe and swfmill aren't complete

[tepples]

Is it the proprietary plug-in nature of Flash that you don't like?

That and the fact that you still need to spend three figures to use SWF for animations (as seen on Newgrounds) as opposed to applets. Free tools such as swfmill can copy clips from an SWF library into your SWF project, but none of the guides I could find with Google describe a way to create vector-based clips to put into a library in the first place. The authoring tools aren't even up to the level of Flash 3, let alone CS3.

Can't complain about IE incompatibility anymore

[tepples]

It's the inconsistent implementation of the DOM by Microsoft that's the problem.

You mean was the problem, at least until Google released Chrome Frame. Yes, Google knows you like to develop, so they put a browser in your browser so you can surf while you surf.

Re:Can't complain about IE incompatibility anymore

[rayharris]

Until IE without Chrome Frame accounts for less than 10% of the market, you can't ignore IE and all its flaws.

Re:Can't complain about IE incompatibility anymore

[tepples]

Until IE without Chrome Frame accounts for less than 10% of the market, you can't ignore IE and all its flaws.

Then make two views of the web site: a version with little or no JavaScript for people with IE 6 or 7 who decline the automatic prompt to install Chrome Frame, and the full experience for users of any web browser that reports itself as Opera, WebKit, or Gecko.

JavaScript is already installed; others aren't.

[tepples]

Life would be so much easier if browser vendors defined a language-neutral DOM abstraction and allowed scripting languages to be added as plug-ins. Then developers would be free to use <script language="python" src="script.py"... or >script language="java" src="script.jar"...

Web applications would still be coded in ECMAScript to get around blocks on installing third-party scripting language plug-ins imposed by computer administrators and device manufacturers.

null and void

[tepples]

Did that joke just go flying over my head?

The issue is that null and void(0) both exist and aren't the same thing. Which of these more cleanly corresponds to None of Python or null of PHP or null of Java?

if ("invisible pink unicorns exist") alert("hai");

[tepples]

In Python, strings are sequence types. Like all other sequence types, they coerce to boolean the same way their length does: "true" is true because it has length 4, and "false" is true because it has length 5. If coercing "invisible pink unicorns exist" to true isn't considered evil in Python, why should it in JavaScript?

Your customers will blame only you.

[tepples]

If I was given a screwdriver to drive a nail, I'd be more apt to blame the tool that handed me the screwdriver

You can blame the substandard tool who gives you substandard tools, but your customers will blame only you because your competitors excel at making do with substandard tools and the substandard tools who provide them.

There's a map for that, and you're out of range

[tepples]

It's not a 56kb/sec world anymore.

You'd be surprised. There are still parts of Canada and the United States where the phone company won't put a DSLAM within 4 km and the cable company just chooses not to operate. On a mobile phone, "there's a map for that," and if you're not in the 3G zone, expect the Internet connection to become dog-slow as it falls back to EDGE or even GPRS.

More than one language

[paxcoder]

We never had a battle of user-side scripting languages. I think one is in order, don't you think?

Re:Some of your points will be address in ECMAScri

[MobyDisk]

Good to know. Thanks.

Re:WELL

[DocHoncho]

This silly bastard posts this copy-pasta all the time. No one reads it, and those who do go mad. They really just need to ban his ip, cuz it's getting old.

How polite!

[Sits]

You're welcome!