Forgot your password?
typodupeerror
Programming The Internet IT Technology

Was Standardizing On JavaScript a Mistake? 525

Posted by CmdrTaco
from the hindsight-is-twenty-twenty dept.
snydeq writes "Fatal Exception's Neil McAllister questions the wisdom of standardizing on a single language in the wake of the ECMA Committee's decision to abandon ECMAScript 4 in favor of the much less ambitious ECMAScript 3.1, stunting the future of JavaScript. Had the work continued, McAllister argues, it could have ushered in an era of large-scale application development that would ensure the browser's ability to meet our evolving needs in the years ahead. 'The more I hear about the ongoing efforts to revise the leading Web standards, the less convinced I am that we're approaching Web-based applications the right way,' McAllister writes. 'If anything, the more we talk about building large-scale Web applications, the more we should recognize that a single style of programming will never suit every job.' McAllister's simple truth: JavaScript will never be good for everything — especially as the Web continues to evolve beyond its original vision. His solution? 'Rather than shoehorning more and more functionality into the browser itself, maybe it's time we separated the UI from the underlying client-side logic. Let the browser handle the View. Let the Controller exist somewhere else, independent of the presentation layer.'"
This discussion has been archived. No new comments can be posted.

Was Standardizing On JavaScript a Mistake?

Comments Filter:
  • Got it wrong (Score:5, Insightful)

    by AKAImBatman (238306) * <akaimbatman@gmai[ ]om ['l.c' in gap]> on Thursday August 21, 2008 @11:11AM (#24689833) Homepage Journal

    So here's an idea: Your Web browser window is a View. Maybe it's high time we stopped trying to force it to be a Controller, too.

    Here's an even better idea: The HTML DOM would be the View, the Javascript would be the Controller, and the server would be the Model! I'll bet I'm the first one to think of that...

    So if nobody ever managed to come up with the ultimate, perfect language for systems programming, what makes us think we can do it for the Web?

    The browser model allows for languages other than Javascript. (e.g. VBScript is somewhat popular in IE-only applications.) It's just that no one has come up with a better language. If no one comes up with a better language, why reinvent the wheel?

    Ever since the early days of Web browsers we've had this language, JavaScript. Over the years, we've demanded more and more of it, to the point that we're now talking about using it to build entire applications. The simple truth, however, is that JavaScript will never be good for everything.

    That's one person's opinion. My opinion (and the opinion of many others) is that Javascript is a very powerful LISP-like langauge capable of far more than its given credit for. Part of the reason for abandoning ECMAScript 4 is that v3 already supports most everything we need. It's not perfect, mind you, but it doesn't actually NEED the features of v4. Most of those features are syntactic sugar that makes the language more comfortable to Java programmers.

    Behind the scenes, nothing really changes with the common features of v4. There's some type checking and a few other minor additions going on, but otherwise the objects are translated into Javascript objects.

    Strong typing, packages, and namespaces may make it a lot easier to maintain large applications, but they're virtually useless to any Web coder who just wants to bash out a little bit of UI glitz.

    And there-in lies the problem. People think of Javascript as being for "UI Glitz". That's the real issue to tackle. Not the imagined lack of MVC.

    • Re: (Score:3, Insightful)

      by mcvos (645701)

      It's just that no one has come up with a better language.

      No one has been able to come up with a better language than javascript? That's a scary thought.

      • Re:Got it wrong (Score:5, Insightful)

        by Swizec (978239) on Thursday August 21, 2008 @11:30AM (#24690107) Homepage
        The problem with javascript isn't that it's a bad language, the problem is that everyone continues on thinking about it as a tool for quick and dirty hacks. But guess what, that's how PHP started out and look where it came.

        All javascript really needs is to be well supported in all browser and that people would stop thinking about it as just a script kiddie tool. Javascript is perfect for what it was intended to do and it's very good even for what it wasn't exactly intended to do and THAT's why there hasn't been a "better" language yet, because this one is good enough for the job. Frankly, outside of becoming standardised all over, I don't see what more you might want in javascript that you absolutely cannot live without.
        • Re:Got it wrong (Score:5, Informative)

          by coryking (104614) * on Thursday August 21, 2008 @11:41AM (#24690269) Homepage Journal

          I don't see what more you might want in javascript

          - A real way to include other javascript files.
            - A well defined way to say "The page is loaded, all your variables and objects are loaded, Time to execute!" rather then "You can only see the variables and objects that are defined 'above' you and not 'below' you in unloaded portions of the page".
            - Ponies.

          • by Chaos Incarnate (772793) on Thursday August 21, 2008 @11:51AM (#24690437) Homepage
            Any spec without ponies is a defective spec indeed.
          • Re:Got it wrong (Score:5, Informative)

            by DougWebb (178910) on Thursday August 21, 2008 @12:28PM (#24691039) Homepage

            - A well defined way to say "The page is loaded, all your variables and objects are loaded, Time to execute!" rather then "You can only see the variables and objects that are defined 'above' you and not 'below' you in unloaded portions of the page".

            jQuery's [jquery.com] $().ready( function() {...} ); method has been a fantastic help in my Javascript development. It executes after the DOM has been initialized, but before all of the images have been loaded. window.onload() waits for the images to load, which delays your javascript from running until after the page has been rendered. jQuery doesn't do that; your code will often run before the page is rendered, so you can use javascript to enhance/replace elements that work without javascript too. For example, I often have UI controls which will refresh the entire page to perform their function when javascript is not enabled, but they'll use AJAX and refresh only the necessary elements if javascript is enabled. Using jQuery, I can attach events and alter CSS classes before the user sees the page, so javascript and non-javascript users get somewhat different looking, somewhat different behaving, but always fully functional views of my application.

        • Re: (Score:3, Insightful)

          by Mr2cents (323101)

          Leaving the language itself aside, the big problem I see when reading javascript is all these tests to check on what browser it is running. If I write code, I don't wan't that mess (Luckily, I I'm not a web developer).

          • Re:Got it wrong (Score:4, Informative)

            by erlando (88533) on Thursday August 21, 2008 @11:53AM (#24690469) Homepage

            Leaving the language itself aside, the big problem I see when reading javascript is all these tests to check on what browser it is running

            In modern Javascript usage you leave that to a framework library such as Prototype, mooTools, jQuery, Dojo etc.

          • Re: (Score:3, Insightful)

            by dword (735428)
            That's not really the problem. Standard JavaScript is supported on most browsers (all popular browsers) in a more uniform way than anything else is. The real problem is the way access to the DOM was implemented, not the language it's self. People realized there were certain needs for certain features (ie, like selecting text in an input element) so they implemented those features in their own proprietary ways and left them the way they were done.
            Some browsers include newlines in the DOM, some don't. If you
        • Re:Got it wrong (Score:5, Insightful)

          by Cecil (37810) on Thursday August 21, 2008 @11:46AM (#24690351) Homepage

          But guess what, that's how PHP started out and look where it came.

          What it became? A tool for quick and dirty hacks that many people use to create applications that inevitably turn into a quick and dirty hack?

          • Re:Got it wrong (Score:4, Informative)

            by Kozz (7764) on Thursday August 21, 2008 @12:35PM (#24691165)

            PHPMyAdmin, OSCommerce, CodeIgniter... yep. Just quick and dirty hacks. Come on, lay off the generalizations.

            PHP doesn't make crappy code, coders do. The same could be said (and has been said) about Perl, but it doesn't make it true.

            • Re: (Score:3, Interesting)

              by gaspyy (514539)

              You may be right, but you got the wrong examples.

              I don't know CodeIgniter, so I can't comment on it.

              PHPMyAdmin is an useful app, but if you ever used MSSQl admin tools, you'd know it doesn't come anywhere near.

              As for OSCommerce... LOL. Have you looked at the code? It's the very definition of dirty.

        • One of the biggest issues I've had with it is the poor performance (relative to what it's being asked to do) in the current browser engines. The good news is the current advances (e.g. WebKit) give me great hope.

          • Re: (Score:3, Insightful)

            by mcvos (645701)

            One of the biggest issues I've had with it is the poor performance (relative to what it's being asked to do) in the current browser engines.

            One thing I learned to avoid is big iterations. Keeping your loop as short, efficient and preferably absent as possible has a surprisingly big impact on javascript performance.

        • Re: (Score:3, Insightful)

          by hey! (33014)

          Well, if you're going to standardize the object model, how much of a larger step would it be to define a virtual machine to go along with it? Then you could use any language you like, provided that it could be compiled for the VM.

          It's funny that this wasn't the way things went, because that certainly works for many developers who don't want to share code, aside from the other things that would make this convenient. On the flip side, it's probably done a lot to encourage open source web UI frameworks, so i

        • Re: (Score:3, Funny)

          by geminidomino (614729) *

          But guess what, that's how PHP started out and look where it came.
           

          To set that bar any lower, you'd need a spade.

      • Re: (Score:3, Insightful)

        by mini me (132455)

        Javascript is an amazing language. The C-like syntax gets in the way occasionally, but all-in-all it's up there with the best of them.

        The problem is that most people do not even realize that it is an object oriented language, let alone containing functional language features as well.

        • Re: (Score:3, Insightful)

          The biggest problem that I've seen is that nobody knows how to code it. With C, C++, Java, and even PHP there's a set of standards that everyone adheres to with objects, functions, loops, etc. Then you bring in Javascript with a completely different paradigm and suddenly the old standards don't apply. When defining functions on the fly, do you use Function(), function *name* {}, eval...? How do you use the prototype? When do you use closures? Most people don't even know how to use these, much less when to u
    • Re:Got it wrong (Score:5, Interesting)

      by tomtomtom777 (1148633) on Thursday August 21, 2008 @11:24AM (#24690011) Homepage

      I strongly agree.

      I even believe the features of v4 will unnecessarily complicate the language. Most problems in javascript arise when people try to mimic 'normal' OO-behaviour instead of using javascript's powerful prototype-based system as given.

      Javascript is extremely useful to create large scale applications but most programmers are to much educated towards 'convetional' OO-programming to use it right.

      I guess it is the same problem as with functional programming, which is often preferable above OO-programming for the server-side model layer. The mindset of the common programmer is simply not diverse enough to use a completely different approach, such as prototype-based or pure functional programming

    • Re: (Score:3, Interesting)

      Wait, nobody has come up with a language better than Javascript? That's funny, because when I think of useful scripting languages, I tend to think of...AWK, PERL, Python, etc. There is nothing stopping someone from integrating one of those languages into a web browser, nor anything stopping a standard "Web Python" from being created, with a specific standard library for web apps (on the client side, that is).
    • Re: (Score:3, Insightful)

      by kingmundi (54911)

      >> It's just that no one has come up with a better language. If no one comes up with a better language, why reinvent the wheel?

      The best language does not always gain mindshare.

    • Re:Got it wrong (Score:5, Insightful)

      by Blakey Rat (99501) on Thursday August 21, 2008 @11:31AM (#24690123)

      I agree that Javascript/ECMAScript is an excellent language.

      Real web-application development isn't being hampered by JS, it's being hampered by the crappy and woefully insufficient DOM API.

      For example, make a Visual Basic (or RealBasic if you're rabidly anti-Microsoft) form and add a scrolling textarea to it. Take a look at the properties inspector, and notice how many properties it has.

      Now do the same thing in DOM. Can Javascript tell which text is selected? No. Can it set the text color, size, or font? No. (There is such a thing as a rich-text textarea, with those options, but DOM API has virtually no access to any of it.) It's simply ridiculous how incomplete DOM is, and that's where your true problems lie.

      Of course, most people (even a lot of web developers) confuse Javascript with DOM and assume they're the same thing. They aren't; if you used python or ruby or any other language, you'd still be limited by a crappy DOM.

      • Re:Got it wrong (Score:5, Insightful)

        by Anonymous Coward on Thursday August 21, 2008 @11:50AM (#24690425)

        The other big showstopper is the total lack of multithreading/multitasking. Javascript has an event system, but it can never interrupt a function. This makes it excruciatingly hard to keep a DOM UI fluid while the application handles big chunks of data, and consequently most developers simply stall the UI (for example: Slashdot AJAX UI.)

      • Talk to someone who knows the inside story and can tell you (because you work for the same company and can discuss what happens at W3C) what happened to the DOM committee and vigorous efforts to add modules, cleanup, or take other actions to solve precisely those deficiencies at W3C.

        Hint. For the sake of argument, assume Microsoft owns W3C control to some extend the same way they own ECMA (now obviously after .net, OOXML, and Javascript subversive actions).

    • by Stooshie (993666)

      ... It's just that no one has come up with a better language. If no one comes up with a better language, why reinvent the wheel? ...

      ActionScript3.0 anyone? As client side languages goes it's pretty solid. Fully object oriented and ECMA compliant.

      If anyone hasn't used flash for a while, it's a whole other beast now. It's not an animation package with a scripting language slotted into the side any more.

    • Re:Got it wrong (Score:5, Insightful)

      by hey! (33014) on Thursday August 21, 2008 @11:55AM (#24690499) Homepage Journal

      Some day, I may write an essay "Model View Controller Considered Harmful".

      It's not that MVC is a harmful pattern. It's a natural pattern that often emerges from an application of sound design principles to many problems. It's that it has become such a design buzzword that it encourages a kind of "design first analyze later" phenomenon. People are so sure they're going to find MVC that they start with it and go looking for ways to fit the problem to it.

      And they find them. The problem is that the first way you find to apply it isn't necessarily the best one or the only one. I think you're brining up an example of how the design first mindset introduces blinders into people's thinking. They can't see the obvious because they're too wrapped up in the idea that MVC will magically simplify design, whereas simplifying design will often generate MVC.

      I've seen so many "MVC" designs that were superficially structured as MVC, but were in fact heavyweight, somewhat arbitrary abstractions through which all kinds of responsibilities are squeezed like so much meat through the grinder.

      • Re: (Score:3, Interesting)

        by CodeBuster (516420)

        I like the way that the Head First Design Patterns poster explains this with the "Zen of Patterns" section:

        The Beginner Mind:

        The beginner uses patterns everywhere. This is good: the beginner gets lots of experience with, and practice using patterns. The beginner also thinks, "The more patterns I use, the better the design." The beginner will learn that this is not so, that all designs should be as simple as possible. Complexity and patterns should only be used where they are needed for practical extensibili

    • by jrumney (197329)

      Here's an even better idea: The HTML DOM would be the View, the Javascript would be the Controller, and the server would be the Model!

      Here's another one for you: The HTML DOM is the view, the Browser is the Controller, the Model is implemented in Javascript, and the server would be a source of data.

  • by godefroi (52421) on Thursday August 21, 2008 @11:24AM (#24690007)

    ... the browser-as-a-ui problem. Browsers are great for online brochures, and terrible for anything more complicated than that. If browsers were a good application framework, we wouldn't need Flash, Air, Silverlight, Java applets, XBAP apps, XUL, etc, etc etc. The sooner we realize that trying to build an "application" directly in html+javascript+whatever-server-side-tech-you-like is a losing strategy, the sooner we can move onto something better.

    • by avandesande (143899) on Thursday August 21, 2008 @11:38AM (#24690225) Journal

      I guess the last 10 years where I have put food on my table and deployed 10s of applications that are used by thousands of people are really a loss.
      Thanks for clearing that up.

      • by betterunixthanunix (980855) on Thursday August 21, 2008 @11:50AM (#24690429)
        1. HTTP is connectionless, but many applications don't make sense in a connectionless setting
        2. Client side privileges are difficult to control, and relying solely on the server for security is not always possible
        3. HTML/XML requests use more bandwidth than binary protocols, which strains slow connections (yes, some people still use dialup, especially mobile users, and here in America many mobile users still rely on 9.6kbps cell phone connections). *ML requests also include a lot of useless tags that describe the "document," even though it is really an RPC request.
        4. XMLHTTPRequest is not standardized across all browsers, and multiple copies of some sections of code must be sent, wasting even more bandwidth.

        Anyone who wishes to amend this list is welcome to. I'm *ML requests sure there are even more reasons, that I am just not thinking of at the moment.

        • by hypnagogue (700024) on Thursday August 21, 2008 @12:20PM (#24690899)
          1. IP is connectionless, but somehow TCP works anyway. Session is a layer.
          2. Client side privileges are IMPOSSIBLE to control, relying on the server for security is mandatory.
          3. Bandwidth does not govern RPC performance -- service time does.
          4. The W3C is addressing XMLHTTPRequest standardization.
        • 1. By Many you mean 1% of the total applications excluding games written. Most frameworks for applications are this. Take Input process data produce output. Step one takes time so there is no need to keep a connection there. step 2 - 3 is done on the server. After you get the data you don't need the connection until the next input. Your way will have the server get overloaded much quicker then with Web Apps as it needs to keep connections until they quit.

          2. I have heard this argument before however I have

        • You don't HAVE to use XML for RPC requests. Heck, the XmlHttpRequest object doesn't even force you to use XML.

          JSON is a much more concise RPC vehicle.

          Further, HTTP isn't SUCH a bad RPC protocol. It's remarkably light-weight. HTTP Headers can be a little as 2 lines of text. And a lot of RPC functionality that doesn't involve sending or receiving much data (for example, marking a message as Read in Gmail) you can use a simple HEAD request instead of GET or POST and use the HTTP Status code to determine succes

    • If browsers were a good application framework, we wouldn't need Flash, Air, Silverlight, Java applets, XBAP apps, XUL, etc, etc etc.

      Newsflash! We don't.

      Flash was never welcome on the web. It was responsible for some of the most horrific, unusable sites known to man. For the most part it has disappeared from common UI use. However, it did manage to find two major niches:

      1. A standard for Web Video (because no one can friggin' agree on a standard)

      2. Online Games

      #1 may eventually be taken care of by the new HTML5 <video> tag. Unfortunately, the powers that be still can't agree.

      #2 *is* taken care of. Javascript games already exist:

      PentriiX Online Multiplayer [wiicade.com]
      DHTML Lemmings [elizium.nu]
      Hull Breach Online [hullbreachonline.com]
      Tetris using Canvas [dnsalias.com]
      Pac Man using Canvas [youtube.com]

      XUL is a Mozilla technology primarily used to construct Mozilla apps. It is not a web language per se.

      Air and Silverlight are solutions looking for problems. The latter is supposed to be a Flash killer at a time when Flash is already at the end of its life. Smooth move, Microsoft.

      XBAP is effectively the heavy-weight daddy of Silverlight. Except that it's not really a web app.

      The sooner we realize that trying to build an "application" directly in html+javascript+whatever-server-side-tech-you-like is a losing strategy, the sooner we can move onto something better.

      So what you're saying is, the sooner we shut down GMail, Yahoo! Mail, Google Docs, Google Maps, Digg, Meebo, and every other DHTML app in existence, the better off we'll be*?

      * Ok, maybe in the case of Digg we would be, but that's the exception that proves the rule!

    • I agree, I think it's time for HTML5 to be the last web page spec then move on to the next thing.

      We need and application framework. It has to break fundamental features of the HTTP/HTML model. It has to be authenticated at OSI session level that fixes huge problems trying to work around statelessness. It has to have something OBDC-like built in to handle data transfers. It can still keep XHTML markup, but streamline it for "moving" apps. It would look a lot like remote X sessions. It would be subject to

      • Re: (Score:3, Interesting)

        by ultranova (717540)

        We need and application framework.

        If you really need all that, you can have it right now: just make a web page that contain nothing but a Java applet that connects back to your server. See http://www.mudmagic.com/java-client/ [mudmagic.com] for example.

        That few people bother doing this implies to me that it isn't, in fact, widely needed.

    • Re: (Score:3, Insightful)

      by Bryansix (761547)
      This is moronic. The browser has been awesome for applications even simply for the fact that it forces user interfaces that are usable as opposed to some of the shit I could come up with in Flash for instance that would confuse the fuck out of people. Have you ever browsed for flash based UIs? Its like stepping into the twilight zone. I mean seriously, tell me one thing you would like to do in an application that you can't do in a simple browser without some plug-ins. I mean obviously some things won't work
      • Re: (Score:3, Insightful)

        by Eli Gottlieb (917758)

        Ever heard of this little thing called "native applications running on your computer"? It works much better than a browser.

    • Re: (Score:3, Funny)

      by oyenstikker (536040)

      Java Web Start!

  • An external browser module capable of executing most of the proposed ECMAScript 4 specification already exists: It's the Adobe Flash plug-in. Other platforms are available as plug-ins, as well, including Curl and REBOL.

    As Web developers, we tend to shy away from these alternatives, but only because of the never-ending efforts to refine and standardize JavaScript within the browser itself.

    Paid shill maybe? Sounds to me like Adobe is trying to persuade the public that "their" Flash ActionScript [slashdot.org] additions

    • Re: (Score:3, Informative)

      by mad.frog (525085)

      You should learn your history... ActionScript 3 was actually based off of an early proposal for "JavaScript 2", written by Mozilla (or maybe it was Netscape at the time.

      The goal was for it to be standards-compliant with the next major revision to JavaScript.

  • AIR lets you pick your language... it is practically a browser replacement using WebKit as it's html/dom render engine which lets you script however you like.... well, it supports javascript, actionscript and can be extended [onflex.org] to allow for coding in C/C++ and all the other languages that sit on top:

    Java, Python, Ruby, PHP, Lua, Perl, C# (Mono), JavaScript

  • by Lord Ender (156273) on Thursday August 21, 2008 @11:29AM (#24690095) Homepage

    The combination of HTML's form controls and Javascript's XMLHttpRequest gives web app designers the power they need to implement 99% of applications as webapps with very little compromise vs. thick-client apps.

    Personally, I care very little about the rest of Javascript's abilities. Most often when I see them used, they add nothing useful to the functionality of the applications--just complexity and gee-whiz UI silliness.

  • Some things are standards by default. Like Microsoft Word format. So by comparison Javascript doesn't look so bad.

  • lol wut (Score:3, Insightful)

    by Alex Belits (437) * on Thursday August 21, 2008 @11:32AM (#24690143) Homepage

    1. The author is stupid.

    Language for client scripts is standardized not based on its convenience for web site developer. It has to be implemented in all clients, and all implementations have to provide clear separation of actions that happen within interface handled by this language's implementation, an anything that affect client platform's security. More things to implement means more incompatibilities and security holes, so standards have to limit the amount of things to implement and clearly provide limits to their functionality. Microsoft tried to break this principle with ActiveX use in its "web technologies", and ended up destroying compatibility and security even within its own product lines.

    2. "Model-view-controller" is a misnomer.

    Properly it should be called "model-view", there is no "controller". Internal representation of data the program operates on is the "model". Interface between program and everything outside provides "view". Program itself would exist regardless of someone calling it "controller" or not, because without a program nothing would be there to implement model, view, and their relationship, so their description would not be applicable to anything at all. No other term specifies both design principle and simultaneously treats the mechanism that implements it as a component of the principle -- it's not even apples and oranges, it's apples and Z axis.

  • The web was invented right, HTML for documents, HTML forms for simple data entry and APPLETS/OBJECT for complex and "rich" content

    The problem is that not all developers look for the right tool for the job, they have a screwdriver and think how to adapt it to a wrench

    Of course the correct solution is to use the right tool, but, hey, this means learning something new !

    Having javascript doing what java/C# does is just reinventing the wheel, it can be done, someone will even be happy to slam Java once again but

  • The HTML browser model is currently an eBrochure model. If one wants to create CRUD screens (business forms and grids), you have to make the eBrochure model bend over backward to achieve it. To allow a more desk-top like feel, the widgets and screen need to be more state-ful. That is, if you issue the command "draw screen X", screen-X will stay there until you tell it to close screen X. (For security-related isolation, an MDI model can be used.)

    Further, we need a GUI interface language/standard that is more

  • Having used the Model-View-Controller (MVC) Design Pattern for years, I know that many people (even programmers) are not aware of what it actually is.

    I recommend skimming through Martin Fowlers excellent description [martinfowler.com].

    You can also get additional links to PHP, .NET, Ruby, Python and Java examples from the main Wiki article on MVC. [wikipedia.org]

    If you have never heard about it (and many of you haven't), you are missing out on a great design pattern.

    - Jesper
  • "Let the browser handle the View. Let the Controller exist somewhere else, independent of the presentation layer.'"

    Has the author ever actually developed a web app? Javascript may be doing things like fetching data and sorting lists, but I have never seen a real application that had sufficient non-display javascript to justify splitting it into a MVC pattern. Despite the fact that we have heavyweight JS frameworks like JQuery and mootools, those are still spending their time rendering the view.

  • by MarkusQ (450076) on Thursday August 21, 2008 @11:42AM (#24690303) Journal

    We standardized on one language?

    Cool. I must have missed that. Now I can strip out all that browser and version detection cruft and just code to the one standard language, right?

    --MarkusQ::sarcasm

  • Yes. Yes it was.
  • I have a better idea. Give up the "web app" mentality all together.

    When you need to access your e-mail, load up an MTA. It works an order of magnitude faster, without maxing out your CPU to display a message. It requires an infinitesimal amount of bandwidth, and allows you to read and respond to e-mails even when you're nowhere near an internet connection.

    When I'm looking at several items, and want them sorted by popularity, I REALLY DON'T NEED to see an animated status bar show up to tell me that the pa

    • by Random BedHead Ed (602081) on Thursday August 21, 2008 @12:23PM (#24690967) Homepage Journal

      If you have a break-through network application that's going to change the world... GREAT! Write an actual program that will merely communicate over the net. Not some hacked together Javascript that just barely works on a good day, on the right version of the right browser, with all the settings done by your CTO.

      Relying upon non-web network programs is what we've been doing for decades. The result is that people use inflexible proprietary software that locks them to their propriety desktop platforms, and those platforms (and we're not naming any names here) have stagnated for years, there being no real competition to drive innovation at the OS level.

      The promise of these web apps is that it doesn't matter whether you buy a Thinkpad with Windows, a MacBook with OS X or an Asus netbook. In any case, online apps like Facebook and GMail work the same anywhere. It's not perfect, and you're right that there's a lot of entropy out there, but everyone can see by now that this is a move away from the Bad Old Days of "I need to be able to use Outlook and IE so I can't buy a Mac."

  • I would think... (Score:3, Interesting)

    by SirGarlon (845873) on Thursday August 21, 2008 @11:52AM (#24690449)

    Now it's been what, almost 10 years since The Cathedral and the Bazaar, and we still have guys like this author telling us the Wisdom of the Enlightened Few should be dictating standards to us ignorant masses who are, well, doing all the productive work.

    I would think we'd be beyond that point by now.

  • by klondike (9378) on Thursday August 21, 2008 @11:55AM (#24690507)

    ...you have reinvented X11

  • by Pedrito (94783) on Thursday August 21, 2008 @11:56AM (#24690513) Homepage

    I think the problem is the failure to distinguish a scripting language from an application development language. JavaScript is designed for the square hole of scripting. It shouldn't be mashed into the round hole of application development. Nothing lives in a vacuum. Different tools are used for different jobs. Look at any major web app and you'll probably find compiled code and scripting languages like JavaScript and maybe some Perl and maybe some other stuff.

    If you make all the tools do everything, then they'll all be cluttered masses of junk. If on the other hand, different tools perform different functions, then instead of using one cluttered mass of junk, you can uses several tools that each perform specific types of tasks that they're appropriate to, as it should be.

    Sure, it can be a pain in the butt to learn to use different tools, but it's far less of a pain in the butt than trying to maintain a big app written with a nasty language that tries to do more than it should.

  • by argent (18001) <peterNO@SPAMslashdot.2006.taronga.com> on Thursday August 21, 2008 @12:00PM (#24690577) Homepage Journal

    I agree, plugins get a bad rap, but the biggest problem with plugins is that they are restricted to a little box in the browser window. What is needed is not a better Javascript, but a better way of doing plugins. What he's talking about, I think (correct me if I'm wrong), is this: let a web page have a Java component (for example) that doesn't run in a little box... but instead runs in the background and updates the page, hiding and showing components, triggering little bits of javascript glue, and generally doing the heavy lifting without having any graphical elements of its own...

  • by expro (597113) on Thursday August 21, 2008 @12:00PM (#24690593)

    Netscape went with ECMA early on and got good results standardizing Javascript. Since that time ECMA whole-sale sold out to Microsoft. Ask any normal party that has been involved and I think you will get the same answer. They are to be blamed for not only this Javascript failure, but for the whole OOXML fiasco. Microsoft went there with a single goal in mind: to block Javascript to allow their own .net-related standards to become relevant, which they get rubber-stamped through ECMA.

    To a lesser degree, W3C has also sold out to Microsoft in their efforts to sell SOAP, deemphasize all the web standards Microsoft does not want to be important so, for example, they don't have to waste effort competing in the browser wars when they think they should just forever be declared the winner without having to do anything that benefits the web in general.

    Should Javascript be the defacto standard on the web? Only in so far as it is useful. Like anything else on the web, if it ceases being useful, people will build a new path and do something else (whatwg, anyone?). But it is silly to call it useful or not useful based upon Microsoft/ECMA blocking the way. It sounds to me like there is some good work going on inspite of the monopolist blocade. I would hate to never see it come to light because of the many formal committees that sold out to Microsoft.

    I love competition and would love to see something an order of magnitude better take over and rule the day, but that should be based upon technical merit and competing against the current success, ubiquity, and any irreparable flaws of Javascript.

    I have every confidence that as ECMA continues to be paid to make good things irrelevant and bad things relevant, other standards organizations, which may start out being ad-hoc, will rise up to fill the void, and Microsoft will continue being irrelevant to those they do not own until they can really come up with something generally useful as a standard.

  • by psykocrime (61037) <mindcrime@cppBOY ... o.uk minus berry> on Thursday August 21, 2008 @01:03PM (#24691611) Homepage Journal

    You mean we could - theoretically - use browsers for what they were meant for (browsing hypermedia) and NOT try to turn the browser into the all-in-one universal application delivery platform????

    BRILLIANT!

    I'd like to hear more about your ideas, please subscribe me to your newsletter.

  • by MobyDisk (75490) on Thursday August 21, 2008 @01:45PM (#24692285) Homepage

    Upon a cursory glance, Javascript seems like a good language. It takes elements from some of the most popular and well-known languages (C,C++,Java) and makes it into something appropriate for scripting. But with experience, I've found that Javascript really only borrowed the most trivial features of those languages, and forgot everything we learned about computer science in the last 20 years.

    The most awful example is the concept of "undefined." Javascript is the only language I know of where it is legal to say:

    if (MyObject.NonExistantVariable == 7)
    { // Do some work
    }

    (BTW: This expression returns false)

    That is the source of most Javascript errors in a large project. A property was removed, a variable renamed, or misspelled, or never initialized. The value of the non-existant variable is "undefined" which is the bane of Javascript. There's even a special === operator for specifically comparing to undefined! And people thought NULL was bad!

    It gets worse because Javascript is a glue language between other things like the HTML DOM or XML/SOAP/JSON so those object definitions can change at any time, and you won't know it broke your Javascript until you hit the right line of code in the right order.

    Javascript is a language with totally dynamic typing and scoping. So it is impossible to compile, or type check. Even most scripty languages like PERL can detect more errors at load-time of the file than can be detected in Javascript.

    • Re: (Score:3, Informative)

      by againjj (1132651)
    • Re: (Score:3, Informative)

      by Phroggy (441)

      The most awful example is the concept of "undefined." Javascript is the only language I know of where it is legal to say:

      Perl will let you do that, although the warnings pragma will remind you "Use of uninitialized value in numeric eq (==)". But in Perl, you test whether or not something is defined with defined(), or whether a hash key exists with exists(), so you don't need a crazy === operator.

  • by FlyingBishop (1293238) on Thursday August 21, 2008 @08:29PM (#24698277)

    Everyone who continuously complains about the inadequacy of the web browser needs to step back, and remember that it is designed to be crippled. If it were as fully functional as the desktop, any yahoo could come by and completely replace your desktop with something of their choosing. I don't need DHTML to watch movies and read the news. I need Firefox and some interlinked markup. Anything more than that is opening up the web to all sorts of attacks that don't need to happen. We don't need a better JavaScript. It would be nice for programmers, but less secure for users.

  • by Stu Charlton (1311) on Friday August 22, 2008 @12:47AM (#24700865) Homepage

    I don't think the author really understands what TBL's original vision was, except in the narrowest of contexts. The idea of code on demand [uci.edu] was certainly described as part of REST.

    The problem with JavaScript standardization arguably comes down to vendor politics (as do most standards efforts). We're in a wave of proprietary "innovations" being pushed, like MS Silverlight, Adobe AIR, Sun JavaFX, etc. It's not in these gorilla's interests to commoditize a richer browser experience before they try to take over a portion of the web on their own.

10 to the 12th power microphones = 1 Megaphone

Working...