Transcript from Thursday January 26th, 2017
# Q: What are your thoughts on Elm? - granmoe
A: I like what I've seen about Elm, and I often recommend it to people looking for a really great developer experience that opens their minds to functional programming. I don't have any experience with Elm's abstractions for building UIs/apps though. I hope that projects like ReactNative can greatly shorten the amount of time that is required for other languages like Elm to support mobile application development.
# Q: Are there plans for bringing React.js and React Native closer to each other? (i.e. for sharing components between mobile and web) - juhasuni
A: Thanks for the question, and this is going to be a long answer.
I should start by saying that this answer is entirely from the perspective of mobile web development and mobile app development. Desktop is an entirely different matter.
I'm going to be a little more blunt, and try to avoid hedging my words about how I feel about the web, and with that carries an increased probability that I say something wrong.
I hope that there are plans for further unifying React Native and React for mobile web. At any given time there's a handful of people (either at Facebook, or other companies/startups) exploring ways to bring RN style mobile app development to the web, and ReactNative seems like a great place to start. One of the things that I'm happy to see, is people implementing ReactNative UI interactions in the same language/runtime that React runs in. That means that sharing more of the code with the web is possible (along with there being many other benefits such as push safety, sharing between multiple native platforms, sharing on Exponent).
There are some difficult challenges with bringing true mobile app development to the web and since I consider React Native development to fulfill the spirit of true app development, it will face those same challenges.
That ability to write a custom gesture handler, or a custom animation, and control every frame of movement on the screen is part of what I believe constitutes the spirit of app development - or at least as developers think about it today. React developers get to realize that today with React Native!
It's not good enough to have to wait three years for browsers to implement some canned interaction/animation (such as a swipeable carousel).
People without experience in platform app development often have the wrong idea - that platforms give you every platform view and interaction and expect you to use it as-is out of the box. It's not the case. Especially on iOS, the platform often gives you the ability to peal back the layers of abstraction and customize views and interactions at a fairly deep level. App platforms give us the ability to implement whatever interactions we need, in user space, with great performance today, not years from now. The web, and key people who are responsible for the advancement of the web as an "application platform" stand in opposition to this philosophy of building mobile apps on the web. This description of the landscape might upset some people, but I'm simply reiterating points and adopting terminology from people who actually build the apps that ship, and choose not to use web technologies for the reasons I mentioned.
These challenges shouldn't discourage us from unifying React Native and React for mobile web - if anything, it means we should be trying even harder to unify the two before this endangered category of developers who see the potential of the web as a true customizable application platform, finally give up.
The web doesn't need a new canned native carousel widget. The web needs the ability for us to implement every last pixel of that carousel interaction at the library level, and with great performance. Whatever is standing in the way of that happening - browsers need to fix it or else the web will be even further relegated to static document viewers.
# Q: Do you use React day-to-day? - vcarl
A: Not much in the last year, since I started diving deeper into language tooling. I am now working my way back up the stack and have resumed using React through that new language tooling. I expect to use it more in the next six months.
# Q: How did you come up with the idea on React? Was it directly inspired by other technologies? Did you try other approaches first which never went public? - Panen
A: Even as I was first learning how to program, the old MVC style of programming with data binding and mutation just never felt right to me, even when I didn't have the technical terminology to describe things like "mutation", or "functional programming". I would find myself structuring my code as much as possible in the (now) React pattern, even in my very first UI programs.
My code would usually look really weird to other people that I was working with because it was typically the only code in the codebase that that looked like React does today - it didn't help that there weren't any frameworks available to help build within the React pattern. For the longest time I just assumed "welp, I guess I'm just a weird programmer". Then I finally took a course on programming language fundamentals (which used ML (SML) for much of the coursework) and I finally had some basic terminology to be able describe how I wanted to build applications. I also learned that the style of programming that I gravitated towards was neither weird, nor new and actually closer to some of the oldest philosophies of programming languages - philosophies which hadn't ever become mainstream - philosophies that the industry had spent upwards of twenty years undermining (in my opinion, to their disadvantage).
One thing I noticed that when people were creating point to point bindings in their more traditional "MVC" app structure, it would almost always end up requiring "computable" bindings which invoke a function anytime a mutable cell had received a "change event". All these "computable bindings" ended up chaining together and small changes would end up causing large recomputation of the majority of the UI. I realized that functions already do transform inputs into outputs, and if we could just find a way to reinvoke those functions repeatedly, and quickly enough, that we could be much more expressive and concise, at not much more performance cost that the chain reaction that "computed bindings" would result in anyways.
To finally answer your question: yes React was inspired by many other technologies including other UI frameworks which we had been using at the time. More than anything, React was inspired by the ML family of languages (including SML/OCaml) which helped me articulate the value (no pun intended) of immutability.
Creating and pushing for the first version of something like React definitely takes a certain ability to discern and ignore FUD when you see it, but ultimately ideas are cheap, and creating an initial version of something is definitely the easiest part. The "idea" of React by itself, doesn't explain why React has become the phenomenon that it has. I believe the culture and energy of the React community is the reason for React's massive success.
# Q: Why is ReasonML the future of web development in general and React specifically?(edited) - kylemathews
# Q: What do you use for state management in your own projects Redux, mobX or something else? - urbanvikingr
A: It depends on the project, but I have a high tolerance for passing props down the hierarchy explicitly, so it takes me a while before I reach for something more involved. I've worked on React apps at Facebook that use Relay to query the server, and I've also built UIs that use immutable data structures as the primary abstraction for storing and sharing data. I understand that these approaches don't work for all applications, and one of things I like most about the React community is that there's always new ideas/proposals for how to structure your app.
# Q: How closely have you been involved in React over the past 2 or so years? What do you think of React now vs how you originally envisioned it? - vcarl
A: The last React application that I collaborated on was the mobile ads manager, and then after that I began to build a prototype for a frame rationing reconciler (providing framework level concurrency) and incremental renderer, where lists of components can be returned from render. I'm happy to see some of those ideas get reimplemented in the upcoming Fiber core of React, in addition to many other features which I had not prototyped such as portals. To answer your second question, Fiber makes me happy.
I still think that there's so many unanswered questions about how we build UI, and we could use React to find many of the answers. For example, how do we integrate layout so that Flexbox can be be implemented in user space and customized at the component level, as part of the reconciliation process? How can we effectively use the increasing number of CPU cores in mobile devices? Do algebraic effects (continuations) radically simplify other abstractions such as "context"? Is there a way to unify animations, layout, and React reconciling?
# Q: When you designed react what were your thoughts on server side rendering for web apps and do you feel they (server side rendered web apps) have a place in industry today. - Macdja38
A: This one is difficult to answer. I'll give a highly speculative reply - which seems better than giving a hedgy non-answer.
If anyone is still surprised that those two things would be separate, then I'd say that illustrates what I believe will be the biggest thing to happen in the next five years, or even the next one year.
# Q: How does React design relate to previous work on Component and Event based systems, like VisualBasic, which Timers and DataSources were also treated as components? Were they a source of inspiration for concepts? - derekstavis
A: Sorry, but I don't have enough context to answer this. I don't know anything about those technologies. Components as timers sounds cool.
# Q: What's the better way to learn and write a React Renderer not targeted for the DOM? - derekstavis
A: I wish I could answer that question better, but Sebastian M is the right person to ask right now, and the answer is likely changing with the introduction of Fiber!
A: It's a great question. React is only (half?) of the CPU time. Even if we make React faster, application code is still going to have to execute, and the best way to greatly improve load time or execution time, is at the language level - across the board, for React and the apps build on top of React, which is why I'm working on Reason. The same kind of deep, aggressive inlining that we want to do at the component level, could be done across the entire app - using ahead of time compilation.
That being said, there are still some things we can do in React to improve React's portion of that time. Right now we have several redundant trees such as the React component hierarchy, the layout tree, and the platform UI tree. We could get rid of a lot of that redundancy by doing layout on the React hierarchy, and compositing from it (like the mentioned react-canvas). I encourage you all to try out a lot of this stuff.
# Q: If React were to be a framework, not just a library how would it look like? - abdellah
A: If I had to guess: React would not be nearly as popular and the community would not be as energetic . In a sense, the community fulfills the role of the framework.