Organize according to network information
“Node is too hard to use now!” . When Ryan Dahl, the creator of Node.js, set out to develop an interactive data analysis tool for JavaScript early last year, he couldn’t help but complain about the technology he’d created a decade earlier.
Ryan Dahl wanted to design an ipython-like interactive command line tool for data science analysis, but instead use JavaScript, which could perform a variety of data analysis, statistical calculations and data visualization soldiers like Python. Rayn Dahl, who had left the Node.js development community for a while, went back to node.js to develop a new data analysis tool he had invented, but it was getting awkward and he started thinking about ways to improve Node.js.
Node.js was first released by Him on November 8, 2009 at the JavaScript community JSConf Europe conference. It brings browser-side JavaScript technology into the domain of server-side applications. Front-end web engineers never thought they could be back-end engineers, but Node.js has changed the world of front-end engineers by taking front-end technology beyond the browser and making it possible for front-end engineers to become full-end engineers.
This server-side JavaScript framework has been in its 10th release since Ryan Dahl designed it in 2009. Along with Node.js, NPM, a JavaScript package management tool designed by Isaac, has become a must-know technology for web developers. More than 600,000 Node.js modules are registered in the NPM repository. This allows Node.js to be used for all types of development or software needs.
JavaScript is the most popular language, while Node.js is the most popular framework
According to Stack OverFlow’s 2018 Developer Survey (which polled over 100,000 developers worldwide), JavaScript is the most popular technology among developers, with nearly 70% using it, higher than HTML or CSS. Node.js is the most widely understood framework, with 49.6% of developers using it regularly, a slight increase of two percentage points from 2017. Meanwhile, the number of developers using node.js continues to grow, well ahead of Angular (36.9%). This is precisely because Node.js is a technology that both front-end and back-end engineers can use.
Node.js is not only the current mainstream technology, but also the key technology for the next generation of Web application architecture Serverless architecture. Christopher Anderson, Microsoft’s senior principal software engineer in charge of the Azure Functions project, said that mainstream serverless services are betting on Node.js because of the rich ecosystem of JavaScript tools, In addition, Node.js is lightweight, easy to spread out and scale horizontally, and easy to run by various operating systems, making Node.js a framework with no server service preference, which makes Node.js more suitable for large-scale deployment applications.
Ryan Dahl himself admitted that he never thought Node.js would have such an impact. He also credits the development community for continuing to improve, allowing it to mature. As of August 2018, Node.js has more than 2,000 developers, with more than 500 updates in the past 10 years. The code has been downloaded over 1 billion times on GitHub, and even large tech companies like PayPal and top scientific institutions like NASA use it.
But Ryan Dahl began to leave Node.js in 2012 and moved to Go, Rust, and math applications, where he was good at. In 2017, Dahl applied for a one-year residency at Google Brain as part of Google’s brain research team. As a deep learning engineer, and invested in the research of image processing technology. It wasn’t until early June 2018, just before Node.js was ready to turn 10, that the JSConf Europe conference again invited Ryan Dahl to give the opening talk.
Despite its popularity, Node.js still has top 10 technical debts
Ryan Dahl originally planned to share his IPython interactive data analysis tool in JavaScript at his 2018 JSConf talk, but as of May, the tool was still not working. Ryan Dahl, who was about to skip the talk, decided instead to share some of the problems he discovered when he went back to Node.js last year. The talk was titled “10 Of my Biggest Regrets from Node.js.” In his talk, Ryan Dahl admitted that Node.js had ten design mistakes, and even regrets.
The mistakes that Ryan Dahl regretted included not using asynchronous Promise objects in JavaScript, underestimating the importance of security, using GYP for Build systems, switching to FFI instead of following community advice, and, He also feels that Node.js relies too much on NPM functionality (it’s a mistake to build in package.json support) and that it’s too easy to use require(“”) to embed arbitrary modules in package.json The misleading concept of modules (making developers think that files in the same directory are the same module), the bloated and complex node_module design, and the development community’s long complaint about the download black hole (NPM takes a long time to download), the require(“module”) feature does not require a.js extension Exhibition title, and useless index.js design.
Ryan Dahl left the Node.js community in 2012. He later explained that node.js was on track and achieving his original goals, so he decided to leave, but in this 2018 talk he admitted that node.js still had a lot of problems to fix, so now that he’s back, To pay off the technical debt of the year and fix node.js design errors.
Ryan Dahl’s answer was to create a new server-side JavaScript runtime environment, the Deno project.
Deno opened its doors on Github in May 2018 to March this year, with more than 100 developers participating, including five core developers who regularly contribute code.
Top 10 Node.js Tech Debts that Ryan Dahl regretted
-
Promise objects that are not handled asynchronously by JavaScript
-
Underestimating the importance of safety
-
Gyp was used to design the Build system
-
Instead of following everyone’s advice to provide FFI and continue to use GYP
-
Over-reliance on NPM (built-in package.json support)
-
Too easy to require(” arbitrary module “)
-
Package. json creates the wrong module concept (files in the same directory are the same module)
-
Bloated and complex node_module design and downloading black holes (NPM often takes a long time to download)
-
The.js extension is not mandatory when require(“module”)
-
Useless index.js design.
How can Deno fix the legacy of Node.js design
This is an example of the Deno project, an implementation of the basic Unix command cat. Cat takes a file from standard input and sends it line by line to standard output. This example reflects Deno’s intention to abstract and simplify I/O.
Ryan Dahl wanted to create Deno, a new server-side JavaScript environment, to address the three main issues of Node.js: accurate I/O interface, Secure by Default, and a decentralized module system. The last one is to solve the old problem of downloading too long and too slow.
Ryan Dahl further explained that although he spent all his time developing in compiled languages such as C++, Go or Rust, he still had something he needed to do on a regular basis that required dynamic scripting. Such as collating data, coordinating test tasks, deploying server or client environments, charting statistics, setting Build System parameters, or prototyping applications.
However, these tasks require switching between different scripting languages or tools, such as Bash, Python, or Node.js, which can be quite troublesome. A setback in the development of the interactive data analysis tool in the first half of 2018 gave him the urge to have a universal scripting tool.
Deno architecture
Create a simple, easy to use universal script tools
“I don’t like to have different tools for different things,” Ryan Dahl said at the Annual JavaScript Developers Conference (JSDC) in Taiwan in November 2018. “I just want to have a simple, direct executable, handy tool, and that’s why WE built Deno.”
In short, Deno uses Chrome’s JavaScript engine V8 like Node.js, but uses TypeScript, a stricter JavaScript syntax specification. Deno is a TypeScript Runtime. The first Deno Runtime was implemented in Go, but Ryan Dahl redeveloped the Deno Runtime in Rust to avoid the impact of using two garbage collectors (one for Go and one built into the V8 engine). In addition, the TypeScript compiler is built into the Deno Runtime.
The goal of Deno is a secure, concise, single executable file
The design goal of Deno is security, simple module, single executable file (simplified encapsulation), etc. One of the features that has been completed is that you can import various modules through URL. In addition, the preset security requires authorization when accessing physical resources or networks, and the user’s code can only be executed in a safe sandbox. Why couldn’t his most familiar Go do it? Because “dynamic languages are still needed. He emphasizes that dynamic scripting languages are an indispensable tool, especially for building a properly usable I/O pipeline.
JavaScript was the ideal dynamic language for him, but Node.js was a technology nearly 10 years old, limited by its original design architecture, and he thought it was possible to re-think the fundamental design of Node.js with features that had emerged in recent years. These include standard methods such as ArrayBuffers for accessing raw memory, TypeScript Interfaces for elastic compositions, and emerging Async and Await mechanisms. Ryan Dahl put these new JavaScipt features into Deno to design a new server-side JavaScript framework.
This time, however, rather than go back to the node.js route of putting the entire Web server into a framework, Ryan Dahl decided to create a fully functional runtime application that was self-contained and easy to carry around, rather than a complex set of directories and structures.
If you deploy Deno on a serverless service, for example, you can specify a url and start the call to the serverless service without having to upload a piece of code to the serverless platform. It can also be deployed to edge computing devices to perform small data processing tasks.
Code that does not trust the user can only be executed in the sandbox
In addition on the security mechanisms, Deno access architecture design for two layer, one is privileged core layer, the other one is no privileged user space, RyanDahl explained, it is like the design of the operating system, don’t trust the user code, distinguish between user access and the power system of the core level, the user program, Access to critical resources must be made through system calls, executed by system core programs. Deno, too, “distrusts client-side JavaScript programs and only executes in a secure sandbox.”
All processing involving sensitive resources, such as the underlying file system, requires authorization. This is the design of default security, including network access, file system write, environment variable access, execution and other sensitive actions, need authorization to execute.
In addition, Deno’s design abstracts the I/O processing so that JavaScript programs don’t have to deal with various output or input configurations, leaving the runtime to take over and not directly touching physical resources. Both simplify the various types of I/O access, both local and remote, by using the same read and write instructions, and enhance security.
Copy() of Deno is based on IO.Copy() of Deno, and BufReader() is based on Bufio.Reader. Ryan Dahl also used the Go language he knew.
Specify a URL to embed a third-party library
The third design goal of Deno was to create a decentralized module system. Ryan Dahl’s design was that Deno could embed external third-party libraries through urls, just like JavaScript. In addition, there has been a lot of integration between Deno and Rust, and even after implementing Deno with Rust, Ryan Dahl revealed that a bridge mechanism would be built so that Deno could easily use the libraries in Rust.
However, he admits that embedding external third-party libraries is one of the features that people have been asking about and worrying about since the Deno project was launched, with concerns about security issues or man-in-the-middle attacks caused by introducing external libraries through urls. “That’s why Deno is designed with built-in security to protect against threats from external third party code.”
In addition, when connecting to a third-party library through a URL, Deno will generate a third-party library in the local environment through the cache, so that the second call to the same URL does not need to download again, thus speeding up execution. Even this one references library functionality via an external URL and can specify the version, even if the version is changed, it can still point to the old version. Of course Ryan Dahl stressed that any access to the external network or downloading and writing to a local file would require authorization.
– WebGL will be supported in the future, Deno will be able to call GPU resources
One of Deno’s biggest differences from Node.js is that it will support machine learning in the future. Ryan Dahl revealed that they were working on a numerical computing add-on module. The most important thing is to support gpus, which is the most important feature for machine learning modules. “Deno will support WebGL natively in the future, allowing JavaScipt programs to call GPU resources. That was one of his goals with Deno.” Ryan Dahl even predicted that in the future TensorFlow JS could be implemented on Deno, since TensorFlow JS also uses WebGL.
Deno will target reasoning needs for small machine learning in the future
Unlike Nvidia’s CUDA, which can be used to schedule multiple GPU resources for complex machine learning training, Ryan Dahl explained that Deno wanted to provide simple enough machine learning capabilities that could be used to meet the computing needs of a single GPU, small or only requiring inference. WebGL support is sufficient.
Since Deno opened Github as an open source in mid-May 2018, there have been more than 80 developers participating in Deno until March this year, with five core developers regularly contributing code. A major effort is being made to design capabilities for the default security architecture.
Will companies finally use Deno? Ryan Dahl admits that Deno is still a long way from 1.0 and is still a very new technology. However, “wait for me for a year. If any enterprise wants to use it, please Email me and I will provide technical support.” “He said seriously.
About Ryan Dahl
On November 8, 2009, RyanDahl, the father of node.js, released node.js for the first time at the European JSConf conference, which was a surprise, bringing JavaScript technology on the browser side into the field of server-side applications. However, he began to leave the Node.js community in 2012, moving into the Go and Rust language communities, and joined Google’s Brain research team as a deep learning engineer in 2017. Now a freelance developer.
In early June 2018, Ryan Dahl presented the Top ten Regrets of Node.js at the JSConf Europe conference and introduced a new server-side JavaScript Runtime solution, Deno.