One of the other uploads that I thought would be worth curating a few items from at the recent React.js Conf is the Q&A session with Facebook’s React.js team being quizzed by the audience.
The first poke was in relation to the prototypes that run React apps in a web worker, “I’ve seen proposals for web workers and this native stuff is the exact same architecture as the stuff I think we might be doing, are there any plans for that or is this just an idea?” (go to 1:52)
Sebastian Markbåge responded by saying, “There’s definitely plans for that, it’s more experimental at this point and the architecture is slightly different, it’s a way to think about React on two sides of a worker. The initial web worker stuff that Pete Hunt did was similar in the sense that it had a web worker running React but on the other side there was no React, it was just a DOM, so it went from React to an asychronous parallel API and that’s the same model as React native. The model that I’m thinking about now is React on both sides of the worker and how would you do things like deep updates and stuff like that… currently React now bottoms out. That’s very experimental but it could allow us things like having very slow components run on a different worker and very critical components running on a different worker and them not colliding with one another.”
One of the challenging questions was about server side rendering, something which Markbåge later explained was not designed to be that way and how whilst there has been a lot of thought put into the rendering mechanics on the client there may not be quite as much thought put into the the server side rendering component and there is a lot of stuff that maybe doesn’t really make any sense to be there. (go to 5:32)
Jing Chen responded by explaining, “for the web version that we are building there are actually multiple modes so in the default mode (the normal mode you would expect) you can run everything on the client but that would actually require a separate round trip to the server for data once everything comes up. So what we do is run on the server to generate the query to start with and then we run that query on the server as well and what we send down to the client is all the JavaScript you need to do the rendering and all the data that you have fetched. The other mode we actually have server rendering as well so you get both the mark up and data needed for your page but I think that is less efficient because you see your mark up early but everything gets hooked up later so there is a spectrum of what we would do in terms of which mode works best”
Someone also probed into the sort of sustainability of React with updated operating systems, “Whenever we have used or looked at frameworks in the past that wrap in one way or another native OS’s there is this danger that new iOS, new Android and so on comes out with lots of new features and then you’re at a disadvantage, it sounds like with the bridging we can just write native code that just bridge to that would use the new features but is there a plan to support new OS features or is it the community that is going to be working on that?” (go to 14:00)
Tom Occhino gave a reassuring and comprehensive response saying, “There are actually two approaches to every component, you can either do, what we call internally, wrap or reimplement. There are cases in native when you want to reimplement so for example, the tab bar at the bottom of the Facebook iOS app is actually a reimplementation of that in native and so there are times when you actually want to reimplement and get flexibility that native widgets can’t provide. The wrapping is perhaps more flexible because as long as the public API of that doesn’t change you can actually create a wrapper that would work across, for example, an OS update. Let’s say from iOS 6 to iOS7 the look and feel changed of the native navigator, but the API to that thing didn’t change, it’s still the iOS navigator. You would get that for free if you are just wrapping but if we are using our reimplementation of the tab bar, when (for example) iOS8 comes out we would need to reimplement that thing to look and feel like the new operating system. In summary, you’re never going to get this a hundred percent for free, anytime there is an operating system update, you have to update your app to look like it… the thing that makes this different is now you kind of have the option of, do I want to reimplement and get a little more flexibility using JavaScript or do I want to wrap and then potentially get that upgrade for free.. so it’s kind of up to the developer.”
One of the last questions in relation to webpack and how Facebook might use it prompted more of an insight from Occhino about what they use internally, “we don’t use webpack for Facebook.com, the things that we use are a packager and two systems, one called hace which does our dependency management, and one called may case which does all our transformations. We have a lot of transformations which are not part of react and aren’t public because the are just tied to our infrastructure so we have an internationalisation transformation, we have transformations for GraphQL and other proprietary ones. The way that the systems works is actually pretty interesting, our packager uses machine learning so what we do is log production data so anyone that requests a package we log that it was used and then we put all of that into a big database and once a week we process that and figure out what next weeks site is likely to need and package everything up based on that.. and have zeroed in on the most optimised version of this packager.”
That’s the base the answer, Occhino holds his hands in the air with a grin for going several layers more than necessary in answering this question but for the full response (go to 22:55)!
