Difference between Java and Javascript

[Great Lee]

Hello,

As I am beginning to learn how to program in Javascript, I am wondering what are the advantages and disadvantages OR pros/cons of using JS versus say a language like Java? Naturally I want to learn both. However, I am just beginning and am wondering about this. Thoughts?

[Tim Cooke]

Java and JavaScript are two completely different programming languages. The only commonality is the word 'Java' in the name.

[Tim Cooke]

I should follow this up by clarifying that Java is a server side programming language that runs on your operating system, where JavaScript is a client side language that runs in a web browser. Because of this fundamental difference it's difficult to provide a pro / con list to compare them.

[Maneesh Godbole]

I would not define Java as "server side programming language" The client side java representatives are Swing and JavaFX (and Android)

[Mike. J. Thompson]

And Javascript does not have to run in a browser. It can run in the JVM just like Java can, and there are mechanisms for Java and Javascript to interact with each other I believe.

But as mentioned Javascript and Java are completely different languages. Java is statically typed and Javascript is dynamically typed. In that respect it is more similar to python than Java.

[Tim Cooke]

Oh dear, oh dear.... Seems I'm adding confusion rather than clarity. Mike and Maneesh are, of course, spot on correct. I suggest the OP take more heed to their advice over mine.

[J. Kevin Robbins]

The best description I've heard was "Java is to Javascript what ham is to hamburger". They have nothing in common except an unfortunate naming similarity. The "real" name for Javascript is ECMA Script, but at the time it was being developed Java was taking off in popularity so the authors of ECMA decided to try and capitalize on that popularity by choosing a similar name. It's caused nothing but confusion ever since then.

[Bear Bibeault]

J. Kevin Robbins wrote:The best description I've heard was "Java is to Javascript what ham is to hamburger".

Thanks for the mention, J. Kevin. That quote is from chapter 3 of my book Secrets of the JavaScript Ninja, accompanied by the following figure:



Another (not of my doing):



Just think of them as completely separate languages with different uses and approaches. The unfortunate naming is just, well, unfortunate.

[Bear Bibeault]

To add some more to the conversation:

What's been happening with JavaScript over the past few years is nothing short of astounding. Back before 2004 or so, it was just regarded as a warty little language that was used sparingly in the browser for image rollovers and other light uses. Then came Ajax, and everything changed. Suddenly, client-side JavaScript was important, and companies like Google led the charge in creating heavy-duty client side web apps (gmail, for example) that exploited the new capabilities. (And to give Microsoft some well-desrved and rare credit, they really spearheaded the whole thing by inventing the predecessor to Ajax for Outlook Web Access.) And so, JavaScript finally started getting some respect, not only from web devos, but more importantly from the browser vendors. (If you chart JavaScript performance in the browsers over time, it's impressively steep.)

And then came NodeJS. Suddenly orange juice wasn't just for breakfast anymore. JavaScript has escaped the confines of the browser and is spreading to the server in a big way. Back within the browser, the number of MVC frameworks such as Backbone and Angular, templating engines such as Mustache and Handlebars, as well as module managers like Require, have made client-side development a whole new ballgame.

I think that the days of creating client-side presentation on the server with technologies like PHP, JSP, ASP, and (shudder) JSF, are numbered. Many modern web applications (such as a number of the ones I am working on), use the server to present a RESTful API which is consumed by client-side JavaScript. Templating is done in the browser, not on the server.

And, of course, JavaScript isn't standing still. Some of the upcoming changes to the language are quite exciting.

In short, I think anyone who still thinks of JavaScript as a not-very-serious "toy" language, especially if they are working in web development, is in for a rude awakening at some point.

Sure JavaScript still has its warts -- what language doesn't? -- but regardless, it's a crucial tool for modern web development.

[David Byron]

In addition to all the preceding, JavaScript is now regarded as an important compilation target for languages such as ClojureScript and CoffeeScript (among many others).

[J. Kevin Robbins]

@Bear, I didn't realize that quote was from your book. See how much I learned?

I've heard some developers say that they just loath working in JavaScript but I don't get it. I really enjoy it, somewhat more than Java perhaps because of the visual feedback. I wish it was statically typed because I think that's less error-prone than dynamically typed languages, but that's just my opinion. There are probably others that like the flexibility of dynamic types.

I really need to look into NodeJS and Angular and start learning that stuff. The company where I work still writes scriptlets at our corporate headquarters and when talk comes up about moving into the 21st century they mention JSF and I just cringe. My first dev job in the Java world was doing JSF and I hated it. You change one control on the page and 10 XML files change behind the scenes and you don't even know where they are.

I'd like to be able to propose RESTful services and JavaScript frameworks as a better option. Any tips on a good place to start learning that stuff?

[Bear Bibeault]

I'd start off with BackboneJS --I think it's by far one of the simplest frameworks for client-side MV*.

[Bear Bibeault]

J. Kevin Robbins wrote:when talk comes up about moving into the 21st century they mention JSF and I just cringe. My first dev job in the Java world was doing JSF and I hated it.

My view of JSF (which I have always detested as a Rube Golderg machine that is much more complicated than the problem it is trying to solve):

[Winston Gutkowski]

Bear Bibeault wrote:I'd start off with BackboneJS --I think it's by far one of the simplest frameworks for client-side MV*.

Wow. I've just had a quick browse of the main page, and several things immediately "made sense". However, it would be nice to see some examples of the "whole thing" in context (ie, what a smallish, targeted backbonejs app looks like along with its associated HTML) so I can tie things together in my mind. Is there any tutorial on the product you can recommend?

Also: Does it (or indeed JS in general) come with any documenting tool like javadoc, or it is basically down to well-placed comments?

Winston

[Bear Bibeault]

There are a number of BackboneJS books out there, but I haven't yet found one that I consider "The Book" to recommend. Guess all of this is too nascent to have accumulated really stellar documentation.

And no javadoc that I know of -- the nature of Java allows inspection; JavaScript is a very different animal.

What I have noticed is that the better JS devos comment public entry points with comments heavily influenced by javadoc.

[Winston Gutkowski]

Bear Bibeault wrote:There are a number of BackboneJS books out there, but I haven't yet found one that I consider "The Book" to recommend. Guess all of this is too nascent to have accumulated really stellar documentation.

Pity, because it really "grabbed" me, for all the "Rube Goldberg" (or, on this side of the pond, Heath-Robinson) reasons you suggest.

Darn, I'd love a simple way to represent data and logic visually over the Internet. It's the main reason why I regard myself as an "M.dot.C" programmer.

And no javadoc that I know of -- the nature of Java allows inspection; JavaScript is a very different animal.

But (especially with something like backbonejs) in play, probably in need of precisely the same order of documentation (possibly even more, since it's less familiar). Unfortunately, the only source example I was able to find had no comments in it whatsoever.

What I have noticed is that the better JS devos comment public entry points with comments heavily influenced by javadoc.

Well, maybe someone will write one then.
I suspect that the nature of code like this is different though.

Winston

[Bear Bibeault]

One thing about frameworks like BackboneJS -- they provide a pattern for use. So, once you know the patterns, it's easy to figure out how things work. As opposed, that is, to everyone just going their own way.

[Nooriya Mishra]

The main difference between Java and JavaScript is that while Java is a programming language, JavaScript is scripting language.
Java uses block-based scoping; JavaScript uses function-based scoping.

[Campbell Ritchie]

Welcome to the Ranch

You can tell by the weak jokes that this particular question crops up frequently

[Bear Bibeault]

Nooriya Mishra wrote:The main difference between Java and JavaScript is that while Java is a programming language, JavaScript is scripting language.

I would say that those terms are rather meaningless. Both are programming languages in that you can write complete programs using either. There's no real official definition to "scripting", so it's not clear what that really means. Perhaps you meant to express that Java is a pre-compiled language, while JavaScript is run-time interpreted.

Java uses block-based scoping; JavaScript uses function-based scoping.

Scoping is actually a lot more complicated than that. But that's a whole 'nother topic.



[P.S. Does anyone "get" the retro pop-culture reference above?]

[Peer Reynders]

Winston Gutkowski wrote:

What I have noticed is that the better JS devos comment public entry points with comments heavily influenced by javadoc.

Well, maybe someone will write one then.

No need to.
JSDoc 3 - or for AngularJS ngDoc

How to Generate JavaScript Documentation with JSDoc 3 and PhpStorm

Nooriya Mishra wrote:The main difference between Java and JavaScript is that while Java is a programming language, JavaScript is scripting language.

How are scripting languages not programming languages?

Besides the differences in scoping the "Object" is central to Java, while the "Function Object" is at the core of JavaScript. Java practices "Classical Object Orientation" (i.e. class-based) - JavaScript does not - while there are constructor function objects there is no need for classes and interfaces due to the dynamically typed nature of JavaScript. JavaScript's prototype chain isn't about "polymorphic inheritance" (i.e. its not about the Liskov Substitution Principle) but mostly about code and memory reuse (and we were all taught to "prefer composition over inheritance"† anyway right?). etc.

†Gamma, Helm, Johnson, & Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Reading: Addison-Wesley, 1994), p.19:

First, you can't change the implementations inherited from parent classes at run-time, because inheritance is defined at compile-time. Second, and generally worse, parent classes often define at least part of their subclasses' physical representation. Because inheritance exposes a subclass to details of its parent's implementation, it's often said that "inheritance breaks encapsulation" [Sny86]. The implementation of a subclass becomes so bound up with the implementation of its parent class that any change in the parent's implementation will force the subclass to change.

Maybe things would have been a lot less confusing if they would have stuck with "Oak" and "LiveScript" (or "Mocha").

Flanagan, JavaScript: The Definitive Guide 5th ed (Sebastopol: O’Reilly Media Inc., 2006), p.2:

Other than an incomplete syntactic resemblance and the fact that both Java and JavaScript can provide executable content in web browsers, the two languages are entirely unrelated. The similarity of names is purely a marketing ploy by Netscape and Sun (the language was originally called LiveScript; its name was changed to JavaScript at the last minute).