Featured Post

Linkedin

 These days, I mostly post my tech musings on Linkedin.  https://www.linkedin.com/in/seanmcgrath/

Thursday, September 28, 2006

On Javascript

A variety of scent trails lead me to Dreaming in Browser Swamp. It is a fun read, reminds me of twenty first century applets in parts. But I'm not sure I agree with some of it.

Steve is not a fan of the "lame-ass toolkit" approach of generating JavaScript. I dunno. Feels like a bootstrap opportunity to me.

1) Lots of v. ugly JavaScript needed to make an app work across a range of disparate browsers
2) Crystallise an abstraction over those browsers in the time-honoured GUI toolkit tradition
3) Write programs to the abstraction using language FOO
4) Compile down to JavaScript or translate on the fly so that all the browser sees is the JavaScript, perhaps after browser sniffing/CONNEG on the server side.

IF the abstraction takes hold, tools to work directly with the abstraction will take hold and eventually browsers that work directly with the abstraction will appear - obviating the need for the downtranslate to "legacy" Javascript.

Somehow, we gotta find a way to clear out the swamp without closing down the fairground. This seems like a reasonable approach to me.

Steve also makes a case for the ecomomic superiority of a single language that supports declarative programming. He is right on the money that the only way that this one-size-fits-all model will work is if it supports declarative programming. I'd go further and say that the key requirement (again a bootstrap argument) is the support for DSLs.

For me, it is the DSL bits of Ruby that are truly interesting vis-a-vis Python or Scheme. The Scheme/Lisp approach to one-size-fits-all falls into the particle physics trap I think. (The layers of abstraction you pay for the homogeneity of everything is too high.). (Think RDF applied to a programming language and you get the general idea.) Ruby mangages to keep fairly intuitive and clean syntax in the DSLs which, I think, is an important lesson for all language communities.

So, here is a strawman grand unifying theory:

XML = a DSL for data that validates and compiles data into tree structures. (think about it.)

FOO = a DSL for web programming at compiles programs into 21st century byte code called BPIJ (Browser Platform Indepdent Javascript)

FOO here is a placeholder for one of todays languages or some yet-to-be-created language.

Now here is the big question: why have FOO and also XML?

If FOO has excellent DSL capabilities then doesn't the difference between code and data dissapear in the blue smoke of logic?

I think the answer might be "yes" as long as the DSL features of FOO hit the right 80/20 point between expressive power and ease of expression.

No comments: