Published on March 31, 2017 by Christopher Zimmermann
(Panel discussion with Christopher Chedeau, Dan Abramov, Lee Byron, Ben Alpert)
In this blog post I hope to get you up to speed on what was presented at the conference. I’ll do a short blow-by-blow rundown of a few of the presentations and then share one person's perspective of the themes that emerged during the day.
Christopher Chedeau - Facebook
At first I was wondering “What does this have to do with React?” But by the end I was hooked anyway. Prettier is basically a project to A. Research the common practices for js code formatting - and B. A tool to automatically apply them to code. Why is this a big deal? Think about the sheer number of devs working at Facebook, how passionate devs get about code style, and the process of onboarding new devs. There’s just a lot of pain and process (and time) around code reviews and nitpicks ie “nits”. Its frustrating - and basically unnecessary. But it’s not just relevant at Facebook - think about open-source projects in general and people trying to contribute. Christopher had a great example of taking the time to fix a bug in an open source library and creating a pull request and everything, and then getting a rejection with some nits for style fixes a few days later. Who needs that? In some cases contributors simply give up. Prettier can solve that.
Andrey Sitnik - Evil Martians
Andrey spoke about the terrible developer experience of working with AJAX, quite convincingly. New es6 ‘fetch’ method examples look nice at first but get complicated in the real world with error and edge-case handling.
Logux combines “Logs” from CRDT (“conflict free replicated data types) and Redux to solve this. Logs store lists of changes (actions) - that get synched between client and server. This solves things like deduplication, handling prioritization of changes, and conflicts. It reminded me of the fun parts of Meteor, optimistic changes on the client that then get synched to the server. It’s in the same space as pouchdb and gun.js.
(Image from Andrey's great slidedeck)
Cheng Lou - Facebook
His wish inspired me: When writing an application, there should be ONLY application-specific code. Think of writing an application today, and how much repetition there often is still, how much dealing with things that don’t really relate to your application. He was also emphasizing the importance of “interfaces” that enable developers to not have to dig into a libraries code - devs know the strict contract that your library, and can trust that it won’t break.
Anna Doubkova - Red Badger
Snapshot tests can be used to make sure that the UI generated by a React component has not changed. You save the output of the component and then in every build you are certain that the output has not changed... or that its time to rebuild your snapshot to match the new output of your component.
Oliver Woodings - Qubit
Qubit is a cloud platform for segmentation and personalization. Each of their customers get a custom React frontend build, and they get a new one anytime they change their configuration. So basically they have a big webpack build farm and he was discussing what they have done to optomize performance. Two main things: Auto-scaling the number of servers based on the size of the job queue. They were able to move all processing to memory, nothing happening on disk. They also did some experiments with using preact and buble (instead of react and babel) and reported big compilation speed improvements.
Jani Eväkallio - Formidable Labs
He was recently on a project where they used React Native to build a mobile app. But the app kind of sucked because you had to be online for it to work. (Don’t you just hate that?) Working offline is important for people who don’t always have a connection - not just growing markets across India, Asia, Africa where networks can be sparse, but also in the London tube (And my back yard in Germany for that matter.) So, redux offline makes it easy by providing a drop in replacement for redux that persists state to your app context whatever that may be. From the docs: “By default, browser environments will use IndexedDB or WebSQL/localStorage fallbacks via localForage, and AsyncStorage in React Native.”
Oh yeah, and he coined the phrase: “Reasonaboutable” TM ;D
Max Stoiber - Thinkmill
With the recent trend of CSS targeted to specific elements (BEM etc), rather than using the cascade, is it not redundant to be adding these css classes to each element, and then defining the style with those names? Why not apply the styles directly? Styled-components introduces a slick way to do this. At first I thought this was ridiculous - css in the js? Shouldn’t we maintain separation of concerns? Shouldn’t a designer be able to work on a different file than the developer? But in conversation with an attendee later I saw that this is preserved if you follow Max’s advice of two different kinds of React components:
So even though the css is in js files, they are clean js files that a designer can work with - similar to how they work with SASS files that also need a build process.
And for those that attended the conference, one additional word: “palevioletred”.
Dustan Kasten - Webflow
The key point here is that React now provides a renderer interface making it easier to provide custom renderers.
Ken Wheeler - Formidable Labs
React powered Nerf crossbow - need I say more?
A cool Live Drawing going on throughout the day.
Christopher Chedeau, Dan Abramov, Lee Byron, Ben Alpert
The slido.com website was used to allow the audience to suggest and vote on questions, which worked really well. There were a lot of “this or this” type questions asking for advice on which library to use. Redux or Mobx? Redux-saga or observables? Which css in js framework? To these the panel invariably answered “Its up to you”. The point is that the team wants the users, the community, to make these decisions. Parodoxically, as the creators/maintainers they feel in a way less qualified to answer those questions as pertains to real world usage.
Some other questions from the audience:
Will progressive webapps take over from native apps? Lee Byron: No, not as long as device makers have a vested interest in native apps. They got burned by that dream before at Facebook when they tried to go fully web stack.
When is Relay 2 coming? Panel: we want to focus as much as we can on improving Relay 1 with the same API, we don’t want to necessitate painful migrations.
What have you learned from other frameworks? Panel: From Vue we are inspired by their amazing documentation and look to it as a lighthouse for their own doc improvements. From Angular they are insprired by the AOT performance benefits. From Ember they are inspired by the great CLI.
What if you could do Facebook.com from scratch? Panel: We woudn’t do it. Everything is developed incrementally which allows us to test which changes are beneficial, and optimize based on those tests. When they have introduced big changes in the past, sometimes it appeared to really disrupt the user expererience - but because the change was big, it was hard to know what was causing the problems.
What is next? Continous work on Fiber, a new core for React which improves responsiveness of animation and interactivity by enabling the system to prioritize certain events and re-renders.
How can the maintainer of a project keep up with a lot of bug reports and pull requests coming in? Lee Byron had good advice: recruit! Find passionate users of the library to help triage the issues to determine the core areas requiring improvement. The community often understands the use-cases better than the developer, so it’s valuable to have them involved. Lee also had good advice for how new contributors could best help:
But, don’t try to add new feature as a new contributor. Especially for big projects (react, etc) there are so many factors going into planning that you are not in a position to understand.
Andrey Sitnik also addressed this in his talk - he boiled it down to:
Hmmm, why would this topic come up at a JS conference? ;D Christopher Chedeaux realized that at least internally at Facebook, he couldnt “push” the “prettier” library to the teams. It had to be on a “pull” basis. Someone (who was it?) talked about creating buzz - but almost at a literal level: he monitored twitter and retweeted/responded every time there was any mention of the library. Cheng Lou also addressed the topic, but with a different tactic - when the library doesn’t get traction, work to bring that hot feature to the library or platform people are already using. At Facebook, devs still wrote PHP, but it got compiled to C++ for production.
Oliver Woodings from Qubit brought up a related topic. He was hoping “the community” would get on board with ES6 as soon as possible. Why? Because then he could make their webpack builds even faster with “tree shaking”(removing code paths that will never be used.)
Of course the adoption on the web has been huge, but it's interesting to see it picking up elsewhere as well. React Native allows building native web apps. A recent Angular native experiment used React Native under the hood (even native mobile developers are expressing intererest in React Native.) Desktop app development with Electron. React hardware. React VR. John Carmack recently tweeted about the dev speed benefits of using React for UI elements in VR app development.
Developer Experience is one of the big draws of React - from being Reasonaboutable TM, to having great error messages in the console, and so forth. Of course there is debate about what makes a good developer experience - in the panel when asked about “Redux vs Mobx”, Dan Abramov (I believe) replied that it is a stylistic preference: If you want simpler looking code, go for MobX. If you want more verbose, but probably easier to debug later, Redux might be a better choice.
Some libraries seek to ease adoption by mimicking known API’s. Redux Offline appears to be a drop-in replacement for Redux. Logux intends to do a similar thing matching the Relay API. On the other hand, true to the React tradition with JSX - other libraries blow away all conventions: “And now for something completely different”. The styled-components library invites you to do your styles directly on React components, and your SASSy things in pure JS with polished. It throws me off-balance, but it’s great that people continue to question the established “best practices” - keeping them from becoming pure dogma.
(Another image from Andrey's great slide deck)
By the way, we were one of the sponsors of React London 2017. We’re trying to get the word out about the great frontend developer experience in our enterprise CMS, Magnolia.
Here’s a 30 second intro to our CLI.
And you might like my new blog post: Don't manage the content of your React app.
See all posts on Christopher Zimmermann