I love the react team for what they're doing here, but I have a feeling that the className -> class change would be a huge mistake. It makes it so that the ({ class }) => ... syntax would no longer work since it's a reserved keyword. A simple find and replace is not going to work and a pretty sophisticated code mod would be required, and even then it still means convenient practical uses like the syntax mentioned above would never be possible.
It also brings up significant package compatibility issues, if even a single package I use uses className I can't upgrade React, if a single one uses class I can't upgrade it. I'd rather not deal with a Python 2 -> 3 situation in React.
Yes, I’m disappointed by this too. It seems to be motivated by thinking about HTML/JSX, rather than the DOM where that attribute really is called className. To me, one of the appealing things about the React model is that the core is a relatively lightweight abstraction on top of the DOM, and other parts of the ecosystem (including JSX templating) are optional. This ends up being one more special case in the React core.
Edit: babel-plugin-react-html-attrs seems like the right solution to people who want to use “class” in their templates.
The increased simplicity and straightforward API seems to outweigh the edge cases though. React has always been very good at backwards compatibility and slowly migrating though, and it'll likely be the case here. The recent lifecycle methods change is a good example.
> Note we can’t just allow both without warnings because this makes it very difficult for a component ecosystem to handle. Each component would need to learn to handle both correctly, and there is a risk of them conflicting. Since many components process className (for example by appending to it), it’s too error-prone.
Unless you meant that there's no reason the code mod they release won't work - I agree with that.
I find it quite interesting how much of the public face of React that Dan Abramov has become. I really like the openness with which he speaks via his blog, but it feels like all the important React announcements come through him and I'm sure there must be some other very senior FB developers who created React before he arrived who might not be so happy.
We generally post on our blog when something is _ready_. Blog has to be very high signal/noise ratio so we don't announce something that might be experimental or has a risk of changing significantly there. Because it creates a lot of churn.
Announcements about work in progress (which might be interesting to spectators but doesn't affect anyone's day-to-day usage of React) typically comes from people working on those things.
I happen to have a large following so I understand why it seems like I'm the only one "announcing" things. Twitter also amplifies it so it kinda feels that way. I encourage you to follow all folks who are currently on our team (see links e.g. in https://wpcouple.com/interview-react-team-facebook-wordpress...).
And keep in mind that announcements directly from me that aren't on React blog/twitter are just that -- things that keep me busy. They're not things you need to know as a React user. When there's something ready that you need to know, the information will be on one of the official sources:
P.S. I'm trying to not mis-represent my role. I do happen to be a "developer advocate" of sort because I enjoy that kind of work in addition to programming. As far as I know my team is supportive of that. Sometimes I make mistakes and they point it out. AFAIK Jordan (who created React) and past contributors also don't mind my active presence. Jordan is currently busy with Reason — you might want to check that out!
Thanks for your reply and your openness. It's great that you find the time to answer random guys on HN.
Since you're here... I do wonder, how much of the React documentation did you write? The 'style' of the writing seems to match yours, e.g. when discussing Immutable JS.
Further, slightly late, reply. I've been looking more at Reason. It's React (not strictly but plays nicely) + Typescript + Immutable JS + Redux all in one fully integrated package. Looks awesome, thanks for the reminder.
It's interesting that the blog needs to be high signal to noise and yet the insinuation there is that twitter does not..
I would personally agree that it is not.
I'm sure I'm _far_ from the only one who doesn't follow much of anything on twitter. And, I'm fairly confident that twitter posts rarely hit hacker news front page. I do, however, read various engineering blogs. Perhaps a different track can be setup for WIP and experiment posts the by the core team...
Dan tweets about React... and music he enjoys. Andrew tweets about Suspense and spinners... and also his thoughts on TV shows, and a bunch of assorted troll tweets. Brian tweets about working on the React DevTools... and also the evening run he's going out on. Seb... okay, so Seb mostly tweets deep thoughts about React and the web platform.
As Dan said, the React blog is where they formally announce things related to React releases and important things the community really ought to know about now. If you follow them on Twitter, you can get insights into what they're working on, and if you don't follow them... well, important comments will still bubble up to other sites like Reddit and HN (as this thread proves), and even if you don't see them here, the critical stuff will be posted on the blog or the official @ReactJS Twitter account when the React team is really ready to officially announce that info in its final form.
I see no reason why they (or any other developer of any kind with a personal Twitter account) should be restricted in what they can talk about. So yes, I would completely say that personal Twitter accounts don't have to be "high signal to noise". A Twitter account is what the owner wants it to be.
I meant specifically within the context of a platform for the developers to communicate information about React.
Twitter is, IMHO, a poor consolation of a communications channel both for the producers and those consumers interested in non-PR reviewed, non-release React information from the developers but not their insights into spinners, TV shows, and whatev.
My general point is that a more official but still on-topic communication channel could be beneficial. I do not believe people should be restricted in what they post on their personal Twitter accounts in this context.
This may be the wrong place, but in response about being a "developer advocate" what about other react projects? react-document-title has a few pull requests without any feedback, I've personally been sidelined since Februrary https://github.com/gaearon/react-document-title/pull/53 when I made a pull request to avoid having to wrap multiple children in a React.Fragment that's child to a DocumentTitle
Maybe my PR was too drastic, I could've just removed the call to React.Children.only
A reflection: here is someone who's a bit lost on which channels should be used, is looking for feedback, & has in response been struck by the silent disapproval of HN. A sarcastic quip: Thanks for giving some tangible direction on what the correct social behaviors are here
I manage the React team at Facebook. Only a couple of us have been on the team since before Dan, and I don’t think anyone resents his public persona. Quite to the contrary – Dan does a great job representing us. :)
>I'm sure there must be some other very senior FB developers who created React before he arrived who might not be so happy.
You might find that not everybody wants to be the face of something. It can be very stressful and people often dehumanize you in their communications as they associate you and the project as the same thing. Think of all the trouble that Lennart Poettering has dealt with as a result of the pushback to systemd.
Yes, a double-edged sword. It's to the credit of the React developers that they've welcomed him. I was just curious as to how the internal politics work there.
People on the team who like to have presence on social media do that. People who don't like it that much, don't. I don't see much politics in this but maybe I'm missing something.
It's an interesting day when Github issues on an official project are considered "social media". I think that can be taken many ways and most of them interesting to ponder.
Yes, but then again, the whole selling point of Github is that it's social media attached to git repositories. That's the reason it's the open source code dumping ground.
I think this misses the point of what a senior developer is.
Nobody builds a huge thing by themselves better than multiple people can. Being a senior developer is enabling a few other people to do their best work.
Dan has been so cordial in every interaction I've seen with him. He can be more conscientious than many devs, so I'm sure it is a talent that the React team likes to showcase.
The truly important announcements come from the whole React team on their actual blog at https://reactjs.org/blog/ , and are written by various team members (such as the "Async Rendering" and "Derived State" posts recently written by Brian Vaughn).
But yeah, if you want a heads-up on where the team is headed and what they're working on, it's worth following them on Twitter, and Dan in particular.
> and I'm sure there must be some other very senior FB developers who created React before he arrived who might not be so happy.
From the very little I know about some of the developers at FB working on React, but I would be very surprised if this was the case. Just because you might feel bothered by Dan Abramov talking on your behalf, doesn't mean those that worked with him do.
So, I've only used react indirectly via Clojurescript and https://github.com/tonsky/rum for a personal project... I don't spend much time in the front-end otherwise, but every time I read something about using React from JS as one would regularly it feels much, much more complicated. I.e. I just write functions that return hiccup-html lists, and @decorate a cursor into my immutable state structure for reactive updates, and that's pretty much all there is to it, apart from a few event handlers and decorations to do special DOM pre/post wrangling for odd cases.
Could someone having experience with Rum or other Clojurescript React bindings, but a better understanding of React coming from more JS like languages chime in with their experience?
I do not have experience with clojurescript or Om.
However, I very frequently switch between React-Native-Web, React-Native & Android SDKs.
In my view, React team actually -- discovered a paradigm that's really good and workable.
In comparasing Android SDK UI work -- feels like it was 'invented' rather than discovered.
Too much difficult to follow indirections and wrong abstraction.
When I program direct Android, I find myself introducing React concepts.
Most of my Presenters and Views now have CMyState class and its one instance.
I have setState_XYZ, and clear_State associated with that state. I cary in that state backend pagination hints, etc (as an example).
And I use RxJava (in Android) to emulate eventing model of Clicks/Mounts/Dismounts (eg when android screen rotates).
All in all, again, it does seem that React developers (not sure who the credit should go to, Peter Hunt, many others ?) -- discovered an a abstraction that was always there, but was not easily crystalized through other frameworks.
And now it is. I would be happy if others would just emulate it and make it working across UI programming platforms.
It supersedes in my mind anything else that I had seen in last 25 years, in this space.
Certainly, clojurescript makes it possible to do productive React development without having to resort to JSX for syntactic sugar- This comes from the "create your own language" nature of lisp languages, which is leveraged by the many different frameworks to easily generate DOM elements in a natural way. (This also makes it easy to implement graph query languages BTW that are more elegant IMHO than graphQL.)
Another big payoff with clojurescript IMHO is the use of async channels and go blocks in lieu of promises to handle asynchronous operations- It's nice to have what is essentially a form of cooperative multithreading right inside your client javascript code, without the need for web workers.
I'm just getting my feet wet with react - but my impression from various blog posts and a bit of coding - is that in the beginning there was reasonml (ocaml dialect - mostly (but not only) targeting compilation to js target) - and react sort of "fell out" as a set of patterns/framework from doing functional programming of dom/gui/state.
And react for js, ("react") is those patterns + patterns for js to make everything (sort of) work without as solid a language to steer one away from various cliffs.
Which is one reason why I don't quite understand why there are class based components at all.
At any rate - my current goal is to try some reasonml+react - and I think it'll feel better. And I'm not surprised cs+react feels more sane than js+react.
> Which is one reason why I don't quite understand why there are class based components at all.
Classes in js are just syntax sugar, so even if you're writing classes you're still actually writing function prototypes. As such there's little reason not to support them, and they're very welcome when you have a team of developers that are adapting to modern js development almost exclusively from traditional OO languages.
Hm. I might have to have another look at the implementation of classes in js. I still don't see the benefit of the syntax - but if it really amounts to just convoluted closures over variables, I guess I'll view them with a little less grumpiness :)
It's an interesting podcast, but wanders a bit, and there's no transcript. But does mention Jordan Walke who wrote the first prototype of react for Facebook ads. Jordan is currently working on reasonml:
I do wonder if it'd be easier to port sml syntax to ocaml rather than make reasonml - I guess not. But it might give similar benefits: a pleasant syntax dialect for ocaml, a mature compiler for js and native, and bringing in th js and ocaml library ecosystems.
[ed: but not, perhaps, 90% overlap with js syntax.]
As I mentioned - I haven't really played with reasonml/reason-react - I think maybe some of the impressions alluded to in my first comment came in part from this:
"When using ReasonML, we don’t need Redux anymore. ReactReason stateless components already come with the concept of a build in reducer, which is meant to take care of the problems Redux used to address."
You might not need this library, especially so in a language which provides good enough construction blocks out of the box. ReasonReact already comes with reducers!"
For example, you can an approximation of some ClojureScript abstractions with Javascript's MobX: a datastructure that you access as normal and it reconciles render()'s for you.
Clojure's simplicity tends to package things up nicer than most other languages, especially a readme, but it's not particularly different from what people are already doing.
I helped with one of the core issues being addressed (the "value" attribute)[0]. At the time, it looked like a small "beginner" issue, but clearly was touching on some important design decisions. I am glad to see the core team take a fresh look at these decisions and using this time to clear out technical debt. This maturity is certainly good for React.
Thanks! We appreciate any help. When doing changes to a part that interfaces with a platform API it's often difficult to forecast what will work out and what wouldn't. I actually made a spreadsheet a few days ago to track all merged PRs that were relevant, and which issues they fixed and broke. Only after that it became clearer in retrospect some decisions didn't really pan out and we need to walk back on them.
I recently went through a framework selection between React, Vue and Angular. I ended up with React for reasons typified by this post. There is a massive community and a great dev team (Facebook) interested in evolving and improving React over time.
We use Angular a little bit at work, and I've been meaning to try Vue or React, but every time I start to setup the tooling, I get this sense of fatigue that's hard to describe. I feel like I have to throw away my Angular investment and start from scratch again. So, I continue to stick with Angular, which doesn't seem too bad.
On a side note, why is Angular CLI so big (71 MB)? Seems like I could write a couple hundred kilobyte python script that does the same thing (or maybe I'm only using like 10% of its features, idk).
You're asking about `angular-cli`, but I see the same question all the time in regards to Create-React-App. I'll paste in my standard answer on that topic:
The set of dependencies that CRA uses includes:
- A compiler
- A bundler/linker
- An optimizing minifier
- A linter
- A development server with live reloading
- A test runner
All of those are isolated and scoped to that one project, and they are all build-time dependencies only. It's also important to understand that Javascript packages are effectively distributed as source, which affects the number of files on disk. (Granted, many NPM packages do include unnecessary files in the published artifacts, but Javascript itself is a major factor there.)
Meanwhile, XCode is supposedly something like 8GB installed, Visual Studio is multiple gigs, and if you were to look at the actual file size on disk of any C++ compiler toolchain, that would be a minimum of several dozen megs - those are just usually preinstalled on Linux or Mac systems.
So, context is pretty important here. 70MB for a complete JS build toolchain is perfectly fine :)
I worked with Angular 5 for about half a year. It get's the job done once you've learnt it — but the problem with Angular is that it has its own way of doing things and its own concepts. "The Angular investement" is an investment in just Angular, to me that felt like a dead end, it's not transferable knowledge. React is a much more lightweight library and you use mostly bare bones JS.
Though I actually wish React was more of a framework in the sense that it enforeced, or at least encouraged, a certain folder structure and a curation of state management, Ajax libs etc. A bit more standardization would make it more convenient to use in teams.
In some ways I would like react to be more of a complete framework like you, but I worry they would do it “wrong”. Wrong, of course, is defined as not what I want.
I’m a long-time Java developer but I’ve just started using React. I, for example, would like to have the file layout be much closer to the standard maven layout. It’s what I’m used to and it works extremely well. But I completely understand why other people don’t do it that way. And since you don’t have to 100% follow some official way I’m free to set things up in a method that’s more convenient for me if I need to.
Unlike other libraries I’ve come across in my career I do like that to react community seems to have settled pretty well. Straight react is there, and read access popular enough that it’s very easy to find what you nee unlike other libraries I’ve come across in my career I do like that to react community seems to have settled pretty well. Straight react is there, and redux is popular enough that it’s very easy to find what you want to know.
When it comes to tools you have a very large number of choices, but the existence of create-react-app makes things easy. Even if you don’t use it to setup your project Babel, Webpack, and Jest are pseudo-official tools that most people seem to use. You don’t have to use them, but you also don’t have to evaluate five choices and try and pick one.
Somethings aren’t quite as clear-cut, like flow versus typescript if you want type checking.
But by and large all seems to work very well, it’s FAR better than I was expecting from the JavaScript ecosystem based on past (and admittedly very old) experience.
I would recommend basing your frontend "investment" around webpack. It's the common denominator that all the frontend frameworks use, and while it's fairly complex, it's complexity that only needs to be learnt once, and unlocks a lot of powerful functionality.
The frameworks themselves aren't that difficult to learn. Since Angular 2, they all work in a pretty similar way...
If by similar you mean they all have some component paradigm...I guess. But the cost of learning Vue, React, and Angular to a high level of proficiency is significant.
I'm working on rewriting an application from a React-like VirtualDOM approach to "ordinary" React components for a similar reason in that while my original approach had many things going for it (was theoretically more performant than React DOM, at least some of the time, according to benchmarks), it really is hard to beat the overall ecosystem around React today. Some things I never got around to doing with the old approach have out-of-the-box React controls and I don't really have to do anything to get those behaviors versus feeling like I was writing the whole world from scratch.
I recently went through same thing at our company and decided on angular. I really appreciate the overall framework architecture angular provides. React doesnt really give that
I want to say Great work, even if it's not done yet.
The react team obviously works well together, the vision is here and as an engineer who's been doing frontend work for 15 years (using flex, vanillaJS, various home-made frameworks, backbone, knockout, angular, etc) let me tell you I've never seen another framework/library come half way close to React.
By the way, why not use this big, breaking release to start offering another way to write stateful components from functions? (ES6 classes, prototypes and anything that forces me to use "this" are still part of the very bad parts of JS, imo)
Because there's only so much the React team can tackle at once :)
Yes, they've said several times they want to introduce a "stateful functional components" API, but based on comments I've seen, that's probably still about a year or so off.
It's disappointing to see no mention of fixing the broken assumptions that lead to difficulties working with Custom Elements, like not being able to set properties from JSX: https://github.com/facebook/react/issues/11347
React is from an era where you could assume a relative static, closed-world, set of built-in DOM elements, with largely attribute and children-based configuration. Now we have open-world set of user-defined elements, and Layered APIs like <virtual-scroller>, that have rich property and method-based APIs. And it seems they will still be difficult to use from React.
> At this stage, the project is very exploratory. We don't know for sure if all of the above things will pan out. .... If there's some area you're particularly interested in, please let me know and we'll work it out.
So, I'd keep an eye on the discussions and bring this up as something that could be worked on as part of the overall effort.
To be honest — as I was writing this a few hours ago custom elements slipped out of my mind, but it's something we'd like to fix too. It would make sense to do as part of this effort so we'll keep this in mind.
React is a very thin layer on top of JS. `className` is JS. Specifically, it comes directly from DOM APIs. Changing it to `class` (while retaining all other DOM API-compatible prop names) is a really terrible decision that relies on “the wisdom of the crowds”.
JSX attributes aren't HTML attributes. One way you can tell is because they don't have any namespace whatsoever.
Similarly when you add a style to an element you don't get to use `background-color` for instance, it's `backgroundColor`. Yet they're not revisiting that decision, even though it's exactly the same, i.e. `background-color` can't be used to to a JS syntax conflict.
It seems arbitrary to make JSX attributes pertaining to a DOM that don't have a namespace match XML attributes in a markup language... while not at the same time doing the same to the CSS object model property names for instance.
The backgroundColor vs background-color thing has nothing to do with React.
That is more JSS which is one attempt at CSS-in-JSS. The removed hyphen is needed because JSS requires property names as object property names where hyphens can be problematic.
Other CSS-in-JSS libraries, such as emotion.sh, has support for CSS (vs JSS above) inside of JS, including React components, and can keep default CSS syntax. Example from the emotion.sh homepage:
JSS? `<div style={{backgroundColor: 'black'}} />` is standard React / ReactDOM.
> The backgroundColor vs background-color thing has nothing to do with React.
You’re right, but it absolutely has to do with ReactDOM which is being discussed here.
Which, btw, is called ReactDOM not ReactHTMLandCSSandStuff.
Although reading Dan Abramov’s further comment ReactDOM is a bit of a misnomer, but from an API perspective it’s definitely more DOM especially with the CSS precedent and lack of XML namespaces vs. the `aria` attributes being the only major evidence to the contrary. I mean, sure it only sets `x` properties directly, but as an end user of the library what do I care about the internal implementation?
Edit: A new `classList` property that accepts an array would be nice as that way anyone using `className` has a superior API to migrate to and stay away from this change entirely. It’s not like it’s setting it directly so just convert to a DOMTokenList on the fly.
Because in JS that attribute/property is `className`. Because `class` is a reserved name in JS.
Same goes for `htmlFor`, for example. So now you will have a situation where all props directly correspond to DOM APIs, and one prop that isn’t. A strange choice given how the stated goal is to be more consistent with DOM APIs.
Leaving my comment here as well for increased visibility:
Current state of things:
- React is inconsistent
- API is camelCase
Proposed state of things:
- React is inconsistent
- API is camelCase
- `className` -> `class`
Perceived benefits:
> If React was open sourced today, it seems like the pros of allowing class (closer conceptually to what most people expect, less typing for the most commonly used prop) outweigh the downsides (slightly more typing to intercept it — in which cases you'll probably just want the spread operator anyway).
Actual downsides:
- the entire ecosystem that depends on `className` stops working (huge upgrade effort)
- the entire vast body of books, tutorials, examples, code, posts, articles becomes ever so slightly invalid
- the only valid JS remaining is additional typing: `const {class: cls} = props`. Every other possible use-case in plain JS becomes invalid
- React API remains inconsistent, and breaks further assumptions (why `htmlFor` not `for` etc.)
If I were a product manager, my immediate reaction to the change would be: wat?
So, with `for` you will introduce even more JS-incompatibility, break even mire stuff (basically, all forms), and the reason for the change is?.. Somewhat less typing (which is already covered by autocomplete in everything but Windows Notepad)?
> Migrate from onChange to onInput... It has been confusing that React uses a different event name for what's known as input event in the DOM.
This change is at least somewhat warranted, as it makes things more consistent with the DOM.
What are the reasons for `className->class`, `htmlFor->for` besides the "it's longer to type" when the many downsides to the decisions have been spelled out in no uncertain detail in the issue?
It can't be "We're already allowing passing class down to the DOM node in React 16" because you're confusing a bad decision (allowing `class`) with requirements for the change ("we now have to change className to class"). Honestly, the whole className->class lacks any real justification.
So yes, to quote yourself:
> using a React component should feel like idiomatic JavaScript.
Idiomatic Javascript is:
- no reserved words as variable names (`class` and `for` are reserved words)
- className, htmlFor etc. because that's what they are in Javascript
- in your insistence that everything needs to be camelCase you forget that `className` and `htmlFor` are already camelCase
So the main issue you seem to have is this:
> React Is Not Just Setting Properties
^ this is what causes all the problems, and this is what needs to change. Not additional confusion where "idiomatic Javascript" somehow ends up having to use reserved words and workarounds for those reserved words.
Highly recommend reading Dan's reasoning; it makes a lot of sense. This quote is as close as I can get to distilling it:
>"I think this is the primary reason it's desirable for props like tabIndex, cellSpacing, and most other DOM-related props to follow the camelCase convention. It's not because they're DOM property names. It's because they often end up in component APIs. And we want component APIs to be consistently camelCase."
tl;dr, There's already a lot of inconsistency, this is not a good argument.
That said, I don't like the className->class change either. It's a reserved keyword, it always made perfect sense why they originally went with className.
Can someone with knowledge of the internals of react-native-web estimate the effect of these changes on the project? are other similar projects like ReactXp better immune?
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?
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.
> 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.
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.
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.
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.
Not sure what you mean. React is 5 years old. Frontend development is more volatile by nature as devices changes, UX guidelines change, etc but overall React was very stable during these years.
You should read the link, these changes are less "modernizing" the API, and more doing the internals, many of which haven't changed since 2013.
In that process there will probably be some breaking changes, but Facebook has some insane number of components they use internally, so they try to never make any breaking changes that can't be automatically migrated.
Changing className -> class and onChange -> onInput is going to affect practically every React component ever written.
They seem to have opposite rationales (class is less pedantic and onInput is more pedantic) and I expect at least one of them will get dropped along the way but we'll see.
It also brings up significant package compatibility issues, if even a single package I use uses className I can't upgrade React, if a single one uses class I can't upgrade it. I'd rather not deal with a Python 2 -> 3 situation in React.