My gripes with JavaScript
Note: This post doesn’t mean I’ll stop working on IronJS, I love working on IronJS and will continue to do so to make it as fast and awesome as possible.
Apparently my recent appearance on hanselminutes caused some stir on twitter. People think I was laying to heavily into JavaScript as a feasible platform for server side development (node.js, etc.).
This might sound odd coming from someone that has built a JavaScript runtime, but my point of view after having developed IronJS is that there are a couple of critical problems with JavaScript that prevents it from ever being a viable alternative as development platform for server application development.
Lack of language defined modules and namespaces
The language doesn’t define the concept of a module or namespaces, several work-arounds exist like require in node.js but there are several problems with using something with require.
- It’s implementation dependent, which means it’s not standardized and you can’t count on it existing in every javascript implementation.
- You can re-write anything in any namespace at will, some people like this since it allows for something called monkey-patching. However this just leads to a whole new can of problems.
- You can replace the require function, or any other function for that matter, at a whim or by mistake leading to very hard to track bugs.
ECMA specification doesn’t define how to organize code over several files
This ties into the previous modules and namespaces, but it’s such a major thing thing it has to be mentioned separately. The specification does not define how to load code from a file, this might seem like a minor issue as node “solved” it with require. But in reality the possible issues that can arise here are many.
For example, as already mentioned, require is specific to node.js and doesn’t exist on any other major platforms. There are major problems with having non-standardized and implementation specific behavior that effect such crucial parts of a language as loading code.
The most obvious one is how the code actually is loaded, for example:
require("foo");
require("foo");
Is the “foo” module/file loaded/executed once or twice?
There’s also more subtle problems, such as: When you use require to load a piece of code, is the code executed in the global environment or the loading context?
(function foo(bar) {
require("foo");
}({x: 1}));
Is the code inside the “foo” module/file executed in the global scope or in the context of the foo function with “foo” and “bar” already bound? Most people will probably say “in the global scope”, but the designers of the PHP include probably won’t agree.
And before you mention CommonJS: It is what some people think is correct and does in no way represent some type of standard
Very small standard library
The standard library, as defined by the specification is incredibly small (compared to the Python standard library, or the .NET BCL, etc.) and only gives you access to the most basic operations, not even I/O is included. Sure you can build your own library for a specific implementation, but it’s not going to be universal and it will tie the code that relies on it to that specific implementation.
Language problems
If you’ve ever written any moderate amount of JavaScript code you’ll know that there are several problems with the language itself, things like with, eval or the inner quirks of how JavaScript applies the concept of equality. The http://wtfjs.com/ is a good read for some more WTF? moments.
Null vs. undefined
JavaScript has two “this is not here/doesn’t exist” values, they’re subtly different and undefined is the one that is most common. But why would you even have two different types of ‘nil’ to begin with? I know of no other language in existence that does this (I’m sure someone reading this is going to dig up another language that has this).
Context sensitive function keyword
In case you didn’t know, these two functions are not identical:
(function bar() { })
function foo() { }
Finding out the difference I’ll leave as an exercise to the reader.
Limited set of data types
- Only 8 byte float numbers, how would you even interface to a database schema that has a 64bit integer column?
- No fast (as in native) arrays
- No int, byte, etc. number types
Fragmented runtimes
While pretty much every single one of these problems could be fixed by either extending the specific runtime you’re using or by ECMA releasing a new standard, it’s just not that simple. Assuming you extend the runtime you’re using to allow for things like native/fast arrays and you define a module/namespace solution like node.js has done, now any code you write will only run on that specific runtime with your extensions which punches a big hole in the “same language everywhere”-argument that you hear every day on twitter (and it really is server-side JavaScript’s only claim to fame).
So what if ECMA releases a new standard that fixes every single problem I’ve listed above (this is no way an exhaustive list)? I can currently count to about six different runtimes in use today (JScript, JeagerMonkey, TraceMonkey, V8, Chakra, Carakan, Rhino). And that’s not even counting the small emerging ones like IronJS, Jurassic, Jint, etc. that are platform specific implementations for embedding. A lot of these runtimes are available in different versions in different browsers and will never be upgraded, so you’ll have to exclude all those new features in our new utopia-style ECMA specification if you wan’t to be “cross-runtime” compatible (which you need for web development at least).
But what about node.js?
First I want to make clear that IronJS is in no way a competitor to node.js, IronJS is a runtime – node.js is an application server that uses another runtime (V8).
Node is decently fast, sure. But it’s nowhere near as breathtakingly fast as it’s zealots want you to believe. Nor are any of the ideas it employs new or groundbreaking. It also comes with several warts that have been inherited from JavaScript which forces you to do manual continuation-passing style. I just can’t see the reasoning behind using a language that wasn’t designed to be used in this context, it just feels like one big hack (albeit a pretty well preforming hack).
Assuming you want to run an asynchronous SQL query in node, it’d go something like this:
db.query("select * from person", function(result) {
print(result);
});
Now compare this to a language that actually was designed (F#):
async {
let! result = db.query "select * from person"
print result
}
Conclusion
The way I see it is that JavaScript has dug itself into a hole that is impossible to get out of, at least if you wan’t to keep “same language/code everywhere” idea alive. And if you’re not, then why would you use JavaScript when so many better (and faster) alternatives exist? There are so many problems with the language, I’ll list a couple more that I haven’t touched on but I think this image illustrates my point of view better then any words could:
- The scoping of the this keyword
- Switch case fall through
- Automatic semicolon insertion
- Bitwise operators that work on doubles
- Type wrappers and type conversions, new String(“foo”) vs. “foo”
- The new keyword makes function behavior dependent on the context they’re called from
- with and eval (it doesn’t hurt to mention these again)
- The arguments object which is an array, almost. Except it’s not. And it’s also magically bound to the parameter variables
- The typeof operator
- The global object
IronJS Blog 
If F# is not from M$, I would give it a try. But sorry..
Jack
June 22, 2011 at 3:15 pm
F# is fully open source on github ( https://github.com/fsharp ) and runs great on Linux in Mono.
Nate
June 22, 2011 at 4:18 pm
Really? M$? 1999 called, they’d like their reality back.
B.R.
June 22, 2011 at 6:00 pm
You do realize that when that joke was still funny, that date would be talking about the future, right?
John Haugeland
June 22, 2011 at 11:31 pm
F# is run by the Mono team now, so you are free to use it without whatever silly existential angst something from Microsoft gives you
almostEric
June 22, 2011 at 7:13 pm
Not true; the core F# team (Don Syme et al.) still works at Microsoft.
jdhardy
June 22, 2011 at 7:31 pm
(to jd hardy, stupid blog theme restricting reply depth)
So basically, as long as someone works at a company you don’t like, they can’t write open source? The license and the gift don’t matter to you?
Please take off the priest hat.
John Haugeland
June 22, 2011 at 11:32 pm
The problem with Microsoft is that, they have got a lot of haters. Who are going to dislike their products, no matter how good they are…
Hemant Pawar
June 23, 2011 at 5:47 am
TL;DR: I’m used to other languages and I think they should all behave the way that I’m used to!
nothanks123
June 22, 2011 at 4:17 pm
Serious – JavaScript is beyond amazing once you understand how to ACTUALLY USE IT.
Norm
June 23, 2011 at 1:27 am
Well, I’m used to `mk_website();` but sadly, it doesn’t work.
Christian Sciberras
June 23, 2011 at 10:30 pm
I’ll dig up that other language for you: VBScript has no less than 3 variants of null: Empty, Null, and Nothing (http://msdn.microsoft.com/en-us/library/f8tbc79x%28v=VS.85%29.aspx).
jdhardy
June 22, 2011 at 4:46 pm
Haha, “Better than VBScript”. Thank you for the chuckle.
Pavel Panchekha
June 26, 2011 at 7:41 am
> But why would you even have two different types of ‘nil’ to begin with? I know of no other language in existence that does this (I’m sure someone reading this is going to dig up another language that has this).
Ask and you shall receive! Visual Basic and VBScript both have this (Null and Empty) and it’s part of COM.
Wayne
June 22, 2011 at 5:41 pm
That picture cracks me up. Thanks for the article, and I agree, the global object is really messed up.
Eli Gundry
June 22, 2011 at 5:54 pm
i agree, it’s even funnier now that the photo’s owner pwned the author for hotlinking to it and for using it without permission :P
overall, some valid points but nothing you can’t learn to deal with, especially if you read either/both of the book that used to be in that image.
keeganwatkins
June 22, 2011 at 9:16 pm
i just realized that i probably ruined the joke by posting the comment above, hopefully the author contacted the photo’s owner before creating a local copy on the ironjs server :/
keeganwatkins
June 22, 2011 at 9:34 pm
See NodeJS Async module
John McLear
June 22, 2011 at 6:22 pm
Great writeup.
Undefined and null (falsey) is something that bites me in the ass sometimes. The reason being is that you could write:
if (someObject) { doSomething(); } taking advantage of the falsey nature of objects.
The issue I find is that this works great for function parameters but not vars scoped outside the function definition (sometimes I drop server side vars on the client for consumption by client side code). I’m tired of writing:
if (typeof someObject !== ‘undefined’) all the time.
You also mention the lack of multiple module support and this has always been somewhat of walking on glass. In the web world the includes are in the webpage, but you have no way other than throwing exceptions in each file if a previously required module/file wasn’t loaded of doing this in a clean way. I wish there was a way to do includes better.
However, JavaScript is still my favorite language. Nothing beats closures and handlers. It matches the way I think.
Lance
June 22, 2011 at 6:53 pm
That’s a terrible terrible reason. Say what you will about Microsoft as a brand, but it has a great job with the CLR, especially when compared to the JVM.
xavi
June 22, 2011 at 7:04 pm
Thanks for venting my frustrations over the past 11 years!
David Glass
June 22, 2011 at 8:22 pm
luajit and js implementations are not comparable.. What were you thinking when you wrote that? The decision to provide that as some kind of fallback or alternative to JS definitely needs some clarification.
Tim Branyen
June 22, 2011 at 8:26 pm
I think you miss-understood, I’m talking about server side javascript like node. Not client side.
Fredrik Holmström
June 22, 2011 at 8:33 pm
Javascript is awesome, i guess i should get more familiarized with other programming languages to get bother by this issues.
Ivan
June 22, 2011 at 8:38 pm
I have to say, as a major nodejs proponent, that I largely agree with your arguments. JavaScript is just too damn flexible, and the learning curve too great to become proficient. I do think that the ECMAscript spec is really starting to address some of these issues, though. The glacial pace of adoption of new browsers doesn’t help matters though. Many of the issues you raise with the language itself though can be mitigated with CoffeeScript. I know its not the same language, but it removes the burden of learning quite so many of the pitfalls of JavaScript’s flexibility. I’m delighted you’re writing the IronJS runtime though, keep up the good work.
Raoul Millais
June 22, 2011 at 9:59 pm
This post reads like a post from the perspective of a web developer, not someone who controls a JavaScript implementation.
The ECMAScript group has solutions to a great many of your gripes:
http://wiki.ecmascript.org/doku.php?id=harmony:proposals
Those are the proposals that have been agreed upon (though there is still time before the spec is finalized to change the details). As an implementer of the language, you could start trying them out now.
Yes, you can’t share that code client and server side right now (unless you use a transpiler, and I’m sure we will see more than one of those). But, the clients are evolving faster than ever and the server evolves at whatever pace the administrators are comfortable with.
So, even the ECMAScript committee members agree with most of your gripes and solutions are already being worked on. Seems reasonable enough to me.
Kevin Dangoor
June 22, 2011 at 10:25 pm
The name of the language should be enough to tell you that it is not intended to be a full blown language. It’s a scripting language and out does that job well. Why try to make it something it’s not when there are plenty of alternatives?
Adam
June 22, 2011 at 10:42 pm
I consider javascript an assembler I compile to. Since this is an ms oriented blog, then e.g. websharper, but personally I use the haXe programming language with Node.js typedefs on the server, and a full html5 typedefs on the client. Super fast compilation and shared libs on client/server it doesn’t get much better.
blackdog
June 22, 2011 at 11:12 pm
JavaScript is nice to do quick hacks and breakable toys with, but THAT’S ALL. As a javascript code base grows it becomes a maintenance hell due to it’s over-dynamic nature. Refactoring anyone? (ha-ha).. And yes there are things like JSLint and JSDoc, but really why oh why.
BTW you are not entirely correct for the non-standartized modules (require(…) stuff) – the modules format is kindof standartized by CommonJS here – http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition I know Dojo recently switched to that.
Ivan Zlatev
June 22, 2011 at 11:19 pm
This article gets better as it goes on. Criticizing monkey patching and modifications of require, etc., are criticisms of users of the language: I’d prefer for things to be permissive and pure, like the ability to modify objects and override non-keywords. And the criticism of the small ‘standard library’ strikes me as odd: where would this live? In the browser-focused runtimes? I/O? And how is this a real drawback?
The wftjs-referenced examples are spot on, I believe, and bigints are a big deal that make Brendan Eich cringe.
If I had to name some flaws:
– Ambiguity between object members and labels combined with ambiguity of blocks and objects
– Automatic semicolon insertion: it should either be standard or not there.
– Base-16 numbers as having a leading zero rather than 0x, and the ensuing requirement to call parseInt with a radix.
Tom MacWright
June 23, 2011 at 5:44 am
Automatic Semicolon Insertion **IS** standard. It’s defined in ECMASpecs, and the rules are *almost* the same as Python’s. Except Python uses semicolons everywhere unless you wrap something in an parenthesized expression, JS uses semicolon unless you start a line with an implicit-line-continuation token.
http://es5.github.com/#x7.9
KillDream
June 30, 2011 at 4:41 pm
JavaScript is a horrible language. I appreciate first class functions but most languages already have this.
What is worse than the language are the developers. C programmers don’t have the luxury of namespaces or classes, yet they are capable of writing modular programs. Take a look at JavaScript’s most popular frameworks such as Prototype.js, MooTools, and jQuery. They all polute global namespace and cause conflictions. They try to alleviate the pain by introducing functions like “jQuery.noConflict()”. If you don’t understand why this is bad you must be a javascript developer.
-MadDeveloper
MadDeveloper
June 23, 2011 at 7:30 am
I agree. Cheers!
Btw, to all you javascript nerds out there, I take my hat off to you hackers. Its amazing what you can do in such an illogically structured language.
But its vital that you realize that you are hackers, or developing on top of hacks. Its great that you can organize yourselves, proves you happen to have some intelligence, but you cannot claim that it is a good idea to dev in javascript, not with so many other viable alternatives out there. Except for maybe the web (why don’t some of you hackers bother to develop 1st class HaXe or Actionscript tools? There are several starting points for open-runtimes that might actually work cross platform, and even better, cross browser. Actionscript 3 is the Ecmascript upgrade that Javascript was supposed become, you can thank Microsoft for helping to kill that standard)
Unless that just happens to float your boat, write whatever works for you, just realize that the next guy isn’t going to necessarily feel the same way about your hacked mess.
anonymous
June 24, 2011 at 10:49 pm
I agree, a lot of good arguments, but the real kicker (for me) is the lack of a standard library, or any decent standards at all. That is so effing basic it’s scary. It’s fine as long the language is meant to be used lightly, eg web frontend stuff, but once you start writing full applications, it’s time to say, “No, this will not do at all.” I like js, its fun, light, easy to get stuff done. But god help me if I ever had to build a real app with it.
Roderick Gibson
June 23, 2011 at 7:36 am
Let’s all stop using JS because of eval() and with()….
No seriously, do I really have to hear this BS over and over again?
Just because some dude doesn’t know eval from assigning a value to a variable doesn’t mean this feature should be gone.
As much as many advocate against the use of eval() (and which I agree with), putting the issue on the design table can only mean you’re a theoretical programmer which doesn’t get past “we need an eval module not an eval feature”…
Christian Sciberras
June 23, 2011 at 7:43 am
I agree that Javascript is a terribly hack; for the sake of the language and web as a whole, quickly improve Javascript before it becomes so entrenched that changing it will destroy what little browser compatibility there was. You know stuff is weird when programmers try to implement using code, what was originally supposed to be compiler based native features.
Cardin Lee
June 23, 2011 at 7:45 am
It’s beauty incarnate compared to C(++)…
Christian Sciberras
June 25, 2011 at 11:26 pm
I’m not sure how you can say that, when C(++) is responsible for the speediest programs on the planet (besides assembly, FPGAs, and ASICs), and C++ at least, is a well structured language with well-defined customs.
Javascript is, in comparison, a stick in the mud.
Of course, you might just be trying to be difficult. :P
anonymous
June 25, 2011 at 11:33 pm
anonymous – First of, C(++) does/did what other languages could have done. It has been successful purely because of hype, not because of its features.
Here’s a little secret; C(++) doesn’t have any feature which makes it run faster, neither does it have any that makes it easier to program in (arguably, the contrary).
Javascript may be slow because it’s first and foremost a script. Still, that’s not my point. As I said earlier, it’s undisputed fact that proper Javascript looks nicer than proper C(++).
Christian Sciberras
June 26, 2011 at 9:46 am
By the way, seems you haven’t heard the say, “C++ is an octopus made by nailing extra legs onto a dog”. There are similar ones which seem to convey the same point, such as, “The problem with using C++ … is that there’s already a strong tendency in the language to require you to know everything before you can do anything.”.
Christian Sciberras
June 26, 2011 at 9:56 am
I wouldn’t say C++ was purely succesfull because of hype. Its an old language, plain and simple, I think its a testament to its utility that its survived as long as it has. Yes, there are a million other languages out there today, but its still usefull enough that they teach it to collegiates.
As for it being an “Octopus made by strapping legs onto a dog” (loose quote), I’d counter that Javascript has its own shortcomings in needing its own strap-ons (J-Query etc.). There’s a lot to be said for coding style that the language itself has less control over.
There is no “undisputed fact” that Javascript proper looks nicer than C++ proper. Besides the saying that “beauty is in the eye of the beholder”, its also very much personal preference what code style works better for a particular programmer. If you’d like to expand your argument to in general C++ libraries being written horribly due to lack of proper understanding of the possible elegance within the language, then perhaps I understand what you’re saying.
There’s no need for C++ to have a feature that “makes it run faster”. Its pretty much one step above assembly code (well the underlying core of C is anyways), so all optimizations can be made at compile time. Of course, there are no runtime optimizations. But it might be mentioned that such runtime optimizations are written in and handled by C-like codes (Javascript Engines, etc).
I pretty much see you as objecting to the nuts and bolts of a machine as being less “pretty”. I’d compare that to saying that a traditional painting is less beautiful than a work of modern art, because the modern art requires less parts.
But I’d agree with you on the point that proper programming languages, vs. scripting languages, do require more time spent learning details. I don’t know that makes them any better or worse, however.
anonymous
July 11, 2011 at 6:41 am
“Undefined” vs. “null” exists in many common languages including Java and C, but “undefined” causes a compile error in those languages. So the major difference isn’t that it’s unique to JavaScript, but that JavaScript postpones to handle “undefined” to runtime, as it does with most of the stuff.
Thomas Jacob
June 23, 2011 at 8:19 am
” require is specific to node.js and doesn’t exist on any other major platforms.”
Did you have a look at Require.js? http://requirejs.org/
I think every language has its quirks, but I still believe that the minimalism of JavaScript still tips to its advantage. C++ also has its strenghts and weaknesses. It doesn’t have the notion of an interface, but I still think its a great language. JS can be improved (as the CoffeeScript syntax proves), but saying that it isn’t usable is a bit much. There are plenty of open-source libraries provided by the JS community that provide solutions for many of the issues with JS.
Jan Van Ryswyck
June 23, 2011 at 9:05 am
Pity javascript is not a sub-set language of java. As it stands or more correctly hat it is now being used for makes it ‘unfit for purpose’.
brian
June 23, 2011 at 9:19 am
I program in ASM, C, C++, D, and JS depending on my goal and time.
Java used an average of double the memory of JS -= a scripting language =- on alioth. Java is unfit for purpose.
It should be noted that I’m not arguing with you on JS being unfit. The language needs an upgrade.
Daniel
July 6, 2011 at 6:06 pm
A language designed for client side is not perfect for server side – what a suprise!
Null and undefined are both different by definition and the language allows you to check for both specifically so I don’t see the problem there.
As for inconsistency accross browser you can say the same for every front end languages, don’t blame the language blame the browsers vendor that still don’t get that to make the web better doesn’t mean creating browsers that are that different from each other on how they handle HTML, CSS, JS and the rest. It should be more about the UX/UI and not about the tech, then they would make the world better by offering users everywhere a stable rendering engine and offering multiple UX to please all. But that’s another issue all together.
I wouldn’t say that Javascript has a perfect design, it has flaws and to me it’s what make developing with it interesting, but who actually knows a programming language with no flaws anyway? Languages are written by humans, humans make mistakes and sometimes we have to live with them – big deal. There is a lot worst mistakes we have to live with.
After one is totally allowed to complain and have frustration tho :) I don’t know any developer that doesn’t have any regarding the language they use on a daily basis. I personally love Javascript, but then again I only use it on the client side :)
WhoWhatWhere
June 23, 2011 at 10:05 am
Perhaps using JavaScript as a server-side language is what is causing you to rant like this. I’m not saying everyone should look at js the way I do but simply put: JavaScript allows me to make the user go “ahhhh, how cool!”. The application (ie website/webpage/etc) would still do the same function, but JavaScript lets me make bells and whistles.
You can’t build a tuxedo just on ties, cumber buns and cufflinks – lol so don’t try :-)
John Y.
June 23, 2011 at 1:29 pm
Since your JS implementation is primarily targeting use as an embedded script engine, and is still early in its adoption, you should start implementing ES Harmony. That could be what sets your implementation apart from other CLR-based JS implementations. You could be the first to implement ES Harmony/6.
Nathan Davis
June 23, 2011 at 2:49 pm
[…] with this blog is that I don’t link to enough cranky rants about JavaScript, here’s one by Fredrik Holmström, of the IronJS project. The strong claim is […]
June 23, 2011: Distributed Magic Control « Rails Test Prescriptions Blog
June 23, 2011 at 3:44 pm
I don’t see a problem with some of your concerns. Other languages have the same “flaws” and have been very successful in their domain. Null vs undefined for example… PHP has the same concept. Now while PHP may not be the epitome of computer science, it is undeniably successful. The scoping of *this* is a something that people complain about often but I’ve rarely had a problem with it… I think this issue stems from people who expect JavaScript to behave like their favorite language. And what’s wrong with bitwise operations on doubles? I’ve not tried it myself, but is not a double just a bit pattern in memory somewhere? Now on the other hand, I do agree there needs to be some serious development of standard libraries. Perhaps this will come with time. JS is perfect for what it was originally designed to do, and is growing to do more.
Timothy
June 23, 2011 at 4:06 pm
Rants like these are really tiresome. I’m just incredibly sorry that JS is both easy to learn and hard to master. Sorry that Google wrote an incredibly fast runtime for it. Sorry it’s now the Lingua Franca in the programming world. Sorry you’re having trouble dealing with stuff that your lowly front-end developers have figured out for years now (“Hey I write Java – I don’t understand closures!” sniffle sniffle). Oh, and you’d like to run it on the server now too? Yeah, JS is awesome enough to do that in a thoroughly cool event-driven way, but maybe we need to write some code for it? Horror!
Maybe put some time into some GitHub projects instead of perpetuating the “JavaScript is not a true language” load of total BS?
Bill
June 23, 2011 at 6:44 pm
Sounds like someone is a bit defensive there.
dotnetchris
June 23, 2011 at 9:30 pm
Allowing a fallthrough for case labels is one of the good parts of JS: A lot of problems can be solved in a more streamlined, compact natural way than with a less readable verbose if-chain.
The lack of a large standard library isn´t a language issue: If a huge standard library is an essential part of a language it is usually a warning sign that the language itself isn´t powerful enough on its own.
Overall, the JS designers did a pretty decent job in creating a language which combines a rather small set of expressions, compact code, good readability and a lot of flexibility and power.
Granted, there are a lot of questionable features as mentioned in your list (the ‘arguments’ inconsistencies make me wonder most), but I can´t say they really affect daily usage.
Something I miss, though (applies to other popular dynamic languages as well): A decent type system which allows more than just the predefined types and would support verification as wel as more sophisticated development tools.
T$
June 23, 2011 at 10:05 pm
[…] Javascript auf dem Server ausführt. Klingt auf den ersten Blick verrückt und Javascript hat durchaus seine Macken, insbesondere wenn es auf der serverseite eingesetzt wird, aber Javascript hat durch seine […]
Mircosoft: Volle Kraft auf die Cloud mit Datenupload & Node.js | Code-Inside Blog
June 23, 2011 at 11:38 pm
Obj-C has several values for null, some of which is inherits from C. These include nil, Nil, NULL and [NSNull null].
Ross Smith
June 24, 2011 at 4:40 pm
I’m not well versed in objective-c, but isn’t this just different names for null in Obj-C? They’re all null (0x0) pointers, correct?
Fredrik Holmström
June 25, 2011 at 3:31 pm
I…believe so. C doesn’t actually have such a thing as null/nill, its just a couple of typedef/defines someone made somewhere….
Obj-C isn’t C, so it might actually be different, whatever semantic heritage it might have. Though I suspect most implementations of null could be argued to be exactly that, pointers to the very first block of “memory”
anonymous
June 25, 2011 at 11:10 pm
NULL is (void *)0. Nil is (Class)0. nil is (id)0 (where id is the “anything that looks like an object” type). NSNull is an actual singleton class, and [NSNull null] returns its sole instance; it’s meant to stand in for nil in collections because getting nil back from a dictionary or a set means “this just wasn’t there”.
Aside from NSNull, I believe the use of many null-like names in Objective-C is primarily meant to make it clearer what type of value you’re (not) passing. NULL is the absence of a function pointer, nil is not an object, Nil is not a class, etc.
As far as undefined goes, I believe Perl tipped this balance right: undef and NULL.
Additionally, it seems weird to cry out for some sort of standard and then deride CommonJS, since as far as I know, node.js is supposed to be an implementation of CommonJS, including its module system. Even if it’s just “some people having an opinion”, isn’t that exactly what you were asking for? What better way for a standard to be borne out of than actual usage?
Jesper
June 26, 2011 at 12:11 pm
Thanks for sharing this.
Raul H Macias
June 24, 2011 at 6:18 pm
[…] just good for JavaScript quizzes?). Recently this way of declaring functions was brought up in this article and confused some folks including […]
Different ways of declaring functions in JavaScript (this is madness!) | David B. Calhoun – Developer Blog
June 24, 2011 at 6:20 pm
PHP is much, MUCH worse, yet people keep flocking to that in droves. Microsoft products are all awful……but…….same story.
I dunno who you are out to convince or what the point of this post is exactly but it reads like FUD. Microsoft shill anybody?
Ryan
June 25, 2011 at 1:15 am
Have been programming javascript client-side for years now. Don’t have any issues. Great language. Btw, jQuery is awesome.
Dan
June 25, 2011 at 4:24 pm
[…] which is used to run JavaScript on the server. Sounds crazy on the first sight and Javascript has its folds especially on the server side but JavaScript has its advantages because of his “asynchrone” […]
Microsoft: full speed ahead into the cloud with fileupload & Node.js | Code-Inside Blog International
June 27, 2011 at 2:32 pm
While I do agree with some of your points, I’ll have to disagree with most of your conclusion.
>Context sensitive function keyword
Function declarations are hoisted, which allows you to have Python-decorator-like functions that add meta-data to another function, to be executed before the physical function declaration in the file.
So:
inherits(Foo, Bar)
function Foo() {
/* xyz lines of initialisation */
}
Is far more readable than:
function Foo() {
/* xyz lines of initialisation */
}
inherits(Foo, Bar)
>The scoping of the this keyword
It has its uses once you start dabbling on protypical inheritance the way it should be done. Also, I still think methods shouldn’t be tied to objects, they should be generic. JavaScript does this, you can pick any function and apply it to any object.
Also, you have Function#bind. And ECMAScript guys are debating over the inclusion of real lambdas, which would preserve the this context for little functional code like:
something.map({|factor| this.value * factor}).filter({|x| x > 0})
It’s not decided upon yet, and even if it is, will probably take far too long to be implemented everywhere.
>Switch case fall through
REALLY? I mean, it has its uses. If you can’t remember to put breaks when you want a case to end…
>Automatic Semicolon Insertion
Never got the gist of the hate over this. It allows you to write clean code, without needless semicolon noises. An clean code > * (which is in part why I love Python)
>Bitwise operators that work on doubles
Technically they don’t, all bitwise operators convert the operands to INT32 or UINT32 before carrying on the operation.
>Type wrappers and type conversions, new String(“foo”) vs. “foo”
I agree, having new String, new Boolean and new Number when the primitives work completly different is entirely silly.
>The new keyword makes function behavior dependent on the context they’re called from
Huh? What do you mean by this? The new keyword just constructs a new instance from a prototype and apply a function on that for doing initialisation. Also, “context dependent” is not really a issue in JS — functions are not bound to objects.
>With and Eval
Hm… lemme see, you’re criticising a dynamic language for having eval? So you also do criticise Lisp, Python and insert-any-dynamic-language-here. Really, eval is GOOD, people just need to use it for things it was designed to solve.
With, while it’d have its uses too, introduces weird ambiguities and is dog slow. It was also removed from the language.
>The arguments object
Agreed again, magical lexical things screams so much badly designed macro… Though, Harmony plans on killing it off and replacing it by splats and keyword arguments.
>The typeof operator
Has some uses as well. For example, checking if something is callable. Checking if a free variable is available without throwing a undeclared error.
>The global object
Huh? I again fail to see the problem here. I mean, something *has* to be at the root of the environments… right, right?
Thing is, JavaScript has its flaws, yeah. Every language has got them (like the terrible way Python 2.x handled variables defined in the outter scope), but JavaScript has also got plenty of goodness to back up the language. You’re free to dislike the language and its features, but listing problems without giving the reasoning of why that’s a problem within the design of the language is usually not the best thing to do =/
I like JavaScript for its minimalistic design and simplicity (though Harmony is somehow killing that). Some of the stuff are very poor — inheritance in JS was a laughable matter until ES5, for example, — and some are hardly bearable, though. The whole standard library has pretty poorly named methods, and some rather unintuitive things as well, but at the very end, I think the flexibility it gives is the most rewarding thing in the language. Surely still not as flexible as Lisp, but still somewhat more than Python, so it has been my language of choice up to now.
Your mileage may vary, of course :3
KillDream
June 30, 2011 at 5:11 pm
[…] The Good Parts）和Fredrik Holmström的文章《我对Javascript的抱怨》（My gripes with […]
阮一峰 | Javascript的10个设计缺陷 | 穿墙链接 http://dld.bz/caonima777
July 1, 2011 at 2:30 pm
[…] My gripes with JavaScript […]
JavaScript Magazine Blog for JSMag » Blog Archive » News roundup: Paper.js, Fathom.js, test262
July 1, 2011 at 6:07 pm
[…] The Good Parts）和Fredrik Holmström的文章《我对Javascript的抱怨》（My gripes with […]
Javascript的10个设计缺陷 « 编程王网站
July 2, 2011 at 4:30 pm
[…] The Good Parts）和Fredrik Holmström的文章《我对Javascript的抱怨》（My gripes with […]
Javascript的10个设计缺陷 — 见贤思齐
July 2, 2011 at 10:42 pm
In a dynamic language, having both ‘null’ and ‘undefined’ is actually quite handy. A good way to think of it (and how the Definitive Guide puts it) is that ‘null’ represents a normal, expected state of a property meaning either “i don’t have a value” or “i don’t apply”, whereas ‘undefined’ generally represents an exceptional/unexpected situation, such as “this is not the object you are looking for”. :)
Because in JavaScript you can add and remove properties at will to an object (something I find incredibly handy), simply having null would not tell you if the property actually exists and is just empty, or it doesn’t exist at all. Moreover, the ability to actually set something to undefined allows you to make something behave as if it doesn’t exist even if it does, which is also really handy.
So in short, I really like having both null and undefined. Now if you really want to get picky, you can look at NaN, and tell me why “NaN == NaN” returns false. ;)
Logan
July 4, 2011 at 3:34 pm
Logan, NaN!=NaN is entirely logical. NaN represents a multi-value, hence there are lots of different NaN’s out there. Everyone should know this, as does the fact that `NaN==NaN` should be rewritten as “isNaN(NaN)==isNaN(NaN)”. :)
This similar in principle to why `{}=={}` returns false – though they *look* like the same, they’re in fact not.
Christian Sciberras
July 5, 2011 at 7:55 am
http://en.wikipedia.org/wiki/NaN
check it out.
Nana's Lich
July 8, 2011 at 3:12 am
In .NET, there is DBNull.Value, which actually represents the null value in ADO.NET, JScript.NET and the native JScript engine.
And for null itself, means “the missing value”, or “undefined” for these scenes above.
Nana's Lich
July 8, 2011 at 3:09 am
[…] My gripes with JavaScript […]
Weekly Links– 2010_24 (50 for Web Devs & Other Geeks) :Misfit Geek
July 15, 2011 at 8:06 pm
(function bar() { })
function foo() { }
The difference being that bar is self-invoking? What’s the issue with that?
akismet-102aed867cd9e1bbb2b77b7e78c701c1
July 17, 2011 at 5:05 pm
In response to a language with two nulls, VB.Net with “Nothing” and “Null”(Technically DBNull). Probably the best example to give since, like javascript, vb.net uses two different ambiguous terms to describe nothingness. Good post though!
Daniel
October 20, 2011 at 9:09 pm
[…] The Good Parts）和Fredrik Holmström的文章《我对Javascript的抱怨》（My gripes with […]
阮一峰：Javascript的10个设计缺陷 - 博客 - 伯乐在线
November 2, 2011 at 11:43 am
I’m certainly not familiar with how libraries or patches are *commonly* done in JS, or if anyone has “solved” it (with their own “standard”), but the monkey patching could easily be solved by a “standard” similar to how SQL databases add their own transition scripts.
You simply register an issue with some sort of ID (int or guid), and make sure to use that ID to check and register your patch in both the monkey patch and the final release patch. Then you issue some sort of patch warning or error when trying to override a patch, and leave it as first-wins instead of last-wins. If you want to get really fancy, you could also create a patch dependency system where you can’t apply a patch unless its dependencies are satisfied.
It’d be really easy to come up with a convention for this, IMO. The standard hasn’t and probably won’t, and I see people being slow to adopt it, but it isn’t really an insurmountable problem. You could come up with a common library or a proprietary system for each library to do this, and either would work as long as the monkey patchers and official patchers both follow follow the same system.
Libraries extending the standard has been the-way-to-do-things in C++ for a while now. They’re super slow, but so is their language design because of dealing with so many low-level issues. I don’t see JS having the same problems with a “prefer libraries over language extension” mantra.
As for browser adoption, it’s picked up a *lot* over the last 3-5 years because of influx of new developer and new ideas, and because of the momentum towards making the browser an OS-style platform rather than “something wot to view web pages in”.
Merlyn Morgan-Graham
December 17, 2011 at 1:47 am