Tuesday, December 9, 2008

The OpenWeb language for the next 100 years is...

Recently, there's been a lot of discussion about frameworks which translate or compile alternate programming languages to Javascript, John Resig's article being one of the more recent. At the heart of John's article is a lament that by abstracting people away from Javascript, they may not choose to learn the language.

There is some merit to this, after all, many developers use programming languages which compile down to assembly, but never take the time to learn the CPU architecture. I'm guilty of such, I grew up in the 80s hacking 6502 (VIC20/C64) and later 68k/80x86 code, but after my computer got powerful enough to compile C, I pretty much didn't keep up with ASM never learned MIPS, SPARC, or SSE (although I did take the time to learn DX9 shader assembly).

John also mentions that sometimes abstractions leak, and when they do, it may be hard to debug problems if you aren't familiar with the native platform. This too is a fair point, of course, the same is true with assembly, in that sometimes you do need to step into assembler code when a heisenbug appears.

One lesson to take away from this is that programmers should strive for deep knowledge of the tools they are using, from how compilers work, to library implementation, and underlying execution environment. Is it really good practice for a Java developer to learn nothing about the internals of the JVM, and how Hotspot optimizations work, for example?

But I'd like to ask a more important question: What if future web applications aren't written in Javascript at all, would that really be a bad thing? What makes Javascript ideally suited for client side coding, which really means, DOM/CSS manipulation, event handling, and network I/O? You see, much of the Javascript community accepts that it is perfectly natural for server-side code to be written in any language: Java, Python, Perl, Ruby, PHP, C#, even Javascript. You do not see a huge push for a singular server-side language. And the server-side has since developed into a very strong, diverse ecosystem, sprouting up robust VMs everywhere. And from there, robust library frameworks, like RoR, Django, etc.

So why is it, that only a single language: Javascript, and it's various VM implementations, is treated as if it is the only True and Correct way to work on the client side? If Javascript VMs one day became more general purpose, accepting perhaps bytecode or some form of intermediate representation as input, and we ended up with Ruby, Scheme, Python, et al, running natively in the browser, would this be the end of the world?

To listen to some Javascript evangelists, you would think so. The OpenWeb seems to mean that you have freedom and openness on the server, just don't dare write any non-Javascript on the client side, that's off limits!

Unfortunately, we don't have a general purpose VM in the browser, like JVM, or CLR, or Parrot. Instead, we have Javascript, which is why all of these third party language translators are treating Javascript as if it were assembly or bytecode. But oh, the nerve of these translators! What an insult! How dare you compile some inferior language or DSL down to basic Javascript, and not write beautiful and elegant human readable Javascript instead.

On a more serious note, there appears to be a great deal of hypocrisy in some of the criticisms of third party frameworks as well. That is, it is impermissible to abstract away the Javascript language or try to "hide" the Web, that is, unless you are a Javascript framework which has nifty DSLs and Widgets which do exactly that -- like hiding the pain of getting CSS layouts right from newbies.

The question for you is, do you believe Javascript is the next big programming language, the language that we should be programming the web with, 5 years, 10 years, 100 years from now? What I've learned from sitting through 20+ years of internet/usenet language flamewars is that no language is perfect, people have different tastes, different aesthetics, and different languages fill different niches. Emacs vs VI will never be resolved. Static vs Dynamic typing will never be resolved. And no one language can satisfy everyone.

This is not to say that there aren't concerns about gluing code written in multiple languages together and making them interoperate. This is being done on .NET CLR and JVM today, so it is certainly possible in the future to do it in the browser. On the other hand, many people today already work with incompatible siloed Javascript frameworks, so maybe it's not really an issue if Ruby code can't reuse Python code on the client.

In the end, I would say to Javascript ninjas, relax. There will be more than enough people writing Javascript to sustain a vibrant community. You should welcome polyglots on the client as well as the server.

Let a thousand flowers bloom.
-Ray

8 comments:

Cameron said...

Well Said.

zproxy said...

What if in the future a programmer can express his thoughts in one language yet, it will be transparently stored as another. Take my jsc compiler project for example. With it you could develop an application in C# for various platforms be it javascript, java, actionscript or php.

I think developers should not be bothered with ambigious syntax. Developers should be able to choose a primary extendable language.

It is up for the compiler to transform to the target platform.

I guess in the end we will have the yoda language after all.

Ray Cromwell said...

You might want to check out Intentional Programming if you haven't already, which was somewhat aimed at expressing concepts in an intermediate, AST-like system, and then reflecting it into various target languages.

Tom Robinson said...

Nice post.

Indeed, perhaps we should be searching for the 100 year VM, not the 100 year language.

Dobes said...

Generally I think Javascript is a pretty poor language in general.

Flash gave up on the javascript object model with AS3 and it's much better off for it - both in terms of performance and engineering.

Sun had a great opportunity a while back to BE Javascript with their applets system - they even convinced all the browsers to include Java applet support - but they screwed it up by making applets to hard to write, and not providing easy access to the DOM.

Now, almost ironically, we have GWT which compiles Java to Javascript because Javascript is more powerful than Applets even though the applets theoretically have the advantage.

Anyway, whatever works - I'm fine with GWT although I do find it's long compile times annoying.

If applets were upgraded to have the same powers as Javascript we could be targetting the JVM instead of Javascript, which I think would be an improvement.

Unknown said...

Standard VM instead of language would be good

hallvors said...

There is one server, and you control it, including its interpreters and VMs. There are thousands of clients and you have no control at all.

Doesn't that pretty much explain why, in a client-server model like the WWW's, we're happy to have lots of options for the server-side but would like all clients to behave the same way whenever possible?

You're asking for (even) more fragmentation on the client side. As they say, be careful what you wish for - you might get it!

Ray Cromwell said...

hallvors, all you need to do is include a single shared VM in the client, and as long as that VM is the same on every client, it doesn't matter what the language syntax is.

Today, people already use compilers to translate other languages down the Javascript. The problem is, Javascript sucks as an intermediate bytecode format for cross-compilation, and it has inherent semantics which limit performance.

I'm simply calling for a better base VM to be standardized, then Javascript can be one of the many languages which run on top of it.

No fragmentation.