Microsofts Say in the Matter

By Darryl K. Taft  |  Posted 2008-06-09 Print this article Print


Microsoft will have no say in the matter?

Well, they could try to break us. They could say, "Oh, I can't support this; this is a security hazard. Screaming Monkey is going to bite my nose off, and I'm going to outlaw that MIME type." That probably gets them into some antitrust concern, because it looks anticompetitive. It looks like they're trying to firewall Silverlight and the CLR.

If they try to break the general ActiveScripting facility, they're going to break a bunch of other customers and enterprise people who've added their own scripting engine like CobolScript or whatever.

So, I don't think they can do it. I think they're just going to have to take the risk and try and say we have better tools, we have better run-times. And for some definition of better, for a lot of professional developers, they do. There's no disrespecting Microsoft on that front. That's been one of their strengths, and it will continue to be. VisualStudio is a powerhouse.

But the Web is a low-cost disruption that's always chipping away at that and always saying: Well, do you really want to lock yourself into that and only target Microsoft and what Microsoft supports? Sure, Silverlight runs on the Mac. They've got Miguel [de Icaza of Novell] doing a Linux version. It's kind of like they took out the old "Kill Netscape" playbook and they're using it against Adobe Flash. The same thing happened with Netscape, and of course they dropped the Mac port. And the Unix port of Internet Explorer was contracted out and died a long time ago.

So, I wouldn't be shocked if in the worst case that happens again with Silverlight. But I'm here to prevent that with whatever efforts I can put into it. And part of the effort is making Java??íScript 2 widely available. So we don't want it to be just a Firefox thing. We hope Apple and Opera support it. And Opera's been great in the Ecma group. The people they've brought to bear have been really top-notch. Apple has not really been that involved, but I've been talking to them for over two years, and they're following it. And we're hoping that they'll come on-board at some point.

What we're trying to do in JavaScript 2 is mainly not about performance; it's more about, "Can I write my package or whatever you want to call it, throw it over the wall to you, and have you use it or mash it up with something Alice or Bob wrote and have them not step on each other?" And that's hard. That's the real goal with JavaScript 2, in my opinion.

But can't people do some of that today?

People do that with Java??íScript today using conventions. They have the AJAX [Asynchronous JavaScript and XML] libraries share the global namespace by just using their own YUI [Yahoo User Interface] or Dojo name as an object to hold other names. And it's by convention, it's nice and it's very low integrity. People can attack it. You can make a mistake that stomps on somebody. So there are both security threats and just error and tolerance problems with that. And we'd like to make that better. We'd like to make it possible for developers to make more static judgments about code for security, for instance, or for knowing what names mean so nobody can mess with you.

It sounds as if JavaScript can take on a lot.

Well, the fear is that JavaScript will turn into Java, and it will become this very bounded and disciplined language, and it will be painful because programmers will always have to declare everything, and it'll be used in a way that is rigid and inflexible. We're not doing that. It's still JavaScript; it's still a dynamic language. There's no Java mandatory requirement to always write down your types and declare your variables. You can do anything that goes today. It's backward compatible.

But as you begin to scale up your code, you're going to want to lock a few things down, like your APIs that you present to the other libraries and to other applications-those generally you start out prototyping. You really don't know for sure what you're doing and how to express what you're doing in the language. So you play around and you do some prototypes. As you evolve that, especially if it becomes a hit, then you start to get a better idea of what things are. And for that version at least, you ought to be able to make things a little more controlled.

So, we're trying to improve programming in the large. And that's the real goal.

So JavaScript 2 is really going to take until this fall to really get the spec done. And we're on track. We've cut some things. We've made some important sacrifices, I would say, to get it done soon. Part of that is because we can't keep having it go on and become like a Perl 6.

Darryl K. Taft covers the development tools and developer-related issues beat from his office in Baltimore. He has more than 10 years of experience in the business and is always looking for the next scoop. Taft is a member of the Association for Computing Machinery (ACM) and was named 'one of the most active middleware reporters in the world' by The Middleware Co. He also has his own card in the 'Who's Who in Enterprise Java' deck.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel