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...
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 .
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.
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.
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.
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.
