Twitter | Search | |
Nicolas
Some thoughts about React Native for web developers. I ask that you first forget the name, forget how it works, forget the rough edges, forget web tribalism, forget what your favorite web developers have said about it 😅
Reply Retweet Like More
Nicolas Apr 10
Replying to @necolas
"Feels as good as native" is about as ambitious as web UI gets today. It's punishingly difficult to get there if you start with DOM representations. But you essentially get there out-of-the-box with React Native, including on web!
Reply Retweet Like
Nicolas Apr 10
Replying to @necolas
React Native is decoupling how you describe UI from how it is rendered. In contrast, React DOM makes you describe UI using representations of the render target, i.e., DOM. Targeting the web is important; directly working with DOM representations (although familiar) is not.
Reply Retweet Like
Nicolas Apr 10
Replying to @necolas
React Native allows you to describe interactive and highly dynamic UI that is good enough for many of the world's best *native apps* but without directly using representations from any one platform. RN is in part a component library for platform-independent component libraries.
Reply Retweet Like
Nicolas Apr 10
Replying to @necolas
React Native is a rough first draft of a framework that is not directly coupled to an individual platform's primitives. This means you can describe the majority of your application UI in a simple and expressive form that can then be rendered by a variety of "backends".
Reply Retweet Like
Nicolas Apr 10
Replying to @necolas
Once you also have *better* web apps described using this vocabulary that is not a direct representation of DOM, it can create new possibilities for how those apps are rendered on the web. DOM is just one part of the web stack.
Reply Retweet Like
Nicolas Apr 10
Replying to @necolas
react-native-web is merely a first step in boostrapping this transition for React web apps in a way that's backwards compatible with react-dom. In the future the backend implementation might be a mix of web technologies including DOM, WebGL, wasm, Workers, etc.
Reply Retweet Like
Nicolas Apr 10
Replying to @necolas
Decoupling how we describe UI from the platform it renders on (even if you only render to the web!) can facilitate accelerated innovation for app developers, framework implementations, and geometric authoring tools.
Reply Retweet Like
Nicolas Apr 10
Replying to @necolas
In some ways React Native is part of the boring machinery we need to build to radically rethink modern UI creation as an activity that need not be performed by expert designers/engineers in code/picture editing tools.
Reply Retweet Like
Nicolas Apr 10
Replying to @necolas
Defining and controlling every bit of design and behaviour in code is already quaint in the fields of computer games, machine intelligence, etc. I see projects like React Native as potential stepping stones towards building more UI with our hands and in partnership with machines.
Reply Retweet Like
James Long Apr 10
Replying to @necolas
I love this vision. I use `View` almost everywhere in my app because I fell in love with it from RN. One thing I'd like to see a more modular approach where I can, for example, use Glamor for styling if desired. Seems like we need to establish what the low-level APIs are...
Reply Retweet Like
James Long Apr 10
Replying to @necolas
for styling to get this to work. Then glamor can have a backend which targets it. Maybe this applies elsewhere too.
Reply Retweet Like
James Long Apr 10
Replying to @necolas
It's a balance - finding the right APIs that start with the right terms, but don't differ too much from hosts to cause perf problems. (I have a very perf sensitive part of my app that react-native-web didn't do as good on, honestly. but I love your work)
Reply Retweet Like
Sebastian Markbåge Apr 10
Replying to @necolas @jlongster
Btw, I just changed StyleSheet.create to be the identity function. We won't really special case static in this way because of merging. I think it's likely we'll drop the whole function in the future. We should chat about that though.
Reply Retweet Like
James Long Apr 10
Replying to @necolas
I'd love to understand this better, but probably requires an in-person meeting. fwiw I love using only real inline styles (<View style={{ color: ...}} />) and I have a build step which hoists as much as it can (almost everything that's not dynamic).
Reply Retweet Like
James Long Apr 10
Replying to @necolas
I'm not entirely sure, but I was running into some perf problems in a very large DOM-heavy table that has bi-directional scrolling and animations. Deep profiling kept showing the styling system (and other stuff) in RNW coming up (not at parent, but self cost).
Reply Retweet Like
James Long Apr 10
Replying to @necolas
I removed it and tried glamor and the combination won out. I was trying to use `StyleSheet.create` but part of the problem may have been that I was still doing too many inline styles.
Reply Retweet Like
James Long Apr 10
Replying to @sebmarkbage @necolas
I sense some symbolism in this change of execution...
Reply Retweet Like
Popmotion Apr 10
Replying to @necolas
Surely this approach blindly chucks out non-semantic markup onto the page? Unless there’s some sort of prop that changes the element being rendered. At which point we’re back at...
Reply Retweet Like
Mathias Vagni Apr 10
One thing I've never understood is where web specific semantic things are captured. I'm talking about aria stuff and specific tag semantics like ul's and table's. What's the way to go? Any recommended reading ?
Reply Retweet Like