React London 2017 Conference Report

Published on March 31, 2017 by Christopher Zimmermann



While titled “React London”, this conference was not just about a javascript framework, it was about an open source developer community, developer experience, and about developing and thinking on a big scale (aka Facebook scale).

(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.

 

Prettier (New library) Javascript code formatter

https://github.com/prettier/prettier

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.

 

Logux (New library) to improve developer experience of client-server communication

https://github.com/logux

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)

 

Reason

https://Facebook.github.io/reason/

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.

He also shared that he has been frustrated about working with really nice new technologies and principles, but that for one reason or another he has not been able to use on any “real world” projects - it stays theoretical. Therefore he adopts a new strategy, instead of trying to get people to use a new thing - he works to drag those innovative things back into the languages that people are already using. I guess this is like the new features landing in javascript every year now.

 

Snapshot Testing

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.

 

Realtime Webpack

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.

 

Redux Offline (New library)

https://github.com/jevakallio/redux-offline

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

 

Styled-components (New library) & polished (Brand new library)

https://styled-components.com/

https://polished.js.org/

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:

  • Containers provide how things WORK, ie the js logic.
  • Components provide how things LOOK, ie the styling.

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”.

 

React-hardware (New library) Control your arduino with React hardware renderer

Dustan Kasten - Webflow

http://iamdustan.com/react-hardware/

The key point here is that React now provides a renderer interface making it easier to provide custom renderers.

 

Crossbro - React powered Nerf crossbow

Ken Wheeler - Formidable Labs

React powered Nerf crossbow - need I say more?

 

A cool Live Drawing going on throughout the day.

 

Panel discussion with some core React people.

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:

Since the react ecosystem is building to javascript, the source could be in another language - is it time to abandon JS? Panel: no.

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.


 

Themes

Conferences play an interesting role in the frontend ecosystem, on one hand they reflect the current state, on the other hand, they shape it by highlighting certain techniques, or in the case of JS conferences - new javascript libraries. They are almost like a gallery in the art world, or a cultural “salon” of yesteryear. As you’ve seen from the list above - almost every talk highlighted a specific library. But independent of the curation of the conference organizer - certain themes always emerge at a tech conference. Here they are:

 

Removing barriers to collaboration - Open Source communities and Big teams

This came up in Chedaux’s talk on the “prettier” javascript formatting: working to make it easier for people to contribute to projects. Another conference attendee also mentioned this to me in the context of teams split across timezones where the review cycle might be a full day. Anything that can remove the chances of a declined pull request is a big plus.

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:

  • Help with docs. Project creators have a blind-spot here, they know the project too well, and can’t understand what people don’t understand. (I had a Physics professor like that once ;))
  • Manage tickets. Help people who are creating tickets, ask for more info, verify them, help the maintainer understand and prioritize them.
  • Fix bugs.
  • Choose a project that you are actively using, so you (and your company) have an “Incentive alignment”.

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:

  • Maintainer: be polite
  • Contributor: dont be afraid to fail

 

How to get people to adopt new libraries?

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

 

React Everywhere

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

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)

 

Conclusion

And that’s a wrap! Thanks to the Red Badger team and all the presenters and sponsors for a cool conference.

--

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.

https://www.youtube.com/watch?v=1Y-KMQayEX4

Curious? Try out the Magnolia developer experience in one hour.

And, you might like my new blog post: Don't manage the content of your React app.



 



Comments



{{item.userId}}   {{item.timestamp | timestampToDate}}

About the author Christopher Zimmermann

Christopher is a software developer and startup enthusiast with a focus on front-end web technologies. His interest in innovative UI leads to diverse experimentation from phone based GPS services, to Oculus Rift immersive experiences. He organizes the 'basel.js' javascript meetup group.


See all posts on Christopher Zimmermann

Demo site Contact us Free trial