shtylman

Can you hoist the `if (result)` into the `try` part of the statement? (Without seeing more context hard to know why that wouldn't work for you).

Another pattern to avoid the above is to remember that async functions return promises and that .catch() also returns a promise. So your above logic can be written as:

  const result = await funcThatReturnSomeType().catch(doSomethingWithErr);
  if (result) {
    doSomething(result);
  }

Personally I find SQL much easier to read. In a product where you might allow users to write queries it is a much more pleasant UX experience to write and read SQL than it would be to do so for ES queries. It isn't a problem to understand how to build an ES query object but an ES query object is pretty terrible to read IMO.

It is none of their business why I needed my money or how many trips it took.

the future is now

Duplicate dependencies affecting client side "size" is highly overrated. We can make tools (and have tools) that can compare files for same content and only include them in client side bundles only once. De-duplicating the same could should be a tooling issue. If I want to use client side modules that depend on two different versions of the same library I should be able to do this. Disk space is cheap and we can do the rest via post processing.

Systems where people seem to live under the assumption that if they don't get the latest patch updates or security updates their code will somehow be inferior and they will instantly be hacked. They think that semver will magically solve the problems of having to keep your application dependencies up to date if you want the latest changes/features/fixes.

Pinning in development is equally necessary if you hope to bring sanity to your development team all using the same codebase. Not pinning may be great for a one person 'team' or modules where you control everything, but can be a major time sink when one person is seeing a bug in a patch version they have and another developer is not seeing the same bug because they are on a newer patch. Allowing developers to "clone" consistent versions of the codebase is as important as deploying consistent versions to production.

Why should they reconsider it? Someone that just got into development and might want to show their friends or family something they are hacking away on. According to you they now need to learn about VPS, some random nginx settings or other SSH nonsense and meet some arbitrary "minimal" criteria you have decided upon because that is how you would do it. I think you should reconsider your acceptance of people that don't share your same technological expertise.

To me the ease of having the library be installable with the "canonical" package manager of my platform is too convenient; just "feels" more natural and simpler. I actually thought about writing a node.js ngrok client but then gave up on the idea since localtunnel was working well enough and I personally didn't need the other features from ngrok which I didn't have in localtunnel.

I wouldn't worry about the whole rewrite in c thing. If your server protocol is simple enough, writing clients in the native languages will be better than writing bindings. Installing bindings trips up a lot of users that are not used to compiled software.

You can. See the README.

The fix for this is to use a module. Simple. Not a problem.

The generator example has no error handling (at least not from what I can see).

Once the "callback hell" example was re-written with named functions, it is not much different than the generator example and depending on how you are testing, easier to test because it separates out IO from logic (Which you could still do in the generator example).

One thing callback style code has begun to make me think about is the nesting/IO complexity of the functions a I write. When you nest, the IO/event boundary is visible in the code (by the indentation). As you continue to nest, you can start to get a clear idea of the amount of IO being done and where a particular function may be doing too much. Anyhow, most of this is preference anyway :)

I'll get the medic.