Slashdot Mirror
MS, Mozilla Clashing Over JavaScript Update
jfruhlinger writes "JavaScript has become a crucial part of Websites built on AJAX underpinnings, which makes the upcoming revision to the ECMAScript standard crucial for the future of the Web. But in today's browser environment, no one vendor can impose an update path — which may set things up for a nasty conflict. A fight is being fought on blogs between Mozilla Chief Technology Officer (and creator of JavaScript) Brendan Eich, who wants to the new ECMAScript standard to be a radical upgrade, and Chris Wilson, architect of MS's IE team, who would rather keep JavaScript as is and put new functionality into a brand-new language."
Maybe this is a naive question, but why isn't a third-party standards organization leading the way on this? I know that W3C didn't do a great job standardizing HTML (as any web developer who has spent hours debugging IE vs Mozilla can attest), but ANY standard is better than no standard here. Where's NIST or ANSI? I hate to even suggest that the US government get involved, but setting some kind of standard could avoid another Blu-Ray vs. HD DVD wasteful standard war that hurts consumers and developers. Everyone would be better off if this conflict could be avoided entirely. What would it take?
Yeah, design by commitee always works out so well! Seriously, third party standards bodies are only good at post-facto. Don't rely on them to innovate. I say IE and Mozilla battle it out, release the product, and may the best man win. Once a winner is reasonably clear, then the standards bodies can get in and write it in stone.
By "flexibility", you mean "use javascript or MSVbActiveFlashScript"?
Opera's Haarvard suggests that it's about Silverlight, and Microsoft trying to close the web. Mozilla, Opera and others are pushing to extend open web technologies, but Microsoft is saying, wait, the web doesn't need to be extended at all! Well, except with Silverlight and WPF...
If they're serious about turning the browser into an application platform, there needs to be a multithreaded language with full DOM access, whether that is Javascript or something else. An application where the UI stalls the processing or the other way around is just not acceptable. Since Javascript multithreading has been rejected before, because it's supposedly too difficult for the typical script author, I suspect that Microsoft may have the right instinct here to go with a separate language for "pros", keeping Javascript simple for things like mouse rollovers and other eye candy.
ECMA International is a group that writes standards.
By the time that a good chunk of all browsers actually support ECMA 4, it's going to be a "nice to have" feature that nobody's going to be too keen on.
The road forward, in true hacker fashion, is probably to write translators so that part of your PHP, Ruby, Perl, Java, or C# code magically runs on the client, treating ECMA 3 as a vague intermediate language.
ECMA 3 can be the x86 assembly language of teh intarweb. No CPU actually executes real x86 instructions anymore, they translate it into internal RISC/VLIW-ish operations. Very few programmers write much of any raw x86 instructions anymore.
Of course, this may or may not be handy for the other ECMAScript implementations like LiveScript.
Gentoo Sucks
There needs to be a third pary arbitrator here.
And hopefully that arbitrator tells them all to just STFU up and use python
NewslilySocial News. No lolcats allowed.
As a user, I really couldn't care less which way it goes.
Just don't break things that work now!
As a developer, I really don't care, either.
Just don't break things that work now!
Honestly, if we're going to have a new version that's significantly different and "updated," just fork: Keep the original code that works well as one version and then rewrite it as the basis for the new one. The first thing that comes to my mind is KDE4: It's a hell of an idea, but I think they'd best keep 3.5.* around until they're done with 4.0.
In short, give people a choice: Let me choose if I want to write for the stable venerable base or the new pretty whizbang version.
OK, maybe I'm missing the point here but AFAICS no-one's arguing against the new draft; instead, the argument about whether you accept the new syntax inside tags or not. One side says yes, other says we should keep that for older JS and put the new stuff inside tags or similar so we can tell ahead of time which one we're supposed to be dealing with and make sure we don't break existing web code.
I don't see anything about closing the web or stomping on the little guy or anything like that. Where's that coming from?
For once, someone at Microsoft gets the deal right. They should leave javascript as-is, and improvise XUL or whatever is the new buzzword. Tacking on updates to existing standards only creates ugly security loopholes, and all sort of weird hacks. Why, in the name of the lord, can't people learn from the mistakes that others have made?
Microsoft: "You've got questions. We've got dancing paperclips."
I know it's somewhat indicative of a tinfoil hat, but that's basically what I and many others do, using NoScript.
If I trust the website enough to run javascript, then I add it to my whitelist. I don't see the need for javascript on most of the pages I go to, and would rather not have my computer running unnecessary code. Seems to my totally uneducated POV that it'd slow my computer down if I have 20 tabs each running javascript stuff, when only 2 of them ACTUALLY need it. My RAM is precious to me. =(
And the languages won't win either. Javascript will stall at its currently supported version as people strive for cross-compatibility.
[ think ]
I've actually had dreams about all the major browsers coming to an agreement about consistent standards with HTML, CSS and Javascript. I have actually had dreams about designing an elaborate webpage layout for Firefox and then having it turn out perfect when it came time to load it in IE. But then I woke up and went about another busy day of using tables and NOT divs for webpage layouts...
*sigh*
/* No Comment */
There's no need to pull Ron Paul's abysmal ability to properly render real world websites into the discussion.
Wanting to create a new language instead of supporting an upgraded JavaScript shows one thing, how bad the IE codebase for JavaScript handling might be. This majorly smells like those situations where after a long update and extension period a code becomes so hard to handle that it's better to drop the whole thing and start a rewrite from scratch. Of course, if you argue for a new language, this probbably isn't such a big issue, since you'd need to write a new handler code for that anyway, and nobody will know what your reasons were.
Of course this is all just speculation. Wouldn't be the first time I'd be wrong, still, the smell is really strong.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
Well that's what GWT, OpenLazlo et al do already anyway. The thing is you can't get all the features of the underlying language that way. The key is to making the source language so much better than Javascript that my complaint sounds like saying "the problem with C++ is that you can't get all the features of assembly." (And I mean within the source language, not with things like asm blocks.)
Personally I like Javascript as a language and think it's a shame to see roadblocks to it's development happen because of the nature of the platform it usually runs on. I'd like to see something like GWT where the source language is Javascript instead of Java - that is a Javascript to Javascript compiler where you could add whatever local features you need and have the compiler throw away the fluff and stick in cross-browser compatible shims.
more of the same on Twitter.
Screw two languages. I'd love to have one language that actually works on all the browsers. Javascript as it's implemented by Microsoft is worlds different from any implementation outside of it. It's only by hacking together the common bits between the implementations that web pages are actually capable of working on multiple browsers.
Star Pirates
The trouble is, Microsoft has a point. Original HTML, up to, say HTML 3.1, was limited but a reasonable design. Most of the attempts to extend past that point have been disappointing. CSS is a collection of attributes in search of an architecture. Page layout with "float" and "clear" is too limited and doesn't work well. (The "three column problem" is well known, and workarounds using layers or absolute positioning often result in text on top of other text.) Javascript is a mediocre language. (Could have been worse; see TCL.) That's the current mess.
Papering over the problem with a layer of "toolkits" just resulted in a proliferation of incompatible toolkit layers. That wasn't the solution.
But Microsoft will try to "fix" the problem with a closed, ambiguous system that requires frequent updates. That's what they do with everything else.
I don't see a good way out of this. Who can provide leadership? Adobe? They can't even make Dreamweaver work right any more.
Javascript is intentionally designed to be less functional than any of the languages you've mentioned, and with good reason...A client side language with the sort of feature set that perl or ruby or python has would be death on a plate in the context of a modern web browser; you'd go to a webpage and it wouldn't just slip you a trojan--it'd reinstall your OS.
Client side languages need to be concerned purely with the cosmetics of the interface. Any single step beyond that opens up some extremely scary security concerns.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
I think Microsoft royally screwed up with outlook web access. They added XMLHttpRequest to the browser so outlook web access would work more like a desktop app. They built an application on a technology that did not require full access to the latest version of the win32 api and x86 assembly language and it was off to the races. Most of Google, Yahoo and indeed the entirety of Web 2.0 was built on this mistake. They are desperately trying to put the web back in the original box they intended it to be in which is people without access to the latest version of the full Win32 API, and an X86 processor will be denied access to all online content.
Are you nucking futs? At what point in the history of MS have they done anything that was relatively useful to the end user if it was not Ultimately useful to MS in isolating end users from choice?
Not because I just want to bash MS, but they earned this one fair and square.
I'm not against a company wanting to innovate and improve their product in order to be the best in class, but that is not what MS is famous for. Their innovations have been purchased (nearly a 100 startups left to buy now) and they do not strive to be best in class with any kind of success (can I mention Vista here?). Even when a workable open standard is proffered up, MS has to do their own version in order to isolate end users from choice (can I get a hell yeah for ODF?). We 0nly have to look at the difference between standards based web browsers and IE to see that MS has no intention of doing anything that is actually good for the world unless it benefits MS (can I mention the bill and melinda foundation and OLPC?). MSIE was, and will continue to be a tool for MS to attempt to remain dominant on the desktop. By virtue of business mentality, it must also always be used to isolate the end user from choice. That is simply how big business in the US of A works.
I believe that it's simple dumb luck that we don't have to buy tires from the manufacturer of the vehicle we own. Sure, there is more to it, but think about how valuable the car analogies really are. Do we really want Nissan or Ford or VW designing the roads? Your driving experience depends on your choice of vehicle, and choice of roads. If we all drive MS cars and truck, using MS tires, on MS designed roads... where will the choice be?
Support NYCountryLawyer RIAA vs People
Javascript, like HTML, has grown to handle tasks it was never envisioned or intended to do when it was first created, and that has tremendous implications in the security space (cross-site scripting, cross-site request forgery, etc). Why not just scrap the HTML and Javascript specs and start over with something designed with security in mind from the get-go? Swapping Javascript for Python or Ruby only means that we get to write/deal with exploits with more syntactical sugar. Let's fix the darned problem once and for all.
I'd prefer to see scripts specify which language interpreter they're tested under, and the browser (or other executing object) retrieve an interpreter for it, caching them (and bundling popular ones if necessary). Why should old scripts stop working because they fixed something I never used in its interpreter, and left out the things I did use?
--
make install -not war
So you think that while right now we have partial and buggy implementations of one scripting language in most browsers, when we have two new additional scripting languages we'll have two well-supported, to-the-spec implementations of the two new languages in most browsers?
You want to give a website the ability to run client side perl?
Considering the amount of havok that is caused using javascript, a language that can't even actually write to a file, I can't even imagine the chaos that would be caused by perl, with all of it's methods for reading system states, and manipulating files and output devices.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Did you know that in Opera you can right click on a web page, select Edit Site Preferences and disable Javascript, or just disable the features the site abuses. No extension needed! And it runs perfectly fine on older machines since it doesn't leak memory like sieve like certain competing browsers. It's also free and cross platform just like them.
And it has fewer vulnerabilities -
http://news.softpedia.com/newsImage/Internet-Explorer-vs-Firefox-vs-Safari-vs-Opera-3.png
Plus since it has a tiny market share it's very unlikely anyone will bother to target it.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
The overview of the current ES4 proposal is here: http://www.ecmascript.org/es4/spec/overview.pdf
Go check it out and decide for yourself.
My guess is Microsoft realise that compatibility with JavaScript, HTML and other open standards is questionable in most browsers and they absolutely do not want to make it any better. After all, if the open standards were adhered to (and improved such as with ES4), who would care about Silverlight or .NET? I think that's the bottom line here. ES4 makes many fundamental improvements to JavaScript. It's not hard to think that ES4 + HTML + a strong Ajax lib might render Silverlight irrelevant. And Microsoft sure can't let that happen. Better to talk up problems in js and subvert every effort to improve. Meanwhile they'll push Silverlight as the solution to all the problems they're partly responsible for. The sad part is that Flex and venerable Java are still better solutions than Silverlight but we know how the industry loves the next best thing even if there is no need to.
But if MS creates a new language and it's beloved of "web developers", it won't take long to be implemented within Firefox, Opera and Safari. If not beloved and not supported, it'll die.
Deleted
And hopefully that arbitrator tells them all to just STFU up and use python :).
Yes, a language that parses whitespace like Python does would be great for client-side scripts run from a web browser.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
Purely for syntactical reasons. At the risk of ticking somebody off, I really dislike VB's syntax.
Javascript is in no way comparable to XUL. XUL is an XML layout dialect, JS is a programming language.
Also "Tacking on updates to existing standards only creates ugly security loopholes, and all sort of weird hacks."?
Yeah, that explains why Python 2.x is so much worse than Python 1.x and Perl 5 is so much worse than 4 and why the new versions of C, C++, C# and Java never caught on... Oh, wait.
Climate Progress - Hell and High Water
Your criticisms seem to be aimed at HTML and CSS, and at attempts to make up for their failings with Javascript toolkits. What Mozilla is pushing here is significant enhancement to Javascript in order to remedy many of its failings while maintaining backward compatibility. Microsoft, on the other hand, is trying to limit changes to the language. According to Eich, Microsoft is criticizing the ES4 proposal without offering concrete alternatives. Instead, he says, they are developing their own language in secret.
I think Javascript's a pretty good language. Certainly it's not perfect - few languages are. PHP, C++ and Perl spring to mind as being particularly flawed, but they have been indispensable nonetheless. Javascript has a huge installed base of runtimes and many programmers are familiar with it (so there's lots of bad code, which may be why JS has such a bad rep). We know how conservative most developers are about learning new languages (especially ones that don't look like C or BASIC), so there would be a significant cost and risk to trying to switch horses from Javascript to something else. Browser compatibility is another matter altogether - but we know who is causing the trouble there.
Javascript is practical and flexible; the main problems I have encountered are weak support for OO and larger projects - problems the ES4 effort appears to be trying to address. Microsoft's argument is for making minimal changes in favor of some unknown future language. If they really are working on that language in secret, and are able to complete it while Javascript is mired in controversy, the outcome is unlikely to be good for the rest of us.
That's exactly it. Some people are fond of saying "You know, it was actually Microsoft who invented AJAX because they had XmlHttpRequest() first" but if Microsoft had known that they'd be enabling a general-purpose platform for application delivery -- one that doesn't require Win32, or even a full desktop computer at all -- they'd have found another way or not done it at all.
Tired of FB/Google censorship? Visit UNCENSORED!
I agree with you, except for the Python part. Python is an ill fit for a language that's meant to be embedded in a (X)HTML, because (X)HTML does not honor content whitespace (and neither to a lot of related tools) and Python relies on whitespace for structure.
I could see trying to standardize a subset of Ruby though. Drop some of the ambiguous (or more difficult to implement parts) and access to operating system services (like fork(), etc), just keep the very basics necessary for pure code and modular OO, give it a well-though-out built-in object model for the DOM (and perhaps some built-in libraries of functionality for things like XML/XSLT, xmlHttpRequest-like stuff, etc), and keep the language compatible back to real Ruby (that is to say, all BrowserRuby code runs on a real Ruby interpreter, but not vice-versa).
Re-reading the above, it sounds like I'm basically describing a rehash of what the Javascript guys did. The difference would be that (1) We can do a better job today now that the problem domain is better understood, (2) It will actually be compatible (javascript code does not run in a real java environment unfortunately), and (3) It will be based on a much better language (no offense, but Java sucks).
Normally I advocate Perl over Ruby, but in this context Ruby probably makes more sense (in the very broadest sense, the languages are fairly comparable anyways).
11*43+456^2
Actually, I wrote a function for an application I'm developing (in Python) that fixes that problem to some degree with XML files. Example:
:)
<script type="text/python">
from template import *
who='Slashdot'
if not (who == ""):
s=Template('Hello, $n!').substitute(n=who)
else:
print "I'm confused!"
print s
</script>
will cause problems, since XML parsers tend to include all the whitespace and newlines and so forth. My function simply converts the tabs to spaces and then unindents everything deleting the number of leading spaces of the first line, which will never be indented in a valid Python script, from all the lines of the script.
Probably not something that hasn't been done before, but I did come up with it all by myself.
My blog
Firstly, at the time there were a huge range of "safe-for-scripting" ActiveX objects that could be created in IE. This was Microsoft's way of clutching every corporate shop that dared to use one in a death grip, instantly destroying their potential to have the versatility that a web application would normally bring. XmlHttp, found in the MSXML library, was just another safe-for-scripting object. At the time the web curious were already exploring a number of ways to do asynchronous calls, most commonly being hidden IFRAME updates, but there were a myriad of other options, including plenty of third-party XmlHttp type components, and even some Java Applet techniques for doing this.
This was a hugely growing need, and while Netscape was beaten to the ground and slowly regrouping Microsoft seemed to lead by default.
The point, I suppose, is that the invention of "AJAX" was absolutely, positively inevitable. Microsoft's influence in those early days is entirely the result of its monopoly, not its technical leadership.
Also "Tacking on updates to existing standards only creates ugly security loopholes, and all sort of weird hacks."? Yeah, that explains why Python 2.x is so much worse than Python 1.x and Perl 5 is so much worse than 4 and why the new versions of C, C++, C# and Java never caught on... Oh, wait.
.. but if you want another example of a language where tons of insecure and hacky cruft has accumulated over the versions, try PHP. Now there's a language that needs a complete restart if I ever saw one!
Your examples actually strengthen the point you are trying to argue against. C++ is indeed lots of new stuff tacked on to an existing language (C), with a result that is far from elegant and full of gotchas, as any newbie to C++ will know. C# and Java are both completely new languages, they can be called successors to C/C++ but neither even tries to be backwards-compatible and neither builds on the C++ standard. I don't know about Python and Perl
Quality, performance, value; you get only two, and you don't always get to pick.
I learned to program with VB, and still think its an acceptable language, and I agree with you 100%. Newlines mark the end of statements unless you add a '_', you Dim As, or just Dim (strongly typed or not, wtf?), and thats all I really can remember.
As someone who has written a 1000+ line AJAX app in the last 6 months, I can tell you that cross-browser incompatibilies already make programming javascript a bitch. I can't remember too many specifics, but I know that mozilla javascript implements arrays slightly different than IE, and it was a pain in the arse to CONSTANTLY patch around DOM issues. The breakdown of my time was probably spent 20% design, 20% code, 60% patching for IE.
Mod parent up. Anyone who posts anything else should read this first. At first I was a little learly of ES4 since I'm so used to ES3. After reading the overview, it's not that bad, and I don't understand what the big fuss is.
I have to agree with MS on this one. A radical update to Javacript has the potential to break more than I would care to think about. Major web applications can take months to simply test and years to design and implement! Major platform changes of this type are an unacceptable risk in the enterprise setting. Now, I fully agree that JScript is a horrible and broken implementation of the ECMAScript standard, but let's face it: JScript's own problems aside, Javascript as a language is not acceptable given what people are trying to do with the web. It was meant to provide limited dynamic capabilities to mostly static information delivery. That was yesterday, now let's take a serious look at today. I'm sorry if I'm offending any scripting fanboys, but weak typing, the lack of threading, the lack on non-prototypical OO features, the lack of a serious class library (including real data scructures), etc. all get in the way of delivering truly powerful client/server apps.
As I view it, casual web browsing and using a large-scale web application are fundamentally two different things, and demand two different approaches to development. Let ECMAScript/JScript/etc. stick around; it's sufficient for small-scale or casual needs. But if we're really talking about delivering large-scale, complex applications over the web, Javascript costs countless hours of productivity, and does limit the potential for what web applications might be able to deliver to users.
I'm completely in favor of creating a new language to meet the needs of tomorrow's web applications, provided that Microsoft and open source vendors work together in an open and honest fashion. This will only become a reality if all parties cooperate and make it a true standard. But on principle, yeah, Microsoft has the right idea on this one. (In my dream world, I would love to be able to deliver bytecode via HTTP, execute it in a tightly controlled sandbox, but still use the DOM as the UI delivery mechanism, but somehow I doubt that'll happen!!)
-James
Or they could create a very basic, low level bytecode interface to a browser and the DOM and then have any scripting language JIT compiled to that low level representation... at the script-standard bytecode-native compilation stage you can use program transformations to move towards your browser's native structure
Go one step further and provide some helpful jit compilation operations and somebody could just say <script language="{http://www.me.com}myscript}"< and the browser could download a jit compiler. Hey presto, browser-independent scripting.
I leave the implementation as an exercise to the reader
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
Microsoft's dream since 10 years is to rent web applications, since it will allow them to earn more and more money.
It's impossible to program Office with the current Javascript language.
So, Microsoft is trying to push Silverlight (since it's its own baby based on C#).
The battle that will result may see Microsoft's largest defeat.
First, this is a political battle, and every opponent has to make concessions, and M$ are not good at that.
Secondly, M$ is no more in a position to dictate how the Web should work, since the users have now a large choice of Web browsers (Safari and Firefox in particular). They still behave as if the Web was IE-centric.
Thirdly, Microsoft imposed his OS by crushing its competitors one by one. Due to the progress of Apple and GoogleOS, it's not any more possible.
Frankly, I don't see how Microsoft could win this battle.
If they count on their own forces, they will fail, like they failed with Vista.
If they expect a large developers support, they are wrong, since nobody (I mean nobody important) is supporting Silverlight.
If they count on a miracle, I think they had their share.
Once a technology standard will be decided, everything will depend on large Web companies, like Google.
You seem to be under the impression that JavaScript has some relationship to Java. It doesn't.
From the Wikipedia Javascript page:
"Despite the name, JavaScript is essentially unrelated to the Java programming language; though both have a common debt to C syntax. The language was renamed from LiveScript in a co-marketing deal between Netscape and Sun in exchange for Netscape bundling Sun's Java runtime with their browser, which was dominant at the time. The key design principles within JavaScript are inherited from the Self programming language."
Yes, I'm too lazy to find a better source.
I can't believe that nobody's pointed this out.
.NET and the CLR.
.NET runtime in the browser. Probably a sandboxed one that can only access the DOM and browser. But you still get all the .NET benefits, like multithreading and bytecode compilation. And all the .NET drawbacks, like you can't implement it outside of IE because it's patented from here to hell and back.
Microsoft wants a new language for client-side scripts. Just-so-coincidentally, Microsoft has this new "language" ready to go for us. It's called
C#, VB.NET, J#. Whatever. Microsoft wants a
See Silverlight? That's the tip of the iceberg.
Open your eyes, people. This is Microsoft.
Have you ever, honestly, been to a website that freezes Firefox?
Yes, I have. There's a dating/forums site called plentyoffish that regularly freezes Firefox for me (at least as of 2.0.0.8). Sometimes the browser recovers quickly, sometimes it recovers slowly, sometimes I give up waiting and kill it.
It's official. Most of you are morons.
There are some issues I have with the fact that there's no simple way for users to set trusted zone and Firefox security tends to throw the baby out with the bath water as far as security goes(no modal windows, no clipboard modification etc, I know why this is the case, but sometimes folks like me have legitimate reasons for these sorts of things). I'm also a bit annoyed with the whole "we'll fix it in 3.0" thing that's going on right now, but that's another story.
This all sounds like a wonderful story for the Mozilla corp, but it's not. While the bundling didn't help, Netscape got beaten by IE because IE was better. It's not now, but that's mostly because Microsoft have been slack bastards and sat on it for years.
I remember the browser wars well. I wasn't on the web for mosaic, but I was on for the browser wars. I know that having bundled IE got a lot of people on the net who wouldn't have otherwise gotten there, and I know that Netscape got bundled by ISPs for a while too. Netscape 4 was a great browser, it was better than IE 4, when I had to choose between those two, I used Netscape. However, Netscape 4 wasn't better than IE 5, and by extension it wasn't better than IE 6.
After Netscape 4 there was pretty much nothing for a number of years. Netscape 6 was an abomination, an unfinished rendering agent(gecko is great now but it wasn't done then). Opera was and is a great browser, probably the greatest browser of that time(might still be haven't played with it in a while) most of the innovations of the new era of browsers came from Opera, but it never caught on. Partly that was because in order to be faster it gave up on all the terrible web kludges and large chucks of the web in those days was terrible kludges. It could also be its linux reliance on QT which was bad back then, or the cost, who knows. You want to find a case for why a good browser failed, look at Opera, but back then Netscape wasn't in it and Mozilla wasn't done.
As for the reason why there are standards out there that nobody complies with, it's because the standards suck.
Two counter examples come to mind:
The abominable <marquee> is a microsoft invention, while <abbr> is still not supported by IE7.
I'm sure there are plenty more out there.
If you wanted to include an external *.py script, then yes it would be easy to control the whitespace and indenting as you would have the entire file created ahead of time.
But a lot of times your client scripting code is generated dynamically as a result of code running on the server (through Java, PHP, ASP, etc.). Often, these languages (especially tag-based languages like PHP or JSP) insert whitespace between different tags and it gets difficult to control their output precisely without doing works around the language. If that happens, your server script could put more or less whitespace than you intend into the dynamically generated *.py that would then execute incorrectly in the browser.
This gets even worse if your server code is not all generated in one block, but is assembled by a number of small blocks (like Struts/Tiles) as the small template that you are modifying may be included by another block (which is included by another) and if the indenting changes at the top level, you'll need to know and go find it in all the child levels to modify it.
Ever look at the source HTML to a lot of dynamically generated sites and wonder why there are odd patches of whitespace? Since it isn't (for the most part) significant in HTML, existing web server-scripting technologies have been built without necessarily caring about what it outputs. To suddenly need to care would mean re-working a whole lot of other tech just to make it work.
I'm not knocking Python or even its whitespace significance, but it definitely would introduce a huge problem for browser read scripts that weren't statically generated.
No doubt. I printed a copy so I could read it on the train... schlepped it to work/to home for two weeks... what a waste.
Then I found something far better... a CPAN project that implements a Javascript parser, using a YACC-like, Javascript 1.5 compliant syntax definition. Sweeet!!
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.