Transcript
Moderator: We have a great selection of panelists here to talk about the future of JavaScript. Gordon, whose talk was just on, that you might have seen, talking about fantastic devices and JavaScript. Eoin, who's going to be talking about serverless later. Katelyn, who's going to be talking about running third-party JavaScript. Miguel, who's going to be doing his quantum phasing in act later on.
I want to get started with the developer experience around JavaScript. One of the reasons I moved to JavaScript from Java 10 years ago, was for the developer experience, you got immediate feedback. You didn't have to wait for your code to compile. If you remember, 10 years ago, Java didn't exactly compile all that quickly. I find myself today, especially with front-end code, back in the same situation where I'm waiting for the transpiler, or Babel, or even NPM, to download all the modules. I ask myself, how did we end up in the situation where this wonderful developer experiences, immediate feedback that you used to get with JavaScript seems to have degraded?
Gordon, because you've built stuff all the way up from assembly, do you think that the nightmare of transpiling is a phase that we have to go through until we get better support? Or are we stuck with it now as the mode of using JavaScript as a developer?
Williams: Do I think that the nightmare of transpiling is a phase that we have to go through until we get better support or we are stuck with it now as the mode of using JavaScript as a developer? I would hope that it's just a phase. I think one of the issues is that the benefits you get from running through a compiler and being able to actually type-check your code, for the bigger projects, in a way, that far outweighs a lot of the other trouble you'd get.
Debugging
Actually, it does seem an older phase that effectively debugging has got more or less completely lost in lots of cases and for a lot of people. Having a debugger adds so much productivity to your programming. Also, not only a way to avoid errors but avoid making the same error over again, and learn things that aren't working the way you hope. Also, for performance as well, if you don't really know what your code is turning into in the browser, then that's a really bad sign.
Moderator: We've all got bitten by that for sure. Eoin, your background is actually similar to mine. You started off in the Java world, or you actually have a computer science degree unlike me. Where do you think this is going? Are we stuck with this transpiling now?
Shanaghy: Are we stuck with transpiling now? Yes. Definitely I'd agree. I think we're definitely stuck with it. I do see it as a positive. Ultimately, we're at the early stages of evolution of the tooling. That's such that the transpilation time is slow. That's something that's going to improve.
ES Build
I tried a recent development called ES Build, which is a native transpiler written in Golang, which is significantly faster than any of the alternatives. I think that's ultimately what's going to happen because the benefits are there. You need it. You want to ensure that the code sizes, particularly for browser applications, are going to be small. Not just for browser applications, actually, but for serverless applications, too. You're always trying to reduce the code size and do bundling. You need to have a solution for it.
Moderator: You think we're stuck with it and you think the solution is, swallow our pride, and go with Rust or Golang as the tooling?
Shanaghy: Do I think we're stuck with it and the solution is go with Rust or Golang as the tooling? Yes, absolutely. You don't have to build every JavaScript tool in JavaScript. Those benefits are enormous.
Front-end User Experience
Front-end development has always been hard, actually. The user demand on front-end experience is just getting bigger and bigger. It's just getting higher and higher. Users demand better user experiences. They have to be fast, very responsive, load time is important. The bar is always constantly getting higher. We just need to improve the tooling. I suppose there was a period of catch-up when mobile development came along, users got used to very fast experiences. Then the web was caught with a lack of tooling to be able to deliver very fast responses. That's where webpack, and Babel, and everything that you're complaining about today comes from.
Moderator: Katelyn, how do you feel about this fact that the code you see in front of you, we're just getting further away from that code?
Sills: How do I feel about this fact that the code I see, we're just getting further away from it? I know from some of my co-workers' experiences in TC39, the JavaScript Standards Committee, that there is actually a lot of work being done to make the plain old JavaScript actually work better.
Node
We've seen the ECMAScript modules being able to use Import rather than Require in Node. We've seen the experimental mode there in Node, allowing us to use that. I think basically, what we're seeing is that being able to use the type module in the webpage, things like that. We're actually getting more out of transpiling these things and squishing them down into the minimized JS, and actually being able to use the real modules in the webpage and in Node, and things like that. I think we're moving away from it. I may differ a bit. I think that's a really good thing.
Moderator: You think the browser ultimately will support us as developers so that the browser is essentially doing this work in the background for us?
Sills: Do I think the browser ultimately will support us as developers so that the browser is essentially doing this work in the background for us? What we're going to see is that standardization is going to be helping us make this transition. It's going to be on all of the hosts, all the browsers, things like that, are going to be supporting these standard module types so that it's not just that Node has its own weird way of doing things. Is that there's standardized JavaScript ways of doing it.
Moderator: Miguel, you have the benefit of coming to this world, fresh, and not having suffered all the terrible ways of developing, even going back to the '90s. I remember seeing Netscape came out with server-side JavaScript in the late '90s. I remember looking at it going, "No way am I ever going to do this?" Fifteen years later, I'm doing Node.
Without having the burden of history, what is your opinion? How do you feel about working with JavaScript, coming at it from a modern perspective?
Ramalho: How do I feel about working with JavaScript, coming at it from a modern perspective? I'll start off by saying that I've been using JavaScript for five years. I've got some also bad experience in it.
As a matter of fact, I feel that today things are getting much better. I was very used to using libraries like jQuery and other things, for instance, for development. Nowadays you have things like dollar sign that is natively supported by JavaScript, and queries, functions. Everything seems to be coming into a point where JavaScript is going to be much better than it used to be. It used to be 5 years ago for me, maybe for you it's 100 times better than it used to be. I really feel that although we have a lot of things that are building on top of things, and we are losing focus on the lower-level stuff. I feel that it's a trade-off between functionality and things that we get out of the box, and things that we can really understanding. If you really want to, I think you can still develop things in JavaScript that you understand. Of course, it's a trade-off. It's not going to be easy to get away from all the hustle of using all these languages like CoffeeScript and TypeScript. They appeared for a reason. We'll see. I'm hopeful for keeping on using JavaScript. I'm not feeling it's a burden at the moment.
Moderator: I think this is the message from the panel is that things are getting better. The question is whether we'll stick with transpiling or not. Can I call for a vote, actually? Do you want to see the transpiling tools, Babel, all that, stay as part of the ecosystem, or would you prefer for them to die away?
You can't deny that there are certain advantages to the tool. You are dealing with a language that was written in two weeks. There's always going to be gaps. Perhaps the way around this problem is to not use JavaScript at all. Perhaps the way around it is to start using WebAssembly and start using other languages. What do you think Gordon? As someone who can code in assembly?
Williams: As someone who can code in assembly, I think, for some things, it will be very useful. I would hope that people wouldn't all start using WebAssembly.
WebAssembly
My thing is that if every webpage was written in C, the web would be a very different place and would be much more difficult to use, I feel. It depends why you're going to WebAssembly. If it's as part of a bundling process where you develop in JavaScript, and then you try and you effectively do it as an optimization process before you ship as a form of minification, then maybe that's ok. If it's a tool to get something running on a web browser, that you wouldn't normally have done.
I've been at companies where you have a big black box of code that some guy wrote 50 years ago before he retired, in Fortran. No one dares change it. In an ideal world, you would change it. You'd rewrite it. You'd make it better. That's not what happens. You've got this BLOB. If it means that you can then run that BLOB in the browser, make everyone's life nice and easy, and have it running very quickly and in a user friendly way, rather than running on the server somewhere with seconds of delay between requests, then it's a big bonus.
Moderator: Eoin, you're focused more on the serverless end of things. Where does WebAssembly fit into that? It feels redundant in that context.
Shanaghy: Where does WebAssembly fit into the serverless end of things, and does it feel redundant in this context? Yes. I would say so. If you're going to write serverless back-ends in Rust, you're going to do them in Rust and compile them with native.
JavaScript
WebAssembly is really an opportunity for people who aren't comfortable with JavaScript on the client to have an alternative. I think that's a good thing, actually. I'd not like to see it become too popular, in that, JavaScript is a very productive language, gives you a lot of freedom. A lot of developer creativity. I'd like to see WebAssembly succeed, but only in areas where it's really necessary to optimize hotspots within the code base. Maybe within frameworks like React or Vue, where they have to do Virtual-DOM doffing, and therefore, you got hotspots, which necessitate some level of optimization to make applications run faster.
Moderator: That's a browser specific use case as well. Katelyn, in terms of running third-party JavaScript code, if that code has been compiled down to WebAssembly, and that's what you're given to run, surely that makes your job more difficult to be able to make sure that code is safe. Or is it easier, perhaps?
Sills: Is it difficult running third-party JavaScript code compiled down to WebAssemly and ensuring the code is safe? Yes. It does make it more difficult.
There are certain security guarantees that you get at the JavaScript language level. For instance, you don't have access to an object, unless you're given access to it. JavaScript has unforgeable references, unlike C. In C, you could try to guess a pointer, and then maybe you've actually gotten it and you can get the data at that pointer. In JavaScript, you can't do that. For Wasm, this is an area that I'm not that familiar with, but some of my co-workers are. I know there are certain JavaScript language guarantees that actually are not met at the Wasm level, if you try to bring everything down to that level. There's a proposal, I think it's called Wasm GC. Somehow this is connected to the garbage collection. I don't quite understand that. There are certain proposals that are trying to fix that. I think we're going to see if people do Wasm right, hopefully, we'll be able to maintain the same security guarantees that we have at the JavaScript level at the Wasm level. That remains to be seen.
Moderator: Miguel, the interesting thing about quantum computing, and if anybody has actually looked into it, I believe there are some really interesting tutorials that take you through the mathematics behind as well, which is something that you have to learn. The binary nature of the whole basis of our ordinary programming languages is not really appropriate. You end up with this world where you have to deal with things like Qubits. Does having a compilation target like WebAssembly make your life easier?
Ramalho: Does having a compilation target like WebAssembly make my life easier? What I will focus on is saying that when you're handling things like Qubits, usually you want to focus on using them for computation. You're writing an algorithm on top of it directly. What you can have is a phase before getting into that code that would resemble some assembly code. You already have a few things like that. In terms of trying to put both things in the same bag, I think it will be complicated, although it might be interesting in a few years. A lot of these concerns that pertain to getting good standards and getting good performance, it's a bit like JavaScript, you build something that works and then you start building on top of it. I think we should wait for me to answer that.
Moderator: You mentioned something interesting there, which is JavaScript is all about building stuff on top of other stuff that people have done. One of the most amazing things about the JavaScript ecosystem and about the Node ecosystem, especially if you were there in the early days, was the phenomenal growth of NPM. How it completely took off. Before that, you had CPAN, and you had various other artifact repositories. The Node one just took off and went completely crazy. You got hundreds of thousands of modules, most of them quite bad. Most of them had security flaws. We've had all sorts of interesting things happen with developers canceling themselves, and completely removing all their code, or code being maliciously taken over.
We now have this really difficult dynamic where it's very easy to participate as an open-source developer directly in the Node and JavaScript ecosystem. At the same time, you end up depending on hundreds of other people. Hundreds of other people end up depending on you, which raises not only security issues, but also raises issues around, as an open-source maintainer, how do you participate effectively in that ecosystem? I think it's a problem that we haven't yet solved, and which is really important to the future productivity of JavaScript developers.
This is a two-part question for each member of the panel. First of all, how do we deal with these huge dependency trees? Have we gone down the wrong path? Should we try and pull back and in some way reverse what's happened? Or should we embrace it?
The second is, if you participate in this ecosystem, do you implicitly create for yourself a burden or a responsibility to everybody else in the ecosystem. If so, if you're just doing this in your spare time at the weekend as a hobby, we've seen lots of people get burnt out from trying to be a good citizen. You have people who just open up their entire code bases, which lead to all sorts of security problems, or you have people who tightly control it, but then are working 80-hour weeks on a hobby. That's not a hobby anymore. Gordon?
Williams: How do we deal with these dependency trees? I think in terms of being part of this dependency tree, creating a huge amount of modules you're dependent on. I wonder whether, again, it's a sign of the fact that everything's moved so quickly and the tools haven't quite caught up.
NPM
Already, we've got ways for NPM to try and check for security risks. Perhaps, there are other metrics it could work on. When you're searching for a package to do a specific task, you could actually look at the number of dependencies and whether those dependencies can effectively be merged with other packages that you're using. Because, yes, at the moment, if you want to solve a specific task, you're basically Googling to try and find out that task, you find a few different packages. Then, either you try them all out, or it's hit and miss. If you had a good way of finding out something that was an efficient solution to your problem in line with all the other stuff you're using, that would probably.
Moderator: People have tried to do this, where you have some curation around the packages. One of the pushback from the community around that has been that it excludes people. If you were there, in the early days, your package is going to win. We see some interesting things happening to try and address that. Mikeal Rogers, who is one of the original Node people, wrote a module called Request, which was the first professional grade HTTP request client. He has recently completely put that module to bed. That module is now totally deprecated, and he says don't use it anymore. If you read his explanation, it is explicitly so that new modules that are better can start to become the prevalent ones.
It's not so easy I think to say, there needs to be curation and there needs to be somebody who decides what the good modules are.
Williams: No. I wasn't necessarily saying curation, but some way of actually figuring out when you're looking through a bunch of modules, programmatically what their dependency tree is like. Because often you just install one thing and you think it really should be there to provide a very simple task. If you actually look at it, it's installed 400 modules. If this goes out to a whole project, you end up with this massive tree.
Moderator: I'm not going to let you answer just yet. That is fair enough. The problem is, that's going to be true of almost every module. You still end up with analyzing a tree. This module might have a different tree to that module, but it's still a very deep tree. I don't know if that solves the problem.
Dependency Tree Security
Williams: If people care about it, and people obviously do care about the dependency trees, especially now that tools are checking the dependency trees for security issues. You're more likely to have more security issues the more modules you depend on. If you make that something that people care about when they're selecting packages, if you want your package to be more popular, then you will try and make your package dependent on packages that you will try and reduce your dependency tree as well. If you provide people the tools that they can actually see what's going on, hopefully, over a period of time, people will start to change the way packages are made.
Moderator: Eoin, to bring us back to the code's question. As an open-source maintainer yourself, and as someone who has to use a large number of Node modules for enterprise projects, how do you address this issue of having such a big dependency tree, and yet having to maintain a level of quality for your clients?
Shanaghy: How do I address this issue of having such a big dependency tree, and yet having to maintain a level of quality for my clients? The benefit of it outweighs the disadvantage. I think that you rightly say the successive Node was just ballooned with the proliferation of all these tiny modules, and small components in software are really effective. It makes it very easy to be agile in how you develop and swap in and out components, and experiment, and innovate. The benefits are there. Ultimately, I think what I'd like to see is some content security policy where I can install the module and know what it has access to in the same way that when you install an app on your phone, you have to explicitly grant it permissions to access the file system, or the network, or whatever native resource. If I deploy a Node.js serverless function, I can give it access to very specific minimum privileges in a cloud environment. At the moment, it's actually quite difficult to say, but don't give it access to the disk. Or, don't give it access to the internet, so it can't steal my environment variables, take out secrets, and post them to somebody's email account.
Moderator: I like this idea. In this way, you're effectively whitelisting what modules can do. At least one source of frustration I have, and I don't know, Katelyn, perhaps you know if this is still the case. There is a way to create an internal VM in Node itself. If I remember correctly, if you read the documentation it says, "Don't use this for security purposes." Does it still say that?
Sills: Is that the built-in Node module VM?
Moderator: Yes.
Sills: If I read the documentation, does it still say, "Don't use this for security purposes?" I don't have any expertise in that in particular. I will say that in JavaScript already, there's the concept of a realm. Each webpage that you run JavaScript in is a realm. JavaScript that operates in one webpage can't affect JavaScript that operates in another. There are a number of proposals that are going through TC39, right now, that are trying to take this idea of a realm and make it actionable for security. You might be able to create a new realm, or you might be able to create an even lighter realm, that allows you to execute third-party code safely. I think people are taking that concept and they're actually bringing it to real life and allowing people to use it.
Getting Security Right
To go back to your earlier question about the dependencies, I think the number of JavaScript dependencies that we have, and the fact that NPM has over 800,000 different packages that you can use, that's a fantastic thing. We should be proud of that. I think the fact that we can't see the entire dependency tree, that's a problem security wise. If we look at how real life works, I don't know how the bread that I had at breakfast was made. I don't know who made it. I don't know where it came from. If we get the security right, that's fine. I shouldn't have to know those things. What we have to do is we have to create the environments that allow us to get the security right.
Moderator: I think both of you actually touched on an interesting point. Because it strikes me that perhaps we should invert the problem. Perhaps it's not so much a consequence of having used JavaScript as a consequence of software development, moving towards the idea of finally having a composable architecture where you can pull together lots of small modules. Perhaps JavaScript is just the canary in the coal mine because it's so easy for us to have small modules.
If you think about the wider question, surely, this applies to all languages really, at the end of the day. In the Java world, which is the only other world which I have a great deal of experience in, that problem is solved through curation. You've had Apache, and people like that, and IBM. Those were the guys that you trusted. Speaking for myself, I still apply that mentality in the world of Node. I don't know if any of you are familiar with the Hapi.js ecosystem, and that web server? I just trust that guy and all of his stuff, and I use as many of those packages as I can. That's the way I reduce the problem space for myself. That's not optimal. I think we should perhaps think about this in a little bit of a wider sphere. Maybe this isn't just JavaScript's problem. What do you think, Eoin?
Shanaghy: This isn't just JavaScript's problem. I think we should perhaps think about this in a little bit of a wider sphere. In theory, the same problem applies to Python modules, but you don't have as many small modules in Python. It hasn't really manifested itself in the same way. I agree. It is a general problem.
Publishing Public Open-Source JARs
I think Java has solved it with Maven. It also made it very difficult. I've tried to publish public open-source JARs in the last couple of years, it's amazingly difficult how much friction there is. Therefore, people will just be discouraged from using it. I think we have to be permissive in allowing people to publish, and then encourage people to just be restrictive in how they consume. That's really the way forward.
Moderator: Katelyn, I just want to get your take on this.
Sills: What part specifically?
Moderator: In terms of the small module approach not being specific to JavaScript. This is actually a wider trend in the software world, and in particular, how does that apply to security?
Sills: How does that apply to security in terms of the small module approach not being specific to JavaScript? We've definitely seen what they call supply chain attacks, I think in other languages as well. There might have been a Ruby gem attack. Python, we mentioned.
JavaScript - The Canary in the Coal Mine
I think you're right, that we're seeing it from the JavaScript side, because JavaScript is so widely used and it has so many packages. It is the canary in the coal mine, I think. One of the great things about JavaScript is that it already has this clear separation between the pure computation part and the outside world. A lot of languages just don't have that separation. Anything that you get from the host window, or document, or something like that, you could potentially just cut off all of the access to those things. Then your JavaScript doesn't have access to the network, or it doesn't have access to the file system, or the things that are really dangerous. I've heard that Java, for instance, it's really hard to make that separation because things are too embedded. We actually have something in our favor in terms of JavaScript and security.
Moderator: Miguel, after having heard everybody. What's your take on this?
Ramalho: Are we over the edge on using modules? I think we are. I don't think that's a bad thing. What I think happened is JavaScript became something so worked on and with so many people giving it a background that it became so tempting for big companies to use it. If I use it on my personal projects, I don't think it's problematic if there's a security flaw, or at least it's not as much as a company deploying something in production.
I think it's good, but we do need some way of curating this. We need to do it in a scalable way. Because we cannot have someone go through 8,000 packages trying to find if they have security flaws, and so on. There's a need for something that's scalable, and that's a way of curating it.
Open-Source Developer
As an open-source developer, I only find that open-source developers, at this point can only do it for the community. They cannot do it to make money. You can get some incentives. GitHub, for instance, has a sponsored program now, which is supposed to give some background on it. I don't think it's working as they intend to, or at least not at this point. One other thing that GitHub is doing very well, I think, and this happens with Node modules, for each repository they say how many times this was used, or how many other repositories mentioned this one, which is also a good way of curating some things. Because you get a good sensation of how many people use it, and how trustworthy it might be, even without a standardized way of auditing for security flaws and so on.
Moderator: I think the message for me coming out of this discussion is there's a tooling gap here. It's an interesting space for somebody to step in and start helping us solve this problem.
Last question, what is going to happen to JavaScript in the next 10 years, Gordon?
Williams: What is going to happen to JavaScript in the next 10 years? I am slightly biased about it because I was brought to JavaScript because I liked the fact that it had a very clear grammar, almost like Java at the time where you could pretty much have a A4 cheat sheet of everything you needed to write code, not how to use the inbuilt APIs and stuff, but how to actually write an algorithm in it. It feels every year there's a new version with more features that in lots of cases, early on, effectively features really filled a big gap. They let you do something that you couldn't previously do. Recently, I feel features are just adding extra fluff.
Moderator: [inaudible 00:31:11] parser, don't you?
Williams: Yes. I have to deal with all these. Every year, I have to deal with all the new stuff, which is also often written without much of an eye to the people who are writing the parses. Often, it's not very efficient for parsing or very fast, which every year, it makes the compiler writer's job harder, it slows down the interpreter as it tries to parse all these potential different grammars. Yes, for me, that's a slight concern going forward is the bloat of the language past what was needed, especially as it gets to the point where a lot of people are transpiling. They're not using all these extra features really. They're just using the base that's needed, which is basically the output.
Moderator: You don't predict, you hope rather that people could just leave it alone. It's not there, stop.
Williams: Yes. I predict this could get bloated by, I really hope that could have stopped.
Moderator: Eoin, where do you think JavaScript is going to go?
Shanaghy: Where do I think JavaScript is going to go? I don't know about 10 years. I feel we've peaked in terms of JavaScript's ascendancy. I don't think it's necessarily a bad thing. It'll continue for the next 10 years in browsers for sure, but I think more people will be writing TypeScript than JavaScript ultimately.
TypeScript
It's not something I do myself, actually, very often. I like dynamic languages. I like the frictionless nature of it, as long as you're writing small components. TypeScript is useful when you've got large projects, again, which is a little bit of a red flag. Sometimes you have to do it. There are good use cases for it. I think TypeScript has been very well designed, and it's an unstoppable force at this point. The tooling is fantastic for it. I really see, just as you had the dominance of Java in the early 2000s, ultimately, other languages emerge, and it becomes more of a level playing field. JavaScript won't dominate as it has in the last 10 years.
Moderator: History doesn't repeat but it does rhyme.
Katelyn, where's JavaScript going to go?
Sills: Where's JavaScript going to go? I think we were right when we were saying earlier that JavaScript had this attitude of, you put it out there, and then you clean it up afterwards. I think we're going to see an increase in the amount of cleanup, and refinement, and learning about best practices.
Don't Break the Web
If you look at what the JavaScript Standards Committee was trying to do, their main imperative was, don't break the web. It's really hard to clean things up after the fact when you don't want to break what people are doing right now. They were able to introduce JavaScript strict mode. You could choose to put the strict imperative at the top of your file and that would enforce certain restrictions on what your code could do rather than the sloppy mode that was usual. Doug Crockford has this great book, "JavaScript: The Good Parts." You can take this very messy language, and you can extract the parts of it that are really good. You can enforce these certain restrictions on your own code and the code that you use. I think we're going to see certain parts of the JavaScript ecosystem become more refined and just really embrace better practices.
Ramalho: What is going to happen to JavaScript in the next 10 years? I'm going to have a positive view now. I think from what I've seen in the past years, JavaScript is really taking over things.
Libraries for Back-end Development
You see libraries, for instance NestJS, and other libraries for back-end development, that are completely replacing what we used to do in PHP and so on. Then you have a lot of libraries that are open-source from Google and Facebook, like React, and Angular, and so on. Those are really taking a good stance of the markets. Then you have multi-platform development, which you can do in JavaScript. Although it's not as fast as native code at the moment, I think it's walking very close to closing that gap. That's the point. You also have libraries for using machine learning with JavaScript, and quantum computing with JavaScript. The question is, what can't you do with JavaScript? If the answer is nothing, why should it stop, or why would it? I'm confident that it will stick along for the next 10 years.
Moderator: Full speed ahead, 100 miles an hour.
Would anyone like to make some comments on the future of JavaScript, or indeed any of the other points that the panelists made.
Participant 1: I'm actually from outside the JavaScript ecosystem. One thing I'm always wondering is, why won't you guys have a standard library? Wouldn't that solve a number of issues, proliferation of packages, and [inaudible 00:36:17], and curation?
Moderator: Yes, I'd love to have a standard library. What do you think guys? Gordon?
Standard Library
Williams: I think to a certain extent there is a bit of a standard library, like all the functionality in string and regular expressions.
Moderator: It's rubbish. We need more.
Williams: I don't know.
Shanaghy: How do you respond to that? Yes, I go the other way. Part of the success of it was that we didn't have a standard library, and that you had this composable set of modules around it. I've never really actually felt the lack of a standard library to be a problem. You have a lightweight core, and then you pick and choose around it. That's my opinion on it. Say, for example, you have this response then, so Golang came out with this very complete and robust standard library, and that draws a huge response. It's interesting to see how that dynamic works.
Participant 1: Left-pad, looking at that, it's not what happened.
Sills: Left-pad?
Shanaghy: Left-pad? Yes, that's true. It might be something else. I don't know.
Sills: Yes. I think the example of Left-pad is a really good example. For those of you that don't know, this very widely used package just got taken out of the ecosystem, and then everything that used that was just broken. I think that means that we need some redundancy. We're missing the infrastructure that you would actually want to have in an ecosystem like that. I think the fact that it's not centralized is actually a good thing. Ideally, what you would want is a competitive landscape of different packages that you could choose from. Maybe if Left-pad wasn't there anymore, you automatically already had a backup, or something like that.
I think it goes back to what Gordon was saying about having more information or some way of sorting through the packages so that your competitive landscape is actually an informed decision and not just, "This package looks like it'll do what I think I want. Let me install it, and let's see if anything bad happens." I think we have a long ways to go in terms of actually making the package infrastructure work correctly. I don't think centralizing all of the functionality is the way to go.
Ramalho: I would actually add that, I think it makes sense to have something of a standard library. For instance, what makes Python very successful is that it already has a lot of things you can import without installing it. I don't think you can have everything on it. You will still need to have these packages, even with a standard library. I'm not opposed to it. I actually think it would be a good thing. You still need to have some space for people that are building sometimes redundancy, or redundant things that are already in the library, for instance, because they want to focus more on performance, or something like that. It's not something bad from my point of view. It's not something that's going to make JavaScript much better than it is at the moment.
Participant 2: I think it's not a problem of the module and the ecosystem to say, there's an extra. You don't always write everything in vanilla JavaScript and write your own modules and everything. It's just that you're lazy and you just want to take a module. That's your own problem you need to take first. Then, it's your responsibility to evaluate those modules, and it's for safety and, I believe, the tendency to hear that.
Moderator: It comes down to a trade-off between getting the stuff done, but taking personal responsibility for modules that you import. That is a valid point.
Do you feel it's actually practical? As a JavaScript developer, I often feel under pressure to deliver and it feels very hard to assess the dependency tree?
Williams: Do I feel it's actually practical to get stuff done and take personal responsibility for modules I import? I think your thing about JavaScript giving you flexibility is really good. I feel it's a little bit like C, in a way, or C++. There are a million ways to shoot yourself in the foot with C++. If you are a company that's developing a project with it, you are almost certainly going to have coding standards otherwise you're going to end up with a completely unmaintainable tree. I think that's probably something that just has to happen with JavaScript as well. You have to have standards about which features you use of JavaScript and how you choose the modules you're doing. Even if only right now that's because of licensing concerns. It's very powerful. As long as you don't use everything that's available to you, you can actually produce some really good maintainable code in a very productive way.
Shanaghy: Do I feel it's actually practical to get stuff done and take personal responsibility for modules I import? I think the free lunch is over in terms of consuming modules and forgetting about them, and thinking it's the open-source maintainer's responsibility to give you perfect software. The tooling is there, actually. You got NPM audit, you got Snyk, security audits are available. You also have to do all the sensible things. Security problems are just going to increase. Multifactor Authentication on your NPM repo, using a proxy for NPM so that you've got your own artifact repository as well, they're responsibilities that we're just stuck with now. We just have to adopt them.
Sills: Do I feel it's actually practical to get stuff done and take personal responsibility for modules I import? Part of my background is actually in food safety. There is an interesting analogy here. Imagine if someone said, "You can eat the food that someone else sells you but if you really want to be smart you got to grow the wheat yourself and then make the bread. Then you got to control the whole supply chain." People would say, "That's so much work. You must be insane".
Ecosystem of Code
I think we're building up these packages. We have this rich ecosystem of code. What we need to do is add the layer of civilization on top of it. Part of that is maybe more curation, more auditing. I also think, because it is code, because it is not physical items, we have a unique situation. We can actually start out with perfect security. We can start out by putting things in the realms and the compartments that I was talking about earlier, and not allowing any authority to get in except what we explicitly grant. Because it's code, we have this unique opportunity to try to do things differently, and to actually be able to use other people's code safely.
Ramalho: Do I feel it's actually practical to get stuff done and take personal responsibility for modules I import? If you want to do an MVP, if you want to do something really fast, or if you want to compete with a startup and so on, and you're using JavaScript, it's not going to be feasible to develop things from the bottom up. I agree with you, this is the way to go. Although there are some trade-offs. There are some things you can do. There are some things as well that are going to help the situation.
Summary
Moderator: One of the really interesting takeaways for me was this idea that perhaps we have entered a brave, new world of small modules. It doesn't just apply to JavaScript. It's a universal problem that I think is going to come to all software engineering. We have to grow up and be civilized.
See more presentations with transcripts
