JavaScript is a toy language, but that is a good thing

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

Nearly two years ago, I wrote a post entitled “JavaScript is a toy language.” It proved a controversial post, which – with hindsight – I should have expected. Two years on, much has changed in the programming world and much has changed with my position on JavaScript. So I thought it time I revisited the topic.

JavaScript remains a toy language
First let’s get one thing clear: I stand by almost everything I said two years ago about JavaScript. It isn’t an OO language (it’s a prototype-orientated language that supports object-based inheritance) and it isn’t a functional language (it is a prototype-orientated language with limited functional features.) It contains a great many flaws that cause developers a great many problems (everything is global by default, there are no namespaces or packages and quirks of the language render features (such as the “==” operator) near unusable.) However, the one thing I do now view differently is my claim that it isn’t fit for purpose. The reasons for this change are the motivation behind me writing this post.

Toy languages aren’t all bad
Proponents of software craftsmanship often rave about dynamic languages. Ironically the reason they do this is not because dynamic languages are inherently better than static languages, but for the exact opposite reason. Because dynamic languages cannot detect so many errors at compile-time as their statically-typed cousins, one needs to be more disciplined over testing. Good dynamic-language-based applications and libraries are therefore tested with extensive unit, integration etc tests. The lack of compile-time checks positively encourages this must-write-tests attitude. It’s a line of argument that I find odd and it has taken me a long time to come to accept it. Spending time with ruby developers though has changed my mind recently.

JavaScript is both dynamically typed and loosely typed. This means it will implicitly cast between types on the fly. Whilst dynamic typing can be a source of bugs, it is as nothing compared with loose typing, especially with a language like JavaScript, where the rules on type conversions are so muddled and inconsistent (see wtfjs for some examples.) It should therefore come as no surprise that the JavaScript world is awash with TDD and BDD frameworks for use by the more professional developer. There are also syntax checkers available – such as JSLint and JSHint – that statically analyse code to help find errors before the code is run. Books like “JavaScript: The Good Parts” complete the picture by helping to guide developers toward the better parts of the language. By itself, JavaScript is in many ways not fit for purpose, but a lot of people have put a lot of time into providing tools and resources that support developers in making it a better fit.

Lego is a toy too
I used the term toy two years ago quite deliberately as I was seeking to be deliberately disparaging toward what I saw as a rubbish language. In recent months though, I have started to wonder whether it being a toy is a problem. Lego is a toy. Kids play with their lego bricks, creating great works of fantasy. Lego has a serious side too though. Technics and Mindstorms lego can be used to teach engineering and robotics ideas and to help people learn to program. This toy can be used to build a “3D printer” that can build more lego creations from CAD drawings. People have even built working “Babbage difference engines” from lego pieces.

Toys can have serious sides. This is clearly true of Lego. Having experimented with JavaScript more and more recently, I’m coming to the conclusion this applies to JavaScript too.

Toys are fun
Last week, I read something that really brought home to me what is good about JavaScript. I have been getting excited about JavaScript recently despite it being such a crappy language. The reason for this is that the community around JavaScript is so alive, active and enthusiastic. The article “Is Programming Less Exciting Today?” really clarified this. Sure, if you are mainly writing eg Java code, programming will seem less exciting than in the past. The reason why JavaScript is doing so well is because it is fun. Being fun seems to have become overlooked by many languages. Being paid to have fun is why many people indulge in a development career though, so it is an important omission.

Imagine you are just setting out learning to program and you are going to learn Java. You attempt to write the cliche “Hello World” program. To do so, you must download and install the Java SDK, then write code containing imports, a class and a static main method. Then you run the compiler to turn it into bytecode and then use the JVM to run it. Seriously ask yourself, is that your idea of fun? With JavaScript, write the following

to a .html file and open it in a browser. Job done.

Such simplicity encourages people to play with the language, to explore it’s abilities and laugh at it’s stupidities. In the process, that person starts to become a developer. There is plenty of time later in their career for them to be taught SOLID, testing strategies, static typing and many other tools of the software professional. We shouldn’t forget that playing is the best way to start learning.

JavaScript is a fun toy for kids (of all ages!) to learn to program with. Thanks to an enthusiastic community around it, it is also a tool that can be used to write well crafted, professional applications. JavaScript is a toy language, but I have come to the conclusion that this is a good thing…

5 thoughts on “JavaScript is a toy language, but that is a good thing

  1. I do like the fact that after listing a whole host of faults you then say this is “fit for purpose”, surely this is an oxymoron (or something similar, I never really got to grips with the English language).

    Also programming is fun and always has been, even before computers were invented learning about the turing machine, definite finite automata and the like still floats my boat and is STILL the basic foundation for solid understanding of programming principles. Recently a friend asked me to teach them how to program they had some things working and wanted to know how to make them better. Looking at the code it was a mash-up of code copied from many different google searches slapped together with some bailing twine and sticky back plastic that had been “nailed in the upright position”. In a word it was bad, unmaintainable and worked in a very limited number of cases. I’ve seen a lot of this working with contractors that are so eager to earn money and move onto the next project that they never see the destruction chaos and mayhem that they leave behind. Yes people should be interested in being able to make cute little games with minimal effort and this is where javascript comes in, the trouble is that when a toy (such as lego) is then used to solve real life problems the temptation to stick some shit together is overwhelming.

    javascript is a toy language, toys are for children, when I was a child I thought as a child played as a child and programmed as a child, but when I grew up I realised it was time to put away childish things. 🙂

    I do like javascript, but everything in its place, cute quirky web apps and nice slick gui components YES, but a web server HEEELLLLLL NNNOOOO!

  2. Do you really believe you have to make programming trivially easy in order for in to be fun (as your “Hello World” example suggests)? Anyone who thinks the Java version is just too much effort should probably be looking for a career in management or hairdressing.

    The argument that a poor language choice will force one to write better crafted code is more full of holes than an Italian cruise ship.

  3. I suspect The Boss has missed the point a little. To continue the lego analogy, lego is great for exploring alternative ways to solve a problem, or meet a specific design goal. It is used with reasonable frequency for hardware prototyping because it’s cheap, flexible and easily available.

    Similarly, it is the “trivially easy” features of JavaScript that makes it far more suitable for exploring new solutions than, for the sake of argument, Java. Low cost of implementation leads to a lower cost of disposal. Frequent disposal can lead to far better solutions than the mistaken assumption that all problems can be defined and solved up front.

    But, the fictional programmer in my head may say, then any sane coder would want to re-implement the hacked JavaScript solution. I don’t see any lego cars on the road.

    Not so, I retort. The beauty of JavaScript is that it’s flexibility means that it is also flexible enough to be restricted. It generally seems to be the case that writing code to restrict code/program behaviour takes less time than writing code to make it more flexible (compare, for example, code to restrict values in a type to implementing a new type).

    Finally, the fun part becomes very important for the (nebulous term alert) vibrancy of a language. If it’s fun to program with, it’s fun to explore with. From that I’d say it’s reasonable to propose that a fun language will have a broader range of good and bad solutions known. More choices of known solutions are, I would say, a very good thing. Programming problems of a non-trivial scale are rarely identical. Having more fodder for thought processes is good. Otherwise everything is a nail and the language is the hammer.

Comments are closed.