One of the most popular blog posts in 2014 was Developer inequality and the technical debt crisis with Jonathan Edwards presenting a rose tinted view of the good old days of archaic languages, moaning about the dark age of the web, and claiming it is responsible for a technical debt crisis.

This was the spirit of languages like COBOL, Visual Basic, and HyperCard. Elegant tools for a more civilized age. Before the dark times… before the web.

How many people, whether they be professionals or amateurs, really want to go back to this?:

These primitive tools still exist in both old and newer incarnations. It’s just as easy if not even easier to create a basic calculator, Celsius to Fahrenheit converter or other simple app in modern VB.NET or C# as it was back in the 90’s. But in these “dark times” of the web, these programs are not only available for free, they only take two or three seconds to find using your favorite search engine.

For a long time non developers have found they can create simple programs themselves in Microsoft Office with VBA. However what has always been the case is as a program becomes more and more complex, it requires more structure and more knowledge about good principles and practices in order to adequately manage that complexity. It has always been relatively easy for anybody to create simple applications and significantly harder to build large applications and this is something that I don’t believe will ever change.

It will also always be the case that all programs start of very small and continue to grow. Unfortunately, non developers often don’t realize how large their programs are going to get, and when the time comes that they need to get a professional in to help, the program is in such as bad state that it’s in need of a full rewrite. Now that is a real technical debt crisis!

Old programs in old languages such as COBOL led us to the Y2K bug, and continue to be a huge maintenance burden for thousands of companies who weren’t savvy enough to gradually modernize them before they turned into white elephants.

Jonathan states “it takes a skilled programmer with years of experience just to build simple applications on today’s web” however websites are now easier to build than ever. Blogging platforms such as WordPress allow any beginner to create a site within minutes and there are more and more widgets allowing drag and drop functionality without the need for any coding knowledge whatsoever on the part of the author.

However it is very true that JavaScript is not easy and does need to improve. The original version of JavaScript was created in just 10 days, and is widely considered to be, at the very least, a language with many bad parts. In fact it’s often described as terrible!

As an illustration, compare the size of the good parts with the book that covers both the good and bad parts:

Actually even JavaScript The Good Parts spends 8 pages on Appendix A: Awful Parts and 6 pages on Appendix B: Bad Parts. The 10 pages on JSLint are also essentially a guide to avoiding the bad parts.

“JavaScript’s popularity is almost completely independent of its qualities as a programming language.” – Douglas Crockford

The very best, most hilarious illustration of some of the problems of JavaScript is Gary Bernhardt’s WAT lightning talk, which is just 4 minutes long in total, and moves from Ruby to JavaScript at around 1:30 in. If you haven’t seen it watch it now!

“Don’t throw anything at me! We’re doing our best to make it better” – Jafar Hussain, TC39 (JavaScript standards) rep

Despite the problems with the language, there has been a huge rise in popularity of JavaScript and I can only see this continuing. The language today is viewed quite differently than how it was 10 years ago. In Code Complete 2nd Edition Steve McConnell wrote:

JavaScript is an interpreted scripting language that was originally loosely related to Java. It is used primarily for client-side programming such as adding simple functions and online applications to Web pages.

Several new technologies mean JavaScript is now much more than this and can be used for large enterprise web applications.

Because it takes quite a lot of effort to write applications using raw JavaScript, there are frameworks such as jQuery that build abstractions to let us achieve more with much fewer lines of code. However there is no such thing as a free lunch and you need to be aware of the pitfalls.

In a great talk by Yehuda Katz at RailsConf 2014, he discusses the Paradox of Choice. In essence we all love having choice, but we don’t like having to choose, especially if it is a very difficult choice. Having to make a lot of difficult decisions can really sap our energy levels. Yehuda talks about the common mentality of wanting to feel special and use special tools and how it has impeded the progress towards better shared tools.

The LAW of leaky abstractions. Any time somebody couches an observation about software development as a LAW, you know something fishy is going on.

Shared abstractions are a necessary and essential part of progress for our industry. But what we need to avoid is having a big pile of hacks. In order to fully identify the useful abstractions from the less useful ones requires many users carefully evaluating over a period of time.

Eventually the community realizes that we hardly ever need to worry about the layer below anymore. The top layer of abstraction is the area of experimentation. New abstractions need time to mature before any one can be accepted as a standard.

In 2015, we are at the beginning of the HTML5 era. We have a huge amount of competing JavaScript frameworks and also a ton of transpilers creating a huge paradox of choice for JavaScript developers.

While there is a need to maintain some amount choice, too much choice isn’t just off-putting for beginners, it wastes a lot time for professional developers as well. Instead of having to spend time and money researching and evaluating different frameworks against our project requirements, we should be in a position where we know enough to get started coding right away.

This is a large project that I am working on at http://www.zombiecodekill.com/JavaScript which contains an A-Z of all major frameworks. I will be gradually evolving this to include more and more valuable information.

Update 30th August 2015:
I’ve just seen the talk
JavaScript: State of the Union by Geoff Schmidt. This is a very good explanation of why JavaScript is so important. It’s rare to find a talk that is both honest about its flaws and insightful about how it has come to be so dominant.

He says creating connected client experiences is not just about saving some money, but about company survival. Many companies delivery old website experiences look so primitive compared with Apps like Facebook that customers are moving away from using them.

JavaScript has 4 characteristics that almost guarantee that it will continue to dominate:
– Easy (see here for my personal take on this one)
– Ubiquitous
– Performant
– Well known

Based on this Geoff argues

JavaScript is the only reasonable language for cross platform all development

I think this argument explains a lot of the changes Microsoft have been making for ASP.NET 5. The tables have turned and we are now seeing traditional server technology having to play catch up. The whole direction of Microsoft has changed to show that their technology is a good choice for cross platform development – something it never cared too much about until recently.

This year I have been finding that the typical way that ASP.NET MVC is used to render HTML doesn’t deliver a good enough user experience and have been using it to render JSON more often. I’m also using Web API controllers instead of MVC ones just to ditch a little of the heavyweight clunkiness of ASP.NET MVC (MVC 6 can’t come fast enough for me).

I often find the best parts of ASP.NET MVC are its use of unobtrusive JavaScript, but we’re often much better off working with the raw JavaScript than with simple cookie cutter frameworks.

I still believe that traditional server side languages remain important, but running JavaScript on the server as well the client is a good choice for many companies.

One area where I think there needs to be a lot more work in is security. It’s really difficult to write a fully secure sophisticated web application even with the help of tools such as Auth0.

In the Universal JavaScript area I haven’t yet seen anything with anywhere near the kind of maturity that exist on top of the big traditional server side languages. Dynamically typed languages also offer hackers more attack vectors than statically typed ones.

The analogy Geoff uses of server side platforms being like cars and JavaScript being like planes is excellent for a different reason for me. We still have too many car accidents but that doesn’t stop everyone looking up at the sky and deciding they want to fly a plane.

The only difference is you don’t need a licence to code JavaScript!

Other things that I find very far from enterprise quality are the number datatype and date object which remain just as awful in ES 2015. I would not want to based any financial application or a worldwide GPS system (which I work on) entirely on a language that cannot correctly add 0.1 and 0.2 together, evaluates new Date(0,0,0).toDateString() as a valid date of “Sun Dec 31 1899”, and automatically jumps forward and backward and hour for datetimes between daylight saving times.

“When it comes to Daylight Saving Times, the JavaScript date object is assumptive, inconsistent and downright broken” – Matt Johnson

I’ve since learned that the Big Number library is very useful for doing accurate calculations. The same author has also written Decimal.JS, which contains a number of trigometric functions.
For working with date times, the most well known library is Moment.js.
I love these highly focused libraries, and I wish they would make it into the language itself.

So despite the language issues, watching the State of the Union talk has made me realise that this “terrible” language, JavaScript, has now become my favorite dynamic language.

I think this is why we are only currently seeing Node JS used successfully by the biggest companies. They have the very large budgets to write nearly everything in house from scratch and never compromise on quality and proper planning. For smaller companies, we don’t see the same returns that the efficiencies of Universal JavaScript give us and we are better off sticking with our traditional server side languages. Technologies such as Signal R give us the opportunity to produce fast connected client experiences without going JS only.

I absolutely agree with Geoff: what is holding JavaScript back is the lack of one clear platform. His talk is a great call to action. Unfortunately the culture of the JavaScript community has always been one of competing standards. This has served up far more ideas than I’ve seen from any other language, but most developers just want one technology that we can identify with as the best. Just trying to keep a list of frameworks and libraries up to date has been a big challenge for me. Actually knowing everyone of them is too much, even for a JavaScript specialist. It’s critical that we as a community start looking to consolidate our efforts.

I have a theory that the long term vision for Angular JS is to grow it into the JavaScript platform of the future. (Update 2016: this has now been confirmed by Google as more than just a theory).

Because of this I believe it’s very important to keep up to date on its developments, even though many developers (at least in the London area) are currently ditching it in favour of libraries such as React.

Geoff works on Meteor JS and wants to grow this into the future platform. Since this talk was given, Meteor has actually gone on to receive more Github stars than Ruby on Rails. This doesn’t mean much, but does show that the idea behind it is a popular one.

There are interesting times ahead of us.

Follow me on Twitter