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

81–90 of 113 posts

Re: React Fire: Modernizing React DOM

#81

Post by TeMPOraL »

acemarke wrote: post #11
shawn wrote: post #7

Relevant: http://thecodist.com/article/the_programming_steamroller_wai... “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 Reac…

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…

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

Re: React Fire: Modernizing React DOM

#82

Post by rezistik »

_uhtu wrote: post #69

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 abo…

Yeah, that's the only change I'm not thrilled with.

Re: React Fire: Modernizing React DOM

#83

Post by quink »

pests wrote: post #78
quink wrote: post #26

Earlier quoted context omitted.

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…

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 f…

JSS? `` 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.

Re: React Fire: Modernizing React DOM

#84

Post by dvdhnt »

peterhunt wrote: post #56
spicyj wrote: post #45

Earlier quoted context omitted.

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 echo this sentiment!

Sweet last name you got there.

Re: React Fire: Modernizing React DOM

#85

Post by swrobel »

_uhtu wrote: post #69

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 abo…

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

Re: React Fire: Modernizing React DOM

#86

Post by manigandham »

_uhtu wrote: post #69

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 abo…

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.

Re: React Fire: Modernizing React DOM

#87

Post by scns »

maga_2020 wrote: post #71
Nihilartikel wrote: post #21

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 update…

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 f…

I think the credit should go to Jordan Walke who first wrote React in Standard ML

Re: React Fire: Modernizing React DOM

#88

Post by scns »

e12e wrote: post #36
Nihilartikel wrote: post #21

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 update…

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 everythin…

React was first written in Standard ML

Re: React Fire: Modernizing React DOM

#89

Post by kylemh »

swrobel wrote: post #85
_uhtu wrote: post #69

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 abo…

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

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

Re: React Fire: Modernizing React DOM

#90

Post by dmitriid »

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

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?

Post reply on HN