The first ever ReactConfAU was held in Doltone House on Sydney’s Jones Bay Wharf.

Greeted with a smoking ceremony and fired up with Little Marionette coffee, 500 people found their seats and settled in to fill their brains with Reacty goodness.

Questions from speakers about “Australian food” led to discussions about Gaytimes and fairy bread, starting with assurances our MC, Jess Claire, absolutely wasn’t making this stuff up on the spot. We also discovered it’s difficult to entirely explain the significance of the sausage sizzle.

Disclaimer & Credits

  • These notes were hammered out very quickly and paraphrase what speakers were saying. If you need an exact quote, use a definitive source such as a recording or slide deck.
  • Photo and other content credits as per the social media embeds.

Jump menu

Day One

Day Two


Keynote – Max Stoiber

Max is here to talk about the past, present and future of CSS in JS/styled components. Max, obviously from his history, loves open source.

A brief refresher on CSS in JS – writing CSS and having it applied via a hash-based class in the HTML.

Max loves this because…

  • confidence – any given style is only used in one known place
  • painless maintenance – no “append only” stylesheets
  • enhanced teamwork – not everyone has to have an encyclopedic knowledge of CSS
  • fast performance – (noting some people disagree) only the CSS you need for the current view is loaded
  • dynamic styling – theming in CSS in JS is highly dynamic

CSS in JS guides you to the “pit of success”. That doesn’t mean you can’t fuck it up! But it means you won’t have some of the common problems. It’s popular – 60% of React installs also install a CSS-in-JS library.

But it wasn’t always this way. A brief history:

  • Nov 14: JSS (first..!)
  • Nov 14: @vjeux
  • Jan 15: Radium
  • Feb 15: Rebase
  • May 15: CSS Modules (not technically CSS-in-JS but popularised hashed classnames)
  • Sep 15: CSJS (introduced strings of CSS instead of CSS in JS objects)
  • Oct 15: Aphrodite (critical CSS extraction)
  • Jun 16: Fela (style as function of state)
  • Jul 16: Glamor (performance by skipping DOM)
  • Oct 16: jsxstyle
  • Oct 16: styled-components (popularised the style.div API)
  • Dec 16: styletron
  • Dec 16: styled-jsx (style tag API, so you can write CSS as normal)
  • Mar 17: Astroturf (extracted styles out to .css file)
  • Apr 17: Glamorous
  • May 17: styled-components v2 (stylis as CSS parser of choice)
  • Jul 17: Emotion (pushed performance)
  • Sep 17: Linaria (extended static CSS extraction)
  • Nov 18: Emotion v10 (css prop)
  • Jun 19: theme-ui (consistency via theming)

Max loves all of these! It doesn’t matter which one you use. These projects collaborate all the time and push each other to make things better.

We need you to create the future of styling React apps!

Tips for making a CSS in JS library (or any open source project):

  • make it work, then make it right, then make it fast – most projects start as a hack to see if it works at all
  • share early, share often – get feedback, iterate
  • document all the things – if you don’t have documentation, people won’t use your library!

If you have an idea for a CSS in JS libary – build it!


Themeability is the path to dark mode – Diana Mounter

Diana works at Github… “if you haven’t heard it, it’s the American version of Bitbucket”

Design Infrastructure started as Design Systems in 2015 and has grown to a large team. It looks after Github’s design systems, core experience and engineering application of design systems.

Colors are cultural creations and they’re kind of shifting all the time, sort of like tectonic plates. Color is not a precise thing. It’s changing, it’s living, it’s constantly being redefined and argued over and that’s part of the magic of it – Kassia St Claire

In 2017, Github’s design system team only had two people facing a mountain of technical debt. The stack included utility CSS, BEM, Sass and Ruby on Rails.

There was no colour system, but it did have 2449 hex values! ...not ideal. They updated the site, got rid of the drab, dull old colours; improved the colour accessibility; rationalised the hex values to Sass vars. They also introduced new colour scales.

DX (dev experience) improvements – variables, ability to update colours across the whole system, consistency, ability to lint against non-system colours.

Their idea was to have system variables abstracted behind functional variables; but the colour vars ended up being used directly. Their stack could only get them so far.

They wanted more leverage, a greater ability to make one-line changes to update system-wide things. They moved to styled components to do this (specifically styled-components and styled-system). They needed to get away from CSS leaking into unintended places – they even had an outage related to this. They wanted style encapsulation and predictability.

They started thinking about the kinds of styles they had:

  • layout
  • common components
  • theme

So they categorised the props for their components accordingly; and created arrays of colours so they could use themes/colours as props in their components.

Colours were grouped as “schemes” (they’ve since moved to 'variant’).

Themes are composed of fonts, colours and spacing. Common theming patterns are defined as variants inside the components.

So what about colour modes like dark mode? Users clearly want it! There was a google chrome plugin with 20k downloads, applying a dark mode.

Working with colour in dark mode is interesting. People tend to think you can just flip the colours. Diana tried this as a hacky trial and it doesn’t really work. Some colours work very well, but others are lost in dark mode. Some colours need to be shifted multiple steps up the colour scale. Lots of hue and luminance adjustments are required to give the same impression and feeling as the light mode colours.

A simple test: show the flipped version (eg. black text on white; and white text on black) and see if one feels more bold/heavier than the other.

Dark mode is not an inversion, it’s dimming the lights.


To recap, in dark mode some colours moved significant steps in the scale; and others had to be adjusted even more significantly. You ultimately need a different palette for dark mode. While similar they won’t be the same; and some colours will need drastic changes.

Functional naming helps a lot. Presentational names make it too hard to track and apply colours – variant 'green’ becomes variant 'success’. (if you work with Rails this is probably interesting to you!)

Color is the most relative medium in art – Joseph Albers, Interaction of Color

So many things influence how colours are perceived, we can’t control them all. We can change our code but not the context the user is working in – where they are, what device they’re using, if they have any disabilities (permanent or temporary) impacting their perception of colour.

Perfect is the enemy of good – Voltaire

Don’t let something being just 'good’ get in the way of shipping it!


(Proto)typing innovation in BBC News – James Dooley

James works on the BBC News Labs – they’re trying to future proof news. Driving innovation in the newsroom by experimenting with new ideas and tools. They have engineers working with journalists.

Two main strands:

1. improving production workflows, eg. translation workflows, video production workflows
2. new audience experiences, eg. news via chatbots, voice interfaces like Alexa

Example – “Skippy”, a skippable news app for Alexa. It started during a hack day. The core idea was to let you go through the top news items on the BBC, skipping the ones you don’t want to listen to. That worked and it was actually pretty useful… but they wanted to do more – BBC produces about 57 hours worth of content every hour.

They started with a create-react-app prototype. They needed a way to cut up their radio broadast to grab highlights… and it turned out someone had already built something for that in React! The prototype quickly showed that content producers really loved drag and drop interfaces and tree-based UI… and those existed too. So they could quickly work out what the flow would be on an Alexa.

They could go from hack day, to prototype, to production… and now there’s a whole team of people producing content for voice.

React lets the team move quickly and not reinvent the wheel. They wanted to share back as well. So they did this with transcription – which is at the heart of a lot of content production. Transcripts are used to plan stories, produce content, then deliver content with appropriate accessibility and searchability.

But one hour of media takes 3-4 hours to transcribe manually. This is laborious and time consuming, and people still do it. You can outsource to agencies – which has good accuracy, but it’s slow and expensive ($60/hour). You can use automated transcript apps – faster and cheaper ($10/hour), but not accurate.

The BBC produced OCTO to generate transcripts for journalists. This brought their costs down significantly (9c per hour), but still wasn’t perfect. Editors were copying the output into MS Word to fix it, which meant more work and also the final, fixed content was lost from the system. So they built a react tool to navigate via transcript and edit the text at the same time. The editing updates the timing data to keep things synchronised – the tool estimates the corrected timing based on words around the edit.

This is all powered by draft.js, a rich text editor framework for React. It’s powerful, but the learning curve is pretty steep. But it does abstract away complexities of working with ContentEditable. It uses ImmutableJS to easily create undo/redo stacks without losing performance.

This kind of development quickly takes you into editor state – content state, selection state, decorators (subsitute custom components as needed, eg. for at-mentions or hashtags), entitymap for metadata (eg. inline styles are stored as ranges against the base content string). Transcript data is pretty big so there’s a lot to keep track of.

While this was made for journos, it was packaged for developers:

npm i @bbc/react-transcript-editor

Producers use literal paper editing to build up scripts for a program. It works but it is very time consuming, so they also used the editor to create a tool for generating scripts.

The library has even been used and adapted in other news organisations.


1. Features – you have to solve a lot of problems before people will change how they work
2. Pains of scaling a prototype


  • If you’re building something complex, build an abstraction layer so you can change out the engine underneath.
  • Get whatever you can for free
  • If you’ve worked on text editors, come chat

The community is here to help!

Modern Forms in React – Erik Rasmussen

Everyone has to do forms! In core React we do this with controlled inputs. With hooks there isn’t too much code, but it’s still easy to make little mistakes like forgetting an initial value – so the input isn’t controlled.

Then there’s form state – you need to keep track of values, validity, whether inputs are dirty, messages like errors, whether the input is active, visited, touched, modified….. then you need UI states like spinners during submission, submission success or failure… and more.

If you are building a moderate sized form with even moderate complexity, there’s a lot to think about. Would you really want to do all that with hooks?

Facebook intentionally left this question to the community – that is, for the community to find solutions that worked in the real world. To this end Erik wrote ReduxForm and still maintains it… it gets lots of feedback! Over the years the community has largely decided that global state is a bad place to store form state; and why do you need redux just for form state?; and why so much rendering? ...and it’s a big library! 27kb gzipped. Also it’s just for React.

So there must be a better way. Erik started from scratch. What would a great solution look like?

  • Pure JS/no dependencies
  • Framework agnostic
  • Subscription based
  • Modular, pluggable solutions

The result: which meets all of those… plus to wrap it up for React. 8.5k gzipped in total. There are migration guides to go to Final Form from ReduxForm and Formic as well.


  • Form – wraps the form and provides form state to a render prop
  • Field – registers a field
  • FormSpy – read state without re-rendering the whole form


  • useField
  • useFormState
  • useForm

Live coding demo –

  • showed the basic setup
  • demonstrated why re-rendering can quickly become an issue
  • The subscription prop is an object of booleans, for Form and Field – they give fine grained control to the author to allow specific rendering triggers.
  • This reduces the re-renders, but keystrokes still massively add up; and if we stop those other components can no longer get the values – this is where FormSpy comes in, as it lets you spy on the state of the form without triggering re-renders.

How to choose a library?

  • Consider the complexity of the problem you are solving, and whether the library is appropriate for that level of complexity
  • How extensible are the libraries? Will they grow with you as your use case gets more complex?
  • Usage examples are a good indicator – when there are lots of other use cases being handled, you will probably find you’re ok in future
  • Bundle size – while it’s not everything, it might be the deciding factor
  • Don’t use github stars and npm downloads to choose – over time libs will have a lot of these, so they can be misleading metrics.
  • Does it make sense to you? If one just works with your methodology better, go with it.

One more thing…

As designers and devs we think we’ve built something easy to use, only to watch our users having trouble with something we thought they’d love.

We need information about how users are interacting with our forms:

  • how many users abandon the form?
  • which fields causes them to abandon?
  • how long do they spend on each field?
  • how long does it take to get to the most important field?

So… Eriks has built to help. Currently in private beta, sign up on the website.


react-beautiful-dnd: Behind the magic – Alex Reardon

A little while ago Alex taught himself some basic card tricks. There is a great satisfaction pulling off a great trick, a great illusion.

As frontenders we use misdirection and sleight of hand all the time – React Beautiful DND (RBDND) does a lot of them, which requires a lot of event binding and state; tracking all kinds of user interactions and possible issues that can happen in a drag and drop interface.

RBDND has sensors for mouse, touch and keyboard; but it’s pluggable so you can add more as needed. It can also handle programmatic changes. To avoid multiple sensors 'fighting’ each other, there is the notion of a lock – once a sensor has a lock, it drives all interaction until it’s released. It is possible to purge sensors to handle error states. Components are kept in a registry; and RBDND often sidesteps React for performance reasons.

There are lots of challenges in DND. Elements are often sized according to their parent element, so when they are removed during a drag interaction, they change size. The position they were in has also lost an element, so that changes size as well. To combat this, the registry keeps original element dimensions so they can be used mid-drag. This is also used to manage the drop impacts, moving other items around.

Moving lots of elements is expensive, so RBDND uses windowing – only the elements the user can actually see on screen are being moved around. That does require some thought on elements that are currently invisible, but will become visible after the view changes.

Next challenge… bulk actions. They use data attributes to apply pointer event CSS across multiple elements. Then all elements are moved in one event, to keep things fast.

There’s a collision element to determine element displacement; and move displaced elements with CSS animations. This offloads as much as possible to the GPU.

For lots of detail on the design of the animations, see Alex’s blog post, Beautiful interactions.

Animations can be flushed, so if a new interaction starts before the previous animation has completed; it just snaps to the final position and the new interaction animates. Most are fast enough that it doesn’t happen, but it’s handled in case it does.

How about accessibility? Screen reader users get a combination of keyboard actions and audio cues. ARIA is used to alert the user that elements are draggable; and detailed instructions are provided in a hidden element. A live region is used to announce and confirm steps in the interaction.

(live demo of screen reader!)

Sometimes magic is just someone spending more time on something than anyone else might reasonably expect. – Teller

A lot of time has been put into RBDND; with a shout out to all the people who have contributed.


10 x your teamwork through pair programming – Michael Milewski & Selena Small

This was a perfectly-aggravating roleplay of an average dev onboarding (awful) and “pair programming”, complete with condescension, back seat driving and every personal annoyance you could come up with. A microcosm of many, many cultural issues in tech beyond their impact on pair programming. This wasn’t possible to transcribe with any justice, you had to be there!

The pairing to do list:

  1. ergonomics (ensure both people have a keyboard and monitor, etc)
  2. remove distractions
  3. take regular breaks (this is when you can handle distractions)
  4. create a plan (both for the work and how you’ll pair, eg. ping pong pairing)
  5. do the actual work (and take turns driving)
  6. mini retros (what went well today? what didn’t go so well?)

The first two seconds: Faster page loads with React – Josh Duck

This talk is about the work Josh (and his team) did at the ABC.

There’s a bit of a meme that React is inherently slow, and if you pick you must hate your users… but in the end it’s just JavaScript, so there are native APIs and other things we can do to make performant React. The web platform has been around for a long time and has a lot of great features.

There are a lot of architectural choices available for React –

  • full server side rendering, SSR with client-side hydration, progressive hydration
  • static site generation, server rendering with CDN/caching, SSR per request
  • CSS media queries as the basis of the rendering model

Josh’s team made their choices and ended up with a site that was ok for performance. Users were not actively complaining. But it could certainly be better.

There’s a lot of sketchy information out there about the real impacts of performance. Even Google’s supposed punishment for poor performing sites is only applied to very slowest sites… and people blogging about their performance gains tend to edit unflattering information.

The two seconds number comes from IBM research in the 60s, which found interactions over 2 seconds caused people to perceive the interaction differently.

So what should you actually measure? A good place to start is Lighthouse performance testing. This gives an easily understood overall metric and a breakdown into detailed actions/metrics.

But don’t stop there, decide which metrics make sense for you. Lighthouse punishes React for things you might consider an acceptable tradeoff, and if you’re committed to using it you can’t just yank it out.

The ABC team broke down their performance goals into three phases:

  1. initial render
  2. hydration + page interactive
  3. non-critical content

Effectively they were focused on perceived performance, not blunt metrics.

Phase one

  • They started by ensuring they were serving content correctly (headers, http2, gzip etc)
  • Font swapping gave a massive speed boost
  • Preloading with rel="preload"
  • Lazy loading images – they wrote some bootstrap JS that executed before React loaded, which checked which images were above the fold. This will come natively to browsers with the loading attribute.

Phase two

  • no module hack to avoid polyfills in non IE11 browsers
  • dynamic bundles and bundle splitting (use bundle analysis to identify problems)
  • Loadable Components package
  • use React dev tools to profile React performance

Phase three

  • most sites have heaps of third party code; and there’s often very little recourse. The ABC at least didn’t have to run advertising code. But a youtube widget was adding 500k on top of their own 250k bundle. Double the size just for a video!
  • Lighthouse gives a really good breakdown of this kind of code and the impact it’s having

Overall the gains were significant. About 45% improvement across the board, but most importantly it felt fast.

Lessons learned

  • some metrics in Lighthouse don’t have the impact they claim – in particular, implementing critical CSS gave no gains
  • measuring the impact of changes is hard – if you can’t measure something it’s difficult to improve it
  • Lighthouse itself has variability of scoring – they say you need to expect +/- 15% across runs using the same network. That means you can’t verify any gain or loss of less than 15%.
  • There are tools that will average data over a long period, which helps
  • You can use the Performance API to measure real user results
  • Record your wins and losses – they used Calibre for this. It helps tell the story over time and justify the investments being made.

React complements the web platform. The cost of react was the big block of JS execution; but it takes less than 400ms and they were able to sequence it so it didn’t block render. React also provides opportunities like bundle splitting and SSR/hydration.

The final result – a website that was fastest in its class; and the team was happy with their work.


Engineering led design – Lauren Argenta

Lauren is the design director at Thinkmill. Previously she was in a design-led organisation, but when she joined TM it was engineering driven. The process was a bit basic, scrappy and design was a little too meek. Lauren came in to create a “proper design practice” in an engineering-led organisation.

So what did this really look like? What can engineering leaders do to improve design?

  • Context together
  • Create a dictionary
  • Teach as you work
  • Play it back to validate
  • Break down language barriers

Context together:

  • Shared context is really valuable – gather it together. This is hard work, it takes time and attention.
  • You need shared context to make good decisions as a multidisciplinary team – it breeds confidence.
  • Everyone attends all context-gathering meetings, particularly in the beginning. Even when the meeting is supposedly “about design” or “about engineering”. The cross-pollination is important.
  • Engineers attend and ultimately facilitate research sessions
  • Engineers educate designers about the hard problems in software

Create a dictionary:

  • Naming is hard. Using precise language is important. The same terms do not mean the same thing in design and development!
  • Both sides use jargon.
  • In practice – create a shared document that everyone can use (they use a wiki). Define project-specific terms (eg. data structures)
  • DYFA – define your frickin acronyms
  • Reserve critical terminology. Example: observation != finding != insight. These are very loaded terms in design. Similarly accessibility has a very specific meaning in software – it does not mean “convenience”.
  • The dictionary becomes a critical Source Of Truth. Don’t underestimate the importance.

Teach as you work:

  • Learning from each other makes the most of the diversity of thought. We can’t become experts at each others domain, but we do need to understand each other.
  • inject short, structured lessons into your daily work
  • Thinkmill call them “asides” – ~30min deep-dives, done when needed. They are a first-class citizen in the work day and not a distraction.

Play it back to validate:

  • A great way to uncover and test assumptions is to play back your thought process
  • It will flush out the hidden information and assumptions
  • In practice – designer explaining a new design, or an engineer explaining a change to a data model
  • Consider what needs a playback – prefer to do one than not

Break down language barriers:

  • Design and dev have a big communication problem! This isn’t controversial, it’s just true.
  • Practice empathy – people aren’t dumb, you just haven’t explained it well enough yet.
  • Useful phrases are “did that make sense?”, “can I explain it another way?”, “can you play that back to me?”
  • tip – most designers are visual thinkers. Draw things… stick figures are fine!
  • unpack technical concepts with plain language

Why bother, as engineers?

  • you will get designs that are much better aligned with technology
  • easier to negotiate constraints
  • faster, better decisions
  • you will have a better time, it will be more fun

Design can thrive in an engineering-led environment. Engineers are crucial in that process – try these five behaviours as a first step.

Take a load off with React – Jake Moxey

This talk is about common problems around data fetching; and the general state of data fetching in React.

Fetching data is integral in any kind of application, but it can be hard.

Representing a finite number of states can be overlooked. Consider the states of a promise: idle, pending, resolved, rejected. There is no loading state – you have to use !data and !error to build up a loading state. There’s also UI problems, like throwing too many loading spinners at the user – it can get annoying.

Data fetching approaches in React

  • fetch on render (most common)
  • fetch then render
  • render as you fetch (ideal)

Fetch on render has a waterfall loading timeline – download, render, then fetch data. This has some issues like re-loading content you’ve already seen. We can get race conditions, so the wrong content loads. There are more problems but these are common. But these problems shouldn’t impact our users, they are dev concerns.

There are tools to solve these problems – lots of options (demo through Tindata, fake dating app to find your perfect data fetching solution):

  • Local state – as react devs we tend to lean towards this, but it is after all local and it’s limited
  • Redux – popular approach to global state management, but no data fetching tooling out of the box. Risk of bloat if not used correctly
  • Apollo – a breakthrough external data fetching client. Great dev-first experience for creating flawless user experiences
  • Relay – friendly competitor to Apollo
  • React Loads ( – supports suspense and concurrent mode

Choosing the right approach is as personal as dating.

React is working to add much better hooks for preloading and transition between views. eg. React concurrent mode allows us to start fetching data immediately, in parallel to download and render, allow pre-rendering of the next view/page, generally allowing us to create much smoother/less jarring experiences for our users.

Farewell spinner waterfall, race conditions!


Senior to leader: Taking the next step – Cathy Lill

While this talk is called 'senior to leader’, the story should have some ideas to consider wherever you are in your career.

Cathy’s current role is her first step outside frontend – whether frontend dev or frontend leadership, all her previous roles were in some way about frontend. This was her next step. There are many next steps and people leadership is just one, you might also want to take on a new technical role or move to a new area of the business.

Cathy was reaching a point where she was getting too senior to keep working as a dev; but moving up brought up questions like whether she was “technical enough” with frontend experience. It was feeling like a barrier to managing cross-discipline teams.

Then her workplace brought consultants in to do a salary calibration – and they said frontend was ranked lowest in terms of value. After the ensuing nerd rage, Cathy reflected on how she was presenting the value of frontend.

This leads to thinking about the value we provide, the skills we have and how we can use those skills to move on to the next level. It turns out frontend devs build skills in many areas of the business. We work at the intersection of human and business concerns.

So what technical expertise do you need to demonstrate?

Engineering excellence – Frontenders build reliable scalable technology in a complex, volatile environment. Every day. We deal with complex technical issues and generally have an awareness of the whole system. But don’t assume your CTO knows that you know these things!

Product stewardship – understanding and executing the big picture; make sound product decisions; and an ability to advocate and communicate. Frontend devs tend to do this without realising it – we advocate for users, clients, for our teams and choices. These are valuable skills. We’re the custodians of user experience and customer value. We fight really hard for things like accessibility, a great user experience, perfecting design and improving performance. Even if you aren’t aiming for a leadership role, being good at these things make you better devs.

Leadership and management – taking responsibility for long term outcomes; lead, coach and mentor effectively; effect and manage positive change. These skills are critical as you get into leadership roles. Lucky for us, we’re a vibrant, supportive community – not all industries come to conferences as we have done today! Just by participating in this community you are growing your skills. You can further develop these skills by becoming a mentor at groups like Codebar.

There are also lots of new skills that we need to learn at this stage:

  • Broaden your technical knowledge, participate in decision making, develop your technical vocabulary.
  • Participate in product meetings, learn to make better-informed product decisions.
  • Mentor, coach, teach. Seek opportunities to manage and delegate. Develop persuasive speaking and writing skills.

Getting into product meetings is often as simple as putting your hand up to attend, or at least sit in on the meetings to understand the discussions being held. You need to understand the concerns outside your current sphere of influence.

Building the formal technical vocab can be a particular challenge for people who are self-taught and not in on the formal jargon. Even if you just google terms you haven’t heard before, build up your knowledge so you can match them up to the conceptual knowledge you already have.

For leadership and management, again you need to put your hand up and ask for opportunities to start. Otherwise, it won’t happen until someone else chooses to put you into management.

The need for speaking and writing skills will become evident when someone else does it better and wins a business debate!

Many of these things are a form of learning new things outside your current domain. Grow your skills and opportunities will open up.


Targeted extensibility: Lessons learned from building Atlaskit – Charles Lee

Charles works at Thinkmill and has spent the last few years working on Atlaskit for Atlassian; and react-select.

For the uninitiated, a design system is a system of guidelines and artifacts to help make design decisions, and reduce non-differentiating work. It avoids spending time on trivial decisions; and reduces duplication of effort.

In its simplest form – design systems save us time. That’s the biggest business value.

Prior to Atlaskit, there was a jQuery+CSS UI library which was solid and flexible; but that flexibility had led to inconsistency across products. In reaction to that, Atlaskit v1 was locked down as tightly as possible. The intent was to enforce good design decisions and a better user experience. This led to low adoption. By making it too hard to use Atlaskit, people stopped using it or they were hacking around it. So even a small release of the design system would break all the hacks. Time wasn’t being saved.

So you are stuck trying to find a balance between the design system being too flexible, or too constrained… and as the maintainer in the middle it often feels like a lose-lose situation. Not helped by the fact the product teams simply outnumber the design system engineers.

Charles proposes React component composition as a way forward. Bake in the crucial design decisions and allow users to modify things that can bear it. To provide flexibility within some reasonable constraints.

Products change all the time and new features are being added. If you add absolutely everything you end up with prop soup, which makes it hard to get context on a component; makes it harder to understand how to use it, even when docs are great. It also bloats bundle size for features a given product is not using.

Instead expose:

  • basic props
  • themes

Exposing design tokens/theme configuration allowed broad customisation within basic constraints of the system. eg. They can apply colours, but those colours come from a controlled palette. But they don’t help with DOM/behaviour customisation.

When the user can’t modify something, having to wait for the design system team to add a feature takes some time. Generally the developer will abandon the system for the sake of the 20% difference, losing the 80% common problems it solves.

So you can hand off more implementation details:

  • export hooks
  • export higher order components
  • render props

You can also do…

  • targeted overrides

React Select uses a components prop to allow users to override specific subcomponents or apply their own styles. Selective amounts of overrides without changing the entire component. A tradeoff is exposing private functionality, which has its own risks.

These are all escape hatches for users, which can lead to the exact same fragmentation and inconsistency problems you were trying to solve in the first place.

In conclusion: design systems are hard!

What is an XSS attack – and why should you care? – Carmen Chung

(Lightning talk)

Three topics today:

  • what is an xss attack
  • how do you prevent them
  • what happens when you circumvent those measures

An XSS attack is a cross-site-scripting attack, where unsanitised input is executed as code in the client. This is typically exploited by the attacker injecting their own code from another site in order to steal session data or otherwise compromise the user’s session.

React automatically protects us by escaping strings and handling input via a sanitisation method. However it also provides dangerouslySetInnerHTML which circumvents these measures.

Demo: hijacking someone’s Twitter login by injecting an iframe into an unsantised form field.

What can you do?

  • don’t use dangerouslySetInnerHTML
  • if you do have to use dangerouslySetInnerHTML, sanitise it yourself – ideally on both the front and back end


Creating a custom form handler with hooks – Hannah Thompson

(Lightning talk)

useForm will be a custom form that takes a validator function, a callback, initial values and then returns the values.

In this hook, write functions that…

  • add to values object
  • validate
  • run the callback if valid/no errors

Lessons learned doing this for real:

  • Keep business logic out of your form handler!
  • Protect the hook once you create it – people will want to shove all kinds of things into it that don’t belong in there!
  • TypeScript in forms gets tricky, particularly if the team isn’t used to TS… but it’s worth it. Providing a TS interface to the form will prevent a lot of problems.

You too can create your own hooks!


Reactronica: Music as a Function of State – Kaho Cheung

(Lightning talk)

React is UI as a function as state. What if we could have music as a function of state?

<Song isPlaying={true} bpm={70}>
<Track steps={['array','of','notes']}>
	<Instrument type="amSynth" />
	<Effect type="reverb" />

This lets you build up a song using React components, which in turn makes it easier to build a visual representation as well.

Or you can build live guitar/uke tablatures… or show a tune playing through sheet music… or make an Ableton-style tool right in the browser.

@unkleho | Slides:

Redux Connect vs Redux Hooks: A play – Terence Jeong

(You had to be there, this doesn’t transcribe :))

Rendered! Woohoo!

Rethinking Design Practices – Mark Dalgleish

Mark’s work in design systems reveals that the industry is at a crossroads. Our design systems aren’t delivering their full value, our code and design workflows are still too separate. However with technical advances it is becoming possible to design in code directly – and this has the potential to really re-think the way we work together.

Designers and developers are literally not speaking the same language. At Seek they’re solving this by working directly in code together.

  • Tooling
  • Abstractions
  • Workflows

A key tool at Seek is Playroom. Playroom pushes the idea of JSX as a design tool – prototype directly in JSX, in the browser with no installs. Then you can share the URL with people.

A quick refresher on design systems:

  • Design tokens – a store of variables defining design fundamentals like colours, spacing values, etc
  • Primitives –, responsive props (eg. padding={['medium','large']} for two breakpoints). The goal is to stay out of CSS as much as possible, and in the component layer.
  • Components – full widgets like buttons
  • Layout – inspired by Space In Design Systems …key idea: components should not add any whitespace, only layout should apply whitespace. The problem is that the browser breaks that rule immediately with text – text has space between the actual glyphs and the element’s bounding box. At Seek they use some neat CSS tricks to collapse text down to match its bounding box. At this point, while it seems a bit weird it makes text behave like all other components.
  • Layout components – eg.
    • Stack which controls the spacing between a stack of child elements
    • Inline for elements inside another element
    • Columns

These components should make sense to non-developers. That is, designers should understand it too. This enables prototyping in code. Playroom snippets help speed this up.

(live demo of prototyping in JSX, using Playroom with a library of snippets pre-loaded)

The idea is to make code part of the design process – not something we do at the end.

How can we help? First, get involved with the designers. Work with them early and often in the process, see the iterations, understand the decisions and how they’re made. This will work best by finding an early adopter for JSX prototyping and offering them constant support. Encourage pairing between designers and developers.

We’re not trying to get designers to instantly abandon their current tooling, this is about using JSX as one of the tools. For this to work, developers have to make designers feel as welcome and supported as possible. Run workshops, get them to try it out, take feedback. When mockups are sharable React, it’s vastly easier to turn it into a production implementation.

This is about rethinking design practices. It has to be led by the people in the room. Get out there and try it!

5 things you should know about WordPress… wait, what? – Isabel Brison

About a third of all websites use WordPress..!

Things you should know about WordPress:

  1. A lot if it is now being built in React
  2. WP uses React wrapped in a package
  3. WP has a REST API to help it all fit together
  4. The new editor is open source and can be used outside WP
  5. Third party devs don’t have to use React

React was an interesting choice in a PHP-oriented community, but it emerged as the right choice… right at the time of the licensing worries in 2017. So Wordpress published a post saying React would be out of the question, and then suddenly the React license issues were resolved. But it did mean Wordpress had to think about how to safeguard the community from that kind of risk.

So WP uses React wrapped in a package – it looks and works as you’d expect, but it is an escape hatch in case they were forced to remove React in future. It’d be good if it never happened, but it’s possible.

The new editor (aka. Gutenberg) is a React application – it uses the existing venerable monolith’s REST APIs. But the editor is a separate package and you can use it.

(demo – Gutenberg in Drupal!)

Third party devs aren’t forced to use React – it does have a big learning curve and not everyone has time to do that right now (remember – a third of all websites, it’s a lot of people). So the new stack isn’t imposed on everyone, WP has added a JavaScript global wp that exposes the new functionality – you can build things in whatever you want (like existing jQuery plugins).

@wordpress/create-block makes it easy to get into the new system. WP love React! They do want people to use React, even if they do give another option.

It’s all open source and they always need contributors.


Write fewer tests! Model-based testing in React – David Khourshid

They say a good software engineer always looks both ways before crossing a one-way street. David is apparently not a good software engineer, he’s nearly been run over in Sydney because we drive on the wrong side!

Assumptions are dangerous. We have no idea how people will use our app, even when it seems obvious to us. In a survey David ran recently, the biggest frustration with testing was writing the tests.

In the normal run of things, a codebase will grow with base code – but the test code is probably growing faster than the base code.

Remember the testing trophy…

What if we wrote fewer tests? What if tests can be generated? Model based testing is not new, but it’s a useful concept to explore in React.

Consider the Die Hard riddle – measuring 4 gallons with a 3 and 5 gallon jug. The process you go through to solve this can be mapped as a Finite State Machine.

Every app starts in idle state; and most have a finite set of other states like loading, success and failure. The states and transitions are not endless. This means we can generate all the combinations. We can generate a graph of all possible paths you can take with a 3 and 5 gallon jug. Although this is a contrived example, it’s a good way to think of our apps. Cucumber testing help imagine the preconditions and success conditions.

How we can put this into practical use:

1. create a model of your app (a graph)
2. generate abstract tests
3. make those tests real
4. execute the tests
5. profit!

Once you go this way, writing new features doesn’t mean writing new test assertions. When you add new features, you add to the model and new tests are generated.

Real example: testing a feedback form with a conditional text input (click 'good’ get a simple post submit, click 'bad’ it asks why, then shows post submit)

Using: React Testing Lib, Jest, XState

Writing a normal test is straightforward – create test fixture, assert initial state, trigger a change, assert new state. It’s easy to write a couple of these, but it’s time consuming and you can easily miss states and paths.

Instead generate a state machine (an object defining states and transitions/events); then we can calculate shortest paths, weighted shortest paths, simple paths, etc. So instead of manually writing every combination of assertions, the actual tests are generated. The results are self-describing as they show which state and transition path was being tested.

Xstate has a visualiser to help work out the state machine.

If you’re using Puppeteer instead of RTL it still works – you can swap pieces out.

(Live demo)

Time-travel debugging in the future!

What does this have to do with React? Well… absolutely nothing. You can do this with any framework, or vanilla JS… it doesn’t matter. There are several libraries: Xstate Test, Simulato, Graphwalker (for Java, but has interesting ideas).

Going into model-based testing has a learning curve. You have to learn how to model your application correctly, as well as learning how to write all the tests. Also it has to be noted that it still won’t guarantee 100% coverage of possible outcomes (model might be wrong!).

But there are lots of advantages worth having, particularly considering the cost of maintenance long term. You’re only writing the model, not all the tests it generates.


Make your code model-driven
Make your code generate tests
Make your code generate docs
Make your code generate prototypes

Make your code do more.


The tragedy of scale – Nadia Makarevich & Hannes Obweger

Hannes and Nadia work on Jira’s new React UI. There are 500 contributors and 1.5m LOC. That’s some scale!

This is also a story of history, politics and philosophy.

Parable of The Tragedy Of The Commons – it makes sense for every individual to graze a cow on common land. But overall, it doesn’t work – the common land can’t cope and ends up as an apocalyptic wasteland. It is a shared, limited resource. The principle applies to many things – grazing, fishing, pollution, email… and software engineering.

Our codebase is a shared, limited resource. It is limited by our brains ability to process it. The browser that executes all our code is also limited. If everyone shoves more and more code in, eventually the repo and browser become an apocalyptic wasteland.

So people think what if we don’t have any shared, common resource? In farming this means separate farms instead of a commons. In software it’s modularisation – functions, components, files, packages.

Packages are very familiar to library devs – we don’t deploy apps, we publish packages. Products are composed of packages and custom code, where the boundaries and responsibilities can be controlled. Groups of people can own specific sections of the overall codebase.

But then if you have a particularly large section… you might reproduce the tragedy of the commons. So you need to embrace the component mindset. This is very strong in React which is built to be composable. But you can still bind everything together with a mess of state (in Jira’s case a massive Redux store) – imagine trees with a tangled root system.

So they needed to rethink state. They needed modular, composable, future-proof state as well as components.

They split state into three types:

  • local
  • shared
  • remote

Local state is simple, confined to components (not necessary to put in Redux).

Shared state is a bit harder – when two components need to share information. They can share via the closest parent, at small scale you can manage with props. But when they are not neatly co-located this isn’t enough. React Context provides an escape hatch to deal with this. You can have a provider at the 'top’ and components share via the provider.

Remote state is interesting – when components want to share information that lives outside the UI, eg. a remote enpoint (REST or GraphQL). You can handle this with a parent component that handles the connection to the remote state store/endpoint.

So context solves lots of problems – but with great power comes great responsibility. You can end up in 'providers hell’, nested providers, lots of providers, it becomes unmanageable and easy to make mistakes or put yourself into re-render hell.

It’s the same story with Redux – it has lots of benefits, lots of baggage you don’t care about. So they did the obvious thing… made their own:

But this still only gets you so far. In the grazing analogy, imagine the field is divided evenly but there is a shared lake in the middle; and a bad actor poisons the water. There are many shared resources, many relationships beyond the simple allocation of land. This is why you end up with rules and conventions to create some order – you have a rule about not poisoning the water, because you can’t divide the water and contain the impact.

In software we have our own rules and conventions. It’s ok to release packages that are independent, but not ok for packages to depend on a specific application/consumer.

Atlassian is 'borderline obsessed’ with static code analysis, like ESLint and again the made their own: …plus they have a Platform Team responsible for enforcing common tech stacks, rules and conventions. They actually have a story-based concept: “as a developer I want type safety -> Typescript”.

To recap… as a society we have shared, limited resources. It can be many things. It’s a stuggle as old as mankind to sustainably manage these things. Engineering teams are a microcosm of that struggle. We can take learnings from thousands of years of human experience to find solutions in software engineering.

  • Separating fields – modules
  • Splitting up fields – components
  • Rules and conventions – rules and conventions (linting)

Freedom is the recognition of necessity.

We are all in this together. Personal freedom can only go so far.

@adevnadia | @obweger

Building with Monorepos – Mitchell Hamilton

Mitchell works on Emotion … A couple of years ago they had some problems they decided to solve by splitting it into multiple repositories. They ended up with bigger problems managing dependencies across the packages. This also split up the project’s identity.

So they went to a monorepo instead. This has a lot benefits:

  • one place for pull requests, and PRs can work on multiple packages
  • single identity
  • central docs and issues

But at the time, monorepo tooling was pretty bad. Problems:

  • dependency management
  • packaging
  • releasing

Dependency management

  • They started using Lerna to handle installation and linking between modules. They created Bolt, trying to solve problems with Lerna’s dependency management. Bolt enforces common versioning for shared dependencies and handles installs from the root.
  • Then Yarn workspaces came along – solved everything right? Not really, it still had issues.
  • So they built manypkg to enforce some constraints and fix some where possible.


  • Lots of issues so they built preconstruct
  • Rollup is really good, so they use it for bundling
  • Babel configuration is hard – use babel.config.json
  • Then you hit packages with multiple entrypoints, which makes things more complex – preconstruct handles this as well
  • Development process was simplified with preconstruct’s build command
  • preconstuct


  • They want contributors to declare their changes and how that impacts the version. They don’t want this to be git based as it’s too hard to enforce in a big project.
  • Need to bump dependent package versions
  • Easy to automate releases
  • So they built another thing! changesets to handles versions and releases
  • changesets

So they solved the three big problems in a nice way.

There are still tradeoffs – imports can get messy and anyone can import anything revealed in dist. Node is adding exports to properly limit the exports of a module.

But overall they still feel monorepos have more benefits than problems, and they’re gathering their knowledge in a new website:

It helps guide you on how to 'think in monorepo’.


How to teach an old dev new tech: Learning React as a senior developer – Trent Willis

Nine months ago Trent was at a crossroads. His team was building a new app, in a new stack. They were fighting their old, familiar stack – the tooling was falling behind, the community support wasn’t there any more. So they chose React + Redux + Typescript. But this was a big challenge for Trent… he didn’t know any of that! Bit of a problem for the lead dev.

Nine months later, things are going well – user feedback is good, development is on track, and he now knows and likes React. But it made him wonder what made this project successful? What did his team do that led to success, that others could follow?

It’s an important to note Trent isn’t saying “old” as in years, just old in terms of the old saying “you can’t teach an old dog new tricks”. Sometimes you get people stuck in a rut, they’re stuck in their comfort zone. While you can still be extremely productive, it can bias you against learning new things.

The comfort zone is not inherently bad. Your team can be very happy, experts in their domain who are performing well and producing good things. A sense of mastery is important.

The comfort zone becomes bad when you don’t trust others’ experience; you’re afraid to fail or admit you don’t know something; or you just want to remain the resident expert.

The comfort zone is bad when it does not celebrate learning. It can lead to teams that have very little diversity of thought; and is generally a sign of culture problems.

But why do we learn anything? There are lots of motivations, but they mostly fall into two categories:

  • Extrinsic – money, fame, success, keeping your job…
  • Intrinsic – doing it for the joy of doing it

(Aside: for more on this, read Drive by Dan Pink)

Trent wanted to learn React; and he had to learn React.

While both are valid, research shows intrinsic motivation tends to produce better results. Understanding motivation lets us create environments where success is more likely. When people were gripped by Javascript Fatigue, they had lost intrinsic motivation.

Motivations can change over time; people can move between extrinsic and intrinsic motivation.

So you should build a culture that fosters positive motivations for learning. But how do you do that?

  • Start by being honest. Be honest about what you know, admit when you don’t know something. When people are open about knowledge, they can easily get into learning modes and learn new things together.
  • Make the ability to learn more valued than already knowing it. This kind of culture is empowering.
  • Build empathy for people who are learning something. Listen to the people learning something for the first time. If they say it’s hard, don’t dismiss what’s happening for them – help them move forward. Find ways for them to get over the hurdles.
  • Try learning a complex new skill yourself. Last year Trent also tried to learn guitar – and it was really hard! But it was really exciting when he had successes.
  • Learning a new technology is like climbing a mountain. Sometimes it’s easy, sometimes it’s hard, sometimes you feel lost, but reaching the summit is a wonderful feeling. But it’s easy to forget how we got there.
  • Encourage exploration – eg. on Trent’s team someone spent time learning about WASM. They didn’t end up using it in their app, but they took ideas and learnings into other work.
  • Play to the existing strengths and knowledge of the people on the team. Let them take the lead, learn from them. Everyone grows from doing this and people feel a greater sense of ownership. Make sure you recognise people who have done good things.
  • Celebrate what you’ve done and what you’ve learned. Most teams don’t really do this much. At Grooveshark, they had a kudos culture – a shout out and a Kudos chocolate. A small but public token of appreciation. Find whatever feels right and authentic for your culture.

Software is complex, fast paced and can be difficult to learn.

How do we learn effectively?

  • Research the scope of what you need to learn – what does it mean to “learn React”?
  • Build knowledge in well-defined increments – it’s more tangible to learn how to use React Hooks, or implement a Redux reducer
  • Choose and allocate work in ways that support people learning the right things – don’t put everything on one person, particularly if they’re still learning things. Take the pressure off.
  • Take breaks – when you’re frustrated or bored, take a break and come back with fresh eyes. Breaks help consolidate and retain new knowledge. They help in all kinds of ways with mental and physical health.
  • Don’t underestimate the power of rest. Get enough sleep. Lack of sleep can reduce your ability to learn by up to 90%.

To recap…

The comfort zone is ok, but don’t let it stifle learning important new things. Build a culture of learning and find ways for people to learn effectively.

If you’re not sure where to start – simply start by being honest. Let your team know what your limitations are; and work together. Stop all the gatekeeping. Be a developer who celebrates learning for yourself and those around you.

@trentmwillis | Trent’s slides and notes

A GraphQL Survival Kit – Petra Gulicher

Learn from the mistakes of others. You can’t live long enough to make them all yourself. ― Eleanor Roosevelt

So what is GraphQL?

  1. a query language
  2. a runtime to execute those queries

Why is it cool?

  • product centric
  • hierarchical
  • schema driven

Dangers you might encounter

  • slow query responses
  • not knowing what to call things
  • working blind when things go wrong

Deep GraphQL trees can get slow, particularly when the underlying data is being retrieved from different protocols and sources. (example of a query to build a user object: it pulls their profile from one source, avatar from an external service, list of favourites from another source…)

Responses can be delayed by design/intention, or simply by the weather. Literally. A lot of people get slower internet after rain. Yay for us.

Surviving speed issues

  • cache responses, although be careful how you choose what to cache lest you get an exponentially growing cache
  • you may get better results from pre-fetching or an application cache
  • remember the fact a single GraphQL endpoint exists doesn’t mean you have to pull everything in one request. Small, granular/incremental requests can work out to be faster
  • Peel back the curtain. GraphQL can provide a unified endpoint but you still need to understand where everything comes from.

Surviving naming

  • Designing a schema is really modelling your domain
  • Four areas to focus on…
    • naming things (draw on the domain model)
    • how to connect them (one to one, one to many…)
    • lists (what do you do with empty lists, how to paginate a list…)
    • making changes – describing in the schema how you make changes can be the hardest thing… describe user behaviour; and be specific. updateProfile is vague; addTrackToProfile is very specific. Yes this means you have a lot of mutations… do the work! It’s still not as expensive as adding a REST endpoint.

Surviving errors

  • how do you deal with errors delivered with a 200 response? it turns out your app has to decide what to do with errors. There was no network error and you have a data tree, but you have a populated list of errors to work with.
  • Server errors are different from GraphQL errors.
    • Server error – plumbing has gone wrong.
    • GraphQL errors: data’s gone wrong.
  • You just have to do the work… it’s a new class of error.

Petra has gone through all this and still thinks GraphQL is worth it:

  • great coverage of tools and adapters
  • writing a schema gives you API documentation for free (swagger is not free!)
  • it doesn’t care about your transport method
  • you can write less code and get more app

@petronbot |

Powerful REST in a GraphQL world – Tejas Kumar

Tejas’ story begins where all great stories begin… with JavaScript! He was working on a big JS project and having all the issues of a big legacy codebase. They were feature frozen against their will. So while Tejas loves JS, there may be something better…

They found Typescript. There was a learning curve but they saw value – they could confidently refactor, confidently delete… they had a design system and they used React Styleguide to document it.

Their docs had nice examples and code playground, but it wasn’t a true representation. It was JSX but it would not error on invalid props.

They took the VS Code editor (Monaco) and put that into their docs, so now it has prop validation and intellisense. Right in the browser in the docs.

(Demo of their docs –

(There is a whole talk about this project online, from React Finland… back to this talk!)

While the team was happy using TS, they were still having issues with the backend. Lots of errors and breakage and general unhappiness. REST just wasn’t working for them.

Let’s not just say things are bad – let’s give real reasons when we do that.

REST is bad… because:

  • it’s not a formal specification – there are conventions, but no spec
  • guessing games
  • leads to meaningless discussions – should this be a put or a patch? your users do not care!
  • no contract between the frontend and backend

Having become disilluisioned with REST, he looked at GraphQL.

GraphQL is nice… because:

  • formal specification
  • no guessing games
  • meaningful discussions
  • strong contractual agreements

There are other reasons but they are the big ones.

So how do you get GraphQL into the business when there are lots of crappy arguments against it? All the usual FUD about cost, being too busy and so on. Tejas found himself blocked by the business. This is frustrating!

In the face of constraints you can either get bitter, or you can get better.

They had an idea – they started a side project using GraphQL. They created restful-react.

(Demo of restful-react)

REST does have some contractual agreements – look up the OpenAPI initiative. Restful React includes a CLI that pulls the OpenAPI definition in; and outputs react hooks. So now you can create an API definition file that lets you work with whatever random endpoint in a typesafe way.

(In the demo we saw this created and used in a few minutes from start to finish. Very impressive.)

End to end type safety with a REST API!

Take aways:

  • Innovate against constraints
  • Choose better over bitter
  • Support open source


Close – Jed Watson

Jed begins noting it was a scary thing to start ReactConfAU, but it has been so much fun. One of the big themes of the past two days has been innovation and the spirit of sharing. Which is really precious in our community.

What is the value of open source? It’s everything and nothing. It’s a curious thing.

Jed has done a lot of open source. He maintained a Github streak of 1000 days (although he doesn’t really recommend trying it at home). During the streak he started a company, travelled, started a family. Jed is a founder, a maintainer, a parent. This is what he’s bringing to the talk.

Reflecting on what he got out of the experience. There are big statistics about how much his code is used now, although it doesn’t translate into money. He’s made friends, got a lot of satisfaction, yes he’s also dealt with jerks, and he’s learned a lot.

Open source is valuable to us as a collective. You almost certainly use a large amount of open source code. It improves our quality of life. It makes our work better and easier. We’re here at ReactConfAU because React is open source.

We build on great abstractions. As devs we love abstractions… although we perhaps don’t think about them enough.

Create React App is an abstraction not just of code, but of all the people who contribute to the code behind it.

Open source is strong, but it does have a weakness. While there is a lot of value in it, it has no financial value because it’s open. We have a catch 22.

Projects start with great enthusiasm, they get opened up with open source, they grow (if you’re lucky), then you reach maintenance. Which is a lot of work – a lot of unpaid time. You can become a victim of your own success.

So in open source, success is not actually success.

In react-select, someone has opened an issue asking if the project is still maintained; and how people can help. It has been hard to keep up with the demand placed on the project. It has had investment from Thinkmill and Atlassian, but investment !== sustainability.

So do we start making people pay for it? That’s not what led us here. Charging for open source is probably not the answer. So what else is there?

People talk about social responsibility a lot. Companies are not charities – and they are not meant to be. So that’s not the answer.

What does work? The concept of the virtuous cycle – where good behaviours lead to and enhance each other.

What does work? Let’s look at real examples:

  • React is sustainable under the corporate stewardship model. Facebook get plenty of value and they use it themselves.
  • Apollo works by providing services and support to generate income
  • Next – providing a platform to generate income
  • Gatsby – has attracted VC funding

Erik observed it’s awkward to make something that saves companies millions of dollars, to get $300 for it.

Thinkmill builds things, open sources them, which creates value and awareness, which brings opportunities that provide funding to keep building things.

These are all abstractions. What would happen if we didn’t need them?

Alex Reardon’s twitter bio: trying to make software that makes other people feel like rockstars.

What if that was enough, without having to find some combination of luck, services and strategy to make it sustainable?

Babel is supported by donations. It’s critical infrastructure. It is used incredibly widely and has a clear roadmap (the JS spec). But it is seriously underfunded… even though it is the best-funded project on Open Collective. Would you take a job for $2k/month? Would you join a startup with $100k in the bank? That’s how these projects are surviving.

Without successful commercial abstraction, open source falls victim of the tragedy of the commons. It leans too heavily on individual donation to be sustainable at scale.

We need to frame the value of open source in company terms. There are things that companies have budgets for, like training.

In open source you’re working with the largest team in the world. You learn all kinds of useful skills working in open source – good API design, good docs, dealing with constraints. There is no forced adoption in open source. You need to build good things to get things adopted. It also takes you out of your comfort zone. You get broad experience as a product owner, designer, engineer, leader and diplomat. This makes it worth investing time as a form of training.

But the biggest argument is risk. Companies think about risk a lot. Legal risk, retention risk, insurance, security risks. Heartbleed exposed this risk.

A question to ponder: what would be the cost if the company had to maintain an open source package it is currently using? How many days effort are being saved?

No one individual or company should bear all this cost. What if companies paid a small, but relative amount to open source: for a $100k developer, give $100 to open source. Think of it as paying your open source team.

We are the ones who have to make this happen. We have the power to make this happen. We make decisions about infrastructure and licenses.

Do you think companies wanted to pay for ping pong tables and free lunches? No. They have a demonstrable ROI. People showed that ROI and got the budget.

Demonstrate the value of open source and add a line item to the budget. It doesn’t have to be big.

(At this point Jed gave everyone an open source collective gift voucher to invest in an open source project! I gave mine to stylelint)

Help start this conversation. Talk about the value of open source. Get your company to make a $100 donation to Open Collective. If everyone at ReactConfAU did that, it’s $50,000.

Just 1% of the world’s developers donating $100 per year would triple the funding going into open source.

We are all here because of open source. Funding it does make sense within the models companies use to spend money.

Let’s add a line item for open source.