11 reasons the new JavaScript isn’t like the old JavaScript

In 1995, a small group of programmers with big dreams launched JavaScript. It was going to be called Mocha or LiveScript, but then some savvy folks decided to jump on the Java-language bandwagon, which was already building a big head of steam.

The initial goals for the new scripting language were simple: Add a bit of life to static web pages (in those days, the only motion on a web page came from the <blink> tag—which is long gone but not forgotten). At the time, JavaScript’s developers probably never dreamed that a tiny layer designed to double-check form elements would someday be the dominant way software is distributed.

The current version of JavaScript bears little resemblance to that first-generation scripting language. While much of the old code still runs in websites, innumerable features and layers have been added since the early days. The roles and responsibilities associated with JavaScript are also much broader. Thanks to Node.js, the language isn’t just for web pages; it is a big part of many server-side stacks, running code that has nothing to do with <blink> tags or cat memes. Cryptocurrency applications, healthcare, and stock-trading bots are just a few of the jobs that depend on JavaScript.

With JavaScript’s 30th anniversary on the horizon, now seems like a good time to take stock of how much the language has changed. Here are 11 ways the JavaScript we use today is completely different from the language its inventors and early adopters could have imagined.

11 ways JavaScript is not what it used to be

1. It’s not called JavaScript anymore
2. It’s so massive that developers have to specialize
3. It’s all about the frameworks
4. It’s isomorphic
5. Many new operators
6. JSON is everywhere
7. Builds and build tools
8. JIT compilation
9. Type safety
10. The vast library ecosystem
11. Other languages cross-compile to JavaScript

It’s not called JavaScript anymore

In the beginning, everyone called it JavaScript. Today, most developers still use that name. Officially, though, the people who create standards use the name ECMAScript. Some even spell out the official version number of the normative language specification, which goes up to 14. ECMAScript may not roll off the tongue or conjure memories of warm coffee, but it successfully differentiates JavaScript from Java. That way, JavaScript’s developers don’t have to worry about Java trademarks, logos, or any other form of trade dress. Well, except for the fact that ECMA International, the keepers of the specification, like to put that little registered trademark symbol next to the name: ECMAScript®.

It’s so massive that developers have to specialize

JavaScript today is so immense that it’s impossible for anyone, even developers who use it every day, to know every part of it. The arrival of server-side options and isomorphic code attracted so much new energy and development that one person can hardly know all the idiosyncrasies of writing code for the browser or the server—let alone both. Developers are forced to specialize in one of these two areas, even though they could, in theory, write code that runs across them. It’s pretty common for developers to spell out that they work on browser-based JavaScript frameworks, server-side JavaScript, or even database-side JavaScript. Hey, it’s a big world out there.

It’s all about the frameworks

The split between the server and browser worlds is one thing, but JavaScript developers also tend to narrow their specialization by framework. Many job advertisements don’t ask for “JavaScript” programmers per se. They look for React or Angular, or any of a dozen other popular JavaScript frameworks. It’s a practical decision. Programmers need to be well-versed in the idiosyncrasies of these frameworks to succeed. Oh, sure, they also have to know some JavaScript basics. But if a developer doesn’t know how Angular uses HTML attributes, no amount of JavaScript expertise will help. The big frameworks like Angular and React are getting so big and complex that some programmers are specializing in smaller tools focused on subareas of JavaScript, like state-management tools (Redux, MobX) or the base model options.

It’s isomorphic

One of JavaScript’s biggest jumps in popularity came after Node.js made it possible to write JavaScript code that ran on the server. Suddenly, there was no need for one team to handle the browser software and another team to manage the server side. The same code could run in both locations isomorphically, which made it much easier for JavaScript developers to move functions from the browser to the server and back again.

But wait! Didn’t I just say the JavaScript world is bifurcating or trifurcating or worse? Yes, but the isomorphism is still valuable. Many basic functions for tasks like encryption can run identically in different realms. Sure, programmers may specialize in one niche, but code itself can often flow unfettered between all the niches.

Many new operators

The original JavaScript had a few simple features for juggling data objects. The newest versions support thoughtful additions like the spread operator (...) and map that can slice, dice, expand, and surgically alter data structures. The result is very compact code that is also very powerful. Programmers can easily ship complex data structures without writing endless routines for packing and unpacking them. The code is simpler, faster, and, if you know the new syntax, easier to read.

JSON is everywhere

In the early years, JavaScript programmers were forced to parse and serialize data to share it. Then, someone who was clever noticed that the native JavaScript object format—JavaScript Object Notation, or JSON—was both efficient and fast. JavaScript stacks could parse data stored using JSON faster than most other formats. Today, even programmers who aren’t going to write any JavaScript end up using data in the JSON format simply because it’s flexible and efficient. JSON is everywhere but feels most at home in a JavaScript environment, which will quickly parse it and turn it into an object.

Builds and build tools

In the beginning, people wrote JavaScript with a text editor and tested it in a browser. Modern JavaScript applications are a little more complex. Most need multistage build tools like Grunt, Gulp, or Webpack that stitch together various components into the final executable stack. Many developers end up using full CI/CD servers that also test the code and check for any bugs that might crash it.

JavaScript’s build tools are so powerful that developers often have a love/hate relationship with them. The code they write won’t run anywhere until it’s been analyzed and assembled into the format that will actually run. Yes, technically JavaScript is still a dynamic scripting language, but its builds sometimes take longer than the old C compilers.

JIT compilation

Today, the processing and preprocessing is happening up and down the stack. Just-in-time compilers unlocked the power of JavaScript when they first appeared, and they continue to get better. The compilers are now smart enough to repeatedly analyze the code as it’s running and improve the core parts of the algorithm that are getting the most work. They do a better job with garbage collection and prevent some of the more abusive behaviors. For a language that started as a scripting language, JavaScript’s JIT layer looks just as powerful as a language that’s officially “compiled.”

Type safety

When JavaScript began, some programmers hated the extra keystrokes needed to define the type of the data stored in each variable. Developers who still use vanilla JavaScript can live free all they like, but there’s now a substantial population that embraces TypeScript and some of the other typed options for JavaScript. These preprocessors enforce type rules along with all the belt-and-suspenders safety that comes with them.

The vast library ecosystem

It’s hard to summarize the breadth and depth of libraries that flourish in the JavaScript ecosystem today. There’s code for thousands or maybe even millions of different kinds of applications. The build files for even basic projects can import hundreds of different dependencies. JavaScript is one of the most popular languages on repositories like GitHub and GitLab, where you could spend days exploring code for just about any occasion.

Other languages cross-compile to JavaScript

One of the odder jobs for JavaScript these days is supporting code that was written in another language. There are hundreds of different languages that can be cross-compiled into JavaScript and run in either a browser or a server. The just-in-time compilers now make JavaScript a good waypoint for developers who want to get their old COBOL or their new Haskel running everywhere quickly. Sure, the people who love those languages could write their own compilers, but it’s easier to just cross-compile into JavaScript and let those tools do the optimization. As a result, many lines of code in JavaScript were written by a programmer who was thinking in an entirely different language.

Also by this author

• 8 reasons developers love Go, and 8 reasons they don’t
• 11 surprising ways developers are using Wasm
• 9 reasons SQL has got to go