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

21–30 of 113 posts

Re: React Fire: Modernizing React DOM

#21

Post by Nihilartikel »

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

Re: React Fire: Modernizing React DOM

#22

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

Re: React Fire: Modernizing React DOM

#23

Post by jzelinskie »

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.

>I'm sure there must be some other very senior FB developers who created React before he arrived who might not be so happy.

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.

Re: React Fire: Modernizing React DOM

#24

Post by danabramov »

ben_jones wrote: post #15
acemarke wrote: post #11

Earlier quoted context omitted.

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…

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

Re: React Fire: Modernizing React DOM

#25

Post by angersock »

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…

Look outside just the React team: it's okay, even useful, for the React folks to get to work on things from Facebook--and to release them to the ecosystem at large--in no small part due it establishing both programmer cred and (arguably more importantly) cover fire for the other Facebook activities.

Re: React Fire: Modernizing React DOM

#26

Post by quink »

MBCook wrote: post #12
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”.

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.

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.

Re: React Fire: Modernizing React DOM

#27

Post by chrisco255 »

nicoburns wrote: post #18
umvi wrote: post #10

Earlier quoted context omitted.

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

I would recommend basing your frontend "investment" around webpack. It's the common denominator that all the frontend frameworks use, and while it's fairly complex, it's complexity that only needs to be learnt once, and unlocks a lot of powerful functionality. The frameworks themselves aren't that difficult to learn. Since Angular 2, they all work in a pretty similar way...

If by similar you mean they all have some component paradigm...I guess. But the cost of learning Vue, React, and Angular to a high level of proficiency is significant.

Re: React Fire: Modernizing React DOM

#28

Post by danabramov »

spankalee wrote: post #14
acemarke wrote: post #6

Earlier quoted context omitted.

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.

They're quite aware of this issue.

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.

Re: React Fire: Modernizing React DOM

#29

Post by acemarke »

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.

The truly important announcements come from the whole React team on their actual blog at https://reactjs.org/blog/ , and are written by various team members (such as the "Async Rendering" and "Derived State" posts recently written by Brian Vaughn).

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.

Re: React Fire: Modernizing React DOM

#30

Post by angersock »

dmitriid wrote: post #19
MBCook wrote: post #12

Earlier quoted context omitted.

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.

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