Live data from Hacker News

React Fire: Modernizing React DOM

github.com

51–60 of 113 posts

Re: React Fire: Modernizing React DOM

#51

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

> Now we have open-world set of user-defined elements

Maybe this is true at Google, but I just don't see much demand for s/Web Components/Custom Elements.

Re: React Fire: Modernizing React DOM

#52
post #48

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.

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.

Re: React Fire: Modernizing React DOM

#53

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

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.

Re: React Fire: Modernizing React DOM

#54
post #17
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 worked with Angular 5 for about half a year. It get's the job done once you've learnt it — but the problem with Angular is that it has its own way of doing things and its own concepts. "The Angular investement" is an investment in just Angular, to me that felt like a dead end, it's not transferable knowledge. React is a much more lightweight library and you use mostly bare bones JS. Though I actually wish React was…

In some ways I would like react to be more of a complete framework like you, but I worry they would do it “wrong”. Wrong, of course, is defined as not what I want.

I’m a long-time Java developer but I’ve just started using React. I, for example, would like to have the file layout be much closer to the standard maven layout. It’s what I’m used to and it works extremely well. But I completely understand why other people don’t do it that way. And since you don’t have to 100% follow some official way I’m free to set things up in a method that’s more convenient for me if I need to.

Unlike other libraries I’ve come across in my career I do like that to react community seems to have settled pretty well. Straight react is there, and read access popular enough that it’s very easy to find what you nee unlike other libraries I’ve come across in my career I do like that to react community seems to have settled pretty well. Straight react is there, and redux is popular enough that it’s very easy to find what you want to know.

When it comes to tools you have a very large number of choices, but the existence of create-react-app makes things easy. Even if you don’t use it to setup your project Babel, Webpack, and Jest are pseudo-official tools that most people seem to use. You don’t have to use them, but you also don’t have to evaluate five choices and try and pick one.

Somethings aren’t quite as clear-cut, like flow versus typescript if you want type checking.

But by and large all seems to work very well, it’s FAR better than I was expecting from the JavaScript ecosystem based on past (and admittedly very old) experience.

Re: React Fire: Modernizing React DOM

#55
post #48

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.

You should read the link, these changes are less "modernizing" the API, and more doing the internals, many of which haven't changed since 2013. In that process there will probably be some breaking changes, but Facebook has some insane number of components they use internally, so they try to never make any breaking changes that can't be automatically migrated.

Changing className -> class and onChange -> onInput is going to affect practically every React component ever written.

They seem to have opposite rationales (class is less pedantic and onInput is more pedantic) and I expect at least one of them will get dropped along the way but we'll see.

Re: React Fire: Modernizing React DOM

#56
post #45
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 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!

Re: React Fire: Modernizing React DOM

#57

Earlier quoted context omitted.

You should read the link, these changes are less "modernizing" the API, and more doing the internals, many of which haven't changed since 2013. In that process there will probably be some breaking changes, but Facebook has some insane number of components they use internally, so they try to never make any breaking changes that can't be automatically migrated.

Changing className -> class and onChange -> onInput is going to affect practically every React component ever written. They seem to have opposite rationales (class is less pedantic and onInput is more pedantic) and I expect at least one of them will get dropped along the way but we'll see.

They almost always provide codemods which can automatically convert a codebase for you, and they work pretty damn well.

And while I'm not sure if I'm on board with all of the changes, I'm in no way worried about having to do anything instantly.

Re: React Fire: Modernizing React DOM

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

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

From the very little I know about some of the developers at FB working on React, but I would be very surprised if this was the case. Just because you might feel bothered by Dan Abramov talking on your behalf, doesn't mean those that worked with him do.

Re: React Fire: Modernizing React DOM

#59

Earlier quoted context omitted.

You should read the link, these changes are less "modernizing" the API, and more doing the internals, many of which haven't changed since 2013. In that process there will probably be some breaking changes, but Facebook has some insane number of components they use internally, so they try to never make any breaking changes that can't be automatically migrated.

Changing className -> class and onChange -> onInput is going to affect practically every React component ever written. They seem to have opposite rationales (class is less pedantic and onInput is more pedantic) and I expect at least one of them will get dropped along the way but we'll see.

The rationale seems to be "default to plain html/dom" where possible.

Re: React Fire: Modernizing React DOM

#60
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 think this misses the point of what a senior developer is.

Nobody builds a huge thing by themselves better than multiple people can. Being a senior developer is enabling a few other people to do their best work.

Post reply on HN