Slashdot Mirror
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?"
will alert 2.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
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.
æeee!
>> 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....
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.
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
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.
Michael J. Ryan - tracker1.info
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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...
Nerd rage is the funniest rage.
"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.
Santiago
so until and unless major browsers start implementing things like JIT compilation
Wish granted (at least for chrome).
This space intentionally left blank.
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++:
Java and C# go one step further, and prohibit shadowing of locals altogether. E.g. C#:
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.
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.
Sure.. but given JS expressive power, I dare you.. Especially compared to LISP.
If you ask for threading though, I yield ;)
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.
Slipping shoelaces ?
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