karin: I don't understand why you're using template literals for this

Template literals was really weird for me at first sight, but I guess we can wait the lib to be fully develop to see how the community will adopt it. It’s really nice from @vaheqelyan to make a lib like this, it’s a experiment to see if we can make more stuff using template literals or not.

Before you go, its worth considering a couple of things.

Functionally equivalent does not refer only to performance, which I assume is what you are referring to when you say ‘heavy’. My intention was to refer to the capabilities of the two options, which have the seame end result.

Performance optimizations will be introduced as needed or desired by the overall community, and often times, worrying about performance differences at this level is a waste of time. Extra 10’s of miilseconds on one vs another wont be noticed which is why no one writes super optimized JavaScript code. It would be horribly difficult to read and maintain. We use all kinds of slower syntactical solutions to improve readability.

@StoneCypher if you disagree with this library, don’t use it. I don’t think it’s a good idea to be shooting down new and interesting open source projects like you are. If you have complaints, cite your sources or show some evidence, because as of right now, you’ve only spoken your opinion on the matter. This idea is intended to be an easy, interesting, and quite readable implementation of HTTP requests. If @neurotrack-matt is right in saying 10’s of milliseconds, then this is perfectly reasonable, based on the fact that a typical GET and especially POST request will take quite a bit longer than a couple dozen milliseconds. Yes, this might not be the ideal library for you if you’re creating a very data heavy application, but I don’t believe that is what the creator of this library intended on it being used for.

Actually, after running some tests comparing functions to template literals, they seemed to be comparable in speed.

One really great value of tagged template literals, IMHO, is the ability to interpolate arguments within a context, i.e. the template string. This is incredibly useful if you need to do something with those arguments.

If all you’re doing is toString()-ing and concatenating values in the template string, you don’t need a tagged template function and probably wouldn’t write one, you could just pass the value in like doThing(`cool ${story} bro`).

that’s nice. the issue is closed. i’m sorry that i wasn’t able to explain why it isn’t okay for a library to use a mechanism where the results can be different between browsers. please don’t tag me to argue again. thanks.

your tests are bad

speed isn’t the issue. you can get different results between environments. this is a correctness problem.

stop reopening this.

Template literals are functionally equivalent to a function. What they offer is syntactical sugar, which is if course fairly subjective. The persuit if making code easier to read is fairly noble and I hope this project does well.

@MrFranke This library is just an idea.

There’s no benefit, and a significant correctness defecit.

There are great times for template literals. I use them in my state machine library.

However, if something can be done equally well with a function, and if the expense of the parse-and-scan and code differences from locales don’t buy you anything, using them is generally a bad idea

I’ll go away now

Template literals are functionally equivalent to a function.

No, they very much are not. What goes into a template literal comes from a string scan and parse, which is both very expensive and will deliver different results under different locales.

.

and tagged templates are syntactic sugar around what you’re saying

Tagged templates are not syntactic sugar around functions. They’re a significant heavy facility on top of functions.

Syntactic sugar does not mean “is made out of.”

.

being explicit about them allows development tools to analyze them.

No development tool that I’m aware of analyzes template strings but not functions.