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

71–80 of 113 posts

Re: React Fire: Modernizing React DOM

#71

Post by maga_2020 »

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 find myself introducing React concepts. Most of my Presenters and Views now have CMyState class and its one instance.

I have setState_XYZ, and clear_State associated with that state. I cary in that state backend pagination hints, etc (as an example).

And I use RxJava (in Android) to emulate eventing model of Clicks/Mounts/Dismounts (eg when android screen rotates).

All in all, again, it does seem that React developers (not sure who the credit should go to, Peter Hunt, many others ?) -- discovered an a abstraction that was always there, but was not easily crystalized through other frameworks.

And now it is. I would be happy if others would just emulate it and make it working across UI programming platforms. It supersedes in my mind anything else that I had seen in last 25 years, in this space.

Re: React Fire: Modernizing React DOM

#72

Post by a13n »

boubiyeah wrote: post #52
imh wrote: 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.

And honestly, you don't really have to keep up with the latest version of React. We're still on 15.4 – almost 2 years old! Works great for us.

Re: React Fire: Modernizing React DOM

#73

Post by acemarke »

Rapzid wrote: post #68
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…

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…

Dan tweets about React... and music he enjoys. Andrew tweets about Suspense and spinners... and also his thoughts on TV shows, and a bunch of assorted troll tweets. Brian tweets about working on the React DevTools... and also the evening run he's going out on. Seb... okay, so Seb mostly tweets deep thoughts about React and the web platform.

As Dan said, the React blog is where they formally announce things related to React releases and important things the community really ought to know about now. If you follow them on Twitter, you can get insights into what they're working on, and if you don't follow them... well, important comments will still bubble up to other sites like Reddit and HN (as this thread proves), and even if you don't see them here, the critical stuff will be posted on the blog or the official @ReactJS Twitter account when the React team is really ready to officially announce that info in its final form.

I see no reason why they (or any other developer of any kind with a personal Twitter account) should be restricted in what they can talk about. So yes, I would completely say that personal Twitter accounts don't have to be "high signal to noise". A Twitter account is what the owner wants it to be.

Re: React Fire: Modernizing React DOM

#74

Post by acemarke »

a13n wrote: post #72
boubiyeah wrote: post #52

Earlier quoted context omitted.

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.

And honestly, you don't really have to keep up with the latest version of React. We're still on 15.4 – almost 2 years old! Works great for us.

Out of curiosity, anything preventing you from upgrading to 16.x ?

Re: React Fire: Modernizing React DOM

#76

Post by robdachshund »

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.

No one ever talks about that little clause in the react terms that says fb can revoke your license if they feel you are infringing on their parents.

That's right, fb can legally block your access to react if they determine you are a threat to fb at large. For that reason, and the fact that it is owned by fb, I have very little interest in ever using it.

Re: React Fire: Modernizing React DOM

#77

Post by robdachshund »

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…

I wouldn't call it a hidden agenda. You work for Facebook. Pretty out in the open these days.

Open source or not; it's a tough pill to swallow using these freebie frameworks and tools from massive companies like fb and google.

It obviously benefits these companies when we make your products de facto standards, open source or not.

Not sure I want the tech giants controlling the internet at large, as well as the tech behind it.

Re: React Fire: Modernizing React DOM

#78

Post by pests »

quink wrote: post #26
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.

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 from the emotion.sh homepage:

  const Link = styled.a`
    min-width: 12rem;
    margin: 0 auto 20px;
    padding: ${props => props.primary ? 18 : 16}px;
    border-radius: 5px;
    text-decoration: none;
    border: ${props =>
      props.primary ? 'none' : '3px solid currentColor'};
    background: ${props =>
      props.primary &&
      'linear-gradient(90deg, #D26AC2, #46C9E5)'};
    color: ${props =>
      props.primary ? '#1D2029' : '#D26AC2'};
    &:hover {
      opacity: 0.95;
    }
    @media (min-width: 768px) {
      margin: 0 20px 0 0;
      &:last-child {
        margin: 0;
      }
    }
  `
If you notice variables and props are available via string interpolation. emotion.sh also makes inline styling easier:

  render(
    
      This has a hotpink background.
    
  )
[edited for formatting and word choice]

Re: React Fire: Modernizing React DOM

#79

Post by wLMeOv2qjsFOjZG »

chrisweekly wrote: post #66
danabramov wrote: post #62

Earlier quoted context omitted.

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…

But both class and className are camelCased.

Re: React Fire: Modernizing React DOM

#80

Post by TeMPOraL »

Rapzid wrote: post #70
danabramov wrote: post #37

Earlier quoted context omitted.

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.

Yes, but then again, the whole selling point of Github is that it's social media attached to git repositories. That's the reason it's the open source code dumping ground.
Post reply on HN