401–410 of 478 posts
Earlier quoted context omitted.
All of the packages you mentioned are maintained by the same guy.
Have you seen his twitter? It's incredibly cringey. I don't understand how someone could be so arrogant to claim millions of companies use his software, when his software is isFalse. Not to mention his hundreds of packages that literally just output an emoji.
Earlier quoted context omitted.
Lile... x instanceof Promise It works for standard promises, sure there are non standard promises, ancient stuff, that to me shouldn't be used (and a library that uses them should be avoided). So why you need that code in the first place? Also that isPromise function will not work with TypeScript, imagine you have a function that takes something that can be a promise or not (and this is also bad design in the first p…
Your implementation is broken even if everything uses native Promises. I don't know how many times this exact thread needs to happen on HN (as it has many times before) until people realize their "no duh" implementations of things are actually worse than the thing they're criticizing. Make an iframe. In the iframe: > window.p = new Promise(() => {}); From the parent window: > window.frames[0].p instanceof Promise fal…
Earlier quoted context omitted.
Yes, that's largely my point. I'm not sure why it is surprising to see an ecosystem, twenty-five or so years younger than the one I compared it to, have the same problems as that one did twenty-five years or so ago.
In one of Robert "Uncle Bob" Martin presentation you may find the answer. The number of developers duplicates each 5 years. That means that any point in time half of the developers have less than 5 years of experience. Add to that realization the fact that inexperienced developers are learning from other inexperienced developers and you get the answer on why we repeat the same mistakes again and again. I guess that i…
You probably mean "double" here, but the bottom line is that there is zero data to back up that claim.
He literally made up that number out of thin air to make his talk look more important.
Earlier quoted context omitted.
Do you have the source? Sounds like an interesting talk.
I found it! :) I has a lot of content and insights. "Uncle" Bob Martin - "The Future of Programming" https://www.youtube.com/watch?v=ecIWPzGEbFc
There is zero evidence for his claim that the number of developers double every five years.
Weinberg's Law: If Builders Built Buildings the Way Programmers Wrote Programs, Then the First Woodpecker That Came Along Would Destroy Civilization.
Call me crazy, but... I don't add things to my projects without looking at the source. Mostly because it saves me from shit like this. If I see something is small enough, and easy enough to reason about, I'll just copy-pasta that motherfucker with a comment citing the source and date it was pasta'd (license permitting). Things like this are so not worth a package, ever, it's something when you see it you go "oh yeah,…
Do you also copy/paste the tests? https://github.com/then/is-promise/blob/master/test.js . Just curious, sometimes it's really not just about the code but that it's continuously tested as well.
If the code is in your codebase it does not need a test.
Digging into the reason behind breakage, the change is this one: https://github.com/then/is-promise/commit/feb90a40501c8ef69b... Which adds support for ES modules: https://medium.com/@nodejs/announcing-core-node-js-support-f... However the exports syntax requires a relative url, e.g. ‘./index.mjs’ not ‘index.mjs’. The fix is here: https://github.com/then/is-promise/pull/15/commits/3b3ea4150...
I wonder why people won't use yarn zero installs. They are great for having a reproducible builds and can work offline. You can have a CI and git hook which checks your code before deployment or pushing to git. Another way is to pin down the specific versions without ~ or ^ in the package.json so your updates don't break stuff.
I'm a developer, but I'm also on-call 24/7 for a Node.js application. The number of people here saying "this is why you don't use dependencies" or "this is why you vendor your deps" is frustrating to see. No one _but no one_ who has managed complex enough systems will jump on the bandwagon of enterprise-ready, monolithic and supported over something like Node.js. I'd trade in my JavaScript for J2EE about as fast as I…
Funny, I run an “enterprise” stack almost entirely made of Java. I wouldn’t trade it for NodeJS for the world. Making upstream changes indeed would be very, very hard. But I never have to make upstream changes because they’ve spent quite a large amount of effort on stability.
Earlier quoted context omitted.
Your implementation is broken even if everything uses native Promises. I don't know how many times this exact thread needs to happen on HN (as it has many times before) until people realize their "no duh" implementations of things are actually worse than the thing they're criticizing. Make an iframe. In the iframe: > window.p = new Promise(() => {}); From the parent window: > window.frames[0].p instanceof Promise fal…
No, it was not given a Promise. It was given a foreign object from another window. If you want to inspect another window you should not be reusing code that is designed for single threaded operations. Instead, have a layer that translates, serializes, or explicitly defines an interface that the objects we are dealing with are foreign and need to be transformed. Then the abstraction implementation details of dealing w…