251–260 of 887 posts
Good programmers understand the risks of making your system depend on something you don't have control really well; They know how keeping system complexity low is like an good investment which makes your life later easier (low maintaining costs).
Bad programmers stacks up technical debts such as including unnecessary dependencies until the system no longer works.
Earlier quoted context omitted.
With the advent of ES6 modules's selective imports and tree-shaking, that's definitely quickly becoming a better approach. With the old CommonJS modules, you need to be concerned about overall code size, which is where small, single purpose modules excel, and why this approach has proliferated to this degree.
Doea code size really matter to node.js ? And how common was commonjs (no pun intended) on the client before ES6 ? Also doesn't commonjs bundling add a significant overhead when talking 5 line function modules ?
There's probably not any overhead in bundling, though. Not in speed or memory, at least. The overhead is in the complexity: the programmer now has one more place to check for faults, and debugging stack traces now point to a bundled version of code instead of the original sources.
The case where none of this is true is when require() ends up being called thousands of times. Startup time will be correspondingly slow, and bundling is the cure. But that should only be done as a last resort, not a preemptive measure.
Going down the "lots of tiny modules" route is about these three things: a) No standard lib in JS b) JS is delivered over the internet to web pages in a time sensitive manner ... so we don't want to bundle huge "do everything" libs. Sometimes its convenient to just grab a tiny module that does one thing well. There isn't the same restriction on any other platform c) Npm makes it really easy to publish/consume modules…
Earlier quoted context omitted.
No, no, no Left padding is (almost in all languages) built-in, even C can do it with printf (edited) The problem is not having a library that offers that, but having this micro-module thing as a whole NPM module . No other language does that. If it was inside a string helpers, that's great. But don't make me one single module for just left-padding (or is-integer-number)
Uh, no Left Padding is NOT built-in in JavaScript. The proposal to add `String.prototype.padLeft()` was just added to ECMAScript 2016. JavaScript had a very minimal standard library, it's pretty asinine of you to compare it to C or any other language with a pretty extensive standard library.
Nobody has forgotten. These people never knew to begin with. NPM/JS has subsumed the class of programmer who would have previously felt at home inside PHPs battery-included ecosystem. Before that, a similar set of devs would have felt at home with Visual Basic. Seriously, go visit the comments section on archived copies of the PHP documentation. You'll find code of a similar nature. If PHP had had a module system 10+…
PHP has had an extension module repository since 1999
Compare NPM to Composer/Packagist and you get a better comparision. I've personally seen only very few micro packages on Packagist, thankfully this never seemed to gain traction in the PHP world.
In a way this shows what a great job NPM did at making it easy to publish packages. It's so easy that people decide to package up extremely easy functions. As a python developer I would never publish a small package, simply due to the overhead of setting up a PIP package.
Earlier quoted context omitted.
You can't escape problems by bundling specific library versions. You just get a different set of problems. When you require a specific version of a library, you're making your code incompatible with anything that requires a higher or lower version of that library. You're also assuming there will never be a security fix that requires you to update your dependency.
...you're making your code incompatible with anything that requires a higher or lower version of that library. Actually that's not correct when using node/npm (or anything else in the ecosystem like browserify). That is one of the impressive things about this platform: any number of different versions of the same module can be required by the same app. It would be nuts to do that in your own code, but as long as the…
Using multiple versions of the same library is code smell. It's a stability issue, a security issue, a complexity-breeder, and an absolute nightmare for packagers.
And npm allows it to happen silently.
Earlier quoted context omitted.
There's already `Array.prototype.reduce()` in most browsers, which will do summing, string concatenation, and any other kind of aggregation: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... If you need something more convenient I highly recommend just adding lodash and getting a whole bag of rock-solid awesome tools.
reduce isn't a safe way to add floating-point numbers unless your accumulator is much more precise than your array values. You'll end up with what they call "catastrophic cancellation". And they won't let you have fixed-point in JavaScript!
Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…
The recursive folder structure in npm-modules was the first indication. At least Java had a single tree with com.bigco.division.application.framework.library.submodule.NIHObject.java
Earlier quoted context omitted.
So I don't think this is an example of core team members who don't know what you're doing. This function repeats a string up to a certain length. e.g. repeatString(foo, 10) = foofoofoof This could entirely be what the developers needed in their code base. The fact that it doesn't repeat a string N times, is at best, an example of bad naming. The issue here is that someone unrelated to the core team grepped the node c…
Allocate and join an array of blanks just to repeat a string is acceptable?!
Consider the following:
1: var str = 'foo';
2: str += 'bar';
3: str += 'baz';
Now consider the following:
1: var str = ['foo', 'bar', 'baz'].join('');
Once you have a large number of elements, or are joining large strings, the performance difference (especially regarding garbage collection) could matter.