I agree with Matthew Johnson.

One can build a robust and sophisticated full-stack web app with Ruby (on Rails or lighter weight Sinatra) with little to no Javascript.

The importance of JavaScript comes later when someone convinces you that they need you to build a Single Page Application.

So I suggest you set up your curriculum in this order:

1. Learn Ruby on Rails from soup (html templates, controllers) to nuts (models and ActiveRecord database migrations);
2. Learn rudimentary Javascript and JQuery because you'll likely need to add some user-friendly schmutz to your server-side Rails web app;
3. Progress to intermediate Javascript. Look into frameworks like Angular.js and Backbone.js (w/ Marionette). But before you do too much Javascript, check out CoffeeScript.
4. Learn CoffeeScript because it's Ruby-like, you will already know Ruby, and CoffeeScript can generate nearly perfect JavaScript with much less WTF head scratching. Ultimately you'll want to be able to write sophisticated client side code, but you'll want to try to avoid the hairball that Javascript invariably grows into with a Single Page Application.

All the best in your journey.

Javascript has some gotchas, you never need to learn "everything about javascript", but surely you need to learn all good parts - and be aware of bad parts. Douglas Crockford's book - JavaScript: The Good Parts: Douglas Crockford: 9780596517748: Amazon.com: Books
Javascript is small and to write code substantial in size and maintainable at the same time, you need to know about Javascript Idioms. This has a very important role when you are writing libraries for others. Although Douglas Crockford's book covers almost a lot of good practices, but you may wish to look at: JavaScript Patterns: Stoyan Stefanov: 9780596806750: Amazon.com: Books . Sometimes you need a full reference of Javascript. Look for Amazon.com: JavaScript: The Definitive Guide: Activate Your Web Pages (Definitive Guides) eBook: David Flanagan: Books

Fortunately there is a small and beautiful language named CoffeeScript, which provides a higher level abstraction over javascript, implementing all good parts. See here: CoffeeScript
To learn Javascript, you need to run some programs. You can find one already installed with your browser or you can install something like Firebug in your browser. Recommended is to use node.js
Hope it helps.

Your question is not dumb. Relax :-)

There’s nothing special about JavaScript, which is a dynamic scripting language like Ruby, Python, PHP or Lua, just to name a few. For many years it was one of the most despised languages in the world, and just as slow (or more) than Ruby.

It’s just that for political reasons, it became the only language supported natively by all the major browsers, so whether you liked it or not, you had to learn it if you were into web development.

Its situation changed dramatically when Google created the V8 JavaScript engine. They hired Lars bak, the creator of the Java HotSpot VM, which is a state of the art virtual machine for the Java language. With V8, the speed and performance of Javascript increased dramatically, approaching in some cases those of statically compiled languages. But there is a lot of investment, talent and man hours behind V8, and it’s not something easily replicated by open source contributors for other languages.

Anyway, there are some rather successful projects out there that employ similar techniques. For example PYPY, which is a just in time python engine, which runs up to 7.5 times faster than regular Python. Unfortuntely, it doesn’t support C extensions very well, and that’s the reason it didn’t replace regular Python so far.

Another successful project, that’s older than V*, is LuaJit, a just-in-time engine for Lua. It’s very, very fast. But Lua is a much simpler language than the others, so it’s easier to speed up. Although that doesn’t diminish a bit the talent of its creator, Mike Pall.

So in theory, and provided there’s the talent, time, money and commitment to do it, Ruby could be as fast as JavaScript.

GOOD NEWS:

There’s already a language that borrows much of Ruby’s features and syntax, and that runs at Javascript’s speed: CoffeeScript. Coffeescript is actually an alternative syntax for Javascript. It’s a transpiler (a trans-compiler) that translates Coffee’s code to plain old Javascript so, in the end, it runs as fast as its compilation target language. Check it out.

HTML - Hypertext Markup Language.

CSS - Cascading Stylesheet.

JS - JavaScript.

RoR - Ruby on Rails.

HTML is like blueprints: this how you know what will be laid out, how, and in what order.

CSS is the language for styling the HTML elements. It's how you fan make 3 columns with blue backgrounds and centered text.

JS is a client- and server-side programming language. It is how dynamic events take place in the web browser. It is also the language for the increasingly popular server runtime environment called Nodejs, which is what allows for server-side programming in JavaScript.

RoR is a framework for the server-side programming language called Ruby.

You should pick one language and stick with it until you know the basics.
As a learner you will have enough to deal with.
JavaScript and Ruby has different purposes, syntaxes, functions and classes making it complex to learn.

What language is pretty much up to you.
You're not necessarily limited to those two languages since many languages can be used for web development, including Java, Perl, PHP, and Python.
As with Ruby they will need a little preparations; buying hosting or setting up your own web server.

With JavaScript you could start with a text editor and a browser. But even though JavaScript is easier to begin with, you will find it limited
to code at the client side. JavaScript can be also used on server side by installing node.js or similar platforms.

Ruby vs Python
Ruby is famous for being a fast way to become productive on the web with the Ruby on Rails framework. But Python has it own frameworks for the web, including Django that many consider as useful.

Do you always need JavaScript?
There are frameworks for the server side language that will do most or all of the things that you need JavaScript for by generating that code for you. One example is Remote Application Platform (RAP), but there are many others. Knowing some JavaScript will however be helpful in edge cases.

EDIT: A lot of what I’ve said here has been fixed by ES6 and the overall JavaScript community. At this rate, I’d say it’s safer to learn JS over Ruby. However for posterity purposes…

No no no. Do not learn JavaScript first. JS is my first love, and my strongest language, but I'll be the first to admit that it has it's questionable pitfalls.

Please trust me on this. Learn Ruby first.

Ruby let's you think about the problem at hand, and not about JS shenanigans.

Ruby has convenience methods, like each and select (libraries like underscore and lo-dash will hook you up with these eventually, but don't get caught up in that right now), which help you accomplish simple concepts that allow you to focus on the programming problem at hand.

Ruby has a glorious REPL, built into every Mac.

Ruby is the language of the most easily accessible REST framework around, Rails. If you really want to be a full stack dev, starting with Rails is a great idea.

JS might be more modular at this point, as you can realistically write it server and client side these days, but Ruby will make your learning process a ton more fun, guaranteed.

Good luck out there.

The main reason to learn Ruby is if you are working in a context where Ruby is required. It is a comparatively little-known language (fewer than 7% of programmers use it), so if you can find a client who needs it, you’ll be very popular. I myself was once offered a job merely because I was willing to learn Ruby on the job.

Beyond that, here are some other reasons:

• Ruby is fun
• Ruby is powerful
• Ruby has a consistent design
• Ruby is easy to learn

Also, Ruby is often paired with a framework called “Ruby on Rails” that makes it trivially easy to build programs that follow a certain well-known and useful pattern (model-view-controller). Once you learn this, your programs will almost write themselves!

As a beginner, it depends upon your capacity for learning, but overall no, it's not smart to be learning two languages at the same time.

The one thing going for you is that JavaScript and Ruby share some similarities (similar syntax, built-in arrays and maps, both can be object oriented and functional) but that's about it.

I would stick with learning just Ruby first. Then I assume you'll want to learn Rails for developing Web apps.

For JavaScript on the front end, just learn enough to use frameworks such as JQuery and you should be good. If you really want to learn JavaScript to the point where you can write your own front-end libraries then you can do so but personally, I don't see the point.

And, yes, you're wrong about Python. I don't use it myself but I'm fully aware that Python+Django is more than equally capable of rapidly building Web sites as Ruby+Rails can.

JavaScript was developed by Netscape and Mozilla, and was originally called LiveScript. It was designed as a language for embedding live behaviors into HTML-based web pages by getting access to page elements and changing their values. It's a dynamically typed language that was originally suitable mostly to being programmable "glue" for sticking together and manipulating stuff that is really implemented in some other language that was more powerful and a lot faster.

Java was created by Sun Microsystems, now Oracle, at essentially the same time (both JavaScript and Java date to 1995), for the purpose of writing complete server and graphical applications, and for writing utilities. It was designed to be easily networked, to be operating system neutral, and to be powerful enough to write just about anything. It is also a strongly typed language roughly in the tradition of C, C++, and similar languages like Pascal and Modula-2, and has a nice clean class model that is much simpler than the model in C++. It lacks C and C++'s low level access to OS primitives and memory but is otherwise quite powerful and capable.

At some point, Sun started pushing the idea of running Java in browsers similarly to how LiveScript runs in browsers, but with what was at the time much richer graphics and animation capabilities, though lesser HTML integration.

For some reason that I still don't quite get, Netscape responded by renaming LiveScript to JavaScript. I guess the idea was to confuse the market into using its awkward and mildly ugly LiveScript language rather than the much cooler Java language.

There, that's the similarity between Java and JavaScript. They can both run in browsers, extending the raw capabilities of HTML, they are both computer languages, they were both invented at about the same time, and they both begin with the letters J, A, V, and A.

It's also true that they are both object oriented languages, but there aren't many modern languages that don't do objects, so that's not that meaningful, and they do objects fairly differently.

JavaScript has always had better browser integration, so if you are making live web pages using browser side coding, write JavaScript.

JavaScript has since been optimized to a remarkable degree, so it isn't such a terrible server side language, though for large projects you are almost certainly better off writing Java. You really want compile time type checking for large projects, and Java has quite a rich set of server-side tool libraries.

It would be easier to describe their similarities. Java is a compiled, statically and strongly typed language with runtime linking targeting the JRE. JavaScript is a weakly typed language normally interpreted (with some JIT compilation for optimization) and normally running in a web browser and until recently had no way to directly include/import additional files.

Java is a very object oriented language based on class inheritance. All code and variables are part of an object. JavaScript is much less so. It uses prototypal inheritance, though there is some class-like syntactic sugar in modern versions of JavaScript. It is quite possible to program JavaScript like any non-object oriented, procedural language. JavaScript is also much more enthusiastic about casting from one type to another without the programmer asking for this, which leads to some odd and unexpected behaviors when you accidentally mix numerical values with string values as opposed to throwing an error.

Java has a very large defined runtime including support libraries/objects. The JavaScript language itself has few defined support functions. This is part of the reason the NPM eccosystem is so full of modules that are basically a single function, because these functions would be part of the standard support objects in the Java world.

JavaScript can (but won’t always depending on how they’re declared) hoist variables outside of the block that they’re defined in. In addition, JavaScript is happy to reference undeclared variables, assuming them to be properties on the global object.

They do both have syntax rather strongly based on C style syntax, and I’d actually say that most of the similarities between the two languages lie here.

• In DOM Tree each HTML element is called node.
• Object means properties with values.
• For example,

• This is Polacode extension from VSCode.

I feel like I can finally answer a Quora question!

I have been learning JavaScript for about a year and I am now in a boot camp learning ruby. Javascript, in terms of the language as it is used today is harder. There are more gotchas. (hoisting, this, use of the semicolon)There are more use cases and edge cases. Ruby is built to make us “happy”, javascript was not. ;)

For a complete beginner javascript is easy to dive into. Use the console or jsfiddle or any of the other tools and just start learning.

Ruby does take some understanding of the command line and a bit more understanding of how your computer works.

So ease of getting started goes to javaScript but...

Once you begin to learn the languages, oh ruby feels nice! There are a ton of pre-made methods for your convenience that javascript doesn’t have. Iterating over an array or hash(object in js) is easy.each{|a| a.upcase} !

Ruby is full-blown Object Oriented Programming.

Javascript is prototypal and functional… and um everything is an object… and also it’s not OOP but it also is. :/ There are also several "fixes" to javaScript that seem to be intended to make it more like other "better" languages. Many javaScript diehards would prefer it be left alone and people respect the prototypal paradigm that makes it unique, many others use TypeScript/babel because they can't live without classes. Don't think that javaScript isn’t awesome though. I think it gets a bad rap from people who don’t know it very well, but ruby is far more straightforward.

Edit:

I didn’t provide an answer about the importance of each language in web dev:

I would say JS is vastly more important to web dev. You may even NEED to know javaScript(typeScript, coffeeScript, elm, jQuery, etc.) to do web development. You most certainly do not NEED to know ruby.

If your friend can program in some other language already, it really doesn't matter if he starts with Ruby or JavaScript first. Note the key words here are 'start' and 'first'. If he can already code and understands how to write a piece of software, in particular to the web, he can and should pick up both of them. However they are quite different syntax and concept wise so the learning curve of each depends on what he knows already, and the learning curve for both in general depends on how well he knows 'programming' in general. The underlying concepts of writing code are the same across all languages and you can find a common base even across languages that are polar opposite in their philosophy. Ultimately your goal in this game is to break down big problems into smaller ones using abstractions.

If he knows nothing or is at a lower level, I'd suggest starting with Ruby as its syntax is easier on the eyes. Another idea is that Mr. Friend should pick a first project and then choose the language based on the project's needs. He'll likely to end up using both.

I think Ruby is easier to learn.

The reason why, is I think the language has a lot of good conventions that make it easier to remember.

For example:

• member functions that return True/False end in a ?
• x.nil? means “is x nil?”
• member functions that destructively change their object
• y = x.sort! means x will be now sorted. x and y point to the same object.
• y = x.sort means a copy of x is stored and will be stored in y. x and y are distinct objects

Also you can dynamically query an object to find stuff about it.

• myObject.class - returns the class
• myObject.methods - returns the methods (member functions) that myObject knows about.

Here is my thought, but this can't be same with others expertise and experience, but from my opinion I am answering your question, if you like this, then don't forget to share with your friend :

Pros of Ruby:

1. Elegant Syntax: Ruby is known for its clean and elegant syntax, which makes it easy to read and write. This promotes developer productivity and code maintainability.

2. Rich Ecosystem: Ruby has a robust ecosystem of gems and libraries that simplify many development tasks. This saves time and effort in building various functionalities.

3. Strong Community: Ruby has a passionate and supportive community of developers. This means you can find help, tutorials, and resources easily.

4. Rails Framework: Ruby on Rails, a popular web framework, is known for its rapid development capabilities, making it a go-to choice for building web applications. There are some top websites those are running with Ruby on rails web framework, like: Spotify, Hulu, Fiverr, AirBnb, GitHub etc.

5. Object-Oriented: Ruby is a pure object-oriented language, which means everything in Ruby is an object. This simplifies code structure and promotes a consistent approach to programming.

Cons of Ruby:

1. Performance: Ruby can be slower compared to some other languages like JavaScript. This can be a drawback for applications requiring high performance.

2. Concurrency: Ruby's Global Interpreter Lock (GIL) can hinder concurrency, making it less suitable for CPU-bound tasks.

3. Limited Mobile Development: While Ruby can be used for mobile app development (e.g., RubyMotion), it's not as common as other languages like JavaScript for this purpose.

Pros of JavaScript:

1.Ubiquity: JavaScript is the primary language for web development, making it essential for front-end and back-end development with Node.js. This ubiquity ensures wide adoption and support.

2. Performance: JavaScript engines have improved significantly in recent years, providing competitive performance for web applications.

3. Versatility: JavaScript can be used for web development, mobile app development (React Native), desktop applications (Electron), and even server-side development (Node.js).

4. Large Community: JavaScript has a vast and active community, resulting in extensive documentation, libraries, and frameworks like React, Angular, and Vue.js.

Cons of JavaScript:

1. Inconsistencies: JavaScript has quirks and inconsistencies, which can lead to unexpected behavior if not handled carefully.

2. Callback Hell: In asynchronous code, JavaScript can suffer from callback hell, making code harder to read and maintain. However, modern JavaScript has addressed this with async/await.

3. Security Risks: Client-side JavaScript can be vulnerable to security threats like Cross-Site Scripting (XSS) if not properly secured.

Remember to discuss this with others person before shifting your jobs, based on my expertise and the knowledge I have shared this answer. Thanks for looking.

Basics

Functions in JavaScript are first class citizens: they can be assigned to variables and can be freely moved around:

var printer = function() { 
  console.log(‘it works!’); 
} 
 
var delegator = function(func) { 
  func(); 
}; 
 
# prints "it works!" 
delegator(printer); 

The same is true for when a function is not assigned to a variable. It can still be referenced the same way as if it was a variable:

function printer() { 
  console.log(‘it works!’); 
} 
 
var delegator = function(func) { 
  func(); 
}; 
 
# prints "it works!" 
delegator(printer); 

In Ruby, blocks are not first class citizens - they are special language constructs which are meant to complement the functionality of regular methods. They are not objects (unlike most Ruby constructs), so they can’t be moved around or be referenced outside of their owner methods, and they don’t respond to any methods of their own.

Every method in the Ruby language is able to receive an implicit block. Unfortunately, not much can be done with the block except for calling it before it falls out of scope.

def delegator 
  # runs the block 
  puts yield.class 
 
  # also runs the block 
  yield 
end 
 
# prints "String" and "it works!" 
delegator do 
  puts 'it works!' 
 
  'a string' 
end 

Here you can see that the yield keyword calls out the block, which falls out of scope after delegator runs.

Blocks are intrinsically coupled to methods, but this is part of why Ruby is so unique. We can probably say that each method owns its block. Note that blocks can easily be converted into procs or lambdas in order to have a similar flexibility as that of JS functions.

Lexical scope

JavaScript functions are able to access variables from the outer scope. Any variables around at definition time (that is, run time) can be accessed.

var a = 'a'; 
 
function callbackProvider() { 
  var b = 'b'; 
 
  return function callback() { 
    var c = 'c'; 
 
    console.log(a, b, c); 
  } 
} 
 
var callback = callbackProvider(); 
 
# prints a, b, c 
callback(); 

Scope access is outward-oriented, thus inward variables are never visible. For instance, callbackProvider is not able to access the c variable, which is defined inside the nested callback function — but it’s able to access a and b.

Ruby blocks have similar lexical scope rules, in the sense that they hold a reference to the outer scope.

a = 'a' 
 
def delegator 
  yield 
end 
 
# prints "a" 
delegator do 
  puts a 
end 

Similarly to JavaScript, variables defined from within blocks are not accessible to the outside:

run_me do 
  b = 'b' 
end 
 
puts b # fails 

We can conclude that a block created from within a method shares the same scope as the method plus a scope of its own. The same applies for when the block is contained by other language constructs such as classes.

c = 'c' 
 
def other_method 
  d = 'd' 
 
  yield 
end 
 
def my_method 
  a = 'a' 
   
  other_method do 
    puts a 
 
    # neither of these variables exist here 
    puts c 
    puts d 
  end 
end 
 
# prints a and fails 
my_method 

Our block is not able to access d, neither can it access the outer c variable because of method scope rules. It can only access the same that's available to my_method.

Arity

Neither blocks nor functions have strict arity requirements, so they accept any number of arguments (including no arguments).

function myFunction(arg1) { 
  console.log(arg1, arguments); 
} 
 
# prints 3 and { '0': 3, '1': 4 } 
myFunction(3, 4); 

In this JavaScript example we called myFunction with two arguments, but myFunction only has one argument in its arg list.

Nevertheless, we can still access the arguments by means of the special arguments object.

This is bad for JavaScript because function is the only construct provided by the language to hold and execute code. We must manually check the arguments should we want to ensure arity in JavaScript functions.

Ruby blocks share the same dynamic essence as JavaScript functions:

def delegator 
  yield 'a' 
end 
 
delegator do |var1, var2| 
  puts var1 # prints 'a' 
  puts var2 # prints nil 
end 

Note that the delegator method calls the incoming block with one argument, even though the block lists out two arguments.

The block could even be called with three arguments, but delegator would not able to access the third one. Unlike in JavaScript, we don’t have a way to access all arguments unless we explicitly allow the block to do so:

def delegator 
  yield ‘a’, ‘b’, ‘c’ 
end 
 
delegator do |*args| 
  # prints a, b, c 
  puts args 
end 

Here we are using a splat (language construct) as the first argument in order to catch all arguments.

Shadowing

A variable can be shadowed in JS functions and in Ruby Blocks as well. If you define a variable in a block or function and an outer variable with the same name exists, the block or function won’t be able to be access or modify it.

The shadowed variable takes precedence over the outer one inside the block or function, and the outer one is preserved intact.

Conclusion

JavaScript functions and Ruby blocks are very similar. The main difference between them regards flexibility — as the former is a first class citizen and can be used in many more ways. Fortunately, Ruby offers procs and lambdas to overcome this fundamental limitation, which we will not discuss about here.

Couple of points.

1. Javascript can be used not only for client side but also as a server side programming language but currently mainly used for client side operations.

If you want a complete javascript stack for application look at something like
SocketStream: http://www.socketstream.org/

2. Learning curve

Javascript - It depends on what you are trying to do with
- do you need to use it more for client side operations, then learning the basics and using any of Javascript library like Jquery, ExtJS, Prototype etc is easy. You do not need to worry of handling cross browser compatibility issue.

- Debugging javascript is harder compared to ruby.

Ruby - It might look simple from outside but it is like a swiss knife.
It is really strong in terms of meta-programming, too dynamic and supports multiple paradigms like it is imperative, functional and object oriented.
The complexity increases depending on the use of different features of the language, the more dynamic code : more complexity.

From my perspective Ruby is more complex than Javascript.

3. Importance in web-development:

Both have their own use and advantage depending on the application.

Javascript
If you need a simple application which has lot of user operation on the client side then the entire application can be built using complete JS stack.Other general uses

- Interactive UI
- Form/data validation
- Creating funky/cool UI

Security and Cross browser compatibility are some of its drawbacks

Ruby
If the application is much more than that then using different frameworks, like Sinatra, Rails etc involves using ruby. For using any of these frameworks you do not actually need to learn ruby to the core but i feel learning and understanding the basic concepts, strength & weakness of a language is really important.
There are many web frameworks around which uses ruby as core ROR, Merb etc.

The importance of ruby is more on server side and javascript on client side.

OO is a style of programming, not just a language construct

At it's core, object-oriented programming is about representing related bits of data and functionality into named chunks called objects, and then writing your code in such a way that it's easy for humans to interact with it. It's a way of organizing your code so that future developers can make sense of things easily, and hence it keeps the cost of development low.

Certain programming languages such as Ruby, Java and JavaScript have language constructs that make it possible for you to write code in an object-oriented fashion, some more easily than others. Other languages, like Haskell make it more difficult to write (and in some cases impossible) to write code in an OO fashion.

So you can write functional-style programs in both languages, or OO-style programs in both languages.

Objects and methods

To start, Ruby and JavaScript both share the concept of there being Objects, and being able to call methods on those objects. Syntactically both use the dot notation (`object.method`) to call methods on objects, so it might seem like they are more similar than they actually are.

In Ruby methods truly do belong to objects, and can only be called on those objects. In JavaScript "methods" are really just short-hand for looking up the correct function to call, and passing in the object as `this`. So the following two calls are identical in JavaScript:

var person = { 
 fullName: function(){ 
  return [this.firstName, this.lastName].join(' '); 
}; 
} 
 
person.fullName(); // is the same as... 
person.fullName.call(person); 

So in Ruby you have to invoke a method on an object. In JavaScript you just have functions, and if you call a function on an object it will afford you some benefits.

Inheritance

Inheritance deals, in part, with method lookup. Ruby and JavaScript both have built-in support for calling methods up-the-chain, so to speak, but they implement it very differently.

Take the following Ruby:

class Person 
  attr_reader :first_name, :last_name 
  def initialize(first_name, last_name) 
    @first_name = first_name 
    @last_name = last_name 
  end 
 
  def full_name 
    "#{first_name} #{last_name}" 
  end 
end 
 
Person.new('Jeff', 'Dean').full_name 

When you call the `full_name` method on your new Person instance, it looks at itself, at Person and then at any class Person inherits from (in this case Object, Kernel, BasicObject etc...). This is what you'd call an "is-a" relationship - your object is a Person. The `full_name` function can only be called on a person, or another object that's a subclass of Person.

In JavaScript, a reasonable approximation of this would be:

var Person = function(firstName, lastName) { 
  this.firstName = firstName; 
  this.lastName = lastName; 
}; 
 
Person.prototype.fullName = function(){ 
  return [this.firstName, this.lastName].join(' '); 
}; 
 
new Person('Jeff', 'Dean') 

But rather than creating an "is-a" relationships, when you use the `new` keyword, it effectively does this:

var person = {} // plain old javascript object 
Person.call(person, 'Jeff', 'Dean') // call the Person function, passing in our new object as `this` 
person.prototype = Person // (pseudo-code) - point our `person` object to another Object where functions might be defined 
return person; 

Note that what comes out of `new Person()` is just a plain old JavaScript object - but it has one special property set - the `prototype` property. So when you call `person.fullName()` it looks at itself first, then goes to its prototype, then its prototype's prototype etc... JavaScript uses prototypes to find the right function to call, then it uses the fact that `object.foo()` is the same as `object.foo.call(object)` to make it appear as if it's doing the same thing that Ruby is doing.

So method lookup can feel similar in both languages, even though their exact details are quite different.

Super

Ruby has proper support for `super` - that is, when you override a method, you can internally call your super-class's method with the same name. JavaScript does not have a built-in concept of super, although you can create your own fairly trivially (see Invoking Super Methods in JavaScript (http://blog.salsify.com/engineering/super-methods-in-javascript)).

This is one of the biggest differences in the two.

Encapsulation

Ruby has the concept (although a bit strange) of hiding methods and instance variables. Ruby has a concept of public, protected and private methods, with the latter two being a little harder to call on objects. It also has the concept of instance variables which should, in theory, only be accessed by methods on that class. As with everything in Ruby, there are ways to get around it, but Ruby clearly supports the intent of the developer to make things hidden from the outside world.

In JavaScript there are no built-in concepts of private functions or private attributes that you can use in a declarative way (like `public :foo`), so many people think you can't encapsulate data, but it does allow you to hide data well if you know how (Private Members in JavaScript).

Polymorphism

Both Ruby and JavaScript have types, but don't enforce them. For example you can't make either language enforce that you pass a string to a method. So in both languages you can rely on duck-typing - basically writing methods such that if an object has the right methods / properties your code will work ("if it walks like a duck and quacks like a duck"...)

This makes polymorphism super easy, and you won't notice much of a change for most parts of your program if you are actually using polymorphism well. However, Ruby allows you to ask an object for its type (`person.is_a?(Person)`) whereas JavaScript's typeof will always return "object" for your "instances". So if you rely heavily on that kind of asking you'll have to hand-roll it in JavaScript.

Just as the question is posed, it is difficult for the person who asked it to understand the answer.

1. They are all programming languages, (all).
2. Only C ++ is compiled into machine language (binary)
3. Java and Python are converted to intermediate code before running
4. Less C ++, the others have JITs
5. Python and Ruby are also considered scripting languages.
6. I have not found references to PHP being a scripting language (although by the definition of a scripting language, it could be).

In general, a scripting language is one that allows making small programs (generally of the imperative type) that are executed with an interpreter. In that case, the only one that wouldn't be scripting is Java (I didn't find any indications that this is the case).

The simplicity of a program could be based (incomplete) to determine if a language is scripting.

Example a program to write Hello World!

C++

#include <iostream> 
using namespace std; 
int main() { 
	std::cout << "Hello World!"; 
 	return 0; 
} 

Java

public class Program { 
	public static void main(String[] args) { 
	System.out.println("Hello World!"); 
	} 
}