 Anyway, thank you very much for coming. I'm not Dave Ings, as it says in the program. I'm Michael Dawson, IBM's community lead for the Node.js community, and a contributor and developer. And we have a great panel here today, and we're going to talk about the state of Node.js. I'll let our panelists introduce themselves. So maybe we'll start with Trevor at the end, since you've got a mic. Yeah, hello. My name is Trevor Livingston. I am a principal architect at HomeAway, which is an Expedia subsidiary. Previous to that, I came from PayPal, where we did Node.js at scale. And we're doing the same thing over at HomeAway now. I am Tracey Lange, notification community manager for the Node Foundation, last part of the Lange Foundation. Is that it? Maybe we just need to be closer. Is that better? Oh, thanks. I think so, yeah. I can just talk real loud. It's been about two years since the foundation came together. And just wanted to get your opinions on, you know, what you think is working well, what's not working so well, and, you know, sort of where we're on, where we're going to lead us off on that one. Sure. I mean, when the foundation was first started, the immediate question was, like, how do we work? It happened relatively quickly. I mean, it was definitely a line during the process. Doing that work would probably double the number of procedures in the project as well. So we had a lot of kind of new sale problems. We had an LTS policy that was just created. And a lot of that stuff was kind of a movement. I mean, we've taken some ideas. The final version that actually worked everything together was version four of what they asked. And we've just recently put that in the maintenance mode. Now we've been out of LTS, right? So we kind of looked back at, like, a full cycle. And that's all worked out really, really well. I mean, adoption of the node has continued to double every year. But most importantly, you know, adoption of new releases of the node is really good. And it continues to get faster every time we do a release. And every time we do, you know, a new LTS line, we see adoption skyrocket again. So we can kind of say pretty different than those policies they work. They really do encourage adoption. And that having, you know, a fast pace of initial development really gathers more commuters because now we have, like, over 100 commuters. So yeah, we know that all of that kind of stuff is working. I think that when your community is growing that quickly and the contributors are growing that quickly, you're always going to have new scale problems. You're always going to have, like, single points of failure where this person took on a responsibility because they had the time to do it. But now that responsibility is, like, three times what it used to be. And so we need to figure out how to break that responsibility up into more people and bring up new leaders and all that kind of stuff. So I think that there's always something that's not working in the project. The important thing is that there's a process of re-evaluating what isn't working and changing it and fixing things. Right. And I think, you know, your key point there about bringing up new leaders is one of the really important things, like how to bring up new people and enable them to help out in those areas. Yeah, I think the key for me that I've seen in coming up with Node and sort of its maturing is collaboration and sort of understanding what that means, but that means within the technical group with companies coming together and coordinating efforts through the foundation of Node and then people working together in the ecosystem as well. Even with you think about the idea of the fork with I.O. and those collaborators coming back into the fold with the companies that they needed to come to a neutral standpoint with. It's really interesting to see the challenges of Node growing as a community and ecosystem and the scale that we're operating at now and how every portion of the project has to find new ways to work together. It used to be that we would have single owners of areas of even the technical project and it's an awesome blessing that we're not having that bus factor anymore but that also means that then multiple people have to work together and it's interesting to think about how large the Node project is and how we could still have single owners on those things and we're trying to fix that because that's important to not have that bus factor. But yeah, getting everyone to work together in that and even looking at things like how we're working so much better together with the V8 team at Google because we rely on a lot of upstream so it's really important that we have been able to focus on that so that's exciting for me that we've seen that coming of age and that's sort of the new era with us I think in the maturity of Node. I don't really have a lot to say other than that it's been a night and day difference. It's amazing to see how quickly things have progressed since the fork has merged back in and as Michael was saying, the number of contributions that have gone up has been fantastic. It's almost too fast at times. When you work at a larger enterprise and you're trying to operationalize and you have these new versions coming out and everybody wants to get it and then you're kind of trying to hold people off so that's kind of a challenge but that's a good challenge to have. Right. I'm just wondering from your perspective, we're pretty close to the foundation and sort of getting the core run time out. In terms of more of an end user, is the foundation doing all the things that you'd like to be seeing being done or are there some things that you'd like to see more of, less of that kind of thing? To be honest, I don't have a lot of insight into the operations of the foundation. It feels like the right things are happening but it's actually really hard to say from completely outside the community because I have a lot of connections to core contributors. And so I have a little bit of the kind of insider info sometimes on things and I can also use that to sometimes get things addressed that need to get addressed. So one of the things I don't have insight into and I wish I knew more about is how people that don't have that connection are perceiving whether things are being addressed like they need, whether it's a feature suggestion that sometimes feels like a little bit of a... not really a club-based mentality but sometimes it feels like there are a limited number of people who have the final say and there may be good ideas out there and people are having a hard time getting it in. And when you have the inside track you can just kind of go talk to core contributors directly and try to socialize it. So it's hard to say, I'd be kind of curious to learn more about that from the outside. Right, okay, that's a good point. I think in general it would be nice to have more direct input from external users who aren't quite as slow so that's a good point to think about that. Yeah, I mean it gets harder every year because the community is doubling. We have about 8 million users now. So how do you get a beat on how 8 million users feel about something going in? We certainly can't just optimize for whoever happens to be the loudest in an issue. That would not be good. But we do have a fair amount of metrics, we have a fair amount of data. We can look at the NPM ecosystem and what's growing and what people are doing and we can actually respond to what people are doing. So I think a lot of the stuff that really pushed some of the recent promises work over the line is that you can see how people are using these now. You can talk to a bunch of people that are using them in different ways and go like, what are the problems that you're having? How do we actually improve this experience for you? Whereas before it was a very opinionated person that was maybe not even running the stuff in production yet. When we have this many dependencies, we can't be leading like that, we can't be adding APIs that we're going to have to deprecate in the future because they were the wrong idea. So things are getting easier. But if you just have a random idea for a feature, it is somewhat hard to get that in without just code. If there's code, everybody can evaluate it. There's a decision making process that's all there. But when it's just an idea and not code, that does get very tricky. Something that we've talked about, I think in some of our community committee conversations, we'll talk a little more about that I think later, but is the concept of, if you think about our project almost, it's not a product, but if you think about it in the sense of like, how many people we need to support, then sort of from a customer support angle, we do need to start moving forward at how we can help support all of those people. Like, do we have easy getting started? Are they easy to find from a search perspective? Are we supporting them or are we expecting the ecosystem to support them? Do we have active chat channels? Other companies are adopting channels other than IRC for their customers being able to reach out. Our customers or users or developers need to be able to have ways to do that. But we also can't rely on our core contributors to answer all of those questions because otherwise then they're also not able to work on their code because it's too many people. So sort of like trying to solve that problem moving forward is a really interesting one. Yeah, that's a really good point too. So one of the things Trevor mentioned was the releases that are coming out. So we just had Node version 8. We have releases. That's our biggest win from these days. We have releases. So we just had Node version 8 come out. So I thought I'd, you know, see what you guys thought about it, your favorite features. I know which one mine is since I worked on it, but get your input on what you like about what just came out and what you're most excited about. So maybe Trevor, if you want to start? Yeah, I think that my own favorite is the rewrite of async hooks or async listeners or however you want to call them. But I know that that's still experimental, but I think that's going to be really promising. I know firsthand kind of the problems that something like continuation local storage can cause in software. So seeing an opportunity to potentially improve those things, improve the performance, I think we're going to see a lot of wins across the board in areas where we need to use those kind of things. So I'm a little bit hesitant and it's maybe not a feature that I'll personally use a lot, but I'm hoping that we see some improvements that come out of that. I think one of the other ones is, you know, and I think that is a common favorite is async await. I'm not a huge fan of promises myself, but I know how well it helps transition new developers into Node. And I think that that's just one of those things that that little extra syntax sugar gets people excited and they feel like they can ease into it a little bit more easily. Yeah, I think I'm going to echo the point of the promises looking forward to more promises support. So you told I'll promise if I, I think it's my favorite from a technical standpoint. And what a challenge I think it was to make that happen, but also that it represents us making sure that a lot of people are taking care of if they want that option. And I think that that was a really important win. And then I'm also going to throw in another win. I think that was really important to call out that NPM 5 being rolled up release wise with Node version 8 was a huge win in terms of us understanding how much it takes to coordinate and collaborate. And I don't think we'd had a major release coordination like that since the early days of Node. And that's when the leader of NPM and Node were the same person. So it was pretty easy to coordinate. So it's just, you know, that in itself, I think is it shows us that it can be done. It's not that we need to be doing that regularly, but I think it's really going to concrete, you know, a good year for us moving forward. Yeah, I think that along with your comment about the, that along with your comment about the, you know, the closer relation relationship with the VA team really shows that, you know, as a community, we're making good strides in building those bridges. So that's, it's a really good thing. So on that note, I think, so my favorite feature is, is that the native API finally landed in some form. So that's, I mean, in literally, you know, the first week of I OJS, we started to try and repair and create a better relationship with the VA team. And that's only gotten better. In fact, every time that I'm at any conference, I get to say the relationship with VA is better than it's ever been because it's only gotten better from that point on. But I think that this is where the foundation really went out by coordinating an effort between Microsoft, Mozilla, Intel, IBM and Google to not only create this native API, but for all of the existing VM developers to say, we're going to support this indefinitely. Doesn't, this was an argument that we had, you know, before the fork, which is, you know, Node can say whatever it wants is, is it's native API. It could make that up a ton of times in the past. But if the VMs don't say that they're going to support it, then we're going to eventually have to break that API. It's not actually going to be stable. Because we know from experience that the VM APIs are just going to alter themselves enough that we're going to have to make some kind of breaking change. We've seen this with Nan, right? If you were to go into the code base, if you were to send a PR to Node, and it was like the best feature that anybody had ever heard of, but it required 30% of the users of Node to go and intervene into their project and do something, that feature would never land. But we do that every major release, because every major release we have to take a new API from B8. Finally, we can kind of see a light at the end of the tunnel now where eventually we will stop doing that. We will stop breaking 1% of the packages in the ecosystem that are native, that are transitively depended on by 30% of the ecosystem. We will actually stop breaking those, right? We can ensure a level of stability that we haven't before. And I think as good as our numbers are right now for people adopting new releases of Node, it's going to go up even further, because now there's just no barrier to updating, right? Being part of the group that's been working on that, it's really good to hear the excitement. The other thing that I found interesting, it's a little too early to name names, but there's been a few people from outside the Node community that have been looking at the API as something that they might want to use for their languages as well. So I find that that's really interesting. It's like, hey, maybe it'll be a problem, an API that solves a broader problem, or Node, which is really a good thing as well. I've run into a lot of Java developers at this conference, so I think one of the things maybe it would be good to touch on is what kind of advice we have for people who are coming from other languages and want to get into Node.js, how to get started, some of the issues that maybe they're going to run into, and just basically what advice you guys would have on that front. Tracy, do you want to start with that one? Sure. So the first thing, I think, with Java or .NET developers, who are coming from other languages, especially those types are, they're used to awesome IDEs, tooling that allows them to get up and get going very quickly. And we have that with Node and JavaScript now. We didn't have that so many years ago. But Eclipse, IntelliJ, Atom, Cloud9, VS Code, which is awesome. All of those have really great Node support and much better than they used to be. So that's really easy to get up and started. And you're also really used to good documentation. That is something that we are still struggling a bit. But that's also because our language is very small. So we rely a lot on our ecosystem. And the documentation in the ecosystem, especially if you look at all of the packages in the NPM registry, a lot of them have really good documentation. And you can, I find that you can also rely on our community, which is a big part of being, you know, being able to write this language that people can recommend really good packages for that. Yeah. And there's also a lot of good courses. So you have the advantage if you've already written another programming language that you understand a lot of the constructs that we're operating under. There are some unique ones that you have to think about that might be different, like threading or streams. They might be a little different than the language that you wrote previously. But there are really good courses on, like Udemy, as well as Free Code Camp. And Westboss, who is prolific in the JavaScript community, has a really good node course as well. And that's hours and hours of concepts that are going to make sure that you really have the JavaScript pre-rex down to understand what you're doing with your node. So. Trevor, again. Yeah. I would second everything that Tracy just said. I think that the tooling has come a long way and it's been pretty fantastic. Most Java developers, I actually, myself, a reformed Java developer. I've programmed Java for about 15 years. And then once I picked up JavaScript and started using Node.js, I never looked back. I don't think I've written Java since. But one of the things that was challenging for me at the time was tooling and the kind of immaturity of the project at the time. Also, really common concepts, things that are really the most important is just how the runtime works. It's one of the fundamental things that you need to grasp before you can actually do anything. And I think that that's missing and from a lot of education. People tend to educate based on the language and the language is the easy part. JavaScript is not a very complex language, but understanding the Node.js runtime and how the event loop works and those things is really, really key. So grasping those concepts makes it a lot easier and avoids a lot of common mistakes that you'll make jumping just from, you know, a multi-threaded language to a, for all intents and purposes, a single-threaded runtime. So at the foundation, we've talked to a lot of enterprises that are going through digital transformation. If you have that buzzword on your enterprise bingo, you're welcome. But it's interesting to talk to them because it's rarely just that they adopted Node. It's also that they adopted a bunch of new workflows and a bunch of new ways that they managed their team and a lot of new ways that they write their code. And one of the things that I've always been really skeptical of is, you know, taking the entire workflow that people do for Java development and then just replicating that on top of JavaScript because you skip all of that, like, nice reforms you have, right? But you do sort of throw the baby out with the bathwater sometimes. Like, there are some really nice things in there that would be nice to have. And it's nice to see some of these tools come along, like TypeScript and FlowType, that replicate a lot of the things that people miss but don't completely change the entire workflow, right, and integrate in the same way. I think another good example of this is, like, Visual Studio versus Visual Studio Code. It is amazing. It's not an IDE. It's an editor with every feature that you ever wanted from an IDE in your editor, right? It doesn't have, like, the entire kind of build flow and all of that stuff, but it does have, you know, amazing, you know, introspection intelligence and all of the features that, you know, if you, like me, have been using an editor forever, you always did kind of wish you had from an IDE but you didn't want to take everything else. And so we're in this really interesting place now where you can actually, you know, adopt JavaScript, adopt Node, get a bunch of the things that you like, but also, you know, really kind of reform some of your workflows and so that you can write code a little bit faster and be a little bit more nimble as a team. Okay, that's great. Right, so, you know, I think we've talked a little bit about where we're at today. I'd be interested to hear, you know, what you think the most exciting and interesting things are going to be that happen over the next year or so as we move forward. So, I don't know, Mike. Mike, do you want to start with that one? A year from now. So, Node, well, Node's already in space, so I can't go there. Yeah, oh, wow, that's a good one. I can't really predict where the native API is going to go. I think, so for a long time, I was sort of expecting that a platform would come along and supplant Node. Like if you've been around long enough, you see new languages come up and other ones die and all that. And a couple of years ago, I started to look at the kind of market share numbers and think, like, I don't know, that might not actually happen. There's a lot of good languages that have come out since then, but they just haven't gotten the kind of traction that Node has. And then I started to think, well, maybe that's not what you should be looking for. What you should be looking at is, what is the layer that people live in when they write their application? And that will probably be something that's not Node. Maybe it's built on Node. Maybe it's something entirely different, right? I think that there's a lot going on right now in the web to try and make it easier to share HTML components, CSS styles. Like in Node, we have this amazing amount of reusability, and you can take a module from five different people and use them together, and those people never knew each other or coordinated, right? This is not the case in HTML components. Like no matter what framework that you're in, you have to integrate these into your application. But a lot of the stuff going on in web components actually give us some primitives that we need to abstract that. And then you can start to imagine a platform where at the same level of authority that you have JavaScript modules, you have HTML components. You actually have a module system and a compatible ecosystem there. And it's kind of unclear what that looks like. I think Webpack is getting kind of close. It's just that right now there's 12 people with opinions about CSS modules, and it supports all of them, right? And that's not a layer of compatibility. But I think that we're nearing it and the further along that the web standards get the closer that we're going to get to this kind of standard. Yeah, I think something we haven't really mentioned that's being worked on and has been worked on is HTTP2. Shout out to James Snell, who's doing a lot of that work, amongst other people. So that's, I think, going to be really exciting. I think people are watching that, and we get a lot of engagement from that when people are speaking about it at our events. Yeah, I mean, I think it's still more, I'm interested to see where the promises conversation goes because I don't think anything that we do in Node related to promises is going to be easy to adopt. From the technical group perspective, it is still very contentious. A lot of the people I feel like in the CTC as well as the TSC are not super excited about promises, but that chip is sale and they understand that it's still needed, right? The option is still needed. So I'm excited to see where that goes, and also ES modules. I still think that that's... What happens with that and when it chips is going to be interesting, but we still are waiting to see. And then from a community side, I think we're still seeing where the community committee can best be used, and we'll talk about that in a little, sorry, as well as how... Yeah, as well as the community committee can best be used. Yeah, as well as... I'll just talk about it. Okay. So how the community committee is going to be collaborating with the TSC and the board, and the community committee in Node is a relatively new thing. It was chartered back in February, I believe, for final adoption, but this isn't really something that's common in code projects, and that is community given a top-level voice. So in most projects governance, you have a technical steering committee of some sort. If it's a foundation, you also have a board which is in charge of the business aspects, and then you have this whole ecosystem contributing in various ways, but in Node, we're finally recognizing that there are serious technical contributions, but that the community itself, the ecosystem has very much been bolstered by all of these things that are outside of the scope of our technical steering committee, but also need a voice in how the project moves forward, and that's from a technical and from a social or cultural perspective, because so much of that is sort of like being in a workplace. You can try and ship a project every week. You're working on this thing together, but are you? You can't work together if you can't collaborate if you're not getting along. If you don't have the ground work where everyone is enjoying themselves, they're going to go elsewhere. There's a lot of programming languages. So we want to lay that ground work for making it a more pleasant place for the people who are already there, so they'll stick around and to get more people involved who are really excited about programming and maybe they want to help us. So that's really a big effort this year is figuring out how we can all help. It's sort of not land grabbing for things that are already in existence that need to be worked on, but it's saying we have so much room for more people to come in and help out from every part of the project. You stole HTTP2 from me. I'm also very excited about that. One of the other things that I'm really kind of hoping for is just generalized improvements or continued improvements in crypto because that's always been kind of a thorn in the side of Node.js development. It doesn't affect everybody, but I think that in the future, as we want to become more secure, it's only going to become more relevant. And it's going to be something that everybody's going to be doing crypto pretty soon. So as we continue to try to become more secure and do perfect forward secrecy and all these things, we need performance enhancements there. So I'm really hoping to see that. I think there are people working on it, and there's been amazing improvements over the years anyway. I think that Node 6 was just a massive improvement in that department. Then the other thing is just kind of coming from the ecosystem is that we're seeing such amazing tooling, and I think that's really exciting. I'm really curious kind of where it's going to go. We see all these major APM vendors like Dynatrace and AppDynamics supporting Node as a first-class citizen. Their tooling is continually improving. I think that we're going to see a massive explosion there. We've got nice tooling like Insolid as well, which is a runtime on top of Node. So I'm really kind of excited about that. What I'm concerned about is the complexity of application development. So you have all these great technologies out there, but often what's required is just gluing them together. And as that, you mentioned web components, but today when you have an application that's using React and Redux, and has GraphQL in there, and it's doing isomorphic rendering, and if you look at a typical application just even a simple one, they're incredibly complex, and that's a huge barrier to entry for people who are trying to learn. If you just do Node.js module development, it's super fun and easy. Once you get into application development, it's no longer that thing where you're like, oh, look how easy it is. That was one of the big kind of exciting things about writing JavaScript on the server side also was you could show it to people and they'd say, oh, that's so easy. I can be so productive. And now when you build a really modern web application, it's not quite the case anymore. So, I don't really know what the answer to that is, but what I'm hoping to see in the next year is that something that gets kind of under control either through better frameworks or better standards. Okay, thanks. I think we just have a few minutes left, so maybe we can see if there's any questions in the audience at this point. The Node.js certification. What's the status plan? I know that's Tracy. Yes. So, we're still actively working on putting together the infrastructure between the different groups that are working on that with the LF as well as with Hacker Inc, which is the environment that we're actually going to be running the certification in. That's an experiment between us, between the Node Foundation and Hacker Inc, which I think is really exciting because it means anybody can take it around the world, almost instantaneously. It's a very quick setup. We don't have to worry about provisioning in the same sense. We're still able to plug up our proctoring layer to make sure that people are who they say they are when they're taking the exam and also not cheating. So, that's helpful to make sure that we're having a legitimate exam that's still offered in browser and you don't have to go to a location to be able to take it. That was really important. And we can also have language support. So, we'll be able to have it in multiple spoken languages down the road very quickly, which is lovely because we have a very global community and we are looking for Q3 release. So, yep. Any other questions? Okay. Well, thank you very much. Thanks a lot to you guys on the panel. Those were always really great and insightful answers and questions. And thanks to everybody who came out and spent the time to listen to us and we hope to see you again soon.