1. 1

    The client side bits remind me of Java applets and liveconnect. Like if you compiled any language into java bytecode and just made it interface with the DOM/BOM through plumbing. That’s a “common” VM and intermediate format.

    I think the problem with the argument (and not to pick on the author… it’s a broadly discussed topic) is that implementers would have their own versions of this common vm. Their own versions of this plumbing. “Write once, run anywhere” fell short of its vision partly because of so many implementation differences.

    If the big thing is to get typing into the client, or not depending on what makes sense for your app maybe the thing is to get a future version of javascript to have typing, or not. Kinda like strict or not… albeit with a much huger dev push behind it to pull it off.

    1. 1

      It’s not just about typing; it’s also about choice and sharing code.

      Choice: On the server we have choices, and people pick different languages - there are merits to them all, whether they’re technical, based on familiarity, or even just available libraries.

      Sharing: Often we have to repeat logic in both the client and on the server. If our server is running language X, why must we re-implement that logic in JavaScript, or worse still, send the data back to the server for processing?

      I don’t think different VM implementations would be a big problem. Mono seems to be doing pretty well; and you never know, people might share code (until recently, Chrome used WebKit for rendering)!