Why use Java instead of HTML?
Because HTML is a passive code. It does nothing but tell the browser how to display text and graphics, and creates hyperlinks. Javascript can actually do things, like accept and process user input, modify the display according to user preferences and any number of other things.
It should be said that Java and Javascript are not the same thing, and someone who can explain the differences between them will be along soon.
Java is an interpreted programming language developed by Sun Microsystems. It differs from other languages like C++, in that instead of being fully compiled into EXE files, it is partially compiled and then run with inside of a “virtual machine” on the user’s computer. The virtual machine is an intermediate program that takes care of file system access and other low-level stuff, and makes it possible to run Java code on any platform without recompiling. It’s possible to do commercial apps with Java, but because it’s slower than its competitors and doesn’t do EXE files, it has largely been relegated to a teaching role. My college programming courses so far have all been in Java.
In the 90’s, Java was supposed to be the next big thing on the web, and applets (small programs with limited functionality, like stock tickers) showed up on a lot of sites. However, people began to realize that said applets were slow, messy, and prone to breaking (because of all the overhead from the virtual machine), and technologies like PHP and Flash took over.
At the height of all the Java hysteria, Netscape renamed their LiveScript technology to JavaScript. JavaScript was and is useful because it lets you change elements on a page in real-time (without reloading the page). Of the other technologies you see on the web, only PHP and possibly some newer XML-based stuff can do this. JavaScript has support in every major browser from about version 3.0, and has been adopted by the World Wide Web Consortium (the standards group for web development).
Because you can’t do any of this in HTML.
Daver, PHP is a server-side technology. Was this just an acronym mix-up?
I agree with most of what Daver said except
Jave hasn’t lived up to the hype on the desktop side, but there’s a lot of Java out there on the back end that you’ll probably never see. This is it’s easier than native executables to move from mainframes to linux to OSX to Windows. A Monster search tossed back 3800 for Java, and 2400 for C++.
Hal
And I agree with most of what Daver said except
As previously mentioned, PHP can’t do this, as far as I know - it’s merely a server-side technology. However, the new .NET technology (C#/VB.NET/ASP.NET/CLI) can do some basic stuff with real-time changes, assuming that the client has the .NET framework. Some of it is jimmied through an awkward machine-generated JavaScript, but stuff like validation is original code.
And I agree with everything Daver said except for this.
Java, the language, has no prohibition against being compiled to a native EXE. It’s the Sun compiler that compiles it to VM code. Nothing in the actual language prohibits it from making an executable in completely the same sense as a C++ program.
Also, to say that it’s not fully compiled is something of a misstatement, as well. Java code IS fully compiled, just not to the x86 instruction set.
Nanoda, that’s a great site. Is it yours?
This is only vaguely bordering on true if you restrict the discussion to client-side applications. It’s not even remotely true in general. A tremendous amount of large-scale programming is done in Java to create web applications and enterprise apps. I can point to a number of shops and hundreds of programmers (and this is just my inner circle, not an industry survey) that use Java to create large mission-critical apps for financial services, manufacturing, and all kinds of real-world applications. Even on the client side, Java is becoming more prevalent with the use of WebStart for distribution and now that Swing is supported in applets. Java is far from being only a pedantic language. Perhaps your college uses it because they’re trying to teach you to earn a living.
Spectre - I only wish. My best Java projects were all school projects. My personal favourites were the Whack-A-Mole™, and the classic Towers of Hanoi. That site is pretty good though.
What Daver said about PHP is correct if he’s reffering to JSP, a Java based server side language. JSP is moderately popular still, although as he said, not as much as some others.
No, it’s not. Both PHP and JSP are server side, and thus don’t allow one to change what’s shown in/to the browser without reloading the page.
XML alone can’t do it either, but with the addition of some client side scripting (javascript, etc) can be quite powerful. SVG for instance is a fully animatable scriptable graphic format implemented with xml and javascript.
The best java game in the world:
http://www.brackeen.com/home/scared/
Do you mean that Daver meant to compare PHP to JSP rather than applets? At least that comparison would make sense since both PHP and JSP are server-side code, but he seems to be specifically talking about client-side code (applets) in saying they were messy and slow, and comparing applets to PHP is ridiculous. They’re completely different roles.
We’re talking about client-server applications here. Some code runs on the server producing output for the client and other code runs on the client. Server-side code alternatives include PHP, JSP and servlets, ASP (which can be written in a number of languages including Javascript but are typically VBScript), CGI, and several others. All of these provide output for the client browser to render. This output may be plain HTML (i.e. a PHP or ASP script on the server may send nothing but HTML to the client) in which case the browser just renders it, or it may include executable code such as Javascript (embedded in the HTML) or some completely separate application run by a plugin or extension such as a Java applet or Flash file.
The OP itself is nonsensical. There is really no comparison between Java and HTML and you wouldn’t use one in place of the other. Java is a language used to write applications which might be used on the server to produce HTML. HTML is just a markup language specifying the layout and display details of content.
This thread seems filled with confusion and misinformation, and I’m not even sure there is a valid question to be answered. Perhaps the OP could clarify exactly what the issue is. Are you really wondering about why you might embed Javascript in HTML? Or why you would use Java (or some other server-side code) to create content instead of using static HTML files?
Yeah, well, speaking of misinformation, you are actually saying Java is only used server-side?
Not that I speak for micco, but:
(bolding mine)
seems both an answer to your question and a pretty accurate description of what is going on.
Did you miss my first post where I mention applets and WebStart? Or did you just miss my mention of applets in the second post which magog already pointed out? I was talking about server-side code because Daver was trying to compare PHP to something, but I’m not sure what since he said applet but surely couldn’t have meant that.
If you’re going to bandy accusations of misinformation, I’d appreciate you pointing out exactly where I lied or bent the truth instead of mischaracterizing my post.
No, I didn’t miss any of that. That is why I asked if, rather than assumed that that is what you meant.
I concur that, at a technical level, Java and HTML are not mutually exclusive on the browser side, and that a Java applet won’t even run in your browser without being referenced by some HTML. But non-technical users probably don’t care, and when you say
a lot would then say “Then what’s the deal with my favorite website having that new Java navigation bar?? It used to be plain HTML!”
Within that scope, Java certainly does replace HTML. A Java applet serves the same function that a bunch of <a href=… tags used to. That the applet had to be placed on the page by an HTML tag is another matter.
I was irritated because I feel the statement is misleading to the average user.