Slashdot Mirror


Was Standardizing On JavaScript a Mistake?

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.'"

19 of 525 comments (clear)

  1. Got it wrong by AKAImBatman · · Score: 4, Insightful

    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.

    1. Re:Got it wrong by Swizec · · Score: 4, Insightful

      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.

    2. Re:Got it wrong by Blakey+Rat · · Score: 5, Insightful

      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.

    3. Re:Got it wrong by Cecil · · Score: 5, Insightful

      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?

    4. Re:Got it wrong by AKAImBatman · · Score: 4, Insightful

      ActionScript3.0 anyone?

      ActionScript 3.0 == ECMAScript 4.0

    5. Re:Got it wrong by Anonymous Coward · · Score: 5, Insightful

      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.)

    6. Re:Got it wrong by hey! · · Score: 5, Insightful

      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.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    7. Re:Got it wrong by coryking · · Score: 5, Insightful

      That document.observe is all great until you try to mix Prototype (or any of these libraries) up. Say you needed to use the YUI calandar control on a page that also uses Prototype (for lightbox2). Now the two libraries will "fight" over the browser's onload.

      Actually.. that is the biggest problem we have right now. Dozens of javascript libraries and all do pretty much the same thing. All of them "weight" like 20->40k. That "weight" and the potential for them to conflict make life really hard.

      What if you based your own code on Prototype and want to integrate a really nice file-upload control that uses MoTools?

      What if you are using Prototype and you drop in TinyMCE. Now you've got two runtime libraries that both have their own methods for injecting objects into the DOM. Those two methods are ever so slightly incompatible so if you create a DOM object via Prototype (actually scriptalicious) and try to inject it using the TinyMCE way, things will break in random browsers in very hard to track way.

      Enter Silverlight/Flex. Now you can go from dozens of Javascript runtime libraries to only two very stable ones. As the "UI control" scene for these grow, I suspect our dependency on Prototype/jQuery/Whatever will shrink.

      After all, it has to be way easier for control vendors to target Silverlight/Flex then it is for them to target javascript. And as a bonus, it is way easier for me to integrate their UI controls into my own Silverlight/Flex application.

    8. Re:Got it wrong by PitaBred · · Score: 5, Insightful

      Except there will be no first-party support of Silverlight for Linux, ever, so it will always be a second class citizen in the .NET world. Assuming Moonlight even gets to the 1.0 status, or ever works as a browser plugin. The gnome guys working on it are so busy sucking Microsoft's dick for cash that they can't actually make it useful (it's compiled without any kind of multimedia support, which is the main feature that it's pushed with). And the Mac will get the same treatment, the Silverlight releases will always lag significantly behind the Windows one in version and bugfixes.

      Embrace, extend, extinguish. They've done it before, they'll keep trying to do it again, and people like you who say "look how little work it takes to make something locked into a very expensive OS that actively works against it's user!" just enable them to keep doing so.

    9. Re:Got it wrong by Serious+Callers+Only · · Score: 5, Insightful

      I've been playing with Silverlight. Took me a single night to cook up a file upload control that works on IE6,7,8, Firefox 2 & 3, Intel Mac & Windows (even 2000) and will work on any other platform Microsoft targets in the future.

      With Microsoft's track record of openness and cross platform support, what could possibly go wrong with your plan?

      BTW, your upload control doesn't work on most browsers on the web today, and I wouldn't download a plugin for your content, sorry.

  2. Re:Javascript/HTML are the way of the past by AKAImBatman · · Score: 4, Insightful

    I foresee API-based web development, and web pages/apps are done programatically, rather than as text markup.

    You forgot to add "I have a dream!" in your one-liner.

    Let me get out my crystal ball here... *clunk* *crash* *bang* sorry *oof* *whump* haven't *whim* *whim* *whim* used it *whack!* in awhile. So where was I? Ah yes. I am staring DEEP into the past. Looking at the days when UIs were programmatic. I see when UIs caused long lengths of repetitive and ugly code. I see resource files being invented! It's a miracle! UI programmers no longer have to keep their layout in their code! These resource files appear to be getting more complex... they are supporting graphical layout... productivity is improving!

    Wait, what's this? Some silly person on Slashdot is attempting to derail the web form of resource files! He thinks that the DOM should be constructed... programmatically? Has he ever tried building a UI 100% programtically? It's a nightmare!

    Levity aside, it can be done, but it's far from the ideal solution. New document formats like XUL may pop up, but suggesting that we move away from keeping layouts separate from our code simply smacks of inexperience.

    "Those that fail to learn from history, are doomed to repeat it." - Winston Churchill

  3. No scripting language is going to solve by godefroi · · Score: 4, Insightful

    ... 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.

    --
    Karma: Poor (Mostly affected by lame karma-joke sigs)
    1. Re:No scripting language is going to solve by avandesande · · Score: 5, Insightful

      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.

      --
      love is just extroverted narcissism
    2. Re:No scripting language is going to solve by AKAImBatman · · Score: 4, Insightful

      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
      DHTML Lemmings
      Hull Breach Online
      Tetris using Canvas
      Pac Man using Canvas

      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!

  4. XMLHttpRequest aught to be enough for anyone by Lord+Ender · · Score: 4, Insightful

    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.

    --
    A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
  5. Since when is javascript only one language? by MarkusQ · · Score: 4, Insightful

    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

  6. When it's all said and done... by klondike · · Score: 4, Insightful

    ...you have reinvented X11

  7. Re:Reasons why browsers are poor application runti by betterunixthanunix · · Score: 4, Insightful

    Yes, but those "holes" are usually evident when you try to force an environment to do something that falls way outside of what it was designed for. HTTP is a connectionless, stateless protocol, by design. It makes a lot of sense for document retrieval. Forms make sense, even email front ends make sense. Instant messengers, word processors, spreadsheets, etc. make no sense in the context of document retrieval or exchange. We are going down a fundamentally misguided path when we try to force those applications onto the web. That was my point.

    --
    Palm trees and 8
  8. Re:End the web-apps by Random+BedHead+Ed · · Score: 5, Insightful

    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."