JavaScript is sweeping the development community and is popping up everywhere, having broken free from the confines of the browser. We see it at the server side, embedded inside programs, powering mobile apps and we even see it popping up inside of games. However, we are creating a huge headache for developers and companies in the future, because JavaScript was never designed to take on this scale. It isn’t a proper language.
Now that I have your attention let me begin.
JavaScript burst onto the scene back in 1995, when Netscape released it as LiveScript. It was quickly renamed to JavaScript with a shorted sighted view of hooking into the popularity of the other new language at the time, Java. The name stuck and nearly 20 years later, is still proving to be a constant source of confusion for beginners, managers and recruiters.
Java is a fully typed, compilable language, whereas JavaScript is a dynamic, scriptable language. They both have Java in their name, but there-in the similarities end. They are no more alike than C++ is to Ruby.
JavaScript is a beautifully powerful simple language. There is absolutely no barrier to develop solutions with it. No compilation, no fancy deployment phase, just save the file and hit refresh/reload and by’n’large you are good to go.
For the most part JavaScript is absolutely fine, sprinkled into web sites to create a much richer experience to the application. If it was just limited to that, then there wouldn’t be so much of a problem. The problems come when you attempt to do anything large and complex with JavaScript. The code becomes quickly unmanageable.
The language itself does not impose any sort of standard for code creation. You can have everything in one big file if you want, or even in one long line if you really are perverted. There is no official way to create objects, instead a pattern is semi agreed on to be adhere to – “More honoured in the breach than in the observance”.
There is no type checking going on to make sure what you are about to call is indeed still there and is still expecting the type of data you are about to pass to it. You can’t be assured of what type of data is coming back, it could be anything.
Scaling JavaScript up beyond a single developer starts to show its weaknesses. No one likes to go into JavaScript code to start enhancing or fixing. The opportunity to break existing functionality is huge, and here is the kicker, you won’t know it until that particular line of code gets triggered by the application. A single stray semi-colon can bring down a complete system.
This is an intolerable situation for the enterprise. The code the enterprise produces has a long shelf life compared to the code of startups and most web sites. Many developers will cycle in and out of the project/company and this code needs to be maintained, added to and ultimately supported for many years to come.
There are huge amounts of work being done in this space to start to get a handle on this problem. Many projects are popping up to give JavaScript, type checking, mock compilation, function look ups to try and get ahead of these fundamental problems.
Yet that isn’t enough.
JavaScript has another problem lurking in the background which is potentially even more serious. Because the barrier to entry is next to nonexistent, anyone can dabble in JavaScript. Literally anyone.
It look’s so easy, that non-software developers who have not trained and have a deep understanding of the cause and effect of software design are producing large projects under the illusion that everything is working beautifully. Their lack of discipline coupled with the loose structure of JavaScript is a recipe for disaster when it comes to writing code for maintainability and longevity.
“JavaScript makes it easy for anyone to write vast amounts of monstrously unreadable, undebuggable, impenetrable code.”
Ken Scott – Answer at Quora
We’ve seen this before.
1991 was the year Visual Basic burst onto the scene from Microsoft. This powerful drag’n’drop programming didn’t even start out as a true language, but Microsoft decided to add Basic to the company it bought, Tripod, to which Visual Basic then became. Visual Basic revolutionized the computing landscape, and while it was officially retired in 2005, it’s legacy is still powering a vast array of crucial applications and corporate tools world wide today.
What Visual Basic did was to let anyone build complex applications by simply drawing on a canvas, tying components together and before you knew it, you had frontends to databases and systems quickly evolving. Everyone got in on the act. From the spikey hair boss, who fancied himself a developer, to the youngsters in their bedroom, Microsoft made it really easy to do great things.
That is no bad thing, however, what it did, was to create huge amounts of legacy spaghetti code that goes largely unsupported. While you may have a VB app running away, it is slowly eroding as no one wants to crack open the source and start making changes. It was code that was hacked together by those that didn’t really know the techniques of the trade. Microsoft convinced legions of companies that real software engineers weren’t needed, and if it couldn’t be done in Visual Basic then it wasn’t worth doing.
Microsoft was not alone as others got in on the act too. PowerBuilder, Delphi, Paradox are ones that spring to mind that had a similar drag’n’drop concept.
JavaScript I contend is even worse than Visual Basic in the legacy it is producing for us in the future. The applications written with JavaScript are far more fragile than the VB apps that were produced with a few clicks and drags of a mouse.
JavaScript isn’t going anywhere soon, if anything, it is spreading further and wider.
So what is the answer?
I don’t believe the answer lies in tooling. Tooling will only help the situation, but anyone with a text editor can easily bypass any rules or laws the tooling is hoping to enforce. Discipline and code review in following the guidelines and laws set out by companies will get you only so far too.
The answer I believe lies in looking at JavaScript not as a language, but instead as a runtime, an instruction set if you will. What if we view JavaScript’s syntax as the bytecode of a virtual machine, with that bytecode being produced by a compiler, from a language that supports and enforces strong type/function checking.
There is a reason why very few people write actual machine assembly language these days – it is too darn complicated and prone to easy mistakes. It has a very loose structure too, with complete power to do anything in the system. You can’t get much closer to the CPU. However, assembly is not the language you want teams of developers producing. It is too low-level.
JavaScript should be treated with the same respect as assembly. It is a truly wonderful runtime, that has democratized the differences in computing platforms by providing a virtual machine that has a known set of characteristics and behavior. However, JavaScript is just too dangerous and powerful to be put in the hands of most developers. It is too easy to make colossal mistakes that could cost large amounts of money and now it is going to embedded devices, lives.
Instead let us use a strongly typed, object oriented language that can compile down to JavaScript. This allows us to utilise all the compile checking that goes on well before we have to execute a single line of code. No one has to touch JavaScript code directly again. The tools support for these type of languages far out passes anything that can be provided for such a loosely coupled language such as JavaScript.
I am not alone in my thinking here. Google has been producing JavaScript with its GWT project for over 7 years now. Now JavaScript has reached mainstream, GWT is gaining popularity and a renewed interest. GWT allows you to code your web applications in Java, with all the usual checks and balances that any Java application brings. But instead of distributing .class files, GWT takes those .class files and creates JavaScript code that can then be shipped to the browser for execution.
GWT isn’t the only horse in the race, there are other projects that attempting to use Java as the source with JavaScript as the output.
I would much prefer to have a team of developers support 1 million lines of Java code than 1 million lines of JavaScript code. I also get the advantage of future compiler optimizations free of charge. The Java-2-JavaScript compiler can evolve and produce faster and smaller code at a completely different rate than the top level application. I don’t have to change any of my application code to take advantage of this.
JavaScript is a powerful language that has enabled some beautiful applications to exist. I believe it has a huge role to play in our computing space as we evolve to build better and greater solutions to our problems. But let us not get caught up in the hype and produce unmaintainable code for generations to come to have to support.
Let us instead see JavaScript for what it has done, which is to give us a truly virtual platform to run our logic upon, whether it is a browser, mobile device, embedded or the server side. Leave the actual production of JavaScript to highly optimized compilers/convertors that can do far better than a human, while removing the headache that a loosely typed language brings to the developer.
Who knows, we may actually put the Java back into the meaning of JavaScript after years of confusion and misrepresentation.
References
alan williamson 