Forgot your password?
typodupeerror
Mozilla The Internet Microsoft Programming Software IT Technology

MS, Mozilla Clashing Over JavaScript Update 521

Posted by Zonk
from the minor-frustration-of-the-titans dept.
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."
This discussion has been archived. No new comments can be posted.

MS, Mozilla Clashing Over JavaScript Update

Comments Filter:
  • Why not both? (Score:1, Insightful)

    by magisterx (865326) <[TimothyAWiseman] [at] [gmail.com]> on Friday November 02, 2007 @01:39PM (#21215457)
    It seems they could both radically improve javascript and add in support for additional scripting languages. It would come at the price of increasing the size of the browsers, but that seems a small price to pay for the increased flexibility for developers.
  • Re:Why not both? (Score:2, Insightful)

    by Seumas (6865) on Friday November 02, 2007 @01:40PM (#21215477)
    By "flexibility", you mean "use javascript or MSVbActiveFlashScript"?
  • About Silverlight? (Score:5, Insightful)

    by Kelson (129150) * on Friday November 02, 2007 @01:42PM (#21215507) Homepage Journal
    Opera's Haarvard suggests that it's about Silverlight [opera.com], 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...
  • by cmowire (254489) on Friday November 02, 2007 @01:43PM (#21215527) Homepage
    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.
  • Re:Either way... (Score:3, Insightful)

    by blhack (921171) * on Friday November 02, 2007 @01:45PM (#21215551)

    I say IE and Mozilla battle it out, release the product, and may the best man win.
    Unfortunately, if that happens, the best man won't win. Firefox doesn't have NEARLY the market penetration required to actually stand toe to toe agains IE in something like this. Thats why there are "standards" out there that nobody complies with; because IE doesn't.

    There needs to be a third pary arbitrator here.
    And hopefully that arbitrator tells them all to just STFU up and use python :).
  • by Roadkills-R-Us (122219) on Friday November 02, 2007 @01:45PM (#21215559) Homepage
    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!
  • by The Master Control P (655590) <ejkeever@@@nerdshack...com> on Friday November 02, 2007 @01:45PM (#21215563)
    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.

  • Re:Either way... (Score:2, Insightful)

    by DanielJosphXhan (779185) <scatterfingers.w ... TScom minus poet> on Friday November 02, 2007 @01:50PM (#21215657)
    And the languages won't win either. Javascript will stall at its currently supported version as people strive for cross-compatibility.
  • by Metaphorically (841874) on Friday November 02, 2007 @01:53PM (#21215699) Homepage
    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.
  • Re:Why not both? (Score:4, Insightful)

    by apt142 (574425) on Friday November 02, 2007 @01:56PM (#21215759) Homepage Journal
    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.
  • by Animats (122034) on Friday November 02, 2007 @01:58PM (#21215783) Homepage

    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.

  • Re:Multithreading! (Score:4, Insightful)

    by soliptic (665417) on Friday November 02, 2007 @01:59PM (#21215803) Journal

    Disclosure: I am a web developer, but my use of javascript extends only as far as your "simple things like rollovers". (Well, not actually rollovers, that's done in CSS unless you're an idiot, but...) I am not a "proper" Developer. Hence, this genuine question:

    To solve the problem of "the UI stalls the processing or the other way around" (which, funnily enough, I only ever really encounter right here on Slashdot), why would the script language need to provide multithreading to the script author (typical or otherwise).

    Surely you could solve that particular issue by running Firefox-itself code in one thread, and on-page-javascript-or-whatever-script in another thread (or perhaps one thread per .js, or per site, or per tab, or whatever). You wouldn't need to actually let the script writer work in multiple threads, would you?

  • by Spiked_Three (626260) on Friday November 02, 2007 @02:01PM (#21215831)
    "Opera's Haarvard suggests that it's about Silverlight [opera.com], 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..."

    Insightful? Come on, that's rubbish. It is a simple minded microsoft bash with no basis in fact or reasoning, and yet it gets moderated insightful.

    Silverlight is not about competing with Javascript at all. It's about bringing robustness to web apps. It's about being slightly compatible with desktop apps in code. Those are things that current web technologies, even with AJAX, can not do. Silverlight is about competing with adobe flash, which by the way is way ahead of microsoft at the moment for the robust web app space, so why did you choose to bash Microsoft and not adobe? Never mind, we know the answer.

    Mozilla, opera and other pushing to extend open web technologies? Please .... how does a fight between what version 2 of something is named have anything to do with extending open technologies? You are throwing around buzzwords to make yourself sound smarter (and some moderators fall right for it). Microsoft is saying we have a standard, we have products that are written to that standard, and it will be expensive to supercede that standard with a replacement. They have no objections to something new, just dont break the old.
  • Ug. (Score:5, Insightful)

    by SatanicPuppy (611928) * <Satanicpuppy@MOSCOWgmail.com minus city> on Friday November 02, 2007 @02:09PM (#21215953) Journal
    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.
  • by Anonymous Coward on Friday November 02, 2007 @02:09PM (#21215957)
    And that is exactly what ECMA 4 does: it leaves ECMA 3 as it is (except for a few really minor and obviously broken things that everyone except for Microsoft agrees on), and then adds some sorely needed extras on top of it which the open web really needs in order to stay competitive with the closed-offerings by the likes of Microsoft.
    All current-day JavaScript will continue to work! Backward compatibility has been the number one goal during the development of ECMAScript 4. But Microsoft is scared - web applications have finally started fulfilling the original promise shown by Netscape, making the OS largely irrelevant. And so Microsoft is throwing up any- and all roadblocks it can think of, stalling for as much time as possible in order to create enough lock-in with WPF e.a. that they'll remain relevant. Understandable, of course - they're a company, trying to survive. But a really bad thing for the open web, and something which must be overcome.
  • by parvenu74 (310712) on Friday November 02, 2007 @02:12PM (#21215989)
    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.
  • Re:Why not both? (Score:5, Insightful)

    by msuarezalvarez (667058) on Friday November 02, 2007 @02:14PM (#21216025)
    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?
  • Seriously? (Score:3, Insightful)

    by SatanicPuppy (611928) * <Satanicpuppy@MOSCOWgmail.com minus city> on Friday November 02, 2007 @02:15PM (#21216041) Journal
    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.
  • by Kelson (129150) * on Friday November 02, 2007 @02:16PM (#21216045) Homepage Journal

    You are throwing around buzzwords to make yourself sound smarter (and some moderators fall right for it).

    By "you," are you referring to me, the person who summarized something that I thought was an interesting take on the issue, or to Haarvard, the person who actually made the assertion and discussed it in detail?

  • by Wylfing (144940) <brian@wyMOSCOWlfing.net minus city> on Friday November 02, 2007 @02:18PM (#21216065) Homepage Journal

    Microsoft is saying, wait, the web doesn't need to be extended at all! Well, except with Silverlight and WPF

    Those are actually Brendan Eich's words. The extended commentary from which that comes is over here [mozilla.org].

    MS do indeed want to close the internet, and the name of the game is "patent encumberance." It's going to be too hard to lock up JavaScript, so they don't want to play with that anymore. They need to have everyone investing in a new MS-proprietary, patent-encumbered language.

  • by Anonymous Coward on Friday November 02, 2007 @02:25PM (#21216163)
    Do you really think it is a good idea to insert a whitespace meaningful scripting language (Python) into whitespace meaningless HTML? The level of indenting in HTML has no effect on the rendering, but change the indenting in Python and you've borked your script.

    Seriously, Python would be the WORST language to use for scripting in HTML.

    Javascript is actually pretty good, the only reason it has a bad name is from the different browser implementations and different DOM accessing methods. Fix that, and add some more convenience libraries / functions and you are set.
  • by Arthur B. (806360) on Friday November 02, 2007 @02:27PM (#21216191)
    Because HTML and javascript

      - have know been widely field tested, their strenght and shortcomings are known, there are hundreds of implementation of them that have been heavily tested and debugged, this is extremely precious
      - it is widely adopted, switching represents a huge cost for the whole industry (not only it pro but all the people in the world who live by selling html developpement)

    While starting from scratch looks pleasant, for big things (and html is *big*) gradual changes are more appropriate.
  • by PHAEDRU5 (213667) <instascreed.gmail@com> on Friday November 02, 2007 @02:33PM (#21216285) Homepage
    "Embrace and Extend" not working, Microsoft goes with "Repudiate and Close".

    I expect a Dilbert strip about this any day now.
  • Re:Either way... (Score:5, Insightful)

    by blincoln (592401) on Friday November 02, 2007 @02:38PM (#21216371) Homepage Journal
    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.
  • Re:Why not both? (Score:4, Insightful)

    by cromar (1103585) on Friday November 02, 2007 @02:38PM (#21216381)
    Purely for syntactical reasons. At the risk of ticking somebody off, I really dislike VB's syntax.
  • Re:Either way... (Score:3, Insightful)

    by Randle_Revar (229304) * <kelly.clowers@gmail.com> on Friday November 02, 2007 @02:40PM (#21216407) Homepage Journal
    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.
  • Re:Sure (Score:2, Insightful)

    by markjl (151828) on Friday November 02, 2007 @02:45PM (#21216449)
    I seem to remember VBScript, it's a perfect example of MicroSoft's agenda and why JavaScript should evolve instead of fork. From a pragmatic point of view, there might have reason -- but it's clear that MicroSoft's agenda is neither technical, nor pragmatic. Image M$ advancing the same argument for forking Java into a new language when new functionality/semantics were planned? It's ridiculous.
  • Re:Sure (Score:1, Insightful)

    by JCSoRocks (1142053) on Friday November 02, 2007 @02:51PM (#21216545)
    In which case we'll be right where we are now... with old JavaScript and the addition of some useless language. Microsoft always wants to make a new language. I'd absolutely vote for the improvement of JavaScript, it makes sense and all browsers can (theoretically) be relatively easily updated to support it. Additionally, developers are busy enough keeping up with the constantly changing landscape, we don't need *another* freaking language. There are plenty. Just add the features it needs and fix the bugs.

    oh, and one more thing... please, please, please, can we do something about the insane code necessary to make JavaScript work on the two major browsers? It's ridiculous the amount of garbage you have to throw in just to cover yourself for the last two versions of the two big browsers. Can we just make browser upgrades mandatory or patch old versions or something? (I know that'll still leave me with the Mozilla / IE differences but then I only have to worry about two browsers instead of four.)
  • Re:Sure (Score:2, Insightful)

    by Neo_piper (798916) on Friday November 02, 2007 @03:03PM (#21216703)
    Don't forget all the fun with JScript in Internet Exploder.
    But seriously folks if one way or another it's gonna be a different language, just call it "Javascript+ ver.1" instead of "Javascript ver.N+1" as long as you keep the ability to run "Javascript ver.N" in the browsers I don't see whats to bitch about in making it a different language.
  • by Geof (153857) on Friday November 02, 2007 @03:07PM (#21216757) Homepage

    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 [burningbird.net] 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.

  • MOD PARENT UP (Score:4, Insightful)

    by IGnatius T Foobar (4328) on Friday November 02, 2007 @03:10PM (#21216809) Homepage Journal
    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.
  • by DragonWriter (970822) on Friday November 02, 2007 @03:27PM (#21217097)

    Silverlight is about competing with adobe flash, which by the way is way ahead of microsoft at the moment for the robust web app space, so why did you choose to bash Microsoft and not adobe?


    Because the story being discussed here isn't about Adobe lobbying a standards body in an effort to hold back adding new functionality to an open standard that could provide an alternative to closed add-on technologies like Silverlight and Flash.

    If it was, people would be bashing them for trying to push the dominance of their proprietary solution by holding back standard, non-proprietary technology in the exact same way that Microsoft is being criticized here.

    Microsoft wasn't criticized for having Silverlight, they were criticized for the manner in which they were perceived to be promoting Silverlight.

    Mozilla, opera and other pushing to extend open web technologies?


    Yes, they are.

    Please .... how does a fight between what version 2 of something is named have anything to do with extending open technologies?


    That's not what the dispute is over. The dispute is over whether Release 4 of ECMAScript should:
    1) Include major new functionality, or
    2) Include only minor new functionality, with major changes outside of the scope of the standard and left for other languages (either proprietary or part of different standards efforts.)

    The first position favors substantial extensions to non-proprietary, freely-implementable standards for the web. The second does not.

    Microsoft is saying we have a standard, we have products that are written to that standard, and it will be expensive to supercede that standard with a replacement.


    A new version of a standard doesn't impose costs; no one is obligated to support the new version. ECMAScript Releases 1-3 won't stop working when a specification for ECMAScript Release 4 is released.

    OTOH, more features in the standard means more that can be done within the scope of the standard and without non-standard, proprietary alternative technology.

    They have no objections to something new, just dont break the old.


    New standards, even ones that aren't backward compatible, don't break old standards. ECMAScript 3 implementations don't break just because there is an ECMAScript 4 standard.
  • Re:Ug. (Score:4, Insightful)

    by multi io (640409) <olaf.klischat@googlemail.com> on Friday November 02, 2007 @04:14PM (#21217693)
    JS has several features that e.g. Python lacks, for example prototypes, open/classless objects and closures. JS bashers usually know little about JS and largely perceive it as a web toy, something like VBA with Java syntax and without the IDE. The fact is, you can write real, reusable, object-oriented software in JS, without going crazy in the process. There are deficiencies and incompatibilities in the various browser runtimes, but those are neither JS's fault nor will they magically be avoided by inventing some new language.
  • by blazerw11 (68928) <blazerw AT bigfoot DOT com> on Friday November 02, 2007 @04:23PM (#21217815) Homepage

    It's about bringing robustness to web apps.
    I stopped reading your quote here because the only person that would say that is somebody from Microsoft's marketing department.
  • by ergo98 (9391) on Friday November 02, 2007 @04:40PM (#21218013) Homepage Journal

    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

    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 [yafla.com], 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.
  • Re:Either way... (Score:3, Insightful)

    by W2k (540424) <`moc.liamg' `ta' `suilesnevs.mlehliw'> on Friday November 02, 2007 @04:48PM (#21218087) Homepage Journal
    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.

    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 .. 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!
  • by Rysc (136391) * <sorpigal@gmail.com> on Friday November 02, 2007 @04:48PM (#21218089) Homepage Journal

    No Microsoft is not pushing Sliverlight and WPF here. OR saying scripting does not need to be extended. They are saying there needs something better than javascript
    It's true that this is not what Microsoft is actually saying, but you can be sure that's what they mean and want.

    Frankly anyone that thinks the present javascript is worthwhile keeping just has not programmed enough in it
    I have done a ton of work in javascript for the last decade or so, and you are very wrong. Javascript has always had its pains, but the pains are not inherent in the language and (very importantly!) these pains are rapidly going away. Throwing JS out now back before Mozilla 1.0 might have been reasonable, but by now JS support in all browsers is to a point where throwing out JS would be *stupid*.

    JS as a language is not fundamentally broken!
  • Re:Sure (Score:3, Insightful)

    by Neo_piper (798916) on Friday November 02, 2007 @04:55PM (#21218171)
    Yes you can make browser updates mandatory, by simply refusing to support the old ones. ( all hail Cthulhu )
    You know the same way Apple and Microsoft force you to get new computers if you want to run the "New And Improved With 25% Fewer(?) Gaping Security Holes Operating System"
    But that would require organizing developers into some form of union.
  • by Blakey Rat (99501) on Friday November 02, 2007 @05:26PM (#21218521)
    The current Javascript has a lot of bad bits, though.

    How come IE uses "innerText" and Firefox uses "textContent"? Right there is a little compatibility function nearly every single Javascript in the world needs to write to work correctly.

    Why is there no "GetElementsByClassName?" Another function nearly every Javascript needs.

    How come the various "geometry"-returning functions have some baffling results? How come it's so hard to answer basic questions like, "did the user scroll to the bottom of the webpage?" What the hell is a "userAgent" anyway? Does the measure of it include toolbars? Status bar? How come the screen functions return different results for IE and Firefox on multiple-monitor systems? How come the screen functions don't even *support* multiple-monitor systems?

    Why does Firefox insert blank text nodes into the DOM while IE doesn't?

    How come my Javascript can't tell if a TextArea has text selected or not?

    How come the internationalization features suck so much?

    Why does "XMLHttpRequest" have such a strange name? Are acronyms supposed to be in all-caps or not, because that function shows it both ways.

    There are a hundred problems, not necessarily with Javascript, but with Javascript's interaction with the DOM and browser. I think it's clear that both IE and Mozilla are right in that *something* needs to be done. Whether it's a new language or a new direction for JS, I dunno. (I like the language itself, for the record.)
  • by Anonymous Coward on Friday November 02, 2007 @05:39PM (#21218655)
    For fairly well-defined problems. GSM isn't a great cell phone standard, but it has allowed European cell phone manufacturers to take over the global marketplace while American cell phone companies with splintered standards have had to play catch up for more than a decade now.

    C++ is an example of horrible design by committee, with ever shifting basic functionality and over complexity. But the updates to C (by committee) have been very reasonable and useful. Germany's design by committee of power plugs has been great for Europe, and has even taken over Britain's mishmash of plugs that has been a plague and a bane to the folks of the island. The metric system has worked out pretty well for everyone.

    When the problem is old and simple, committees do a great job of explicitly laying out the pre-existing consensus. When the problem is new and interesting, with no clear solution, committees produce a self-conflicting hodge-podge solution that is always behind the times.

    It's not necessarily post-facto, but just not innovative. They're not the same thing. I'm not sure how much "innovation" is really needed for the next generation of js. I'd hope that the problems and their technical solutions are pretty clear by now, and just implementation and standardization are needed. If that's the case, design-by-committee is probably the best thing that could happen.
  • by compupc1 (138208) on Friday November 02, 2007 @05:55PM (#21218851)
    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!!)
  • Re:Why not both? (Score:3, Insightful)

    by pdbaby (609052) on Friday November 02, 2007 @06:02PM (#21218957)

    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

  • by Bitsy Boffin (110334) on Friday November 02, 2007 @07:09PM (#21219717) Homepage
    Javascript is a beautiful ulimately flexible language, implementations of it (esp Microsoft's) may suck, but the language itself is very good. Learn to use it properly, prototypes, closures, higher order functions... and you will soon learn what a remarkable language for scripting it is.
  • by Calroth (310516) on Friday November 02, 2007 @07:16PM (#21219761)
    I can't believe that nobody's pointed this out.

    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 .NET and the CLR.

    C#, VB.NET, J#. Whatever. Microsoft wants a .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.

    See Silverlight? That's the tip of the iceberg.

    Open your eyes, people. This is Microsoft.
  • Re:I agree with MS (Score:1, Insightful)

    by Anonymous Coward on Friday November 02, 2007 @09:33PM (#21220691)
    No, JavaScript is NOT a horrible language. It's a fairly standard dynamically typed language, with prototype-based OO, and a small set of simple, flexible datatypes. It's consistent. It's logical. As long as you're not after C++, it makes sense, especially for web site scripting.

    It gets better if you start using the language features supported by Firefox, but not IE. Things like E4X, for example, make dealing with XML data trivial.

    There are basically three problems with JavaScript as-is.

    First, people (you included, apparently) seem to think of JavaScript in the way it was used back in '98 or so - basically no better than BASIC with C-style syntax.

    Second, Internet Explorer's DOM. It's inconsistent, buggy, and makes things unnecessarily difficult.

    Finally, Internet Explorer's implementation of JScript. Which is a pile of junk, almost impossible to debug, and has an irritating tendancy to crash the entire browser if you use complex scripts.

    Obviously, upgrading IE's support for JavaScript would fix the latter, but there's no chance of fixing the second, and the former is simply a matter of perception (helped by IE, which fights you if you try to do anything useful with JavaScript).

    Besides, Microsoft don't care about breaking the web - they care about breaking all the poorly written intranet apps (including their own, such as OWA) which rely on bugs in IE to work.
  • Re:Wishes (Score:5, Insightful)

    by jddj (1085169) on Friday November 02, 2007 @11:07PM (#21221239) Journal

    Is there a non-elitist reason to not use tables for a layout?

    There are many. Let's try a few:

    • Semantic, linear structure of the page. When one forces a layout into a table, almost invariably the "reading order" of the page gets fouled up. Text content that probably should be readable in top-to-bottom order gets split up into left-to-right cells (in page-load order). This plays havoc with the ability to repurpose the page for mobile devices, pdfs and screen readers, and (perhaps more importantly to the folks signing the checks) makes the page harder for search engines to understand, potentially lowering your page rank. By creating a page that makes semantic sense and using <div> tags and other parts of HTML properly (parts like <h1>, <p>, <ul>, etc.) you help convey to the search engine what the page is about.
    • Ease of updating. When you need to change the layout of a page created in tables, you have to reconfigure all the tabled content, moving some from cell to cell, changing colspans, etc. If instead you've made semantic sense of the content, you can move the content around the page with CSS, never having to touch the HTML. You can even do things like change lists of links from vertical nav trees to horizontal tabs without changes to HTML.
    • Ease of creating printable pages. When you lay out in tables, you may be able to "hide" display of the tables in the print style sheet, but browser problems may push content around the page anyway (have been struggling with this in a poorly-designed page this week). With tableless layout, it's easy to hide the elements on the page you don't want to see in the printout, set size and margins for the elements you do, then do a window.print()
    • Separation of content from presentation. When tables are in use, typically related content is plunked into adjacent cells (image slicing anyone?). When this happens, the presentation (layout) is tangled up with the content. This is difficult to maintain. The developer and the designer have to touch the same page for different reasons. When the page has to be edited for layout, the designer has to know enough about the table code to do things like remove or insert colspans, when in fact there are no columns of tabular data.
    • You get to break out of the grid and use flexible (even liquid) layout. You can move things around, put 'em in front of or in back of other items, never having to worry about running out of cells or keeping colspans straight.
    • When all else fails in trying to make a table layout do something it was never intended to do, designers make "pictures of type" so the layout observes their wishes. This is a huge mistake for searchability and accessibility. The search engines can't read the pictures any better than the blind can.
    • Table-based layouts typically get really, really screwed up when the user resizes the fonts in her browser. Trust me: I'm doing this all the time 'cause I don't want to bother with reading glasses.
    • Layout is not tabular data. It's just not. Tables work great for tabular data, and they have many features to render spreadsheet-like pages with clarity.
    • It's a misuse of a feature of the language. You might think this is elitist, but would you also imply that the suggestion that someone stop using a Crescent wrench as a hammer is elitist? Or might you instead think: "there's a better tool for that job - one that's designed to do it well".
    • It's the right thing to do for the disabled. Not bothering to lay out the page well so the visually impaired can read it could be interpreted as elitism on the part of the sighted.

    Is that good for a starter? I'm about out of time to spend on this...

    I don't think that browser support for tableless layout is perfect. It's awful in older browsers, but getting better all the time.

    In any case, it's the browser's job to render the standard properly, not yours to break the code for the browser. I find the middle-ground is to keep the layout pretty basic to get broadest browser support, and tolerate browser differences. I'd never promise pixel-for-pixel cross-browser support. HTML isn't designed to do that.

  • by Anonymous Coward on Saturday November 03, 2007 @05:26AM (#21222511)
    You want to add

    //works 99% of the time (thanks to pesky exceptions such as DST and leap years)
  • Re:Either way... (Score:3, Insightful)

    by ip_vjl (410654) on Saturday November 03, 2007 @06:23AM (#21222703) Homepage

    While I don't agree that python would be a good idea, counting it out because of its whitespace would be stupid.
    You could include scripts, just like like you include javascript and css outside of the html.


    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.

The world is no nursery. - Sigmund Freud

Working...