Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

JavaScript: What, Why, and How

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    JavaScript: What, Why, and How

    ** This thread discusses the article: JavaScript: What, Why, and How **
    Keep in mind that even though 6% use Netscape, it's probable that at least half of them also have IE on their desktop but choose to use Netscape instead. They COULD use IE if your application was compelling enough. So, if you program your application for IE you will have probably covered 97% of the market. What more could you want? Remember one thing to keep perfectly clear. It's not a religious war it's about business. Use the tools that work best. I would never think of telling a vendor that they must use UPS instead of FedEx, I only want the package delivered. chuck Opinions expressed are not necessarily those of my employer. "Joe Pluta" wrote in message news:6ae7eeba.11@WebX.WawyahGHajS... > Which browsers to support is always a difficult decision, but it's just a business decision. When you decide on support, you have basically the following choices: > > 1. Implement all features on all browsers > > 2. Do not provide certain features to some users > > 3. Provide only features that work on all browsers > > Option one is more expensive, in some cases MUCH more expensive, as time you could be spending on product features is instead routed to browser support. Option three is a lose-lose situation for everybody, especially if you decide to standardize on an earlier browser such as Netscape 4. > > It's a clear case of business goals. Since the vast majority of my clients are B2B as opposed to C2B, they find it easier to dictate IE choice to their end users. Especially since some 94% of users use IE anyway, as opposed to about 3% on various versions of Netscape. And since my clients want function key support and field editing, they are more than willing to use IE. I've found very few businesses thus far that have standardized on non-Windows desktops. > > You need to realistically assess how many users you have that have standardized on non-IE browsers. Then you have to decide what level of support you will give them, and how far down the chain you support. Netscape 7? Netscape 6? Netscape 4.57? Opera? Lynx? > > Currently, no PSC/400 clients require Netscape. One prospect bailed because they wanted to standardize on Internet appliances (thin clients) with Netscape 4.57, but that's the only time anybody ever balked. > > Are you writing B2B or C2B? B2B users tend to need power data entry, with heads down keying and function keys and the like. These folks are far more likely to standardize on IE. C2B applications, on the other hand, are usually much more of a point-and-click (or "point-and-think") type of interface. These don't perhaps need function keys and field editing, and can instead rely on the rather less powerful techniques supported by Netscape. > > Joe

    Comment


    • #17
      JavaScript: What, Why, and How

      ** This thread discusses the article: JavaScript: What, Why, and How **
      Joe, The biggest drawback I've found to JavaScript is that the user can simply elect to turn JavaScript off. In fact, many corporate environments do that by design. So, it's always a good tactic to duplicate validation on the host. I, for example, always turn fields into upper case on the host side programming when a field MUST be in upper case even though I've put it into JavaScript. I don't want to rely upon JavaScript to make sure that my data has integrity. Yes, this requires some extra work but the coding is actually less than the JavaScript code. chuck Opinions expressed are not necessarily those of my employer. "Joe Pluta" wrote in message news:6ae7eeba.12@WebX.WawyahGHajS... > I do have an opinion. I haven't seen anything that can be accomplished in VBScript that can't be accomplished in JavaScript. And so rather than lock yourself in even tighter to the Microsoft world, I'd recommend highly using JavaScript wherever possible. > > And according to my understanding, LotusScript is a server-side technology, and is only used to generate pages on the server. You can't execute LotusScript in a browser. AFAIK, anyway. It's been a while. > > Joe

      Comment


      • #18
        JavaScript: What, Why, and How

        ** This thread discusses the article: JavaScript: What, Why, and How **
        This makes it sound like you DON'T do the conversion in JavaScript. My users would find the lack of feedback unacceptable. It's especially problematic for numeric fields, where the user can accidentally hit a bad key, thus invalidating the entire transaction. I suppose doing both is a possibility, but again that's a business decision, trading off extra programming effort. Joe

        Comment


        • #19
          JavaScript: What, Why, and How

          ** This thread discusses the article: JavaScript: What, Why, and How **
          The Oct. 8/2001 issue of InfoWorld magazine contained a relevant article. It was called "Browsers converge on standards" and was written by Tom Yager from their Test Center. I had thought, partly based on this article, that much of the browser incompatibility we saw was a thing of the past. The Test Center reviewed Netscape 6.1, IE 6, Opera 5, and Konqueror 2.2 (all new at the time). In particular, Netscape 6.1 and IE 6 both achieved scores of "Excellent" on ECMA-262 and DOM Level 1 compliance. They both achieved a score of "Good" on DOM Level 2. The ECMA-262 is particularly interesting, since it is supposed to be a version of JavaScript (ECMAScript) that is standardized and cross-platform. Would you care to comment?

          Comment


          • #20
            JavaScript: What, Why, and How

            ** This thread discusses the article: JavaScript: What, Why, and How **
            Brian, I missed this particular comment, I apologize. To answer your question, the people that run these tests don't actually program for a living. Check out Mr. Yager's bio and you'll see what I mean. And the article itself is two years old, meaning it's unlikely to address any of the stuff we really need. Because ECMA-262 isn't exactly leading edge stuff. Published in 1999, it's woefully behind the times, and doesn't even address event handling (although it's also not gotten much farther - the ECMA people are too busy playing with CLI and C#). All the JavaScript dialects handle the programming side of script fine - functions, looping, creating HTML dynamically, all that good stuff. Where they diverge radically is in event handling, which is the one thing you need for true client-side development. The DOM folks are getting better - they at least finally got around to addressing event handling in DOM 2, and by DOM 3 they've managed to create a decent LISTENING structure, but there's still no mention of CHANGING events, which is required for all but the most basic event handling. Now, it may be that they will allow substitution of events, but that's not clear and again, that's because they're just writing specifications without having a lot of business goals in place. What I'd like to see before they go any further is a set of business cases to process, like filtering keystrokes or enabling command keys or mapping keyboards. Anyway, my point of all this is that the only people who seem to use their browsers for any sort of indutrial strength application design are the folks at Microsoft, because their DOM has been capable of most of the really useful features for a long time. Nobody else is close yet. Joe

            Comment

            Working...
            X