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.
Edit: babel-plugin-react-html-attrs seems like the right solution to people who want to use “class” in their templates.
Unless you meant that there's no reason the code mod they release won't work - I agree with that.
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.
So you might hear from Brian (https://mobile.twitter.com/brian_d_vaughn) on the Profiler work he's been doing, or from Andrew (https://mobile.twitter.com/acdlite) on scheduling.
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:
* https://mobile.twitter.com/reactjs
Hope this makes sense!
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!
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.
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...
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.
Maybe my PR was too drastic, I could've just removed the call to React.Children.only
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.
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.
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.
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.
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?
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.
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.
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.
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.
There's a really good history at https://stackshare.io/posts/the-react-story .
I didn't realize they didn't start with ocaml, but sml.
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.
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).
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 :)
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.
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.
The frameworks themselves aren't that difficult to learn. Since Angular 2, they all work in a pretty similar way...
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)
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.
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.
Maybe this is true at Google, but I just don't see much demand for s/Web Components/Custom Elements.
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”.
And most of the time you see it you’re making JSX elements, where you would expect to use the word ‘class’.
I think they’re right it’s more consistent with what people would expect to happen.
The fact there is a special note in the docs calling out that everyone gets it wrong is a sign it was a problematic choice.
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.
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:
const Link = styled.a`
min-width: 12rem;
margin: 0 auto 20px;
padding: ${props => props.primary ? 18 : 16}px;
border-radius: 5px;
text-decoration: none;
border: ${props =>
props.primary ? 'none' : '3px solid currentColor'};
background: ${props =>
props.primary &&
'linear-gradient(90deg, #D26AC2, #46C9E5)'};
color: ${props =>
props.primary ? '#1D2029' : '#D26AC2'};
&:hover {
opacity: 0.95;
}
@media (min-width: 768px) {
margin: 0 20px 0 0;
&:last-child {
margin: 0;
}
}
`
render(
<div
className={css`
background-color: hotpink;
&:hover {
color: ${color};
}
`}>
This has a hotpink background.
</div>
)
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.
https://github.com/facebook/react/issues/13525#issuecomment-...
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.
grumbles
revises React lecture slides
This was one of my reasons for only using Preact. Preact is a lot simpler mental model than react. It’s smaller, faster and arguably has less nuances.
“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?
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.
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.
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.
But even Java changed A LOT in 5 years...
You always have to keep up as a developer.
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.
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.
And while I'm not sure if I'm on board with all of the changes, I'm in no way worried about having to do anything instantly.