Express author TJ says goodbye to node. js and goes

S.  . As a beginner of node. js, thank TJ for his efforts and good progress.

Body:

Say goodbye to the Node. Js

Get out of the node. js realm

I've been in production with node. js for long enough, and unfortunately, now that I don't like the job anymore, at least for the moment, it's my official goodbye. More importantly, I need the maintainer.

              Node is great in some ways, but it's not the right tool for the type of software I've been interested in lately. I still plan to use Node as a site, but if you're interested in maintaining any projects, just leave a comment with your Github username,   NPM username, and project name to let me know. Usually all I'm asking is that you don't completely change your existing API, and if you do, start a new project.

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

The story of the grail

I've always loved C, but everyone involved in C development knows that it's valuable and error-prone. It is difficult to justify a language choice in everyday work because it is not entirely the fastest work. Simplicity is the reason it's always appreciated, but you can't go very far without a lot of templates.

The more involved I became in distributed systems, the more frustrated I became by the trend toward Node performance over availability and robustness. Over the past week, I've rewritten a relatively large distributed system with Go, which is robust, better performing, and easier to maintain, with better testable coverage because synchronous code is generally more elegant and easier to develop.

              I'm not saying Go is the holy grail, it's not perfect, but it's an excellent answer for the many languages that exist today. As more and more of these "next generation" languages like Rust and Julia find their place and mature, I'm sure we'll have more great solutions.

              Personally, I'm excited about the Go language because of its iterative speed, excited to see them eager to reach version 2.0, and from what I've heard, they're not afraid to break the great stuff. I'm happy if it's true, more because I believe that if it's really good for the language, it's time to break things up quickly. But I'm not a software giant running a lot of systems. : D

              Editor: I must have misinterpreted some of the submitted mailing lists. They were not eager to make any disruptive changes at any time. @ enneff

Why Go?

Node is still a great tool if it works for you and you have nothing to worry about. But if something is bothering you, don't forget to jump out of your box and see what else is out there -- I was hooked in the first few hours of using Go to build the product.

Again, I'm not there to say Go is definitely the best language and you have to use it. But for its age, it is very mature and strong. (about the same age as Node). This type of refactoring is fun and easy, the jobs and debugging tools provided by Go are great, and the community has very strong rules on documentation, formatting, benchmarking, and API design.

              Having become so used to Node being extremely modular and having experienced Ruby's rotten standard library, when I first heard Go, I thought its standard library was terrible. As I got deeper into the language, I realized that the vast majority of standard libraries are now necessary, such as compression, json, IO, buffered IO, string manipulation, and so on. Most of these APIS are well defined and powerful. It's easy to write an entire program just by using these standard libraries.

Third party Go packages

Most Go libraries look similar, and most of the third-party code I've used so far is of high quality, which is hard to find in Node because JavaScript appeals to developers at different levels of skill.

              There is no registry for Go packages, so you will usually see 5 or 6 of the same packages at the same time. In some cases, this can be confusing, but it has an interesting side effect that you have to carefully review each package to decide which is the best solution. Node usually has canonical packages such as "redis," "mongodb-native," or "zeromq," so you'll stop there and infer that they're the best one.

              If you're doing some distributed work, you'll find Go's impressive concurrency base data types helpful. We can get something similar by taking a line in Node, but in my opinion, a line is only half way there. Without independent error handling, the reporting stack is trivial at best. I don't want to wait three years for the community to rebuild when these programs work.

  In my opinion, Go's error handling is outstanding. Node is great in the sense that you have to consider every error and decide what to do. However, Node failed in:

You may repeat the callbacks

You probably don't get lost in the unstable state of callbacks at all.

You may get a takeaway error

Emitters may get multiple wrong events

Forgetting the handling of the wrong events can ruin everything

Often unsure of what needs to be handled incorrectly

Error handling is very redundant

Callbacks suck
In Go, when my code ends, it ends, and you can't reexecute it in a statement. This is not certain in Node. You would expect a program to be fully executed until a library accidentally calls a callback multiple times, or fails to clear the handlers properly and causes the code to execute again. Finding these reasons in actual production code is pretty hard, so why bother? Other languages won't put you through this pain.

The future of the Node

              The fact that we will still have this ambiguous Error "Error: getaddrinfo EADDRINFO "in 4-5 years tells us where Node's development priority is. Understandably, it's easy to miss these things when you're focused on building the core of the system. I think users have expressed their opinions on this kind of thing over and over again without seeing any results. We usually get a few responses to claims that what we have is already perfect. In practice, this is not the case.

            Streams are broken, callbacks are not easy to use, errors are vague, tools are not working well, and community rules are there, but they are scarce compared to Go. However, I may continue to use Node for certain tasks, such as creating web pages, or for a few loose apis or prototypes. If Node can fix some of its basic problems, it has a chance to stay relevant, but the argument for performance over availability doesn't go very far when the alternative is higher performance and higher availability.

  If the Node community decides to embrace the roots and implement them at the very heart of Node, to pass errors appropriately, there's an opportunity to make this referential. This radically improves the availability and robustness of Node.

              That doesn't mean it's an attack on an individual, and a lot of really talented people are working with Node or on top of Node, but that's not what I'm interested in anymore. I had a great time in the Node community and met some really interesting people.

              The moral of the story is, don't be trapped by your own circle! See what else is out there, and you might enjoy programming again. There are a lot of great solutions out there, and I made the mistake of waiting too long to play with them!