(upbeat music) (audience applause) - Hello, everybody.
Oh dear, I've destroyed my slides already.
Sorry. All right.
Before we get started, it's very important that I take a speaker selfie, because if it's not on Instagram, did it even happen? Alright, that important thing out of the way. Good morning.
My name is Laurie, thank you very much to the organisers of Web Directions for inviting me to speak and thank you all for waking up what I realise is very early to hear me talk. This is my first visit to Australia and I'm liking it so far.
The coffee is as good as everyone said that it would be. (audience laughs) I helped co-found NPM Inc.
and I'm currently the Chief Data Officer there which means I basically draw graphs and stuff and count things up.
But what I am, what I identify as is a web developer. I've been a web developer for 23 years now, which means that I occasionally run into people who are younger than some of my websites.
Making the Web bigger and better and more accessible to more people is what really drives me.
And I know you were all expecting a talk about the future of JavaScript, 'cause that was on the thing, but at the last minute, I decided to throw it all away and give a talk about microfrontends.
(man laughs) Not really.
Can you even imagine? If you laughed at that joke, you spend too much time on Twitter.
What I'm really here to talk about is JavaScript. I'm going to talk about who we are.
We the people who write JavaScript.
- And as John just mentioned, who in this room considers themselves a developer, even if it's not your day to day job right now? Right, Good. Excellent.
Because I'm gonna be using the words we and us a lot. So if you weren't all considering yourselves developers that would've got awkward.
I'm gonna be talking about who we are as JavaScript developers.
I'm going to be talking about where we're writing JavaScript.
I'm going to talk about why we're doing JavaScript the way that we are right now. The forces that got us to the state that we're in. And then finally, I'm gonna talk about what comes next. I'm going to take a look at all the trends that I'm going to tell you about today and make some guesses about where this is going to go. The goal of this talk is to give you a sense of perspective about the state of JavaScript as a whole, and where your current tools and techniques sit. Because too many developers work in a vacuum. We don't know if the stuff that we are doing at the company we're at is a best practise or an outdated practise or a new fad that nobody's really doing yet because very few people have hard data.
There's an enormous amount of hype going on. But NPM has hard data.
And that is what I'm here to share with you. I hope that you'll leave this talk feeling good about one thing that you're currently using. Realising that it's time to move on from one other thing that you're using and curious about one new thing that you think it's time to learn.
But before I get into all of this stuff, it's worth asking where I have this information. I have three main sources of information.
The first is the NPM registry logs.
NPM gets two billion downloads every single day. That gives us an enormous amount of insight into what people are using and whether that stuff is getting more popular or less popular.
Second, we went out and asked people directly. We don't have to extrapolate from the downloads. We did a survey two years ago of 16,000 JavaScript developers.
And then we repeated it again last year with 33,000 JavaScript developers.
So we have an enormous amount of direct information. And then finally, I supplemented and double checked our numbers with the excellent state of JavaScript survey which is run by some independent members of the community, who luckily came up with all the same numbers that we did. So I felt a little bit better about our survey at that point.
Incidentally, this talk is focusing on JavaScript but if you are more of a CSS person or you are very interested in CSS, the same people who did the state of JavaScript survey did a state of CSS survey this year, which is full of really interesting information about what is going on in CSS land, presented with an overwhelming super fluidity of CSS transitions and animations.
I've never seen a website that went so completely overboard on animations. And before we dive in, a few quick disclaimers. Some of what I'm presenting here are facts and some of what I'm presenting here are opinions. And I'm going to try and be as clear as possible about which of those is which.
One of the things that happens nearly every time I give this talk is somebody will see a graph that shows that a technology that they are using is getting less popular, and they get very, very angry about it, and there's nothing I can do about it. The disclaimer doesn't work.
All I can say is I have a lot of terrible opinions. Please feel free to get mad about my terrible opinions, but try not to get mad about the graphs.
They're just graphs.
I do not have a horse in this race other than NPM. I'm not a contributor to any of the projects that I'm talking about.
Secondly, a lot of what I'm talking about involves relative popularity of technologies. And I wanna make clear that just because the technology is popular, that does not mean that it is the best. In fact, I don't even know what best means when it comes to a technology.
Technology lives in a multi dimensional space that depending on your constraints and your team, and where you are as a company, the best solution is going to be different for every single person. There is no single best answer.
However, I have an enormous amount of information about popularity.
So popularity is what I'm going to be talking about and popularity is useful for a technology.
If there's a lot of people using your technology then there will be a lot of tutorials about it. There will be a lot of bugs fixed, there will be a lot of Stack Overflow questions answered. It will be easier to hire people who are using that technology.
So regardless of how good a technology is, if it is popular that can make your job easier. And finally, I really, really love this stuff. And I tend to get very excited about it.
When I get excited about things, I curse like a drunken sailor.
And I have absolutely no intention of changing or modifying that behaviour in any way.
So just apologies in advance.
So who are we? The JavaScript developers? The answer is, at this point, we are pretty much like all developers.
If you look at our demographics, we have the same age distribution, the same levels of education as developers working in all other fields.
We work in every industry, in every country in the world. And part of the reason for that, is that we are rapidly expanding to be all developers. There are now 11 million JavaScript developers in the world. And those 11 million developers are using more open-source software than any language community has ever used before.
The NPM registry is the largest repository of open-source of any kind that has ever existed.
Whether you measure it by lines of code, or number of modules, or number of users, whatever it is still the biggest.
It is more than twice as big as the next biggest module repository.
Of course, everybody knows that JavaScript has a tendency to use lots and lots of small modules.
So maybe that's an unfair comparison.
What about other kinds of activity? On GitHub, JavaScript is the biggest language by number of repositories, by number of issues, by lines of code, and it has been for seven years. On Stack Overflow, they did a survey recently of 80,000 developers and JavaScript was the most popular language with 68% of all developers saying that they use it. Of course, you work in this field.
So probably by this point, you were aware that JavaScript is a fairly popular language. But here's the truth.
JavaScript is the most popular programming language in the world and there are more developers than there have ever been before.
So JavaScript is the most popular programming language that has ever existed.
As JavaScript continues to grow, the JavaScript community is changing.
One thing that we noticed between our surveys from two years ago and last year, is that JavaScript developers are getting more experienced. They've been writing JavaScript for longer. We especially noticed this with NPM itself. A year ago, half of NPM users were new by which we meant that they've been using NPM for less than two years.
And this year, only about a third of them are. Around about 2014 and 2015, there was a massive and sudden spike in the number of NPM users, as basically all the people who had been writing JavaScript before NPM was invented, sort of clued into the existence of NPM and started using it simultaneously. These days, the number of new NPM users and the number of new JavaScript users are beginning to converge on the same number. Essentially, all of the people who knew JavaScript before NPM have picked it up by this point. And all of the people who are learning JavaScript these days learn NPM at the same time.
So our current estimate is as of the end of 2019, about 99% of JavaScript developers will also be NPM users.
So that is why in the course of this talk, when I talk about NPM users, or survey respondents or JavaScript developers, I use those terms interchangeably because they pretty much are.
So this ever growing pool of increasingly experienced JavaScript developers means that we've seen a shift in what people care about.
We knew from analysing last year's data when we split people up by experience, that more experienced developers have different concerns.
They tend to be more interested in best practises. They care more about security.
They do more bundling.
They do more linting.
They use more web frameworks.
They just do more of everything.
And now that the whole JavaScript community is getting more experienced, that's becoming true of the whole JavaScript community.
Since last year's survey, the number of people concerned about the security of the open-source modules that they use has increased.
And we have done some things to address that. In the last two years NPM has introduced two-factor off to help protect package publishers from account theft so that nobody can publish malicious packages as them. And we've also built a lot of automation behind the team behind the scenes and hired a security team to detect and flag malicious packages.
But malicious packages are not really the primary threat. Much more common than malicious packages are accidentally vulnerable packages.
Packages where the vulnerability was a mistake or a bug. And the vulnerability exists in your app simply because you haven't upgraded to the latest version of that package.
So last year, we introduced the NPM audit command which exists to find and fix vulnerabilities in your app by detecting outdated dependencies.
So you run NPM audit or you just run NPM instal and you get a list of vulnerable packages in your application.
We have run 335 million of those in the last 30 days. And it is having an effect on how secure JavaScript is. If you think that your company should be doing more about JavaScript security and it probably should, you'll forgive me if I take a second to mention that NPM Inc. has a product called NPM Enterprise.
NPM enterprise gives you your own registry, on your own domain, with your own personal NPM website, where you can see what your devs have published and you can publish your own private packages. You can get full package pages and readme's. It's just like the NPM website.
You get Single Sign On support, extra security and compliance reporting.
And basically, if you are a big company, you should probably be using it.
And if you are a small company, we have a product called Orgs which will do stuff for you instead.
With that terrible sales pitch over back to the survey data. Another aspect of our increasingly sophisticated user base is that people actually care about the software licences that they use.
That was a huge surprise to me.
I just throw things in there without checking. But 58% of people say that the licence affects whether they use a software package, an open-source software package, and within those people, 55% say that their company prohibits them from using specific licences.
So overall, 29% of people are prohibited by their company from using certain software licences.
What licences exactly? Well, the GPL and the AGPL are unpopular because of the restrictions they placed on commercial software, but much bigger than those was unrecognised licences.
The problem is, if you want to have a list of licences you use that are approved at your company, you have to hire a lawyer to tell you which licences are approved. So if you run into a licence you've never seen before, you have to go back and hire the lawyer again. And nobody wants to do that.
So people just have a short list and they stick with them. And they ignore licences that are outside of that list. So if you have to put up a (mumbles) licence, pick a... Please put a software licence on your open-source and definitely pick one of the big ones.
You're not going to be able to get away with making your own licence.
Facebook tried to put one on React and everybody told them that they wouldn't. So if Facebook can't get away with it, you definitely cannot.
And the final aspect of who we are that I want to touch on is a consequence of how ubiquitous JavaScript has become. When 68% of people are writing JavaScript, it's got to be the case.
And not all of those people are writing JavaScript because they want to, some of those people are writing JavaScript because they have to. It's become inescapable which means that there are a bunch of JavaScript developers who aren't writing JavaScript by choice.
And that is gonna show up in a bunch of places in this data. So what are those other languages written by developers for whom JavaScript is not their primary language? 25% of JavaScript developers say that it is not their primary language.
Top of the list is TypeScript.
And I'm going to talk more about TypeScript in a bit. But there are also tonnes of Python and Java and C/C (mumbles) developers in there.
A fun fact is that 12% of JavaScript developers say that they don't write any other languages. It's just JavaScript all the time.
So now we've covered who we are and we are all over the world.
We are every age and experience.
We are increasingly sophisticated developers who care about security and licencing, and 88% of us write languages other than JavaScript. Where are we writing all of this JavaScript? Is the next question.
And the answer is every goddamn place you can imagine. The first and most obvious place is browsers. 97% of us write code for browsers.
But 77% of us are also writing code for servers. So no, jazz is still a big deal for the, excuse me, no (mumbles) is still a big deal for the community.
But there were two big surprises in here.
The first of which was that 46% of us are writing native applications in JavaScript, and 13% are doing embedded applications in JavaScript. And I'm going to dig into all of those numbers. First off, when people write for browsers, do they target the mobile web or do they target desktops? The overwhelming majority of us are targeting both, 72%. But despite all of our talk about mobile first, only a very small number of people target only mobile. 27% of us are getting away without paying any attention to mobile at all. And that is probably legitimate.
There are a bunch of applications, which don't actually need to run on a phone ever.
They're back-end, back of office applications that no one's ever going to need to be responsive. But let's talk about native apps.
46% of JavaScript developers are writing native apps. That is a very different change from where we were 10 years ago.
By a native application, I mean an application that runs directly on your phone or your desktop or your laptop, not inside of a web browser, not a web app that has a shortcut to your home screen. We were very careful to phrase our survey question to capture only these types of applications. Sometimes they are transpiled.
Sometimes they are running inside of a Container on your desktop, but they are JavaScript and they are running directly on your hardware to the, directly.
Where are we writing JavaScript apps? Where are we writing native apps? As you can see, the biggest group is mobile devs. 35% of respondents said that they wrote native mobile apps and 26% said that they are writing native desktop apps, and a big chunk are doing both.
What are they using to do that stuff? Amongst desktop developers, 26% of devs say that they write native desktop apps.
And we have a bit of a puzzle here because we know from the survey data that 21% of people say they use Electron.
We've all used, we probably all heard about Electron as a way of writing native desktop applications in JavaScript.
But that means there is 5% of people who are writing native desktop applications in JavaScript, and they're not using Electron.
And I don't know what they are using.
If you do, please come talk to me after the conference, because not only are there 5% of people doing this, that number is getting bigger.
Last year, the number of people who said that they were writing Electron was 24%, and this year, it has dropped to 21%.
So somewhere, there's a community of native desktop application developers in JavaScript using a mysterious technology that I haven't heard of yet. Looking at native mobile app developers.
I measured the popularity of frameworks for native mobile apps, and I'm going to explain how I did this in a second.
The green line is all native frameworks.
So you can see that native development in general has stayed fairly popular over the years.
But the tools have fragmented since 2015.
You can see that in the yellow line, there's Cordova, which used to be the only game in town.
And these days, somewhere between 13% and 19% of JavaScript developers are using it.
React Native has grown very strongly.
And now another 19% of JavaScript developers using that. Together, those two add up to roughly to 35% of people who are writing native desktop application, native mobile applications, but if you are using something else, I would love to hear about it. Our final where question is about server side applications. Where are we deploying them? 77% of us are writing server side applications and the majority of us are using Containers like Docker or Kubernetes, with Docker to do that deploying. Sorry, deployment platforms like Heroku and Netlify which abstract away, some of those things are getting increasingly popular.
It was a surprise to me that virtual machines, which I personally sort of considered the default way of deploying software are only third in popularity. But the big surprise here was Serveless.
33% of us are deploying JavaScript to Severless platforms. This is not an early adopter technology anymore. This is a firmly mainstream trend.
And I'm gonna touch more on that later.
So now let's talk about what we're using to do with all of this.
As with the who and the where section, so I'm going to try and keep this as factual as possible. And to measure this stuff, I use a metric called Share of Registry.
Share of Registry is a very useful metric but also somewhat confusing metric so I'm going to explain that a little bit.
This is a graph of the weekly downloads from the NPM registry.
We do nearly 12 billion downloads per week at the moment and that has grown more than 26,000% since NPM Inc. became a company five years ago. And this presents something of a problem when you're trying to measure the popularity of things, because all of our download numbers go up.
Here's a graph of downloads of the some major front-end frameworks.
As you can see, they're all growing pretty fast. In fact, it's very difficult to tell which is getting more popular than everything else, 'cause everything is getting bigger.
Everything in the registry, all of the packages in the registry have more downloads this week than they did last week.
Every single package accumulates new users because just tonnes of new users are constantly showing up and going, "I don't know.
"I'll just use this thing called Evil Package One." So instead, we have to use absolute growth doesn't work. So instead, we have to use relative popularity of packages. We use downloads as a percentage of all of the downloads in the registry, and that is what I call Share of Registry. This is the same graph again.
Instead, using our Share of Registry metric now, it's a little bit clearer what's going on.
Some stuff is going up, some stuff is going down, some stuff is staying flat.
But it's important to remember that staying flat here means that you're keeping pace with the registry. So if you are a flatline on this graph, you grew 26,000%. If you are going up on this graph, you are growing faster than 26,000%.
You are going extremely fast indeed.
So now let's actually dig into these frameworks. The story of front-end frameworks in 2019 is extremely simple.
React has conquered the web.
It has more than four times as many downloads as the next biggest framework.
And there's never been a framework that is anything like this popular.
Part of the reason for that is that React is not just a front-end framework in fact, it's not even a front-end framework. React is just a component model.
And that component model is used in web apps, but it's also used in React Native mobile apps, and in Electron desktop apps.
But this is just the downloads data what about in the survey data? In our survey, 63% of JavaScript developers said that they are using React, but using is a very vague term.
What exactly do they mean? We asked a more specific question.
57% of people said that they write React themselves. 6% use React written by others.
But more interestingly, 15% of people say that they don't use React right now, but they are considering it, which means that this already enormous 63% adoption could potentially have room to grow even further. However, React's Share of Registry seems to be levelling off, so we don't really know if it's gonna grow further. To dig even further, we asked people how much they write React.
Inside of the 57% of people who said that they write React 49% said that they primarily write React, which means overall 26% of people who use JavaScript primarily write React these days.
And if you add in the people who write it sometimes, then 47% or nearly half of all JavaScript developers are writing React some or all of the time.
That is a ridiculous amount of adoption.
There has never been anything like this.
Moving on to other frameworks.
Last year, I got into some trouble because I took Angular version one and Angular version two onwards, and I treated them as a single framework called Angular. And I was strenuously informed by the Angular community that that is incorrect.
Angular version one is called Angular JS now, and Angular versions two onwards are a completely different framework, which has nothing in common with it, called Angular, (audience laughs) which I think is a little bit confusing, and I feel like I can be forgiven.
But as you can see, Angular JS has been in decline since 2016.
And Angular two onwards has been in decline since 2017. But it's very important to keep in mind that this is only decline in Share of Registry. This is a relative decline.
Both frameworks in absolute terms have more users than they've ever had before.
In absolute terms, both of these frameworks are still growing.
They're just not growing as fast as everything else in the registry.
37% of NPM users say that they are using some version of Angular. 29% of NPM users say that they are using the current version of Angular.
And that is probably about 3 million developers. This is not a small community, and it is still growing. So Angular is not going anywhere.
Let's look at one more framework of note, which is Vue. Vue is the only major framework other than React that is showing strong positive growth in Share of Registry. But it is extremely positive.
The share of registry has more than doubled in the last two years, which means that actual downloads went up by a factor of 10.
And our survey data backs this up.
This year 27% of people say that they are using Vue, which is up from 24% last year.
That means that in terms of share of developers, Vue and the current version of Angular or about level at the moment.
One thing I haven't talked about much is Web components. Part of that is that Web components are built into browsers so there's no Share of Registry to track, nobody's downloading anything from NPM to make them work. But the other reason is that they just don't seem to be very popular.
We didn't ask in our survey about Web components, which was a mistake.
But the state of JavaScript survey people did. Or rather they allowed people to volunteer if they used Web components, but less than 1% of people did. So I'm not ignoring Web components.
But the data that I have about Web components is not very good right now.
The people who build Web components into the browser are telling me that Web components are much more popular than I believe but of course, they would say that. Moving from the front-end to the back-end.
There has been a real revolution.
Previously, I've talked about Ember and things like (mumbles) and those frameworks are all still around and they are showing flat growth, which is to say 26,000% growth.
But everybody is writing rich front-end applications these days and frameworks that produce static views like those are becoming less useful for that kind of use case.
So instead, what has happened is that front-end framework enthusiasts have realised that for performance purposes, they need to be able to deliver pre-rendered HTML. So they invented stuff to do that, and they called it server side rendering.
Which is to say that the front-end framework people invented back-end frameworks.
So now the front-end frameworks are all back-end frameworks. All of them have their own back-end frameworks to go to that does all the routing and the rendering for you, which makes it really easy to build a full server using your favourite framework.
I don't know about you, but the idea that I can just write components and then throw them into an existing framework that does all of the parsing and serving for me, it's really great.
It's really useful.
And it's also really familiar.
I'm pretty sure this is how PHP worked.
Someday soon, somebody is going to tell me that I can just FTP my React components onto a server and they'll just work and then the circle will be complete. So we will have reached the level of PHP accessibility circa 1996.
Before I talk about these new SSR frameworks, it is important to note that they are all still pretty small hair for comparison is Express.
Express is a giant of a package.
It used to be 1.5% of the registry all by itself, and it is still very, very big.
All of the other frameworks that I'm about to be talking about are that flatline the bottom of the graph.
But when you take Express out of the picture, something very interesting is happening.
At the top of our list is Gatsby.
Gatsby uses React and provides a whole set of tools for hooking it up to back-ends and the whole suite of tools for deploying it as well.
Gatsby snuck up on us.
Two years ago, we didn't ask about it in our survey at all, which was a mistake, because this year when we asked, 8% of people said that they were using Gatsby. That is a big and real community for comparison frameworks like rails, and sorry, (mumbles). Those are hovering around the sort of 4%, 5% area. Ember is around there as well.
So Gatsby at 8% is a real framework with a real community and it is growing very, very fast.
And next comes a trio of back-end frameworks all of which have four letter names beginning with n and ending with t in a way that isn't annoying at all.
First up is Next.js, which is another React based back-end framework. Our survey respondents were very big on Next.js. There were about 9% of them said that they were using it. Share of Registry says that Gatsby is a little bit bigger. But it's clear that those two things are quite close together in terms of usage right now. Then there is Nuxt, with a U which is very much like Next.js but it's for Vue instead. About 5% of the devs in our survey said that they were using it.
And then there's Nest.js with an S which is apparently also very much like Next.js but it is for Angular.
I don't know very much about Nest.js.
Our survey didn't ask about it.
But extrapolating from the data, about 2% of JavaScript developers are using it and it is similarly showing some healthy growth. Closely related to all of these frameworks that are now back-ends is GraphQL.
GraphQL is the hot new way of building an API to power all of this stuff.
As you can see GraphQL's core library and two its most popular clients are all growing very, very quickly.
And that climb is reflected in our survey.
22% of JavaScript developers say that they are already using GraphQL.
Well, but 49% say that they are considering using GraphQL, which means that 2019 is going to be the year that everybody jumps on board the GraphQL train. And the final set of trend data we're going to look at is the hottest trend of all, which is the trend of not writing JavaScript anymore. Remember, all of those non primary JavaScript developers that I was talking about at the beginning? Especially the ones coming from typed languages, this is where the influence is beginning to show itself. The biggest part of this trend is TypeScript. Last year, we were caught very much by surprise when 46% of our survey respondents said that they use TypeScript.
And this year, that number is up to 63%.
But using is a very vague word.
So again, we asked in more detail, we discovered that 15% of people say that they are using TypeScript, but what they mean is they are using a framework that is written in TypeScript.
In particular, the current version of Angular is written in TypeScript.
So people who are using that version of Angular tend to identify as TypeScript users even though they're not writing a lot of TypeScript themselves. React and Ember both have TypeScript in them now as well. So in fact, the only framework that doesn't have some TypeScript in it is Vue.
But even if you say that you write TypeScript, do you mean that you write it all of the time? Do you just try it out? Is it just a thing you do once in a while? Within TypeScript developers, 52% of them say that they primarily write TypeScript and another 34% say that they write it some of the time, which means that overall, 36% of NPM users 36% of JavaScript developers are writing TypeScript some or all of the time.
A third of JavaScript developers don't write JavaScript anymore.
That is a huge change in this community.
Incidentally, one of the features of TypeScript is that it's type definition files are hosted on the NPM registry. And so I went checking and discovered that 2.5% of all downloads from the NPM registry are now types being downloaded mostly by copies of vs. code. So at some point, I'm going to have to have a chat with Microsoft about their bandwidth bill.
The other part of the not writing JavaScript trend is WebAssembly, which you've probably been hearing about. WebAssembly is a technology that lets you take any compiled language and run it on the web at near native speeds.
There's two things that people find interesting about that. The first is the speed.
But the people who write WebAssembly, the people who are creating WebAssembly say that that is not as as important or as interesting as the second part, which is that you can use any language. You can take existing code from other languages, and you don't have to put it to JavaScript, you can just compile it and run it directly on the web. To me, one of the most exciting features of that is that WebAssembly modules, once you've done that can inter-operate seamlessly with existing NPM modules, with existing JavaScript.
So you can use a tool, like Wasm pack for us or other tools in other languages, you can write code in those languages, and then turn it into an NPM package and publish it to the NPM registry and just use it with your existing JavaScript like any other module, and you won't even notice that is happening. And the reason that I know that you won't notice that that's happening is because that has already happened. There are already some popular packages that have Wasm in them.
And if Wasm supported, they switched to their Wasm implementation without you noticing.
I should say that WebAssembly is still very new; only about 3% of people say that they use it. But in the gigantic NPM community, that still means about 300,000 people.
And we found that only 0.06% of packages in the registry have WebAssembly in them.
But again, the registry has a million packages these days. So that's about 600 packages.
And some of those packages are already pretty cool and useful.
And you might even be using them without knowing. But the really interesting number for WebAssembly is 54% like graphQL that is the people who think that they are about to adopt number.
54% is an enormous number of people to be considering adopting a new technology especially when almost nobody's using it right now. So this year, I don't think it's safe to say that you'll be using WebAssembly, but you will get bored of hearing about WebAssembly at conferences.
You're going to be hearing about it over and over and over. And about a year from now, it'll actually be useful. So, now we know who we are and what we're using and those facts together can point us to some explanations as to why.
This is where I switch from facts to analysis, which is to say opinions, which means that I start being wrong.
But before I do that, I need to split the room up into two teams.
So everybody on this side of the room, you are team A. Everybody on this side of the room, you are Team B. Can I hear it from Team A? - [Team A] Whoa! Team B.
- [Team B] Whoa! - Team A again.
- [Team A] Whoa! - Team B again? - [Team B] Whoa! - All right, I'm not actually gonna use that for anything. It's just to wake you up after 30 minutes of graphs. (audience laughs) The first why question to answer is why is JavaScript the most popular programming language? I think we can discard the idea that it is the best designed programming language. But one possible answer is the NPM registry itself. A guy called Leo Meyerovich did a study in which he researched why people pick a programming language.
It was a huge empirical study for his PhD.
And the answer that came up was, open-source libraries. the biggest reason bigger than speed, bigger than features bigger than their company forced them to do it was the existence of open-source libraries that solve the problem at hand.
If there is an open-source library that does the thing that you want, you pick the language that that open-source library is in.
And because NPM is the biggest library of open-source, that means more people are getting attracted to JavaScript than any other language.
And once you do that, a positive feedback loop kicks in. More open-source libraries bring more users and those users write more open-source.
Once about every 15 minutes or so somebody on Twitter sends me this picture.
They think it's very funny.
But it's not actually a bad metaphor.
The NPM registry creates a gravity well that sucks in developers and once those developers are in the gravity well, they increase the pull.
But this is created, as I said, a new kind of JavaScript developer, the relaxant JavaScripter.
They used to be a very small group but these days, there are a quarter or more of the JavaScript developer community.
And they don't write JavaScript because they like it they write JavaScript because they have to. And that is bad.
That's bad for them, because they hate it, obviously. But that's bad for JavaScript, because people who don't like write a language who don't like the language, sorry, will write it very badly.
This happened before 'round about 2009 and 2010, the Ruby community found that JavaScript was taking off and they got sucked into JavaScript and they hated it. The survey data makes very clear that they hated it. They still hate it.
They don't wanna be doing it.
Very sorry, Ruby developers.
Some of the Ruby community attempted to solve this problem with CoffeeScript, which introduced a tonne of Ruby-like features into JavaScript and CoffeeScript at this point, I think it's safe to say has failed but the Ruby developers mostly won.
Modern JavaScript is full of features that I first ran into as part of Ruby and had been adopted into the JavaScript community as a result of all of those Ruby developers frequently demanding those features.
TypeScript is something like that pattern.
Remember, a lot of those non primary JavaScript developers, a bunch of people from typed languages have turned up in JavaScript and discovered that they missed the types from their other languages.
So TypeScript gives them what they miss.
It gives them the types back and given that there are huge numbers of people from typed languages writing JavaScript, and also that Microsoft is backing it, I don't think TypeScript is going to suffer CoffeeScript's fate.
I think TypeScript is probably here to stay. In our survey, 17% of people who had heard of WebAssembly said that the thing that they found most interesting about WebAssembly was it allowed them to write some language other than JavaScript because they didn't wanna be writing JavaScript. WebAssembly lets them do that.
WebAssembly frees web development from JavaScript and the result is inevitably going to be that a large number of people are going to stop writing JavaScript.
But I want to be clear, that's not something that I'm worried about or that you should be worried about.
First, not everybody is going to stop, just the people who hated writing JavaScript in the first place.
And second, when people who are writing WebAssembly are looking for a place to share the open-source WebAssembly that they're writing, the logical place for them to do that will be the NPM registry. The gravity well of the NPM registry will make it a natural place to publish those modules.
WebAssembly will make JavaScript stronger by giving JavaScript access to the best code from every other language.
That is a tremendously exciting idea.
And the next question worth spending time on is what the hell is going on with the React? Part of the explanation is that React isn't a full web framework.
It has no opinions about routing or data which means that as fashions change and routing and Data Management, people can switch to those new frameworks without having to abandon React itself.
And the other part is that it's just a component model. It creates truly reusable, fully functioning components. And if you've never seen quite how well that can work, here are two examples.
These are two React components that you can NPM instal today.
They provide a colour and the date picker.
You've just put them in your application and they work without you having to do any tedious configuration or copying of config. files.
And you could just instal them into your application. That has been the dream of web development for 20 years, my friends, and it is working, it is amazing. Other projects provide whole libraries of excellent prebuilt components to use.
React toolbox provides you with a bunch of material UI design elements.
It's using Google's material design, but it is not by Google.
And Reach UI is an excellent start on addressing accessibility concerns in React by providing a library of fully accessible components. that you can use in your application.
But now React can go even further.
Have you heard of Hooks? Raise your hands.
So in React 16.8, they introduced Hooks.
Hooks are new way of handling (mumbles) in React. They are tidier in a bunch of ways.
But one of the most interesting features about Hooks is because they are encapsulated, it means that you can NPM instal Hooks, and you can NPM instal a whole chunk of functionality into your application.
Again, as an NPM package, a promising early demonstration of that is a library called React Use, which just provides tonnes of functionality. This is just one screen.
They have like four more screens of things that they let you do.
It gives you access to a lot of the trickier parts of the web API while writing very little code. And again, you can just throw it into an existing React app without having to do a whole bunch of work. This suggests an enticing future where we can build web apps at a new and higher level of abstraction.
We won't have to think too hard about the server. We can just put existing components together without having to reimplement them every time we start a new project, each new component added to the pile will increase the value of the pile as a whole. And it can, it could produce the same feedback loop that made NPM itself popular.
This could make React an unstoppable force that changes web development forever.
But it's not guaranteed.
Like I said, React's Share of Registry seems to be levelling off and Vue is showing strong growth. So is React going to decline and fade like every web framework has before it? Is Vue going to be the future? We don't know.
But in the next couple of years, we're going to find out.
If React manages to stay strong for the next two years or so React will probably never go away.
In the meantime, React's dominance on the front-end has completely changed the back-end.
As I showed earlier, frameworks that enables server side rendering of React apps are now more popular than traditional frameworks.
So instead of writing code for client and server ISO (mumbles) apps, whatever the hell those were, we don't do that anymore. We just write code for the client and we get the server to figure it out.
And we also increasingly abstract away how the code is deployed.
We just throw it onto a serverless thing and get that to figure it out, scaling, routing, balancing, all of that stuff just gets abstracted away. Is that a good idea? Is building all apps as rich front-end apps a good idea? I don't know that it is.
But it's certainly a popular idea.
And popularity has its own momentum.
At least one browser maker is already working on specific optimizations to make React apps faster at the browser level.
And last year, I made the case that React components or at least some core parts of them should become part of the web API so that we can make React smaller and faster and the other frameworks which are doing things very similar to React can also become smaller and faster. And I stand by that because we've done this before. Everybody talks about jQuery and how we don't use jQuery anymore.
We do use jQuery, we use jQuery every day, the APIs that we're part of jQuery just became part of the web API.
You don't have to use the jQuery library to use jQuery anymore, 'cause it's just built into your browser.
And we can do that again.
And with React, it's beginning to look like we should. So let's take all of those trends and analysis and weave them together and make some guesses about the future, which means that I am going to go from being slightly wrong to being extremely wrong. First is a future that I don't have to guess about, and that is NPM Tink.
NPM Tink is a tremendously exciting leap forward as the Next Generation Package Manager and runtime. You won't have to instal packages anymore.
You won't have to transpile TypeScript.
You won't have to think about WebAssembly.
You can just import it all and let Tink figure it out. And let's see what that looks like in practise. So what you're seeing here is there's two modules in this folder.
One is JavaScript and one is Wasm.
The main file is TypeScript.
That's index.ts.
We can import the Wasm straight into the TypeScript and then we can use tink sh to run it.
This is happening.
We have never run an NPM instal.
All that stuff is happening in the background. There's no babble.
There's no web pack.
There's no transpiling.
There's no loading.
All of that stuff is just happening automatically in the background and it works. It is amazing.
And it is very exciting.
Dan Abramov tweeted recently about how VB6 is the thing that got him into programming, and it was a really great point because that is exactly where all of this looks like it might be going. Imagine a world where you can build a web app without needing to know the details of how all of your components work.
People hate on VB6, but VB6 at one point was the most popular programming language in the world. And that's us now.
VB6 unlocked and created a whole generation of programmers just by being very, very easy to use, and we can be the same thing.
Think how many more people could be web developers if you could build a real useful web application by just dragging and dropping open-source components and putting them together.
This wouldn't make the job of current web developers obsolete, you would still need everybody in this room and everybody who works for you to write Web components. But we would need a room 10 times this size to fit all of the people who would be using those applications.
A whole new level of abstraction would create a whole new type of web developer, which I think it's a tremendously exciting idea. Then you add to that mix, WebAssembly.
Like I said, it's still very early days for WebAssembly. But you could bring every useful library from all of those other package repositories, and pull them into the same unified library of open-source. You can make them all interoperable with no performance hit and suddenly, not only is it easier to build apps in JavaScript than any other language, but you can do more stuff in JavaScript than you can do in any other language because you can do everything all of the other languages can do.
And the last piece of the puzzle is all of those native app developers.
They are already nearly half of us.
You can take highly performant rich web apps and then you can run them anywhere you like. You can run them on desktops, on phones, on tablets, on watches, on VR headsets, on your shoes, wherever the hell you want.
JavaScript running everywhere, absorbing every other language into a single unified world of open-source components built by an everexpanding and increasingly diverse community of developers. There is no guarantee that this will happen. But I can imagine a world where the thing that we have grown up calling web development becomes just the way that we build all software. And after 23 years of watching the Web grow, no time has been more exciting than right now to be involved in web development.
And you, my friends and colleagues in this room are perfectly placed to become part of that change. The Web is an amazing force for good and for evil. It is a toy, and it is a tool.
It is a playground and a marketplace.
It is ultimately amazing and terrifying and its power. We can do as web developers so much good and so much harm, depending what we choose to build. But I choose to believe that in the long run, we are going to collectively decide to do more things that help the world than hurt it.
We've all made mistakes that have hurt people in the past. I know that I have.
But I believe that in the course of time, our good decisions will outweigh our mistakes and that the Web will grow forever.
I hope that what I've shared with you today, has helped you see where you are and what you can do. I hope that's helped motivate you and I hope that helped make you curious, and I hope that you have a great conference today. Thank you all so much for your time and attention. (audience applause) (upbeat music) $%^&1_Laurie Voss.srt#$%^
(upbeat music) (audience applause) - Hello, everybody.
Oh dear, I've destroyed my slides already.
Sorry. All right.
Before we get started, it's very important that I take a speaker selfie, because if it's not on Instagram, did it even happen? Alright, that important thing out of the way. Good morning.
My name is Laurie, thank you very much to the organisers of Web Directions for inviting me to speak and thank you all for waking up what I realise is very early to hear me talk. This is my first visit to Australia and I'm liking it so far.
The coffee is as good as everyone said that it would be. (audience laughs) I helped co-found NPM Inc.
and I'm currently the Chief Data Officer there which means I basically draw graphs and stuff and count things up.
But what I am, what I identify as is a web developer. I've been a web developer for 23 years now, which means that I occasionally run into people who are younger than some of my websites.
Making the Web bigger and better and more accessible to more people is what really drives me.
And I know you were all expecting a talk about the future of JavaScript, 'cause that was on the thing, but at the last minute, I decided to throw it all away and give a talk about microfrontends.
(man laughs) Not really.
Can you even imagine? If you laughed at that joke, you spend too much time on Twitter.
What I'm really here to talk about is JavaScript. I'm going to talk about who we are.
We the people who write JavaScript.
- And as John just mentioned, who in this room considers themselves a developer, even if it's not your day to day job right now? Right, Good. Excellent.
Because I'm gonna be using the words we and us a lot. So if you weren't all considering yourselves developers that would've got awkward.
I'm gonna be talking about who we are as JavaScript developers.
I'm going to be talking about where we're writing JavaScript.
I'm going to talk about why we're doing JavaScript the way that we are right now. The forces that got us to the state that we're in. And then finally, I'm gonna talk about what comes next. I'm going to take a look at all the trends that I'm going to tell you about today and make some guesses about where this is going to go. The goal of this talk is to give you a sense of perspective about the state of JavaScript as a whole, and where your current tools and techniques sit. Because too many developers work in a vacuum. We don't know if the stuff that we are doing at the company we're at is a best practise or an outdated practise or a new fad that nobody's really doing yet because very few people have hard data.
There's an enormous amount of hype going on. But NPM has hard data.
And that is what I'm here to share with you. I hope that you'll leave this talk feeling good about one thing that you're currently using. Realising that it's time to move on from one other thing that you're using and curious about one new thing that you think it's time to learn.
But before I get into all of this stuff, it's worth asking where I have this information. I have three main sources of information.
The first is the NPM registry logs.
NPM gets two billion downloads every single day. That gives us an enormous amount of insight into what people are using and whether that stuff is getting more popular or less popular.
Second, we went out and asked people directly. We don't have to extrapolate from the downloads. We did a survey two years ago of 16,000 JavaScript developers.
And then we repeated it again last year with 33,000 JavaScript developers.
So we have an enormous amount of direct information. And then finally, I supplemented and double checked our numbers with the excellent state of JavaScript survey which is run by some independent members of the community, who luckily came up with all the same numbers that we did. So I felt a little bit better about our survey at that point.
Incidentally, this talk is focusing on JavaScript but if you are more of a CSS person or you are very interested in CSS, the same people who did the state of JavaScript survey did a state of CSS survey this year, which is full of really interesting information about what is going on in CSS land, presented with an overwhelming super fluidity of CSS transitions and animations.
I've never seen a website that went so completely overboard on animations. And before we dive in, a few quick disclaimers. Some of what I'm presenting here are facts and some of what I'm presenting here are opinions. And I'm going to try and be as clear as possible about which of those is which.
One of the things that happens nearly every time I give this talk is somebody will see a graph that shows that a technology that they are using is getting less popular, and they get very, very angry about it, and there's nothing I can do about it. The disclaimer doesn't work.
All I can say is I have a lot of terrible opinions. Please feel free to get mad about my terrible opinions, but try not to get mad about the graphs.
They're just graphs.
I do not have a horse in this race other than NPM. I'm not a contributor to any of the projects that I'm talking about.
Secondly, a lot of what I'm talking about involves relative popularity of technologies. And I wanna make clear that just because the technology is popular, that does not mean that it is the best. In fact, I don't even know what best means when it comes to a technology.
Technology lives in a multi dimensional space that depending on your constraints and your team, and where you are as a company, the best solution is going to be different for every single person. There is no single best answer.
However, I have an enormous amount of information about popularity.
So popularity is what I'm going to be talking about and popularity is useful for a technology.
If there's a lot of people using your technology then there will be a lot of tutorials about it. There will be a lot of bugs fixed, there will be a lot of Stack Overflow questions answered. It will be easier to hire people who are using that technology.
So regardless of how good a technology is, if it is popular that can make your job easier. And finally, I really, really love this stuff. And I tend to get very excited about it.
When I get excited about things, I curse like a drunken sailor.
And I have absolutely no intention of changing or modifying that behaviour in any way.
So just apologies in advance.
So who are we? The JavaScript developers? The answer is, at this point, we are pretty much like all developers.
If you look at our demographics, we have the same age distribution, the same levels of education as developers working in all other fields.
We work in every industry, in every country in the world. And part of the reason for that, is that we are rapidly expanding to be all developers. There are now 11 million JavaScript developers in the world. And those 11 million developers are using more open-source software than any language community has ever used before.
The NPM registry is the largest repository of open-source of any kind that has ever existed.
Whether you measure it by lines of code, or number of modules, or number of users, whatever it is still the biggest.
It is more than twice as big as the next biggest module repository.
Of course, everybody knows that JavaScript has a tendency to use lots and lots of small modules.
So maybe that's an unfair comparison.
What about other kinds of activity? On GitHub, JavaScript is the biggest language by number of repositories, by number of issues, by lines of code, and it has been for seven years. On Stack Overflow, they did a survey recently of 80,000 developers and JavaScript was the most popular language with 68% of all developers saying that they use it. Of course, you work in this field.
So probably by this point, you were aware that JavaScript is a fairly popular language. But here's the truth.
JavaScript is the most popular programming language in the world and there are more developers than there have ever been before.
So JavaScript is the most popular programming language that has ever existed.
As JavaScript continues to grow, the JavaScript community is changing.
One thing that we noticed between our surveys from two years ago and last year, is that JavaScript developers are getting more experienced. They've been writing JavaScript for longer. We especially noticed this with NPM itself. A year ago, half of NPM users were new by which we meant that they've been using NPM for less than two years.
And this year, only about a third of them are. Around about 2014 and 2015, there was a massive and sudden spike in the number of NPM users, as basically all the people who had been writing JavaScript before NPM was invented, sort of clued into the existence of NPM and started using it simultaneously. These days, the number of new NPM users and the number of new JavaScript users are beginning to converge on the same number. Essentially, all of the people who knew JavaScript before NPM have picked it up by this point. And all of the people who are learning JavaScript these days learn NPM at the same time.
So our current estimate is as of the end of 2019, about 99% of JavaScript developers will also be NPM users.
So that is why in the course of this talk, when I talk about NPM users, or survey respondents or JavaScript developers, I use those terms interchangeably because they pretty much are.
So this ever growing pool of increasingly experienced JavaScript developers means that we've seen a shift in what people care about.
We knew from analysing last year's data when we split people up by experience, that more experienced developers have different concerns.
They tend to be more interested in best practises. They care more about security.
They do more bundling.
They do more linting.
They use more web frameworks.
They just do more of everything.
And now that the whole JavaScript community is getting more experienced, that's becoming true of the whole JavaScript community.
Since last year's survey, the number of people concerned about the security of the open-source modules that they use has increased.
And we have done some things to address that. In the last two years NPM has introduced two-factor off to help protect package publishers from account theft so that nobody can publish malicious packages as them. And we've also built a lot of automation behind the team behind the scenes and hired a security team to detect and flag malicious packages.
But malicious packages are not really the primary threat. Much more common than malicious packages are accidentally vulnerable packages.
Packages where the vulnerability was a mistake or a bug. And the vulnerability exists in your app simply because you haven't upgraded to the latest version of that package.
So last year, we introduced the NPM audit command which exists to find and fix vulnerabilities in your app by detecting outdated dependencies.
So you run NPM audit or you just run NPM instal and you get a list of vulnerable packages in your application.
We have run 335 million of those in the last 30 days. And it is having an effect on how secure JavaScript is. If you think that your company should be doing more about JavaScript security and it probably should, you'll forgive me if I take a second to mention that NPM Inc. has a product called NPM Enterprise.
NPM enterprise gives you your own registry, on your own domain, with your own personal NPM website, where you can see what your devs have published and you can publish your own private packages. You can get full package pages and readme's. It's just like the NPM website.
You get Single Sign On support, extra security and compliance reporting.
And basically, if you are a big company, you should probably be using it.
And if you are a small company, we have a product called Orgs which will do stuff for you instead.
With that terrible sales pitch over back to the survey data. Another aspect of our increasingly sophisticated user base is that people actually care about the software licences that they use.
That was a huge surprise to me.
I just throw things in there without checking. But 58% of people say that the licence affects whether they use a software package, an open-source software package, and within those people, 55% say that their company prohibits them from using specific licences.
So overall, 29% of people are prohibited by their company from using certain software licences.
What licences exactly? Well, the GPL and the AGPL are unpopular because of the restrictions they placed on commercial software, but much bigger than those was unrecognised licences.
The problem is, if you want to have a list of licences you use that are approved at your company, you have to hire a lawyer to tell you which licences are approved. So if you run into a licence you've never seen before, you have to go back and hire the lawyer again. And nobody wants to do that.
So people just have a short list and they stick with them. And they ignore licences that are outside of that list. So if you have to put up a (mumbles) licence, pick a... Please put a software licence on your open-source and definitely pick one of the big ones.
You're not going to be able to get away with making your own licence.
Facebook tried to put one on React and everybody told them that they wouldn't. So if Facebook can't get away with it, you definitely cannot.
And the final aspect of who we are that I want to touch on is a consequence of how ubiquitous JavaScript has become. When 68% of people are writing JavaScript, it's got to be the case.
And not all of those people are writing JavaScript because they want to, some of those people are writing JavaScript because they have to. It's become inescapable which means that there are a bunch of JavaScript developers who aren't writing JavaScript by choice.
And that is gonna show up in a bunch of places in this data. So what are those other languages written by developers for whom JavaScript is not their primary language? 25% of JavaScript developers say that it is not their primary language.
Top of the list is TypeScript.
And I'm going to talk more about TypeScript in a bit. But there are also tonnes of Python and Java and C/C (mumbles) developers in there.
A fun fact is that 12% of JavaScript developers say that they don't write any other languages. It's just JavaScript all the time.
So now we've covered who we are and we are all over the world.
We are every age and experience.
We are increasingly sophisticated developers who care about security and licencing, and 88% of us write languages other than JavaScript. Where are we writing all of this JavaScript? Is the next question.
And the answer is every goddamn place you can imagine. The first and most obvious place is browsers. 97% of us write code for browsers.
But 77% of us are also writing code for servers. So no, jazz is still a big deal for the, excuse me, no (mumbles) is still a big deal for the community.
But there were two big surprises in here.
The first of which was that 46% of us are writing native applications in JavaScript, and 13% are doing embedded applications in JavaScript. And I'm going to dig into all of those numbers. First off, when people write for browsers, do they target the mobile web or do they target desktops? The overwhelming majority of us are targeting both, 72%. But despite all of our talk about mobile first, only a very small number of people target only mobile. 27% of us are getting away without paying any attention to mobile at all. And that is probably legitimate.
There are a bunch of applications, which don't actually need to run on a phone ever.
They're back-end, back of office applications that no one's ever going to need to be responsive. But let's talk about native apps.
46% of JavaScript developers are writing native apps. That is a very different change from where we were 10 years ago.
By a native application, I mean an application that runs directly on your phone or your desktop or your laptop, not inside of a web browser, not a web app that has a shortcut to your home screen. We were very careful to phrase our survey question to capture only these types of applications. Sometimes they are transpiled.
Sometimes they are running inside of a Container on your desktop, but they are JavaScript and they are running directly on your hardware to the, directly.
Where are we writing JavaScript apps? Where are we writing native apps? As you can see, the biggest group is mobile devs. 35% of respondents said that they wrote native mobile apps and 26% said that they are writing native desktop apps, and a big chunk are doing both.
What are they using to do that stuff? Amongst desktop developers, 26% of devs say that they write native desktop apps.
And we have a bit of a puzzle here because we know from the survey data that 21% of people say they use Electron.
We've all used, we probably all heard about Electron as a way of writing native desktop applications in JavaScript.
But that means there is 5% of people who are writing native desktop applications in JavaScript, and they're not using Electron.
And I don't know what they are using.
If you do, please come talk to me after the conference, because not only are there 5% of people doing this, that number is getting bigger.
Last year, the number of people who said that they were writing Electron was 24%, and this year, it has dropped to 21%.
So somewhere, there's a community of native desktop application developers in JavaScript using a mysterious technology that I haven't heard of yet. Looking at native mobile app developers.
I measured the popularity of frameworks for native mobile apps, and I'm going to explain how I did this in a second.
The green line is all native frameworks.
So you can see that native development in general has stayed fairly popular over the years.
But the tools have fragmented since 2015.
You can see that in the yellow line, there's Cordova, which used to be the only game in town.
And these days, somewhere between 13% and 19% of JavaScript developers are using it.
React Native has grown very strongly.
And now another 19% of JavaScript developers using that. Together, those two add up to roughly to 35% of people who are writing native desktop application, native mobile applications, but if you are using something else, I would love to hear about it. Our final where question is about server side applications. Where are we deploying them? 77% of us are writing server side applications and the majority of us are using Containers like Docker or Kubernetes, with Docker to do that deploying. Sorry, deployment platforms like Heroku and Netlify which abstract away, some of those things are getting increasingly popular.
It was a surprise to me that virtual machines, which I personally sort of considered the default way of deploying software are only third in popularity. But the big surprise here was Serveless.
33% of us are deploying JavaScript to Severless platforms. This is not an early adopter technology anymore. This is a firmly mainstream trend.
And I'm gonna touch more on that later.
So now let's talk about what we're using to do with all of this.
As with the who and the where section, so I'm going to try and keep this as factual as possible. And to measure this stuff, I use a metric called Share of Registry.
Share of Registry is a very useful metric but also somewhat confusing metric so I'm going to explain that a little bit.
This is a graph of the weekly downloads from the NPM registry.
We do nearly 12 billion downloads per week at the moment and that has grown more than 26,000% since NPM Inc. became a company five years ago. And this presents something of a problem when you're trying to measure the popularity of things, because all of our download numbers go up.
Here's a graph of downloads of the some major front-end frameworks.
As you can see, they're all growing pretty fast. In fact, it's very difficult to tell which is getting more popular than everything else, 'cause everything is getting bigger.
Everything in the registry, all of the packages in the registry have more downloads this week than they did last week.
Every single package accumulates new users because just tonnes of new users are constantly showing up and going, "I don't know.
"I'll just use this thing called Evil Package One." So instead, we have to use absolute growth doesn't work. So instead, we have to use relative popularity of packages. We use downloads as a percentage of all of the downloads in the registry, and that is what I call Share of Registry. This is the same graph again.
Instead, using our Share of Registry metric now, it's a little bit clearer what's going on.
Some stuff is going up, some stuff is going down, some stuff is staying flat.
But it's important to remember that staying flat here means that you're keeping pace with the registry. So if you are a flatline on this graph, you grew 26,000%. If you are going up on this graph, you are growing faster than 26,000%.
You are going extremely fast indeed.
So now let's actually dig into these frameworks. The story of front-end frameworks in 2019 is extremely simple.
React has conquered the web.
It has more than four times as many downloads as the next biggest framework.
And there's never been a framework that is anything like this popular.
Part of the reason for that is that React is not just a front-end framework in fact, it's not even a front-end framework. React is just a component model.
And that component model is used in web apps, but it's also used in React Native mobile apps, and in Electron desktop apps.
But this is just the downloads data what about in the survey data? In our survey, 63% of JavaScript developers said that they are using React, but using is a very vague term.
What exactly do they mean? We asked a more specific question.
57% of people said that they write React themselves. 6% use React written by others.
But more interestingly, 15% of people say that they don't use React right now, but they are considering it, which means that this already enormous 63% adoption could potentially have room to grow even further. However, React's Share of Registry seems to be levelling off, so we don't really know if it's gonna grow further. To dig even further, we asked people how much they write React.
Inside of the 57% of people who said that they write React 49% said that they primarily write React, which means overall 26% of people who use JavaScript primarily write React these days.
And if you add in the people who write it sometimes, then 47% or nearly half of all JavaScript developers are writing React some or all of the time.
That is a ridiculous amount of adoption.
There has never been anything like this.
Moving on to other frameworks.
Last year, I got into some trouble because I took Angular version one and Angular version two onwards, and I treated them as a single framework called Angular. And I was strenuously informed by the Angular community that that is incorrect.
Angular version one is called Angular JS now, and Angular versions two onwards are a completely different framework, which has nothing in common with it, called Angular, (audience laughs) which I think is a little bit confusing, and I feel like I can be forgiven.
But as you can see, Angular JS has been in decline since 2016.
And Angular two onwards has been in decline since 2017. But it's very important to keep in mind that this is only decline in Share of Registry. This is a relative decline.
Both frameworks in absolute terms have more users than they've ever had before.
In absolute terms, both of these frameworks are still growing.
They're just not growing as fast as everything else in the registry.
37% of NPM users say that they are using some version of Angular. 29% of NPM users say that they are using the current version of Angular.
And that is probably about 3 million developers. This is not a small community, and it is still growing. So Angular is not going anywhere.
Let's look at one more framework of note, which is Vue. Vue is the only major framework other than React that is showing strong positive growth in Share of Registry. But it is extremely positive.
The share of registry has more than doubled in the last two years, which means that actual downloads went up by a factor of 10.
And our survey data backs this up.
This year 27% of people say that they are using Vue, which is up from 24% last year.
That means that in terms of share of developers, Vue and the current version of Angular or about level at the moment.
One thing I haven't talked about much is Web components. Part of that is that Web components are built into browsers so there's no Share of Registry to track, nobody's downloading anything from NPM to make them work. But the other reason is that they just don't seem to be very popular.
We didn't ask in our survey about Web components, which was a mistake.
But the state of JavaScript survey people did. Or rather they allowed people to volunteer if they used Web components, but less than 1% of people did. So I'm not ignoring Web components.
But the data that I have about Web components is not very good right now.
The people who build Web components into the browser are telling me that Web components are much more popular than I believe but of course, they would say that. Moving from the front-end to the back-end.
There has been a real revolution.
Previously, I've talked about Ember and things like (mumbles) and those frameworks are all still around and they are showing flat growth, which is to say 26,000% growth.
But everybody is writing rich front-end applications these days and frameworks that produce static views like those are becoming less useful for that kind of use case.
So instead, what has happened is that front-end framework enthusiasts have realised that for performance purposes, they need to be able to deliver pre-rendered HTML. So they invented stuff to do that, and they called it server side rendering.
Which is to say that the front-end framework people invented back-end frameworks.
So now the front-end frameworks are all back-end frameworks. All of them have their own back-end frameworks to go to that does all the routing and the rendering for you, which makes it really easy to build a full server using your favourite framework.
I don't know about you, but the idea that I can just write components and then throw them into an existing framework that does all of the parsing and serving for me, it's really great.
It's really useful.
And it's also really familiar.
I'm pretty sure this is how PHP worked.
Someday soon, somebody is going to tell me that I can just FTP my React components onto a server and they'll just work and then the circle will be complete. So we will have reached the level of PHP accessibility circa 1996.
Before I talk about these new SSR frameworks, it is important to note that they are all still pretty small hair for comparison is Express.
Express is a giant of a package.
It used to be 1.5% of the registry all by itself, and it is still very, very big.
All of the other frameworks that I'm about to be talking about are that flatline the bottom of the graph.
But when you take Express out of the picture, something very interesting is happening.
At the top of our list is Gatsby.
Gatsby uses React and provides a whole set of tools for hooking it up to back-ends and the whole suite of tools for deploying it as well.
Gatsby snuck up on us.
Two years ago, we didn't ask about it in our survey at all, which was a mistake, because this year when we asked, 8% of people said that they were using Gatsby. That is a big and real community for comparison frameworks like rails, and sorry, (mumbles). Those are hovering around the sort of 4%, 5% area. Ember is around there as well.
So Gatsby at 8% is a real framework with a real community and it is growing very, very fast.
And next comes a trio of back-end frameworks all of which have four letter names beginning with n and ending with t in a way that isn't annoying at all.
First up is Next.js, which is another React based back-end framework. Our survey respondents were very big on Next.js. There were about 9% of them said that they were using it. Share of Registry says that Gatsby is a little bit bigger. But it's clear that those two things are quite close together in terms of usage right now. Then there is Nuxt, with a U which is very much like Next.js but it's for Vue instead. About 5% of the devs in our survey said that they were using it.
And then there's Nest.js with an S which is apparently also very much like Next.js but it is for Angular.
I don't know very much about Nest.js.
Our survey didn't ask about it.
But extrapolating from the data, about 2% of JavaScript developers are using it and it is similarly showing some healthy growth. Closely related to all of these frameworks that are now back-ends is GraphQL.
GraphQL is the hot new way of building an API to power all of this stuff.
As you can see GraphQL's core library and two its most popular clients are all growing very, very quickly.
And that climb is reflected in our survey.
22% of JavaScript developers say that they are already using GraphQL.
Well, but 49% say that they are considering using GraphQL, which means that 2019 is going to be the year that everybody jumps on board the GraphQL train. And the final set of trend data we're going to look at is the hottest trend of all, which is the trend of not writing JavaScript anymore. Remember, all of those non primary JavaScript developers that I was talking about at the beginning? Especially the ones coming from typed languages, this is where the influence is beginning to show itself. The biggest part of this trend is TypeScript. Last year, we were caught very much by surprise when 46% of our survey respondents said that they use TypeScript.
And this year, that number is up to 63%.
But using is a very vague word.
So again, we asked in more detail, we discovered that 15% of people say that they are using TypeScript, but what they mean is they are using a framework that is written in TypeScript.
In particular, the current version of Angular is written in TypeScript.
So people who are using that version of Angular tend to identify as TypeScript users even though they're not writing a lot of TypeScript themselves. React and Ember both have TypeScript in them now as well. So in fact, the only framework that doesn't have some TypeScript in it is Vue.
But even if you say that you write TypeScript, do you mean that you write it all of the time? Do you just try it out? Is it just a thing you do once in a while? Within TypeScript developers, 52% of them say that they primarily write TypeScript and another 34% say that they write it some of the time, which means that overall, 36% of NPM users 36% of JavaScript developers are writing TypeScript some or all of the time.
A third of JavaScript developers don't write JavaScript anymore.
That is a huge change in this community.
Incidentally, one of the features of TypeScript is that it's type definition files are hosted on the NPM registry. And so I went checking and discovered that 2.5% of all downloads from the NPM registry are now types being downloaded mostly by copies of vs. code. So at some point, I'm going to have to have a chat with Microsoft about their bandwidth bill.
The other part of the not writing JavaScript trend is WebAssembly, which you've probably been hearing about. WebAssembly is a technology that lets you take any compiled language and run it on the web at near native speeds.
There's two things that people find interesting about that. The first is the speed.
But the people who write WebAssembly, the people who are creating WebAssembly say that that is not as as important or as interesting as the second part, which is that you can use any language. You can take existing code from other languages, and you don't have to put it to JavaScript, you can just compile it and run it directly on the web. To me, one of the most exciting features of that is that WebAssembly modules, once you've done that can inter-operate seamlessly with existing NPM modules, with existing JavaScript.
So you can use a tool, like Wasm pack for us or other tools in other languages, you can write code in those languages, and then turn it into an NPM package and publish it to the NPM registry and just use it with your existing JavaScript like any other module, and you won't even notice that is happening. And the reason that I know that you won't notice that that's happening is because that has already happened. There are already some popular packages that have Wasm in them.
And if Wasm supported, they switched to their Wasm implementation without you noticing.
I should say that WebAssembly is still very new; only about 3% of people say that they use it. But in the gigantic NPM community, that still means about 300,000 people.
And we found that only 0.06% of packages in the registry have WebAssembly in them.
But again, the registry has a million packages these days. So that's about 600 packages.
And some of those packages are already pretty cool and useful.
And you might even be using them without knowing. But the really interesting number for WebAssembly is 54% like graphQL that is the people who think that they are about to adopt number.
54% is an enormous number of people to be considering adopting a new technology especially when almost nobody's using it right now. So this year, I don't think it's safe to say that you'll be using WebAssembly, but you will get bored of hearing about WebAssembly at conferences.
You're going to be hearing about it over and over and over. And about a year from now, it'll actually be useful. So, now we know who we are and what we're using and those facts together can point us to some explanations as to why.
This is where I switch from facts to analysis, which is to say opinions, which means that I start being wrong.
But before I do that, I need to split the room up into two teams.
So everybody on this side of the room, you are team A. Everybody on this side of the room, you are Team B. Can I hear it from Team A? - [Team A] Whoa! Team B.
- [Team B] Whoa! - Team A again.
- [Team A] Whoa! - Team B again? - [Team B] Whoa! - All right, I'm not actually gonna use that for anything. It's just to wake you up after 30 minutes of graphs. (audience laughs) The first why question to answer is why is JavaScript the most popular programming language? I think we can discard the idea that it is the best designed programming language. But one possible answer is the NPM registry itself. A guy called Leo Meyerovich did a study in which he researched why people pick a programming language.
It was a huge empirical study for his PhD.
And the answer that came up was, open-source libraries. the biggest reason bigger than speed, bigger than features bigger than their company forced them to do it was the existence of open-source libraries that solve the problem at hand.
If there is an open-source library that does the thing that you want, you pick the language that that open-source library is in.
And because NPM is the biggest library of open-source, that means more people are getting attracted to JavaScript than any other language.
And once you do that, a positive feedback loop kicks in. More open-source libraries bring more users and those users write more open-source.
Once about every 15 minutes or so somebody on Twitter sends me this picture.
They think it's very funny.
But it's not actually a bad metaphor.
The NPM registry creates a gravity well that sucks in developers and once those developers are in the gravity well, they increase the pull.
But this is created, as I said, a new kind of JavaScript developer, the relaxant JavaScripter.
They used to be a very small group but these days, there are a quarter or more of the JavaScript developer community.
And they don't write JavaScript because they like it they write JavaScript because they have to. And that is bad.
That's bad for them, because they hate it, obviously. But that's bad for JavaScript, because people who don't like write a language who don't like the language, sorry, will write it very badly.
This happened before 'round about 2009 and 2010, the Ruby community found that JavaScript was taking off and they got sucked into JavaScript and they hated it. The survey data makes very clear that they hated it. They still hate it.
They don't wanna be doing it.
Very sorry, Ruby developers.
Some of the Ruby community attempted to solve this problem with CoffeeScript, which introduced a tonne of Ruby-like features into JavaScript and CoffeeScript at this point, I think it's safe to say has failed but the Ruby developers mostly won.
Modern JavaScript is full of features that I first ran into as part of Ruby and had been adopted into the JavaScript community as a result of all of those Ruby developers frequently demanding those features.
TypeScript is something like that pattern.
Remember, a lot of those non primary JavaScript developers, a bunch of people from typed languages have turned up in JavaScript and discovered that they missed the types from their other languages.
So TypeScript gives them what they miss.
It gives them the types back and given that there are huge numbers of people from typed languages writing JavaScript, and also that Microsoft is backing it, I don't think TypeScript is going to suffer CoffeeScript's fate.
I think TypeScript is probably here to stay. In our survey, 17% of people who had heard of WebAssembly said that the thing that they found most interesting about WebAssembly was it allowed them to write some language other than JavaScript because they didn't wanna be writing JavaScript. WebAssembly lets them do that.
WebAssembly frees web development from JavaScript and the result is inevitably going to be that a large number of people are going to stop writing JavaScript.
But I want to be clear, that's not something that I'm worried about or that you should be worried about.
First, not everybody is going to stop, just the people who hated writing JavaScript in the first place.
And second, when people who are writing WebAssembly are looking for a place to share the open-source WebAssembly that they're writing, the logical place for them to do that will be the NPM registry. The gravity well of the NPM registry will make it a natural place to publish those modules.
WebAssembly will make JavaScript stronger by giving JavaScript access to the best code from every other language.
That is a tremendously exciting idea.
And the next question worth spending time on is what the hell is going on with the React? Part of the explanation is that React isn't a full web framework.
It has no opinions about routing or data which means that as fashions change and routing and Data Management, people can switch to those new frameworks without having to abandon React itself.
And the other part is that it's just a component model. It creates truly reusable, fully functioning components. And if you've never seen quite how well that can work, here are two examples.
These are two React components that you can NPM instal today.
They provide a colour and the date picker.
You've just put them in your application and they work without you having to do any tedious configuration or copying of config. files.
And you could just instal them into your application. That has been the dream of web development for 20 years, my friends, and it is working, it is amazing. Other projects provide whole libraries of excellent prebuilt components to use.
React toolbox provides you with a bunch of material UI design elements.
It's using Google's material design, but it is not by Google.
And Reach UI is an excellent start on addressing accessibility concerns in React by providing a library of fully accessible components. that you can use in your application.
But now React can go even further.
Have you heard of Hooks? Raise your hands.
So in React 16.8, they introduced Hooks.
Hooks are new way of handling (mumbles) in React. They are tidier in a bunch of ways.
But one of the most interesting features about Hooks is because they are encapsulated, it means that you can NPM instal Hooks, and you can NPM instal a whole chunk of functionality into your application.
Again, as an NPM package, a promising early demonstration of that is a library called React Use, which just provides tonnes of functionality. This is just one screen.
They have like four more screens of things that they let you do.
It gives you access to a lot of the trickier parts of the web API while writing very little code. And again, you can just throw it into an existing React app without having to do a whole bunch of work. This suggests an enticing future where we can build web apps at a new and higher level of abstraction.
We won't have to think too hard about the server. We can just put existing components together without having to reimplement them every time we start a new project, each new component added to the pile will increase the value of the pile as a whole. And it can, it could produce the same feedback loop that made NPM itself popular.
This could make React an unstoppable force that changes web development forever.
But it's not guaranteed.
Like I said, React's Share of Registry seems to be levelling off and Vue is showing strong growth. So is React going to decline and fade like every web framework has before it? Is Vue going to be the future? We don't know.
But in the next couple of years, we're going to find out.
If React manages to stay strong for the next two years or so React will probably never go away.
In the meantime, React's dominance on the front-end has completely changed the back-end.
As I showed earlier, frameworks that enables server side rendering of React apps are now more popular than traditional frameworks.
So instead of writing code for client and server ISO (mumbles) apps, whatever the hell those were, we don't do that anymore. We just write code for the client and we get the server to figure it out.
And we also increasingly abstract away how the code is deployed.
We just throw it onto a serverless thing and get that to figure it out, scaling, routing, balancing, all of that stuff just gets abstracted away. Is that a good idea? Is building all apps as rich front-end apps a good idea? I don't know that it is.
But it's certainly a popular idea.
And popularity has its own momentum.
At least one browser maker is already working on specific optimizations to make React apps faster at the browser level.
And last year, I made the case that React components or at least some core parts of them should become part of the web API so that we can make React smaller and faster and the other frameworks which are doing things very similar to React can also become smaller and faster. And I stand by that because we've done this before. Everybody talks about jQuery and how we don't use jQuery anymore.
We do use jQuery, we use jQuery every day, the APIs that we're part of jQuery just became part of the web API.
You don't have to use the jQuery library to use jQuery anymore, 'cause it's just built into your browser.
And we can do that again.
And with React, it's beginning to look like we should. So let's take all of those trends and analysis and weave them together and make some guesses about the future, which means that I am going to go from being slightly wrong to being extremely wrong. First is a future that I don't have to guess about, and that is NPM Tink.
NPM Tink is a tremendously exciting leap forward as the Next Generation Package Manager and runtime. You won't have to instal packages anymore.
You won't have to transpile TypeScript.
You won't have to think about WebAssembly.
You can just import it all and let Tink figure it out. And let's see what that looks like in practise. So what you're seeing here is there's two modules in this folder.
One is JavaScript and one is Wasm.
The main file is TypeScript.
That's index.ts.
We can import the Wasm straight into the TypeScript and then we can use tink sh to run it.
This is happening.
We have never run an NPM instal.
All that stuff is happening in the background. There's no babble.
There's no web pack.
There's no transpiling.
There's no loading.
All of that stuff is just happening automatically in the background and it works. It is amazing.
And it is very exciting.
Dan Abramov tweeted recently about how VB6 is the thing that got him into programming, and it was a really great point because that is exactly where all of this looks like it might be going. Imagine a world where you can build a web app without needing to know the details of how all of your components work.
People hate on VB6, but VB6 at one point was the most popular programming language in the world. And that's us now.
VB6 unlocked and created a whole generation of programmers just by being very, very easy to use, and we can be the same thing.
Think how many more people could be web developers if you could build a real useful web application by just dragging and dropping open-source components and putting them together.
This wouldn't make the job of current web developers obsolete, you would still need everybody in this room and everybody who works for you to write Web components. But we would need a room 10 times this size to fit all of the people who would be using those applications.
A whole new level of abstraction would create a whole new type of web developer, which I think it's a tremendously exciting idea. Then you add to that mix, WebAssembly.
Like I said, it's still very early days for WebAssembly. But you could bring every useful library from all of those other package repositories, and pull them into the same unified library of open-source. You can make them all interoperable with no performance hit and suddenly, not only is it easier to build apps in JavaScript than any other language, but you can do more stuff in JavaScript than you can do in any other language because you can do everything all of the other languages can do.
And the last piece of the puzzle is all of those native app developers.
They are already nearly half of us.
You can take highly performant rich web apps and then you can run them anywhere you like. You can run them on desktops, on phones, on tablets, on watches, on VR headsets, on your shoes, wherever the hell you want.
JavaScript running everywhere, absorbing every other language into a single unified world of open-source components built by an everexpanding and increasingly diverse community of developers. There is no guarantee that this will happen. But I can imagine a world where the thing that we have grown up calling web development becomes just the way that we build all software. And after 23 years of watching the Web grow, no time has been more exciting than right now to be involved in web development.
And you, my friends and colleagues in this room are perfectly placed to become part of that change. The Web is an amazing force for good and for evil. It is a toy, and it is a tool.
It is a playground and a marketplace.
It is ultimately amazing and terrifying and its power. We can do as web developers so much good and so much harm, depending what we choose to build. But I choose to believe that in the long run, we are going to collectively decide to do more things that help the world than hurt it.
We've all made mistakes that have hurt people in the past. I know that I have.
But I believe that in the course of time, our good decisions will outweigh our mistakes and that the Web will grow forever.
I hope that what I've shared with you today, has helped you see where you are and what you can do. I hope that's helped motivate you and I hope that helped make you curious, and I hope that you have a great conference today. Thank you all so much for your time and attention. (audience applause) (upbeat music)
