Become a fan of Slashdot on Facebook


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

MS, Mozilla Clashing Over JavaScript Update 521

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:
  • agree on using and implementing the same HTML and CSS standards. What? Never in a million years? OK, there's your answer for fixing/replacing JavaScript.
  • About Silverlight? (Score:5, Insightful)

    by Kelson ( 129150 ) * on Friday November 02, 2007 @02:42PM (#21215507) Homepage Journal
    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...
    • That's exactly what I was thinking, if I had mod points I'd mod you up. By keeping JavaScript back, they're also pushing Silverlight forward.
    • Re: (Score:3, Interesting)

      by LWATCDR ( 28044 )
      I would bet big money on that.
      I would love to see a good javascript replacement. I don't like javascript and find it kind of nasty to write in. I just don't want it to be under the control of Microsoft, Apple, or Adobe.
      • by cromar ( 1103585 )
        I would like to see a replacement as well. The obvious choices would be something like PHP or Python, maybe even Ruby. On the other hand, a functional programming language could be really interesting...
      • by Bitsy Boffin ( 110334 ) on Friday November 02, 2007 @08: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 Wylfing ( 144940 ) <brian&wylfing,net> on Friday November 02, 2007 @03: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 [].

      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.

  • Multithreading! (Score:5, Interesting)

    by Anonymous Coward on Friday November 02, 2007 @02:43PM (#21215517)
    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.
    • by cromar ( 1103585 )
      While that would be pretty neat, something like a Java or Flash solution is already available. Or, you know, writing a desktop app... Or, perhaps in-browser JavaScript interpretors could start optimizing a page's scripts to be multi-threaded with no changes to the language. I'm not sure how feasible that would be though.
    • Re:Multithreading! (Score:4, Insightful)

      by soliptic ( 665417 ) on Friday November 02, 2007 @02: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?

      • Re:Multithreading! (Score:5, Interesting)

        by _xeno_ ( 155264 ) on Friday November 02, 2007 @03:19PM (#21216101) Homepage Journal

        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?

        Yes, you would. The basic reason is that while, conceptually, you're right that you could use your solution to prevent the browser from locking up, you'd still have to worry about the page locking up.

        JavaScript code is generally only executed during events. These events include relatively minor things like scrolling, clicking, typing, or basically any form of interaction with the page. Now you could make the page code "smart" and avoid locking the page if there are no JavaScript event handlers interested in the current event, but you'd still potentially have issues where the page would essentially "freeze" until whatever long-running task completed. Since JavaScript events also fire when the page is unloaded, such a "freeze" could also prevent the user from navigating away from the page.

        This leaves us with a potentially responsive browser UI, but a tab that can't be used until its task completes. This is still better than the Firefox situation (and, due to the way Firefox is designed, something that isn't going to change in Firefox for a long while), but still undesirable.

        To allow the page to remain responsive while the page is doing some long-running task, you'd have to allow multiple threads so that the event handlers could run.

        This is, in a way, the problem that "asynchronous" part of AJAX solves. It doesn't allow another thread to be run via script, but it does allow the page to send the task back to the server to execute, allowing the page to remain responsive while whatever long-running task completes.

        I think a similar solution could work via JavaScript: instead of sending it off to the server, allow a script to be executed asynchronously. It would have no access to any information not sent to it when it was started (as otherwise the thread synchronization issues would remain), but it could run a task and then return a result.

        There can be some argument over whether JavaScript should ever be used for a "long-running task" but the reality is that more and more web applications are finding that it makes sense to allow certain tasks to run on the client instead of burdening the servers. Most clients have the memory and CPU to spare, and it makes sense to use those resources instead of making the bottle-neck be the server.

        Unfortunately the current solutions cause the page to become non-responsive while JavaScript executes and, in the case of poorly designed browsers, cause the entire browser to be non-responsive.

  • by cmowire ( 254489 ) on Friday November 02, 2007 @02: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.
    • by Metaphorically ( 841874 ) on Friday November 02, 2007 @02: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.
  • by Roadkills-R-Us ( 122219 ) on Friday November 02, 2007 @02: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@neDEBIA ... com minus distro> on Friday November 02, 2007 @02: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.

    • But that's exactly what Wilson is saying -- leave ECMA 3 as it is, broken and all, and add something new.
      • by Anonymous Coward on Friday November 02, 2007 @03: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.
        • Re: (Score:3, Informative)

          Are you trying to tell me that the addition of new reserved words to a language is a "small" change? [(ee the ES4 overview for details [].) Particularly when those reserved words are common terms like "cast"? Sorry, but that's major breakage, and not a small matter. If the default were to behave exactly as ES3 or ES4 interim, and the new restrictions only applied then, it might be a justifiable change -- but that is explicitly not what the overview says.

          Sorry, but this is BS.
          • by Briareos ( 21163 ) on Friday November 02, 2007 @05:46PM (#21218067)

            If the default were to behave exactly as ES3 or ES4 interim, and the new restrictions only applied then, it might be a justifiable change -- but that is explicitly not what the overview says.
            I don't know which overview you've been reading, but mine says this:

            III. Compatibility
            Some identifiers that were legal names in ES3 (let, yield, cast, is, and a few more) are keywords in ES4. Other keywords in ES4 were future reserved words in ES3, and correct ES3 programs do not use them (class, interface, public, private, and many others), though some implementations allow them to be used as names. Sometimes the new keywords are contextual and can continue to be used as names, but in general an ES4 implementation that must be able to process all ES3 programs must be told which dialect--ES3 or ES4--it is looking at, so that it knows whether to treat these identifiers as keywords or not.

            The mechanism that supplies the dialect information will depend on the environment. In a web browser the information comes from the MIME type of the script or from a version parameter on the SCRIPT tag in the document. New web pages that choose to use ES4 will have to specify the dialect.
            So unless you specify that some script block is actually version 4 ES4 interpreters are supposed to treat it as version 3 code.

            np: Savath & Savalas - Tormenta De La Flor (Golden Pollen)
  • by Anonymous Conrad ( 600139 ) on Friday November 02, 2007 @02:47PM (#21215599)
    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 <script type="javascript"> tags or not. One side says yes, other says we should keep that for older JS and put the new stuff inside <script type="ecmascript4"> 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?
    • by Stradivarius ( 7490 ) on Friday November 02, 2007 @07:23PM (#21219171)
      I think the argument goes like this:

      The existing Javascript/ECMAScript has a large installed base. Thus if you simply extend the existing spec in a backwards-compatible way, you allow developers to
      keep using Javascript and upgrade with new features at their convenience. This keeps everyone using Javascript and *should* be a smooth and gradual transition.

      However, if you switch to a require a separate mechanism to execute or a incompatible language, you force developers to rewrite their code in order to take advantage of the new features. This may be philosophically cleaner, but doesn't have the continuity benefit of the other approach.

      Now if you're Microsoft, which situation do you prefer? The second one, because it fragments the installed base and therefore the influence of the platform you don't control. That gives you an opportunity to sell people on using your technology platform instead, since they'll have to rewrite either way to use new advanced features. But if they don't have to rewrite completely, it makes more economic sense for developers to stick with Javascript.

      Now there may very well be other technical arguments too, but the above is why people are suspicious of Microsoft's arguments. After all, Microsoft knows very well the power of an installed base and the benefits of having control over common technology platforms.
  • Wishes (Score:3, Funny)

    by Tarlus ( 1000874 ) on Friday November 02, 2007 @02:50PM (#21215659)
    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...

    • by jddj ( 1085169 )
      If you're using <tables> for non-tabular data, you're part of the crowd perpetuating the problem, not driving the solution.

      Wanna do more than dream? Leave <tables> behind. Unless you're displaying tabular data, of course.
      • Re: (Score:3, Informative)

        by Tarlus ( 1000874 )
        Why? Is there a non-elitist reason to not use tables for a layout? I use tables because that's the one thing that'll work consistently between all the major browsers without having to spend several extra hours messing with the divs and underlying.
        • Re:Wishes (Score:5, Insightful)

          by jddj ( 1085169 ) on Saturday November 03, 2007 @12:07AM (#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.

  • brand new language (Score:3, Interesting)

    by l3v1 ( 787564 ) on Friday November 02, 2007 @02:52PM (#21215685)
    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.

  • by Animats ( 122034 ) on Friday November 02, 2007 @02: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.

    • by Trillan ( 597339 )
      Microsoft has a good point, but I don't think that's it.

      Microsoft's point seems to be that something new should be given a new name: "so we could continue supporting existing users as well as freeing the new language from constraints." That's a pretty good argument. In fact, I'd say it's an awesome argument.

      Now, granted, this is probably being suggested so Microsoft can say "We support JavaScript/ECMAScript, but not XyzScript." Bah. But the point about naming incompatible things differently (or, inversely,
    • I don't see a good way out of this. Who can provide leadership?
      I'm not usually a proponent of Java (quite the opposite, rather), but in this particular case, I cannot see why people would even think twice about adopting Java as the solution to these problems.

      We already have a hypertext web that works very well with XHTML and CSS (not that they don't have their flaws, as you rightly point out, but they certainly work). What people are looking for with AJAX and Silverlight and what not is ways of delivering programs over the Internet in a secure manner, and Java already has that problem solved with both applets and Java Web Start. Java is also both an open specification and open source and it has a number of interpreters for almost any platform you can beg for, it has been around for far over a decade, and is very mature by now.

      I don't see why people are not using Java. What's the problem? There are the obvious problems with Java being a horrible language to work in, but even so, it's probably still better than AJAX, Silverlight and Flash.

    • by Geof ( 153857 ) on Friday November 02, 2007 @04: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 [] 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.

      • by Blakey Rat ( 99501 ) on Friday November 02, 2007 @06: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.)
        • Re: (Score:3, Informative)

          by protohiro1 ( 590732 )
          As you noted, your issues are with the DOM apis, not the language. ES4 solves NONE of these problems and instead focuses on make JS more like Java. What benefit do we get from ES4? Its slightly easier to develop in? Yay, but that certainly doesn't do anything about the real issues: * Same origin security is broken and just makes it hard to develop mashup style aps * JS/DOM as implemented now is inherently insecure * Event listeners and dom interaction is memory hungry and slow * Regex implementation sucks
  • Wilson wrote that the proposed new standard may result in complications and incompatibilities with existing Web sites and applications.

    So, it works the same as always then? Everything seems normal with the new standard.

    What I want to see is a giant red T-Rex fighting a massive four-colour Butterfly...with the T-Rex stomping the Butterfly, completely altering the future.
  • Lets call it C# or linq instead of java and xsl2 just so we can force our own standard upon everyone.
  • Microsoft are right IMHO, JavaScript is a horrible language in many ways which are well known. I would much rather see a more modern language designed from scratch designed for the future of the web rather than hack in new features to JavaScript beyond the scope it was originally designed for. We also need better development environments for JavaScript as debugging it can be a royal PITA, while Firefox + extensions help it isn't perfect, a proper debugger would be great :)
  • As usual, Microsoft is attempting to wipe out an existing standard in favor of some new bastardized monster which it will control. Everyone will have to play catchup to Microsoft's ever-shifting language target, web developers will more than ever be stuck writing everything twice, once for IE and once for everything else. To further its monopoly, it will screw developers and consumers.

    I mean, and what the fuck is wrong with updating a fucking language? Christ, they've been doing it with C for the better
  • by TheNarrator ( 200498 ) on Friday November 02, 2007 @03:12PM (#21215981)
    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.
    • MOD PARENT UP (Score:4, Insightful)

      by IGnatius T Foobar ( 4328 ) on Friday November 02, 2007 @04: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 ergo98 ( 9391 ) on Friday November 02, 2007 @05: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 [], 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.
  • Language Plugins (Score:3, Interesting)

    by Doc Ruby ( 173196 ) on Friday November 02, 2007 @03:12PM (#21215997) Homepage Journal
    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?
  • by DrXym ( 126579 ) on Friday November 02, 2007 @03:29PM (#21216229)
    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.
  • I agree (Score:3, Interesting)

    by Yold ( 473518 ) on Friday November 02, 2007 @06:28PM (#21218529)
    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.
  • by compupc1 ( 138208 ) on Friday November 02, 2007 @06: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!!)
  • by Calroth ( 310516 ) on Friday November 02, 2007 @08: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.

We gave you an atomic bomb, what do you want, mermaids? -- I. I. Rabi to the Atomic Energy Commission