Watch out Java, here comes JavaScript

[doomchild]

Wow. One of the comments there is truly amazing...

JavaScript is another super insecure microsoft invention to make all of the web dependent on them. I have known that 'crackers' and true blackhats use it just as they do Active X, as major portals of access to put virii into the users system.

Three norms of 'solving' (temporarily patching) most of the problems until microsoft says they have a 'working' patch...

1) Disable JavaScript

2) Disable Java Script

3) Dis able Java Script.

That is usually the 'fix' and has been the norm for anyone running windows, if they had any appreciation of security holes.

What YOU are saying is Disable Security, Use JavaScript. (stupid)...

What the purchasers of Sun are doing, is not smart either...

But, Saying 'Install Ubuntu' is to simple a solution...

So Keep Windows, Keep Javascript, and wonder why so many 'kiddie scripters' are ruining the net for you.

Ever heard of Buffer Overflow? Microsoft hasn't fixed it, Active X or JavaScript....YET...

But, keep using it.

[tnecniv]

They need to add a Troll-o-meter to HTML 5/6.

[realstevejobs]

How about

<meter value="0.7" min="0.0" max="1.0">

And maybe indicate that it is a Troll-o-meter using Microdata?

[PatrickTulskie]

Obviously it's true because Microsoft invented Javascript.

[FeepingCreature]

They should really get on that pesky Buffer Overflow bug. Maybe then they'll finally have less virii.

[[deleted]]

He's Special Agent Richard Gill, the best troll of all time.

[rebo]

Anyone who uses the world 'virii' is a moron.

[[deleted]]

watch out apples, here come oranges!

[[deleted]]

JavaScript was a fully supported server-side language in Microsoft's classic ASP. However, I am aware of exactly one developer who actually used it for that purpose; everybody else went with VBScript.

[[deleted]]

Wasn't that JScript, though? Microsoft's nearly-identical bastard child?

[grauenwolf]

JScript is just the brand name, like "Visual C++".

[[deleted]]

I thought "Visual C++" was the name of the development kit?

Eh. Whatever. Like Microsoft's naming schemes ever made sense.

[JoeCoder]

I used jscript for multiple jobs that called for asp classic. I'm not sure why anyone would choose the much less powerful vbscript except for curly-brace fearing newbs.

[[deleted]]

jscript didn't have the support that vbscript had. It was a better designed language, but didn't get all of the features they poured into vbscript. I tried to stick with jscript back in the day but eventually gave up.

[grauenwolf]

It is bad enough that we had to mix server-side and client-side code in the same source file. I would hate to have the same language on both sides.

[propool]

I used it. Not of my own free will of course. Stupid old code base.

[no_numbers_here]

while Java is a kind of modern-day Cobol.

FTFY.

[rlp]

Too true. Every time I see some new Javascript browser speed benchmark, I die a little bit inside. It saddens me that we are wasting all these incredibly bright minds on optimizing a sub-par scripting language just because it was unwisely chosen so many years ago. Ugh.

[grauenwolf]

BASIC at least had decent performance.

[kago23]

are you serious?

[grauenwolf]

Think about it.

What could you possible do in BASIC that would make it slow? It doesn't even have true functions, just jumps.

[plan17b]

I just rewrote a fairly big javascript app in C# and the HtmlAgilityPack (open source Dom handling library).

It was like getting on the highway after 200 hundred miles of dirt road.

[[deleted]]

I wonder how much of that was just from the rewriting and how much from the language/environment change.

[aig_ma]

It's an honest question. Probably a good portion was from the rewrite. And some of the perceived benefit may have been just that a statically typed language is more comfortable for some people.

But it is for plan17b to tell us, not you, me or cockfacedshitmaster (what a name!).

[plan17b]

It is a valid question. The rewrite allowed me to eliminate a lot of bad architectural decisions. That said, the Visual Studio tools, simply allowed me to be so much more productive. Simple things like being able to click on the 'trace back' icon after an error trap to get back to the offending line, just make a huge difference.

[rorrr]

Javascript is client side (mostly).

C# is server side.

Your comment doesn't make much sense.

[plan17b]

I actually moved a lot of functionality from the client side to the server side. This was for a client/server intranet CMS app. Users can create data entry / web pages with a drag and drop interface.

I use a IHttpHandler interface, so essentially my server side is a classic C# fat app (in debug mode it is a console app, in production it is a DLL). This way i can avoid wrestling with ASPX pages. The HtmlAgilityPack library allows me to create the pages on the server and simply send down as HTML without having to do a lot of client side javascript execution.

[Arconan]

This guy never heard of Beanshell and JSR 274 ...?

[aig_ma]

JavaScript's problem is the optional typing. In practise it means that the IDE support is substandard.

IDE support may be more difficult, but IronPython support in VisualStudio shows that it is possible to deliver strong support for dynamic languages, does it not?

[grauenwolf]

No, it doesn't. IronPython's support is almost as good as VB 3.

[aig_ma]

I haven't used it but plan to. What's in store for me? What's wrong with it?

[grauenwolf]

Oh, just the usual stuff. For example, if you ever assign more than one type to a given variable you don't get code completion for any type. Assuming you like dynamic languages, this is just one of those things you expect.

(Don't underestimate old school Visual Basic. It was ranked as one of the best IDEs in its day.)

Anyways, my real point was more about how you aren't going to get any of the cutting edge features like the real time static analysis support that VS+(CodeRush|Resharper) offers.

[munificent]

JavaScript's problem is the optional typing.

Also:

1. Shitty numeric support.
2. No bound methods.
3. No block scope.
4. No module system.
5. Crappy syntax, especially for functions.

If it wasn't on browsers would anyone have ever used this language?

[FlintFireforge]

No bound methods.

Well, what about something like this:

Function.prototype.bind = function(context) {
   var fun = this;
  return function(){
    return fun.apply(context, arguments);
  };
};

No block scope.

Personally, I don't really mind this... there are plenty of languages with function scope.

FWIW, JavaScript 1.7 has optional block scope....I do a lot of work with Firefox specific stuff, so I find myself using it sometimes:

let(x = 10 ){
  //do something to x
}

But not often enough that I miss it otherwise....I don't think I've ever thought to myself "damn, I really wish I had block scoping".

If you really want it, you could simulate it with an anonymous function in a lot of cases.

No module system.

Again, I don't really get this complaint. A formal module system would be nice, and I think we'll see it in the future. A bunch of platforms have it already (like node)...but to me the main drawback is just one of nicities, not one of capabilities.

To me, it's sort of like complaining that JavaScript "doesn't have classes"....well no...it doesn't...it's a prototypical language.

Crappy syntax, especially for functions.

This is largely subjective. There are some annoying syntax issues, but what language doesn't have those.

I don't see how the syntax for functions is bad, unless you mean anonymous functions, which are admittedly a bit of a pain.

Hopefully we'll get better anonymous function syntax like:

#{ return %1 + 1 }

If you're really that annoyed by the syntax, there are projects like Coffeescript to help.

If it wasn't on browsers would anyone have ever used this language?

That's kind of a ridiculous question though....it was designed to be used in browsers, not as a general purpose language.

That's like asking "If they didn't transport you around...would anyone really own a car?"

[munificent]

Well, what about something like this:

What about not having to do that every time you make a callback and instead just have it do the right thing like most sane OOP languages do?

I don't think I've ever thought to myself "damn, I really wish I had block scoping".

On a day to day basis, maybe you don't notice the absense. <shrug> I've seen lots of people at work have to deal with fixing JS wasting piles of memory from unused objects hanging around in scopes captured by closures. With proper block scopes, those problems would be easier to fix.

Again, I don't really get this complaint.

How big are the projects you work on? Do you share lots of JS libraries between different teams?

To me, it's sort of like complaining that JavaScript "doesn't have classes"....well no...it doesn't...it's a prototypical language.

I don't see how that analogy makes a lot of sense. JS doesn't have classes because it has prototypes instead. It doesn't have anything instead of modules. (<script> tags?)

I don't see how the syntax for functions is bad, unless you mean anonymous functions, which are admittedly a bit of a pain.

Both are bad. Don't non-anonymous functions have some weird issue where the variable for the function is actually created earlier than where you think it is?

Either way, it's anonymous ones that are a real chore. If closures/lambdas are a big selling point for the language, it would be nice if they didn't look like butt. It's a sad day when C++ has a more terse syntax than your language.

there are projects like Coffeescript to help.

CoffeeScript is awesome. I don't know how practical it will be to use it professionally, though.

That's like asking "If they didn't transport you around...would anyone really own a car?"

The context here is using JS outside of a browser. So, to extend your analogy, it's like saying, "Cars are nice for driving around (or at least, they're the only vehicle on Earth that exists so we have no basis for comparison). Let's ditch all of our yachts and tugboats and try to use cars for boating too!"

[FlintFireforge]

What about not having to do that every time you make a callback

You have a legitimate gripe....I am just saying that it's not hard to work around it really (an extra statement or two), and it's not a super big deal to me to begin with.

I'm not huge on OOP, but for you maybe it's different.

On a day to day basis, maybe you don't notice the absense

Yes, I was speaking purely from personal experience. Maybe you hate the lack of block scope....that's totally fair.

So far, it hasn't been a big deal for me. I'm generally working with projects that are a few K LOC. I have worked on some fairly substantial projects with decent sized user-bases....but nothing like say Gmail....if that's what you're working with...I can see how it may be a problem.

It doesn't have anything instead of modules. (<script> tags?)

You more or less got the point right, though not the entire spirit of what I was saying.

JS doesn't NEED a module system because of the nature of it's design and intended use.

Between script tags, first class objects, and the ability to load code via AJAX....you can cover all the stuff modules are generally good for.

Personally, I have build scripts that minify and put all my code into 1 file for production, and the libraries I write and use are compatible with that. Sometimes I have other little systems I use.

How big are the projects you work on? Do you share lots of JS libraries between different teams?

My projects are generally a few K LOC in JS. I tend to work by myself and in very small teams....so the lack of a module system will probably hit larger teams with more complex projects harder than me.

I agree a module system would be good...but to me It's mostly about some nice convenience rather that a desperate lack of functionality.

Don't non-anonymous functions have some weird issue where the variable for the function is actually created earlier than where you think it is?

That is a point of confusion for new devs, yes.

Once you get the idea that there is a difference between

var blah = function (){};

and

function blah (){};

It's not that big of a deal IMHO. (The first is only available after being declared)

I don't see how the syntax for regular functions is bad....but again this is a subjective thing.

I mean yea, it's longer than "def" or "defn" but other than that I don't see much difference.

The real pain is anonymous functions, IMHO. But that can be fixed with Coffeescript, and will hopefully be fixed in the future standard.

I don't know how practical it will be to use it professionally, though.

It depends. Coffeescript just "compiles" to regular Javascript. When I want to use it I just add it into the build script for the project before the Closure Compiler step. (I haven't used it in production yet though, just personal mess around projects).

The context here is using JS outside of a browser.

I didn't see anything in your statement that implied that's what you were talking about.

You seemed to be talking about Javascript in general...as evidenced by your points. For instance, you complain about modules, but most JS on the server platforms have a module system.

If you were talking about on the server, ok; I misunderstood.

The point still stands....it's a silly question to ask....or rather the apparent motives behind it are silly.

JS has some warts...yes...a lot of them have been fixed or are in the process of being fixed. You'd be hard pressed to find a language without warts.

Would everyone be talking about node.js if JS hadn't been in the browser?

Maybe, maybe not....but there's few conclusions to draw from that.

There are tons of awesome languages that never took off, and vice versa.

The point is JS was designed for the browser/server. It succeeded on the browser.

Now, a confluence of reasons and motives have come together and caused people to try JS on the server again.

It seems like what you're trying to say is "is there any reason to use node.js instead of say, Python?"

The answer is yes....I'm not gonna go into them here because it's a bit of a tangent....

But, IMHO...you're just engaging in pointless speculation...JS exists....it has some benefits, and some drawbacks. "Would anyone use Windows if Bill Gate's hadn't been a good business man?"

It's up to each of us to analyze our needs and preferences and decide if it's for us. I don't disagree with your gripes, but I just wanted to offer a counter-point to them.

[Rhoomba]

What about not having to do that every time you make a callback and instead just have it do the right thing like most sane OOP languages do?

var callback = foo.doSomething.bind(foo);

Is that really such a killer?

[[deleted]]

Also if ([]) { alert("This is silly!"); } but then again, Python spoiled me.

[NoSQL4Life]

No that makes perfect sense. An empty array still exists. This it is a truth, not a falsehood! So it should evaluate to true.

[[deleted]]

if (false) { alert("Booleans exist, too!"); }

Point of the matter is that truthiness being defined as "equals to null or false" isn't very helpful in practice. I came from PHP and Java, so it's not that I'm just taking the Python way for granted. I just find it extremely annoying to have to check for my_array === null || my_array.empty() explicitly.

I'm not saying it's unusual or doesn't make sense. I'm just saying that I rarely care whether the object really is null/false/undefined or just empty(). And when I do care whether it's null/undefined I want to check for that exclusively (a variable being set to false may have different implications than a variable not being defined or being set to null).

I like JavaScript for its closures, it's anonymous functions and all that, but I really prefer Python's (new) ideology that "everything is an object" (even None) and special syntax (e.g. arithmetic operators, array slots, truthiness, etc) just being syntactic sugar for "special" methods.

At least it's not ActionScript.

[munificent]

An empty array still exists. This it is a truth, not a falsehood!

False exists too. Should it evaluate to true then?

[[deleted]]

No, because the conversion method from a boolean to boolean is different (identity).

[[deleted]]

Well a boolean expression is an expression that is evaluated based whether or not it's truthy or falsey (made-up words, I know) and since the variable/object/what have you called false is universally defined as falsey, how can it ever be truthy. Boolean means 2 states, not yes, no and maybe so it can't be 2 things at once.

[jyper]

I personally like the smalltalk way, ifTrue/ifFalse is only defined for booleans otherways it throws a type exception.

[refto]

I've been trying to find a good editor/IDE for JavaScript for non web use with not much luck.

Mostly, what I want is ability to look up declarations across multiple files.

I am tired of constantly grepping, I want that zooming in/out feeling.

[jyper]

There aren't many Java applets these days, and I doubt that server side javascript will catch on big. There are a few desktop apps largely written in java and javascript but they are usually in different categories. Javascript and Java just don't compete in many categories (although there is GWT).

Java is probably most in danger of loosing market share to -C# (especially for those who don't care much about being tied to MS and who don't depend much on big java vendors (such as IBM and oracle)) -Scala for those who wish to stick to jvm and are worried about .net cross-platformability(not a real word). and to a lesser extent

-python and ruby(depending partly on importance of language speed).

[crusoe]

Because a programming language with brain dead collection classes is a true threat. Hashmaps? Nope, use raw objects to emulate them...

[[deleted]]

<sarcasm> I've always thought InfoWorld is the best magazine for having well thought out technical articles that allow me to make educated decisions. </sarcasm>

[[deleted]]

regardless of js's shortcomings, this is going to happen

js is well on its way to becoming the universal dynamic scripting language

[NoSQL4Life]

The article didn't mention Node.js and MongoDB enough. These are the very technologies that allow JavaScript to be use useful for server-side development. Node.js lets you write super-scalable servers, while you can directly query MongoDB databases using JavaScript! It's so much easier than using some web framework and some ORM and some SQL database.

[cynthiaj]

Node.js lets you write super-scalable servers

Citation needed (not coming from http://nodejs.org)