Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Fire: Modernizing React DOM

github.com

Post reply on HN
Print view View original

61–70 of 113 posts

Re: React Fire: Modernizing React DOM

#61

Post by danabramov »

icc97 wrote: post #40
danabramov wrote: post #32

Earlier quoted context omitted.

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…

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.

I wrote some pages in the Main Concepts section. Maybe a few others. Hope it's not bad.

Re: React Fire: Modernizing React DOM

#62

Post by danabramov »

angersock wrote: post #30
dmitriid wrote: post #19

Earlier quoted context omitted.

Exactly. It’s JS and not HTML. 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.

And yet the entire reason for using JSX in the first place is that it looks like HTML. This is a reasonable change.

So I wrote in detail why I think `class` is the right choice here. Hope it helps.

https://github.com/facebook/react/issues/13525#issuecomment-...

Re: React Fire: Modernizing React DOM

#63

Post by chrisweekly »

cryptozeus wrote: post #47
ericand wrote: post #2

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.

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

Angular is a batteries-included full-fledged framework. React is a small view lib. Apples:oranges. Or, rather, apple orchard:orange.

Re: React Fire: Modernizing React DOM

#64

Post by ec109685 »

danabramov wrote: post #24
ben_jones wrote: post #15

Earlier quoted context omitted.

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

My motivation for writing this up was going through this list for the last two weeks: https://github.com/facebook/react/issues?q=is%3Aopen+is%3Ais... That's it. There's no hidden agenda here. We want to fix bugs in React. This is our strategy for a group of fixes. If something in the strategy is poor we'd love to hear feedback. But it's a bit perplexing to me that it's seen as us trying to force people to do more wor…

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.

Re: React Fire: Modernizing React DOM

#65

Post by chrisweekly »

danabramov wrote: post #24
ben_jones wrote: post #15

Earlier quoted context omitted.

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

My motivation for writing this up was going through this list for the last two weeks: https://github.com/facebook/react/issues?q=is%3Aopen+is%3Ais... That's it. There's no hidden agenda here. We want to fix bugs in React. This is our strategy for a group of fixes. If something in the strategy is poor we'd love to hear feedback. But it's a bit perplexing to me that it's seen as us trying to force people to do more wor…

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.

Re: React Fire: Modernizing React DOM

#66

Post by chrisweekly »

danabramov wrote: post #62
angersock wrote: post #30

Earlier quoted context omitted.

And yet the entire reason for using JSX in the first place is that it looks like HTML. This is a reasonable change.

So I wrote in detail why I think `class` is the right choice here. Hope it helps. https://github.com/facebook/react/issues/13525#issuecomment-...

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

Re: React Fire: Modernizing React DOM

#67

Post by grandpoobah »

dmitriid wrote: post #9

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

Your argument is addressed by Dan Abramov in the comments on the Github issue -

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.

Re: React Fire: Modernizing React DOM

#68

Post by Rapzid »

danabramov wrote: post #32
icc97 wrote: post #22

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…

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

Re: React Fire: Modernizing React DOM

#69

Post by _uhtu »

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.

Re: React Fire: Modernizing React DOM

#70

Post by Rapzid »

danabramov wrote: post #37
icc97 wrote: post #34

Earlier quoted context omitted.

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.
Post reply on HN