It does actually make a difference. Contrast:

> "x is a build system developed by me as a side-project that I might drop at any time, and its only production use is to compile itself and a hello world app"

Not to say people's side projects aren't useful, but there's only so many hours in a day, and there are thousands and thousands of open source projects, so you need some way to evaluate what's worth looking at. Knowing it has more than one person behind it, some time in field (so it's not 0.0.1 alpha), and is actively being used (you're not writing the first production code using it) goes a long way to separating it from the pack.

> I understand the human need to optimize attention, use basal heuristics to weed out unattractive options, and nurture a need to belong, but this is not logic. It's a rationalization.

There is an underlying logic though when you frame it in as a time vs reward problem. I could spend a few months evaluating all of the various build tools out there and find the perfect fit for my team. Or I could spend a few days evaluating the projects with the most support (be that large companies, large communities, whatever). I'll concede that I can't guarantee it's the _perfect_ fit, but it's likely good enough when you compare the opportunity costs.

> Why does facebook know best what kind of build system is suitable for my needs

well, by definition your needs are yours, and only you know them, right? perhaps that is your point... but then this question would seem to be malformed, or perhaps disingenuous. why does facebook need to know "your needs" to develop a good build system? maven developers don't know "your needs" anymore than make, cargo and all the rest.

> I'm probably nothing like facebook?

it's not clear what it exactly means to be "like" or "nothing like" facebook, without further context. differences with your understanding of facebook's operational requirements do not necessarily translate to same or similar differences with their software development and build needs and practices.

> Why does George Foreman know how I want my grill?

similarly, the structuring of "my grill" bit seems problematic. also, this seems outright unrelated, unless foreman is in fact a very intensive user of grills and has optimized the grill design over time based on his experiences... and you are also, in some capacity, a professional user of grills.

> It's a brilliant marketing and recruiting tool and a way to insert influence under the guise of open benevolence.

even if we accept the premise of it as a "marketing tool", this doesn't imply that it's not a solid tool proven in real world projects. no obvious mutual exclusivity here. it also doesn't mean it's not-benevolent.

it would seem impossible for any company to avoid this pointed finger of yours if they release an project, because any engineer is going to ask "where did this come from" at one point or another. then, presumably, they will have been victims of villainous marketing.

> Hidden out there is probably a better tool for your needs. But now you'll never find it.

maybe, maybe not. how much better? at best, unknown or unresearched tools would seem to have indeterminate benefit (or lack thereof) relative to what is known and researched.

As a complete outsider, the way I see it a lot of the systems at Facebook actually originated within Google, but were never published. Engineers from Google then went to work at Facebook and wanted to replicate the systems they were already familiar with. The only difference is that Facebook actually releases most of these things as open source. So I guess the good news is that when engineers leave Facebook and go to work at "next big thing" they can bring the same tools with them without having to rewrite them again.

I think you are overreacting. The first sentence has to introduce you to what you are reading about, and this seems like a fairly minimal description of what Buck is. There are more detailed points below the first paragraph, and a talk available on YouTube: https://www.youtube.com/watch?v=uvNI_E0ZgZU.

Yeah, sorry. I've just been seeing this more and more in open source and the first paragraph just jumped out at me. Why is is so important that things we use be developed by major companies?

It's an unpoular opinion, but I feel that React et al are just a way for Facebook to gain developer mindshare. Likewise how Angular is a play for Google to gain developer mindshare. The big guys want developers locked into their ecosystems. It's a play out of Microsoft's book.

When you realize that none of these frameworks are even an improvement over jQuery, it becomes clear what the true motivation is.

Well, IMO, React is much better than building the equivalent in jQuery.

I once thought that too. But after working under a jQuery ninja I learned that it's far more powerful than most people give it credit for. More importantly, it's significantly easier to reason about DOM changes in jQuery vs other frameworks because there's no magic at all.

For example, here is a SQLite playground that I built with a friend https://sql.glitch.me/. The entire frontend is only 100 lines of Javascript thanks to jQuery. I'd love to see what the React implementation looks like.

Pretty sure no one really doubted jQuery power.. it's about maintainability, state management, modularization.

If you tinker hard enough, you can achieve those with jQuery, but it'll never be as easy as React.

Also, your site doesn't load (project not found)

I guess we just disagree over whether or not all that is made easier with React. I have worked on large jQuery codebases that do everything you mentioned: they are maintainable, they manage state in a comprehensive fashion, and they are modularized.

JavaScript Fatigue inducing media tries to taint jQuery calling it all sorts of things but that hasn't stopped me. Sure you need to learn and use a handful of useful patterns to build with it, but it's the same situation if you want to make proper use of any framework.

And I updated the url for my demo :)

I don't find that important, but I find that it means

1) This is probably a project I want to check out, if it pertains to my stack, and

2) This is probably going to stick around and not be unsupported very soon.

I would be just as happy if FB hadn't developed it, and instead it was just used by them. (Or any other of maybe a dozen big camps) Or if it was just used by a whole lot of people.

Widespread use is a pretty good metric for what library to choose, when you aren't familiar with the landscape.

It isn't. But if something is run by a major company wouldn't you want to know?

It's important because a lot more gets done when multiple people are being paid to work on bugs & features full-time than when it's, say, one person trying to find some spare time in their evenings.

I think the argument is that Facebook is spending an absurd amount of money on engineering. So, anything that emerges as something that huge pool of engineers find useful and cool is probably pretty well made.

On the other hand. I do think you are right. React suffers from this a lot. React is good. It has a lot of strong competition from smaller groups. But, the attitude seems to be "FB will rub so much money against React! That much money and fame will polish anything. Soon it'll be popular because it's popular. Don't fight it."