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)
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)
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)!