Suggestion: consider using React "Native"

[necolas]

I was reading through the docs and intended feature support, and on first appearances I think the web version of React Native could be a good fit. And if there are rough edges that you come across, I'd be interested in smoothing them out.

There's a lot of out-of-box functionality and stronger guarantees. Automatic RTL layout of the chrome GUI (runtime toggle too). Styles are resolved deterministically; your current css-in-js library was based on RNW but doesn't provide this guarantee. The style mechanism also accounts for dynamic styles in the render function, and use outside of React via setNativeProps (roughly equivalent to using findDOMNode and mutating directly). The components also have built in mechanisms for measuring or responding to layout. And plenty more.

If you're interested in looking into it, or have any questions/feedback, I'd be happy to help

[nathansobo]

Hey @necolas. Thanks for the input. I'm definitely open to it. I actually did some research into react-native-web early on, but ended up deciding to just use React at first because it felt like a more trodden path and just a more basic place to start. Not exactly a super deep technical analysis.

My main concerns with react-native-web are related to support and ecosystem. Will we have access to the same features that come out on standard React? Also, I'm still not super clear on the exact problems it solves assuming we don't care about rendering on mobile. So yeah, I guess I'm interested, but to justify using something other than the mainstream React I need a really clear understanding of the benefits. The deterministic CSS stuff is interesting but seems solvable on its own. Maybe I should take a deeper look. Maybe you can help me understand your view of the trade-offs as well.

[necolas]

Thanks, I've tried to answer some points below. Will close this as it was just a "have you looked at..." issue.

My main concerns with react-native-web are related to support and ecosystem

So far it's been supported for over 2 years with over 160 releases. The ecosystem is tied to the large React Native ecosystem. RNW is currently used in production by Twitter, Flipkart, Uber. Twitter is using it for desktop and mobile web UX in the upcoming replacement of twitter.com with mobile.twitter.com.

Will we have access to the same features that come out on standard React?

By "standard React" do you mean React DOM? The DOM APIs change very slowly so React DOM is pretty stable. RNW is actually built over React DOM which means you can use 'react-dom' directly if ever needed. This is how Twitter can incrementally concert components to use RNW too.

I'm still not super clear on the exact problems it solves assuming we don't care about rendering on mobile.

As mentioned above, it's not just for mobile. Other problems it solves are deterministic styles with minimal footprint, prefixed styles, built-in RTL layout support, subscribing to element layout, built-in layout measurement, accessible interactions via kb, mouse, or touch inputs (eg Surface laptop support all 3 at once). And it provides higher level abstractions for building UI than you get from the DOM. All of this is built into the framework and the component props.

to justify using something other than the mainstream React I need a really clear understanding of the benefits

Sure. Think of it more like a component library for React DOM. Your requirements are not met by React DOM, that's just a React API for the DOM. Whereas Facebook designed React Native for app developers and a lot of tools we need to build web apps are built into it. The styling alone provides guarantees, performance, and dev tools integration which most web css-in-js libraries do not.

The deterministic CSS stuff is interesting but seems solvable on its own

It's not unless you want to design and build your own library, but React Native has already done the work https://github.com/necolas/react-native-web/blob/master/website/guides/style.md#how-styles-are-resolved

In contrast, libraries like styletron have determinism issues that can be difficult to debug when components and styles are composed.

Maybe you can help me understand your view of the trade-offs as well.

IMO what you lose is relatively limited because you can use one of several escape hatches whenever needed, including using it alongside any vanilla JS or react DOM code. You buy into a stricter contract with more powerful primitives in the places you benefit from that. Most notable is no support for state in CSS - media queries, hover. In reality I think non-trivial apps benefit from this as you need to replace or update components in response to layout changes anywhere in the tree, rather than only change styles when the viewport changes.

[nathansobo]

Thanks very much for the thoughtful reply. I will give it a closer look. The benefits you mention to indeed sound compelling to me.

[necolas]

And FWIW, I understand that trying new react tools isn't the priority for xray. But as someone who understands the specific requirements of xray, I would be interested in hearing any further thoughts you have, or any issues you might identify, even if it's just exploring in your own time and not for xray. Thanks!

[cztomsik]

This might be interesting alternative too.

It's a GPU-based (webrender) and there is absolutely no DOM or CSS involved. It's currently a subset of react-native with aim to be react-friendly cross-platform UI for desktop applications (not there yet at all).

Footprint is 50M including npx ts-node so it should be around 30M with react if precompiled.