Presentation: npm and the Future of JavaScript

I'll talk more about server-side stuff, and I’ll emphasize Node. We've found that the security message is important to people, so there will be quite a bit there. There's been this huge shift in how JavaScript is used and enterprises are only just beginning to catch up to that. There are many people working on JavaScript, and they're not just throwing script tags into web pages. They are writing huge chunks of very valuable IP for you.

There's all of these other languages (Java, Python, and C). They have institutional knowledge about how to manage this stuff, how to grow people in their jobs, how to manage large projects, and that stuff is only being haphazardly (or not at all) applied to the JavaScript space. So one of the messages that we're trying to get across is this is actually a huge chunk of what you do now. Your website may contain thousands and thousands of open source modules that you're not paying attention to. You don't know what's in them, and you spend all of this time training your developers to write secure code but 97% of the code in your website is coming from our servers and you should really be looking at that as well.

It's a talk that I've stopped giving at JavaScript-focused conferences because it's mostly landed now, but at an enterprise, heavy-Java background conference like this, I would probably step back a couple of years in terms of the focus of the talk. You should be taking JavaScript seriously because it's a huge part of your budget.

Also, I'm trying to give predictions about what you should be doing in 2019. People generally find that pretty useful.

Yes, that's one of them, transpilation and stuff like that. Transpilation is basically the userland showing the standards bodies where to go.

My favorite example is Backbone versus jQuery. Backbone is a framework that lived and died, and other frameworks came to replace it. jQuery didn't die. jQuery transcended. The API that jQuery invented became part of the browser. Nobody ever stopped using jQuery, they just stopped using the library that provided it, and now all browsers provide CSS selectors for DOM manipulation which was jQuery’s primary invention.

So there's a bunch of stuff we're doing where the browser manufactures and Node are being shown what it is that users actually want. For example, if 42% of people are using types, then JavaScript should be considering types. If 60% of web developers are using the React model to build component based websites then, even though Web Components exist that means:

• web components are not going to work (otherwise, we'd be using them)
• some kind of native component model is going to be necessary

The failure of Web Components does not mean that people don't like components it means they don't like these Web Components. These are things that we can see at the package manager level.