Code in the Browser

Yesterday I was lamenting the lack of good choice for coding in the browser. I know, I know, I gripe too much about it. I can hear folks now “Just shut your pie hole and learn JavaScript, like everyone else.” That is good advice, I should learn JavaScript, but I digress.

The mere mention of it started a conversation on Twitter, which lead me to start thinking about a weblog post, which lead me to a search for “CLI in the browser” or something like that, which landed this great post by Miguel de Icaza.

“ECMA CLI would have given the web both strongly typed and loosely typed programming languages. It would have given developers a choice between performance and scriptability. A programming language choice (use the right tool for the right job) and would have in general made web pages faster just by moving performance sensitive code to strongly typed languages.”

This is what I’m after. Choice and closer to native performance. JavaScript could be one of the supported languages, and should be for that matter, but in the end it would be really great to have a language agnostic runtime.

I’d compare the state of coding in the browser to coding 20+ years ago. At that time everyone was using C because it was the most portable way to get your code on other OS’es. I find it a bit depressing browsers haven’t moved past JavaScript. Can you imagine only being able to code in C on your favorite platform? Of course not, that’s preposterous.

It will be interesting to watch browsers mature into a layer that completely replaces the OS for services. Until then, we’ll have to make due with what we have.

Here’s the Twitter conversation that lead to this post (sorry, the Twitter embed code only grabbed the last bit of the conversation, not sure how to get it all.):

@notrazawa @kepford I do, but we certainly don’t have to agree. JavaScript is a starting point for an immature environment. It’ll change.

— Rob Fahrni (@Fahrni) May 14, 2013