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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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.

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

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.

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

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

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?

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

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

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

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