Preview is valuable because it produces *exactly* the output that the wiki does. A JavaScript work-alike parser is unlikely to work exactly the same even in the best case, and isn't going to provide for extensions at all without invoking the PHP parser on the server.
I never intended this to be a replacement for the current preview as it simply is impossible to provide a feature-complete preview without invoking server-side processing. On the contrary, this is just an extension for people who understands the limitations of using such an alternative. For those people I believe this could prove to be very useful.
Having two parallel parsers is also a bad practice, introducing extra work in maintaining them both and keeping them in sync. Someday we may have a real working 'alternate' parser, but if so it's going to have to prove itself worth the effort of maintaining it; as it is we have enough trouble with sloppily-written pages not working when copied to another wiki that's not running with tidy to clean up HTML kinks, and that's just a post-processing phase rather than the parser itself.
Now, I don't even pretend this to become integrated with the current software, I don't even see the need for it as long as there are ways of customizing one's wiki (namely with monobook.js). Of course not everyone would understand the difference between server-side and client-side previews, so having this enabled by default would be a big mistake.
So, in other words, I want this to be some sort of plug-in which particular users could install for themselves _if_ they want to. I'm sure there's nothing wrong with that. What's more, I think MediaWiki could do with some more ways of customizing user interfaces.
There's some experimental code in 1.5 for fetching previews via an XmlHTTPRequest, which avoids the skin rendering overhead (and in many cases should avoid message cache initialization overhead) required for a full HTML page submission while letting the PHP parser return real rendering results. Most of the time spent in rendering non-trivial pages is concentrated in a few hotspots (particularly title normalization, link checking, and link generation) and IMO optimization effort would be better spent on these.
Sounds really interesting. I'm really for that kind of a approaches. Look at GMail for instance, I think it's amazing. MediaWiki could take great advatange from that kind of techniques.
This is not to say that a JavaScript wikitext parser is useless; but I don't think we would be able to use it for things like previews.
Hm... since I can't fully agree here I can only hope I stated my view clearly. In the meanwhile I will continue to enhance and extend the script to support as many features as possible.
Regards,
-Pedro