The Case For and Against JavaScript, and a Potential Solution

The case against JavaScript is fairly simple. As a language it employs arcane and to the uninitiated meaningless syntax. Structurally it’s a mess. The lack of type safety puts data at risk. It is being utilized as an ‘object language’ without any sensible structures that make creating and using objects easily doable or readable. Even as a scripting language, it’s among the worst available. Finally, the structural and syntactical issues make writing decent tools next to impossible.

The case for JavaScript is equally simple. Due to happenstance its inclusion into Netscape and subsequent generalization to other browsers has made it the only language interpretable by most browsers, which are the vehicle of choice for software UI delivery to end users. As a result, no matter how disliked it is by most developers, there isn’t much in the way of a significant alternative when deploying code that web browsers need to execute. Over the period of web application development, most of the code that web browsers need to execute is UI related, and as a result the main population familiar with JavaScript are designers, whose focus is on design, not on the minutiae of writing decent code.

Now, you might say that JavaScript is “just another programming language” and to some degree the notion has merit. Tools don’t make a product, they just make it easier or more difficult to make the product. That good products and frameworks have been written in JavaScript is sufficient demonstration of the notion. From a developer’s perspective, though, the annoyance factor makes it less attractive to take on a role as a JavaScript developer, and developers are usually only convinced to take on less attractive roles via a more attractive pay rate. The shortage of accomplished developers relative to the need, originating out of the combination of a large percentage being primarily designers and the rest being redirected from better programming environments, causes the going pay rates to be even higher. Adding the general difficulty of programming efficiently in JavaScript, and debugging quickly, and to get good JavaScript done winds up taking many more hours, usually at a significantly higher hourly rate. It doesn’t take a business guru to figure out that this isn’t good business, assuming there was any alternative.

The emergence of Node.js, with extensions such as dojo, Express.js and Kraken.js makes JavaScript a viable language in which to write server facades, usually to back end services written in languages with more extensive and reliable ecosystems such as Java EE or C++. From the business perspective, there’s nothing gained technically that couldn’t be accomplished via other means, but it is being touted as a way to ‘force’ server side, code focused developers to learn JavaScript, where the skills obtained can then be reused to make the client side code better than it generally is today. However this is rather like forcing wheat farmers to use a hacked lawn mower instead of an advanced combine so that they will do a better job of landscaping the front lawn. One would think there has to be a better solution.

There are of course other solutions to writing the UI for a web browser, full event driven frameworks like wingS, Eclipse RAP and to some extent JSF suffer from the problem that since most of the actual code is being run at the server, supporting a large user base requires server hardware and bandwidth that makes IBM and Oracle salesmen foam at the mouth, and pushes broadband providers to rethink not putting in terabit connections to the desktop this year. Solutions such as Seaside, Rails and Grails have the problem that, while they may integrate with one or two major frameworks in the JavaScript ecosystem, that ecosystem is itself changing too rapidly for them to continually integrate every ‘cool new library’ that comes out. Syntactic sugars on top of JavaScript such as CoffeeScript generally are more difficult than JavaScript itself in terms of integrating new libraries, and cause limitations in trying to accomplish anything beyond the relatively simple.

I have been looking for a solution based on a different paradigm. Retaining JavaScript as the deployment vehicle is a necessary evil, but developers focused on the convolutions of JavaScript, no matter how knowledgeable, are by definition at least partially focused away from solving the users’ and business problems they were hired to solve. Writing in a language that permits that focus, while deploying in JavaScript, is the ideal solution, but that language cannot limit either the basic capabilities of JavaScript or the ability to use other JavaScript frameworks and libraries.

The only solution I’ve found that meets all these requirements is a language known as Amber. Amber is a dialect of Smalltalk. Now before you jump to the conclusion that since Smalltalk isn’t new, it can’t be a solution, Ruby is syntactically and structurally nearly identical to Smalltalk, but with the caveats that it isn’t properly virtualized, has no decent tooling and a paucity of libraries. Like the main dialects of Smalltalk (and unlike oddities like GNU Smalltalk) Amber is written in, well, Amber. A small bootstrap loads the very basic VM, and from there Amber objects are built out of Amber objects. However Amber compiles to fairly efficient JavaScript (more efficient in fact than many JavaScript programmers manage to write manually) and so runs either on Node.js, or within the browser execution environment, precisely as JavaScript. As well, it is capable of using a simple JS require to import any JavaScript frameworks or libraries and expose them as Amber Smalltalk objects. The base environment includes all the usual Smalltalk tools, including a class browser, workspace, transcript and debugger, and include a version of SUnit, the unit testing framework that led to JUnit and all the other -Unit test frameworks.

So what do you gain from writing JavaScript in Smalltalk? You get a language as fully dynamic as JavaScript itself – code changes reflect immediately in the browser environment or on the Node server. The Smalltalk tools themselves all run within the browser, since they are written in Amber Smalltalk. You get the type safety of Smalltalk objects, the structure of the purest object language there is, and a terse but highly readable syntax that makes programming both efficient and enjoyable. From the developer’s perspective, unless you feel ‘cool’ writing unintelligible code, it’s an ideal situation. There’s no additional danger in writing business logic in Smalltalk versus other object languages, so code written in Amber can do more than simply allowing a more dynamic user experience

From the business perspective, developers familiar with object languages such as Java, Python and Ruby can learn Smalltalk pretty quickly, and more importantly write good code in it, which is the more significant issue with JavaScript. Companies that have based their internal coding on Smalltalk have historically had lower overall development costs even compared to relatively well structured languages such as Java and Python, when compared with JavaScript the cost differential is liable to be massive.

Now the expected caveat. Amber has been developed by a small team over about three years. Given the small development crew and short time span, the efficiency of Amber is already demonstrated by the stability and usability of the system as it already is. In order to develop it further, particularly in terms of ensuring it remains stable in more highly scaled environments, companies wanting to use it need to have a reasonable expectation of contributing development time to the project. This is already the case, though, in JavaScript, and in other language ecosystems such as Java and Python, and shouldn’t be a significant barrier. The main barrier, as it so often is, is visibility and awareness of what it can do.


Amber can be looked at, instantly tried out, and downloaded from . Thanks to the people involved with it for developing such a great environment.




Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s