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

[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

[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

[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

[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

[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

[fulldecent]

so when is dom2 coming out?

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

[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

[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

[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

[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

[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

[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

[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

[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

[yuhong]

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

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

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

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.

Better Idea

[physicsphairy]

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

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

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

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

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!

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

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

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

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

Re:Why bother?

[Anonymous Coward]

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

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

[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:javascript is good

[kbielefe]

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

Wish granted (at least for chrome).

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.

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

[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: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: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: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?

[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?

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

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