Why JavaScript is a toy language

! Warning: this post hasn't been updated in over three years and so may contain out of date information.

I recently wrote an article on why HTML5 is stacking up to be a bad idea and why an Virtual Machine-style solution to web content would be so much better. In that article, I made the claim that JavaScript is a toy language and suggested that few people would argue against this. I have since learned that a lot of people would actually argue against it, claiming that it is a good language really.

To my mind it is self-evident that JavaScript is a toy programming language, but clearly it isn’t self-evident at all. So why do I make this claim and how can I defend it? Read on for the answer…

JavaScript can’t be compiled
When considering what makes for a serious, professional language, and what makes a toy language, code compilation seems the obvious place to start to me. Every line of JavaScript written for every web page exists as fully readable source code, for JavaScript cannot be compiled. The nearest thing I can find to a JavaScript compiler is the now defunct compiler for .NET language, JScript.NET. This however isn’t true JavaScript; instead it’s a JavaScript-like language, for it supports classes for example.

There are two really important reasons I can think of for wanting to be able to compile code: protecting ones ideas and security. The latter is one that many folk may not immediately think of, but it is in many ways the more important. By compiling code into some sort of library, that library can be digitally signed to protect it from being tampered with. JavaScript cannot do this. Nor can it protect your ideas: every bit of JavaScript you write is made available to everyone to steal and re-use as they see fit and good luck in court proving you wrote it first!

JavaScript is not a true OO language
I’ll admit up front that this is the most controversial of my criticisms of JavaScript, as it is the most difficult to defend. In reality, there is no standard definition of what makes an Object-orientated language. So anyone is free to call anything OO if they so choose. JavaScript fans do just that with their language.

There are though a bunch of features that tend to be common across OO languages: abstraction, encapsulation, polymorphism and inheritance. There is also another feature common to every single mainstream OO language bar one (that one being JavaScript) and that is classes. Classes are required to achieve abstraction and so JavaScript can be crudely thought of as only 3/4 of an OO language.

JavaScript fans like to talk of “two schools of thought on OO”, those being “classical” (ie every OO language bar JavaScript) and “prototypal” (ie javaScript). Generally in life, when the arguments of both sides have been examined and the result is “you” on one side of the fence and “everyone else” on the other, it is safest to conclude that you are wrong.

Despite this, Doug Crockford and other JavaScript apologists like to trot out a truly bizarre claim: prototypal inheritance is so powerful, you can do everything in JavaScript that you can in class-based OO, but that the opposite isn’t true. For some reason this statement never seems to be challenged, even though its blatantly nonsense. Class-based OO can offer the developer features such as static methods, abstract classes, interfaces, method overloading and operator overloading. None of these features can be offered by prototypal objects. Prototypal objects on the other hand are really nothing more than glorified hashtables and every OO language that allows functions to be treated as objects (which includes just about every OO language bar Java) can replicate prototypal objects with ease.

JavaScript has almost no type security
Many JavaScript fans like seem to take the view that when in a hole, one might as well keep digging. Not satisfied with claiming JavaScript is a true OO language, they like to claim its a functional language too. Two pieces of evidence are offered up to support this assertion:

  1. JavaScript supports lambdas/ closures
  2. JavaScript has loose typing

I have no beef with the first claim: JavaScript has a good implementation of closures, though it is a feature that a great many modern languages, such as ActionScript, C# Ruby and Scala, also offer. The second is nonsense though. True functional languages such as Haskell and OCaml are very strongly typed languages that permit no implicit type conversions.

It is true though that JavaScript has loose typing. In fact it is so loose that even a gentle shake will make it fall apart. JavaScript – through its use of hashtables as objects – takes mutability to the extreme. As there is no concept of packages or name spaces in JavaScript, every public member of every object is exposed to every other object. Worse, every public member of every object can be changed on a whim by any other object.

Of course its worth also mentioning that this excessive mutability is exposed to every dodgy piece of malware code in every advert, hacked page etc that the browser is exposed to. So the lack of security in JavaScript isn’t just limited to the type system.

JavaScript encourages abstraction layers
When I published my article on why HTML5 should not become the future of the web, the first two comments addressed the issue of JavaScript’s inadequacies with “don’t worry, you can hide the JavaScript crap beneath an abstraction layer” remarks (paraphrased). Abstraction layers such as JQuery, Objective-J and GWT have become very popular recently. The reason for this seems obvious: JavaScript is not up to the job so needs hiding away from the developer, who needs a “real” programming environment offered to her instead.

Whilst these tools no doubt remove some of the pain of using JavaScript, they are to be treated with caution. Take GWT: it allows developers to use a “proper” programming language, in the form of a Java-like syntax, to develop their web app. This can be compiled to the JVM, debugged etc. Then when the developer is happy that it works, they “compile” the code to a mass (mess might be a better word) of JavaScript, which then runs in the browser. This does of course cause a huge problem of how to debug JavaScript you didn’t write when it doesn’t work the same as the original code. However that is a minor point compared with the elephant in the room: Google must have concluded JavaScript was so far removed from a language its developers should work with, it invested in an entire JVM-based development environment to shield them from it.

JavaScript: The Good Parts
Whenever I mention my concerns with JavaScript, many folk tell me I should read Doug Crockford’s book “JavaScript: The Good Parts” or watch various talks he has done on the subject. I watched an hour long presentation he gave to some Google employees. The good parts are Lambdas, dynamic objects (think hashtables again), loose typing and object literals (think hashtables again.) I didn’t time it precisely, but I felt he spent around 15 minutes of his hour’s talk detailing these supposed good parts. The rest of the time was spent criticising the language. For me this quote from him summed it all up: “JavaScript became the world’s biggest programming language completely independent of its merits.”

We are currently stuck with JavaScript as it has spread all over the web like a plague. Its commonality though should not be taken to imply it’s fit for purpose. It clearly is a grossly substandard language by modern standards and thus can be legitimately described as a toy language. I rest my case.

40 thoughts on “Why JavaScript is a toy language

  1. David:

    You are being inconsistent when you state:

    “This does of course cause a huge problem of how to debug JavaScript you didn’t write when it doesn’t work the same as the original code. However that is a minor point compared with the elephant in the room: Google must have concluded JavaScript was so far removed from a language its developers should work with, it invested in an entire JVM-based development environment to shield them from it.”

    and at the same time claim that js needs to be compiled. A compiled language converts high-level code to a mass (or mess) of machine code. How do you debug this when it behaves differently?

    Also, you state that uncompiled code can’t be digitally signed. I’m not sure where you get this from. Why on earth is it harder to sign a .js file than e.g. a .exe file?

  2. If your whole post was meant to be a troll, then I apologize for biting.

    1. Javascript can’t be compiled:

    Why not? Just because nobody has written a binary compiler yet doesn’t mean that nobody COULD write one? The dynamic nature of JS would make this rather tricky, but harder problems have certainly been solved.

    Re: signing: You could just as easily sign a .js file and only load signed .js files as you can with dll’s and so forth.
    Re: “code security”: This argument is rubbish. Most any .NET assembly or java class file can be trivially dissasembled by tools like .NET reflector into a near-perfect match for the original source code. Doing this with native C/C++ would be more difficult, but there are still plenty of C/C++ dissasemblers out there.

    2. JavaScript is not a true OO language:

    As you’ve mentioned yourself, “OO” means different things to different people. To me, C#, Java and C++ aren’t true OO languages either, because they have no inheritance for static methods, and many other such holes.

    I think you need to rephrase the statement to read “JavaScript doesn’t do OO the way I’m familiar with, and this upsets me. I want a pony”

    3. JavaScript has almost no type security:

    private member variables and functions can be implemented relatively easily using closures, so I don’t see how you can claim that any object can be easily mutated by any other object…

    Yes the implicit type conversions between strings and numbers and so forth are annoying when you’re learning the language and you don’t expect them, but once you know the rules they’re no worse than implicit operators in C# (and certainly less problematic than operator overloading in C++).

    At the end of the day this comes down to philosophy: Do you think the users of your code are likely to be idiot code monkeys that you have to protect everything from, or do you think they’ll be reasonable and sane? Most of the time the users of your code are YOU, so it’s a subjective personal question 🙂

    4. JavaScript encourages abstraction layers:

    If you want to code for the web you MUST use javascript. Anyone who is opposed to using javascript for whatever reason therefore is forced to write an abstraction such as GWT.

    IMHO it’s a testament to the power and flexibility of javascript that this is possible.

    At any rate, abstraction layers are GOOD. If it weren’t for abstraction layers, we’d all still be coding in binary. Any language that makes it easier to define abstraction layers is giving programmers a productivity boost. Again, this is a PLUS for javascript, not a minus.

    At any rate, I appreciated the essay 🙂

  3. > JavaScript can’t be compiled

    Both .net and java supposedly compile, but only to intermediate language. The actual byte code still gets compiled at runtime into actual machine language (with all the awesome jit magic). No difference.

    > JavaScript has almost no type security

    Type safety is illusion. Unless you can differentiate between int-feet from int-meters.

    > JavaScript encourages abstraction layers

    Ha, every abstraction layer is useless unless its between assembly and the layer I am comfortable with.

  4. Sigh.

    Compilation – lots of dynamic languages used in professional settings to run serious applications can’t be compiled. Would you argue that Python or Ruby is a toy language?

    OO – Javascript has objects; it has inheritance (prototypical rather than classical); it has abstraction; it has encapsulation; and it shares its way of implementing these things with other real languages.

    Loose typing – yes, Javascript has loose typing.

    Abstraction layers – really? Really? Javascript isn’t a real language because it encourages developers to build functionality and then abstract it? *Really?* I guess everyone who uses a library or module with an API is playing with a “toy” language.

    The Good Parts – people tell you to read the book, and in response you watched a video? Try reading the book.

  5. Glad the first few commenters kept their cool and told it straight, I was having trouble catching my troll breath at all the language bigotry, narrow-mindedness, and fallacious arguments in the post proper!

    But honestly, I sympathize. Only lately am I TRULY appreciating Javascript for what it is, and it’s so easy to write it off as a toy before you have your epiphany.

    On the bright side, ECMAScript 5 was just approved, so it looks like the language itself has a chance at moving forward this decade!

  6. like most of the other respondents, I disagree with your claim. Javascript is a lightweight interpreted language. The only major fault I find with it is in the multitude of mildly incompatible implementations across different browsers. The language itself is fairly nice I think.

    1. Javascript can’t be compiled

    It can, of course, there are many different Javascript compilers producing machine code, java bytecode, etc. Any programming language can be compiled.

    What you really mean is that it’s not possible to ship compiled objects instead of source in your web page. I regard this as a good thing, it encourages sharing and open source. There are javascript compressors / obfuscators which make it even more difficult to discover what a piece of javascript does, compared to decompiling unobfuscated object code written in C. I’m glad the default is openness. CSS and HTML are similarly open formats, it’s simply better to use readable plain text as much as possible.

    Openness leads to better security, compared to bogus “security by obscurity”. Compare the security of Linux, OpenBSD and Apache with the closed-source Windows and IIS.

    2. JavaScript is not a true OO language

    Actually all these “OO” languages such as Java, C++ and suchlike are not true OO languages. Smalltalk is an OO language, and Javascript is a lot closer to it than Java or C++. Go read something by Alan Kay.

    3. JavaScript has almost no type security

    This is a design choice. According to your criticisms, python, perl, ruby and lua are all “toy languages”. Perhaps that’s why google writes so much of their code in Python, because it’s a toy language.
    It is easy to write things in Javascript that would require “template functions” and the like in C++, because Javascript does not enforce strict typing. No need for explicit interfaces, any conforming object can be used.

    4. JavaScript encourages abstraction layers

    This is obviously a good thing. The main need for abstraction layers in Javascript is so that you can support all those gratuitously / maliciously incompatible browsers such as IE; but abstraction has other benefits. There are some really good libraries and toolkits for javascript, such as jquery. It’s a credit to the language and object model that it is not too hard to create powerful libraries like these.

    I regard all of your criticisms as advantages for Javascript. Additionally, your points apply equally to most other dynamic interpreted languages such as python and ruby. While these are not usually compiled to machine code, and therefore usually run a little more slowly than C programs, they can be good lightweight languages, and are emphatically not “toy languages” as they are widely preferred by expert programmers around the globe for important projects and tasks.

  7. You could have saved yourself some time (plus some flames and a whole article body) by just writing ‘JavaScript is a scripting language’ 🙂

  8. I don’t really care about javascript. I think its level of abstraction is wrong for web programming. There is too much you need to reimplement from the basic building blocs given to you. Sure these building blocks are very powerful, but the whole point of abstraction is to make is easier and faster to manipulate high level concepts.

    I agree that browsers should have some kind of vm (jvm or clr) and jit compile whatever scripting language the website wants to use. I disagree that you should be able to distribute compiled bytecode right away, you mention security: once the signing mechanism is corrupted (and it will because the incentive is huge) this will be an open bar for all malware around. I want _my_ browser to consider that anything coming from the network is hostile and should be sandboxed.

    However, you should lookup Prototype Oriented programming a bit more. Javascript is not the only language to use this paradigm: Lua (this is used in commercial products quite a bit), Io, Object Lisp,… are also based on it. And if you consider ruby to not be a toy language then Lua is not one either. Not to mention that some ruby features actually tend to imitate Prototype based features. There are CS researchers working around prototype (see the Safe programming language). Admittedly though, there is not a lot of literature on prototype based programming yet.


  9. who cares either way?
    All of these arguments be it whose ide is better or who has the better language are just abstractions of the school yard “my dads better than your dad” argument.

    You use whatever suits you at the time, if you don’t like writing in javascript then make an abstraction that suits you and stop crying like a baby that not everyone sees you eye to eye.

    grow up, please this is a massive waste of time and everyone here should be ashamed!

  10. Seems strange to be agreeing with David but I very definitely do in this case. With one exception – toys are meant to be fun to play with. But JavaScript just gives me a headache whenever I look at it. It’s a nasty little piece of junk.

    I love the quote fro acb:

    > Toy language or not, javascript gets shit done

    My feeling exactly (although I suspect we have opposing interpretations) – a whole lot of **** is done in JavaScript.

  11. It seems most of the comments conclude my thoughts also, so I won’t repeat what’s already been said.

    JavaScript is a bastardised language, born out of necessity and with hardly and forethought. It’s borrowed features from other languages – the syntax from Java, the functions from Scheme, the prototypal inheritance from Self, regular expressions from Perl and so on. But this does not mean it’s a “toy” language. I’m not even sure what you mean by that. The fact that it’s easy to write code in it must be an advantage, not a disadvantage. I’m sure many thousands of kids have first learnt to program by starting in JavaScript.

    I like to draw parallels with the English language. English wasn’t initially planned by an overseeing standards body, it’s horrible to learn, it’s completely unphonetic and inconsistent and is a fusion of many other languages all rolled into one. But therein lies its power – i did can rite well bad wordz n dat – but with decent education and focus on grammar, I (and poets) can write beautiful literature. The same applies to JavaScript. You can write bad and good JavaScript if you try.

    I think for all JavaScript’s faults, it has many great positives. It’s not ideal, but don’t deny what it’s capable of. And yes, I’d read Crockford’s book, not just watch the video. I’ll lend you a copy if you like 🙂

  12. @Paul Neave
    you can make such observations about any language, following the predicate law if the negative of a statement is also true then the original statement didn’t state anything at all. Your comment fits this criteria.

  13. @Jason,

    Your comparison of JavaScript with machine code is not a valid one. When debugging compiled code, there is metadata associated with the bytecode/ machine code that enables the debugger to map back from an instruction to a line of code.

    One point I was making regarding signing is that compiled code goes through a transformation process, which is missing with JavaScript. Signing becomes part of it and building in a check within other code for the correct signature also becomes part of that transformation. Taking a set of dll’s, stripping out the signature and signing checks and still have it work is a non-trivial task. Sure a source file could be signed, but that signature is trivially easy to remove and replace. It is far less secure therefore.


    Someone could write a JavaScript compiler. No one has though, despite it having been around for 15 years, no one has.

    It is easy to obfuscate .NET dll’s etc to prevent disassembly. This cannot be done with JavaScript. As for “JavaScript doesn’t do OO the way I’m familiar with, and this upsets me. I want a pony”, I think my original comment is more accurate: JavaScript doesn’t do OO the way every other OO language. Because of this it makes sense to call it a prototype-orientated language, rather than an OO language.

    I wasn’t referring to private members. I explicitly stated any public member of any object could be modified by any other object.

    “If you want to code for the web you MUST use javascript” is what is wrong with the web in my view. Imposing a language – and one that even its fans admit is really rather shoddy in many ways – is just plain wrong. Thus my original article suggesting that HTML5 should consign JavaScript to the bin of history (or at least to the fringe occupied by its most devoted fans. In its place we should have some sort of browser VM that has supports a defined set of bytecodes. This then allows any language to be used with web pages.


    There is a world of difference between source code and bytecode. The latter is language agnostic. In the last 10 years, ECMA have faffed about with JavaScript making tiny changes to it, through fear of breaking existing code. During the same time, the JVM has barely changed (I believe they have added one bytecode, but would need to check that), yet Java has gone through huge changes and we have a whole raft of languages from Erland to Ruby that now target the JVM.

    Regarding int-feet and int-metres, type safety tends to only be done properly by functional languages, which is why its no surprise that F# can differentiate between them at compilation. Take a read of F# units of measure to find out more.

    I do not like Python, for I dislike its use of whitespace to describe a program’s structure. It is hardly a toy language though. The fact that it and Ruby are both available for .NET and the JVM – whereas JavaScript isn’t. Why might this be? The obvious answer is because Ruby and Python aren’t toy languages like JavaScript and that JavaScript only gets used at all because web developers have no choice.


    ECMAScript 5 is really ECMAScript 3.1, ie a tiny tweak to a 1999 standard. It is still firmly stuck in the last millennium.


    You misunderstand what I mean by type security. I’m not referring to the dynamic nature of variables in JavaScript. As you say, many non-toy languages use loose typing. There is no right answer to the dynamic versus static typing debate. I personally prefer static typing, but it’s purely a personal opinion. The problem with JavaScript is not that there is no static typing, it is with the nature of its “objects”. Every public property of every object in JavaScript can be modified or deleted by every other object. This is an absolute recipe for disaster as far as security is concerned.


    By “toy language” I mean that it isn’t fit for purpose as far as using it in professional situations is concerned. Sure its used on the web. This is because folk have no choice. Where folk have a choice though (ie everywhere else), then JavaScript is conspicuous by its absence. This is why I say its a toy language.

  14. The Mongodb database uses javascript for implementing map-reduce query functions, which are run in parallel on multiple machines. It can compile / evaluate the javascript using spidermonkey or google V8. If javascript is used by a major database for a performance critical subsystem like paralllel map-reduce, in what way can it be a toy language? Couchdb also uses javascript I believe.

  15. @Sam,

    I’m impressed that you found something so highly regarded (if not exactly mainstream as NoSQL DBs are still fringe) that is based on JavaScript. Some people make the strangest of decisions.

    There again, NoSQL is all about key/ value pairs, just like objects in prototype-oriented languages are. Perhaps they are ideally suited to each other. So after the web revolution when we are all liberated from the constraints of “JavaScript or nothing” for web development, JavaScript can find itself a new home powering future NoSQL databases. 😉

  16. Something else that’s based on JavaScript, highly regarded and a little more mainstream than NoSQL would be the common Web Browser. No other client-side language for the web has had comparable success. Perhaps there is a reason for that – JavaScript is actually a pretty good language. Seems like you just don’t like it – that’s ok, but your criticisms are all invalid or misdirected (they would brand python a toy language along with JavaScript, which is evidently false).

  17. @Sam,

    You are going around in circles now and descending into farce with your comments. JavaScript is built into browsers and no other language is. Of course it’s the most popular as it’s the only choice!

    And as previously stated, you are completely wrong when you try to extrapolate from my criticisms of JavaScript to Python. Python compilers exist (because Python is actively used in many programming domains, unlike JavaScript). Python is a true OO language. Python has better type security than JavaScript. Unlike JavaScript, there hasn’t been an explosion in abstraction layers for Python that try to hide the language from developers.

    Python is fit for purpose; JavaScript isn’t.

  18. I believe another elephant in the room is Mozilla’s Rhino platform. A cursory glance at Rhino’s website was all it took to confirm that the Rhino engine compiles JavaScript to JVM bytecode (I’ll admit that I’m not very familiar with the Java ecosystem). Thus, if you argue that both Ruby and Python have implementations on the JVM and are NOT toy languages, you must concede that native or byte code compilation has nothing to do with your opinions on JavaScript.

    For what it’s worth, I used to agree with you. I thought JavaScript was an absolute nightmare to work with (PHP, too). But like so many other languages, I had to immerse myself in the ecosystem and find which tools worked for me. I agree that the DOM API is unnecessarily complex, but if you plop jQuery on top of it, it becomes manageable and even enjoyable. A 3rd party library clearing up some of the uglier parts of standard implementations is hardly unique to JavaScript.

    I concede JS’s relative inflexibility in the OO department, but I don’t believe any point you’ve made really puts it in the toybox. To me, a toy language is one that, while Turing complete, doesn’t lend itself to solving real world problems in any domain.

    I can understand the fact that you don’t like JavaScript. That’s fine. As other commenters have noted, there are abstraction layers available. Come to think of it, i believe the availability of abstraction layers like GWT and Pyjamas makes a case for JavaScript’s utility and wide use. When was the last time you heard of an abstraction layer on top of Brainfuck?

    I’d love to see alternatives become available, but if you think those alternatives won’t also be some permutation of a lightweight, interpreted language (Lua, anyone?), I want some of whatever you’ve been smoking 😉 I shudder to think of a future with more Java applets… I think we’re currently moving in the right direction.

  19. @Mike,

    Where did you find a reference to Rhino compiling to JVM bytecode? Having looked closely at the site before (at least I thought I had), I found no reference to it compiling JavaScript, nor can I find any now. It is a JavaScript interpreter, written in Java. I’d imagine the project it pretty much dead these days, as the likes of Groovy, JPython and JRuby all offer the same functionality, but using far more powerful, far less domain-specific languages. As an added bonus, they can be compiled to JVM bytecode.

    I haven’t been smoking anything: I’ve simply been breathing the air of the 21st century. You should try it sometime ;). Java is an old language, just like JavaScript. I no more see Java as the future of development any more than I see JavaScript offering a viable future.

  20. I agree with David Arno that JavaScript is obviously, to my mind as well, a toy language in its practical usage. The obviousness is inherent in that most things built with it very clearly feel like plastic toy versions of the things which, “the toys”, are attempting to emulate; and is further expressed by the (to me, confusing) need to recreate everything ever programmed as a WEB 2.0 (!!) toy mockup of those same things.

    More specifically, I would like to point out something I found amusing in, “JavaScript: The Definitive Guide”, Section 9.3.7, where, “ImmutableRectangle”, is described using Doug Crockford’s, “private members”, pattern. I found it interesting that, while using such a pattern, the member properties of an object are immutable due to closure; however, the accessor methods are necessarily public, and are thus mutable just as the member properties were before the programmer created an IE memory leak (closure) to, “protect”, the precious variable… but then realized we still need to read the variable for it to be useful.

    From that, I would conclude that while all data is mutable, some data is far more mutable than it should be; that the private member pattern of JavaScript is a glorious excercise in futility; and that feeling convinced of its usefulness would probably illustrate a need to justify the utility of something which is actually a toy. That being said, considering what JavaScript is to contemporary web design, I’ll still be finishing my study of it and willingly, if grudgingly, utilizing it professionally. People buy and sell toys quite readily, after all. 🙂

  21. @(the author)… I completely agree with your post and think that you made some very valid points… anyone who thinks javascript (or PHP for that matter) are decent languages are not really programmers but most likely some form of “web designer / web developer” where programming is only part of what they do.. I was this way myself for a while as its the natural course to get into real web development but once I started learning Python I start to throw up a little when I have to do anything directly in javascript or PHP (I am starting to use a python port of the Google Web toolkit for my JS now)… the list could go on and on about whats wrong with these toy languages but just one example is that you can’t even use dictionaries in either, thats right, you have to use numerical indexes in “arrays” for everything which is just plain stupid and counter-productive to the programmer

  22. I think someone said to me once: One can love or hate Javascript. Well, let’s not get so emo.

    I don’t agree something can be just good, or just bad. Something is good/bad by some criteria.

    As we go further in semantics, it’s hard to say something is a toy language, because there is no such term (not mentioned by a language authority like an author of English dictionary). as for definition for a “toy” alone, one can have fun with any language, not only Javascript.

    But because it should be an intention of debaters to try to understand each other, that’s what I do (and I hope You will try to repay reading my awful english).

    Basically You just don’t like Javascript, and that’s hard to argue with. What is a flaw for You, for me is a virtue. For example You say that javascript is not secure because it’s not compiled. I couldn’t disagree more! I have no hacking background, but hacked two popular mmo games already that were made in flash. One is http://versus.thewitcher.com (quite funny duel mechanics btw). The developers thought they’re client is secured, as it’s compiled. That’s why at least from a an end-user point of view Javascript is better, because it enforces developers to put crucial checking and logic on a server. It also forces being open source making it so easy to learn (You see something nice? Just steal it’s source)

  23. “It also forces being open source making it so easy to learn (You see something nice? Just steal it’s source).”

    Yeah, I love it when I spend weeks putting together a complex web app for a client knowing that anybody can right click and take it. Great ROI. If I want to start a community project I’d like to be the one that makes that decision thanks.

    Anyway, I don’t like javascript and I hate the fact that I am forced to use it. jQuery is ugly as hell too so that’s not that much better. Everybody goes on about chaining and how great it is. It’s plain stupid. It’s the programming equivalent to a massive run-on sentence. It’s very difficult to read and in the end doesn’t really save you a whole lot of lines. There is no advantage to chaining over using separate statements.

    Out of the abstractions I’ve checked out, MooTools and Cappuccino are the most appealing. Unfortunately as seems to be the tendency on the web, the least robust (jQuery) has gained the most traction. When even Obi Wan Crockford uses the term “steaming pile” in his description of javascript, JS apologists should hardly be offended by this article.

  24. @Rick – I know this is an old thread, but saying that JS doesn’t have dictionaries shows how little you know about the language. Objects in JS ARE dictionaries/maps/key-value pairs. Using them is as easy as:

    var map = {
    “fu” : “f***ed-up”,
    bar : “beyond all recognition”

    alert(“Your understanding is ” + map.fu + ” ” + map[“bar”] + “!”);

  25. Oh my god… I really liked this article. I know there is a bunch of people that love javascript. I respect it. But, to be honest, it always seemed to me like a draft, an unfinished language project. It does not enforce good programming practices and give the vm developers a hard time to make it perform decently. Hard to maintain, crap OO support. OOP was thought to enforce programmers to write better code, and javascript is totally the opposite. I am not stating you should love C++, but Google Dart is so much superior…

  26. Rhino is a JavaScript compiler:

    “The JavaScript compiler translates JavaScript source into Java class files. The resulting Java class files can then be loaded and executed at another time.”


    Also, all three of the main browser JavaScript engines (SpiderMonkey in Firefox, JavaScriptCore in Safari, and V8 in Chrome) contain JavaScript compilers.

    Anyway, the problem you identify isn’t that there are no JavaScript compilers – it’s that the main use of JavaScript (browsers) doesn’t specify a common form for distributing that compiled code. That’s not entirely true, however: there is Google Closure, which compiles JavaScript to an intermediate representation which can be used by browsers – it just turns out that that intermediate representation is itself JavaScript:


  27. “Class-based OO can offer the developer features such as static methods, abstract classes, interfaces, method overloading and operator overloading.”

    These are also limitations of class-based OOP that prototype OOP eliminates the need for.

  28. I think every language has their own problems. You just have to be strict when you writing your programe to avoid those bad bits.

  29. I totally agree with you David, I think Javascript is a toy language. I will change my mind when I see the latest 3D game or application like Photoshop written in Javascript. I’m not as much of an expert in the field of programming as many guys (or girls) around here seem to be but without memory management and loose variable typing how could Javascript ever be considered a powerful language?

    I think PHP is much better except it too has some loose typing which makes its classes far less powerful than they could be (overloading methods and templates would be nice). As far as I’m concerned C++ is one of the best languages around but C# and Java are good modern languages that are alot neater even though they’re slower. Javascript has its uses but I think it’s a pretty weak language and is not even in the same league as the heavyweights I’ve just mentioned.

  30. Another agreement. If JavaScript is the eventual locked in language of the web as it’s shaping up to be then it’s a sad turn of events.

    The idea of a common VM is a great one and something that half of the JavaScript defenders above totally missed the point on. While people can argue it’s not a toy citing widespread use or whatever else – It will always be a mediocre mash up at the mercy of the painfully slow standards process. I’m all for the end of proprietary VM’s embedded in browsers but I’ll gladly keep them if it means keeping Java and ActionScript on the web. I’m not saying they’re better (just thinking it) but they are better suited for many purposes as we can all agree one language never fits all. Sadly the web may become one language.

  31. I have programmed similar projects in Javascript and Silverlight/Flash and I would recommend the latter. The main reason for this is significant reduction in development time and also reduced debugging/maintenance cycles.

    The main advantage of Silverlight is separation of presentation from code via the MVVM design pattern. This makes code much clearer and the UI can be finally be designed by someone with artistic rather than technical experience. This is seperation of concerns extended to specific human talents.

    No more time writing different code for different browsers which depend on a multitude of different abstraction layers to hide the language and browser incompatibilities.

    With Silverlight every bit of programming is done with c#, even the client code. That makes Silverlight a quicker and clearer technology for the average computer programmer to employ. Also everybody in the web development team talks in the same language (English) so there are no conversational attitude problems or philosophical arguments in the work place to further hinder the development effort.

    The main reason Javascript is so popular is because Google and Apple had no real option but to push it as they were streets behind Adobe and Microsoft in the rich internet application technology market.

  32. I agree with this article, coding javascript is akin being a person with no principal. Corroboration between humanity was achieve by fellow humans who have common benevolent principal and understanding.

    In javascript, there’re too many ways of doing one simple feature. There’re no common rule for code re-usability and there’re no principal in the language. Its more like a language in anarchy.

  33. IMO, JavaScript is a great language that has stood the test of time, keeps improving, and is being adopted on a growing scale for client and server side processing. If you like .NET and Microsoft…Windows8 Metro Apps are being developed mainly with HTML, CSS and JavaScript. If you like Mac, all the cutting edge development is being done with node.js. If you want compilation…now you can write CoffeeScript that compiles to JavaScrpipt.

    While admittedly, there usually are several ways to go about solving the same issue, I have seen this is many cases in very ‘sophisticated professional’ languages including .NET. There are design patterns and many different reasons to use each. I don’t know, I’m still learning, but JavaScript ain’t going away, and I’ve found it very useful for data binding, manipulating the DOM, client side data validation, providing rich user experiences, giving users feedback without a post back from the server, etc.

    I’m not saying you have to love it, but it is a part of the future of the web and I dare to say many non-web related software and applications. The more you understand the language, the more you appreciate it.

    I think that frustration and hatred of anything usually comes from a misunderstanding. If you are a JavaScript expert, I think you have every right to make claims like this, but if your not, I would try to gain a better understanding of the language and the ways it can work for you, rather than trying to work against it.

Comments are closed.