Oct 29 2007
God Bless Scoble
One of my favorite bloggers is Robert Scoble . Not just because he is smart, popular, and handsome. (Well 2 out of three aint bad) Because he tells it like it is. And he does it well.
I was at a Web 2.0 conference this week, and my intention was to blog on it every day to help generate a community, but I had to wait until now. How in the HELL does he charm all the dirt on new tech and still have energy to blog? I recently had a very bad experience with U.S. Airways, but I would be afraid to hear some of the horror stories Scoble could dredge up.
Here is what I learned at the Ajax Experience : There is a jihad going on in the web development community and we are ALL going to loose.
- There was a browser war. Microsoft won
- We are in the middle of another
- The Javascript language is being used as the foremost weapon
- Adding ANY new feature to the web can be argued it has a chance to cause harm
- Time benefits entrenched companies to keep the status quo and not change
Here are the players
- Microsoft: I can not find ANYTHING on what is really going on. NO ONE at the conference trusted them. If they want developers, developers, developers then they should be more transparent. Will XAML interfere with Open Ajax?
- Yahoo: I tended to believe Douglas Crockford that the new Javascript language is akin to ‘the ghost of Netscape’ and may be bloated. However, adding CLASSES to JavaScript is NOT a bad thing and computer scientists should not be afraid to add new features. I am am also cynical that Yahoo may still be promoting IE.
- Mozilla: How exactly did the current Ecmascript 4 proposal get through the committee ?
- Adobe: A breath of fresh AIR, but what is the partnership with Mozilla? I think it is great that such a mature scripting engine was donated, but wonder the business objective.
- AOL: Thanks for supporting the conference and especially Dojo! Where can we find information on the agreement?
- Sun: jMaki is kewl. What exactly is JavaFx in the new web?
- Apple: Um… where were you? For that matter, where were reps for Facebook and MySpace?
- Framework vendors: Why exactly is your framework better than the other TWO HUNDRED Ajax vendors out there? Please be specific because you are asking me to spend my time and money on your proprietary system and there are many Open Source solutions out there.
- Google: They claimed to want more developers, but they were not very approachable. Dion was nice however, although hard to talk to just because he was so busy!
- IBM: Jon Ferraiolo has done a GREAT job with Open Ajax, but I do wish he could understand there is more than the corporate way to contribute.
There are A LOT of accusations of backroom deals being made. Can anyone make a clear statement addressing this? The first company to get the trust of the developers will win, and I intend to do everything I can to support true OpenAjax.
Microsoft believes that much of the current success of Ajax was made possible by the stability of ECMAScript and the fact that because of this stability the major browser implementations have largely converged upon a reasonable de facto interpretation of the ECMAScript standard. This was the foundation that was needed for Ajax to emerge. We want to find a way to evolve ECMAScript without losing this stability. We would sooner “go slow” and get it right than rush to premature standardization. The last thing the Ajax web needs is a major language reset followed by 5 years of instability as browser vendors try to interpret a new language specification, figure out how to efficiently implement, and then try to iron out their different interpretations.
Details of our vision for ECMAScript will be rolling out on the JScript blog. As a first step (http://blogs.msdn.com/jscript/archive/2007/10/29/ecmascript-3-and-beyond.aspx) we have made available to the community a draft document where we have tried to identify every way in which IE JScript differs from the ECMAScript 3 specification. We think understanding this level of conformance both of IE and all other major browsers is an essential first step toward evolving ECMAScript to include new functionality which maintaining the essential stability of the web.
Allen Wirfs-Brock
Microsoft Developer Division
Allen.Wirfs-Brock at you know where…
Hey Ric. Good to hear from you in an open forum, Allen.
Developers (both web and competing browser developers!) could have used that JScript vs. ES3 doc a number of years ago. Having reverse engineered enough of JScript to help Firefox gain market share, Mozilla JS hackers are interested in more than going slow to help Microsoft go fast with Silverlight.
Really, don’t Ajax developers deserve more from ES4 at this late date than deferred JScript maintenance and ES3 spec-polishing?
/be
What is the end game?
Doug’s biggest technical argument is that the changes in ES4 is bigger than all of ES3. Is there some magic metric we would all be more comfortable with? How about 30% bigger? Would we argue is JavaScript 2 only had ONE major new feature like classes? I bet we would!
My response: so what? IF Mozilla CAN make ES4 a BETTER language, who in their right mind would argue with that? What is they can actually pull it off? A more expressive, secure programming paradigm that is compatible with the current web. With the extensive experience of Actionscipt, it looks possible. If it does happen, as a web developer I would feel compelled to vote Brendan to a Nobel prize (We should have a computer category)
On the other hand, if it does not work, what is the risk? Will the web die or just Firefox?
IMHO, if it is backwards compatible, we SHOULD call it Ecmascript4. Naming it anything else, would doom it to VBScript land. However, I do not know if we should add the version number. That makes it feel like another name.
Screaming monkey sounds like a good idea, but IE does not really have a market for plugins, so do not expect high adoption.
But to paraphrase Crockford again, “Microsoft has a virtual [browser] monopoly”. All they have to do is NOT implement ES4, and they win. As web developers, we have to code to multiple browsers now, and this will only exacerbate the problems. Mozilla has a double edged sword: they need to get it out there as fast a possible to grab more market, but it has to be DAMN good or people will not use it as a reason to switch.
Please note that the #1 site on Xaml is an OpenDomain so in some ways, I want Silverlight to succeed. But the most important part is that Microsoft IS part of the OpenAjax alliance AND they seem to be responding (on my blog - Holy Moley!)
Ric, have you heard of ScreamingMonkey? See
http://weblogs.mozillazine.org/roadmap/archives/2007/07/new_projects.html
There’s hope yet for all those IE browsers that will lack ES4 support in a year.
/be
For the record, I am not opposed to Brendan’s proposal because of any affinity with IE. I use FireFox myself, and if more people used FireFox, my world would be a better place.
There are a lot of people who feel that JavaScript sucks, and are hopeful that the proposed language will suck less. My concern is that it may suck more. If new language is able to prove itself, then it may earn adoption. But it should not be standardized and displacing stable technology until it is proven.
Once a feature goes into a standard, it is really hard to remove. For example, typeof null === ‘object’ is a bit of suckage that the new language dares not fix. Before we standardize a lot of new features, we need to have confidence that we got everything right this time. Good intentions are not enough.
The technologies of the web are obviously deficient, but we must be careful in how we repair them. I think the most promising prospect for going forward are in Google’s Gears. It is from a fierce competitor of mine, but it has the potential to make things significantly better, so I am supporting it.
The new language, on the other hand, doesn’t let me do anything that I can’t already do. It does not correct the language’s biggest flaws. And it adds at least one new one: It is too complex.
Simplicity is underrated.
Ric, glad to be here… you asked “what is the end game?” Personally, I don’t think there is one. The web better be forever. If I ever get my personal achieves up on the web (probably won’t happen before I retire) I hope that they’ll still be around somewhere, accessible, and usable “on the web” a thousand years from now. This includes any scripts that they embed. If they do last that long, I doubt that they will be accessed using a Microsoft (or Mozilla or Apple) “browser”. If this is going to happen, it’s going to have to be through standards and standards that survive across the centuries. Such standards are not replaceable, they must continue to exist and be implemented, as originally written. That doesn’t mean that the set of standards that define the web must be hence forth frozen. No way, can that be the case. What is does mean is that new or improved standards need to enter the web ecosystem as alternatives, not replacements for existing standards. Over time, new development will shift to using new standards but the support for old content, based upon old standards must remain.
One of my major concerns about ES4 is that it seems to be positioned as a replacement for ES3. Both as a language and as a language implementation within browsers it is intended to replace the existing ECMAScript. Brendan asks us to trust him and his design team, they’ll get it right, they’ll maintain compatibility, they won’t break anything. I’ve met them and I believe that they’re serious about this intent. But the weight of computer science history is against them. Major new languages (and ES4 is a major new language) seem to always have design flaw and need one or two major revisions after initial significant usage. It typically takes a couple of iterations for implementers to learn how to best implement a new language and get the subtle feature interaction bugs out. There are always interoperability issues among independent implementations of a new language. For the sake of argument, let’s just say that I trust that Brendan and his team will avoid these problems. That great, but I don’t trust that Microsoft, or Google, or Apple, or Opera, or anybody else won’t have these problems. I won’t even trust myself in this regard.
Ric asked “what is the risk?”. The risk is that we will go through a five year period of unstable browsers as every browser vendor works to replace their script engine with a new implementation that runs ES4, maintains compatibility with existing ES3 code, and perfectly interoperate with every other browser vender’s implementation. Is that an acceptable risk? Personally, I don’t think it is but I do think there are ways to advance browser scripting that avoids such risks.
Allen,
Thank you for the great reply.
I posed something along the same vein in the ES4 list:
“As a software engineer, I welcome most of the proposed changes. BUT, as a web developer, I feel I am forced to take Doug’s view: even there was only ONE change between browsers, I would have to have special code to handle ALL cases. And the sad thing is that it WILL happen. I am willing to bet up to $100,000 - any takers?”
Ric
Hey Doug, a few comments:
* The new language is not being pushed throught Ecma this year. It will be implemented and deployed before next fall, when we hope it will be standardized. Contrast with the rubber-stamp standards Microsoft has pushed through Ecma.
* You can’t prove a new language without specifying it so browsers can implement it interoperably, which means making a formal standard of some kind. If you insist on de-facto standards emerging before any standard that others can implement, you’re giving Microsoft alone the power to force new standards.
* No one gets everything right. I don’t believe you walk on water, and I know lots of languages, including standardized ones other than ECMAScript, that have unfixable flaws. So please, get over this utopian disease, it is simply helping Microsoft stall improvements to JS while they aggressively evolve C# and its runtimes.
* It is false to claim that ES4 does not let you do anything you can’t already do in ES3. Can you make immutable bindings in the global object? Can you ensure that names are looked up in ways that can’t be overridden, including in standard prototypes and the global object? Can you hide names without three times the object overhead (for private members using closures)? Can you seal initialized instances against mutation?
* Simplicity is good, but Einstein had something to say about it — how did it go? “… as simple as possible, but not simpler”. And here’s Yukihiro Matsumoto (in Beautiful Code):
“Simplicity is one of the most misunderstood concepts in programming. People who design languages frequently want to keep those languages simple and clean. While the sentiment is noble, doing this can make programs written in that language more complex.”
Guy Steele had something along the same lines (”Growing a Language”). I wonder if you disagree in principle, or only in detail — or whether you’ve read these writings.
/be
Worrying about compatibility is exactly what every browser vendor except Microsoft, while it sat on IE6, has had to do, and worry effectively — so effectively that some of us even gained market share from IE, and are still gaining. Now to hear Allen and Chris Wilson talk, Microsoft is the soul of prudence, while others are reckless. This is an excuse for stalling improvements to web standards.
Ric, there’s no cost to web developers, they keep using ES3 for as long as they like. Browsers that do not have Windows Update on their side will be backward compatible when handling ES3 content. Those wanting to opt into ES4 will face the usual law-of-zeroes bugs as new implementations come on line, but nothing those kinds of early adopters haven’t faced before in ES2, ES3, JS1.6, and JS1.7. In spite of Firefox extending JS, the web didn’t break and we did not bounce off it, i.e., lose market share because of the extensions.
/be
“It typically takes a couple of iterations for implementers to learn how to best implement a new language and get the subtle feature interaction bugs out.”
Many of the new features have undergone a few revisions in one or more of Opera, Flash, or Firefox. It’s only completely new for Microsoft, because their support for open Web technologies has stagnated while they devote resources to proprietary plugins like Silverlight.
Full disclosure:
I am a hardcore .Net developer and own the #1 site on Xaml
I am also the owner of OpenDomain, and have contributed to many Open Groups
I am NOT a JavaScript expert on the same level of Brendan or Doug, but I HAVE been programming for 30 years!
I cannot say anything about the industry talk, but this one caught my eye:
Cite Brendan:
“It is false to claim that ES4 does not let you do anything you can’t already do in ES3. (…) Can you hide names without three times the object overhead (for private members using closures)?”
I take for granted that backwards compatibility will be assured… but it will take a long time to get me to develop ES4 specific code. Reason ist not so much that I don´t like the new features. Reason is, I prefer a small syntax set over a bigger one. It is true that you need to know about techniques like closures, continuations and such - but once you know them you usually know more about JS engine behaviour than other coders programming in a more formalized style. In my eyes this is worth much more in a programming team.
For the record I also have done programming for almost 30 years. My only concern is to keep on track and not get into problems using a new codebase. As to the name space, a question: say I run a #1 site utilizing member-coded meshups. Would it be possible for somebody to disallow certain libs by pre-occupying its namespace? Can a namespace be hi-jacked?
Bottom line: if ES4 provides both ways of coding - great. But I will very closely evaluate before using an ES4 specific feature. Also I fear every restriction may come with an inherent risk.
Last thing: thank you all for all the info… it is really exciting to watch the ongoing discussion here and in other spots.
[...] I should have given credit to Ric of OpenAjax for starting this off and helping me see the conflict brewing here. Filed under: Brendan Eich, ECMAScript, Microsoft, [...]
[...] I should have given credit to Ric of OpenAjax for starting this off and helping me see the conflict brewing [...]
On one hand it’s exciting to follow the discussion about ES4 and see web-evolution in progress, on the other it’s scary to think about the possible outcome of this struggle for survival:
JS becomes extinct (or should I say made extinct/obsolete?), because it failed to adapt to the changing web-environment. Either because its development (got) stalled, or because it lost (was made to loose) its competition against other proprietary languages.
Simon, web developer and biologist
[...] than openly designed, consensus -driven industry standards. Regardless, though, I have no intent of "helping Microsoft stall improvements to JS while they aggressively evolve C# and its runtimes&… - in fact, I personally think those are orthogonal issues, and Javascript's current lack of [...]
Javascript has historically been implemented outside of the standards process. Someone implemented it and the others copied the leader.
Lets stop wringing our hands regarding Microsoft. I think it’s about time that we see some leadership from some of the web browser vendors. We really need to get things going. The language has not changed since 1999. If I built a web site today like I did in 1999, I would be embarrassed.
The bottom line is that Microsoft will do what it pleases. No one can make them write to the standards. IE is quickly becoming obsolete. Lack of canvas support and now this. The other web browsers are slowly adding one compelling after another. It’s like Microsoft wants the web to fail or something. But the web is bigger than Microsoft.
In the end, if Microsoft refuses to implement the standard, I’ll compile some kind of special js file for IE using a pre-processor. I already minimize my code, so I already do something like this already.
I think Microsoft would be stupid to ignore the new spec, however. The reason I say this is because the improvements in the language are going to result in dramatic improvements in execution speed. With Web 2.0 applications the differences are going to be stark. There will come a day when someone will say - Hey, things are so much faster and more secure using Safari, or Firefox or Opera. And that’s the same browser that I have on my Phone already.