JavaScript and Java confuse many new programmers. They sound so similar, so one might think they have the same use-cases, or perhaps the same company created both languages. Neither of those hypotheses is true! Let’s go over the differences and history in this quick read.
Java – Brief History
Java was created in 1991 by James Gosling of Sun Microsystems. Sun Microsystems wrote software for many different devices, and re-compiling or restructuring code to run on various CPU architectures became time-consuming.
Fun Fact: The founding team had a hard time thinking of a good name for their project, and while out for coffee, decided to name the language after their coffee.
Cross-Platform (JVM)
Java is a general-purpose programming language that allows developers to run code on any device. Code is compiled into Java-specific byte code, then the Java Virtual Machine (JVM) converts that byte code into machine compatible code. When code is compiled in this way, Java becomes completely cross-platform, which is a major contributing factor to Java’s success.
Object-Oriented Design
Java rose quickly to fame and adoption mostly due to its cross-platform nature and object-oriented programming (OOP) pattern. OOP was and remains popular due to the ability to reuse code and think about entities within a program as hierarchies of types. Java is a king of the OOP design pattern, and requires that everything in the program be a class, even the main function!
OOP was so popular in the 90s and early 2000s that it became (in my opinion) ubiquitous. These days it has more appropriately found its niche, but when JavaScript was first coming into existence OOP was the name of the game.
JavaScript – Brief History
In 1995, 4 years after Java got its start, JavaScript was created by Brendan Eich while he worked for Netscape. At the time, Netscape had complete market control of the web browsing industry, and Microsoft was just starting with the Internet Explorer project.
In an attempt to beat Microsoft, Netscape partnered with Sun Micro systems and branded JavaScript with the name it has in order to latch onto the Java hype train that was plowing ahead in the developer community.
JavaScript’s Success
JavaScript started as a small scripting language to perform actions on the client-side within the browser. Development was rushed and interesting design choices were made, including:
Optional semi-colon line endings
Objects and classes but with limited encapsulation
Single-threaded (Callback based, no concurrency)
However, JavaScript was positioned uniquely which would contribute to it becoming the most used programming language today. The following points attributed to its widespread success:
The “JavaScript” naming ploy to steal marketing hype
Not seen as competition because web development was “not serious development”
Monopolizing browser programming, again, because other projects didn’t see browser scripting as a serious programming
Many developers considered “front-end” development to be for artists and designers. After all, “it’s just styling and tempting, right?”
This was the case for a long time, but in the last decade, front-end development has become just as serious as back-end development. Single page apps, and frameworks like Angular, React, and Vue, have pushed logic that used to be controlled by the back-end directly into the user’s browser.
Runtimes, Speed, and Benchmarks
Most compiled languages like C, C++, and Go compile code directly into machine instructions. Those instructions are specific to a CPU architecture and operating system. Neither Java nor JavaScript are typically compiled in this way.
Java and JavaScript operate in distinct ways. For this comparison, we will assume Java is compiled to JVM bytecode, and JavaScript is being run in a NodeJS interpreter.
Note: Java can be compiled to native code, or run via an interpreter, and JavaScript can run outside a browser via Node, but we will stick to these speicifc use cases for now.
Java Virtual Machine (JVM)
The JVM compiles code (.java files), into compiled classes (.class files). These class files make up a complete compiled Java program, with the requirement that one of the class files has a “main” function as an entry point. Class files are typically archived and distributed together in a .jar file, which makes it easier for users to download a single executable file.
The JVM runs faster than interpreted languages like JavaScipt because code is compiled to machine code before runtime. The JVM is slower than most natively compiled languages because it misses out on architecture-specific optimizations, and still has to do JVM –> CPU conversions at runtime.
NodeJS – V8 Engine
JavaScript is an interpreted language that has many different interpreter implementations. One of the most common ways for JavaScript to run in production is by using the NodeJS interpreter. Node uses Chrome’s V8 engine to interpret and run JavaScript.
As you can see in the following benchmarks, Java fairly consistently performs better than Node in regards to memory and CPU:
What really slows JavaScript down is that it is interpreting code at runtime. At roughly each line of execution, the interpreter has to convert the JavaScript into machine code, a very slow process to be doing at runtime.
Classes and OOP
In Java, everything is a class, and OOP is enforced in a fascistic manner.
In JavaScript, classes are optional, and functional programming is possible and even encouraged lately. JavaScript has most of the OOP paradigms available in the language, but encapsulation is not as robust as it is with Java.
Threading and Concurrency
JavaScript is single-threaded, which means that it will never execute code at the same time. Concurrent programming is a feature of most languages, and JavaScript is fairly unique in not being able to accomplish the task.
The way JavaScript makes up for being single-threaded is by use of asynchronous programming and the event-loop. Whenever an API Call or some other long-running process needs to happen without blocking the execution of the rest of the program, the event-loop is responsible for doing the waiting. When the asynchronous task completes, the main thread is able to detect the results of the task.
Comments