The Facebook(React) Way
As a social scientist I have been doing anthropological research within the technology sector where I have set out to look at developers/designers and how they adopt, readopt, and abandon new technologies. Recently I came across this article (http://www.tidev.io/2015/01/30/reacting-to-react-native) ,, it attempts, to make it very clear that what Facebook has developed within React Native, is exactly what Appcelerator “has been doing for years” so this started as a draft(this is not a conclusion of my research, but rather just a response in the same field) of a response that looks into the wider phenomenon of adoption.
(Given you don’t want to read for the next 6 minutes, I’ve summarised it near the bottom.)
…I also think you may be missing something to do with React Native and why it’s been such a star. React Native fits into a hero’s narrative that Titanium currently does not;
Once Upon a Time…
ReactJS had a slow start, because of it’s subtle description, the “V” in MVC. Many devs couldn’t (without thinking very hard) see how it would fit into their stack and less could understand the benefits. But what was brewing in the undercurrents wasn’t a library that just worked on the “V”, but Facebook was working with/on what would later be seen as a paradigm shift and a dismantling of MVC. While many devs in the industry kept developing in the MVC paradigm and still do, they weren’t openly questioning MVC but rather kept working through it, consequently they became very familiar with the same sorts of problems that Facebook would set out to resolve. Getting tangled in too many models and controllers, or laying out the view appropriately without being controlled by your models and sharing data between each and so on.. (This isn’t exhaustive or an essential list, just some of the problems I’ve heard in interviews or second hand).
Meanwhile in Mobile App Land
Meanwhile, on the mobile app side, after not too long ago, the “hybrid” apps sector suffered a stigma for several issues but I focus on the problem of authenticity; these libraries weren’t just “difficult” to use or limiting, but how it grew into the culture as something not “authentic” or pure to form had all the right ingredients to create a cultural taboo. A very divided community of native and non-native devs remains on this very cultural understanding of what is or isn’t authentic. You can say that Titanium is “native” or that React Native is “native” but you miss the point of how the tech culture experiences such things in the context of what it means to be a native developer vs a non-native developer. This is also a externality of the cultural value I’m labelling purity here; the same value or cultural belief that created the “emacs” and the “I only use a text editor for development” culture. In this case it is enacted through using the right framework for the right job. Bypassing the “I only use a text editor for development” and “always roll your own” practices and inherit values, meant there was likely a cultural shift where practices shifted towards the higher order cultural value to sharing and “rapid iteration”. Some of the old values begin to look very perverse to the newer generation that was and is fastly adopting fully fledged IDE’s like Jetbrains, and the new rites of passage that include making contributions to libraries on github, and especially the right libraries.
So as the stigma has and is gradually lifting, it is in stride with the cultural shifts I talked about earlier. Along with overcoming technical barriers, solutions like Titanium and Ionic get wider access to those who can now consider it an option culturally even if they could have long before this given that it has become culturally “ok” to be a developer that creates “hybrid” apps, but there is still the knowledge of tradition and the native still is king; my research reveals how some tech houses use solutions like Titanium and Ionic as “placeholder apps”, keeping in their mind that they will eventually hire an in-house iOS and Android developers to build the “true” or “real” apps, which reveals the hierarchy and exposes a specific groups mental model around authenticity in practice.
Back to React
Coming back to React, we started to see devs tinkering with ReactJS, largely in part because they could implement it in existing project without much fuss. Where as some other frameworks are structurally built as “new projects”, say using Rails, ReactJS looks and feels like a “drop in” like jQuery or many other front-end libraries. ReactJS wasn’t selling itself, it seemed ambigious, but since it allowed you to try it on an isolated part of your app, you could try it with very little risk of breaking your current stack. Many devs did exactly that, isolating one feature and testing it against their current workflow. As Facebook paired ReactJS with Flux, it “felt” to many devs like a progressive step and shift away from a traditional understanding of how apps should be developed and towards the future of apps. After it was confirmed that a flurry of big name tech houses, with influence in the dev world, were using ReactJS successfully it resulted in React and Facebook’s approach becoming a hero and salvation taking on what a large segment of the tech world agreed were worthy issues to tackle. Facebook seemed to be making a shift that many others couldn’t afford to do (not just monetary); since many houses were so heavily invested in MVC they were searching for better MVC frameworks rather than rethinking or questioning the paradigm altogether. Changing paradigms isn’t just technically difficult, it’s culturally difficult; but ReactJS was built to allow a subtle entry, which slowly builds itself into a full shift, infecting those with “The React Way” of thinking. First devs use it just for the view as it says, (notice it says other people call it that, not itself) as a result you get to see the paradigm in practice. If you agree with it and feel a relief, a turning from the old tradition into the new, you begin to apply it elsewhere. (this is also culturally significant because devs have come to expect “full-fledged” frameworks, more advanced devs seem to know how to create stacks while another segment of devs either don’t possess the know-how to create stacks or don’t want to add on the complexity, which drastically changes the amount of devs who can adopt at all). As a result devs end up diving deeper into the source, which Facebook contorls, gaining more social capital from through the everyday action of going to Facebook as the main/“pure” source to learn The React Way. This may not have been intentional by Facebook, and of course it doesn’t always result in a full conversion, but the numbers are growing at a rapid pace as this small library, it’s creators, and it’s friends (Flux, Nuclide, Relay…) are just getting started taking on a long held tradition whether that is their intent or not.
Facebook — Now Developer Approved
The Facebook F8 Conference seems to be the tipping point for Facebook and it’s relationship with the dev community (minus the current open source patent issue), helping further shift the community’s former cultural understanding that was “ a group of hackers who use PHP(a programming language already stigmatised )”, to a world class group creating next generation tools that are empirically sound as the collective imagining sees Facebook in production pulling gold out and giving it to the open source community. I posit that their presence this year will likely be it’s largest year of dev converts in it’s history and this shift will be a more permanent one that establishes them if it hasn’t already. Take events like the recent React and Angular team meetup which transferred Facebook much more social capital as it painted a picture of a humbled Google taking notes from Facebook, only furthering the hero narrative with Facebook and The React Way at the centre of it.
[I digress: (Disclaimer: I haven’t conducted any ethnographic research on Angular) Google’s AngularJS is another interest of mine, I’d like to focus on in the future but what I can say for now is that Angular seems to be doing what jQuery could not allow itself to do; transform itself in a way that would be experienced as, a tearing down of some of it’s early pennants within it’s own tradition. I posit that Angular faces huge resistance to change because devs using it right now have a sort of functional and paradigm fixedness that the Angular team no longer believes in. Some devs have spoken of Angular 2.0 being like a betrayal, but hopefully it’s for the better. We’ll see.]
The result is that Facebook and it’s React family is shaped into a sort of salvation, where many devs will try to “Reactify” everything in every way. So when someone makes a claim about how React Native copies Titanium, it misses all the cultural construction that has lead up to this point. It’s not that Titanium or Appcelerator didn’t do a good job getting this out, but it’s the interplay between narratives, cultural values, and the right shifts at the right time that stand behind this “craze”. People will adopt React, despite standing solutions. This is not a matter of presence, this is about culture and the temporality of culture.
Unpacking your company or brand is about finding it “out there” with the people using it. Whether that’s using your product or it being used in conversation by someone who has never used it before. Mental models are incredibly powerful while cultural transmission helps build these models that are enacted in everyday interaction between devs. Unpacking is more important than creating more documentation and/or boosting $$ on marketing. Riding the cultural wave takes a sensitivity especially if you are starting on the outside of it. First you can start by understanding the cultural reactions to new technologies including yours. Mapping yourself and other tech against cultural practices and their implicit values can open up a new understanding of the dev world. Take Appcelerator’s; though I haven’t done any extensive research here, it seems targeted at devs who may have used or heard of non-native hybrids looking for something “as close to the metal” because something is preventing them from going all the way there. If a dev was competent in iOS would they buy into Titanium? I’m unsure, but don’t think it’s likely. Many devs believe that being “native” means being idiomatic, for example a native iOS app most likely requires that you develop code using Objective-C/Swift and probably within XCode. As I have further unpacked these specifications it seems unlikely that devs see using HTML/JS within an iOS app as something that is “truly native”, this is not based just in the technical, but the dev culture’s shared values of what is authentic, pure, and true to form.
The “selling point” then isn’t “nativeness” but it’s “Reactness”.
Facebook and contributors are building “The React family” by applying the paradigm in different places (i.e. Component Kit). So the difference between Titanium is that it doesn’t take on “The React Way” and isn’t responding to the same cultural issues that React is doing today. If FB would have created a native framework just like Titanium without the paradigm shift, I don’t think it would be such a hit with devs.
The Cultural Turn
By framing MVC within the cultural narrative, we see that it is positioned as the lever of the cultural turn and it becomes essential to the turn towards React because something needs to be displaced or transcended to complete the turn. The turn itself requires a project, the agency and motivation to abandon a project driven by a parallel transcendence target. The transcendence target in this case is the “React Way”. MVC becomes a causal object of the groups larger problems in which a cultural aversion is developed. Looking at the manifestations of this developed cultural aversion, we can see that it’s within the every day conversations and interactions that the aversion is spread and “the turn” progresses. Something happening now, is that devs seems to be redirecting their frustrations from framework/language towards MVC(paradigm),
From:
“I dislike framework x, it’s issues are x, y z”
To:
“I like framework x but I end up with a problematic MVC framework that has problem x, y z”.
This aversion makes a key set of problems inescapable unless they abandon the paradigm altogether.
The turn doesn’t just make it normative behaviour to abandon or talk openly about frustrations but also reveals to others what could be behind their issues which calls for a reframing of their past; they can begin to hook onto memories and relabel them as MVC issues. As the “turn” grows (or shrinks) out and within a community, in order to keep growing members need to be equipped with a way to complete the turn. In my talk with devs with less experience in MVC and development in general, they revealed how they easily see why “The React Way” is better; pointing at it’s unidirectionality or it’s virtual DOM, but surprisingly it was harder for them to explain why the DOM was hard to work with in the first place (Why is the DOM slow) or how MVC data flow made it problematic. I posited that this layer of the conversation was not technical knowledge but cultural knowledge developed into a sort of shared rhetoric. This shared rhetoric is a key strategy and tool that arms and empowers other developers with the ability to convince themselves, and other important stakeholders.
At the phenomenological level, we see a picture of a developer seeking out articles and case studies that might resolve their “pressing” concerns. These concerns will often be shared and the existence of such articles and case studies are probably a response to those concerns. Take the question below.
“Are stores == models?”
This attempt to map out the operational definitions per paradigm, shows just how entrenched the “MVC way” is. Consequently, some developers are sensitive to how other developers model the new in the frame of the old, writing explicitly to prevent the mistake, asking dev readers to suspend their 1 to 1 mapping as they learn React/Flux.
“Do not think of Flux/React the way you think of MVC”
Every article written has it’s own reason for existing but for the turn, these articles become essential to lowering the cost of entry, allow me to explain. Many articles on React are meant to resolve the pressing concerns of developers migrating from the former tradition. Article authors are actively creating paths for developers (readers) to buy in or not. Given there are articles that resolve developer’s pressing concerns, the path seems to be continually made easier. Though it may not be this straightforward, this knowledge development is essential to the uptake of the new paradigm.
To complete “the turn” the group must enable it’s members to debase the initial project. The more significant or impactful the “turn” the more likely it is that members were more equipped to debase and disarm the tradition moving from the ability and motivation to convince oneself to empowering and inspiring others which create the smaller revolutions. As the communities collective actions begin to sweep through the rest of the culture, “The React Way” can become something inscribed on the “collective sense” experienced as something that “feels” right while being equipped with the sensitive knowledge and rhetoric to legitimate their use of it.
Despite many devs knowing that reactive, declarative, unidirectional, and all of the concepts that React + Family has built-in already exist and aren’t “anything novel” as some devs have reacted, they are missing the cultural context in which these events are taking place and obscures what is actually happening underneath.
Key points:
In my opinion Facebook has officially(culturally) legitimised itself as a credible institution within the wider dev community paving the way with a new paradigm, a new way. Here’s what we can learn from the Facebook React/Way.
It’s about “the way”(paradigm) not necessarily the tools.
Understanding cultural narratives within the community can reveal why certain adoptions that seem “overrated” occur. It can reveal what you’ve become to “the people”, providing a grounded alignment of how you are experienced and perceived by the culture. Given you develop a firm grasp of this understanding, you can then decide how you’d like to move on with the narrative.
Your company/org is experienced as a paradigm that people can buy into, a paradigm that devs will argue for, with, or against.
Understand that devs aren’t just focused on what’s better feature-for-feature, nor are they just making rational decisions based on performance.
Whether the phenomenon is two mammoth’s like Facebook or Google having a publicly noted meeting, or an “overrated” tool that gains more followers in a couple of days than it’s nearest competitor receives in months, or the rise of Ruby on Rails only to start losing traction to a language that many people hated a few years ago (Javascript), these shifts are all underpinned by culture and their interaction with technology. One phenomenon at a time, technology adoption today is situated in a tradition and tangled in shared cultural practices, narratives, hierarchies, within a network of actors with ever-shifting influence and relevance. As I’m currently still in research(ethnography), I can say that it is pointing towards the moment when a dev thinks he/she is making a “logical” or “technical” decision, but really the decision is situated in “webs of significance” of the not-so-technical.
that man(woman) is an animal suspended in webs of significance he(she) himself(herself) has spun, I take culture to be those webs — Clifford Geertz (Anthropologist)
Given we are creating solutions for any group of people, we must take in to consideration not just features of technology but the features of culture to develop an understanding the provides us with a starting point to create solutions that resonate with the people we are designing for.
Christian Ramsey @ESP Collective Social Scientist focused on ethnographic research to unpack the cultural practices and symbolic interactions between developers and technology.
