On Javascript…


So, a couple of days ago I had a good discussion on Twitter with a developer that I respect regarding the future of JS. This was in response to this article, which basically suggests that within the next few years JS will become the defacto programming language on both the client and server. Now, I’ve read that article, and re-read it, and re-read it again. I still don’t agree with it. Let’s discuss both client and server sides as separate entities…

Javascript on the client

There are already three programming languages out there that compile down to JS – CoffeeScript (CS), TypeScript (TS) and Dart. Dart has slightly loftier goals in that it sees itself in the long-term as a complete replacement for JS, with it’s own interpreter / compiler in the browser, but in the short-term it fulfils the same purpose as the other two. CS uses a completely different syntax to JS, whilst TS is a superset of JS, meaning that the barrier to entry is extremely low. At any rate, the fact that these three languages exist tells us something – that JS has problems writing large-scale applications. It has poor facilities for abstraction, module discovery and generally for reasoning about your code that allows you to do simple things like rename a variable with any degree of certainty. Developers at places like Google have had to come up with ridiculous naming standards of variables and classes etc. to allow people to infer scoping or usage of types etc.. I thought we dropped Hungarian notation with it’s szCustomerName ridiculousness for good in the 90s, but evidently not.

So where am I going with this rant? Simply that whilst JS will almost certainly stay as the most popular language that web applications run on, it won’t be the dominant programming language for developers. I certainly wouldn’t want to write the next Facebook, Gmail or whatnot in plain JS. It’s a nightmare to maintain and, without basic constructs like interfaces, classes and modules doesn’t easily allow for organising code into manageable chunks. I’m not saying it can’t be done, but it involves lots of extra work by the development team – things that should be given to us by a modern language (cast your mind back to what JS was originally designed for – it certainly wasn’t to write Google Maps).

Javascript on the server

On the server-side things get even more bizarre. For starters, not only do you have all the same issues as above (which in todays world are likely to become even more of an issue as big data problems get both more complex and commonplace), but a whole host of other issues rear their head.

Firstly, server side applications tend to be much more mission critical than a front-end application from a data point of view. A bug on your website may only result in displaying some data incorrectly – this is a transient issue that can be fixed with no permanent damage. Conversely a bug on the server may end up actually calculating the wrong data and persisting it to your data store. Because of the nature of server-side applications, you might not even notice this until much later. Indeed, with JS, issues like accessing the wrong field because of a typo don’t cause a runtime error – it’ll just carry on happily. More so, with the relatively immature nature of JS testing frameworks, these sorts of errors might be even more prevalent. And I don’t want to generalise too much, but how many front-end JS developers would be confident writing a server-side application in a test-first manner?

What about features that you would expect to see in a language that was going to be used to write a mission-critical server-side application? How about excellent multithreading support? No, wait, how about any multithreading support? What about simple to use and powerful asynchronous support (I’m talking like that in C#, F# and I believe Python have now)? The ability to know with certainty where a particular object is being used? I just don’t understand why you would want to give up all of those language features, let along features like test frameworks – or tooling – that people have grown accustomed to.

How about performance? I’ve already mentioned about multithreading. An application that deals with large amounts data these deals may need to push data out onto multiple threads for work, or going forward even onto multiple machines. The latter is a framework / tooling issue, so slightly out of scope, but at the core language and runtime level, this is something you’ll want. On a side note, I’m not a compiler designer, but Lars Bak, who leads the Dart project, is. How much optimising can you do on a compiler for a language whose type system cannot distinguish between an integer and a floating point number? This is precisely the sort of issue you get working with a simple type system like JavaScript.

Conclusion

I worry about people that believe that JavaScript is the language of the “future”. There are many things that are popular – this doesn’t necessarily make them the “right” thing to do – or even a “good” thing. Or maybe it’s a good thing in certain circumstances, but not others?

 I would be more concerned as a client or project owner about a team writing a system in JavaScript rather than in something like TypeScript – even if they aren’t JavaScript experts. I can personally vouch for this because – and I come from a C, C++ and C# background – whilst I’ve struggled to feel comfortable with writing raw JS, I’m happily productive in writing in TypeScript. I feel more confident about my code. I feel happier with the results, and I get the right thing done in less time. On the server these days, I use F# and C# whilst in .NET. Whilst going back to C# from F# feels like a little bit of a step back – going back to JavaScript would feel to me like a going back to the days of Visual Studio 2.2 and straight C – no thanks.

TypeScript exposes some irrational Microsoft hatred


Just watched a couple of videos on TypeScript – basically a Microsoft-developed (but open source) superset of JavaScript which compiles into plain old JS that gives you a type-safe environment to write JS. Unlike stuff like Dart or Script#, because it’s a superset of JS, you can easily opt-in to bits you want; it integrates without any issues with existing JS like Node.js or JQuery.

Initial thoughts of TypeScript

Firstly, coming from a .NET developer background, my first thought was that TS reminds me of F#! By that I mean, first it builds on top of JS to give more functionality in a similar way that F# builds on top of the functionality of C#. Ironically some of this is accomplished by “removing” functionality e.g. static typing, just like F# introduces immutability which initially seems like a restriction but actually is a boon.

The type inference also reminds me of F# is that the output of methods is inferred from the return type from the method, or how you can define fields within the constructor directly. In fact, it makes me wish that C# had better type inference – and it just goes to show you can do more powerful type inference without more CLR support.

All in all, it looks very nice – basically gives you more intellisense, refactoring opportunities e.g. rename, lambda expressions, implicit closures etc. which are very C#-like.

Initial thoughts of TypeScript – with feeling

This is all good. Yet I’ve already read an incredible amount of emotional, uninformed spouting about it. I’m not referring to the actual articles in the links here – although the Register one isn’t quite as accurate as I’d have liked, talking about “extending JavaScript” in the headline which isn’t quite right. They’ve written a new language which itself is a superset of JS. They’re not writing an MS-only version of JS.

Yet there are many comments on the following tangent: –

  • It’s from Microsoft. Ergo, it’s crap.
  • It’s from Microsoft. Ergo, it must have some hidden nefarious purpose.
  • It’s from Microsoft. Ergo, it won’t be secure.
  • It’s just another Dart. What’s the point. Oh it must be competing with Google for the sake of it.
  • They’re trying to lock me in to the Microsoft tool-space etc. etc.
  • Static typing is crap.
  • This will just fragment the JS community by creating a different version of JS.
  • I can write JS directly, what do I need this for?

What a load of tosh! Anything that allows me to refactor a method or property name easily, or gives me intellisense for exploring an API is definitely a good thing. It doesn’t affect the runtime – it’s still spitting out plain JS. It doesn’t require me to learn lots of new things if I’m a JS developer. The language builds on top of JS – so you can opt-in for the bits that you want. It’s open source. What’s the problem?

Of course – it’s written by Microsoft.