5 ms·

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

by mashlol 10y ago

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?

jorblumesea 10y ago
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 :)
- deleted 10y ago
  [deleted]
- jonathankoren 10y ago
  Give it up. The JS kiddies had to rediscover vendoring. Something that's been a best practice since the 1970s.
- Klathmon 10y ago
  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.
  - jorblumesea 10y ago
    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.
    - Klathmon 10y ago
      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)
sheriffderek 10y ago
I prefer writing <heading level 1> instead of <h1> :p

by mashlol 10y ago

jorblumesea 10y ago

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 :)

deleted 10y ago
[deleted]
jonathankoren 10y ago
Give it up. The JS kiddies had to rediscover vendoring. Something that's been a best practice since the 1970s.
Klathmon 10y ago
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.
- jorblumesea 10y ago
  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.
  - Klathmon 10y ago
    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)

sheriffderek 10y ago

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