JB: CREN Virtual Seminar Expert Series for Spring of 1998 on untangling the Web. Whether you're joining us by phone or by Internet audio, you are here because it's time to discuss on the of the leading core technologies in your future, the World Wide Web. This is Judith Boettcher of CREN, one of your hosts for today's session. Ken Horning, a consultant at MERIT at the University of Michigan, will be standing in for our regular co-host, Greg Marks. Ken is a consultant at MERIT, and in addition, I understand, has some history in radio. Thanks for being here, Ken.

KH: Thank you, Judith. It's been a while since my broadcast days, and I'm looking forward to being a part of today's Virtual Seminar using this new broadcast implementation. So picture me here with one hand over my ear and a big Larry King microphone.

JB:. All right. I've got the picture clear. Our guest expert today is World Wide Web expert Howard Strauss from Princeton University. Howard is the manager of advanced applications at Princeton and a well-known presenter on Web issues and futures. Howard is also the seminar leader for the CREN Virtual Seminar on untangling the Web. Welcome, Howard, and thanks for being here again today.

HS: Okay, thanks, Judith, but I'd like to remind the people who are tuning in one way or another that we can discuss almost anything except, I think, El Nino and President Clinton's problems.

JB: All right, and moving quickly right along, as a special treat today, we have an expert (inaudible), Ira Fuchs, joining us for this session. Ira is the president and CEO of CREN and the vice president for computing and information technology at Princeton University. Ira, again, thanks for being here.

IF: Well, thank you, Judith. I'm delighted to be here today and to participate in this CREN Expert Event. And I'm going to do my best to make sure that Howard doesn't get away without answering some tough questions.

JB: All right, good.

HS: Oh, that's great!

KH: Before we launch into our discussion today, I'd like to remind everyone that we will have participants joining us actually in one of two ways during today's expert event. Those that want to participate can join the phone conference by calling area code 734 647-2801, or alternately, you can join us via the World Wide Web using the two-step link that you'll find at the CREN homepage at www.cren.net. And for those of you joining us in either way, we do have e-mail facility to feed your questions if you're not on the telephone call with us to our expert participants. You may send e-mail to utw@cren.net, and if you will include your name and institution and title, we'll be able to pose your questions on your behalf to Ira and Howard.

JB: All right. Thank you very much, Ken. And just a couple other little notes. Remember that this is our second series of Tech Talk, and that if you do miss the live session and aren't able to listen in at the specific time, you can also pick up selected portions of the session from the Website, and that is open and free right now. Howard, I think we're about ready to begin our session focusing on the Future of Java and JavaScript, but let me just ask a general question. In this whole area and this whole landscape concerning Java, isn't the landscape getting, shall we say, muddy? I thought that the promise of Java was that the world of development was going to really get simpler with Java rather than more difficult.

HS: Well, Judith, I think a lot of things start out like that, with a great deal of promise, until you have to get down to the details of doing them. And then things do get a little bit muddy. But I think that Java and JavaScript--which is quite a different thing, and we'll talk a little bit later about the differences--but with Java and JavaScript, they do have a lot of promise and I think that they are going to do some wonderful things, and are doing wonderful things already for our Web development and for things quite a distance outside the Web.

JB: Okay. Well, given the promise of Java, Howard, maybe it's a good idea to stop for a moment and back up and explain to our listeners. Just what is Java and why is there such a big fuss about it? Isn't it just another programming language that we have?

HS: Actually, it is just another programming language. It's a programming language that looks a great deal like C++, without some of the bad stuff that C++ has in it. There's some things in C++--and we won't get into the details of that--like memory management and pointers and things like that that make it a dangerous language to use. But Java's just another programming language, except that's what it is on the surface. If we go a level deeper, Java was designed to deliver applications across the Web. It was designed to be safe to do that. As I'm sure everybody listening knows, one of the dangers of picking up something across the Web is you might pick up something more than the application. You might pick up viruses, you might pick up things that could potentially damage your machine or damage your network. And Java was designed to be a language that would make it safe to pick up these applications, so that's quite a step forward. But at another level, Java was designed to challenge the ownership of the desktop. Challenge who? Challenge Microsoft, obviously. If Java could fulfill its promise, if it could do everything that Sun Microsystems, who developed it, said, then it wouldn't matter what operating system you were running on your desktop. And if it didn't matter what operating system you were running on your desktop, then Microsoft would be a little unhappy.

IF: Howard, some of our listeners may be a little confused, since they share at least part of the same name, between Java and JavaScript. What exactly is the difference between Java and JavaScript and VB Script, for instance? How does that all fit?

HS: Even just taking the first two, Java and JavaScript, there's a world of difference. In fact, Java, as I mentioned before, was developed by Sun Microsystems and JavaScript was developed by Netscape, and it wasn't called JavaScript in the beginning. It was called Live Script. People who know a lot about Netscape's products probably know that everything that Netscape makes starts with the word "Live." And when they developed an HTML scripting language, they called it Live Script. But at the time, Java was a very hot thing, and still is a very hot thing. And with agreement with Sun, they decided to call Live Script JavaScript. And really, that's the only thing it has in common with Java is it shares the name. It's used for something entirely different. Java is used to actually write programs, whereas JavaScript is used as a scripting language for HTML. Java is a real, object-oriented language, and JavaScript sort of has an object-oriented flavor. The rules are quite different. In fact, JavaScript and VB script, which is Visual Basic Script done by Microsoft, are much, much similar, at least functionally. They both are HTML scripting languages, they work with HTML, whereas Java tends to work outside of HTML, so they're entirely different. I'd like to make one other point about them, and that is that Java is a serious programming language. That is, it takes real technical talent to code Java. This is not a thing that can be coded by somebody really that's far outside the information technology area. So it takes a real expert to program Java. But anybody who's poked around with programming, whether it's been Basic, or written a few macros or done anything like that can probably pick up JavaScript or VB script pretty easily.

JB: So would it be safe to say, then, Howard, that any of us, then, could actually do some programming with VB Script or JavaScript?

HS:. Yeah. Again, if you felt that you could write a macro or a couple lines of basic code--and by basic I mean the Basic programming language--if you could string together a couple lines of code, you could certainly write in JavaScript or VB Script. It's a very easy programming language. It's very elementary, whereas Java looks a great deal like C++, a very difficult language to program unless you're a programmer. If you're a programmer, it looks enough like C++, so in fact, if you knew C++, the transition from C++ to Java is not really a big deal.

KH: Howard, can you say a little bit about when you would use Java in your Web page vs. JavaScript or VB Script?

HS: Yeah, and I think that that's a good point in terms of looking at the function of the two different kinds of things. With JavaScript or VB Script, which is an HTML scripting language, what you would do, you would use that to affect the way your HTML looks. So for example, you might want some dynamic control over your HTML, or you might have some HTML and you might want the HTML to do something. So you want to affect things that have been put on a Web page with HTML. You can't do anything with JavaScript or with VB Script that HTML can't do. That is, if you could somehow change the HTML by yourself and display different things on your screen, JavaScript and VB Script just let you do that sort of automatically. Java, on the other hand, lets you take an area of a page and do things that you couldn't possibly do with HTML. It lets you put CD quality applications up right in the middle of a Web page. A good example of that kind of thing is, suppose you wanted to do some kind of simulation. You'd prefer not to have your students, for example, actually go out and run a nuclear reactor, but you'd like them to learn how to do that. You could write a Java applet, which is a little Java program that downloads onto the Web. You could write this little Java applet, and right in the middle of a page, you could have a nuclear reactor simulation that your students could play with. You really couldn't do that with HTML, and since you can't do it with HTML, you couldn't do it with JavaScript or VB Script either.

IF: Does dynamic HTML, which we've been hearing about lately from Microsoft especially, change any of this?

HS: Well, it changes -- it doesn't change the fact that you probably couldn't do a nuclear reactor simulation with HTML, but it does change how much you need to use a scripting language, because dynamic HTML, to be effective, requires some kind of scripting language to make the HTML move around. What most people are using is, they're using JavaScript or they're using VB Script. But there's other products that are popping up. Things actually coming from Macromedia and other companies that enable you to do things with HTML by providing what really amounts to another HTML scripting language. So you could have many, many different HTML scripting languages, and JavaScript and VB Script today are just the most common ones, but I wouldn't be surprised to see more in the future.

JB: Howard, you mentioned Macromedia. Is Shockwave one of the other -- is that equivalent, then, to JavaScript or VB Script?

HS: No, and here's where things get just a bit confusing, but Shockwave is a plug-in that also lets you do things on a Web page that amount to dynamic interactions, and in fact, it's very difficult on the surface. If you were looking at a Web page, it's very difficult to tell the difference between something that is really being run by Shockwave and something that's an applet, a Java applet. But Shockwave is neither Java nor is it JavaScript. It's not an HTML scripting language and it's not a Java applet. It's a plug in, of which there are many, that lets you, using some other language. In the case of Micromedia's Shockwave, I believe they use a language called Lingo, which looks nothing like Java and looks nothing like JavaScript, and it's not an HTML scripting language. But there's lots and lots of ways to get interaction on a Web page. JavaScript can do it, but at a fairly low level. Macromedia's Shockwave can do it at a little higher level, and Java gives you a great deal of flexibility, probably the most flexibility of anything, but it's probably the most difficult thing to tackle.

JB: Well, while we've got this nice continuum here, Howard, of the various tools for building interesting Web applications, is now a good time to ask you a question about just what about the Java programming language that Sun is licensing to Microsoft and then the Java IE programming language that Microsoft is actually using. Are they really the same, or if they're different, how different are they? Maybe you could address that.

HS: Well, Sun licenses a common programming language. They license Java, and one of the supposed advantages of Java--and in fact, it would be a wonderful advantage if everybody would just sort of follow the rules--one of the real advantages of Java is that you should be able to write an application in Java. Let's say this nuclear reactor simulation or whatever you're planning to write in Java. You should be able to write it once, and then you should be able to run it on every platform, every operating system. It shouldn't matter if a thing is running in Windows 95 or Windows NP or running on Macro S or Rhapsody or you name the operating system and the hardware. It ought to run just fine. Now, none of that's going to work if there's more than one version of Java. If there's more than one version of Java, you're going to have to write this thing for every different version of Java that's out there, so we would hope that kind of thing wouldn't happen. Unfortunately, it's happening to some degree. Microsoft has gone out and modified Java in some ways that makes it such that if you write for the Microsoft platform, the thing you write may or may not run on other platforms, and vice versa. This might be good for Microsoft. It's certainly not good for Sun Microsystems. I don't think it's good for the user community in general..

KH: On the practical side, Howard, as a Web page author, what kinds of things can I use Java and JavaScript to do? Can my Web page just have a little bit of Java script, or is there a minimum you need?

HS: Okay, Ken, you said Java and JavaScript. I think you meant just JavaScript, because they're really quite different animals here. When it comes to Java, if you're going to have Java on your Web page, you're going to have an applet, and an applet's a complete little program. The program might not do very much. It might be a very simple little program, but you're not going to sprinkle little bits of Java here and there inside your Web page. But you can do that with JavaScript because of the kinds of things that JavaScript can do. A line or two of JavaScript in the right place can do kind of neat things within a Web page. Of course, you might have lots and lots of JavaScript. A real simple example of a line or two of JavaScript is let's suppose you have a form on the Web that you want people to fill in and there's a field or two that you really want them to fill out. There's a couple ways you can do that. One thing you can do is you can say, well, they'll fill out the whole form. We'll take the form, we'll ship it off to the server, the server will look to see if they've filled in the fields they've supposed to have filled in, then send the thing back across the network and tell them, "Oh, by the way, I can't process this form because you didn't fill in fields two and three." Now, all our listeners know that documentation saying "fill those fields" is a waste of time. You ought to do that, but that doesn't mean people are going to fill them in. With JavaScript, one line of JavaScript could, inside the Web page, check to see if somebody has put something in the field. In fact, you could check to see what they put in the field. In other words, if the field was required to be numeric or to have nine digits in it or to be between a couple values, before this form is shipped back to the server. With JavaScript, it's just a line or two of JavaScript, you could check to make sure the fields are filled in, the fields have correct values, etc., avoiding this round trip back to the server just to tell the user that they've done something wrong. In fact, you can tell the user that the moment they leave the field. As soon as they put something in the field, you could come back before they even get to the next field and say, "No, no, that's got to be numeric."

KH: Howard, imagine I'm a Web page author and I want to really have a very sophisticated page, and I don't want everyone in the world to know how I did it. I just want it to kind of look like magic. Is there a difference between using Java and what would be revealed to a user vs. using JavaScript or VB Script?

HS: The answer used to be yes all the time, and now the answer is yes some of the time. I'll try to explain that a little bit better. If you code a Java applet, you can never see a source code for the Java applet unless the designer, as a separate step, chooses to publish the source. What happens to the source, the source is--I wish I could speak in italics and quotes here--

JB: You often do!

HS: Because the source is compiled. The source of Java is compiled, but it's really not compiled in the strict sense of compilation.

KH: But it's turned into something that isn't readable by any normal human.

HS: Right, it's turned into byte codes, so that it can be interpreted later, but it's called compiling it. At any rate, it's turned into these funny byte codes that no normal human being can read, and even that stuff is difficult to get anyway. That stuff is stored on the server, it's only downloaded so the interpreter can see it. But the source code is completely hidden. No one can see the source code under any circumstances unless you choose to let them do it. With JavaScript, the JavaScript traditionally has been part of the HTML. That's where it's always been. If you look inside a document, you'll see the JavaScript or VB Script scattered.

KH: So if I just say VIEW SOURCE on somebody's page, I can see the JavaScript?

HS: Well, you used to always be able to do that, and what's changed is--and I think it's a very good change--that it's now possible to take the JavaScript and store that on the server. And the advantage of doing that is suppose I write a nice little JavaScript routine that checks to see if various fields are numeric. If I've written this and it works really well, it would be really nice if lots of folks in my organization could share that. And if I just give that thing a name, store it on the server, then all I have to do is, from my Web page, point to that thing. This even means you could actually do such amazing things as enforce some standards with HTML because my JavaScript code could actually generate HTML and we could decide as an organization that our backgrounds will always look this way and our headings will always look this way, and here's how we would check our fields and so forth. And if somebody makes a change to this thing, we make a change to the thing on the server, which all these Web pages point to. Amazingly, all the Web pages suddenly do the new thing correctly so we don't have a difficult synchronization problem. So if you do look at a Web page and you expect there's JavaScript there, and instead of JavaScript you see something that says LANGUAGE = JAVA SCRIPT and you see SRC = something that looks like a filename or URL, well, it's pointing to a filename or URL that lives out on the server, which you may or may not be able to see.

KH: Now, when you say that JavaScript is on the server, does that, then make a difference as to which server you happen to be using? As to whether you can do that? Or do all the servers, Web servers support that functionality?

HS: Well, when I say the thing is on a -- oh, are you asking do all browsers support that?

KH: No, on the server end. When you said that the JavaScript would be on the server.

HS: Yeah, all servers support that because all you're doing, it's just a URL out to the server, effectively. So the server is delivering what it thinks is another HTML page. Any server that can deliver an HTML page.

KH: So it's still being executed by the client?

HS: Oh, absolutely, it's being executed by the client, but the thing is, it's no longer required to be embedded inside the HTML page, and with the obvious advantages of being able to share code, which is kind of a nice thing to do.

IF: Yes, it is.

KH: We're just about halfway through our Expert Event this afternoon. Might be a good time to remind folks that you can join us by participating on the telephone, by calling area code 734 647-2801, and you could also e-mail us at utw.cren.net if you're participating via real audio and connected to our Web page, you can just use the link on the Web page to send us e-mail.

JB: Thank you, Ken, for that reminder. I was just thinking myself that it was just about time that we did that. You know, as a special experiment this after, we had also talked about moving from the Web page and actually doing some linking from the Web page and having Howard go through an example of what--a little exercise that he's got on the Website. Howard, as part of that was we had talked about the question about if there was any way that I could incorporate perhaps just a Java applet into my code. Would you like to address that, and perhaps have our listeners go actually to the Website and see some of the code that we're talking about?

HS: Okay, we could certainly do that. What I think Judith is talking about here is that, although Java applets operate outside of HTML, since they appear inside a Web page, you actually have to code a little bit of HTML to get the Java applet to appear, and there's not much HTML to do that. Writing the Java applet is a bit of a challenge. In fact, it's quite a bit of a challenge, but once somebody's written an applet, anybody can use the thing, so although most folks listening here are not going to go off and write their own Java applets, if there's a library of Java applets or if somebody else has written one, it's relatively easy to put it inside the Web page. Do you want to read that URL, Judith?

JB: Certainly, let me just back up here. We've got a nice little applet that says that Java makes the Web come alive. And let me back up here just one more time.

KH: You'll find the link at the bottom of the Web page under Howard's picture. It's https://webware.princeton,edu/howard/cren/java.htm.

JB: Right, and as Ken said, it's right there, the third little paragraph right under Howard's picture. If you just click on that, it will in fact take you to a whole host of information about Java and JavaScript.

HS: Once you get there, you'll see that the third link down from the top says HOW TO MAKE LIVE DOCUMENTS, JAVA AND JAVA SCRIPT. If you click on that, you'll be positioned properly to look at this thing.

JB: Okay, my system is coming up and I'm there.

KH: I'm there.

HS: Okay, what this is, this is actually an applet that I did not write, and I do have the source code for the thing available here, something you would normally not see. But the author graciously agreed to let us do this, and so if you look at the thing, you can actually look at the source code. But skipping the source code for the time being--in fact, forever, since we're never going to go through that thing--what you'll see is you'll see the nervous text applet operating on two different text strings. The top one says CREN IS COOL and you can see the words CREN IS COOL moving around wildly. And underneath that, it says JAVA MAKES THE WEB COME ALIVE. Right below that is the HTML coding to insert that into a Web page, and you can see that there's a little gray area on the page in which the applet operates. That area is actually defined inside the HTML code. You'll see that there's a width parameter and a height parameter, and those things are in every applet HTML definition. You just say how big an area on the Web page do you want this thing to live in. So it gobbles up a little area of the Web page and operates inside there. The other really interesting thing in this HTML is, there is a thing that says PARAM and it says NAME =, TEXT VALUE = YOUR MESSAGE HERE. If you get somebody to code an applet for you, or if you discover an applet, if the applet's well-written, what it will have is it will have a bunch of parameters in it, and these are parameters whose values you can fill in in the HTML. So although you probably can't write an applet yourself because they're difficult to do--at least, for most of us, we can't--if you have an applet written by somebody else, you can put it inside your Web page wherever you want. That's easy to do. You can see there's just a couple lines of HTML to do that. And even neater is, if the applet was written with enough parameters, what you can do is you can change the parameters easily yourself. So if you're in a position where you can get somebody to write one of these for you or you control people who write them, it's very important that they write these things with lots of parameters. Here, we only have one parameter, the parameter called TEXT, and we can put any value we want. The value is the message that appears here, so we have this applet. The applet could have been written with the text hard-coded in it, so we could have had an applet that just displayed four words of text that moved around, but here we can put any words in. It would have been nice if this applet had another thing that let us change the color of the background or let us change the color of the text or let us change the style of the text and so forth. If this were a really well-written applet, it would have had lots and lots of parameters in it, so although I couldn't go out and write the applet myself, it would seem like I still had a great deal of control over the thing.

JB: Howard, did you want to go on, and also we've talked a fair amount about the difficulty of seeing the type of code behind that type of an applet. Did you want to mention your annotated link from this site?

HS: Yeah, of course, I would like somebody to look at every line of this site, and we expect they would go through it very carefully.

JB: Well, given a few Java Beans or whatever, right?

HS: I took so much time putting this thing together. But for those folks who just want to get the highlights here, there is a link to the source of the applet, untouched. This is just the way it appears as provided by the author. But if you go down a few links, you'll see there is an annotated version of the source. And what I've done there is I've taken the source of this applet and I've explained what virtually every line of the thing does. So you can read through this applet. This will not teach you how to code in Java, not by a long shot here, but what it will do, it will give you this very simple applet. You can see what it does, you can actually insert this applet in your own HTML. You can feed it different parameters, and by going through the annotated source, you can see what different parts of the thing do and how an applet's put together. I think it's a real good example of how a simple applet's put together. You'll also notice that, although this is a very, very simple applet, as you go through the annotated source, you'll see this thing uses such things as multi-threading, which virtually every applet does. You would think that with just a couple letters wiggling around, it wouldn't do all this kind of stuff, that there's only one process running at a time, but in fact, there's more than one process running here at a time. And that's explained in some detail in the annotated version of the source.

KH: Howard, since you've mentioned that the writing of the applet is kind of a high level advanced task, is it likely that we'll see the day when pre-produced applets, if you will, are marketed or sold by companies much in the same vein that photo bank image repositories are licensed for one-time-only or multiple use?

HS: Well, Ken, there are lots of applets out there already, and you can certainly take an applet that's out there already. There's a lot of free applets out there, and you can take them, and you can put them in your Web pages if you have the right to do that and change the parameters and things. But most of those things today are toys, and most of the kind of applets that you'd really want really need to be customized to do what you really want them to do.

KH: Oh, I see.

HS: I mean, if some company or some group of people, whoever, could figure out some set of applets that could be generally useful and could put enough parameters in them, that would be a really neat thing. I hope it happens.

IF: Howard, what are Java Beans and what effect might they have on our ability to create Java programs more easily?

HS: I was going to tell you about Java Beans just being little things that live in a jar, except for the fact that actually Java Beans, which I'll talk about in a minute, actually are grouped in collections and stored in a thing called a Jar.

JB: Oh, dear, there goes that analogy!

HS: (Inaudible.) What I'll try to do is in the least technical way I can do this, one of the things about a Java applet is that although it can be used in a Web page and things, if you have a Java program that you want to be used by lots of other programs, it would be nice to have a standard interface to these Java programs, and a standard interface that would expose all the variables and all the methods. And for folks that are not familiar with an object-oriented paradigm, methods are sort of like functions, without going into it deeper than that. That'll work. And what a Java Bean does, a Java Bean is a way of encapsulating a Java program in such a way that there is a standard interface that easily exposes the variables and the methods inside that. Now, sometimes you're going to have a bunch of related Java programs or Java applets, and you can pack them together in a thing called a Java Bean Jar. And then what we can do is we can move these Java Beans around from place to place and not even knowing what's inside this Java Bean, we kind of know what the interface is going to be. And this is a very powerful thing, defining a standard interface. This is what you'll see in any modern operating system or any kind of modern software, where there will be a thing called API, an Application Program Interface, that's a standard, defined way to get to the thing. And if you can define a standard interface to something, it makes the thing much, much more usable by many more people. And that's sort of what the fuss about Java Beans and Jars of Java Beans and other high-level collections of Java programs is all about.

JB: Howard, let's go back again and think of myself or think of the person who is developing for the Web, and we know, too, that both Netscape and Internet Explorer tend not always to interpret the code the same way. Is there some way, in fact, that I as a developer can code and optimize for more than one browser?

HS: Well, unfortunately, the statement you made, Judith, is correct, that JavaScript is not the same for Netscape and all its products as it is for Internet Explorer. Internet Explorer does support both JavaScript and VB Script, so one would think you could write in JavaScript and it would be fine in Netscape, in all their products, and in Internet Explorer's products. And that's probably 90% true. Most of the things you write work just fine. But some don't, and so you are faced with the choice of writing in some subset of JavaScript that you know will work under both browsers. Of course, both browsers are changing. Tomorrow morning, the browsers are going to be different, so if you pick some subset to write in, maybe that will work with the new browsers and maybe it won't. We really desperately need some standards here, and of course, there are standards here. What we need even more than standards are for people to adhere to them. It's very tempting for both Netscape and for Microsoft to see some new feature that they believe is a neat thing to have and to code it in, even though it's outside standard. There's unfortunately lots of those, and any good reference on JavaScript will document differences that it knows about when it was published.

JB: So if I want to, in fact, have fairly enhanced pages for both browsers, that's definitely another level and layer of design and development than if I'm just going out for what I can assume is there? Is that safe to say?

HS: Yeah. Especially with JavaScript. You're going to have to be pretty careful. I mean, I would in environments here where I actually develop Web pages and where the Web pages are going to be used in a variety of hardware and software platforms, it's a good idea if you're in a situation where you're developing Web pages, even if you're using simple HTML or whatever you're using, to be sure that you try the things on a variety of platforms and a variety of operating systems that reflects what you believe your user community is going to be. In fact, one way to discover some of the strange machines that you didn't think your users had is to put up a Web page. They'll be calling you.

KH: Howard, if the animation makes one think of JavaScript, can one assume that if one sees animation and movement and activity on a Web page, that that's what they're looking at.

HS: No, they're probably not looking at Java at all. That's probably one of the least likely things. If you see something moving around on a Web page, it's hard to put exactly what's at the top, but my guess would be if you see something move, it's a thing called a gif animation. It's just a gif file. I'm not sure if that's pronounced G

IF: or JUF. Ira?

IF: I think both work.

HS: Okay. Well, I've learned G

IF: first, so I'll just keep using that. But basically, a gif animation is a standard gif file that has many frames and control blocks that decide how those frames are going to be displayed. And all the browsers can display them and they're very easy to build. There's free or shareware programs that enable you to build gif animations, and because they're easy to build and because they don't take a lot of time to download and are real simple to do, lots and lots of people use them. And if the people listening don't know how to build them, somewhere else I think in this untangling the Web series, we talk about gif animations. You ought to learn how to build them. So if you see things moving around, they probably are, but they might be things done with Shockwave or other plug-ins, or, in fact, they might be Java applets. Or increasingly today, they might be DHTML. Dynamic HTML can make things move around, so it could be lots and lots of things.

IF: Howard, could you say a little bit--you talked about how difficult it is to build some of these Java applications and you described Java Beans and so on. Are there tools that are on the horizon or here already that will eliminate some of the complexity of the programming and allow us to create real applications graphically by just tying elements together?

HS: That's certainly a wonderful dream, Ira, except for the word eliminate, which is pretty strong language there. There are lots of things out there that claim to be able to do this kind of thing, and there's lots more things that claim they can really do this kind of thing that are coming. The things that are available today and the things that are available immediately on the horizon just do a great deal of the user interface kind of work, that is, they let you build what the applet or the application will look like. But very soon after you have built the little objects, moved the little buttons into their place and made the little buttons look three dimensional and green and fixed the text and all that kind of stuff, very soon after you do that, little windows open in which you're invited to write the Java code yourself. So they do some of the work, and it's certainly nice that they do the work of building the user interface for you, but you still have to know a great deal of Java. They're still not writing the code for you. And I think that's a very difficult thing for them to write the code for you. It might be that we're going to have to wait for the kind of thing that Ken was talking about, which was can we get a bunch of building blocks in Java together, and if we could get a big library of building blocks and we had one of these Java visual development environments, then maybe we'd have to write a little bit less Java code. But today, if you're going to do this with any one of these tools, all you can really write are little toys, little things that amount to not much more than the demos that come with these packages. That's really all I've been able to do with them.

IF: Okay, so you've convinced me that if I want to write a Java program, I'm really going to have to learn Java. It seems that every time I go into the bookstore, I see ever more Java books appearing, and some of them make claims like "Learn Java in only 21 Days!" Is that realistic?

HS: Not at all. You can't learn Java--actually, you've seen one of the less outrageous claims which is "Learn Java in 21 Days." I've seen a book that says "Learn Java in a week!"

KH: Or while you sleep!

HS: First of all, I'm sure, Ira, you've even noticed somebody, when I mentioned I was going to be chatting about Java and JavaScript, they actually dumped a book called Learn Java in 21 Days at me, and I notice that it's 500 pages of technical material that you're going to go through, and it has a CD ROM in the back that has 600 meg of supplementary material on the thing. So even if it's really 21 days --

IF: These are 21 earth days or --

HS: That's really unrealistic. I think the kind of people who could learn Java in 21 days are people who are experts at C++. They could probably do that, but short of those folks, it's unrealistic. I think that you should expect that your best programmers, people who know C or C++ are the people who are going to learn this. And even those folks I would give more than 21 days to do this. And as for the book that said I could learn it in a week, well, maybe I could learn to code the HTML for an applet.

IF: So you don't think there's any danger of us being overrun by Java programmers anytime soon?

HS: No, and in fact, I think if you pick up the New York Times or The Wall Street Journal, you'll see that good Java programmers are commanding high salaries because they're pretty scarce. But if you look at resumes, everybody claims they can do Java. Why not? It's the thing people are looking for.

KH: Howard, we talked a lot about the Web. Are we seeing Java being used for programming in any other environments?

HS: Yeah. In fact, Ken, one of the biggest areas where Java's being used, it's being used for traditional MIS applications, so instead of writing your payroll systems and your other financial applications, your loans and receivable systems in, say, COBOL or some traditional MIS language, Java's beginning to make, anyway, real inroads in there because it has lots and lots of advantages. It's this new, modern language. It uses an object-oriented paradigm. It's safe, it's well-structured. There's lots and lots of reasons why it's very attractive, and I think that for decades now, people have been looking for some alternative to COBOL.

KH: We're down to just slightly under three minutes in today's Expert Event, probably time for a couple more questions. Judith?

JB: Thank you very much, Ken. I think there was just one other thing that we wanted to make sure to share with our listeners today, and that is just a little tool that Howard had generated about a week or so ago. And that was, if in fact, I'm developing a Website and I want to make certain that someone, depending on which browser they're using, I would be able to know how to do that, Howard, what's the little tool that you developed for that and how might someone use it?

HS: Well, if every tool I was asked to develop consisted of only one line of code, I'd be in just fine shape, here.

JB: This one's short, you're saying?

HS: That's what this is. But I think this is a good example of the kind of thing that you can do with one line or just a few lines, anyway, of JavaScript. And this happens to used one line of JavaScript. Is there a URL of that thing out somewhere?

JB: Well, you know, no. We'll put it up, but would you mind telling what it is?

HS: Sure. Let me tell you what this thing is. What happened is that in the last presentation, where we were talking about HTML, Ken Klingenstein called in and he was teaching a class at the time. And his students wanted to know if there was a way, from inside an HTML page, if you could tell what browser the HTML page was being displayed on. And from some of the things we've said today, you can see where that would be a pretty important thing and actually an interesting thing to be able to do, since the browsers treat HTML differently and they treat JavaScript differently and generally they behave differently. If the HTML page was aware of which browser it was running on, with JavaScript or VB Script or one of these things, you could actually code the page so it would detect what browser was on, and then it would just use the features of the particular browser, avoiding the features that didn't work on this particular browser. So you could have a page that was sensitive to the browser, and in fact, to the operating system it was on. This little page, which is at https://webware.princeton.edu/howard/browtype.htm just implements a little button. There's a little button that says WHICH BROWSER on the page. If you click that button, you'll discover that what it does, it gives you the code name of the browser, it gives you the browser name and it gives you the version of the browser and the operating system you're running on. And this is all done with a single line of JavaScript. If you view the source of the thing, you'll see there's one line of JavaScript in there. I believe the code is pretty clear, since there's only one line of it. And what one could do, you obviously wouldn't just print this thing out, but if you took those values and tucked them away into variables in a JavaScript program, then you could do different things based upon their value.

JB: Okay, and Howard, you know the URL that you gave out is almost exactly what we have up there on the Web page. You might want to just repeat again what comes after your name, howard.

HS: Okay, it's the word BROWTYPE.htm. And again, just if you go to that thing, you'll see a yellow page that has a button that tells you which browser you're using. And if you click on the little WHICH BROWSER button, which is the only thing on the screen, just about, a little box will appear generated by JavaScript which will tell you the code name of your browser, the browser name itself, and the version and the operating system you're running. This ought to look different on different browsers. Try it on Netscape and then try it on IE 4.0 or other browsers.

JB: And we will put that little note up on the Website within the next day or to so people can come back to that if they don't have time to do it right now.

IF: I just tried it on Netscape 4.04 on Solaris and it worked just great.

JB: Okay, it picked up where you were, right?

IF: It picked up, it told me I'm running Mozilla, which is otherwise known as Netscape.

HS: Right, that's the code name.

IF: Right. Netscape 4.04, and then it tells me X 11 and SUNOS 5.6, which is correct, so yes, it works, even on Solaris.

KH: Well, we're out of time.

JB: All right. And thank you so much, everyone, for being here, and if there are follow-up questions, you can pose them to the same e-mail address of utw@cren.net. Also, be sure and mark your calendars for the fourth and last in the spring series by Howard, and that event will be on Tuesday, March 10, at our more regular time of 2:30. And Howard's going to be talking again about the future of the Web and where it's going.

KH: And don't forget to watch the CREN Website in general for the event phone numbers and the URL's, just like the priors to the next Expert Event, and if you'd like to receive announcement messages for the session, send e-mail to CREN at cren.net.

JB: All right, thank you. And Howard and all the event participants, thanks for being here. And also thanks to everyone who helped make this possible today. That includes the board of CREN, Corporation for Research In Educational Networking; our guest expert, Howard Strauss from Princeton; Ken Horning at MERIT; C. L. Phillips at UM Online for the audio coding; and Ira Fuchs, our special expert discussant. Thanks all of you on the phone and on the Web. You were here Because It's Time.