String interpolations vs util.format

[vilimco]

I think that we should define this and what are we going to use.

I have seen that on some project that util module is being used for string formatting, which is exact equivalent of PHPs sprintf function.

console.log(
    util.format("some text %s, and some number %d", 
        stringVar, 
        numberVar
   ) 
);

While it has its benefits, like never used %j format, this was written while there were no native string interpolations in nodeJS. Something more natural for the JS world are native string interpolations being used in following format.

console.log(`some text ${stringVar}, and some number ${numberVar}`);

I get that we are used to sprintf format from PHP, but I would go propose that we go with something that is native and ditch util.format. While we pull one less dependency that way, it really looks a lot prettier and less bloated.

I am ok with using this module in cases that require translation and we are binding specific values that just need templating or something else, but for pure logging it just looks unreadable.

What do you guys think?

[krukru]

why not both?

[jakagacic]

Thumbs up for native interpolation 👍

[vilimco]

I would like to define when we are going to use one, when another, not to have different approaches on every second project.

Here's a proposition:

• if you are logging only primitives, use string interpolation
• if you have logging of classes, jsons, etc, use util.format with specific formats

I would use util module for advanced stuff it has (https://nodejs.org/api/util.html#util_util_format_format_args).

Otherwise, toString is being called from top of the prototype chain over any object and you get exactly the same output for all primitives (but when using util.format, you have to write 3+ additional lines for the same output).

Just keep in mind, you are consoling primitives probably 99% of the time (outside debugging when you are not using formats in any way).

[krukru]

What is the performance overhead of using util.format?

[vilimco]

I don't see one that would matter (I mean, you have a function call, scope binding, string building and all those stuff that are probably less optimized than native).

The bigger problem for me is that it just isn't that readable as native string interpolations and from development process perspective I would have to decode what is binded to what template placeholder. Within context of TypeScript, information about type binding also seems redundant.

[vilimco]

And there are no online discussions about what to use and I think that is due to the fact that almost any tutorial that you can find from last two years about JS and ES6 is using native string interpolations.

[krukru]

I think your reasoning is a fallacy, but if the majority agrees on interpolation using ticks we can use this system. Interestingly enough I found out that this works

const someBar = "bar";
console.log("foo %s", someVar);

[jakagacic]

I like it because the syntax is very readable.

[bonzzy]

I prefer native interpolation, but I also think that we shouldn't make it strict because it is really a personal preference. If we are using console log in projects I personally think that it would be better if we simply wrap it in our module maybe and use the same module across projects. That way we could agree on using our module, and inside the module whatever. PS I recommend that we use some advanced logging modules and not simple console log, for example winston

[krukru]

We recently started with our own implementation of a logging service based on yii2 logger. I see now that winston is basically the same thing + it supports profiling. We will continue this in #11.

So what do you propose how do we phrase the rule for string interpolation.

a) You MUST use native interpolation b) You SHOULD use native interpolation, you MAY use util.format or derivatives c) You MUST use native interpolation for some cases, you MAY use util.format for some other cases

I would obviously vote for b) and my least favourite is c)

[jakagacic]

+1 for b

[vilimco]

I am most for c, but I can live with b :)

[bonzzy]

+1 for b I don't like messing with personal preferences 👍

[krukru]

Agreed, we roll with b) If anyone has the time to merge this rule into the docs that would be great

[bonzzy]

Where are we with this? @krukru

[krukru]

Waiting for someone to write this in the docs

[krukru]

OK, will update