Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

JavaScript: What, Why, and How

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

  • JavaScript: What, Why, and How

    ** This thread discusses the article: JavaScript: What, Why, and How **
    ** This thread discusses the Content article: JavaScript: What, Why, and How **
    0

  • #2
    JavaScript: What, Why, and How

    ** This thread discusses the article: JavaScript: What, Why, and How **
    Great article, Joe, especially for a relative newcomer to HTML like myself. I am looking forward to the follow-up article! Re: the incompatibilities of IE and Netscape. I really don't want to start a holy war on this topic, but you refer to Netscape as being non-standard when, to my recollection of the issue, it is IE that thumbed its nose at the standards. Although you qualify it by calling it "essentially a non-standard" and, therefore, I imply that it was relegated to a non-standard by way of market share dominance of monopolistic Microsoft (plus some sloppy work on Netscape's part). The last Netscape I've used is version 4.6, partly because later versions with the Netscape name were, essentially(!), AOL shells with much of the baggage. Hopefully, the pure Mozilla browser that's been out for awhile now addresses some of the incompatibilities, even if it means "dumbing down" from the standards. Or maybe not. To paraphrase your colleague Thomas Stockwell, Could Microsoft's Vulnerabilities Kill Microsoft? Frankly, I see Microsoft as having this huge easy-to-hit target on its back, and I see us users as being the victims of the sniper fire. Getting off track, sorry. But it does lead to another question. Is there a browser that can run in Linux (or other OS) that could run the application you presented? After all, Java is supposed to be platform-independent? Anyway, I downloaded your example, uploaded JSEXAMPLE to our AS/400, and see that I need "at least one server instance working that can invoke servlets by name", which I apparently don't have. Can anyone provide a reference to help me get this going?

    Comment


    • #3
      JavaScript: What, Why, and How

      ** This thread discusses the article: JavaScript: What, Why, and How **
      I always appreciate Joe's clearly-written articles. This one really hit home for us. We are a long-term AS/400 shop just getting started with changing to a web architecture and articles like this with straightforward simple examples really help us get over the "getting started" hurdle. I'd love to have the follow-up article you mentioned maybe writing. Thanks Jim Peary Logan Township, NJ

      Comment


      • #4
        JavaScript: What, Why, and How

        ** This thread discusses the article: JavaScript: What, Why, and How **
        Unfortunately, I don't have as many good answers as you have good questions! But let me start addressing things. First, I'm not going to get into a holy war, either. I did not mean to imply that Netscape/Mozilla was non-standard, but that JavaScript was. I was just trying to say that JavaScript is implemented differently in different browsers, and without an interactive debugger, it's almost impossible to try to get anything done. That's why I don't do much JavaScript coding for Netscape/Mozilla. Sorry for the confusion. The latest Mozilla is no better, unfortunately. Events are read-only, and unlike the incredible online reference that Microsoft provides, the documentation for the Mozilla DOM is pretty much non-existant. Linux browsers? I don't know. And that's perhaps one of the big issues with Linux as a desktop replacement for Windows. IE is the best browser for JavaScript, which means it's the best browser for creating business applications. If you think of JavaScript as equivalent to the features you are so used to on a 5250 terminal (upper case fields, numeric fields, function keys), then IE is to Netscape what 5250 is to Telnet. If you've ever done a "pure" Telnet connection to an iSeries, you'll know what I mean - not all the command keys work, the cursor control is weird, and so on. It's a fact that IE (and thus Windows) holds a definitive lead in this category. Finally, as to your service instance issue, I don't know what web server you're running. You'll need something like WebSphere Application Server or Tomcat. Joe

        Comment


        • #5
          JavaScript: What, Why, and How

          ** This thread discusses the article: JavaScript: What, Why, and How **
          Your clarification on the incompatibility problem residing with JavaScript: How interesting. One would have thought there would be standards with that as well. I'm going to show my inexperience with this question, I'm sure, but with Microsoft supposedly trying to dump Java and replace (?) it with .net, does coding JavaScript for IE have the potential to be a wasted investment? What is the Mozilla community's response with regards to the JavaScript issue? Is it even an issue with them? Should it be? To my way of thinking, JavaScript compatibility should be a top priority, even if MS has commandeered the standard. Maybe easier said than done? You have stated the case well, Joe, who wants to write a version of the same function for each JavaScript implementation? Finally, does your PSC/400 product use JavaScript to do its magic?

          Comment


          • #6
            JavaScript: What, Why, and How

            ** This thread discusses the article: JavaScript: What, Why, and How **
            Sorry, I meant to address this in my last post, but you raised so many good issues at once that this one slipped past... JavaScript is NOT Java, it's not even related. While the JavaScript syntax is similar to Java, that's just an artifact of the fact that many languages, including C and C++, share a very similar syntax. JavaScript was originally called LiveWire, and then LiveScript. The name JavaScript was coined simply to sort of fit in with the whole Java emergence - and thus inadvertantly helped muddy the waters. JavaScript is a completely interpreted language with no strict object typing, and in that regard it's more like Perl or Python than Java. Because of this, you can do some really powerful things with JavaScript, though getting overzealous with your scripting will inevitably lead to some performance issues. Then again, since the scripts tend to run on user machines, it really depends on the horsepower of the user's workstation. Joe

            Comment


            • #7
              JavaScript: What, Why, and How

              ** This thread discusses the article: JavaScript: What, Why, and How **
              It's been brought to my attention by at least one reader that the newer versions of Mozilla (including those in Netscape 6.2 and beyond) contain a JavaScript debugger called Venkman, which looks to be a pretty solid interactive debugger. It seems to have breakpoints and variable inspection and stepping; all the good stuff you might need in a debugger. There are some idiosyncacies, but that's to be expected in a debugger that actually lives inside a browser, but from what I can see, it's a nice implementation. That still doesn't help me with the issue of the read-only nature of most attributes of the Netscape/Mozilla DOM, but it's one step closer to a workable environment. It may be enough to get me to do some research into emulating some of my IE features in Mozilla. Joe

              Comment


              • #8
                JavaScript: What, Why, and How

                ** This thread discusses the article: JavaScript: What, Why, and How **
                I *did* imply that I was relatively new to all this, didn't I? ;-) How about my question about your PSC/400 product? Is that using JavaScript to do its magic?

                Comment


                • #9
                  JavaScript: What, Why, and How

                  ** This thread discusses the article: JavaScript: What, Why, and How **
                  PSC/400 takes advantage of JavaScript to provide features like function keys and field editing to IE users. Netscape users are not so fortunate, but now that I've found out about the Venkman debugger I may be able to find a little time to address those issues. If you don't worry about function keys, and you're willing to ignore the input keying issues, Netscape is just fine. But for business applications, the field editing in particular is an important point (not to mention the ability to automatically move to the next field when the current field is filled), so for now IE is the browser of choice for business applications. Joe

                  Comment


                  • #10
                    JavaScript: What, Why, and How

                    ** This thread discusses the article: JavaScript: What, Why, and How **
                    Joe, just curious, but have you ever had a potential customer of your product reject it because they were "stuck" on Netscape? How often, if ever, have you had a customer change to IE from Netscape because of your product? I ask because this is something that our company may need to address with our forthcoming applications for our customers. How well does this play: "If you're using Netscape, you'll have to switch to IE if you want to use our product (or utilize function keys that our product uses, etc.)"

                    Comment


                    • #11
                      JavaScript: What, Why, and How

                      ** This thread discusses the article: JavaScript: What, Why, and How **
                      I have separated this from the other thread that I keep replying to; it seemed appropriate to branch off. I don't want to detract from the article's theme, but I don't want to come away with "Well, this won't work for us if our client/server apps have to be platform-independent" if, in fact, there are other options we can consider. Based on your comments, Joe, it appears that if browser independence is a real issue (you know, you have a customer that is throwing out MS Windows with the bathwater, going all Linux, that kind of issue. Or maybe they're not currently in that mode, but they don't want to be locked in to Windows), JavaScript probably isn't a viable option. In that case, what are the other options out there for doing client/server with iSeries, with emphasis on the Java catchphrase "write once, run anywhere"?

                      Comment


                      • #12
                        JavaScript: What, Why, and How

                        ** This thread discusses the article: JavaScript: What, Why, and How **
                        Another option that may be considered is VBScript, and if you are doing work in Domino, you may even use LotusScript. VBScript will accomplish similar tasks as JavaScript. It should be noted, as JavaScript is not Java, VBScript is not Visual Basic. I am not stating an opinion that either one is any better or worse than the other. Dave

                        Comment


                        • #13
                          JavaScript: What, Why, and How

                          ** This thread discusses the article: JavaScript: What, Why, and How **
                          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


                          • #14
                            JavaScript: What, Why, and How

                            ** This thread discusses the article: JavaScript: What, Why, and How **
                            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


                            • #15
                              JavaScript: What, Why, and How

                              ** This thread discusses the article: JavaScript: What, Why, and How **
                              I need to know what your business requirements are. As far as simple web applications, pure HTML is by far the most robust. You mention "client/server" programming, and I guess I don't know what you mean by that. Typically, just identifying the possible architectural approaches for an application requires several days of discovery. There are situations where thick client is required, places where it is absolutely not acceptable. There are input requirements, stretching from Section 508 requirements to language considerations to physical device characteristics (phones? PDAs? kiosks?). There are issues of application language, database location, and availability. The point is that there is no one best solution. On the other hand, trying to enumerate all the possible solutions for all possible applications is a hopeless task. Perhaps if you gave an idea of what sort of application you intended to write, it might be easier. Joe

                              Comment

                              Working...
                              X