Errm...

- "test".indexOf("st") == "test".length - "st".length

- "test".enddWith("st")

Am I the only one who thinks the second one is WAAAY more readable? And that's a COMMON function. Using the former is bringing complexity UP.

Not to mention, endsWith is part of es2016 I believe. So this package is just a simple polyfill.

> "test".indexOf("st") == "test".length - "st".length

I don't think this is a correct implementation of "endsWith".

"testtest".indexOf("st") =/= "testtest".length - "st".length

Good point. Should have been

"test".substr("test".length - "st".length) === "st"

Or is it substring? Might there be an off by one in there? Anyway, this kind of reflexion only proves my point. There's no reason to question what endsWith does, because it's obvious. It's the correct abstraction in many cases.

Negative substr() already does the trick, I don't see the need for endsWith() at all.

  'test'.substr(-'st'.length) === 'st'

The thing is :

1. You need to know and understand obscure behavior of substr

2. This hides the programmer's true intent. What you want is to know if the string ends with 'st', not that "the 'st'.length last characters of the string is 'st'". Why make it harder on your fellow coworkers to understand what you mean ?

If you only do this once, sure, maybe importing a whole module is overkill. But as you write it over and over again, in separate projects, having the code safely tucked away in a reusable module brings complexity down.

You can even do

    'test'.match(/st$/)

I don't see why people insist on doing all the low level shit themselves, and then still complain about "scalability" and "fitness for programming on the enterprise level".

- "test".match(/st$/)

I don't understand the problem with those modules. Just because you can do something one way, doesn't mean you shouldn't add an easier and better to understand way. The intention of `string.endsWith('Blah')` is easier to understand then `string.indexOf('Blah') === string.length - 4`. Java String has both `indexOf` and `startsWith`, do you think that is also problematic?

It's added complexity because it's not std lib. Importing an entire module just to accomplish something you could easily do with 1 line of code. I'm not arguing that javascript shouldn't have `startsWith`, just saying there's a large overhead associated for a relatively minor performance increase. Thus going back to the debate about proper engineering. Just my 2 cents, feel free to ignore :)

But it's not "An entire module", it could be as simple as one line.

I know people like to go on about how every module increases complexity by some massive amount, and how you are relying on X number of other developers and systems that can break now, but the NPM/javascript way is the unix philosophy taken to the extreme. Lots of small modules, extremely easy to use and install, that all do one thing and do it well.

There is no overhead to using a small module. It takes seconds to install, in some cases adds literally bytes to the output, and can take care of a lot of hidden complexity like defaulting to using the stdlib version if it exists, and being fully tested (because let's be honest, you aren't going to write 15 tests for a string-ends-with function).

Also, it's not as simple as 1 line of code. Look at the String.prototype.endsWith library. Look at the edge cases it supports, look at the way it does the search to be efficient. your one-liner might seem to work on the surface, but when you use it in a .apply it might blow up, when you try to get it to run on IE8 for some reason nothing works, when you go to run it on a million strings, the whole system bogs down.

There are benefits to using modules where someone has spent the time and effort finding and fixing those edge cases.

That's hardly true, because many modules have lots of unseen dependencies. For all I know, your tiny module could have refs to 3+ other modules to do its work.

Thus, getting leftpadded.

I reject the idea that the size of the module means it is not complex.

That's easy to check, it not only shows you any dependencies of dependencies (of dependencies) when you install, but it also exists in a package.json which you can easily browse.

For example, the String.prototype.endsWith package referenced above relies on 0 other packages.

Another micro-module I've used, clean-stack[0] is one line, and has 0 dependencies. (it just removes mostly unhelpful node.js stack trace entries). This is great example for me because it's just a regex. But, it's a regex that was just updated 11 hours ago because a new version of node added a new stack trace line that's not exactly helpful, and by updating this package, it will pull in that update, and I need to do nothing besides do a quick sanity check that nothing massively changed, and check that my tests still pass.

Is-reachable on the other hand (a simple module to check if a hostname is reachable), has 6 direct dependencies, with 2 more dependencies of dependencies. Altogether that module adds up to about 300 lines of code (including it's 8 dependencies).

That's not massive, that's not even much at all for a server-side system. And if that module ever goes under, re-making it would be trivial. So there really isn't much of a downside to using it (especially if I vendor my dependencies, which anyone should be doing for a production application)

I prefer writing <heading level 1> instead of <h1> :p

String.prototype.endsWith is native [0], it was added as part of ES2015. If you're supporting older platforms, you need to polyfill it.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

How well supported is ES6 across browsers? Chrome for sure. Not sure about FF or IE.

The support is quite good today, see https://kangax.github.io/compat-table/es6/.

You can transpile to ES5 if you've got compatibility issues. Not really a problem.

Transpiling usually concerns syntax. Babel won't transpile .endsWith to a polyfill for you, hence the existence of that package