The libraries/projects I mentioned were only those which quickly came to my mind. Probably we would need to inspect a larger dataset in order to get meaningful results on the topic.
IMHO the reason why alot of single person projects gain traction at all is because they tend to have nice APIs. APIs which developers enjoy using. This is because those single persons have a clear picture in their head about how their library should work.
That's also why TJ has so many popular projects (in my opinion). It's because he does a great job designing the APIs. Funny thing is that he is also an actual designer :)
Nice story :)
Node was always nice to quickly show off something. I remember playing around with Node, the first time, in the end of 2009. Back then it already was clear that it will probably become huge.
I think that's often how new tech slowly sneaks itself into a company. Some developers playing around with it, talking about it at lunch, demonstrating that it is way more productiv than the previous solution. Then the technology gets used in some minor important project, after that maybe in some more important project, and so on.
Couple of years later, same thing happens with some newer technology.
I don't think it plays that of a big role if a library was only created by a single person or not. Think of Node.JS, express, redis, Backbone.js, linux etc. They all became popular, despite the fact that they were created by a single person (at least at the beginning).
Discussing React vs. Vue on the internet ist mostly a waste of time. People tend to be biasd towards their favorite library, like it is some sort of religious cult or something. I'm not excluding myself from this.
Maybe we would get better results if both groups were only allowed to write about the negativ parts of their favorite library.
A similar example in React, using a Higher Order Component, would look somehow like this:
function createSurveyInput(SurveyComponent) {
return (props) => (
<div className="survey-base">
<h4>{props.question}</h4>
<SurveyComponent {...props} />
</div>
)
}
const SurveyInputText = createSurveyInput((props) => (
<input type="text" placeholder={props.placeholder} />
))
If someone explicitly passes in "const opts = { name: null }" then I would argue that he wants name to be null and it should not be overwritten by what is defined in defaults. But I agree with you that there may be some (rare?) cases where some other behaviour is wanted.
The way Object.assign is usually used is like this:
const opts = Object.assign({}, defaults, options);
It will fallback to the properties defined in defaults if they don't exist in options.
Nowadays you can also use destructering to achieve the same:
const opts = { ...defaults, ...options };
A similar example in React, using a Higher Order Component, would look somehow like this: function createSurveyInput(SurveyComponent) { return (props) => ( <div className="survey-base"> <h4>{props.question}</h4> <SurveyComponent {...props} /> </div> ) } const SurveyInputText = createSurveyInput((props) => ( <input type="text" placeholder={props.placeholder} /> ))If someone explicitly passes in "const opts = { name: null }" then I would argue that he wants name to be null and it should not be overwritten by what is defined in defaults. But I agree with you that there may be some (rare?) cases where some other behaviour is wanted.The way Object.assign is usually used is like this: const opts = Object.assign({}, defaults, options); It will fallback to the properties defined in defaults if they don't exist in options. Nowadays you can also use destructering to achieve the same: const opts = { ...defaults, ...options };You can check for the existence of a property with obj.hasOwnProperty('someProp').