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

31–40 of 113 posts

Re: React Fire: Modernizing React DOM

#31

Post by mleland »

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.

Dan has been so cordial in every interaction I've seen with him. He can be more conscientious than many devs, so I'm sure it is a talent that the React team likes to showcase.

Re: React Fire: Modernizing React DOM

#32

Post by danabramov »

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 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://reactjs.org/blog/

* 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!

Re: React Fire: Modernizing React DOM

#33

Post by danabramov »

ghayes wrote: post #5

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

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.

Re: React Fire: Modernizing React DOM

#34

Post by icc97 »

jzelinskie wrote: post #23
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 pushba…

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.

Re: React Fire: Modernizing React DOM

#36

Post by e12e »

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

Re: React Fire: Modernizing React DOM

#37

Post by danabramov »

icc97 wrote: post #34
jzelinskie wrote: post #23

Earlier quoted context omitted.

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

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.

Re: React Fire: Modernizing React DOM

#38

Post by acemarke »

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…

ReasonML is a very new language variant, and wasn't part of React's original implementation.

There's a really good history at https://stackshare.io/posts/the-react-story .

Re: React Fire: Modernizing React DOM

#39

Post by larzang »

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…

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

Re: React Fire: Modernizing React DOM

#40

Post by icc97 »

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…

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.

Post reply on HN