Discussion on: How to build your own React boilerplate

[Harry]

Why the promise wrapper around Express? Is this so necessary?

[Nick Karnik]

Your observation is correct. It is not necessary. However, no matter how small your project, you should always focus on code quality and reusability.

Here are some of the advantages when using promises:

1. It reduces the need for nested callbacks

2. You can chain .then calls (after both .then and .catch) and pass values through each one of them

3. You can pass the promise object around your code and use method chaining

4. Most importantly, you can use the async-await keywords with ES7 to write cleaner code

Hope that helps.

[Harry]

I'm well aware of the benefits of promises - when used correctly they can really aid maintainability. Especially when used with async/await.

Everyone's used to normal express though -

const express = require('express');
const app = express();
app.listen(8080);

Wrapping something simple like this in a promise harms maintainability. It's something that a Dev inheriting a project just doesn't expect.

[Nick Karnik]

If the 'hello world' approach works for you, then, by all means, use it.

I would not make a broad assumption that "Everyone's used to normal express" with that code snippet.

It is not testable and doesn't provide a clean way to reliably perform any actions once the web server has started or ran into issues.

Any dev inheriting a project should not be making assumptions without reading the code.

If you think wrapping it in a promise harms maintainability, I would suggest taking courses on design patterns unless all you want to do is build toy projects.

[Harry]

I would not make a broad assumption that "Everyone's used to normal express" with that code snippet.

If you've set up express, you'll have used my example. Not some over-engineered promise wrapper.

If you're unfamiliar with express, their readme gives a very similar example, at the top. github.com/expressjs/express/blob/...

It is not testable
Setting up an app, like Express' readme states doesn't need to be. I'm confident that they test it.

Any dev inheriting a project should not be making assumptions
You are correct. But you also shouldn't be wrapping code in unnecessary promises.

If you think wrapping it in a promise harms maintainability
In this case, it does. A class for handling 3 lines of code is so unnecessary. The lines of .then() makes it more difficult to read. I'd actually suggest you took a class in writing maintainable code. I'm happy with the quality of my code, and my employers agree.