Express author TJ said goodbye to Node. js and rushed to Go, tjnode. js

Express author TJ said goodbye to Node. js and rushed to Go, tjnode. js

First, this is a Farewell Node translated from TJ. js. After reading this article, I have indeed suffered some impact, but I do not agree with some of the author's views, such as I think Node. js package register is one of its many advantages, but Go is a little lacking in this regard. Due to the limitation of personal skills, there are many issues I don't understand during translation. I also asked some questions on the author's blog and stackoverflow and got answers. There are still many inplaces for translation, hoping to get some comments.

PS. As a beginner of Node. js, I would like to thank corner stone for its efforts.

Body:

Farewell to Node. js

Leave the Node. js Field

I have been working with Node. javascript has been fighting for a long time in production. Unfortunately, since I no longer like this job, at least at this moment, this is my formal farewell. More importantly, I need maintainers.

Node is really good in some aspects, but it is not a suitable tool for the software type I am interested in recently. I still plan to use Node as a website, but if you are interested in maintaining any project, you only need to leave a message to write down your Github username, npm username, and project name to let me know. Generally, only you do not need to completely change the existing api. If you really want to do so, it is better to re-open a new project.

Koa is a project that I will continue to maintain. (WITH Co and friends)

The Holy Grail story

I have always loved C, but everyone engaged in C Development knows that it is valuable but error-prone. It is difficult to prove the language choice in daily work because it is not completely the fastest job. Conciseness is also the reason why we always praise it, but you will not go far without a large number of templates.

With the development of more distributed systems, the trend of higher availability and robustness of Node performance has become increasingly frustrating for me. In the past week, I have used Go to rewrite a relatively large distributed system. It is robust, has better performance, and is easy to maintain, because the synchronization code is more elegant and easier to develop, it has better testable coverage.

I am not saying that Go is the Holy Grail. It is not perfect, but it is an excellent answer for many languages that exist today. As more and more "Next Generation" languages such as Rust and Julia find their place and mature, I am sure we will have more great solutions.

Personally, I am very excited about the Go language because of its iteration speed. I am very excited to see that they are eager to reach version 2.0, and according to what I have heard, they are not afraid to break the original great things. If it is true, I would like to, more because I believe that if it is really beneficial to this language, it should quickly break the existing things. But I am not a software giant running a large number of systems. : D

Edited: I mistakenly interpret some submitted email lists, and they are not eager to make some destructive changes at any time. @ Enneff

Why Go?

If Node is effective for you and you have no need to worry about it, it is still a good tool. But if something is bothering you, don't forget to jump out of your box to see what else is out of the box-within hours of using Go to build a product, I have been attracted.

Again, I am not saying that Go is definitely the best language and you must use it. However, it is very mature and robust for its age. (Generally at the same age as Node ). Type refactoring is interesting and simple. Go provides great job and debugging tools, and the Community has very powerful regulations on documentation, formats, benchmarks, and api design.

While getting so accustomed to extremely modular nodes and experiencing Ruby rotten standard libraries, when I first heard of Go, I thought its standard library was bad. After going deep into this language, I realized that most of the standard libraries are necessary at this stage, such as compression, json, IO, buffered IO, and string operations. Most of these APIS are well defined and powerful. It is easy to write the entire program simply by using these standard libraries.

Third-party Go packages

Most Go libraries look very similar. Most of the third-party code I have used so far is of high quality, it is difficult to find these in Node because JavaScript attracts developers at different skill levels.

For Go packages, there is no registration center, so you usually see 5 or 6 identical packages at the same time. In some cases, this may cause some confusion, but it has an interesting side effect. You must carefully review Each package to decide which one is the best solution. Node usually has standard packages such as "redis", "mongodb-native", or "zeromq", so you will find that they are the best one when you stop there.

If you are doing some distributed work, you will find that the impressive concurrency basic data type of Go is very helpful. We can get similar things through generators in Node, but in my opinion, generators is only half done. There is no independent error handling and report stack, even if it is better, it is still ordinary. When these solutions work well, I don't want to wait for three years for the Community to restructure.

In my opinion, Go's error handling is outstanding. If you have to consider every mistake and decide how to do it, Node is great. However, Node failure occurs in:

You may make repeated callbacks.

You may not get lost in the unstable state of callback at all (for example, if you forget to pass the error processing callback, Node will swallow this error without any feedback)

You may get an out-of-band error.

Emitters may get multiple error events

The handling of events that forget errors will destroy everything.

I often don't know What to handle errors.

Error handling is very redundant.

The callback is corrupted.
In the Go language, when my code ends, it ends and you cannot re-execute it in the statement. In Node, This is not certain. You will think that the execution of a program is complete until a library calls a callback multiple times unexpectedly, or the handlers is not cleared correctly, and then the code is executed again. In actual production code, it is quite difficult to find these reasons. Why bother? Other languages won't let you go through these pain points.

Future Node

I still want Node to do well. Many people invest heavily in it, and it has such potential. I think Joyent and the team need to focus on availability-if your application is vulnerable and difficult to debug, refactor, and develop, performance is meaningless.

In 4-5 years, we will still have this ambiguous Error "Error: getaddrinfo EADDRINFO", which tells us where the Node's development priority is. It is understandable that when you focus on building the system core, it is easy to miss these things. I believe that users have repeatedly expressed their opinions on such things, but have not seen any results. We usually get a few responses to claim that what we have is already perfect. This is not the case in practice.

Streams is interrupted, callback is not easy to use, errors are vague, tools are not easy to use, Community regulations are available, but they are scarce compared with Go. Even so, I may continue to use Node for some specific tasks, such as creating webpages or some scattered APIs or prototypes. If Node can fix some of its basic problems, it has the opportunity to maintain relevance, however, when there is another solution with higher performance and higher availability, the arguments with higher performance than availability will not go too far.

If the Node community decides to embrace generators and implement them in the very core of Node, it is possible to pass errors appropriately to make this a reference. This will thoroughly improve Node availability and robustness.

The good news is that I recently talked to the amazing and talented guy who contributed core code in StrongLoop. They are making it explicit to listen to developers' replies to this platform and plan to find the correct way to fix these problems to make the future Node easier to work on. I'm not sure how many companies will end the conflict with the core part of simultaneous development, but I hope the developer driver will win.

This does not mean that it is an attack on the individual. many talented people are working with Node or on Node, but it is no longer a part of my interest. I have experienced a great time in the Node community and met some really interesting people.

The implication of the story is not to be restricted by your own circles! You may enjoy programming again if you look at something else. There are a lot of amazing Solutions out there. My mistake is that it takes too long to play with them!

Nodejs express Problems

A webpage should have only one
Problems with nodejs express framework Installation

If you execute the express command line, you need to do the following:
This is what npm install-g express-generator @ 3 Officially says on github.