Hacker News new | ask | show | jobs
by shawn 2855 days ago
Relevant: http://thecodist.com/article/the_programming_steamroller_wai...

“The Programming Steamroller Waits For No One“

Also:

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

“Fire and Motion”

The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Facebook. People get worried about React and decide to rewrite their whole architecture for React because they think they have to. Facebook is shooting at you, and it’s just cover fire so that they can move forward and you can’t, because this is how the game is played, Bubby. Are you going to support Saga? Flow? React Native? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond?

1 comments

Can you clarify what you're trying to say, specifically with the second link?

The implication I'm getting out of it is that you feel the React team is deliberately reinventing things to force the web dev ecosystem to keep up with them (specifically per the sentence "The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features."). From my perspective, that's not the case at all. In the last couple years, they have:

- Rewritten React's internal architecture completely based on lessons learned and long-running design goals, giving them a solid foundation to build new features (and without changing the public API)

- Added new features and capabilities based on that new foundation, including many things the community has asked for (rendering arrays, improved context, etc)

- Implemented most of a new feature set that should allow React users to simplify much of their async data loading logic, on an opt-in basis.

- With that winding down, started tackling cleanup and technical debt issues to make behavior more consistent

Sure, that process has all resulted in changes (such as the warnings about deprecated lifecycle methods), but it's been an incremental process, and they've offered up codemods to help with changes for things like lifecycles. The end goals here are better apps and more consistent behavior, not trying to beat down competition.

edit

Since the parent updated with a modified quote from the article that uses a bunch of React-related references instead, I'll respond to that.

The suggestion here seems to be that Facebook is deliberately trying to waste everyone else's time keeping up. As Dan Abramov recently said (https://twitter.com/dan_abramov/status/1033806477306331136 ):

> There’s a common misconception that React is some sort of strategic investment and receives direction from the top. That’s not the case; pretty much all development and planning comes from the team itself. React is useful to FB but FB org is built around products rather than tech

Also, I'll point out that "sagas" are a Redux ecosystem addon for managing side effects, and neither Redux nor Redux-Saga are owned by Facebook in any way.

> The implication I'm getting out of it is that you feel the React team is deliberately reinventing things to force the web dev ecosystem to keep up with them (specifically per the sentence "The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.").

Judging by the first link, GP isn't really trying to accuse React project of trying to block other JS frameworks with suppressive fire. I think the point is, it's yet another encounter with the ever accelerating, already significant-fraction-of-lightspeed fast steam roller of modern/fashionable programming stacks.

I wouldn't be surprised if at least a couple of React's innovations and release cycles correspond with Facebook's bonus incentives for their engineers. There's nothing wrong with that, but I find it highly more likely then some great conspiracy to soak up the dev time of completely unrelated companies.
My motivation for writing this up was going through this list for the last two weeks:

https://github.com/facebook/react/issues?q=is%3Aopen+is%3Ais...

That's it.

There's no hidden agenda here. We want to fix bugs in React. This is our strategy for a group of fixes. If something in the strategy is poor we'd love to hear feedback. But it's a bit perplexing to me that it's seen as us trying to force people to do more work, _or_ that there's some kind of perverse incentives for that. If I'm communicating this badly let me know here or in private (https://mobile.twitter.com/dan_abramov — my DMs are open) how I could do it better.

If you follow the linked issues, they are things we've been planning to do for years. They're hard to fix in isolation which is why we thought it would help to bring them under a single umbrella. We're not trying to play some kind of trick on you -- if you used React heavily you're likely familiar with all these problems, and they probably bit you at one point or another. We're always trying to improve React, and we finally got to this set of issues.

Attaching events to the root ( https://github.com/facebook/react/issues/2043) is a four-year old issue. We have tried to do this in the past (https://github.com/facebook/react/pull/8117) but the effort fizzled because it's too hard to fix incrementally. But it's an important problem and we regularly bump into the consequences of it.

Syncing the value attribute has caused a security issue that was widely discussed on HN (https://news.ycombinator.com/item?id=16422696) and caused countless linked bugs. So we want to change it back, but it's a major one so we also put it under the umbrella.

Simplifying the event system is something we hear about almost every day -- both from the bundle size perspective, and from the bug reports I linked which have to do with the complexity of our existing polyfills.

Edit: wanted to add one more thought regarding the rephrasing of Joel's article in the grandgrandparent.

I don't think replacing Microsoft with Facebook makes sense in this context. Microsoft was creating a developer ecosystem on purpose. Because they are an application platform. Facebook is not an application platform for React apps. The reason we get paid to work on React is because it's useful _to_ Facebook — not because Facebook wants _you_ to build with it. If engineers and a few managers above the React team didn't care strongly about open source in the beginning, and that in turn didn't attract more people who care about open source to the team, React would stay within Facebook and keep evolving there. So I can see why you want to apply this analogy, and it might even make sense for the educational industry that appeared around React, but it has little to do with Facebook or React itself.

First: THANK YOU, Dan, for your and your team's first-rate work on React. Please keep it up!

Next: Tempted to say, "don't feed the trolls".

Finally: it seems to me that all too often React the library gets conflated with "React" (+Redux, +[middlewares], +Webpack, +Babel, +Node) the ecosystem.

Don’t you also get feedback, pull requests, bug fixes and suggestions from the community that are both beneficial to react but also to Facebook as well?

Therefore it now seems like there _is_ incentive for Facebook to want outside developers to use it.

Thanks.

Sure, and that’s very helpful. But we also spend months of work on things that affect open source (like gradual migration strategies) that aren’t beneficial to Facebook per se. So from a business perspective it’s not a clear-cut case. Sometimes it can even challenging to justify some kinds of work. But we believe in it.

What I’m trying to say here is not that we don’t value open source contributions. But that much of the driving force behind how React is developed comes from the team itself. Not executives.

Hey I appreciate your reply and wanted to clarify that my comment wasn't well thought out - I didn't read the article and was reacting emotionally to the bizarre theory above. Thank you for your work on React and effort communicating back to the community.
Look outside just the React team: it's okay, even useful, for the React folks to get to work on things from Facebook--and to release them to the ecosystem at large--in no small part due it establishing both programmer cred and (arguably more importantly) cover fire for the other Facebook activities.