[Node Weekly #419] Node.js framework selection guide

🥳 welcome interested partners, do something meaningful together

I launched a weekly translation project at github.com and fedarling.github. IO

Currently, there is still a lack of like-minded partners, which is purely personal interest. Of course, it will also help to improve English and front-end skills. Requirements: English should not be too bad, proficient in using Github, persistent, modest, and responsible for what they do.

If you want to participate, you can either click here to view it or send an issue message to the warehouse. My blog also has specific personal contact information: daodaolee.cn

I often see people asking “What is the best Node.js framework?” on social media or in the comments section, and the answers are often very subjective, and sometimes even debated by developers. If you are looking for a suitable Node.js framework for your project. Well, that’s not going to help you much.

The sheer number of frameworks to choose from, and these subjective perceptions, can make it harder. Choosing based on the feature list of these frameworks can also be a headache, and these features are only a partial description of the framework. It would be great if you had a clear checklist for evaluating and selecting Node.js frameworks.

I can’t give you an exhaustive list because every project, team, and developer has different needs. However, I do have some guidelines to help you think about what’s important to you when choosing a Node.js framework.

Thanks to the following friends who shared their thoughts on Twitter when choosing the Node.js framework: Matt Hinchcliffe, Alex Wilson, Alexey Antipov, and Anthony Bouch.

How do you use it?

Everything is based on the actual situation. Before you start looking for a framework and its capabilities, identify the requirements. This will help you determine if the framework is designed to support the functionality you expect. If you don’t make it clear in advance, you may find yourself in conflict with the framework when building your application.

Here are some things you might want to consider:

• Full stack applications and apis. Does your application serve HTML pages or an API that sends JSON responses? If it’s an API, is it REST based or GraphQL based?
• Server rendering. Do you plan to use React or Vue components in your projects? Some frameworks provide helper programs to simplify the process of integrating these frameworks into your projects.
• Serverless. Will you deploy your application to the Serverless platform? Cold start times are really important for Serverless platforms like AWS Lambda. If the framework requires a lot of initialization before it can process a request, it can have a big impact on your request response time.
• Instant messaging. If you want to use WebSockets, look for built-in framework support, or community maintenance libraries that integrate with the framework.
• The Typescript. Do you want to develop projects in TypeScript? Some frameworks are designed for TypeScript only, some provide type definitions, and others only provide third-party types maintained by the community. Even if you don’t plan to write your code in TypeScript, your code editor may provide useful hints based on the framework’s type definition.

Frame style

Some developers like the “out of the box” framework, others don’t. “Out of the box” refers to functions beyond HTTP request/response processing and routing. This might include features such as authentication, logging, authentication, database abstraction, and dependency injection. Frameworks in this category often impose restrictions on how projects are built. They require you to develop in a specific way so that you can take advantage of the functionality they provide.

At the other end of the spectrum you’ll find some of the simplest frameworks. They tend to provide only HTTP request/response processing, routing processing, and no integration of other functions. They are not particularly opinionated and give you the freedom to structure the project as you need it. Since they provide a limited number of “out of the box” features, you need to select and integrate other packages to provide additional functionality.

It’s more balanced if you have a framework. They have their own ideas and provide additional functionality beyond the basics, such as logging and validation. The style of framing you choose can be guided by the use cases I mentioned above. It may also depend on your personal preferences (or the preferences of your team). You may not have any preferences yet, but it helps if you pay attention to the style of each framework.

Support promises and Async/await

With node.js and ECMAScript, applications designed around the callback pattern have disappeared. Instead, we can now happily develop with Promises and async/await. This means that it is important for the Node.js framework to be promise-enabled. They should allow you to write async route handlers and handle uncaptured Promise rejections for you safely.

If the framework does not meet these basic requirements, it increases the risk of memory leaks or crashes in your application. I wrote an in-depth article explaining why this is important and what to look out for.

The document

First of all, is the framework you’re looking for documented? ! Without documentation, it can be difficult to develop projects using frameworks. Avoid using frameworks without documentation. Once you are sure that the framework is documented, try to understand the documentation quality. Not all documents are the same, so consider the following:

• Can you use it easily? The structure of the document is really important. It also helps a lot if there is a built-in search function.
• Does that make sense to you? There may be a lot of documentation, but if it’s poorly written, it won’t help much.
• Do you think you can use documentation for development? It’s one thing to read and understand how to do something, and quite another to apply it yourself when building a real project.

demo

When learning to use frameworks, reading long documents can be overwhelming. If there are practical examples available to show you how to use it, it will help you get started with the framework once you have a general idea of what it does. The “Hello World” example might show you the basics of how to use the framework, but that’s usually not much help if you want to do something more complex. Real life examples will show solutions to real problems you might need to solve. Ideally, they will also demonstrate “best practices” for using that particular framework.

You’ll probably find actual examples in the framework documentation or examples in a folder in the project’s GitHub repository. Some frameworks even have full demo examples on GitHub, where you can browse, run, and pick them up. Seeing how the people who created the framework use it is a great way to learn how to use it yourself. Rather than just honing your way through documentation, practical examples will help you speed up your learning curve with the new framework.

Communities and ecosystems

The community that exists around the framework is really important. The most important thing is to know where to go for help when dealing with unexplained bugs. See if the framework you’re considering has a comment area, Slack, or Discord server. Get to know and feel the community. Did the people seem warm and supportive? Are they receptive to contributions? The community around the framework may not be important to you on day one, but you’ll definitely need it in the long run.

Frame popularity isn’t everything, but you’ll build your entire project around it. So it’s especially important to look at how the framework is currently being used by other developers. If a framework is widely adopted, it is easier to find surrounding libraries (such as middleware or plug-ins). It may be fairly simple to replace one library with another in your project, but frameworks are usually not the case.

Stars on GitHub are often cited as indicators of popularity, but I think it’s better to see them as a measure of general interest rather than actual usage. An easy way to determine if the framework is being used by other developers is to look at its package downloads.

They can’t be used to measure how many projects are using a framework — many frameworks are bundled with other libraries but not used — but they can give you an idea of whether a framework is widely used. You can view weekly downloads on the package’s NPM page, and NPM Trends shows the package downloads over time. It also allows you to compare packages.

System robustness

When choosing the framework to build your project, you want to ensure that the project will be up and running and will continue to be maintained for the foreseeable future. Here are some indicators that can be used to assess:

• The Releases. Some developers argue that if the framework is already “fully functional,” it doesn’t need a new version, but security updates and bug fixes are necessary. There is always the possibility of significant vulnerabilities in the framework (or one of its dependencies). It is wise to avoid any frameworks that are not maintained and are no longer released.
• Issues positive degree. The maintenance personnel have not responded to many questions recently, indicating that the project may not be under maintenance. On the other hand, if no one asks questions at all, it might indicate that the framework is being used very poorly.
• Pull request. An ongoing project usually has some recent pull requests. Many old or inactive suddenly open pull requests may indicate that the project is no longer being maintained.
• Contributors. If a framework has only one or two contributors, it may indicate that there is not much community around it. If these contributors exit the project, it also poses a risk to the long-term maintenance of the framework. A sustainable project will have many contributors, adding changes large and small.
• Rely on charts. The more dependencies a framework has, the greater the risk, and the more difficult it is to troubleshoot problems in a project. You don’t need to find a zero-dependency framework, but you should have some understanding of a framework’s dependency graph. The tool NPM Graph gives you an excellent overview.

conclusion

As it turns out, there are a lot of things to consider when choosing a Node.js framework. However, there is one last thing you may want to ask yourself when evaluating a framework: Do you think you would enjoy developing projects with it? Personally, if I don’t enjoy using the framework, it becomes a chore every time I need to use it. The best choice is a framework that meets your needs and that you enjoy using. Choosing a Node.js framework can be tricky, but hopefully the guide I’ve shared will help you refine your framework selection list. May you choose the “best” framework for your project!

A link to the

Guidelines for choosing a Node.js framework