JavaScript has come a long way from a hacked-together language built under time constraints for a new medium. Since its creation, the language has undergone trials and tribulations at the hands of vendors fighting over implementation.

Today, however, JavaScript is the beneficiary of some of the best computer science engineering on the planet. Google, Apple, Microsoft and Mozilla have poured billions of dollars’ worth of development into the construction of modern JavaScript engines, and as a result, the language runs quickly and reliably in all major browsers.

(Related: An in-depth look at what’s coming for JavaScript)

Geoff Schmidt is CEO and co-creator of the Meteor Framework, a JavaScript framework for building modern applications that can run on any screen. Schmidt was one of the inventors of audio fingerprinting and raised his first venture capital round at age 20. He was one of the original authors of Miro, the decentralized Internet TV platform that today has about 2 million active users. In 2007, he founded MixApp, which allowed people all over the world to listen to music simultaneously over a real-time peer-to-peer network.

In 2010, Schmidt was employee No. 9 at Asana, where he worked on the Luna application platform. He is the proprietor of Monument, a 24-unit live work community for scientists and artists, currently being built in a converted warehouse in San Francisco. As a teenager, he won the overall prize at a world science fair, was invited to the Nobel prize ceremony, and attended MIT for almost four months.

We caught up with Schmidt to discuss the past, present and future of JavaScript.

Do you think JavaScript should be more important to enterprises?
We’re very interested in how we get JavaScript further into the enterprise. If you’re a small startup, it’s pretty simple: You have a great time, it’s much less complicated. But most software is written in the enterprise context, where it involves the collaboration of a lot more people.

I think the easiest way to understand the role for JavaScript in that environment is to understand what we’re solving for. We’re solving for what the team structure is, as well as for the technology constraints.

Call them microservices, or existing services that serve as a source of truth. Each of those is going to end up being maintained by a different team, or a combination of teams. Some can be written in JavaScript. A lot of those services already exist in a wide variety of languages. How do you take all those services that exist and bundle them up into something useable by a human?

That’s the place where JavaScript plays a really special role. It’s something really special what people are typically trying to do. They’ve got some combination of back-end services, and they have to build an application on top of them. You want to have it run on desktops, iOS and Android, and you want the application have a modern-feeling user interface.

The team that is building that application is going to build the secure components of the application that needs to run, and write the client pieces. You can do all that in JavaScript. It makes sense to give that responsibility all to one team.

Event brokers seem popular in JavaScript right now, thanks to Node.js and the event-driven programming model. Is this compelling to enterprises?
I think the use case for JavaScript is continuing to grow in the enterprise. The reason JavaScript is so great for building event brokers is that it’s a high-productivity way to build event brokering and logic. There’s always going to be some use cases where you need a statically typed language with more volumes. There will be times when you’re just going to need Go, or C++, but the thing that’s driving the applicability of these situations where there are higher and higher volumes of events to process is that enormous investments have been made in the JavaScript runtime.

There’s this arms race to build the best browser. What people want in a browser is for it to be fast and stable. That means a great JavaScript engine, and that’s driven this incredible investment to make the best dynamic garbage collector we’ve ever had.

What do you think of how JavaScript is evolving? What of ECMAScript 2015?
ECMAScript 2015 is the best version we’ve ever had. It’s kind of interesting to ask the question of how does this scripting language, put together on a tight deadline at Netscape, attracts so many users. It comes down to something simple: It just got embedded in the Web.

The first versions of JavaScript weren’t that good, but people realized we were stuck with it. It turned out the opportunity didn’t exist to get Ruby or Python in the browser. And Java in the browser had problems.

It took a while for the necessary industry coalitions to develop to improve the language, but now we have a good functioning standards process where Google, Apple, Microsoft and Mozilla all understand they want to improve JavaScript.

ECMAScript 2015 is really great because it answers a lot of those concerns people coming from other language backgrounds have. Things like variable scoping. ECMAScript 2015 introduces a new keyword that has scoping. Starting with 2015, all of our JavaScript still works, but if you declare variables the new way, you get the new behavior, and it does what you’d expect.

JavaScript historically uses a version of object-oriented programming, but one that is different. JavaScript uses a protypal model instead of classes. The lines you need to type to have one line inherit from another were a little cryptic. In ECMAScript 2015, we have normal keywords like “class” and “inherit,” so anyone from an object-oriented background will see what they expect.