
React Fire: Modernizing React DOM - radubrehar
https://github.com/facebook/react/issues/13525
======
coltonv
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.

~~~
swrobel
No reason this couldn't be backwards compatible...

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

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

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

So you might hear from Brian
([https://mobile.twitter.com/brian_d_vaughn](https://mobile.twitter.com/brian_d_vaughn))
on the Profiler work he's been doing, or from Andrew
([https://mobile.twitter.com/acdlite](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...](https://wpcouple.com/interview-react-team-facebook-wordpress-
gutenberg/)).

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://reactjs.org/blog/](https://reactjs.org/blog/)

* [https://mobile.twitter.com/reactjs](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!

~~~
__s
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](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

~~~
__s
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

------
Nihilartikel
So, I've only used react indirectly via Clojurescript and
[https://github.com/tonsky/rum](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?

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

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

~~~
e12e
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 :)

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

[0]
[https://github.com/facebook/react/pull/6406](https://github.com/facebook/react/pull/6406)

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

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

~~~
umvi
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).

~~~
acemarke
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 :)

~~~
abhisuri97
For context CRA is 160 MB ish with all dependencies installed.

------
boubiyeah
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)

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

------
spankalee
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](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.

~~~
acemarke
Note that Dan specifically said:

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

~~~
spankalee
They're quite aware of this issue.

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

------
dmitriid
`className` to `class` is a bad decision.

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

~~~
MBCook
It’s JS, but not HTML.

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.

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

~~~
pests
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:

    
    
      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;
          }
        }
      `
    

If you notice variables and props are available via string interpolation.
emotion.sh also makes inline styling easier:

    
    
      render(
        <div
          className={css`
            background-color: hotpink;
            &:hover {
              color: ${color};
            }
          `}>
          This has a hotpink background.
        </div>
      )
    

[edited for formatting and word choice]

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

~~~
pests
Oops I totally forgot about inline styling like that without a preprossor. You
are correct.

Although it does seem like ReactDOM already does some weird stuff already in
regards to vendor prefixing.

------
ofirg
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?

------
abhisuri97
"className -> class"

 _grumbles_

 _revises React lecture slides_

~~~
pcmaffey
more grumbles... `const class = foo`

~~~
lioeters
..grumbles..

({ class: className }) => <div class={ className } />

------
nojvek
className -> class. Finally! Also attaching events on the element rather than
documenting. Seems like they are actually listening to devs.

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.

------
pspeter3
This is incredibly exciting. I'm glad they're focused on simplifying the
model.

------
shawn
Relevant:
[http://thecodist.com/article/the_programming_steamroller_wai...](http://thecodist.com/article/the_programming_steamroller_waits_for_no_one)

“The Programming Steamroller Waits For No One“

Also:

[https://www.joelonsoftware.com/2002/01/06/fire-and-
motion/](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?_

~~~
acemarke
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](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.

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

~~~
danabramov
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...](https://github.com/facebook/react/issues?q=is%3Aopen+is%3Aissue+label%3A%22Component%3A+DOM%22+label%3A%22Type%3A+Bug%22)

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

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

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

------
imh
When react already has to be "modernized" I become thankful that I don't work
in JS land. I honestly don't think I could keep up and remain happy.

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

But even Java changed A LOT in 5 years...

You always have to keep up as a developer.

~~~
a13n
And honestly, you don't really have to keep up with the latest version of
React. We're still on 15.4 – almost 2 years old! Works great for us.

~~~
acemarke
Out of curiosity, anything preventing you from upgrading to 16.x ?

~~~
a13n
We're running a startup and upgrading React just isn't a priority.

