That’s quite a claim! I’m sure many will disagree with me, but since this is my blog you’re going to get my rant! :)

The Problem

Over the past few months, I’ve been thinking more and more about the general frustrations around web programming in 2014. For example:

• There are more programming languages than there have ever been; yet it feels like there is no choice
• We have more experience writing code than we ever have; yet we still struggle to express our requirements in code
• We have higher level languages than we’ve ever had before; yet it feels like we’re writing more mundane boiler-plate plumbing
• We have better browser support for standards; yet it’s more work than ever to support all of our users

It feels to me that as an industry, we’re treading water. Every week there’s something new and shiny, but little that progresses the significant things that could make an enormous difference to our jobs.

No Choice; JavaScript is a Monopoly

It’s no secret that I’m not a big fan of JavaScript. It’s a hacked together mess with silly quirks and no typing. But the problem here is not my opinion of JavaScript, but one of choice…

On the server, I can write my code in pretty much whatever programming language I want: C#, VB.NET, VBScript, Python, Perl, Erlang, Haskell, Clojure, Go, C… and the list goes on. Most of those even work across different operating systems. This means I can pick the language/runtime that will give me the best productivity/stability/maintainability based on the task I’m doing. If I want quick prototyping, I can use something dynamic. If I’m writing something complex that is critical is correct, I can use something more formal.

In the browser, I’m restricted to one language: JavaScript. This feels somewhat ironic given the open nature of the web! There’s no choice here. If I’m writing a huge app with millions of lines of code and I want something that can be safely type-checked and refactored, it’s tough. Your option is JavaScript. If you don’t like it, you can limit the client-side code you write, but that will be at the expense of user experience.

Want to share code between client and server? Now you’re even more screwed, because you’re writing JavaScript on the server too ;)

“AH, BUT…!” I hear you shout. And you’re right, there is another way! …

Tools That Convert to JavaScript are a HACK

Every month there’s a new tool that will let you write something that isn’t JavaScript and convert it to JavaScript. These range from simple ideas like TypeScript and new languages like Dart to huge programs to convert .NET and even native code. Well, they’re all a hack. Hack hack hackety hack. These tools are not being built because they are a good idea, they’re being built because we’re forced into using JavaScript and most people don’t like it. As a result, they’re usually full of edge cases, varying browser support, inconsistent performance and other strangeness.

We Cannot Express our Requirements in Code

Even if you throw away all this client side nonsense for a minute, most mainstream programming languages still fail to allow us to express really common rules at compile time and force us to throw errors at runtime. There are lots of ideas out there about how we can fix it, but where’s the progress? Why is Microsoft’s Code Contracts still an unstable research project? Why hasn’t it had an update for 8 months? Why don’t more languages have dependent types? Why are there not more static analysis tools of this type? Why are even new programming languages being designed today with nullable references you can’t opt-out of?

Our High-Level Languages are not High-Level Enough

With most languages today, it still feels like I’m writing a bunch of plumbing code that I shouldn’t need to. I can easily write a few hundred lines of code across several classes to do something, yet describe the functionality in just a few short sentences. Why do I still need so much third party code to perform basic functions? For example, look at this nodejs module, exit. All it does is exit a node application in the way one would expect, after flushing standard streams like STDOUT. It’s a 41 line node module. A THIRD PARTY MODULE AND FORTY-ONE LINES TO EXIT CLEANLY!!

How can we ever talk about declarative programming when we can’t even abstract the basics away?

Browser/Device Support is Harder than Ever

Browsers implement standards better than they ever have; yet making your app work in all of your users browsers is more difficult today than ever before. Why? There are more browser rendering engines than there have ever been. Even within a single browser rendering engine, there are more versions out there today than there have ever been. IE having huge market share might have had its own issues, but was it really worse than battling with differences between IE7, IE8, IE9, IE10, IE11, IE Metro (likely multiple versions), Chrome, Firefox, Safari, Opera, Chrome for Android, Samsung’s Browser, etc.? And now let’s add in screen size and pixel density! People are trying to write media queries that use size to adjust to the screen, but it’s futile when small devices have hi-res screens and there are no clear boundaries. We need to base things on physical size, not pixel density, yet support for detecting this is poor. These things have become so complicated that services exist just to let you see/execute your apps across all of these devices because nobody can realistically have physical access to all of these things!

How can we Improve Things?

I think it all comes down to a few things:

• I should be able to pick my programming language
• My programming language should be flexible enough for me to express things I know up-front and get compiler assistance instead of runtime errors
• I should not have to write much code that is not specific to my application/domain
• My code should give the exact same results everywhere

Stating requirements is easy; pulling them off less so! Note: I’m just an average developer! I’ve no experience with anything as complicated as what I’m proposing here. Don’t interpret this as me suggesting this is easy!

Here’s what I think we should be investing time and effort into:

• A new intermediate format/VM for running code in the browser to allow multiple languages
  • It doesn’t matter what this is based on; JVM, MSIL, NaCl, something else, as long as it’s something up to the job (with solid sensible behaviour, not JavaScript)
  • It must support being targeted by at least a handful of mainstream languages (this will ensure suitability for new languages too)
  • Both Microsoft and Google agree to implement it (I’m certain other browser vendors would follow if both of these did, but I doubt that Google or MS would follow others)
• All browsers auto-update by default
  • No off-by-default, even for enterprise
  • Browser vendors drop support for old versions quickly
• Good static analysis tools for mainstream languages to allow us to move more runtime crashes to compile errors
  • Microsoft should get Code Contracts or something similar back on the roadmap
  • If we had a good intermediate format (as mentioned above), these tools may be able to be generic and work for multiple languages
• New programming languages; It’d be very hard to try and retro-fit some of the things we need to existing languages
  • Designed to be runnable both on the server and within the browser (see above), including compile-time enforcement of API sets (eg. no access to file system in client libraries)
  • No nulls!
  • Contracts, Dependent Types or some other way to express our requirements better to cut down on runtime errors
  • Strong typing
  • Ability to enforce purity and exhaustiveness/totality on functions

You may argue some of these are not necessary, but I think the end goal needs to include all of these, even if the path to get there is a progressive one.

The Chances of Things Getting Better are Slim

That’s a pretty pessimistic view, but sadly I think it’s where we are. The problem is; the entire “plan” above pretty much hinges on support and collaboration between two of the biggest software companies in the world: Microsoft and Google. Both of these companies have a serious chunk of the browser market and it’s a near-impossible task to ever challenge that. With their rocky relationship I don’t see a world where either company will add the others technology to their browser (eg. IE getting NaCl or even Dart support), nor anyone coming up with a standard intermediate format they would both agree to support. Browser plugins are not a realistic option even today and their support is only likely to shrink in the future.

Conclusion

If you’re writing code on the server, you’ve got it great. You can pick and choose your language and over time, you’ll get more of the programming language features you need, or new languages to provide them.

If you’re writing code for the browser, then unless you love JavaScript, your life is going to continue to be frustrating for many many years to come!