• Interview with Ryan Dahl, Creator of Node.js
• By Ryan Dahl
• Translation from: The Gold Project
• This article is permalink: github.com/xitu/gold-m…
• Translator: Hoarfroster
• Proofreaders: Chorer, Zenblo, Lsvih

Authorized wechat official account: used in front of morning reading class, including but not limited to editing, marking original, etc.

A conversation with Node.js founder Ryan Dahl

The introduction

Ryan Dahl is the founder of Node.js and an early developer of Deno’s JavaScript and TypeScript runtimes. We enjoyed the opportunity to talk to Ryan about some of his other projects and the major challenges Deno faces, learn his thoughts on the future of JavaScript and TypeScript, find out more about third party Deno ecosystem projects, and discuss if he could turn back the clock, How it will change the development of Node.js!

interview

Evrone: Your new project, Deno, has had a big impact on developers. What do you spend most of your time doing?

Ryan: I spent most of my time working on Deno! Deno is actually quite a large collection of software that we put into an executable. We are currently upgrading the Deno runtime and are also working to apply the infrastructure to commercial projects.

Evrone: You have practical experience with a variety of programming languages, such as C, Rust, Ruby, JavaScript, and TypeScript. What is your favorite language to develop in?

Ryan: I find writing Rust to be the most fun these days. It has a steep learning curve and isn’t suitable for many scenarios, but it’s really perfect for what I’m working on right now, much better than C++ — and I firmly believe I’ll never start a new C++ project again. Rust’s ability to express low-level mechanical language so simply is awesome!

JavaScript has never been my favorite language, it’s just the most common language, and as such, it can be used to express many ideas. I don’t think TypeScript is a language in its own right. After all, it’s good only because it extends JavaScript. TypeScript allows people to build bigger, stronger, healthier systems using JavaScript, and I think that’s the language of choice for my daily work.

At Deno, we’re trying to reduce the complexity inherent in converting TypeScript code to JavaScript, and hopefully this will enable more developers to use TypeScript.

Evrone: Gradual typing has been successfully added to the Core Python libraries, PHP, and Ruby languages. What do you think is the main purpose of adding types to JavaScript?

Ryan: The success of adding types (like TypeScript) to JavaScript far exceeds what has been done in Python, PHP, or Ruby. TypeScript is a typed JavaScript language. A better question is: What is preventing the JavaScript Standardization Organization (TC39) from adopting TypeScript? Standardization is done slowly and carefully by design. They are first working on a proposal to make types-as-comments, which would allow JavaScript runtimes to enforce TypeScript syntax by ignoring Types. I think eventually TypeScript (or something like it) will be introduced as part of the JavaScript standard, but it will take time.

Evrone: As a respected VIM user, what do you think of modern Code editors like VS Code? Are they friendly to older developers?

Ryan: Everyone I work with uses VS Code. They like it, and I think most people should use it.

I continue to use VIM for two reasons.

1. I’m very familiar with it and can code quickly with it. I enjoyed the working experience on SSH and TMUx and enjoyed the tranquility of the full screen terminal.
2. It is important for software infrastructure to be text-based and accessible through simple tools. In the Java world, developers make the mistake of associating the IDE too much with the language world, resulting in a situation where people are actually forced to use the IDE to write Java code. By using simple tools, I can ensure that my software doesn’t needlessly rely on the IDE. If you try to use grep instead of jumping to definition, you’ll find that too much indirection to jump to definition is unbearable. For what I do, I think it leads to better software.

Evrone: The Deno runtime shows possible ways to fix long-standing issues like dependency management, security, and more. Do you want it to be like Haskell for experimentation, or do you want to use it as a best practice option for something?

Ryan: Don’t mistake novelty for experimental. Deno is definitely practical and builds on years of experience with server-side JavaScript. My colleagues and I are committed to building a functional dynamic language runtime. Our design choices around dependency management and security were very conservative. We could easily have introduced another centralized system similar to NPM, but opted for a linking system based on Web standard URLS. We certainly could have opened various security holes in the file system and network more easily, but instead we chose to manage access as carefully as a browser.

Deno is new software — which makes it inherently unsuitable for many use cases. But Deno is also a large Rust code base with strong speed, reliable and successful CI management, and regular scheduled releases. You said this was an experiment! This is not an experiment!

Evrone: In 2020, most software developer conferences have become “online” and “virtual.” Have you tried this new format of meeting? What do you think of that?

Ryan: I have, but I’m avoiding online meetings right now. For me, the best part of a meeting is the “corridor”, which is a key missing aspect of online meetings. I prefer to watch speeches on YouTube twice as fast in my free time. Hopefully I’ll be able to attend some non-virtual meetings later in 2021.

Evrone: The idea of dispersing dependency diagrams from one file to a single source file is embraced by Webpack and praised by many developers. But dependency management was challenging, and it took years for Node.js to migrate from common.js to ESM. What is the main dependency management problem you would like to solve with Deno?

Ryan: The browser is not using any CDN to distribute JavaScript. The decentralization of the web is its biggest advantage, and I don’t see why this can’t be used with server-side JavaScript as well. Therefore, I want Deno not to rely on any centralized code database.

Evrone: Python and JavaScript are competing over who is the best general purpose programming language for new developers to learn. What do you think of that?

Ryan: Scripting languages are great for beginners. Essentially, Python and JavaScript are very similar language systems, with different syntax and slightly different semantics. JavaScript is governed by an international standards board, runs everywhere, is an order of magnitude faster (compare V8 to Cpython), and has a much larger user base. For some areas, more Python libraries are available, especially in scientific computing. What novice programmers want to develop varies from person to person, and Python may be appropriate. But overall, I think JavaScript is a better language for getting started.

Evrone: The asynchronous concurrency paradigm with a main thread and small handler callable objects is one of the cornerstones of Node.js. Now, this idea has been further advanced with the new Async/Await syntax and the concept of coroutines. As a platform author, what do you think of them and their available alternatives, such as Go Goroutines or Ruby thread-based concurrency?

Ryan: OS threads don’t scale well to highly concurrent applications. Do not use Ruby if you have many concurrent connections.

Goroutines are easy to use and deliver optimal performance. Like Go, Node and Deno are built on non-blocking IO and OS event notification systems (epoll, kQueue). JavaScript is essentially a single-threaded system, so a single instance of Node or Deno typically can’t take advantage of all the CPU cores on the system without starting to create new instances. Node/Deno is the best choice for JavaScript, but in the absence of other requirements that might favor JavaScript, Go is ultimately a better choice for highly concurrent systems.

Evrone: With so much competition, how do you see the future of JavaScript and TypeScript, especially as it relates to the back end, embedded, and machine learning (ML) areas?

Ryan: Dynamic (or “scripted”) languages ** are very useful. Programmers often solve problems that are not cpu-bound. The problem is more due to time constraints. Being able to develop and deploy quickly is even more important. Among dynamic languages, JavaScript (plain or typed JavaScript) is the most popular and by far the fastest. In the future, I believe that the only dynamic language we will pursue will be this strange, evolutionary language derived from a web browser. With Deno, we are trying to remove barriers and apply JS in places where it is rarely used, such as in machine learning. For example, we might add WebGPU support to Deno to allow for simple out-of-the-box GPU programming, which would eventually enable systems like TensorFlow.js to run on Deno.

As mentioned earlier, dynamic languages have their limitations and are not suitable for all problem domains. If you’re programming a database, it’s best to do so in a language that gives you the most control over your computer, such as Rust or C++. If you’re writing a high-concurrency API server, it’s hard to imagine a better choice than Go.

Evrone: Modern operating systems and the new Deno runtime introduce sophisticated permissions to offset the security risks of third-party software and dependencies. But is it possible for end users and developers using dependencies to make the right decisions about “allowing” and “denying” application security requests? How do you think about the risk in a few years of automatically clicking “allow everything” as most of us do now with website Cookie “security confirmations”?

Ryan: Cookie pop-ups aren’t the best analogy — they’re pretty useless legal byproducts. Even better is a built-in dialog box that says “Allow this site to access your camera” or “Allow desktop notifications” or “Allow this site to view your location.” These are not useless, these are very important security features.

Programmers run many different automation programs on computers, and no one has time to review all the code they’re going to run, and not enough to run all the code in a Docker container: When you run Lint, are you isolated? No, the answer is that you must trust that a Lint script will not break your system. I think it’s appropriate to allow users to view and deny unnecessary system access.

Evrone: The new “full stack” concept has pushed developers to write both front-end and back-end code, and it’s now much easier to use the same language and a shared technology stack like TypeScript. Do you think it’s a good idea for many developers to incorporate so many different things into their daily work?

Ryan: Reducing complexity is always good. The fewer languages, VMS, frameworks, and concepts the programmer must interact with, the better.

Evrone: How do you plan to handle versioning of the TypeScript language itself? Within the Node.js ecosystem, JavaScript syntax updates using the V8 engine often result in certain packages not working properly.

Ryan: The TypeScript language is almost fully functional. Users who rely on the most advanced language features may experience unstable situations, so please do not do this.

Evrone: What do you think about good education for software developers? Do we need “science” (like “computer science”) with all the math, algorithms, and data structures, or do we need something else?

Ryan: People who want a career in programming should go to college and study computer science. Of course, you can get a degree in a related field (e.g., electrical engineering, physics, mathematics); There are many very capable engineers who don’t have a degree at all. But there are real benefits to be gained by spending years learning the basics and doing a lot of very difficult experiments.

Evrone: Do you have any favorite third-party Deno ecosystem projects that have been implemented?

Ryan: Yes, of course:

• A React framework
• Network frameworks such as Express
• A Web-based GUI for desktop applications
• Puppeteer (same as the manipulator in Node)
• Visual module diagram
• Minimal but flexible static site generator

Evrone: With social platforms like GitHub, it’s now easy for individual developers and large companies to use open source and contribute. Do you see this as a “golden age of open source,” or do you see some underlying problems?

Ryan: It’s definitely open source now, and the licensing situation is well known and resolved. There are still unresolved issues with the incentive model for maintenance, and perhaps GitHub sponsors are helping in that direction. It’s better than it used to be, but I hope we can find a way to make it possible for people who maintain important parts of the software to be independently paid for their work.

Evrone: Deno has been around for a while now. What are the main technical challenges of the project?

Ryan: A lot of things in the works: We’re building a binding to the Hyper Web server, which will provide HTTP 2 and potentially be much faster than current Web servers. We’re building the DENO LSP, which provides the language server protocol so that VS Code (and other ides) can interact directly with deno for syntax highlighting, type checking, formatting, etc. — expect the next editing experience to be much better in a few months. We’re trying to get through as many Web platform tests as possible — so, over time, Deno will become more Web compatible. Check out the Q1 roadmap for more details.

Evrone: Our classic time travel question: If you could go back in time and give your younger self one piece of advice just starting out on Node.js, what would it be?

Ryan: In Node’s early days, I wasn’t sure that asynchronous IO would be easy for novice programmers to use on large projects. I went around giving speeches making this claim, but I wasn’t sure how to solve it. If I could go back in time, I would promise myself that it would work. I also tell myself that Node is going to be a critical part of the software, and that large software projects require different concerns than small ones: budgeting, communication, organization. I would tell myself to spend more time on these meta-problems.

Evrone: Any advice for developers who want to support Deno through an NPM package?

Ryan: Use the ES module and look at our Node compatibility layer.

conclusion

We were excited to speak with Ryan to learn more about his life, ideas and plans. At Evrone, we often use Node.js to build custom solutions for our customers. Thanks for reading!

If you find any errors in the translation or other areas that need improvement, you are welcome to revise and PR the translation in the Gold Translation program, and you can also get corresponding bonus points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

Diggings translation project is a community for translating quality Internet technical articles from diggings English sharing articles. The content covers the fields of Android, iOS, front end, back end, blockchain, products, design, artificial intelligence and so on. For more high-quality translations, please keep paying attention to The Translation Project, official weibo and zhihu column.